アジャイルを大規模なチームに拡大する

big とAgile という単語が同じ文の中で使用されることはあまりありません。 大規模な組織は動きが遅いという評判があります。 しかし、それは変わりつつあります。 多くの大規模ソフトウェア組織はアジャイルへの変革に成功しています。 彼らは、SAFe、LeSS、Nexus などの一般的なフレームワークの有無にかかわらず、アジャイルの原則を拡張する方法を学んでいます。

Microsoft では、そのような組織の 1 つがアジャイルを使用して、Azure DevOps ブランドで出荷される製品とサービスを構築しています。 このグループには 35 の機能チームがあり、3 週間ごとに運用環境にリリースします。

Azure DevOps 内のすべてのチームは、最初から最後まで、そしてそれ以降も機能を所有しています。 彼らは顧客との関係を所有しています。 彼らは独自の製品バックログを管理しています。 彼らはコードを作成し、本番ブランチにチェックインします。 3 週間ごとに本番ブランチがデプロイされ、リリースが公開されます。 その後、チームはシステムの健全性を監視し、ライブサイトの問題を修正します。

アジャイルの原則によれば、自律的なチームはより生産的です。 アジャイル組織は、チームが日々の実行を制御できるようにしたいと考えています。 しかし、自立性に整合性がない場合は、混乱が生じます。 独立して作業する数十のチームでは、統一された高品質の製品を生み出すことはできません。 調整によりチームに目的が与えられ、組織の目標を確実に達成できるようになります。 連携がなければ、最も優れたパフォーマンスを発揮するチームでも失敗してしまいます。

アジャイルを拡張するには、組織との連携を確保しながら、チームの自律性を有効にする必要があります。

連携と自律性の間の微妙なバランスを管理するために、DevOps リーダーは分類を定義し、計画プロセスを定義し、機能チャットを使用する必要があります。

分類を定義する

アジャイル チーム、およびアジャイル チームが属する大規模なアジャイル組織が成功するには、明確に定義されたバックログが必要です。 組織の目標が明確でない場合、チームは成功するのに苦労します。

明確な目標を設定し、各チームがその目標にどのように貢献しているかを示すために、組織は分類を定義する必要があります。 明確に定義された分類法により、組織の命名規則が作成されます。

一般的な分類は、エピック、フィーチャー、ストーリー、およびタスクです。

エピック

エピックでは、組織の成功にとって重要な取り組みについて説明します。 エピックを達成するには複数のチームと複数のスプリントが必要ですが、終わりがないわけではありません。 エピックには明確に定義された目標があります。 達成すると、エピックは終了します。 組織の集中力を維持するには、進行中のエピックの数を管理できる必要があります。 エピックは機能に分類されます。

機能

フィーチャーは、エピックの目標を実現するために必要な新しい機能を定義します。 機能はリリース単位です。 それらは顧客にリリースされるものを表します。 公開されたリリース ノートは、最近完成した機能のリストに基づいて作成できます。 機能は完了するまでに複数のスプリントを必要とする場合がありますが、顧客への一貫した価値の流れを確保できるサイズにする必要があります。 機能はストーリーに分割されます。

ストーリー

ストーリーは、機能を作成するためにチームが提供する必要がある増分価値を定義します。 チームは機能を段階的な部分に分割します。 1 つの完成したストーリーだけでは、顧客に意味のある価値を提供できない可能性があります。 ただし、完成したストーリーは製品品質のソフトウェアを表します。 ストーリーはチームの作業単位です。 チームは、機能を完成させるために必要なストーリーを定義します。 ストーリーは必要に応じてタスクに分割されます。

タスク

タスクは、ストーリーを完了するために必要な作業を定義します。

イニシアティブ

この分類法は、万能のシステムではありません。 多くの組織は、イニシアチブ と呼ばれるエピックより上のレベルを導入しています。

各レベルの名前は組織に合わせてカスタマイズできます。 ただし、上記で定義された名前 (エピック、フィーチャー、ストーリー) は業界で広く使用されています。

自律性のライン

分類を設定したら、組織は自律性の線を引く必要があります。 自律性の境界線は、レベルの所有権が管理者からチームに移されるポイントです。 管理者はチームが所有するレベルには干渉しません。

次の例は、フィーチャの下に描かれた自律性の線を示しています。 管理者は、調整を提供するエピックと機能を所有しています。 チームはストーリーとタスクを所有し、それらの実行方法について自主性を持っています。

この例では、経営陣はストーリーを分解する方法、スプリントを計画する方法、または作業を実行する方法をチームに指示しません。

ただし、チームは、その実行が経営陣の目標と一致していることを確認する必要があります。 チームはストーリーのバックログを所有していますが、バックログを自分たちに割り当てられた機能と一致させる必要があります。

計画

アジャイル計画を拡張するには、チームは分類の各レベルの計画を必要とします。 ただし、計画を繰り返して更新することが重要です。 このプロセスはローリング ウェーブ プランニングと呼ばれます。

この計画は、一定期間の方向性を提供し、定期的な間隔で調整が行われることが予想されます。 たとえば、18 か月の計画は 6 か月ごとに調整できます。

エピック、フィーチャー、ストーリー、タスクといった分類の各レベルの計画方法の例を次に示します。

