Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
このガイドは、製品マネージャーが Azure Boards を使い始めるのに役立ちます。 チームの構成、作業の計画、ボード、バックログ、イテレーション、デリバリー計画を使用して価値を予測可能に提供するための実用的な推奨事項をまとめています。
Note
チームがかんばんまたはスクラムに特に従っている場合は、「 ボードとかんばんについて 」または 「スクラム」チュートリアルを参照してください。
ほとんどの推奨事項は、Azure DevOps Services (クラウド) と Azure DevOps Server (オンプレミス) の両方に適用されます。 ロールアップ、分析、一部のポートフォリオ計画ツールなどの一部の機能は、クラウドでのみ使用できます。
チームを構成する
自律的に機能する必要がある各デリバリー グループのチームを定義します。 各チームが製品レベルのロードマップにロールアップしながら、個別に計画、追跡、配信できるように、バリュー ストリームに沿ってチームを構成します。
推奨事項:
- 機能またはデリバリー グループごとにチームを作成します (通常は 6 ~ 12 人の開発者)。
- 各チームに独自のエリア パスと反復周期を与えます。
- チームによって追加された作業項目が正しいコンテキストを継承するように、チーム設定を使用して既定のエリア パスとイテレーション パスを割り当てます。
詳細情報:
イテレーションを構成する
製品レベルでイテレーション パス (イテレーション) を定義し、適切なイテレーションにチームを割り当てます。 調整に役立つ、関連するチーム間で一貫した反復周期を維持します。
推奨事項:
- 一緒に配信するチームの一般的な周期を選択します (通常は 1 ~ 4 週間)。
- 今後 3 ~ 6 か月間の計画をサポートするために、少なくとも 6 つのイテレーションを作成します。
- 予測とイテレーションの計画には、イテレーションを一貫して使用します。
- 固定された時間境界なしで段階的に提供できるチームの継続的フロー アプローチを検討します。
- フローベースのチームの場合は、イテレーション容量ではなく、進行中の作業 (WIP) の制限に重点を置く必要があります。
詳細情報:
作業項目の種類の選択
チームが作業を計画して提供する方法に一致する作業項目の種類を選択します。 製品レベルの作業 (機能、エピック) をチーム レベルの作業 (ユーザー ストーリー、問題、PBI) にマップし、必要に応じてチームが作業をタスクに分割できるようにします。
推奨事項:
- Feature を使用して、顧客向けの価値を表します。
- プロセスに応じて、チーム スコープの作業の要件 (ユーザー ストーリー/問題/製品バックログ項目) を使用します。
- イテレーション内に収まる開発者作業には Task を使用します。
- チームがバグを処理する方法 (バックログ項目として、または開発作業として) に同意します。
詳細情報:
製品ロードマップを作成して管理する
製品のロードマップとして機能バックログを使用します。 製品マネージャーは機能を順序付けし、精査する。チームが機能をバックログ項目に分解し、必要に応じてタスクに分解できるようにする。
推奨事項:
- 機能バックログの順序を維持します。
- イテレーション内でチームが完了できるサイズの要件に機能を分割します。
- バックログを定期的に確認して絞り込みます (バックログのクリーンアップ/絞り込み)。
機能バックログ
製品マネージャーは、機能バックログで機能を作成して注文します。 各機能は、出荷可能な機能を表す必要があります。
要件バックログ
Teams は要件バックログに要件を追加し、イテレーション用にサイズを設定し、親フィーチャーにマップします。
推奨事項:
- チームが 1 回のイテレーションで完了できるように、要件のサイズを設定します。
- 受け入れ基準と完了の定義を明確にしてください。
- 親を持たない作業を適切な機能に紐付けします。
詳細情報:
予測とロードマップ
予測ツールとチームのスループットを使用して、機能が出荷されるタイミングを予測します。 予測には、要件に関する見積もり (ストーリー ポイント、作業量、またはサイズ) が必要です。 カウントによる単純な予測を希望する場合は、各要件に見積もり = 1 を割り当てます。
推奨事項:
- 共通の製品ロードマップを提供するチーム間で一貫した見積もりアプローチを確立します。
- 予測を使用して、複数のイテレーションを先にモデル化し、前提条件を検証します。
依存関係の管理
先行タスク/後続リンクを使用してチーム間の依存関係を追跡し、配信プランで依存関係を表示します。
推奨事項:
- タグ依存は、一貫性のあるタグ (たとえば、
dependency) を使用してすばやくクエリを実行できます。 - 先行タスク/後続リンクの種類を使用して、正式な依存関係をキャプチャします。
- 配信プランの依存関係を視覚化するか、クエリベースのレポートを使用してブロック項目をトリアージします。
詳細情報:
- 配信計画を使って依存関係を追跡する
- 作業項目 をリンクする
Note
Marketplace 拡張機能 (作業項目の視覚化など) は、リレーションシップを視覚化するのに役立ちますが、Azure Boards 製品チームが製品でサポートする機能ではありません。
反復作業を行う
イテレーション バックログとタスクボードを使用して、イテレーション作業を計画して完了します。 進行状況グラフが正確なままになるように、毎日状態を更新します。
推奨事項:
- チームとの各イテレーションを計画し、目標を定義します。
- イテレーションに割り当てられた作業項目に、明確な価値提案と受け入れ基準があることを確認します。
- イテレーション全体の残存作業時間と状態を更新します。
- ダッシュボードとグラフを監視して、スループットや阻害要因を追跡します。
詳細情報:
進行状況と配信を確認する
機能ボード、機能バックログのロールアップ列、および配信計画を使用して、チーム全体の進行状況を確認します。
推奨事項:
- 機能バックログにロールアップの進行状況または合計を追加して、完了を一目で監視します。
- 配信ライフサイクルに合わせて Features ボードの列をカスタマイズします (例: Research、On Deck、In Progress、Customer Rollout)。
- デリバリー計画を使用して、チーム間の日付と依存関係を調整します。
詳細情報:
プロセスの改善
継続的な改善を自分の周期の一部にします。 振り返り、速度グラフ、ダッシュボードを使用して改善点を特定し、進行状況を追跡します。
推奨事項:
- 定期的な振り返りを保持し、改善アクションをキャプチャします。
- スループットとサイクル時間を使用して、作業の流れを理解し、改善します。
- 専用ボードまたはバックログで改善作業を追跡します。
詳細情報:
ワークフローを最適化する
WIP を制御して、配信の予測可能性を向上させ、サイクル時間を短縮します。 チームがイテレーションを使用する場合も、継続的フローを使用する場合でも、WIP を制限すると、チームの集中と価値の迅速な提供に役立ちます。
推奨事項:
- オーバーコミットを防ぐために、ボード列に WIP の制限を設定します。
- 作業項目の種類ごとに、開始から出荷までのサイクル時間を監視します。
- 累積フロー図を使用してボトルネックを視覚化します。
- 新しい作業を開始する前に、作業を完了することに集中します。
詳細情報: