ビッグとアジャイルという単語は、同じ文ではあまり使用されません。 大規模な組織は、動きが遅いという評判を得ています。 ただし、これは変化しています。 多くの大規模なソフトウェア組織がアジャイルへの変革に成功しています。 SAFe、 LeSS、 Nexus などの一般的なフレームワークの有無に関係なく、アジャイルの原則をスケーリングすることを学習しています。
Microsoft では、そのような組織の 1 つがアジャイルを使用して、Azure DevOps ブランドで出荷される製品とサービスを構築しています。 このグループには、3 週間ごとに運用環境にリリースされる 35 の機能チームがあります。
Azure DevOps 内のすべてのチームは、最初から最後まで機能を所有しています。 顧客との関係を管理しています。 独自の製品バックログを管理します。 運用ブランチにコードを書いてコミットします。 3 週間ごとに運用ブランチがデプロイされ、リリースがパブリックになります。 その後、チームはシステムの正常性を監視し、ライブ サイトの問題を修正します。
アジャイルの原則によると、自律的なチームの生産性が向上します。 アジャイル組織は、チームが日々の実行を制御できるようにしたいと考えています。 しかし、アラインメントのない自律性は混乱を引き起します。 独立して作業する数十のチームは、統一された高品質の製品を生み出しません。 連携により、チームは目的を達成し、組織の目標を確実に達成できます。 連携がなければ、最高のパフォーマンスを発揮するチームでも失敗します。
アジャイルをスケーリングするには、組織との連携を確保しながら、チームの自律性を有効にする必要があります。
調整と自律性の微妙なバランスを管理するには、DevOps リーダーは分類を定義し、計画プロセスを定義し、機能チャットを使用する必要があります。
分類を定義する
アジャイル チームと、それが属する大規模なアジャイル組織では、成功するには明確に定義されたバックログが必要です。 組織の目標が明確でない場合、Teams は成功に苦戦します。
明確な目標を設定し、各チームがそれらに貢献する方法を述べるために、組織は分類を定義する必要があります。 明確に定義された分類によって、組織の命名規則が作成されます。
一般的な分類は、エピック、特徴、ストーリー、タスクです。
エピック
エピックは、組織の成功にとって重要なイニシアチブを記述します。 エピックは複数のチームと複数のスプリントを実行する可能性がありますが、終わりはありません。 エピックには明確に定義された目標があります。 達成されると、エピックは閉じられます。 進行中のエピックの数は、組織が集中できるように管理可能であるべきです。 エピックは機能に分類されます。
Features
機能は、エピックの目標を実現するために必要な新しい機能を定義します。 機能はリリースユニットです。顧客にリリースされる内容を表します。 発行されたリリース ノートは、最近完了した機能の一覧に基づいて作成できます。 機能の完了には複数のスプリントを要する場合がありますが、顧客への一貫した価値フローを確保するためにサイズを設定する必要があります。 特徴はストーリーに分類されます。
ストーリー
ストーリーは、チームが機能を作成するために提供する必要がある増分値を定義します。 チームは機能を段階的に分割します。 1 つの完成したストーリーは、顧客に意味のある価値を提供しない場合があります。 ただし、完成したストーリーは、生産品質のソフトウェアを表します。 ストーリーはチームの作業単位です。 チームは、機能を完了するために必要なストーリーを定義します。 ストーリーは、必要に応じてタスクに分割します。
タスク
タスクは、ストーリーを完了するために必要な作業を定義します。
イニシアティブ
この分類は、万能システムではありません。 多くの組織では、 イニシアチブと呼ばれるエピックを上回るレベルを導入しています。
各レベルの名前は、組織に合わせて調整できます。 ただし、上記で定義されている名前 (エピック、特徴、ストーリー) は、業界で広く使用されています。
自律の境界線
分類が設定されたら、組織は 自律性の線を引く必要があります。 自律性の線は、レベルの所有権が管理からチームに渡されるポイントです。 管理は、チームが所有するレベルに干渉しません。
次の例は、以下の機能に示された自律のラインを示しています。 管理部門は、方向性を示すエピックと機能を管理しています。 チームはストーリーとタスクを所有し、実行方法に関する自律性を持っています。
この例では、チームは、ストーリーの分解、スプリントの計画、作業の実行方法をチームに指示しません。
ただし、チームは、実行が管理の目標と一致していることを確認する必要があります。 チームはストーリーのバックログを所有していますが、バックログを割り当てられた機能に合わせる必要があります。
計画
アジャイル計画をスケーリングするには、チームには分類の各レベルの計画が必要です。 ただし、計画を反復処理して更新することが重要です。 このプロセスは、ローリングウェーブ計画と呼ばれます。
この計画は、定期的な間隔で調整を行いながら、一定期間の方向性を示します。 たとえば、18 か月のプランは 6 か月ごとに調整できます。
分類の各レベル (エピック、特徴、ストーリー、タスク) の計画方法の例を次に示します。
Vision
ビジョンはエピックを通じて表現され、組織の長期的な方向性を設定します。 エピックは、組織が今後 18 か月間に完了する必要のあるものを定義します。 管理は計画を所有し、6 か月ごとに調整します。
ビジョンはオールハンズミーティングで提示されます。 ビジョンは野心的であり、その期間に大きな変化を引き出すことができるので、ビジョンの約 60% を達成することを期待してください。
時期
シーズンは機能を通じて記述され、今後 6 か月間の戦略が設定されます。 機能とは、組織が顧客に向けて提供したい内容を決定します。 経営陣は季節計画を所有し、オールハンズミーティングでビジョンと季節計画を提示します。 すべてのチーム 計画は、経営陣の季節計画に合わせる必要があります。 季節計画の約 80% を達成することを期待します。
3 スプリント計画
3 スプリント計画では、チームが次の 3 つのスプリントで終了するストーリーと機能を定義します。 チームは計画を所有し、スプリントごとに調整します。 各チームは、機能チャットを介して管理する計画を提示します (下記参照)。 このプランでは、チームの実行が 6 か月の季節プランとどのように一致するかを指定します。 3 スプリント計画の約 90% を達成することを期待します。
スプリント計画
スプリント計画では、チームが次のスプリントで終了するストーリーと機能を定義します。 チームはスプリント計画を所有し、完全な透明性を確保するために組織全体に電子メールで送信します。 この計画には、チームが過去のスプリントで達成したことと、次のスプリントに対するフォーカスが含まれます。 スプリント計画の約 95% を達成することを期待します。
自律の境界線
この例では、自律性の線を引き、チームが自律性を計画している場所を示します。
前述のように、管理は所有権を自律の境界線の下には適用されません。 マネジメントはビジョンとシーズン計画を利用してガイダンスを提供し、その後、チームに自律的に3スプリント計画や個々のスプリント計画を作成する権限を与えます。
機能チャット: 自律性が一致する場所
機能ミーティングは、各チームが3スプリント計画を管理に提示するカジュアルな会議です。 この会議により、チーム計画が組織の目標と一致することが保証されます。 また、チームが何をしているかについて、経営陣が常に情報を得るのにも役立ちます。 3 スプリントプランはスプリントごとに調整されますが、機能チャットは必要に応じて、通常は 1 対 3 のスプリントごとに開催されます。
機能チャット会議では、各チームに 15 分が割り当てられます。 12 の機能チームを使用して、これらの会議は約 3 時間続くようスケジュールできます。 各チームは、次のスライドを含む 3 スライド のデッキを準備します。
Features
最初のスライドでは、次の 3 つのスプリントでチームが点灯する機能の概要を示します。
負債
次のスライドでは、チームが技術的負債を管理する方法について説明します。 負債は、経営陣の品質バーを満たしていない何かです。 エンジニアリングのディレクターは、すべてのチームで同じ品質バーを設定します (アラインメント)。 品質バーの例としては、エンジニアごとのバグの数、単体テストの合格率、パフォーマンス目標などがあります。
問題と依存関係
最後のスライドに表示される問題と依存関係には、チームが解決できない問題やエスカレーションを必要とする他のチームへの依存関係など、チームの進行状況に影響するものが含まれます。
各チームは、スライドを直接管理に提示します。 チームは、3 スプリント計画が 6 か月の季節計画にどのように適合するかを示します。 リーダーシップは質問を明確にし、方向性の変化を提案します。 また、より深い問題を解決するためにフォローアップ会議を要求することもできます。
チームの計画が経営陣の期待に合わない場合、経営陣は再計画を要求する可能性があります。 このまれなイベントでは、チームは再計画し、2 つ目の機能チャットをスケジュールして確認します。
信頼: アライメントと自律性を結びつける絆
アジャイルを大規模に実践する場合、信頼は双方向の道です。
経営陣は、正しいことを行うためにチームを信頼する必要があります。 経営陣がチームを信頼しない場合、チームは自律性を与えません。
チームは、高品質のコードを一貫して提供することで信頼を得ています。 チームが信頼できない場合、経営陣は彼らに自律性を与えません。
経営陣は、チームが一致して遂行できるような明確な計画を提供し、その後はチームが実行するのを信頼する必要があります。 チームは、計画を組織に合わせ、信頼できる方法で実行する必要があります。
組織がアジャイルを大規模なシナリオにスケーリングしようとしている場合、重要なのは、チームが組織の目標に沿っていることを確認しながら、自律性を提供することです。 重要な構成要素は、明確に定義された所有権と信頼の文化です。 組織がこの基盤を整えると、アジャイルが非常に適切にスケーリングできることがわかります。
次のステップ
あらゆる規模のチームが今すぐ特典を見始める方法は多数あります。 スケールするこれらのプラクティスの一部を確認してください。
ポートフォリオ管理とチーム間の可視性のための Azure DevOps 機能について説明します。
Microsoft は、世界最大のアジャイル企業の 1 つです。 Microsoft が DevOps 計画をスケーリングする方法の詳細について説明します。