スクラム プロセスの作業項目の種類とワークフローを管理する

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022

Azure Boardsでスクラムを使用して、ソフトウェアの配信を計画し、優先順位を付け、欠陥を追跡します。 Teams は、製品バックログアイテム (PBI) とバグとして作業をキャプチャし、それらの項目をポートフォリオの可視性のために機能にマップし、スプリント作業を PBI とバグにリンクするタスクに分割します。

計画と追跡に使用されるスクラム プロセス作業項目の種類を示す概念図。

Note

スクラム プロセスを初めて使う場合には、 スプリント、スクラム、プロジェクト管理の概要に関する記事を参照してください。

この記事は次のことに役立ちます。

Prerequisites

面積 Requirement 共同作業の重要性
プロジェクト メンバーシップ Azure Boardsで作業項目を表示および編集する権限を持つプロジェクトのメンバーである必要があります。 スクラム ワークフローの状態を通じて作業項目を作成、更新、移動するために必要です。
アクセス レベル 作業項目を作成および更新するには、少なくとも Basic アクセス権が必要です。 基本的なバックログ、ボード、タスクの追跡操作に必要です。
バックログとボードへのアクセス チームのバックログとボードにアクセスする必要があります。 ボードとタスクボードから PBI の優先順位付け、スプリントの計画、状態の更新を行うために必要です。
チーム設定の権限 チーム設定、バックログ レベル、またはボード構成を定義するには、管理者メンバーシップまたは同等の委任されたアクセス許可Project必要があります。 チーム レベルのセットアップとカスタマイズに必要です。
テスト管理アクセス テスト ケースを作成して実行するには、Azure Test Plans (またはデプロイ用の同等のテスト ツール) にアクセスする必要があります。 テスト ケースを PBI にリンクし、テスト結果を追跡するために必要です。

詳細については、「作業追跡のアクセス許可とアクセスを設定する」を参照してください。

PBI とバグを定義する

最初に顧客の価値をキャプチャするために PBI とバグを定義し、その後、作業が実行に近付くにつれて実装の詳細を取得します。

次のパターンを使用します。

優先順位が変わると、バックログの順序を更新します。 バックログ ページでは、 バックログの優先度を使用してこの順序を追跡します。

製品バックログ項目の作業項目フォームを示すスクリーンショット。

予測グラフとベロシティ チャートで将来のスプリント能力を予測できるように 、[エフォート] を設定します。 スタック ランクとは別に優先度を表す ビジネス値 を設定します。

スプリント計画の前に各項目を一貫して完了するには、次のフィールドを使用します。 バグの詳細については、「 バグの管理」を参照してください。

フィールド 使用方法
Effort チームの数値単位 (ストーリー ポイントや時間など) を使用して、PBI を完了するために必要な作業を見積もります。 プロセスのカスタマイズに応じて、このフィールドは省略可能または必須にすることができます。 速度グラフ と 予測 では、この値が使用されます。
ビジネス価値 他の PBI と比較した相対的なビジネス値を示す数値を入力します。 数値が大きいほど、値が大きいことを示します。
Description 機能が提供されるユーザー、ユーザーが実行する必要がある内容、および機能が重要な理由について説明します。 タスクの内訳とテスト設計に十分なコンテキストを含めます。
受け入れ基準 実装が開始される前に実行する条件を定義します。 明確な基準により、チームと利害関係者の期待を整合させ、受け入れテストをサポートします。

[ディスカッション] セクションでコメントを取り込む

[ディスカッション] セクションを使用して、コメントを追加および確認することで作業項目で共同作業を行います。

作業項目フォームの [ディスカッション] セクションのスクリーンショット。

書式設定をサポートするテキスト ボックスにカーソルを置くと、リッチ テキスト エディターのツール バーが表示されます。

[ディスカッション] セクションの [リッチ テキスト エディター] ツール バーのスクリーンショット。

Note

ディスカッション作業項目フィールドが存在しません。 ディスカッション領域からコメント付きの作業項目を照会するには、履歴フィールドでフィルター処理します。 [ディスカッション] テキスト ボックスに入力されたテキストの全内容が [履歴] フィールドに追加されます。

他のユーザー、グループ、作業項目、または pull request についてメンションする

次のいずれかのアイコンを使用して、ユーザー、作業項目、またはプル要求の最近のエントリを開きます。

同じメニューをキーボード ショートカット (@メンション @、ハッシュタグ #、感嘆符 !) で開くことができます。

[ディスカッション] セクションの @メンション ドロップダウン メニューのユーザー ピッカーのスクリーンショット。

リストをフィルター処理する名前または番号を入力し、追加する項目を選択します。 グループに言及するには、 @ を入力し、その後にグループ名 (チームやセキュリティ グループなど) を入力します。

コメントを編集または削除する

コメントの 1 つを更新または削除するには、[編集] を選択するかその他のアクション () を選択し、[削除] を選択します。

[編集] または [削除] アクションを選択できる [ディスカッション] セクションのスクリーンショット。

コメントを変更したら、[ 更新] を選択します。 コメントを削除するには、削除を確認します。 [ 履歴 ] タブには、編集および削除されたすべてのコメントの監査証跡が保持されます。

Important

オンプレミスのAzure DevOps Serverの場合は、チーム メンバーが通知を受信できるように SMTP サーバーを構成します。

コメントにリアクションを追加する

コメントの絵文字を選択して、コメントに 1 つ以上のリアクションを追加します。 反応を削除するには、同じ反応をもう一度選択します。 次の図は、コメントに対するリアクションの追加と表示の例を示しています。

[ディスカッション] セクションのスクリーンショット、コメントにリアクションを追加する。

作業項目を保存せずにコメントを保存する

Note

この機能は、Azure DevOps Server 2022.1 以降で使用できます。

作業項目の ディスカッション に追加するアクセス許可しかない場合は、コメントを保存することで追加できます。 このアクセス許可は、区分パス ノードと、 [Edit work item comments in this node] (このノードの作業項目のコメントを編集する) アクセス許可によって制御されます。 詳細については、「 作業追跡のアクセス許可の設定 - 子ノードの作成、領域または反復パスの下の作業項目の変更」を参照してください。

コメントを保存するときに、作業項目を保存する必要はありません。

[ディスカッション] セクションでのコメントの保存のスクリーンショット。

Note

ディスカッション コントロールに加えた変更を保存すると、コメントのみが保存されます。 作業項目タイプに定義された 作業項目ルール は実行されません。

進行状況の追跡

作業が進むにつれて、 状態 を更新して現在の状態を反映し、必要に応じて [理由] を設定します。 両方のフィールドが作業項目ヘッダーに表示されます。

状態更新を一貫して行い、バックログ、ボード、レポート表示の整合性を保ちます。

クイックフロー:

  • PBI とバグを定義して優先順位を付けます。
  • 作業が進むにつれて、ワークフローの状態を通じてアイテムを移動します。
  • ボードとレポートをレビューして、状態の調整を確認します。

バグ作業項目フォームヘッダー領域を示すスクリーンショット。

スクラム ワークフローの状態

アイテムが新しい、進行中、完了、またはスコープから削除されたかどうかを示す 状態 を更新します。 ほとんどの WIT では、前方遷移と後方遷移の両方がサポートされています。

次の図は、PBI、バグ、タスクの作業項目の種類の主な進行状況と回帰の状態を示しています。

プロダクト バックログ項目 Bug Task
製品バックログ項目ワークフローの状態、スクラム プロセスを示す概念図。 バグ ワークフローの状態、スクラム プロセスを示す概念図。 タスク ワークフローの状態、スクラム プロセスを示す概念図。

一般的な PBI とバグのライフサイクル:

  • 新規: 製品の所有者またはテスト担当者がアイテムを作成します。 既定の理由は、作業項目の種類とプロセスの構成 (たとえば、 新しいバックログ項目) によって異なります。
  • 承認済み: 項目は、チームがスプリント計画を見積もって準備するのに十分なほど定義されています。 通常、優先度の高い項目は、最初にこの状態に移行します。
  • コミット済み: チームはスプリントでアイテムを配信することに同意します。
  • 完了: 関連するすべてのタスクが完了し、製品所有者がアイテムが受け入れ条件を満たしていることを確認します。

意図的にスコープ外とされ、提供予定のない項目には Removed を使用します。 これらの項目を 完了 から除外すると、レポートの精度を維持できます。

ボードとタスクボードからステータスを更新する

ボードを使用して、作業がスプリントを通じて進む中でステータスを常に最新の状態に保ちます。

  • ボードを使用して PBI とバグの状態を更新します。
  • スプリント タスクボードを使用してタスクの状態を更新します。
  • 状態と理由の両方を更新するには、項目を新しい列にドラッグします。

Web ポータルのボードでの進行状況の追跡を示すスクリーンショット。

スイム レーンと列を使用してボードをカスタマイズできます。 その他のオプションについては、「 作業の追跡エクスペリエンスをカスタマイズする」を参照してください。

機能へ PBI をマップする

PBI を機能にマップして、製品、シナリオ、またはチーム全体の範囲と進行状況を追跡します。

この方法を使用します。

検証チェック: 各機能にリンクされた子 PBI が表示され、ロールアップ値が子項目の進行状況と一致することを確認します。

タスクの定義

チームがスプリントで作業する場合は、スプリント バックログ ページから PBI とバグをタスクに分割します。

スプリント バックログの [タスクの追加] エクスペリエンスを示すスクリーンショット。

各タスクに名前を付け、作業量を見積もります。

[スクラム タスク] 作業項目フォームを示すスクリーンショット。

Teams は通常、各スプリントの開始時にタスクを定義します。 チーム メンバーは、開発、テスト、ドキュメントなどの作業のサブセットを完了します。

次のパターンを使用します。

  • PBI またはバグを完了するために必要な各配信手順のタスクを作成します。
  • 所有権に基づいてチーム メンバーにタスクを割り当てます。
  • タスクの値を毎日更新して、容量とバーンダウンが正確に維持されるようにします。

チームが数時間または数日で見積もる場合は、 残存作業時間 とオプション のアクティビティを使用します。

フィールド 使用方法
残存作業時間 残りの時間数または日数を入力し、作業が進むにつれて値を更新します。 このフィールドは、容量グラフ、スプリント バーンダウン、および関連レポートを駆動します。 作業をサブタスクに分割する場合は、サブタスクでのみ残存作業時間を追跡します。
Activity チームがアクティビティの種類別にスプリント容量を見積もって確認できるように、タスクを最も適切に説明するアクティビティ カテゴリを選択します。

テスト進行状況の追跡

テスト カバレッジと欠陥追跡をスプリント バックログ項目に接続するには、次のガイダンスを使用します。

テスト作業をバックログ項目に接続するには、次のパターンを使用します。

  • Web ポータルからテスト ケースを作成して、PBI またはバグにリンクさせます。
  • 必要に応じて、[ リンク ] タブを開き、リレーションシップを手動で追加します。

Azure DevOps Server 2022 では、Microsoft Test Manager 2017 を使用することもできます。

テスト スイートの選択とテスト ケースの追加を示すスクリーンショット。

テスト ケースには、ビルドおよびテスト ワークフローと統合されるフィールドが含まれます。 詳細については、「 ビルドとテストの統合フィールドに基づくクエリ」を参照してください。

[スクラム テスト ケース作業項目] フォームを示すスクリーンショット。

[ リンク ] タブには、各テスト ケースにリンクされている PBI とバグが一覧表示されます。

検証チェック: 各テスト ケースのリンクされた PBI またはバグが [ リンク ] タブに表示されたことを確認します。

コード障害を追跡

Web ポータルまたはVisual Studioからバグを作成します。 詳細については、「 バグの管理」を参照してください。

Azure DevOps Server 2022 では、Microsoft Test Manager 2017 を通じてバグを作成することもできます。

一般的な作業追跡フィールドの定義

次のフィールドとタブは、ほとんどの作業項目に表示されます。 一般的なタブには、 History、 Links、および Attachments があります。

すべての作業項目の種類に対して、 タイトル は汎用必須フィールドです。 作業項目を保存すると、Azure DevOpsは一意の ID を割り当てます。 必須フィールドは黄色で強調表示されます。 その他のフィールドについては、「 作業項目フィールドのインデックス」を参照してください。

Note

プロセスとプロジェクトのカスタマイズに基づいて、他のフィールドが必要になる場合があります。

フィールドまたはタブ Usage
Title 簡単な説明 (最大 255 文字) を入力します。 タイトルは後で編集できます。
割り当て対象 作業項目を完了する担当者に割り当てるか、所有権が明確になるまで未割り当てのままにします。
State 作成時、 状態 は既定で最初のワークフロー状態 ( 新規 や 未割り当てなど) に設定されます。 作業が進むにつれて更新します。
Reason 理由 は、アイテムが現在の 状態である理由を説明します。 既定値は、作業項目の種類とプロセスによって異なります。
Area 製品またはチームのエリア パスを選択します。 詳細については、「 エリア パスを定義し、チームに割り当てる」を参照してください。
Iteration 完了予定のスプリント/イテレーションを選択します。 詳細については、「 イテレーション パス (スプリント) を定義し、チームイテレーションを構成する」を参照してください。
[履歴 ] タブ 作成者、日付、更新されたフィールドなど、作業項目の完全な変更ログを表示します。 また、[履歴] に書式設定されたテキストを追加することもできます。
[リンク ] タブ 他の成果物 (親/子作業項目、変更セット、ソース ファイル、テスト結果など) にリレーションシップを追加します。
[添付ファイル ] タブ ドキュメント、画像、ログ、メール スレッドなどのサポート ファイルを追加します。

作業項目の種類のカスタマイズ

ほとんどの作業項目の種類では、フィールドの追加、ワークフローの更新、カスタム ルールの定義、カスタム ページの追加、カスタム作業項目の種類の作成を行うことができます。 詳細については、「 継承プロセスをカスタマイズする」を参照してください。

ほとんどの作業項目の種類では、フィールドの追加、ワークフローの更新、カスタム ルールの定義、カスタム ページの追加、カスタム作業項目の種類の作成を行うことができます。 詳細については、 プロセス モデルに応じて、継承プロセスのカスタマイズ または オンプレミスの XML プロセス モデルのカスタマイズを参照してください。

懸案事項を追跡する

ブロックを追跡するには、 障害 作業項目の種類を使用します。 コードの欠陥にのみ バグ を使用します。

次の要素から障害を追加できます。

新しい作業項目ウィジェットからの作業項目の追加を示すスクリーンショット。

ウィジェットから追加した作業項目は、チームの既定の領域とイテレーション パスに自動的にスコープ設定されます。 別のチーム コンテキストを使用するには、「チーム コンテキストの 切り替え」を参照してください。

バックログ リストの順序

バックログ優先度を使用して、PBI、バグ、機能、エピックの相対的なランク付けを管理します。

次のパターンを使用します。

  • バックログ ページでアイテムを直接並べ替えます ( 「バックログの作成」を参照)。
  • 現在のビジネス優先度を反映するように項目をドラッグします。
  • Azure DevOps でバックグラウンドで Backlog Priority を更新できるようにします。

検証チェック: 並べ替え後にバックログの順序がビジネスの優先順位と一致することを確認します。

一般的な問題のトラブルシューティング

問題点 原因 Resolution
作業項目を予期された状態に移動できない ワークフロールールまたはプロセスのカスタマイズによって遷移が制限されています プロセスのカスタマイズと許可された切り替えを確認します。 継承プロセスのカスタマイズを参照してください。
必須フィールドが作業項目の保存を妨げている Project固有のカスタム ルールには追加のフィールドが必要です 検証メッセージを確認し、プロセスに必要なフィールドを入力します。 作業項目のルールの設定を参照してください。
テスト ケースを作成または編集できない テストのアクセス許可またはアクセス レベルがない テスト成果物へのアクセスとアクセス許可を確認してください。 作業追跡のアクセス許可とアクセス権の設定に関するセクションを参照してください。
リンクされたテスト ケースがバックログ項目に表示されない リンクが作業項目リンクとして作成されなかったか、別のアイテムに追加されました テスト ケースとバックログ項目を開き、[ リンク] タブ で両方の項目のリンクを確認します。
これらの修正プログラムを適用した後で問題を解決することはできません 組織レベルのポリシーまたはアクセス許可によってアクションがブロックされる 最初にProject管理者に問い合わせてください。 組織全体で問題が発生している場合は、Project コレクション管理者またはAzure DevOps管理者に問い合わせてください。

関連コンテンツ

  • Last updated on