特徴選択（スプリント計画 – パート1)
多くのチームは、機能の選択を導くために、イテレーション全体の目標を設定します。会議の開始時には、通常、リリース計画から優先度の高い機能が選定されます。イテレーションに包括的な目標が設定されている場合は、その目標との整合性が高い場合は、優先度の低い機能が選定されることもあります。チームが現実的な作業量をスケジュールするには、事前のベロシティが不可欠です。
例えば、チームが当初40ストーリーポイント相当の製品機能の獲得を計画していたものの、実際に提供できたのは30ストーリーポイントだった場合、次のイテレーションの現在のベロシティは30ストーリーポイントと見なすべきです。過去のベロシティ見積もりと実際の数値の比較は、イテレーションレベル、機能レベル、タスクレベルで役立ちます。これらはすべて、チームが次のイテレーションでどれだけの機能を契約できるかを判断するのに役立ちます。イテレーションがオーバーブッキングした場合、顧客はどの機能を将来のイテレーションに延期する必要があるかを選択する必要があります。 反復計画 会議では、顧客はチームと機能について話し合い、チームの質問に答えようとします。
タスク計画（スプリント計画 – パート2)
チームは機能をタスクに分割します。開発者はタスクにサインアップし、見積もりを行います。タスクの所要時間は通常4時間から2日間で、ほとんどのタスクは1日以内に完了できます。2日を超えるタスクは、通常、より小さなタスクに分割する必要があります。タスク計画中に、当初の計画で機能が著しく過小評価されていたことが判明する場合があります。 リリース計画この場合、チームは顧客と協力して修正された見積りを提供し、その結果どの機能を遅らせる必要があるかを判断する必要があります。
反復調整
イテレーション中に、すべての機能の提供後にまだ時間がある場合、チームは顧客にイテレーションに追加する機能の特定を依頼できます。一方、すべての機能を提供できないことが明らかな場合は、チームは顧客と協力して、イテレーションの期限までに最大の価値を提供するために、どの機能を延期するか、あるいは分割するかを決定します。
警告サイン
- 一連の反復を通じてチームが機能を将来に先送りし続ける場合、それは継続的なオーバーブッキングを最小限に抑え、計画の精度を最大化するためにチームが以前の速度にもっと注意を払う必要があることを示しています。
- チームが各イテレーションで同じ機能を推進し続ける場合、それはチームが特定の機能を意図的に避けていることを示している可能性があり、根本原因を調査する必要があります。
- チームが細部にこだわりすぎて各機能を完全に設計している場合は、必要なタスク作業の特定に重点を置く機会が増える可能性があります。
よくあるご質問
タスク間の依存関係をどのように処理しますか?
この質問はよく聞かれます。イテレーション計画の一環として、チームは機能を分割する際にタスクの依存関係を最小限に抑えるよう努めるべきです。具体的なテクニックは、マイク・コーンの優れた著書に数多く記載されています。 適用されたユーザー ストーリー次に、チームは避けられない依存関係の影響を最小限に抑えるために協力するよう努めるべきです。アジャイルチームは通常、依存関係を最小限に抑える、シンプルで疎結合、かつ適応性の高い設計を採用します。このようなアーキテクチャを考案し、改良するための優れたリソースとして、ボブ・マーティンの画期的な著書があります。 アジャイルソフトウェア開発：原則、パターン、実践アジャイル チームは、相互に依存するサブシステムとモジュールで同時に作業できるようにする手法、ツール、およびプラクティスも使用します。 テスト駆動開発、自動テストハーネス、モックオブジェクトは、チームがタスクの相互依存性を最小限に抑え、対処するのに役立ちます。継続的かつ緊密なコラボレーションが鍵となります。同じ場所にいるチームは、イテレーション全体を通して、依存関係の課題をジャストインタイム方式で共同で解決することが容易になります。
イテレーションの長さには限りがあるため、潜んでいる依存関係が1つでも存在すればプロジェクトが頓挫するリスクを軽減できます。PERTチャートやCPMは、システム全体の理解を深める上では有用ですが、高速で反復的なソフトウェア開発のストレス下では、その効果を発揮しきれない可能性が非常に高いです。2週間のイテレーションのために依存関係モデルを構築するために費やす追加の時間と労力は、ほとんど割に合いません。自動化されたテストとコードは、少なくとも同等の速さで、より正確で実行可能なフィードバックを提供します。
チームメンバーはいくら登録すればいいですか?
チームメンバーが、前回のイテレーションで完了できたタスクの見積もり合計を超えて参加することは稀です。イテレーション計画中にタスクが参加されていない場合は、前回のイテレーションの機能とタスクの速度と比較し、チームが過剰な作業を引き受けないようにすることに重点を置きます。
チームの規模が異なる場合、反復をどのように計画しますか?
一貫したチームワークがなければ、アジャイルであろうとなかろうと、どんなプロジェクトアプローチも多くの洞察を提供しません。しかし、反復的なソフトウェア開発では、少なくとも時間の経過とともに蓄積される何らかの履歴があり、それを計画の基盤として活用できます。反復的な開発において、10人のチームで平均速度20理想日、つまり1イテレーションあたり200時間で複数のイテレーションを実施した後、チームが半分に削減された場合、単純な計算で、次のイテレーションでは（少なくとも当初は）10理想日を超える計画は立てないはずです。主要メンバーが削減された場合、あるいは計画が間違っていたことが判明した場合、数週間以内にその事実が判明し、将来のイテレーションに向けて迅速に調整できるようになります。
諸経費（会議、電子メールなど）はどのように計上しますか?
チームは一般的に、軽微なオーバーヘッド項目の追跡に多くの時間を費やしません。数回のイテレーションを経て、これらの中断は、（予期せぬ場合でも）実際の速度に反映され、より一貫性のあるものになります。リスクを軽減し、可視性を高めるために、より大きな中断や混乱をイテレーション計画に明示的に組み込むチームもあります。
イテレーション計画中にバグ修正をどのように考慮しますか?
チームがバグ修正に取り組む方法はいくつかあります。最もシンプルな方法の一つは、バグをイテレーション計画に明示的に入力し、優先順位を付け、関連するタスクを見積もることです。バグと機能は、計画の目的において本質的に同等の作業単位です。チームによっては、イテレーションプロセスとは別にバグを追跡することを選択する場合もあります。これは多少リスクが高くなります。バグ修正の労力がイテレーション間で変動すると、チームのベロシティもそれに応じて変動し、見積もりや計画に狂いが生じてしまうからです。しかし、バグ修正の労力が一定であれば、この方法は十分に機能します。
反復は常に同じ長さである必要があるのはなぜですか?
同じ長さ、あるいは非常に短い長さのイテレーションは、チームが見積もりや計画に頼るリズムを生み出します。固定長のイテレーションがないと、安定した速度の達成と測定が難しくなります。イテレーションの終了時に生産を停止するという規律は、全員の意識を集中させ、設計をシンプルに保ち、ゴールドプレーティングやスコープクリープを防ぐプレッシャーを与えます。組織全体は、入力、計画、実行、出力、振り返りという安定した流れにすぐに慣れてしまいます。このリズムがなければ、チームの効率は低下します。締め切り、大きな中断、休日などに合わせて、特定のイテレーションを延長または短縮する正当な理由が時折あるでしょう。しかし、これは例外であり、規則ではありません。
テストとドキュメント作成の時間をどのように計算すればよいですか?
テストとドキュメントの更新は、開発者の時間を費やす他の主要な活動と同様に、優先順位を付け、見積もり、計画する必要があります。これらは特定の機能のタスクとして作成されることが多いですが、独立した機能としてグループ化されることもあります。
反復計画中に機能の見積りを修正する必要がありますか?
機能の見積りは、元の見積りが著しく外れており、新しいレベルの作業がチームの他の作業を完了する能力に大きな影響を与えることが判明した場合にのみ、反復計画中に修正する必要があります。
反復中にタスクの見積りを修正する必要がありますか?
当初のタスク見積りは、イテレーション計画が完了した後は修正すべきではありません。一方、将来のイテレーションの見積りは、残存作業量の正確な評価を反映するために継続的に修正する必要があります。
すべてのチームが同じ反復スケジュールで作業する必要がありますか?
すべてのチームが同じイテレーションスケジュールで作業することには利点があります。チーム間でイテレーションのステータスをロールオーバーすることは、チームが同じスケジュールで作業している場合にのみ意味があります。イテレーションを開始したばかりのチームと、もうすぐ終了するチームのステータスを数値的にロールオーバーしても役に立ちません。すべてのチームが同じイテレーションスケジュールで作業することの欠点は、すべてのイテレーションが同時に開始および終了することです。プロジェクト間で共通リソース（顧客や経営陣など）を共有する場合は、チーム間でイテレーションのスケジュールをずらすことが効果的です。
