長期計画とアジャイル？

私のチームは最近、私たちの仕事のほぼ1年の計画を立てるプロセスを経験しました。計画を3つのフェーズに分けました。各フェーズにはいくつかの起動が含まれます。

あなたの機敏な点から、これは間違っているのだろうか？私たちは最初のいくつかのステップ以外の設計にあまり時間を費やしていないので、それは悪い考えではないと思います。方向を変えることは可能です。同時に、目先の短期だけで行動しないことは素晴らしいことです。

プロジェクトがどこに行くのかというビジョンを持つことは、Good Thing ^TMです。

それが正確に起こると信じることはそうではありません。

「戦闘の準備において、計画は役に立たないことが常にわかっていますが、計画は不可欠です。」

-ドワイト・D・アイゼンハワー

アジャイル方法論がとるアプローチは、物を消化可能な断片に分解し、各断片が消化された後に視力を再調整することです。

つまり、今から1年後の終点は、あなたが今思うとおりに正確にならないということです。しかし、あなたはあなたのリストにあるすべての価値の高いアイテムに取り組み、あなたが前進するにつれてあなたの利害関係者を引き付けて幸せにしておくべきでした。

OK、経営者は計画を立てるという神話を提示されました。あなたのために、彼らがあなたにそれを抱かせないことを願っています。目に見えないので、私はあなたのチームがその長期計画が言っているようなことを何も達成しないだろうというお金を賭けるつもりです。実際、業界平均に達した場合、約2倍の見落としがあります。また、ほとんどの組織では、見積もりが与えられると、クラブは好きなだけ勝つことができます。

あなたはたぶん私はただ皮肉だと思っているでしょう。結局のところ、予想外の機能セットについて漠然とした時間を伝えただけで、予想よりもはるかに遅くまたは速く発生する可能性があることを誰もが知っていますか？申し訳ありませんが、そのほとんどは真実かもしれませんが、それは人々がそれらの数字を聞く傾向がない方法です。彼らは日付を聞いたことがあり、一度話された日付はあなたが言ったよりも堅実であると聞く傾向があります。さらに、コミュニケーションの連鎖があれば、それはより強固になります。そして、あなたが言ったことに基づいて外部の顧客が販売によって何かを約束されると、あなたは突然、それらの数にあるべきよりもはるかに少ない柔軟性があることに気付くでしょう。そして、私はあなたが物事にかかる時間を過小評価していることを保証します。

その明らかな点はさておき、ソフトウェア推定を実際に行う方法について学ぶために、ソフトウェア推定を読むことをお勧めします。間違ったことや、次回の改善方法について多くを学ぶことができます。（その過程で、私があなたがすることを過大評価するほど自信がある理由を学ぶでしょう。）

とはいえ、アジャイルは主にプロセスを小さなチームに適したものに減らすことです。多くの場合、プロセスを削減するための良い方法は、短期的に小さなものを計画するために、大規模な長期計画を削減することです。また、より正直になる傾向があります-将来何が起こるかわからないからです。ただし、それは大規模なビジネスニーズに合わないことが多いため、アジャイルであると宣言するかどうかに関係なく、より長い計画を立てる必要がある場合があります。

そうは言っても、あなたが伝えた日付について重要な事実を発見することを強くお勧めします。そして、その事実はこれです。人々は、日付、機能セットのどちらを気にしますか？これが私が意味することです。多くの場合、組織には重要な特定の日付があります。たとえば、会議や休日のラッシュの前に何かをする。その場合、重要なのは何かをリリースすることであり、その何かが完全であるかどうかではありません。また、一緒にリリースする必要がある機能のセットがあり、完全に問題が発生する場合よりも完全性が重要な場合もあります。自分がどの状況にいるかを発見できれば、あなたのチームは、今後の（ほぼ）避けられないクランチをどのように処理するかを計画するためのはるかに良い立場になります。

石で書かれたものではなく、進行中の作業であると考えている限り、計画を立てることは問題ありません。

ここで重要なのは、定期的に（少なくとも月に1回）リリースを行い、ユーザーから実際のフィードバックを収集し、そのフィードバックに基づいて計画を更新することです。

これは、プロジェクトの範囲が変わると計画が変わることを意味します。これは、ユーザーが望んでいることについてより多くを学んだことを意味するため、良いことです。

あなたがスクラムを意味すると仮定するproject-managementとagile、これは正確な方法ではありません。

