スクラムは、ジェネラリストメンバーがいるチーム、つまり、少なくとも2人が同じタスクを実行できるチームに最適です。私の主な関心事は、専門家で構成されたチームのためにスクラムを適応させるための優れたソリューション(何を保持し、何を削除し、改善するか)を見つけることです。
5人の開発者からなるチームがあると仮定します(実例ではなく、単なる例です)。
- Cの強力なスキルを持つ1人の数学者。
- 1人のDB開発者。
- 1人のWeb開発者。
- UX / GUI開発者1人。
- 1人のソフトウェアアーキテクト。
ここでは、すべてがスペシャリストであり、誰も他の誰かを置き換えることはできません(このようなチームを構築するリスクは気にしません。スクラムに集中したいと思います)。だから、スクラムの文脈で、ここに私の考えがあります:
- 役に立たない春の計画:実際、数学者が特定のタスクに2ポイントの価値があると言ったとき、誰も彼に反対することはできません。
- 役に立たないチーム速度メトリック:誰もが自分のタスクに任意の数のポイントを割り当てることができるため、速度の計算は意味がありません。
- 毎日のスクラム会議を毎週(より長い)スクラム会議に置き換えます。チームの各メンバーが自分のタスクに取り組んでいるため、毎日のスクラム会議は「チームスピリット」を維持するために非常に重要です。ただし、毎日のスクラム会議は約15分間続くことになっています。これは明らかに、他の人が何をしていて何をするのかを理解するには不十分です。さらに、数学者はほとんどの場合、同じことを答えます。「私はまだ%&Lo(+?$$ +&)をやっています」...毎週のミーティングでより多くの時間が与えられます。「最初の」スクラム会議と「毎週の」スクラム会議の間で同じ会議時間を維持するには、各週のスクラム会議を継続する必要があります(週5日、4週間のスプリント、スプリント会議は4時間、毎日の会議は15分)。 (4 * 60 + 20 * 15)/ 4 =>
または、スクラムはまだ使用可能ですか?たぶん別のアジャイル技術を使用する必要がありますか?