ワークフローをカスタマイズする (継承プロセス)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
各作業項目の種類 (WIT) には、作成から完了までの作業の状態を追跡するワークフローが関連付けられています。 ビジネス プロセスとチーム プロセスに合わせて、ほとんどの作業項目の種類にカスタム状態を追加できます。 たとえば、バグの Triaged 状態や、機能やユーザー ストーリーの Design 状態を追加できます。
この記事では、バグ WIT をカスタマイズして、トリアージ状態を含めます。 状態フィールドと理由フィールドは、作業項目フォームのヘッダー領域に表示されます。
DevOps タスクのビルドとリリースのワークフローに関するドキュメントについては、 YAML とクラシック パイプラインを参照してください。
重要
継承プロセス モデルは、それをサポートするように構成されたプロジェクトで使用できます。 古いコレクションを使用している場合は、プロセス モデルの互換性を確認してください。 オンプレミスのコレクションがオンプレミスの XML プロセス モデルを使用するように構成されている場合は、そのプロセス モデルのみを使用して作業追跡エクスペリエンスをカスタマイズできます。 詳細については、「プロジェクト コレクションのプロセス モデルを選択する」を参照してください 。
サポートされているカスタマイズ
継承された状態を非表示にするか、カスタム状態を追加することで、任意の作業項目の種類 (WIT) のワークフローをカスタマイズできます。 継承された状態は、カスタム プロセスを作成するために選択したシステム プロセスによって異なります。 オプションは、 Agile、 Basic、 Scrum、または Capability Maturity Model Integration (CMMI)です。 詳細については、「 ワークフローの状態、遷移、および理由を参照してください。
各 WIT の各既定のワークフローは、2 つから 4 つの状態の間で定義され、次のワークフロー操作を指定します。
- 各状態間の前方および後方遷移。 たとえば、基本プロセスの問題 WIT には、To Do、 Doing、 Done の 3 つの状態が含まれます。
- 各状態遷移の既定の理由
状態の種類
サポートされているカスタマイズ
継承された状態
カスタム状態
ワークフローの状態は、次の規則に準拠している必要があります
- Proposed または In Progress State カテゴリに少なくとも 1 つの状態を定義します。
Note
ワークフロー状態を追加する前に、「 バックログとボードのワークフロー状態について ワークフローの状態を状態カテゴリにマップする方法について説明します。
- 少なくとも 2 つのワークフロー状態を定義します。
- 作業項目の種類ごとに最大 32 個のワークフロー状態を定義します。
サポートされていないワークフローのカスタマイズ
- 継承された状態を表示しない場合は非表示にします (名前、色、またはカテゴリを変更することはできません)。
- Completed状態カテゴリに 1 つの状態のみが存在することを確認します。 このカテゴリにカスタム状態を追加すると、他の状態が削除または非表示になります。
- カスタム状態の名前をそのまま保持します。変更することはできません。
- 状態が切り替わる既定の理由 ( 状態トリアージドに移動 状態が Triaged の状態から移動するなど) を使用します。カスタムの理由を指定することはできません。
- フォームの [状態] フィールドと [理由] フィールドの既定の場所をそのまま使用します。配置を変更することはできません。
- 既定の状態カテゴリ名を使用します。カスタマイズすることはできません。
- 継承された状態を表示しない場合は非表示にします (名前、色、またはカテゴリを変更することはできません)。
- Completed状態カテゴリに 1 つの状態のみが存在することを確認します。システムはこのカテゴリにカスタム状態を追加することを禁止します。
- カスタム状態の名前をそのまま保持します。変更することはできません。
- 作業項目フォームのドロップダウン リストで、状態の自然なシーケンスを受け入れます。順序を変更することはできません。
- 状態が切り替わる既定の理由 ( 状態トリアージドに移動 状態が Triaged の状態から移動するなど) を使用します。カスタムの理由を指定することはできません。
- フォームの [状態] フィールドと [理由] フィールドの既定の場所をそのまま使用します。配置を変更することはできません。
- 任意の状態から別の状態への移行を許可します。切り替えを制限することはできません。
状態ドロップダウン メニューのシーケンス
State ドロップダウン メニューには、各状態カテゴリ内で定義した順序で状態が一覧表示されます。 新しく追加された作業項目の場合、 Proposed カテゴリの最初の状態が既定の状態として割り当てられます。
次の図は、ユーザー ストーリーに対して定義された状態シーケンスとそれに対応するドロップダウン メニューを示しています。
各カテゴリ内で、カスタム状態を上下に移動できます。
ワークフローが変更されたチームへの影響
ボードの構成を更新する
Teams は、次のカスタマイズを行うときにボード構成を更新する必要があります。
- カスタム状態を追加します。
- カスタム状態のカテゴリを変更します。
- カスタムまたは継承された作業項目の種類をバックログ レベルに追加します。 「 バックログとボードをカスタマイズするを参照してください。
タスクボードの構成
Teams は、次のカスタマイズを行うときにボード構成を更新する必要があります。
- タスク WIT に状態を追加し、タスクボードに列を追加します。
- タスクと共にバグを追跡しバグ WIT に状態を追加します。また、タスクボードに列を追加します。
- タスクとバグの両方の作業項目の種類に同じ状態を追加すると、状態が一貫して更新され、追加される列の数が最小限に抑えられます。
前提条件
特定のビジネス要件に合わせて Azure Boards を調整する方法については、「 Azure Boards の構成とカスタマイズについてを参照してください。
組織の要件: Azure DevOps に組織化があることを確認します。
アクセス許可:
- Project コレクション管理者グループのメンバーになります。
- Create process、Delete process Edit process、Delete a field from organization Allow などのコレクション レベルのアクセス許可を持ちます。
- これらのアクセス許可を使用すると、組織内のプロセスとフィールドを変更できます。
プロジェクト プロセス モデルの要件:
- プロジェクトが作成されるプロジェクト コレクションの Inheritance プロセス モデル があることを確認します。
アクセス許可:
- Project コレクション管理者グループのメンバーになります。
- Create process、Delete process Edit process、Delete a field from organization Allow などのコレクション レベルのアクセス許可を持ちます。
- これらのアクセス許可を使用すると、組織内のプロセスとフィールドを変更できます。
組織プロセスの設定を開く
組織にサインインします (
https://dev.azure.com/{yourorganization}
)。[組織の設定] を選択します。
プロセスを選択します。
コレクション (
https://dev.azure.com/{Your_Collection}
) にサインインします。[コレクションの設定] または [管理者設定] を選択します。
プロセスを選択します。
Note
継承されたプロセスをカスタマイズすると、そのプロセスを使用するすべてのプロジェクトにそのカスタマイズが自動的に反映されます。 スムーズな移行を確実に行うために、組織全体でカスタマイズを実装する前にテスト プロセスとプロジェクトを作成することをお勧めします。 詳細については、「 継承されたプロセスの作成と管理を参照してください。
ワークフローの状態を追加する
追加した状態は、作業項目フォームとクエリ エディターに表示される [状態] フィールドのドロップダウン メニューに表示されます。 追加した状態との間の切り替えは、他のすべての状態に作成されます。 既定の理由は、 Triaged 状態に移動 状態トリアージドから 移動など定義されます。
作業項目の種類ページで、変更する作業項目の種類を選択し、Statesを選択し、新しい状態選択。
新しい状態 オプションが無効になっている場合、プロセスを編集するために必要なアクセス許可がありません。 「 継承されたプロセスをカスタマイズするを参照してください。
State の名前を入力し、そのカテゴリと色を選択し、 保存を選択します。 指定した色は、作業項目フォームや、状態フィールドがバックログ、ボード、クエリ結果など、製品全体に表示されます。
Note
In Progress または Resolved 状態カテゴリに追加すると、Activated By/Activated Date および Resolved By/Resolved Date フィールドが、これらのカテゴリのワークフロー状態の変更に応じて更新されます。 詳細については、「 日付/日付でアクティブ化」フィールドと「解決日/日付」フィールドを参照してください。
(省略可能)ドロップダウン メニュー内の状態のシーケンスを変更するには、コンテキスト メニュー アイコンを選択し、[上へ移動]、[下へ移動] の順に選択。
WIT の状態の追加が完了したら、ブラウザーを更新して変更を確認し、カスタマイズした種類の作業項目を開きます。
[トリアージ済み] が選択された状態ドロップダウン メニューを次に示します。
バックログ レベルに関連付けられている WIT に State を追加する場合、ボードを使用する各チームは列の設定を更新する必要があります。 ボードの 管理列を参照してください。
状態を編集する
カスタム状態のカテゴリまたは色を編集できます。 ただし、カスタム状態の名前は変更できません。
... から Edit を選択します。 変更する状態のコンテキスト メニュー。
カテゴリまたは色を変更し、[保存] 選択。
カテゴリを変更した場合、ボードを使用するチームは列の設定を更新する必要があります。 ボードの 管理列を参照してください。
カスタム状態を非表示または削除する
状態を非表示または削除する場合:
WIT の [状態] ドロップダウン メニューに状態が表示されなくなりました
作業項目履歴に変更は発生しません
既存の作業項目は状態値を維持しますが、無効な状態です。 作業項目を変更する場合は、まず状態値を更新する必要があります。
クエリを作成し、一括更新を実行して、影響を受ける作業項目を有効な状態に移動することができます。 状態を作業項目の種類に戻すと、作業項目は有効な状態に戻ります。
継承された状態を非表示または再表示する
チームがワークフロー プロセスで使用していない継承された状態を非表示にすることができます。 ただし、カテゴリごとに少なくとも 1 つの状態が定義されている必要があります。
[…] 非表示にする状態のコンテキスト メニューで、 Hide オプションを選択します。
この例では、バグ WIT の解決済み状態を非表示にします。
Note
ボードで追跡されている WIT の状態を非表示にする場合は、ボードを使用する各チームが列の設定を更新する必要があります。 ボードの 管理列を参照してください。
再表示するには、... コンテキスト メニューをクリックし、[ 非表示 オプションを選択します。
カスタム状態を削除する
[…] 削除する状態のコンテキスト メニューを選択し、 Remove を選択します。 削除できるのはカスタム状態のみです。
[状態の削除]ダイアログボックスで、[削除を選択します。
状態ワークフロー モデルを表示する
State Model Visualization Marketplace 拡張機能をインストールすると、状態ワークフロー モデルを表示できます。 この拡張機能は、[状態ビジュアライザー] というラベルの付いた新しいハブをボードの下に追加します。 そのページでは、作業項目の種類を選択して、ワークフロー状態モデルを表示できます。
Note
State Model Visualization 拡張機能は、Azure Boards または製品チームではサポートされていません。 質問、提案、問題については、 のページをご覧ください。
たとえば、バグ ワークフローをカスタマイズして Triaged 状態を設定し、すべての状態を 1 つの状態から別の状態に切り替えることができます。
ビューの拡大と縮小を行うことができます。 また、状態ノードを移動して、状態モデルをより適切に把握することもできます。