でScrumあなたは1年間の計画を得た場合年の月があるとの視点、あなたは少なくとも、多くのスプリントとして持つべきです。したがって、1年間の計画は2つのスプリント間で変更可能であるため、より機敏になっています。

Sprint月、よりもはやなることはできませんTeamコミットをもたらすためSprint Backlog Itemsの状態にDone。

Doneここで重要な言葉であり、それぞれにScrum Team完了の定義が1つ必要です。つまり、実行する作業が残っていない場合です。a Sprint Backlog ItemがDoneの場合、これは、分析、アーキテクチャ、および技術文書が作成され、機能が徹底的にテストされていることを意味します（単体テスト、統合テスト、機能テストなど）。

いったんProduct Backlog配置され、重要度の低い機能が最下位にあるアイテム、および最上位にある最も重要なアイテムが優先されると、（開発者の）チームはそれぞれProduct Backlog Itemの経験に基づいて各開発に要する時間を決定します。ここで、プロジェクトに1年間の作業が必要になると判断できます。のみを考慮してくださいProduct Owner投資収益率の責任者であるか、エンドユーザーにとって最も重要なものを知っているので、アイテムに優先順位を付けます。さらに、チームは、機能の完全な開発に必要な時間を評価するものとしますが、この機能のニーズに合わせて再利用可能なコードが存在する場合があります。つまり、さらなる複雑さを避け、アイテムがチームが必要だと言ったよりも長い。製品バックログは完璧である必要はありません！開発するシステムについて考えることができるユーザーストーリーの単純な列挙は、プロセスのその段階で十分です。

これは、中にあるSprint Planning Meetingチームは、次のために開発されるものにコミットしなければならないことSprint、したがって作成します、Sprint Backlog。Sprint Backlog基づいてサブセットから成るProduct Backlog ItemsことをTeamコミットは、スプリントの終わりに行われます。たとえば、50アイテムの製品バックログを検討し、50アイテムすべてで1年を完了する必要がある場合、チームは、たとえば製品バックログから5アイテムを選択し、これら5アイテムでスプリントバックログを作成できます。これらの同じ5アイテムは、必要に応じて他の複数のアイテムに展開/展開される可能性があります。したがって、チームは改訂後に考えを変え、製品バックログで以前に選択した5アイテムのうち4アイテムのみをコミットします。

Sprint Planning Meetingが終了すると、1か月間のSprintが8時間を超えないようになります。Sprintでは、選択したアイテムの作業をチームがコミットするだけでなく、ジョブの実行方法を計画します。チームの全員が彼女/彼がし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。

すべてのチームメンバーが次の3つの質問に回答する15分間のスタンドアップミーティングである（特定の順序ではない）ことTeamを維持する責任があることを忘れないでくださいDaily Scrum。

1. 前回のデイリースクラム以降、何をしましたか？
2. 次のデイリースクラムまで何をするつもりですか？
3. 前回のデイリースクラム以降に遭遇した問題や障害は何ですか？

参加する義務Scrum Masterはありませんが、チームがデイリースクラムで会合し、メンバーが3つの質問に適切に回答することを保証する必要があります。

スクラムマスターは、他のスクラムチームメンバー（スクラムマスター、プロダクトオーナー、チーム）によるスクラムルールの尊重に責任を負います。

最終的に、これらの単純なルールに従って、開発チームはアジャイルになります。俊敏性とは、チームができる限り迅速に、つまり各スプリントの最後に、プロダクトオーナーがプロダクトバックログにもたらした変更を認識できるように、あらゆる変化に追いつく能力です。全体的な災害と完全な方向転換の場合、会社が吸収しなければならない最大の損失は1か月の開発であり、1か月に約20営業日しかないことを考えると、これはまったく無視できます。

スクラムおよびアジャイルソフトウェア開発に関する詳細情報が必要な場合は、Scrum.orgとそのスクラムガイドを参照してください。

まあ、それはかなりの答えです！これが少なくともあなたのプロジェクト管理に役立つことを願っています。

編集＃1

3つまたは4つのフェーズを行うことを計画しているときに、それを呼び出すと、チームは主な客観的な観点から焦点を失う可能性が高くなります。チームが行ったことを第1四半期だけでデモンストレーションする場合は、ソフトウェアのアーキテクチャの重要な再設計と再考を必要とするいくつかの重要な変更があり、おそらく20日以上の作業の損失を再開する必要があります。俊敏性の原則は、変更が発生するとすぐに、または合理的な時間内で可能な限り早く、つまりスクラムの場合はスプリントのタイムボックスに追いつくことができることです。

