Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
チームのプロセスとポートフォリオのニーズに合わせて Azure Boards をカスタマイズします。 この記事では、エリア/イテレーション構造、作業項目の種類 (WIT)、ワークフロー、ボードの動作を構成する管理者に推奨されるタスクと考慮事項について説明します。
必要な構成タスクが既にわかっている場合は、次の記事から始めます。
Note
ここでのほとんどのガイダンスは、クラウドとオンプレミスの両方のデプロイに適用されます。 一部の機能 (ロールアップ、分析、ポートフォリオ計画ツールなど) はクラウド専用です。
主な考慮事項
設定を変更する前に、チームの働き方と、管理者が見る必要がある内容を決定します。 考えてみてください。
- プロジェクトとチームの構造: 必要なチーム、エリア パス階層、ロールアップ ビューの数。
- イテレーション: スプリント周期、リリース グループ化、予測期間。
- 作業項目スキーム: チームが使用する作業項目タイプ (機能, ストーリー/課題/PBI, タスク, エピック)
- レポートのニーズ: どのフィールド、ロールアップ、分析ビューを使用できる必要がありますか?
- カスタマイズ: ユーザー設定フィールド、ワークフロー、および WIT は、ボード、バックログ、およびレポートに影響します。
- アクセス許可とガバナンス: プロセスやエリア/イテレーション ツリー、チーム設定を変更できるのは誰か？
選択内容を文書化して、チームがそれらを一貫して適用できるようにします。
作業項目の種類とポートフォリオ バックログ
プロジェクトの作成時にプロセス (アジャイル、Basic、スクラム、または CMMI) を選択します。 各プロセスは、既定の一連の WIT とポートフォリオ/バックログ レベルを定義します。 組織をサポートするために、カスタムの WIT とポートフォリオ バックログを追加できます。
次の図は、アジャイル プロセスのバックログ作業項目の階層を示しています:
- ユーザー ストーリーとタスクは、作業を追跡するために使用します。
- バグはコードの欠陥を追跡します。
- エピックと機能は、大規模なシナリオで作業をグループ化するために使用します。
各チームは、ユーザー ストーリーまたはタスク作業項目と同じレベルでバグ作業項目を管理する方法を構成できます。 [バグ対応] 設定を使用します。 このような作業項目の種類を使う方法については、 アジャイル プロセスに関する記事を参照してください。
追加の計画レイヤー (目標や主要な結果など) が必要な場合は、カスタム WIT とポートフォリオ バックログを使用します。
推奨される追跡オプション
チームのプラクティスに基づいて、次のいずれかの高度な追跡方法を選択します。
- タスクのみ - 推奨されません。 優先順位付けが制限され、ポートフォリオ計画は提供されません。
- 子タスクの要件 - 時間を見積もって追跡するスクラム チームに適しています。
- 要件のみ - 時間を追跡しないかんばんまたはスクラムバン チームに適しています。
- ポートフォリオ WIT の下にグループ化された要件 - 複数のチームがロールアップとチーム間の予定表を必要とする場合に使用します。
チームに対して選択したアプローチについて説明し、プロセスドキュメントを更新します。
領域、イテレーション、チームのセットアップ
エリア パスを使用して、製品、機能、またはビジネス領域ごとに作業をパーティション分割します。 スプリント、リリース、またはマイルストーンにイテレーション パスを使用します。
推奨事項:
- マネージャーがロールアップを報告する方法を反映するエリア パス階層を作成します。
- 作業項目が正しいコンテキストを継承するように、各チームに既定の領域とイテレーション サブスクリプションを付与します。
- 一緒に提供するチーム間で一貫した反復周期を使用します。
関連コンテンツ:
ボードとバックログにバグを表示する
各チームは、バグが製品バックログに (要件として) 表示されるか、要件に関連付けられているタスクとして追跡されるかを決定します。 スクラムを使用する Teams では、バックログにバグが表示されることがよくあります。アジャイルまたは CMMI を使用するチームは、バックログにバグを表示するかどうかを選択できます。 チームのバグの表示方法を変更するには、チームの設定を更新します。
クエリ、ボード、ロールアップが予測どおりに動作するように、一貫したチーム ポリシーを維持します。
ロールアップビューとポートフォリオビュー
バックログにロールアップ列を追加して、子項目の進行状況バー、カウント、または合計を表示します。 デリバリープランと機能タイムラインを使用して、チーム間のスケジュールと依存関係を表示します。
チーム間計画の場合は、必要に応じて配信プランと機能タイムライン拡張機能を使用します。
ボード、列、ワークフロー
作業項目ワークフローの状態によって、既定のボード列が決まります。 次のようにすることができます。
- カスタム ワークフローの状態を WIT に追加します (すべてのチームに影響します)。
- チーム ボードに列を追加します (そのチームにのみ影響します)。
- 状態と列のマッピングを慎重にマップして、レポートの一貫性を維持します (累積フロー図など)。
関連コンテンツ:
ユーザー設定フィールドとレポート
ユーザー設定フィールドを使用すると、プロジェクト固有のデータをキャプチャできます。 ロールアップとレポートの機能を支援することができ、プロセス全体に適用されます。
推奨事項:
- レポートまたは自動化をサポートするユーザー設定フィールドに制限します。
- 数値カスタムフィールドを使用してロールアップの合計を算出します。一貫したレポート作成のためにはピックリストを使用します。
- 注意: プロセス レベルのフィールドは、コレクション/組織内のプロジェクト間で共有されます。
Note
プロセスごとに最大 1,024 個のフィールドを定義できます。
カスタムの WIT とプロセスの変更
WIT とワークフローの追加または変更は、多くのツールに影響します。
- 新しい要件レベルの WIT が製品バックログに表示され、スプリント バックログに表示される場合があります。
- 新しいタスク レベルの WIT がタスクボードに表示されます。
- Teams では、ボードとマッピングを更新してカスタム WIT を表示する必要があります。
プロセス レベルの変更は、すべてのチームに影響します。 破壊的変更を制限し、事前に通知します。
アクセス許可と、誰が何を変更できるか
プロセス、領域/イテレーション ツリー、およびチーム構成を変更するユーザーを制御します。
- プロセス レベルの変更: プロジェクト コレクション管理者または適切なプロセス権限を持つユーザー。
- プロジェクト レベルの変更 (領域/イテレーション): ノード権限を持つプロジェクト管理者またはユーザー。
- チーム レベルの変更: チーム管理者またはプロジェクト管理者。
関連コンテンツ:
時間追跡とスプリント計画
スプリント計画とキャパシティには、[残存作業時間]、[元の見積]、および [完了作業時間] フィールドを使用します。 課金やその他の目的で時間を追跡する場合は、Marketplace 拡張機能を評価して、より豊富な時間追跡サポートを得ることができます。
関連コンテンツ:
管理者向けの実用的なチェックリスト
- プロセスと WIT 戦略を決定する (継承またはカスタマイズ)。
- デザイン領域とイテレーション階層。
- チームを構成し、既定の領域/イテレーション サブスクリプションを設定します。
- 必要な共有クエリ フォルダーとアクセス許可を作成します。
- 経営陣が必要とするロールアップ列とダッシュボードウィジェットを追加します。
- ワイド スコープの更新プログラムを適用する前に、1 つのチームでパイロットの変更を行います。
- 変更を伝え、プロジェクト Wiki を更新します。