デリバリー計画とは
開発組織が大きくなると、小さなチームに再編成し、作業単位を分割して効率的に管理できるようにする必要があります。 これらのチームは、通常、組織のより大きな目標の枠の中でチーム固有のニーズを満たす作業スケジュール、ボード、およびその他のプロセスを持ちます。 時間の経過と共に、組織は、一貫性のあるフレームワークにプロセスを集約することで、ネットワークのメリットを享受できるようになる可能性があります。
"デリバリー計画" とは、1 つまたは複数の作業スケジュールを視覚化したものです。 各チームが何をいつ作成する予定なのかについての全体像をチームと経営陣に提供することを目的としています。 それにより、組織全体の投資を最適化する決定を行うことができます。
チームは、デリバリー計画を定期的にレビューし、自分達の作業スケジュールが他のチームのスケジュールと整合していることを確認する必要があります。 これらのレビューでは、次のようなことを確認する必要があります。
- 現在のスケジュールでコミットしている内容を確実に実現できるか?
- 私たちが依存するチームが、彼らの現在のスケジュールで私たちが必要としているものをデリバリーしてくれることを確信しているか?
- 私たちのスケジュールの中に空いている期間があり、作業で埋めることができるか?
- チーム内またはチーム間の依存関係に問題があるか?
デリバリー計画は、プロジェクトのライフサイクルのどの時点でも付加価値をもたらします。 チームのバックログに基づいて動的に生成されるため、常に最新の状態にあり、最新の分析情報が提供されます。
Tailspin Web チームの話し合いに参加してみましょう。
Andy: 先ほど、エンジニアリング管理とすばらしいミーティングを行いました。 私たちが Azure Boards を使って行っている作業をデモしたところ、他のチームにも利用してもらえるのではないかと大きな期待を寄せてくれました。
Mara: すごいですね。 彼らはいつ開始するのでしょうか?
Andy:それが最も良い部分です。 彼らはすでに持っています。 昨晩、ゲーム エンジンのプロジェクト リーダーがチームを作ってスプリントいくつか設定し、作業項目の追加を開始しました。 今朝、ちょっと見てみたところ、いい感じに仕上がっています。 彼らが何をしようとしているのかをお見せしましょう。
Andy は、ゲーム エンジンの現在のスプリント ボードに移動します。 彼と Mara は、大いに興味を持って作業項目を確認します。
Andy: うーん、このスプリントの終わりまでベータ版のデプロイ予定がないですね。 次のスプリント中にランキングをベータ データベースと統合する予定では? ベータ版を先に出してもらわないと、私たちが作業できないですね。
Mara: 良い点を突いていますね。 私たちが成果物を作れるかどうかは、そのチームが成果物を作ってくれるかどうかにかかっています。
Andy: これでは、次のスプリントで私たちの生産性がひどく下がるかもしれない。 電話して、どうなっているのかを聞いてみます。
残念ながら、チーム構造が複雑になると、コミュニケーションのギャップや遅れが生じることがあります。 1 つのチームがブロックされると、別のチームが依存しているものを作成できなくなるおそれがあります。 これは、すべての懸念事項について毎日会議を開く小規模チームにとっては大きな問題ではないかもしれません。 それに対して、チームの規模と場所が拡大すると、すべての場所で起こっているすべてのことを全員が知ることができなくなるおそれがあります。 この時点で、組織は、純粋な "プッシュ" モデル (個人または電子メールによる通知など) から "プル" モデル (チームが互いのスケジュールを確認および追跡できる) に移行する必要があります。
Andy: 開発リーダーと話をしました。 彼女のチームは、アート チームが Cliffchella から戻ってくるまで、ベータ版の出荷がブロックされるそうです。
Mara: 山頂で行われる音楽祭のことですか?
Andy: そうです。デザイン コミュニティの大イベントのようで、チーム全員が参加するために丸 1 週間いません。 ゲーム エンジン チームは、彼らのスケジュールが 3 週間遅れたため、かなり混乱しています。 このことが事前にわかっていたら、必要な成果物を前もって確実に入手していたことでしょう。 また、私たちにすぐに知らせなかったことを謝っていました。 私たちが出荷するために、彼らのベータ版を待つことになると気付いていなかったのです。
Mara: まあ少なくとも、ゲーム エンジン チームがスプリント計画を公開していることは喜んでいいでしょう。 おかげで今回の依存関係の問題を早期に見つけて、スケジュールを調整することができたのですから。
Andy: こうした潜在的なリスクの発生をもっと簡単に確認できる方法があればいいと思います。 私たちのチームは全社的に非常に多くの依存関係があります。すべての会議に出席し、すべての配布グループにサブスクライブするのは無理です。
Mara: デリバリー計画を作成して、チーム スプリントを並べて表示できるようにする必要があります。 こうすることで、両方のチームが、スケジュールが相互にどのように影響するかを簡単に特定できます。
複数のアジャイル チームを管理するための推奨事項
アジャイル アプローチを Azure DevOps と合わせて使用すると、プロジェクトの透明性と予測可能性を大幅に向上させることができます。 しかしながら、プロジェクトは依然として従来の課題に直面するおそれがあり、それは人や誤解に関連していることが多々あります。 ここでは、アジャイル作業をスケーリングする場合に考慮すべき点をいくつか紹介します。
人とプロセスに対する信頼を築く
初期段階では、アジャイル実装がチームのパフォーマンスを向上させることができるかどうかについて懐疑的な意見が多くあります。 組織内のソート リーダーは、ツールとプロセスによって結果がどのように生成されるのかを示すことで信頼を築くことが重要です。 この結果、生産性が向上することもあり、簡単に定量化できます。 しかし、スケジュールの回避可能な遅れや品質問題など、潜在的な問題を回避することでチームの勝利が生じることを忘れずに強調してください。 人々が成果とそれを達成したプロセスを結びつけ始めると、より熱意を持って取り組んでもらえるようになるでしょう。
組織をチーム (および個人) よりも優先させる
新しいプロセスまたはポリシーが提案されたとき、チームや個人によっては縄張り意識が生まれます。 新しいポリシーを、特定のチームや個人のパフォーマンスに悪影響を与えるものと捉えるのではなく、組織全体の新しい透明性によって全員に期待が伝えられることを強調します。 自分たちの作業が組織の目標達成にどのように関連しているのかをだれでも追跡できる場所を 1 つ用意することで、自分たちがプロセスにコミットすることの重要性を理解できるようになります。
透明性の高い文化を育む
残念なことに、"透明性" という言葉には悪いイメージがあります。 すべてがうまくいっているときに、透明性をさらに求める人はいません。 むしろ、チームが苦労しているときに透明性 (またはその欠如) が非難されることが多いのです。 アジャイル チームに透明性を高めるためのあらゆる機会が与えられていても、それでも個人とチームが誠実であるかどうかに左右されます。 透明性を確保する理由の 1 つは、潜在的な問題を手遅れになる前に特定して対処できるようにするためであることを強調してください。 スケジュール期限に間に合わない状況に陥ることがあることはだれもが理解しています。 しかし、悪いニュースをぎりぎりまで報告しても大丈夫だと思えなければ、はるかに破壊的な影響を与えるおそれがあります。 透明性に対する安心感を築くには、予想される遅延をできるだけ早く報告してくれる人に感謝することから始めましょう。