スクラム開発ではチームのベロシティを測り、逆算して開発のゴールがいつくらいになるかを見積もります。
しかし、チームメンバーの変化の多いフェーズではチームのベロシティを測ることが難しいケースもあります。
特にチームの立ち上がりフェーズで、予定の人数を立ち上げ時には集めておらず、開発が進捗する度に１人ずつ増員する場合などがあります。
例えば１ヶ月に１人の増員が入るフェーズだと、３週間で３スプリント回して、平均的なベロシティが見えてきた時には１人増加することで、ベロシティの指標の値がリセットされてしまいます。
これは今までの人数プラス新しい人の分が増えると言う単純な話ではありません。
チームメンバの参加は既存チームのスキルトランスファーをする上で既存メンバーのスピードを落とすこともあります。また、通常チケットに上げづらいような細かな作業が得意なメンバかもしれません。
新しいメンバーの参加はチームに変化をもたらします。
ベロシティが測れない中で、どのように計画を立てたら良いのでしょうか？
バックログに全てに全員でポイントを付けるのはとても時間がかかりますし、スプリントプランニングを待っていたら計画を立てれません。
その作業こそがプロダクトオーナーの仕事なのですが、スケジュールという観点はスクラム開発では定義されていません。
タイムボックスとベロシティが指標になっています。
多くのプロジェクトではビジネス的な要件や契約などによってスケジュールを意識する必要があるケースが多くあります。
スケジュールに対する柔軟性を持っているならば、そのスケジュールに関する機能が柔軟性や堅牢性、保守性を重視すべきならばスケジュールの延長を提案しますが、技術的負債を抱えてもスケジュールを優先するべき重大な事案がビジネス要件としてある場合には、システムの機能は稼働すれば良いという水準にまで下がります。
どちらを選択すればよいかは状況に寄るため、スケジュールの延長が悪いことというのが悪いことであるかはわかりません。
この考えを前提に考えると、ベロシティとスプリントプランニングだけでは見積もりの見通しが悪くなります。
まとめると
- チームの変化が多い
- スケジュールに対して厳しい要望がある
- システムの技術的負債をコントロールする権限がある
- そして割り込み作業がほとんどない
これらの場合やチームがまだ無く見積もり時などの場合ではガントチャートは計画を非常に明確にしてくれます。
アジャイル開発は計画を立てないと言われがちですが、場合によってはしっかりとガントチャートを書いてはじめると良いケースも多いです。
ただし、チームが動き出すと計画はどんどん変わっていきます。
その場合にはガントチャートに縛られすぎず、スクラム開発用のツールやカンバンツールをメインに切り替え、
システムの価値がどこにあるのかを考え、それをコントロールする権限を手に入れ、良いシステムを作る方法を模索して下さい。
それこそがアジャイル開発です。