スケーリングするアジャイルプラクティスを実装する

[アーティクル]
04/05/2024

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

エンタープライズ組織は、多くの理由でアジャイルプラクティスを採用しています。主な理由は次のとおりです。

市場投入までの時間を短縮し、製品の配信を加速する
変化する優先順位を管理するために組織の有効性を向上させる
ソフトウェアの品質と配信の予測可能性を向上させる
プロジェクトの可視性を向上し、プロジェクトのリスクを軽減する

組織が成長すると、アジャイルを維持し、変化する目標を達成するためにプラクティスをスケーリングする必要があります。これを行うには、次の 2 つの基本原則を検討します。

自分、チーム、組織にとって、成功とはどのようなものですか? 最も関心のある点は、納期どおりの配信ですか? 製品品質ですか? 予測可能性ですか? 顧客満足度ですか?
最初の原則に立ち返り、アジャイルマニフェストに列挙された原則と共有価値に立ち返るスクラム創設者の1人である Ken Schwaber 氏は次のように述べています:
- "価値と原則はスケーリングされますが、プラクティスは状況依存です。"
- "価値を維持し、原則を守り、自分について考えます。アジャイルの中核となる前提は、作業を行う方法を最もよく理解できるのは、それを行っている人々であるということです。"

リズムとフローを作成する

共有周期と一連の定期的なコミュケーションを採用することで、組織全体に一定のアクティビティフローを作成します。大規模な組織内でリズムとフローを作成するのに役立つプラクティスは次のとおりです。

共有周期: 定期的なスプリントとリリースによって、ビジネスのリズムが確立されます。すべてのチームが共有周期で作業することは、すべての調整とコラボレーションのアクティビティに役立ちます。
スプリントメール: 機能チームの進行状況と計画に関する情報を組織とすべてのチームに伝えるために、各機能チームは、以前のスプリント結果と現在のスプリント計画の概要をメールで送信できます。
スプリントデモ: チームが作成した新機能を示す短い (2 から 3 分) ビデオ。このようなビデオへのリンクをスプリントメールに含めることができます。
ショーケース会議: 開発中のソフトウェアについて他のチームに知らせ、フィードバックを求めるために、チームは自分たちが行った作業を紹介します。プロジェクトのライフサイクル全体を通じてこれらの会議を定期的に実施し、すべての関係者に公開します。
バグの概要メール: 製品の品質に関する分析情報をサポートし、バグ規範の維持を促すために、品質メトリックを組織と定期的に共有します。これらのメトリックには、機能チームごとのアクティブなバグ、バグの傾向、エンジニアごとのバグが含まれる場合があります。
調整会議: 定期的な間隔で、または重複する目標、依存関係、リスクに対処するために必要な頻度で、チームを調整する会議を開催します。

顧客との対話

製品ライフサイクル全体にわたって顧客を引きつけることは、アジャイルの第 1 の原則です。チームの各メンバーが、各自の所有する機能セットについて顧客と直接やり取りできるようにします。

継続的なフィードバック: 顧客フィードバックループを構築します。これらのループはさまざまな形式を取ることができます:
- 顧客の意見: 顧客がフィードバックの提供、アイデアの追加、次世代の機能への投票を簡単に行えるようにします。フィードバックの提供は、多くの場合、専用の Web サイトを通じて行われます。
- 製品フィードバック: 製品内フィードバックボタンは、製品エクスペリエンスまたは特定の機能に関するフィードバックを求めるもう 1 つの方法です。
- 顧客デモ: 顧客にフィードバックを求める定期的にスケジュールされたデモは、次世代製品の構想に役立ち、顧客が使用したいアプリケーションの構築を軌道に乗せることができます。
早期導入者プログラム: このようなプログラムは、すべてのチームがどこかの時点で参加する可能性があるという考えで開発する必要があります。早期導入者は、動作するソフトウェアの初期バージョンにアクセスでき、フィードバックを提供できます。多くの場合、これらのプログラムは、早期導入者リストの機能フラグの選択をオンにすることで機能します。
データドリブンの決定: 製品をインストルメント化して有用なデータを取得し、さまざまな仮説をテストする方法を見つけます。学ぶことを称える実験しやすいカルチャへの推進を支援します。

