ワークフロー ルールのさまざまなタイプとは

このページでは使用できる各ワークフロー ルールのタイプについて説明して、それらを使用する理由の例を紹介します。ワークフロー ルールの詳細をご確認ください。

ワークフロー ルールの 3 つのタイプは、次の順序で発生します。

1. Restrict transition, which happens before someone tries to transition a work item.

2. Validate details, which happens when someone tries to transition a work item.

3. Perform actions, which happens after someone transitions the work item.

トランジションを制限

This rule type hides the transition from certain people, or from everyone when certain conditions aren’t met. If you add one of these to a transition, people won’t see the transition on a work item unless its criteria is met. Unlike the Validate details rule type, this type doesn’t give people to correct a work item and transition again (they won’t even see the transition). This is very useful for security, but not useful if you just want to remind someone to do something before transitioning.

ほとんどのトランジションの制限ルールには「制限」が含まれます。

Example: Restrict who can move a work item

通常、幅広い領域にわたるチームには、プロセスのさまざまなステージでタスクに取り組んでいるユーザーがいます。たとえば、小規模なチームでは、次のようなステップを踏んでプロセスを進める場合があります。

作業前 → 設計中 → 開発中 → レビュー中 → 完了

チームの領域は次のようなロールにマッピングされます。

• デザイナー

• ソフトウェア エンジニア

• 品質保証

プロジェクト ロールの管理に関する詳細をご確認ください。

ルールを使用して次のような制限を追加することで、適切なロールが作業項目を移動できるようにします。

• 作業項目を [設計中] から移動する場合、作業項目を移動できるユーザーを「デザイナー」ロールに制限する。

• 作業項目を [開発中] から移動する場合、作業項目を移動できるユーザーを「ソフトウェア エンジニア」ロールに制限する。

• 作業項目を [レビュー中] から移動する場合、作業項目を移動できるユーザーを「品質保証」ロールに制限する。

詳細を検証

This rule type makes sure details are correct when transitioning a work item, and stops the transition if they aren’t. When there are incorrect details, the person transitioning the work item will be prompted to fix them.

There’s a subtle difference between this type and Restrict transition. Whereas Restrict transition will hide the transition if they aren’t met, Validate details won’t ever hide the transition. People will be able to see and select the transition, but won’t be able to finish moving the work item if the details aren’t met. That’s why Validate details rules happen when someone is transitioning a work item: it’s after the transition is selected, and before the transition happens.

ほとんどの詳細を検証ルールには「検証」が含まれます。例外は次のとおりです。

• 画面を表示する (企業管理対象プロジェクト)

• フィールドを更新するようにユーザーをリマインドする (チーム管理対象プロジェクト)

Which happen before the other Validate details rules, and allow whoever is transitioning the work item to add information to the work item.

アクションを実行

This rule type automatically does something after transitioning the work item. They’re useful in saving time doing tasks you’d have to do manually. Unlike Restrict transition and Validate details rules which enforce conditions for a transition to pass, Perform actions rules don’t narrow who or when a work item can be transitioned. They’re simply here to help you get work done faster.

Example: Assign a work item

幅広い領域にわたるチームでは通常、プロセスのさまざまな段階でタスクを割り当てます。たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。

作業前 → 設計中 → 開発中 → レビュー中 → 完了

ユーザーはボードの各領域に対して、作業項目を割り当てるためのルールを作成することができます。

• [設計中] に移動する作業項目は、チームの設計者に割り当てます。設計者は、実装の詳細、仕様、および要件を指定します。

• [開発中] に移動する作業項目は、チームの機能開発リードに割り当てます。リードはコードを記述したり、チーム内の他の開発者に作業を任せます。

• [レビュー中] に移動する作業項目は、チームの品質保証担当者に割り当てます。品質保証担当者はテスト記録を作成したり、自動品質テストをビルドしたりします。

• [完了] に移動する作業項目は、割り当てを解除します。