視覚

ビジョンはエピックを通じて表現され、組織の長期的な方向性を設定します。 エピックは、組織が今後 18 か月以内に完了したいことを定義します。 経営陣が計画を所有し、6 か月ごとに計画を調整します。

ビジョンは全員会議で提示されます。 ビジョンは野心的なものであり、その期間中に多くのことが変更される可能性があるため、ビジョンの約 60% が達成されることを期待してください。

時期

シーズン は機能を通じて説明され、今後 6 か月間の戦略が設定されます。 機能は、組織が顧客のために何を照らしたいかを決定します。 経営陣は季節計画を所有し、全員会議でビジョンと季節計画を提示します。 すべてのチーム計画は、経営陣の季節計画と一致している必要があります。 季節計画の約 80% を達成できる見込みです。

3スプリントプラン

3 スプリント計画 は、チームが次の 3 つのスプリントで完了するストーリーと機能を定義します。 チームが計画を所有し、スプリントごとに計画を調整します。 各チームは、機能チャットを通じて経営陣に計画を提示します (下記を参照)。 計画では、チームの実行が 6 か月の季節計画とどのように一致するかを指定します。 3 つのスプリント計画の約 90% が達成されることが期待されます。

スプリントプラン

スプリント計画は、チームが次のスプリントで完了するストーリーと機能を定義します。 チームはスプリント計画を所有し、完全な透明性を確保するために組織全体に電子メールで送信します。 計画には、チームが過去のスプリントで達成したことと、次のスプリントに向けての焦点が含まれます。 スプリント計画の約 95% を達成することが期待されます。

自律性のライン

この例では、チームが計画の自律性を持っている場所を示すために自律性の線が引かれています。

上で述べたように、経営陣は自治権の範囲を超えて所有権を拡大しません。 経営陣はビジョンとシーズン計画を使用してガイダンスを提供し、チームに 3 つのスプリントとスプリント計画を作成する自主性を与えます。

機能チャット: 自律性と連携が融合する場所

フィーチャー チャット は、各チームが 3 つのスプリント計画を経営陣に発表する、形式ばらないミーティングです。 この会議により、チームの計画が組織の目標と一致していることが確認されます。 また、経営陣がチームが何をしているかについて常に情報を得るのにも役立ちます。 3 つのスプリント計画はスプリントごとに調整されますが、機能チャットは必要に応じて、通常は 1 ～ 3 つのスプリントごとに開催されます。

フィーチャーチャットミーティングでは、各チームに 15 分が割り当てられます。 12 の特集チームがいる場合、これらの会議は約 3 時間続くようにスケジュールできます。 各チームは、次のスライドを含む 3 枚のスライドを用意します。

機能

最初のスライドでは、チームが今後 3 つのスプリントで改善する予定の機能の概要を示します。

債務

次のスライドでは、チームが技術的負債をどのように管理するかについて説明します。 負債とは、経営陣の品質基準を満たさないものです。 エンジニアリング部門のディレクターは、すべてのチームで同じ品質基準を設定します (調整)。 品質バーの例には、エンジニアごとのバグ数、単体テストの合格率、パフォーマンス目標などがあります。

問題と依存関係

最後のスライドにリストされている問題と依存関係には、チームが解決できない問題やエスカレーションが必要な他のチームへの依存関係など、チームの進捗に影響を与えるものがすべて含まれます。

各チームは自分のスライドを経営陣に直接提示します。 チームは、3 スプリント計画が 6 か月の季節計画とどのように連携しているかを示します。 リーダーは明確な質問をし、方向性の変更を提案します。 また、より深い問題を解決するためにフォローアップ会議を要求することもできます。

チームの計画が経営陣の期待と一致しない場合、経営陣は再計画を要求する可能性があります。 このまれなイベントでは、チームはレビューのために 2 番目の機能チャットを再計画し、スケジュールします。

信頼: 連携と自主性を結びつける接着剤

アジャイルを大規模に実践する場合、信頼は双方向の通りです。

• 経営陣はチームが正しいことを行うと信頼しなければなりません。 経営陣はチームが正しいことを行うと信頼しなければなりません。

• チームは高品質のコードを一貫して提供することで信頼を獲得します。 チームが信頼できない場合、経営陣はチームに自主性を与えません。

経営陣はチームが一致する明確な計画を提供し、チームが実行することを信頼する必要があります。 チームは計画を組織と調整し、信頼できる方法で実行する必要があります。

組織がアジャイルをより大きなシナリオに拡張しようとしているとき、重要なのは、チームに自律性を与えながら、組織の目標と確実に一致するようにすることです。 重要な構成要素は、明確に定義された所有権と信頼の文化です。 組織がこの基盤を整備すると、アジャイルが非常にうまく拡張できることがわかるでしょう。

次のステップ

チームの規模を問わず、今日からメリットを実感できる方法はたくさんあります。 拡張性のある実践のいくつかを確認してください。

ポートフォリオ管理とチーム全体の可視化のための Azure DevOps 機能について学びます。

Microsoft は世界最大のアジャイル企業の 1 つです。 詳細については、Microsoft が DevOps 計画を拡張する方法をご覧ください。