プロジェクトの可視性を向上させる

作業の目標、ビジョン、進行状況に関する分析情報が多いほど、リスクを軽減し、依存関係をうまく管理できるようになります。

チーム構造: 組織の大きさに関係なく、6 から 9 スケールの小さなチームを中心に組織を構造化します。ポートフォリオ管理区分の下にグループ化された垂直で自律的な機能チームを作成します。
作業分解構造: 大きな目標、機能、または要件を小さなものに分割すると、プロジェクト管理が安定した状態に維持されます。作業を同じサイズのタスクに分割することで、チームはより適切な見積もりを行い、リスクと依存関係を特定できます。
統合ビュー: オンライン追跡ツールを使用して作業を集計し、チーム全体で知識を得ることができます。進行状況と傾向を表示するダッシュボードを作成します。
エクスペリエンスレビュー: これらの会議は、機能の開発開始前に開催され、シナリオと優先順位に関するリーダーシップの教育、フィードバックの収集、期待値の設定、機能に関するチーム間の問題の表面化に使用されます。

従業員の生産性を高める

適切にスケーリングされ、満足度が高く熱心で生産的な従業員につながる特定のアジャイルプラクティスには、次のようなものがあります。

組み込みリーダーシップ: 組織内のチームとリーダーが、可能な限り自己組織化および自己管理できるようにします。チームの自律性により、組織の機敏性とチームの有効性が向上します。チームが成功するために必要な企業スポンサーシップがあることを確認します。
毎日のスタンドアップ: スクラム会議は、スプリントのコミットメントを満たす能力を最大限に高めるために、チームが毎日行う必要があることにフォーカスを合わせ続けるのに役立ちます。組織が成長するにつれて、チーム間の参加が必要に応じて行われるように、これらの会議の時間差の調整を検討する必要があります。
スクラムのスクラム: さまざまなアジャイルチームのメンバーの毎日のスタンドアップで毎日顔を合わせ、完了した作業、次のステップ、代表的なチーム内で発生した問題やブロックを報告します。
チームコミュニケーション: チームと他のチームが企業ネットワークを介してアクセスできるプラクティスとガイダンスをチームに提供し、共有を奨励します。この目的で使用される一般的なツールには、チーム Wiki、OneNotes、Markdown サイトなどがあります。
コラボレーション: チーム内の非公式なチーム間のコミュニケーションとコラボレーションを促します。コードレビュー、設計レビュー、仕様レビューなどのプラクティスを制度化すると、チームのコラボレーションが増えるだけでなく、個人や企業全体の能力を高めるのに役立ちます。

組織のカルチャを改善する

構築するカルチャに参加して、組織の有効性を向上させます。カルチャの変化は、個人、チーム、組織が 1 つ以上の継続的な改善プラクティスを採用した場合に発生します。スケーラブルなアジャイルプラクティスには、次のようなものがあります。

振り返り: "何がうまくいったか"、"何を別の方法で行うべきか"、"何をやめるべきか" などの質問をすることで、チームがプロセスとプラクティスを改善する方法について考えるのに役立ちます。振り返りは、チームがうまく機能しているものと改善が必要なものを表面化するのに役立ちます。振り返りはいつでもどこでも行うことができます。ただし、定期的な周期での特定の振り返りを制度化すると、継続的な改善プラクティスを制度化するのに役立ちます。次に例を示します。
- スプリントの振り返りは、チームが定期的に改善する領域を特定するのに役立ちます。
- リリースの振り返りは、組織がコミュニケーションと内部プラクティスを改善し、次のリリースに向けて改善を促進する領域を特定するのに役立ちます。
- 運用レビュー: 通常は毎月開催され、バリューストリーム全体の代表者が含まれます。プロジェクトやその他のイニシアティブのポートフォリオ全体にわたり、客観的で定量的なデータを使用して、チーム間のパフォーマンスに影響を与えるダイナミクスに関する議論を誘発するようにこれらの振り返りを設計します。
  
  振り返りを計画および実施するためのアイデア、ヒント、ツールについては、「Agile Retrospective Resource Wiki (アジャイル振り返りリソース Wiki)」を参照してください。 Marketplace の振り返り拡張機能も参照してください。