1. できるだけ多くのローンチが必要だと思います。ソフトウェア開発の進捗状況に関する唯一の実際のフィードバック/メトリックは、本番環境に展開されたコードです。したがって、どのプロセスを使用する場合でも、ライブでデプロイする頻度が高いほど、機敏性が高まります。つまり、実際のユーザーから実際のフィードバックをより早く受け取り、より早く適応することができます。

2. Big Design Up Frontを行うべきではありませんが、スクラム（次のスプリント用）とかんばん/フロー（余裕がある場合）の両方について、バックログを調整および補充しようとするたびに、全体像を考えるのは良いことだと思いますWIP制限で）。全体（製品、サービスなど）を考慮すると、次にどのワークアイテムがより多くの価値をもたらすかを考える方が簡単です。

3. 全体像が変わることに注意してください。バックログ、優先度の調整などを考慮するたびに、全体像の変化も考慮します。特定の顧客や市場全体のニーズを含め、物事は時間とともに変化します。計画を立てるときだけでなく、バ​​ックログを補充するたびに優先順位を現実に合わせることができるように、全体像にこれを反映する必要があります。

要するに、私はあなたがより多くのアジャイルを取得し、あなたが検査し、適応することになると思います。

全体像の計画にはそれほど時間がかかりません。また、スプリントを定義するときに大きなプロジェクトを念頭に置くことは非常に重要です。

あなたがすべき：

1. マスタープラン（できれば期限を付けないこと）を用意してください。

2. スプリントを定義するとき、スプリントが全体像と一致していることを確認します。これは、スプリントに何が望まれているのかという考えを常に変えるとは限りません。スプリントを定義するときに、全体像を調整する必要があることに気付く場合があります。大まかな計画とスプリントは、スプリントに入る際に互いに一貫している必要があります。

3. マスタープランは、進行に合わせて調整する必要があります。仕事をしながら物事を学びます。新しい機会が生まれ、計画の矛盾点が現れます。あなたが行くように、その場でマスタープランを調整することができます。しかし、ほとんどの場合、スプリント間で再検討する必要があります。最後のスプリントからの教訓を取り入れ、次のスプリントが全体像と調和するようにします。

バックログと大きなプロジェクト計画が別々の構造である場合が最善だと思います。大規模なプロジェクトオーナーは、コンテキストを維持するためにマスタープランを階層的なアウトライン形式で保持します。その後、機能/タスクをそこから引き出してバックログをフィードし、次のスプリントをフィードします。

バックログは、マスタープランとは異なり、他のチームメンバーが追加できます。バックログの項目と全体像の計画が調和していることを確認するのは、プロジェクトのメインオーナー次第です-時々バックログ項目を調整し、時には全体像の計画を調整します。

この方法は、アジャイルの力と、プロジェクトのすべての要素を全体像の計画を通して特定の時間にできる限り整列させる力を維持します。

ジム

ここに、私の反アジャイル暴言の短い形式を追加します。

特に将来の開発の基礎となるライブラリやフレームワークを構築する場合、アジャイルは大規模プロジェクトにとって非常に破壊的です。初期段階で本当に重要な懸念事項は、「私の設計が来年にわたって提供する必要がある機能をサポートするかどうか」です。ほとんどのアジャイル戦略では、そのような前向きな思考を考慮していないため、プロジェクトの失敗ポイントが作成されます。

私は自分自身でやけどを負ったので、この点で少し痛いです。コアライブラリの一部を書き換えています。最初のフェーズが完了し、スプリントの機能目標を達成しました。それはすべて非常に機敏です。その後、動的ローディング機能を追加するために搭乗しました。しかし、動的なロードはないと想定して書かれていたため、約6週間停止しました。書き直し、既に存在するものを回避するために多くの時間を無駄にしました。最悪の部分は、動的ローディングが最初の仕様にあったことです。将来のすべての要件を念頭に置いて初期作業を行い、アジャイルプラクティスが悪いと考える「前もって大きな設計作業」を行っていれば、数日で機能を実装できたでしょう。

教訓は、捨てたいと思っている小さなものにはアジャイルを使用することです。それは時々素晴らしいことがあります。ただし、それは1つの真のソフトウェア開発方法ではありません。リスクが高い、または寿命が長い基礎コードを作成する場合は、大きな設計を行います。