Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
エンタープライズ組織は、多くの理由でアジャイル プラクティスを採用しています。 主な理由は次のとおりです。
- 市場投入までの時間を短縮し、製品の配送を加速する
- 変化する優先順位を管理するために組織の有効性を向上させる
- ソフトウェアの品質と配信の予測可能性を向上させる
- プロジェクトの可視性を向上し、プロジェクトのリスクを軽減する
組織が成長するにつれて、アジャイルを維持し、変化する目標を達成するためにプラクティスをスケーリングしたいと考えています。 これを行うには、次の 2 つの基本原則を検討します。
- 自分、チーム、組織にとって、成功とはどのようなものですか? 最も関心のある点は、オンタイムデリバリーですか? 製品品質ですか? 予測可能性ですか? 顧客満足度ですか?
-
最初の原則に戻り、スクラムの創設者の一人、Ken・シュワーバーが書いたアジャイルマニフェストに列挙されている原則と共有値に戻ります。
- "価値と原則はスケーリングされますが、プラクティスは状況依存です。"
- 「価値を保ち、原則を守り、自分で考えなさい。 アジャイルの中核となる前提は、作業を行う方法を最もよく理解できるのは、それを行っている人々であるということです。"
リズムとフローを作成する
共有周期と一連の定期的なコミュケーションを採用することで、組織全体に一定のアクティビティ フローを作成します。 大規模な組織内でリズムとフローを作成するのに役立つプラクティスは次のとおりです。
- 共有周期: 定期的なスプリントとリリースによって、ビジネスのリズムが確立されます。 すべてのチームが共有周期で作業することは、すべての調整とコラボレーションのアクティビティに役立ちます。
- スプリント通信: 各機能チームは、組織とすべてのチームに機能チームの進捗状況と計画に関する情報を得るために、Microsoft Teams、Slack、メールなどのデジタル チャネルを通じて、以前のスプリント結果と現在のスプリント計画の概要を共有できます。
- スプリントのデモとビデオ: チームが生成する新機能を示す 2 分から 3 分の簡単なビデオを作成します。 スプリント通信またはチーム チャネル内でこのようなビデオへのリンクを共有します。
- 会議を紹介する: 他のチームに通知し、開発中のソフトウェアに関するフィードバックを求めるために、チームは完了した作業を紹介します。 プロジェクトのライフサイクル全体を通じてこれらの会議を定期的に実施し、すべての関係者に公開します。
- 品質メトリック ダッシュボード: 製品の品質に関する分析情報をサポートし、バグ規範の維持を促進するために、品質メトリックを組織と定期的に共有します。 これらのメトリックには、機能チームごとのアクティブなバグ、バグの傾向、テスト カバレッジ、欠陥エスケープ率が含まれる場合があります。
- 調整会議と儀式: チームを定期的に、または必要に応じて調整して、重複する目標、依存関係、リスクに対処する会議を開催します。 スクラムのスクラムやプログラムインクリメント (PI) 計画セッションの実装を検討してみてください。
顧客との対話
製品ライフサイクル全体にわたって顧客を引きつけることは、アジャイルの第 1 の原則です。 チームの各メンバーが、各自の所有する機能セットについて顧客と直接やり取りできるようにします。
-
継続的なフィードバック ループ: お客様のフィードバック メカニズムを組み込む。 これらのループはさまざまな形式を取ることができます:
- 顧客の音声プラットフォーム: 専用ポータル、コミュニティ フォーラム、または統合フィードバック システムを使用して、お客様がフィードバックを簡単に提供したり、アイデアを追加したり、次世代の機能に投票したりできます。
- 製品内フィードバック: 製品内フィードバック ボタンとテレメトリを実装して、製品のエクスペリエンスと特定の機能に関する分析情報を収集します。
- 顧客デモとユーザー テスト: 顧客からのフィードバックを求める定期的なデモをスケジュールし、ユーザビリティ テスト セッションを実施して次世代製品を形成し、顧客が使用するアプリケーションの構築を追跡できるようにします。
- 早期導入者プログラムとベータ プログラム: すべてのチームがある時点で参加したいと考えるプログラムを開発します。 早期導入者は、作業ソフトウェアの初期バージョンにアクセスし、貴重なフィードバックを提供します。 多くの場合、これらのプログラムは、早期導入者リストの 機能フラグ の選択を有効にすることで機能します。
- データドリブンの決定: 製品をインストルメント化して有用なデータを取得し、さまざまな仮説をテストする方法を見つけます。 学習と証拠ベースの意思決定を祝う実験に優しい文化に向かって進みます。
プロジェクトの可視性を向上させる
作業の目標、ビジョン、進捗状況に関する分析情報が多いほど、リスクを軽減し、依存関係を管理しやすくなります。
- チーム構造: 組織の規模に関係なく、6 人から 9 人の小規模なチームを中心に組織を構成すると、効果的にスケーリングできます。 ポートフォリオ管理区分の下にグループ化された垂直で自律的な機能チームを作成します。
- 作業の内訳の構造: 大きな目標、特徴、または要件を小さいものに分割することは、プロジェクト管理の重要な要素です。 作業を同じサイズのタスクに分割することで、チームはより適切な見積もりを行い、リスクと依存関係を特定できます。
- 統合ビューとダッシュボード: オンライン追跡ツールを使用して作業を集約し、チーム全体の知識を得ることができます。 Azure DevOps Analytics サービスを使用して、進行状況、傾向、主要業績評価指標を表示するリアルタイム ダッシュボードを構築します。
- エクスペリエンスと設計のレビュー: 開発が始まる前に、これらの会議を開催して、シナリオと優先順位に関するリーダーシップの教育、フィードバックの収集、期待の設定、機能に関するチーム間の問題の表面化を行います。
従業員の生産性を高める
適切にスケーリングされ、より幸せで魅力的で生産性の高い従業員につながる具体的なアジャイル プラクティスには、次のようなものがあります。
- リーダーシップと心理の安全性を埋め込む: 組織内のチームとリーダーが、可能な限り自己整理および自己管理できるようにします。 チームの自律性により、組織の機敏性とチームの有効性が向上します。 チームが成功し、チーム メンバーがアイデアや懸念事項を安心して表現できる環境を作成するために必要な企業スポンサーシップをチームが持っていることを確認します。
- 毎日のスタンドアップ: スクラム会議 は、スプリントコミットメントを満たす能力を最大限に高めるために毎日何をする必要があるかにチームが集中し続けるのに役立ちます。 組織が成長するにつれて、チーム間の参加が必要に応じて行われるように、これらの会議の時間差の調整を検討する必要があります。
- スクラムのスクラム: さまざまなアジャイル チームの代表者が定期的に会議を行い、完了した作業、次のステップ、チーム内で発生した問題またはブロックを報告します。
- チームのコミュニケーションと知識の共有: 企業ネットワークを通じて、チームのプラクティスとガイダンスを共有するようチームに提供し、奨励します。 一般的なツールには、チーム Wiki、Microsoft Teams、Confluence、または Azure DevOps Wiki が含まれます。
- コラボレーションとコードの品質: チーム間の非公式なコミュニケーションとコラボレーションを促進します。 コード レビュー、設計レビュー、ペア プログラミング、Mob プログラミングなどのプラクティスを制度化します。 これらのプラクティスは、チームのコラボレーションを向上させるだけでなく、個人と全体的な企業の能力を開発するのに役立ちます。
組織のカルチャを改善する
構築するカルチャに参加して、組織の有効性を向上させます。 カルチャの変化は、個人、チーム、組織が 1 つ以上の継続的な改善プラクティスを採用した場合に発生します。 スケーラブルなアジャイル プラクティスには、次のようなものがあります。
振り返り: チームがプロセスとプラクティスを改善する方法を考えるのに役立つ、"何がうまくいったのですか?"、"何を変える必要があるか"、"何をやめるべきか" などの質問をします。 振り返りは、チームがうまく機能し、改善が必要なものを表面化するのに役立ちます。 いつでも、どこでも振り返りを行うことができます。 ただし、定期的に特定の振り返りを制度化すると、継続的な改善プラクティスを確立するのに役立ちます。 次に例を示します。
スプリント振り返りは、 チームが定期的に改善する領域を特定するのに役立ちます。
リリース振り返りは、 組織が次のリリースに向けてコミュニケーションと内部プラクティスと燃料改善を改善する領域を特定するのに役立ちます。
運用レビュー: 通常は毎月開催され、バリュー ストリーム全体の代表者が含まれます。 プロジェクトやその他のイニシアティブのポートフォリオ全体にわたり、客観的で定量的なデータを使用して、チーム間のパフォーマンスに影響を与えるダイナミクスに関する議論を誘発するようにこれらの振り返りを設計します。
振り返りを計画および実施するためのアイデア、ヒント、ツールについては、「Agile Retrospective Resource Wiki (アジャイル振り返りリソース Wiki)」を参照してください。 Marketplace の振り返り拡張機能も参照してください。
改善の追跡ボード: プロセスを改善するための良いアイデアは、いつでも誰からも生じる可能性があります。 これらのアイデアを取り込んで議論し、それらに対して迅速に対処する方法を決定することで、プロセス改善の取り組みがサポートされます。
ホワイトボードは、アイデアをキャプチャするための簡単で視覚的な手段を提供します。 また、改善追跡チームを作成し、電子 ボードで追跡するアイデアをキャプチャ。
共有と学習を制度化する: ベスト プラクティスを共有し、アイデアを伝えることで、組織内のすべてのチームが成長し、改善するのに役立ちます。 学習文化の発展は、これと他の継続的な改善活動をサポートしています。 次のアイデアについて考えてみましょう。
内部 Wiki とナレッジ ベース
実践とギルドのコミュニティ
ハッカソン週間またはイノベーション時間
これらのプラクティスを採用するチームをサポートするための内部 DevOps およびアジャイル コーチング チーム
通常のランチアンド学習セッション
社内会議と技術講演
Culture Game は 、チームがアジャイル プラクティスを採用し、ベスト プラクティスを共有するのに役立つ、アジャイル マネージャー向けの優れたリソースを提供します。
実践コミュニティ: 内部共通規範 (サイト信頼性エンジニア、ソフトウェア アーキテクト、UX デザイナー、データ サイエンティスト、セキュリティ スペシャリストなど) をサポートします。
動くソフトウェア
「動くソフトウェアを、2、3 週間から 2、3 か月というできるだけ短い時間間隔でリリースします。」
「動くソフトウェアこそが進捗の最も重要な尺度です」
- アジャイル宣言
ソフトウェア、機能、複雑さの量が増えるにつれて、消費型ソリューションの作成に役立つプラクティスを採用する必要があります。
- 機能フラグとプログレッシブ配信: 機能フラグを使用して、さまざまな機能へのアクセスを安全に有効または無効にします。 早期導入者が作業に関するフィードバックを受け取るための機能の有効化をサポートします。 カナリア リリースやブルーグリーン デプロイなどのプログレッシブ配信パターンを実装します。
- リリーストレインと継続的デリバリー: 1 つ以上の機能を提供する別の種類のサイクルを作成します。 機能チームは、新しい機能をプッシュする計画済みのスケジュールを理解し、それに応じて計画します。 リリース 列車は、組織に対して確立されたのと同じスプリント 周期に対応することも、異なる周期で発生することもできます。 スプリントを設定して列車をリリースする方法については、「 スケーリングされたアジャイル フレームワーク 」を参照してください。
- 継続的インテグレーションと継続的デプロイ (CI/CD): 手動作業を排除し、テスト、ビルド、デプロイ サイクルを通じてソフトウェアのフローを自動化する自動化されたプロセスを採用します。 単体テスト、統合テスト、自動受け入れテストなどの包括的なテスト戦略を実装します。
- 内部ソースとオープン開発: オープン ソース ソフトウェア コミュニティで開発された価値とエトスを社内の開発チームに提供します。 チーム間でのコード共有、ドキュメント、およびコラボレーション開発プラクティスを促進します。
- クラウドネイティブプラクティス: スケーラビリティと保守容易性を向上させるために、コンテナー化、マイクロサービス アーキテクチャ、およびクラウドネイティブのデプロイ パターンを採用します。
最新のプラクティスと考慮事項
アジャイル プラクティスが進化したら、次のような最新のアプローチを検討してください。
- DevSecOps 統合: セキュリティを別の懸念事項として扱うのではなく、開発ライフサイクル全体でセキュリティ プラクティスを統合します。
- サイト信頼性エンジニアリング (SRE): システムの信頼性を向上させ、運用オーバーヘッドを削減するために、SRE プラクティスを採用します。
- バリュー ストリーム マッピング: アイデアから顧客への配信に対する価値のフローをマップして最適化します。
- OKR (目標と主要な結果): OKR を使用して、単なる出力ではなく、測定可能な結果に関するチームを調整します。
- 設計思考: 顧客のニーズをより深く理解するために、人間中心の設計アプローチを組み込みます。
関連コンテンツ
上記のプラクティスに加えて、アジャイル ツールのスケーリングに関するその他のガイダンスについては、次の記事を参照してください。
業界リソース
スケーリングしないプラクティス
- 大規模なイニシアティブの見積もり: ウォーターフォール プロジェクト方式の一部として、リソースとスケジュールの見積もりが含まれます。 イニシアチブが大きいほど、これらの見積もりによって価値が提供される可能性は低くなります。 プロジェクトの拡大に伴い、リスクと予期しない問題や障害が発生し、多くの見積もりが無効になる可能性があります。
- チーム間メトリックとしてのベロシティ: チームのベロシティ は、スプリント サイクル中に各チームが完了できる作業の量に関する分析情報を得るための有用なメトリックを提供できますが、チームの速度を追加して意味のあるメトリックや有用なメトリックを取得することはできません。 また、多くのチームから得られた速度を使用して、長距離予測を確実に完了することは問題になります。 チームは作業の見積もり方法によって異なる場合があり、それらのバリエーションは時間の経過と同時に増加します。
- トップダウンの規範的なソリューション: 1 つのサイズがすべてに適合することはなく、1 つのソリューションは通常、すべてのチームに適合するわけではありません。 チームの自律性をサポートすることは、必要なフレームワークとサポートを提供しながら、チームが独自のソリューションを見つけることを意味します。
- カーゴカルトアジャイル: その目的を理解せず、自分たちの状況に適応させることなくアジャイルの儀式を形式的に採用するだけでは、多くの場合、効果的でない実装につながります。