ワークフローをカスタマイズする (継承プロセス)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
各作業項目の種類は、作成から完了までの作業の状態の追跡をサポートするワークフローに関連付けられます。 ビジネス プロセスとチーム プロセスをサポートするために、ほとんどの作業項目の種類 (WIT) にカスタム状態を追加できます。 たとえば、バグに対してトリアージド状態を挿入したり、機能やユーザー ストーリーのデザイン状態を挿入したりできます。
ここでは、バグ WIT は、トリアージ状態をサポートするようにカスタマイズされています。 状態と理由のフィールドは作業項目フォームのヘッダー領域に表示されます。
この記事では、サポートされているワークフローのカスタマイズ オプションと、ワークフローをカスタマイズする方法について説明します。 特に次の内容を学習します。
- サポートされているワークフローカスタマイズシナリオ
- ワークフローをカスタマイズするときのチーム ボードへの影響
- エンド ツー エンドのワークフローのカスタマイズ手順
- カスタム ワークフロー状態を追加または削除する方法
- 継承されたワークフロー状態を非表示または再表示する方法
- 状態モデルのグラフィック表現を表示する方法
DevOps タスクのビルドとリリースのワークフローに関するドキュメントについては、「 Azure Pipelines の使用」を参照してください。
重要
継承プロセス モデルは、それをサポートするように構成されたプロジェクトで使用できます。 古いコレクションを使用している場合は、プロセス モデルの互換性を確認してください。 オンプレミスのコレクションがオンプレミスの XML プロセス モデルを使用するように構成されている場合は、そのプロセス モデルのみを使用して作業追跡エクスペリエンスをカスタマイズできます。 詳細については、「 プロジェクト コレクションのプロセス モデルを選択するを参照してください。
サポートされているカスタマイズ
継承された状態を非表示にするか、カスタム状態を追加することで、任意の作業項目の種類 (WIT) のワークフローをカスタマイズできます。 継承された状態は、カスタム プロセスの作成元として選択したシステム プロセス (Agile、Basic、Scrum、または CMMI によって異なります。
各 WIT の各既定のワークフローは、2 つから 4 つの状態の間で定義され、次のワークフロー操作を指定します。
- 各状態間の前方および後方遷移
- 各状態遷移の既定の理由
たとえば、基本プロセス、問題 WIT は、次の図に示す 3 つの状態 (To Do、 Doing、 Done) と遷移によって特徴付けられます。
状態の種類
サポートされているカスタマイズ
継承された状態
カスタム状態
ワークフローの状態は、次の規則に準拠している必要があります
- Proposed または In Progress State カテゴリに少なくとも 1 つの状態を定義する必要があります
Note
ワークフロー状態を追加する前に、 ワークフローの状態と状態カテゴリを確認し ワークフローの状態が状態カテゴリにどのようにマップされるかを確認します。
- 少なくとも 2 つのワークフロー状態を定義する必要があります
- 作業項目の種類ごとに最大 32 個のワークフロー状態を定義できます
サポートされていないワークフローのカスタマイズ
- 継承された状態を変更することはできません (名前、色、またはカテゴリを変更することはできません)、非表示にすることはできます
- Completed状態カテゴリに含めることができる状態は 1 つだけです。 [完了] カテゴリにカスタム状態を追加すると、その他の状態は削除または非表示になります。
- カスタム状態の名前を変更することはできません
- 状態の理由を指定することはできません。代わりに、既定の理由 ( Triaged に移動、 状態がトリアージ解除された状態に移動など) が定義されています
- フォームの [状態] フィールドと [理由] フィールドの場所を変更することはできません
- 状態カテゴリ名をカスタマイズすることはできません
- 継承された状態を変更することはできません (名前、色、またはカテゴリを変更することはできません)、非表示にすることはできます
- Completed状態カテゴリに含めることができる状態は 1 つだけです。 システムでは、このカテゴリにカスタム状態を追加できません
- カスタム状態の名前を変更することはできません
- 状態の順序を変更することはできません。状態は、作業項目フォームのドロップダウン リスト内の状態カテゴリに基づいて自然な順序で一覧表示されます
- 状態の理由を指定することはできません。代わりに、既定の理由 ( Triaged に移動、 状態がトリアージ解除された状態に移動など) が定義されています
- フォームの [状態] フィールドと [理由] フィールドの場所を変更することはできません
- 遷移を制限することはできません。すべての遷移は、任意の状態から別の状態に定義されます。
状態ドロップダウン メニューシーケンス
State ドロップダウン メニューには、各状態カテゴリ内で並べ替えるシーケンス内の状態が一覧表示されます。 新しく追加された作業項目の場合、 Proposed カテゴリの最初の状態が既定の状態として割り当てられます。
次の図は、ユーザー ストーリーに定義されている状態シーケンスとそれに対応するドロップダウン メニューを示しています。
各カテゴリ内で、カスタム状態を上下に移動できます。
ワークフローが変更されたチームへの影響
Teams では、次のカスタマイズが行われたときに、ボード構成の更新が必要になる場合があります。
- カスタム状態を追加する
- カスタム状態のカテゴリを変更する
- カスタムまたは継承された作業項目の種類をバックログ レベルに追加します (バックログまたはボードをカスタマイズ)
タスク WIT に追加した状態は、タスクボードに列を追加します。 タスクと共にバグを追跡 場合、バグ 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 フィールドが、これらのカテゴリのワークフロー状態の変更に応じて更新されます。 詳細については、「 割り当てまたはワークフローの変更によるクエリ」、アクティブ化日/日付フィールド、および解決日/日付フィールドを参照してください。
(省略可能)ドロップダウン メニュー内の状態のシーケンスを変更するには、
コンテキスト メニュー アイコンを選択し、 [上へ移動 または Move down] を選択。
WIT の状態の追加が完了したら、ブラウザーを更新して変更を確認し、カスタマイズした種類の作業項目を開きます。
[状態] ドロップダウン メニューが表示され、[Triaged] が選択されています。
バックログ レベルに関連付けられている WIT に State を追加するときは、ボードを使用する各チームが列の設定を 更新する必要があります。
状態を編集する
カスタム状態のカテゴリまたは色を編集できます。 ただし、カスタム状態の名前は変更できません。
から Edit を選択します。 変更する状態のコンテキスト メニュー。
カテゴリまたは色を変更し、[保存] 選択。
カテゴリを変更した場合、ボードを使用するチームは、 列の設定を更新する必要があります。
カスタム状態を非表示または削除する
状態を非表示または削除する場合:
- WIT の [状態] ドロップダウン メニューに状態が表示されなくなりました
- 作業項目履歴に変更は発生しません
- 既存の作業項目は状態値を維持しますが、無効な状態です。 作業項目を変更する場合は、まず状態値を更新する必要があります。 クエリを作成し、一括更新を実行して、影響を受ける作業項目を有効な状態に移動することができます。 状態を作業項目の種類に戻すと、作業項目は有効な状態に戻ります。
継承された状態を非表示または再表示する
チームがワークフロー プロセスで使用していない継承された状態を非表示にすることができます。 ただし、カテゴリごとに少なくとも 1 つの状態が定義されている必要があります。
[…] 非表示にする状態のコンテキスト メニューで、 Hide オプションを選択します。
ここでは、バグ WIT の解決済み状態を非表示にします。
Note
ボードで追跡されている WIT の状態を非表示にする場合は、ボードを使用する各チームが列の設定を 更新する必要があります。
再表示するには、... コンテキスト メニューをクリックし、[ 非表示 オプションを選択します。
カスタム状態を削除する
[…] 削除する状態のコンテキスト メニューを選択し、 Remove を選択します。 削除できるのはカスタム状態のみです。
[状態の削除] ダイアログボックスで、[ 削除をクリックします。
状態ワークフロー モデルを表示する
State Model Visualization Marketplace 拡張機能をインストールすると、状態ワークフロー モデルを表示できます。 この拡張機能は、[状態ビジュアライザー] というラベルの付いた新しいハブをボードの下に追加します。 そのページでは、作業項目の種類を選択して、ワークフロー状態モデルを表示できます。
Note
State Model Visualization 拡張機能は Azure Boards のサポートされている機能ではないため、製品チームではサポートされていません。 拡張機能の使用時に発生する質問、提案、または問題については、 拡張ページを参照してください。
たとえば、次の図は、 Triaged 状態を持つようカスタマイズされたバグ ワークフローを示しています。 このビューは、ワークフロー モデルの既定の遷移を示しています。 すべての状態は、ある状態から別の状態に移行できます。
ビューの拡大と縮小を行うことができます。 また、状態ノードを移動して、状態モデルをより適切に把握することもできます。
関連記事
Note
監査ログを使用して、継承されたプロセスに加えられた変更を確認します。 詳細については、「 アクセス、エクスポート、およびフィルター監査ログを参照してください。