改善追跡ボード: プロセスを改善するための優れたアイデアは、いつでもだれからでも生じる可能性があります。これらのアイデアを取り込んで、迅速に対処する方法について話し合い、決定することは、プロセス改善の取り組みをサポートするための鍵です。

ホワイトボードは、アイデアを取り込むための簡単で視覚的な手段を提供します。また、改善追跡チームを作成し、電子かんばんボードで追跡するアイデアを取り込むこともできます。
共有の制度化: ベストプラクティスの共有とアイデアの伝達は、組織内のすべてのチームの成長と向上に役立ちます。学習カルチャの発展は、このような継続的な改善活動をサポートするための鍵です。検討すべきいくつかのアイデア:
- 社内 Wiki
- 社内配布リスト
- ハッカソンウィークまたは 10% のハック時間
- アジャイルプラクティスを採用するチームをサポートする内部アジャイルサポートチーム
  
  『The Culture Game (カルチャゲーム)』は、チームがアジャイルを採用し、ベストプラクティスを共有するのに役立つ、アジャイルマネージャー向けの優れたリソースを提供します。
プラクティスのコミュニティ: 内部共通規範 (DBA、SW アーキテクト、UX 設計など) をサポートします

動くソフトウェア

「動くソフトウェアを、2、3 週間から 2、3 か月というできるだけ短い時間間隔でリリースします。」
「動くソフトウェアこそが進捗の最も重要な尺度です」
- アジャイル宣言

ソフトウェアと機能の量が増え、複雑さが増すにつれて、コンシューマブルソリューションを生成するのに役立つプラクティスを採用する必要があります。

機能フラグ: 機能フラグを使用して、さまざまな機能へのアクセスを有効または無効にします。早期導入者に対して機能を有効にして、作業に関するフィードバックを得るためのサポートを提供します。
リリーストレーニング: 1 つ以上の機能を提供する別の種類の周期を指定します。機能チームは、新しい機能をプッシュする計画済みのスケジュールを理解し、正しく計画します。リリーストレーニングは、組織に確立されているのと同じスプリント周期に対応することも、異なる周期で行うこともできます。スプリントとリリーストレーニングを設定する方法については、Scaled Agile Framework に関する記事を参照してください。
継続的インテグレーション: 手動作業を排除し、代わりにテスト、ビルド、デプロイサイクルを通じてソフトウェアのフローを自動化するプロセスを採用します。
内部オープンソース: オープンソースソフトウェアコミュニティで育成された価値と精神を、社内の開発チームに取り込みます。

上記のプラクティスに加えて、アジャイルツールのスケーリングに関するその他のガイダンスについては、以下の記事を参照してください。

業界リソース

スケーリングしないプラクティス

大規模なイニシアティブの見積もり: ウォーターフォールプロジェクト方式の一部として、リソースとスケジュールの見積もりが含まれます。イニシアティブが大きいほど、これらの見積もりに価値がある可能性は低くなります。プロジェクトの拡大に伴い、リスクと予期しない問題や障害が発生し、多くの見積もりが無効になる可能性があります。
ベロシティ: チームのベロシティは、スプリントサイクル中に各チームが完了できる作業量に関する分析情報を得るための有用なメトリックを提供できますが、チームのベロシティを追加して、意味のある、または有用なメトリックを取得することはできません。また、多くのチームから得られたベロシティを使用して、長期予測を高い信頼性で完了することは困難です。チームは異なる方法で仕事を見積もり、それらのバリエーションは時間の経過と共に増加します。
トップダウンの規範的なソリューション: 1 つのサイズがすべてに適合することはなく、1 つのソリューションは通常、すべてのチームに適合するわけではありません。チームの自律性をサポートすることは、チームが独自のソリューションを見つけられるようにすることを意味します。

スケーリングするアジャイル プラクティスを実装する