長期計画とアジャイル？
私のチームは最近、私たちの仕事のほぼ1年間の計画を立てるプロセスを進めました。計画を3つのフェーズに分けました。各フェーズには、いくつかの起動が含まれます。
あなたの俊敏性の点から、これは間違っているのでしょうか？最初の数ステップ以外の設計にはあまり時間をかけていなかったので、それは悪い考えではないと思います。私たちは方向を変えることが可能です。同時に、目先のことしか考えずに行動しないのはいいことです。
プロジェクトがどこに行くべきかというビジョンを持つことはGood ThingTM。
それが正確に何が起こるかを信じていません。
「戦いの準備をするとき、私は常に計画は役に立たないことを発見しましたが、計画は不可欠です。」
-ドワイト・D・アイゼンハワー
アジャイル手法が採用するアプローチは、物事を消化可能な断片に分解し、各断片が消化された後にビジョンを再調整することです。
つまり、今から1年後のあなたの終点は、あなたが今思っているとおりにはならないということです。ただし、リスト内のすべての高価値アイテムに取り組み、ステークホルダーが関与し、前進するにつれて満足していたはずです。
OK、経営陣は計画を立てる神話を提示されました。私は、あなたのために、彼らがあなたをそれに拘束しないことを望みます。目に見えないので、私はあなたのチームがその長期計画が言っているようなことを何も達成しないことにお金を賭けて喜んでいます。実際、業界の平均に達した場合、約2倍の損失が発生します。そして、ほとんどの組織では、推定値が与えられれば、彼らが好きなだけ勝つことができるクラブになります。
あなたはたぶん私はただ皮肉だと思っています。結局のところ、誰もが予測するよりもはるかに遅いまたは速く起こる可能性があることを誰もが知っている、特定されていない機能のセットについて漠然とした時間を伝えただけですよね？申し訳ありませんが、そのほとんどは本当かもしれませんが、人々がそれらの数字を聞く傾向があるわけではありません。彼らは日付を聞いたことがあり、一度話された日付はあなたが言ったよりも堅実であると聞かれる傾向があります。さらに、コミュニケーションのチェーンがあれば、それはまだより強固になります。そして、外部の顧客があなたの言ったことに基づいて販売によって何かを約束されたら、突然、それらの数値には本来あるべきよりもはるかに少ない柔軟性があることに気付くでしょう。そして、私はあなたが物事にかかる時間を過小評価したことを保証します。
その明白なポイントが邪魔になっているので、ソフトウェアの推定の実際の方法について何かを学ぶために ソフトウェアの推定 を読むことをお勧めします行われます。あなたはあなたが間違ったことをたくさん学び、次回はもっとうまくやる方法を学びます。 （その過程で、あなたが私が何をするかを過大評価したほど私が自信がある理由を知るでしょう。）
とはいえ、アジャイルとは主に、プロセスを小規模なチームに適したものに減らすことです。多くの場合、プロセスを削減するための良い方法は、大規模な長期計画を削減して、短期的にはより小さなものを計画することです。また、将来何が起こるかわからないため、より正直になる傾向があります。ただし、これは多くの場合、より大きなビジネスニーズに適合しないため、アジャイルであると宣言するかどうかに関係なく、より長い計画を立てる必要がある場合があります。
そうは言っても、あなたが伝えた日付に関する重要な事実を発見することを強くお勧めします。残念ながら、これはあなたに噛む期限として戻ってくる可能性が高いです。そしてその事実はこれです。人々はどちらを気にしますか、日付、または機能セット？これが私が意味するところです。多くの場合、組織には重要な特定の日付があります。たとえば、会議のために、または休日のラッシュの前に何かを行います。その場合重要なのは何かをリリースすることであり、その何かが完全であるかどうかはそれほどではありません。また、実際に一緒にリリースする必要がある一連の機能があり、完全にそれが発生するときよりも完全性が重要です。現在の状況を発見できれば、チームは（ほぼ）避けられないクランチの処理方法を計画するのにはるかに有利な立場になります。
進行中の作業であり、石で書かれたものではないと考える限り、計画を立てることは問題ありません。
ここで重要なのは、定期的にリリース（少なくとも毎月）、ユーザーから実際のフィードバックを収集し、そのフィードバックに基づいてプランを更新するを作成することです。
つまり、プロジェクトの範囲が変更されると、計画が変更されます。これは良いことです。これは、ユーザーが何を求めているかについて多くを学んだことを意味します。
_project-management_およびagileがスクラムを意味すると仮定すると、これは正確な方法ではありません。
Scrumの観点では、1年の計画を立てた場合、少なくとも1か月の数と同じ数のスプリントが必要です。したがって、1年間の計画は2つのスプリント間で変更できるため、より機敏になります。
Sprintは1か月を超えることはできません。Teamは、_Sprint Backlog Items_をDoneの状態にコミットします。
Doneはここで重要な単語であり、各_Scrum Team_には、doneの定義が1つ必要です。つまり、実行する必要のある作業が残っていません。 _Sprint Backlog Item_がDoneの場合、これは、分析、アーキテクチャ、および技術文書が作成され、機能が徹底的にテストされていることを意味します（単体テスト、統合テスト、機能テスト... ）。
_Product Backlog_が配置され、重要度の低い機能が最下位に、最も重要な機能が上位にある項目に優先順位が付けられると、チーム（開発者）は各_Product Backlog Item_の開発期間を決定します彼ら自身の経験に基づいて取るものとします。これが、プロジェクトに1年間の作業が必要であると判断できる場所です。 _Product Owner_のみがアイテムに優先順位を付けることに注意してください。それは、投資収益率の責任を負うのがアイテムであり、そうでない場合は、エンドユーザーにとって何が最も重要かを知っています。さらに、チームは機能を完全に開発するのに必要な時間を評価する必要がありますが、この機能のニーズに適した再利用可能なコードの断片があり、つまり、さらに複雑になることを避け、アイテムがチームが必要とするよりも長い。製品バックログは完全である必要はありません！開発するシステムについて考えることができるユーザーストーリーの単純な列挙は、プロセスのその段階では十分です。
チームが次のSprintのために何を開発するかをコミットするのは_Sprint Planning Meeting_の期間であり、したがって_Sprint Backlog_を作成します。 _Sprint Backlog_は、Teamがスプリントの最後に実行することをコミットする_Product Backlog Items_に基づくサブセットで構成されます。たとえば、50項目の製品バックログを検討し、50項目すべてに1年を要することを考えると、チームは、たとえば製品バックログから5項目を選択し、これらの5項目でスプリントバックログを作成できます。これらの同じ5つのアイテムは、必要に応じて他の複数のアイテムに展開/分解される可能性があるため、チームは改訂後に気が変わり、以前に選択した5つのアイテムのうち4つだけを製品バックログから実行することを約束します。
スプリント計画会議が終了すると、1か月のスプリントで8時間を超えることはありません。その間、チームは選択されたアイテムの作業をコミットするだけでなく、どのように作業を完了するかを計画します。チームの全員が彼女/彼女が何をしなければならないかを正確に知っているように、Sprintが始まります。チームは、プロジェクトのために部門を超えて活動することが重要です。
つまり、現在の状況で1か月続く各スプリントの最後に、Teamが実行することを約束したすべてのアイテムは、選択されたアイテムを対象とする完全に機能的な機能の成果物になります。製品バックログから。配信可能である必要がありますが、_Product Owner_に従って配信しても意味がない場合は、配信される必要はありません。
_Sprint Review Meeting_の呼び出し時に_Product Owner_を呼び出す必要があるのは、Teamがスプリント中に何が行われたかを示し、通知する必要がある場所です。該当する場合、コミットしたすべての作業をまだ行っていない理由。元に戻された作業は_Product Backlog_に戻され、次のSprintで使用できます。目的が変更された場合に備えて、プロダクトオーナーから特に指示がない限り、これらの元に戻されたアイテムは次のスプリントに含まれることを確認してください。ただし、最も重要なのは、スプリント中にシステムの目的が変更されたとしても、絶対に必要な場合を除いて、それを中断しないことです。プロダクトオーナーのみがスプリントを中断する権限を持っています。
_Sprint Review Meeting_が終了したら、月間スプリントで4時間を超えないようにします（私が正しく覚えていれば）、_Sprint Retrospective Meeting_にたどり着きました。 _Sprint Retrospective_はTeamが発生するために必要です。これにより、スクラムマスターとプロダクトオーナー（オプション）の前で、何が問題であったか、どのように議論することができますスクラムチームはそのパフォーマンスなどを改善し、それに応じて調整を行うことができます。
_Sprint Retrospective_のタイムボックスが終了すると、新しい_Sprint Planning Meeting_が発生して、次のSprintを計画し、新しい_Sprint Backlog_を作成します。
Teamは_Daily Scrum_を維持する責任があります。これは15分間のスタンドアップミーティングで、すべてのチームメンバーが3つの質問に（特定の順序ではなく）答えます。 ：
- 前回のデイリースクラムから何をしましたか？
- 次のデイリースクラムまで何をする予定ですか？
- 最後のデイリースクラム以降に発生した問題または障害は何ですか？
_Scrum Master_はそこに義務付けられていませんが、チームがデイリースクラムで会合し、メンバーが3つの質問に適切に回答することを保証する必要があります。
スクラムマスターは、他のスクラムチームメンバー（スクラムマスター、プロダクトオーナー、チーム）によるスクラムルールの尊重に責任を負います。
最終的に、これらの単純なルールに従って、開発チームは俊敏になります。敏捷性とは、チームができる限り迅速に、つまり各スプリントの最後に変更に追いつくことができる機能であり、そこでは、製品オーナーが製品バックログにもたらした変更を知ることができます。完全な災害が発生し、方向が完全に変わった場合、会社が吸収しなければならない最大の損失は1か月の開発であり、月に約20営業日しかないことを考えると、これは非常に無視できます。
スクラムおよびアジャイルソフトウェア開発に関するさらに詳細な情報が必要な場合は、 Scrum.org および Scrum Guide を参照してください。
まあ、それはかなりの答えです！これが少なくともあなたのプロジェクト管理を通じてあなたを助けることを願っています。
編集＃1
3つまたは4つのフェーズを実行することを計画している間、それを呼び出すと、チームは主な目的の観点から焦点を失う可能性が高くなります。チームが行ったことを第1四半期だけで実証した場合、ソフトウェアのアーキテクチャを再設計して再考し、おそらく20日以上の作業が失われたことを再開するために、いくつかの重要な変更が行われる可能性があります。俊敏性の原則は、変更が発生するとすぐに、または妥当な時間内で、つまりスプリントの場合はスプリントのタイムボックスで可能な限りすぐに、変更に追いつくことができるようにすることです。
私はあなたができる限り多くの打ち上げを持つべきだと思います。ソフトウェア開発の進捗状況に関する唯一の実際のフィードバック/測定基準は、本番環境にデプロイされたコードです。したがって、どのプロセスを使用しても、ライブで展開する頻度が高いほど、俊敏性が向上します。つまり、実際のユーザーから実際のフィードバックをより早く受け取り、より早く適応することができます。
あなたはすべきではありません Big Design Up Front 、スクラム（次のスプリント用）とかんばん/フロー（WIP制限に余裕がある場合）。全体（製品、サービスなど）を考慮すると、次にどのワークアイテムがより多くの価値をもたらすかを考えるのは簡単です。
全体像が変化することに注意してください。バックログ、優先順位の調整などを検討するのと同じくらい頻繁に、全体像の変更も検討します。特定の顧客や市場全体のニーズも含め、状況は時間とともに変化します。あなたの全体像はこれを反映する必要があります。そうすることで、計画を立てるときだけでなく、バックログを補充するたびに優先順位を現実に合わせることができます。
要するに、私はあなたが より機敏 を得ると思います、より多くの検査と適応をします。
全体像の計画はそれほど長くはかからず、スプリントを定義するときに大きなプロジェクトが全体像を念頭に置くことは非常に重要です。
あなたがすべき：
あなたが行くにつれて進化するマスタープランを（できれば締め切りなしで）持ってください。
スプリントを定義するときは、スプリントが全体像と一致していることを確認します。これは、必ずしもスプリントに何が必要かについての考えを変えることを意味するわけではありません。スプリントを定義するときに、全体像を調整する必要があることに気付く場合があります。いずれにしても、全体像の計画とスプリントは、スプリントに入るときに互いに一致している必要があります。
マスタープランは、必要に応じて調整する必要があります。仕事をしながら、物事を学びます。新たな機会が生まれ、計画の対立点が浮上します。マスタープランは、必要に応じてその場で調整できます。しかし、ほとんどの場合、スプリント間で再検討する必要があります-最後のスプリントからのレッスンを組み込み、次のスプリントが全体像と調和するようにします。
バックログと大きなプロジェクト計画は別々の構造になっているのが一番良いと思います。大きなプロジェクトオーナーは、マスタープランを階層的なアウトライン形式で保持してコンテキストを維持し、そこから機能/タスクをプルしてバックログをフィードし、バックログをフィードして、次のスプリントにフィードすることができます。
マスタープランとは異なり、バックログは他のチームメンバーが追加できます。バックログアイテムと全体像の計画が調和するようにすることは、メインプロジェクトのオーナーの責任です。バックログアイテムと全体像の計画を調整することもあります。
この方法は、アジャイルの力を維持し、プロジェクトのすべての要素を、全体像の計画を通じて特定の時点で可能な限り最高に調整する力を維持します。
ジム