チーム内でアジャイル カルチャを促進する
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
チームの成長に合わせてツールが成長する必要があります。 また、アジャイル方法論を採用している企業の場合は、アジャイル ツールで企業のビジネス目標をサポートする必要があります。
ただし、アジャイルを正常にスケーリングするには、組織内のカルチャとツールの両方に取り組む必要があります。
Note
アジャイル初心者の場合 詳細については、アジャイル カルチャとアジャイルを大規模なチームに拡大する方法に関する記事を参照してください。
自律性を実現する
アジャイルを目指す組織は、企業全体を連携させ、チームの自律性をサポートするという 2 つの義務を考慮する必要があります。 チームが効率的であるためには自律性が必要です。 また、企業の効率を上げるには、チームと組織間の連携が必要です。
チームの自律性が不十分な状態で過剰に連携すると、チームが作業を行う上でのイノベーションや機敏性がサポートされません。 独自のプログラムを実行している各チームとの連携が少なすぎると、ビジネス目標を達成するために必要な分析情報と調整が提供されません。
組織全体の連携とチームの自律性が適切なレベルであれば、個人はイノベーションを行うことができ、ビジネス目標を達成するために共同作業を行う動機付けになります。
連携を生み出す
アジャイル ツール セットを拡張する方法を計画する際には、次の領域を検討してください。 これらの領域は、チームの自律性を育成しながら企業の連携を生み出すための鍵です。
領域
連携を生み出す
自律性をサポートする
製品ビジョン
組織では、組織の目標とロードマップを定義します。 目標は、ポートフォリオ バックログに表示されるエピックおよびフィーチャーとして定義できます。
チームは、ロードマップを達成する最善の方法を判断します。 チームは、チーム バックログを使って、目標をユーザー ストーリーまたはプロダクト バックログ項目に分割します。
チームの構成
組織は、ビジネス目標に基づいて、チームの数と規模を決定します。 垂直方向に構造化された機能チームは、自律性と効率性の向上につながります。
チームでは、製品所有者や開発リードなど、いくつかの確立された役割が必要ですが、役割をローテーションする余地もあります。 たとえば、チーム メンバーは、スクラム マスターとしての行動、スプリント デモの開発、スプリントの振り返りの実行、スプリント メールの作成を順番に行うことができます。
開発周期
アジャイル組織は、製品と機能更新プログラムを定期的にリリースする必要があります。 定期的なリリースとスプリントのスケジュールを確立すると、ビジネスのリズムが促進されます。
各スプリント (2 週間から 4 週間の一定期間の時間ボックス化されたイテレーション) には、計画、実行、価値の提供、反映、継続的な改善への取り組みなどが含まれます。
コミュニケーション周期
スプリントは仕事の流れに自然なリズムをもたらしますが、定期的なコミュニケーションも同様です。 組織は、連携を維持するために見たいコミュニケーションの種類に対する期待値と、それらが発生する頻度を設定することで、チームと企業間の連携を自然に生み出します。
このような定期的なコミュニケーションの例として、チーム スプリントのメール、バグ バーの状態、リリース チームの機能の配信状況があります。
チームは、伝える詳細情報と、その伝える内容を誰が作成するかを決定します。 スプリント メールには、以前のスプリントの成果と次のスプリント計画の概要が含まれている場合や、最近完了したフィーチャーのデモが含まれている場合があります。
品質
各組織は、品質を評価し、品質基準に対する期待値を設定するための条件と標準を設定する必要があります。 条件を定義するいくつかの方法は、新機能開発の終了基準、技術的負債を管理するための標準、チームまたは個人のバグ上限を設定することです。
また、バグ ダッシュボードを作成することで、バグの状態と傾向を監視することもできます。
チームは、品質基準を満たす方法を選びます。 新機能に対して、または各スプリントの終了時に、バグ バッシュをステージングできます。 ローテーション ベースでバグ シールドとして機能する個人を選ぶことができます。
リスクの管理、作業の追跡
組織は、各機能単位が状態とリスクをどのように伝達するかを決定します。 組織が必要とする最低限必要な情報に関する "コミュニケーションのコントラクト" を確立します。
また、組織は、リスクを軽減するためのインフラストラクチャを提供します。 組織は、チーム間で共通のリスクを軽減するためにできることは何でもチームのために行います。
チームは、組織によって設定されたニーズを満たすだけでなく、リスクを軽減するために管理および追跡する必要があるその他の詳細を決定します。 使用するのが付箋付きのホワイト ボードでもガント チャート全体でも、詳細を管理します。 たとえば、チームはバックログ項目を追加して、別のチームに対する依存関係を追跡できます。 または、問題または懸案事項の一覧を使ってリスクを追跡することができます。 また、チームは定期的にプロセスとインフラストラクチャの改善に貢献して、組織がリスクを管理し、分析情報を得る能力をサポートします。
チームを構成する
スケーリングする際に考慮すべき最も重要なタスクの 1 つは、チームを構成する方法です。 従来、水平方向のチーム構造では、ソフトウェア アーキテクチャ (ユーザー インターフェイス、サービス指向アーキテクチャ、データ チーム) に従ってチームが分割されます。
ただし、アジャイル プラクティスを導入することで、アーキテクチャ全体にわたる垂直的なチーム構造によってチームの自律性が高まります。 垂直チームは、ソフトウェア アーキテクチャ全体で作業することで、所有する機能に対する期待に沿うことができます。 また、すべてのチームのすべてのアーキテクチャ レベルで作業するために必要な知識も広めます。
組織が提供したい価値ストリームに沿ってチームを構成します。 たとえば、Fabrikam Fiber は、チームを次の 7 つの機能チームに編成します。
各チームは、提供するフィーチャーを計画します。 データの構造化、サービスの設計、Web およびモバイル ユーザー インターフェイスの設計を行う方法の決定に対して自律性を持っています。 組織によって設定され、すべてのチームが寄与する品質基準に準拠して計画します。
スケーリングするようにアジャイル ツールを構成する
組織が成長するにつれて、次の方法でアジャイル ツールをスケーリングできます。
チームとフィルター処理されたバックログ ビューの追加: チームの自律性をサポートするチームを追加し、そのチームに対して、自分たちの働き方をサポートする、構成および管理できるツールを提供します。 これらのツールには、製品バックログ、かんばんボード、スプリント バックログ、タスクボードなどがあります。
また、バックログとポートフォリオ バックログの階層をサポートするようにチームを構成して、ポートフォリオ マネージャーが複数のチームにわたって優先順位と進行状況を確認できるようにすることもできます。
スプリントとリリースの設定: イテレーションを構造化して、スプリントのフラット セット、またはスケジュールされたリリース内に埋め込まれた一連のスプリントをサポートできます。 各チームは、参加する必要があるスプリントとリリースのセットをアクティブにします。
ポートフォリオの管理: チームとバックログの階層を設定し、ポートフォリオ バックログをアクティブ化します。 プロダクト バックログのサブセットにフォーカスを合わせた機能チームは、バックログだけに集中できます。 進行状況と依存関係を追跡するためにバックログを表示および整理するポートフォリオ マネージャーは、機能とエピックのポートフォリオ バックログを管理できます。
他のポートフォリオ バックログ (シナリオやイニシアティブなど) が必要な場合は、それらを追加することもできます。
ダッシュボードの構成: チーム ダッシュボードを使うと、1 つのチーム内または複数チームの進行状況を追跡するグラフを構成できます。 具体的には、作成したクエリに基づいて状態と傾向のグラフを追加できます。
作業のグループ化または分類: 追跡する作業をグループ化する方法はいくつかあります。バックログは、チーム区分の割り当てに基づいて作業項目をフィルター処理します。 また、ポートフォリオ バックログを使うと、フィーチャーとエピックでバックログ項目をグループ化できます。
他のグループに基づいて作業項目を追跡およびレポートしたい場合は、それを行うことができます。 作業項目にタグを追加し、タグに基づいてバックログまたはクエリをフィルター処理できます。 また、サブ区分パスを追加して、よりきめ細かい機能区分を表すこともできます。
フォルダーの追加とチームのお気に入りの使用: チームが成長するにつれて、作業項目クエリ、ビルド定義、ソース コード フォルダーの一覧が拡大しています。 フォルダー、サブフォルダー、チームのお気に入りを使用すると、これらの一覧の多くをより簡単に管理できます。 共有クエリ、ソース コード、ビルド定義についてチームのお気に入りを追加できます。
プロジェクトではなくチームでスケーリングする
多くの場合、組織はソフトウェア開発プロジェクトごとにプロジェクトの追加を検討します。
次の理由から、プロジェクトを追加するのではなく、ツールをスケーリングするチームを追加することをお勧めします。
- 可視性: すべてのチームの進行状況を表示する方が簡単です
- 追跡と監査: 追跡や監査の目的で作業項目を他のオブジェクトをリンクする方が簡単です
- 保守性: セキュリティ グループとプロセス更新のメンテナンスを最小限に抑えます。
詳細については、「プロジェクトとorganizationのスケーリングについて」を参照してください。
関連記事
アジャイル ツールを作成または操作する前に、プロジェクトが必要です。 まだお持ちでない場合は、作成できます。
1 つのチームから 2 つのチームに移行したり、複数のチームを構成したりする準備ができている場合は、チームの追加に関する記事を参照してください。 チーム管理者を追加したり、チーム資産を構成したりするには、「チームを管理しチーム ツールを構成する」を参照してください。
詳細と例については、次の記事をご覧ください。
- スケーリングのプラクティス
- チーム全体の可視性
- チーム 配信計画のレビュー
- エピック、リリース トレーニング、複数バックログをサポートするための Scaled Agile Framework® の実装。