Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022
作業項目ワークフローをカスタマイズして、独自のビジネス プロセスを反映することで、チームの生産性を最適化します。 各作業項目の種類 (WIT) には、作成から完了までの作業状態を追跡する定義済みのワークフローが含まれています。 カスタム状態を使用すると、Azure DevOps ワークフローを、確立されたチーム プラクティス、規制要件、組織標準に合わせて調整できます。
一般的なワークフローのカスタマイズ:
- バグ管理: トリアージド、調査中、顧客検証済みなどの状態を追加する
- 機能開発: 設計レビュー、開発、コード レビュー、または利害関係者の承認を含める
- コンプライアンス ワークフロー: セキュリティ レビュー、 法的レビュー、または 監査の完了 状態を追加する
この記事では、バグ作業項目の種類をカスタマイズして トリアージ状態 を含める方法について説明します。 状態フィールドと理由フィールドは、作業項目フォーム ヘッダーに目立つように表示され、簡単にアクセスでき、状態が明確に表示されます。
ヒント
DevOps ワークフローのビルドとリリースについては、 YAML とクラシック パイプラインに関するページを参照してください。
重要
継承プロセス モデルは、モデルの種類をサポートするように構成されたプロジェクトで使用できます。 古いコレクションを使用している場合は、プロセス モデルの互換性を確認してください。 オンプレミスのコレクションがオンプレミスの XML プロセス モデルを使用するように構成されている場合は、そのプロセス モデルのみを使用して作業追跡エクスペリエンスをカスタマイズできます。 詳細については、「 組織レベルのプロセスのカスタマイズ」を参照してください。
サポートされるカスタマイズ
継承された状態を非表示にするか、カスタム状態を追加することで、任意の作業項目の種類 (WIT) のワークフローをカスタマイズできます。 継承された状態は、カスタム プロセス (アジャイル、Basic、スクラム、または機能成熟度モデル統合 (CMMI) の作成に使用されるシステム プロセスによって異なります。 詳細については、「ワークフローの状態、遷移、および理由」を参照してください。
各 WIT の既定のワークフローでは、2 つから 4 つの状態を定義し、次のワークフロー操作を指定します。
- 各状態間の前方および後方遷移。 たとえば、基本的なプロセス の問題 WIT には、 To Do、 Doing、 Done の 3 つの状態が含まれています。
- 各状態遷移の既定の理由。
継承されたワークフローとカスタム ワークフローは、次の規則に準拠している必要があります。
- 少なくとも 2 つのワークフロー状態を定義します。
- 提案中または進行中の状態カテゴリに、少なくとも1つの状態を定義してください。
- 作業項目の種類ごとに最大 32 個のワークフロー状態を定義します。
Note
カスタム ワークフロー状態を追加する前に、「 バックログとボードのワークフロー状態について 」を参照して、ワークフローの状態がカテゴリにどのようにマップされるかを確認してください。
継承されたワークフロー状態とカスタム ワークフローの状態のカスタマイズについては、次のリソースを参照してください。
継承された状態
カスタム状態
制限事項
- 継承された状態の名前、色、またはカテゴリを変更することはできませんが、表示したくない場合は非表示にできます。
- 定義したカスタム状態の名前は変更できません。
- 既定の状態カテゴリ名を変更またはカスタマイズすることはできません。
- 完了状態カテゴリに存在できる状態は 1 つだけです。 このカテゴリにカスタム状態を追加すると、そのカテゴリの他の状態が削除または非表示になります。
- 状態遷移のカスタム 理由を 指定することはできません。 既定の理由 ( [状態トリアージ済みに移動] や [状態トリアージ解除 ] など) を使用します。
- 作業項目フォームの [状態 ] フィールドと [ 理由 ] フィールドの配置を変更することはできません。
状態の構造と挙動を理解する
状態カテゴリとワークフローの進行状況
Azure DevOps は、ワークフローの動作を定義する 4 つの機能カテゴリに状態を整理します。
| カテゴリ | 目的 | 例示 | 行動 |
|---|---|---|---|
| 提案済み | 作業の初期段階、計画 | 新規、 承認済み、 トリアージ済み | 新しい作業項目の開始点 |
| 処理中 | アクティブな作業フェーズ | アクティブ、コミット済み、調査中 | 作業が進行中であることを示します |
| 解決 | 検証待機中の完了した作業 | 解決済み、修正済み、テストの準備完了 | 作業が完了し、検証待ち |
| 完了 | 完了した作業の最終状態 | 完了、終了、削除 | ターミナルの状態、作業が完全に完了 |
[状態] ドロップダウン メニューのシーケンス
状態は、各カテゴリ内で定義した順序に従ってドロップダウン メニューに表示されます。 提案済みカテゴリの最初の状態は、自動的に新しい作業項目の既定値になります。
状態の順序付けの原則:
- 論理的な進行: 通常、チームが従う順序で状態を配置する
- 使用頻度: 一般的に使用される状態をリストの上位に配置する
- 視覚的な明確さ: 状態の順序がユーザー エクスペリエンスに与える影響を考慮する
次の例は、状態シーケンスの構成がユーザー インターフェイスに与える影響を示しています。
状態管理機能:
- [上へ移動] または [下へ移動] を使用して、カテゴリ内のカスタム状態を並べ替える
- システム (継承) 状態を並べ替えることができない
- 変更は、プロセス テンプレートを使用してすべてのチームに影響します
ワークフロー変更の影響を管理する
ワークフローの変更がチームにどのように影響するかを理解することは、実装を計画し、更新プログラムを効果的に調整するのに役立ちます。
ボード構成の要件
これらのカスタマイズを行う場合、Teams はボード構成を更新する必要があります。
ボードの更新を必要とする状態関連の変更
| 変更の種類 | 影響 | 必要なアクション |
|---|---|---|
| カスタム状態を追加する | ボードに新しい列が必要です | 列のマッピングを構成する |
| 状態カテゴリの変更 | 状態の動作の変更 | 列の確認と調整 |
| 継承された状態を非表示にする | 列が無効になる可能性があります | 列の再マップ |
| バックログに WIT を追加する | ボードに新しい作業項目が表示される | ボードの設定を構成する |
詳細なガイダンスについては、「 バックログとボードをカスタマイズする」を参照してください。
スプリントとタスクボードに関する考慮事項
タスク作業項目の変更:
- タスク WIT に状態を追加すると、新しいタスクボード列が作成されます
- スプリント計画と毎日のスタンドアップ ワークフローに影響を与える変更
- チーム速度の追跡とレポートへの影響を検討する
バグ追跡の統合:
- タスクでバグを追跡すると、バグ WIT 状態の変更がタスクボードに影響を与える
- バグとタスクの状態を調整すると、ボードの複雑さが最小限に抑えられます
- 一貫性のある状態が作業項目間のレポート品質を向上させる
変更管理のベスト プラクティス
実装前の計画:
- 利害関係者の配置: 影響を受けるチームとのワークフローの変更を確認する
- 変更評価: プロセスを使用してすべてのチームとプロジェクトを特定する
- タイムラインの調整: アクティビティの少ない期間中の変更を計画する
- コミュニケーション戦略: 明確な変更通知を作成する
実装後のサポート:
- ドキュメントの更新: チーム プロセスのドキュメントを修正する
- トレーニング配信: チームが新しいワークフロー オプションを理解できるようにする
- 監視とフィードバック: 導入を追跡し、改善の提案を収集する
- 問題の解決策: 構成の問題に迅速に対処する
ロールバックの準備:
- 変更前の現在の状態を文書化する
- 必要なロールバックに関するコミュニケーションを計画する
- 以前の構成のバックアップ ドキュメントを保持する
前提条件
特定のビジネス要件に合わせて Azure Boards を調整する方法のガイダンスについては、「 Azure Boards の構成とカスタマイズ」を参照してください。
| カテゴリ | 要件 |
|---|---|
| アクセス許可 | - プロセスを作成、削除、または編集するには、プロジェクト コレクション管理者のメンバー グループまたは特定のコレクション レベルのアクセス許可 プロセスの作成、プロセスの削除、プロセスの編集、または [を許可] に設定されている 組織からフィールドを削除します。 詳細については、「 継承されたプロセスをカスタマイズする」を参照してください。 - ボードを更新するには、チーム管理者、または プロジェクト管理者 グループのメンバー。 |
| アクセス | - Basic または下位のアクセス権を持っている場合でも、他のユーザーがアクセス許可を付与した場合でもプロセスを変更できます。 - 既存の作業項目の種類を更新および変更するには:プロジェクトのメンバー。 |
| プロジェクトプロセスモデル | - プロジェクトを含むプロジェクト コレクションの継承プロセス モデルが必要です。 - Azure DevOps Services にデータを移行するには、 Team Foundation Server Database Import Service を使用します。 |
| 知識 | - カスタマイズ モデルとプロセス モデルに関する知識。 |
組織プロセスの設定を開く
組織にサインインします (
https://dev.azure.com/{yourorganization})。
[組織の設定] を選択します。
プロセスを選択します。
コレクション (
https://dev.azure.com/{Your_Collection}) にサインインします。[コレクションの設定] または [管理者設定] を選択します。
プロセスを選択します。
Note
継承されたプロセスをカスタマイズすると、そのプロセスを使用するすべてのプロジェクトにカスタマイズが自動的に反映されます。 スムーズな移行を確実にするために、組織全体でカスタマイズを実装する前に、カスタマイズをテストするテスト プロセスとプロジェクトを作成することをお勧めします。 詳細については、「継承されたプロセスの作成と管理」を参照してください。
ワークフローの状態を追加する
チーム固有のプロセス ステージを反映したカスタム状態で作業項目の種類を拡張します。 状態を追加すると、より適切な追跡、より明確な状態の視覚化、ビジネス要件とのワークフローの調整の向上が可能になります。
新しい州の戦略的計画
状態を追加する前に、チームのワークフローのニーズを考慮してください。
既存のギャップを評価する:
- 現在の状態で表されないプロセスのステージを特定する
- 新しい状態を追加する代わりに既存の状態を再利用できるかどうかを判断する
- 新しい状態と確立されたチーム プラクティスの統合方法を検討する
状態の特性を計画する:
- 名前付け規則: チームが理解する明確なアクション指向の名前を使用する
- カテゴリの配置: 状態のワークフローの目的に一致するカテゴリを選択する
- 視覚的な差別化: ワークフローの明瞭さを高める色を選択する
状態の統合と自動遷移
状態を追加する場合:
- ドロップダウンの可用性: 状態は、作業項目フォームとクエリ エディター全体の [状態 ] フィールドに表示されます
- 自動切り替え: 既存のすべての状態との双方向遷移が自動的に作成されます
- 既定の理由: システムによって生成された遷移の理由 (状態 [StateName] に移動、状態 [StateName] から移動)
カスタム ワークフローの状態を追加する
状態の構成に移動します。 [作業項目の種類] ページで、変更する作業項目の種類を選択し、[ 状態] を選択して、[ 新しい状態] を選択します。
ヒント
[新しい状態] オプションが無効になっている場合、プロセスを編集するために必要なアクセス許可が付与されていません。 「継承されたプロセスのカスタマイズ」を参照してください。
状態プロパティを構成する: 状態の詳細を慎重に入力します。
- 名前: わかりやすい名前を使用します (例: "コード レビュー"、"テスト"、"顧客承認")
- カテゴリ: 適切なワークフロー ステージを選択します (詳細な説明については 、状態カテゴリ を参照してください)
- 色: チーム ワークフローの視覚化を強化する色を選択する
重要
[c0>進行中] または [
解決済み ] カテゴリに状態を追加すると、作業項目がこれらのカテゴリに移行または移出する際に、アクティベートした人 および アクティベート日 、解決した人 および 解決日 フィールドが自動的に更新されます。 詳細については、「[アクティブ化した人]、[アクティブ化された日]、[解決者]、[解決日] フィールド」を参照してください。構成を保存する: [ 保存] を 選択して状態を作成します。 指定した色は、作業項目フォーム、バックログ、ボード、クエリ結果など、プラットフォーム全体に表示されます。
状態シーケンスを最適化 する (省略可能): ドロップダウン メニューのユーザー エクスペリエンスを向上させるには、状態の順序を調整します。
-
コンテキスト メニュー アイコンを選択する - [ 上へ移動] または [下へ移動 ] を選択して、状態をカテゴリ内に適切に配置します
-
実装を確認する: 新しい状態を徹底的にテストします。
- ブラウザーを更新して変更が読み込まれるようにする
- カスタマイズした種類の作業項目を開く
- ドロップダウン メニューに状態が正しい色と位置で表示されたことを確認する
トリアージ状態が選択された 状態 ドロップダウンメニューの例:
実装後の検証
- テスト状態の遷移: 作業項目が新しい状態との間で想定どおりに移動できることを確認する
- レポートの効果を確認する: 新しい状態でクエリ、ダッシュボード、レポートが正しく機能することを確認する
- 導入の監視: チームが新しい状態を使用する方法を追跡し、最適化のためにフィードバックを収集する
Note
ボードを使用しているチームは、バックログ レベルに関連付けられている作業項目の種類に状態を追加するときに、列の設定を更新する必要があります。 包括的な変更管理のガイダンスについては、「 効果管理」セクション を参照してください。
状態を編集する
カスタム ワークフローの状態を微調整して、チームの生産性を最適化し、明確な視覚的な組織を維持します。 既存の状態を編集すると、確立されたプロセスを中断することなくワークフローを改善するためのコスト効率の高い方法が提供されます。
編集するタイミングと新しい状態を作成する場合
次の場合に既存の状態を編集します。
- 現在の状態名は、ワークフロー ステージを正確に表します
- プロセスでの状態の動作を調整する必要があります (カテゴリの変更)
- 視覚的表現をわかりやすくするために更新する必要がある
- 既存の作業項目を中断せずに状態機能を再調整したい
次の場合に新しい状態を作成します。
- 既存の状態名がワークフローの用語と一致しない
- プロセスの粒度を高くする必要がある
- 現在の状態は、必要なすべてのワークフロー ステージをカバーしているわけではありません
編集可能なプロパティ
| プロパティ | Description | 影響 |
|---|---|---|
| 状態カテゴリ | ワークフロー内の状態の動作と位置を決定します | ボード、クエリ、およびレポートでの状態の機能を変更する |
| ステートカラー | プラットフォーム全体のビジュアル識別子 | すべての Azure DevOps インターフェイスの外観を更新します |
編集できないプロパティ
- 状態名: 作成後は永続的です (初期作成時に状態の目的を考慮してください)
- システム状態: 既定の Azure DevOps 状態は変更できません。非表示のみ
カスタム状態を編集する
状態に移動します。 [作業項目の種類] ページで作業項目の種類を選択し、[ 状態] を選択します。
編集ダイアログを開く: … から 編集 を選択します。 ターゲット状態のコンテキスト メニュー。
プロパティを構成します。
- カテゴリ: 適切なワークフロー ステージを選択します (詳細については 、状態カテゴリ を参照してください)
- 色: チームのビジュアル規則に合った色を選択する
変更を適用する: [保存] を 選択して変更を実装します。
変更をテストします。
- 変更された種類の作業項目を開く
- 正しい色とカテゴリの動作で状態が表示されていることを確認する
- 状態遷移が期待どおりに動作することを確認する
変更効果の管理
必要な即時アクション
カテゴリの変更には次のものが必要です。
- 影響を受けるすべてのチームのボード列の構成を更新する
- チーム メンバーと利害関係者に変更を伝える
- 自動プロセスが正しく機能することを確認する
色の変更には次のものが必要です。
- カラー コーディングを参照するチーム ドキュメントを更新する
- 新しいビジュアル表現についてユーザーに通知する
- 新しい色でダッシュボードとレポートの明確さを確認する
その他の考慮事項
- カテゴリの変更: ロールバックが必要な場合は、以前のボード構成の復元が必要になる場合があります
- 色の変更:ワークフロー効果なしで簡単に元に戻すことができます
- ドキュメント: 古い色またはカテゴリを参照するチーム ドキュメントを更新する
ヒント
最適な結果を得るには、前述の包括的な 変更管理のベスト プラクティス に従ってください。
カスタム状態の非表示または削除
状態を非表示または削除する前に、既存の作業項目とチーム ワークフローへの影響を理解してください。
状態の非表示または削除の結果
状態を非表示にする、または削除する場合:
- 状態ドロップダウン: 作業項目の種類の [状態] ドロップダウン メニューに状態が表示されなくなりました
- 作業項目履歴: 既存の作業項目履歴レコードに対する変更は行われません
- 既存の作業項目: 非表示/削除状態の作業項目は無効になりますが、その状態の値は保持されます
- 今後の編集: 影響を受ける作業項目に変更を加える前に、状態値を更新する必要があります
影響を受ける作業項目を処理する
状態を非表示または削除する前に、
- 影響を受ける項目を特定する: 非表示または削除する予定の現在の状態にあるすべての作業項目を検索するクエリを作成する
- プランの切り替え: これらの作業項目を移行する有効な状態を決定する
- 一括更新: 一括編集 を使用して、影響を受けるすべての作業項目を有効な状態に移動する
- 変更の確認: すべての作業項目が正常に更新されたことを確認する
回復オプション
- 復元状態: 非表示/削除された状態を作業項目の種類に戻すと、影響を受ける作業項目は自動的に有効な状態に戻ります。
- チームの調整: 作業項目の更新中の混乱を防ぐために、状態の変更についてチームに通知する
継承された状態の非表示または再表示
プロセスに合わない継承された状態を非表示にして、チームのワークフローを効率化します。 この方法では、システム機能を維持しながら、ドロップダウン メニューから未使用の状態を削除します。
継承された状態を非表示にするタイミング
次の場合、継承された状態を非表示にします。
- チームのワークフローで特定の既定の状態が使用されていない
- ドロップダウン メニューで状態の選択を簡略化する
- 特定の状態によって混乱が生じたり、プロセスの用語と一致しない
重要な制約
状態を非表示にする前に、次のことを確認します。
- カテゴリカバレッジを確保: カテゴリごとに少なくとも1つの状態を確保すること (提案済み、進行中、解決済み、完了済み)
- 既存の作業項目を確認する: 現在非表示にする予定の状態を使用している作業項目があるかどうかを確認します
- チームとの調整: 影響を受けるボードを使用して、今後の変更についてチームに通知する
継承された状態を非表示にする
[…] (非表示にする状態のコンテキスト メニュー) を開き、[非表示] オプションを選択します。
この例では、バグ WIT の "解決済み" 状態を非表示にします。
重要
ボードで追跡されている作業項目の種類の状態を非表示にする場合、チームは列の設定を更新する必要があります。 ガイダンスについては 、エフェクト管理 を参照してください。
作業項目フォームのドロップダウン メニューに非表示の状態が表示されなくなったことを確認して、変更を確認します。
継承された状態を再表示する
非表示の状態を復元する必要がある場合:
- […] 非表示状態のコンテキスト メニューを表示し、[ 再表示 ] オプションを選択します。
- ドロップダウン メニューに状態が再び表示され、使用可能であることを確認します。
- 復元された状態を含めるために必要に応じて、チーム ボードの構成を更新します。
カスタム状態を削除する
[…] (削除する状態のコンテキスト メニュー) を開き、[削除] を選択します。 削除できるのはカスタム状態のみです。
[状態の削除] ダイアログボックスで、[削除] を選択します。
状態ワークフロー モデルを表示する
State Model Visualization Marketplace 拡張機能を使用して、カスタム ワークフローの状態と遷移を視覚化します。 この拡張機能は、作業項目の種類のワークフローをグラフィカルに表現します。
拡張機能をインストールしてアクセスする
- Visual Studio Marketplace から State Model Visualization 拡張機能をインストールします。
- Azure DevOps プロジェクトで Boards>State Visualizer に移動します。
- ワークフロー状態モデルを表示する作業項目の種類を選択します。
Features
状態ビジュアライザーには、次の機能があります。
- ビジュアル ワークフロー図: すべての状態とその許可された遷移を表示する
- 対話型ナビゲーション: ダイアグラムの拡大、縮小、および移動
- カスタマイズ可能なレイアウト: 状態ノードをドラッグして再配置し、最適な表示を実現
- 状態遷移の詳細: 考えられるすべての状態遷移を一目で確認する
たとえば、バグ ワークフローをカスタマイズして トリアージド 状態を含める場合、ビジュアライザーは、すべての状態を相互に切り替える方法を示し、ワークフロー 設計の概要を明確に示します。
Note
Azure Boards と製品チームは、State Model Visualization 拡張機能をサポートしていません。 質問、提案、または問題については、 拡張機能ページを参照してください。