次の方法で共有


Azure Boards のアジャイル ワークフロー

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

Azure Boards でアジャイル プロセスを適用すると、いくつかの作業項目の種類 (WIT) を使用して、チームがプロジェクトの進捗状況を計画および追跡するのに役立ちます。 使用可能な WIT には、エピック、機能、ユーザー ストーリー、タスク、問題、バグが含まれます。 WIT が定義されたら、ボードを使用して、特定の項目の状態を更新することで進行状況を追跡できます。

作業項目の種類を使用して作業を計画および追跡できる Azure Boards のアジャイル プロセスの概念図。

製品所有者とプログラム マネージャーは、フィーチャー、シナリオ、またはユーザー エクスペリエンスのポートフォリオを把握するために、 ユーザー ストーリーフィーチャーに割り当てます。 チームがスプリントで作業するときに、ユーザー ストーリーに自動的にリンクする タスク を定義します。 アジャイル プロセスを開始する場合は、アジャイルを使用して 作業を計画および追跡する方法を確認します。

テスト担当者は Web ポータルまたは Microsoft Test Manager から、 バグと問題 に対するテスト ケースを作成して実行できます。これは、コードの欠陥やブロックの問題を追跡するために使われます。

ユーザー ストーリーを定義する

通常、製品所有者は、アプリケーション、要件、要素の開発に必要な作業を説明するユーザー ストーリーを定義し、スタック順位を付けます。 チームはそれに基づいて、最も優先度の高い項目を実現するための作業量と作業を見積もります。

[Product Backlog]\(製品のバックログ\) ページのクイック 追加パネルからユーザー ストーリーを作成します。 また、ページ内の項目をドラッグ アンド ドロップし、項目の順序を変更したり、 アイテムをフィーチャにマップしたりすることもできます。

ユーザー ストーリー作業項目フォームのスクリーンショット。

各ユーザー ストーリーを開いて詳細を指定し、ストーリー ポイントを見積もることができます。 [ストーリー ポイント] を定義して、チームが予測機能とベロシティ グラフを使い、今後のスプリントや作業工数を見積もることができるようにします。 バックログ ページ ( [スタック ランク ] フィールドにキャプチャされる) のユーザー ストーリーに優先順位を付けることで、製品の所有者は割り当てる項目の優先度を高く指定できます。

フォームに入力するときは、次の表のガイダンスと、 作業項目の種類全体で使われる共通のフィールド を参考にしてください。

Field

Usage


ユーザー ストーリーの場合は、そのストーリーの実装に必要な作業量を見積もるのに十分な情報を指定します。 だれにとっての機能か、その機能で何を達成したいのか、およびその理由に焦点を当てる必要があります。 機能の開発方法を記述しないでください。 チームが項目を実装するためのタスクとテスト ケースを記述できるように、十分な詳細を指定します。

バグまたはユーザー ストーリーを終了する前に満たすべき条件を指定します。 作業を始める前に、顧客の受け入れ基準をできる限り明確に説明します。 受け入れ条件を定義するためのチームと顧客の間の会話は、チームが顧客の期待を確実に理解するのに役立ちます。 受け入れテストの基礎として受け入れ基準を使うことで、満足できるレベルで項目が完了したかどうかをより効果的に評価できます。

エピック、機能、要件、またはバックログ項目で扱う顧客価値の領域。 値は次のとおりです。

  • アーキテクチャ: ソリューションを提供するビジネス機能を実装するための技術サービス。
  • ビジネス: (既定) 顧客または利害関係者のニーズを満たし、ビジネスをサポートするために顧客価値を直接提供するサービス。

チームが希望する測定単位を使用して、ユーザー ストーリーを完了するために必要な作業量を見積もります。 このフィールドの値は、アジャイルの ベロシティ グラフ予測 ツールによって参照されます。 詳細については、「見積もり」のホワイト ペーパーを参照してください。

ビジネスに関連しているユーザー ストーリー、機能、または要件の主観的な評価。 使用できる値は、以下のとおりです。

  • 1: 機能のない製品は出荷できません。
  • 2: (既定値) 機能のない製品は出荷できませんが、すぐに対処する必要はありません。
  • 3: フィーチャーの実装は、リソース、時間、リスクに応じて任意で対応します。

ユーザー ストーリーが正常に完了した場合の相対的な不確実性の主観的評価。 使用できる値は、以下のとおりです。

  • 1 - 高
  • 2 - 中
  • 3 - 低

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

実行されている作業に関するコメントを追加および確認するには、 [ディスカッション] セクションを使います。

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

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

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

Note

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

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

次のいずれかのアイコンを選択して、他のユーザーに言及した、作業項目にリンクした、または pull request にリンクした最近のエントリのメニューを開きます。

同じメニューを開くには、キーボード ショートカット (@メンション @、ハッシュ タグの #、感嘆符 !) を使用します。

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

名前または番号を入力して、入力内容に一致するようにメニュー リストをフィルターします。 追加するエントリを選択します。 グループをディスカッションに取り込むには、 at 記号 @ を入力し、その後にグループ名 (チームやセキュリティ グループなど) を入力します。

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

ディスカッションコメントを編集または削除するには、[編集]、[その他のアクション() を選択し、[削除] を選択します

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

コメントを更新したら、 更新を選択します。 コメントを削除するには、削除を確認します。 作業項目フォームの [履歴] タブには、編集および削除されたすべてのコメントの完全な監査証跡が保持されます。

Important

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

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

コメントの右上にある絵文字アイコンを選択して、コメントに 1 つ以上のリアクションを追加します。 コメント下部の既存のリアクションの横にあるアイコンから選びます。 リアクションを削除するには、コメントの下部にあるリアクションを選びます。 次の画像は、リアクションを追加するエクスペリエンスの例と、コメントに対するリアクションの表示を示したものです。

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

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

Note

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

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

コメントを保存したら、作業項目を保存する必要はありません。

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

Note

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

進行状況の追跡

作業が進むにつれて、[ 状態 ] フィールドを変更して状態を更新します。 必要に応じて理由を指定できます。 [状態] フィールドと [理由] フィールドは、ヘッダー領域の作業項目フォームに表示されます。

[状態] フィールドと [理由] フィールドを示すバグ作業項目フォーム、ヘッダー領域のスクリーンショット。

アジャイル ワークフローの状態

ワークフローを更新すると、チームは新しい項目、進行中のアイテム、または完了したアイテムを表示できます。 ほとんどの WIT では、各ワークフロー状態からの前方および後方への移行がサポートされています。 次の図は、ユーザー ストーリー、バグ、タスクの WIT の主な進行状況と回帰の状態を示しています。

ユーザー ストーリー ワークフロー状態の概念図、アジャイル プロセス。

バグ ワークフロー状態の概念図、アジャイル プロセス。

タスク ワークフロー状態の概念図、アジャイル プロセス。

ユーザー ストーリーの一般的なワークフローの進行状況を次に示します。

  1. 製品所有者は、既定の理由である [新しいユーザー ストーリー]を使って、 [新規] 状態のユーザー ストーリーを作成します。
  2. チームは、スプリント中に作業を完了することを決定したときに、ストーリーの状態を アクティブ に更新します。
  3. ストーリーは、チームがストーリーに関連するすべてのタスクを完了し、単体テストに合格すると解決済み状態に移行します。
  4. 製品所有者が受け入れ基準と受け入れテストに合格した場合にストーリーが実装されることに同意すると、ストーリーは Closed 状態に移行します。

ボードまたはタスクボードで状態を更新する

チームは ボード を使用して要件の状態を更新し、 タスクボード を使用してタスクの状態を更新できます。 新しい状態列に項目をドラッグすると、[ 状態 ] フィールドと [ 理由 ] フィールドの両方が更新されます。

ボードで進行状況を追跡する画面のスクリーンショット。

ボードをカスタマイズして、さらに多くの スイムレーン または をサポートすることもできます。 詳細については、「作業追跡エクスペリエンスをカスタマイズする」を参照してください。

機能にユーザー ストーリーをマップする

一連の製品またはユーザー エクスペリエンスを管理する場合は、製品ポートフォリオ全体の作業のスコープと進行状況を表示することをお勧めします。 機能を定義 し、 ユーザー ストーリーを機能にマップすることで、作業のスコープと進行状況を確認できます。

ポートフォリオ バックログを使うと、 あるバックログから別のバックログへとドリルダウン して、情報を必要な詳細レベルで表示できます。 また、複数のチーム間で進行中の作業をロールアップで表示するために、チームの階層を設定したときにはポートフォリオ バックログを使用します。

タスクの定義

チームがスプリントで作業を管理する場合は、 スプリント バックログ ページ を使用して、計画された作業を個別のタスクに分割できます。

スプリント バックログのスクリーンショット。タスクを追加する。

タスクに名前を付け、[ 作業量 ] セクションで実行する作業を見積もります。

アジャイル タスク作業項目フォームのスクリーンショット。

アジャイル プロセスを使う場合、チームは作業を予測し、各スプリントの開始時にタスクを定義します。 各チーム メンバーは、識別されたタスクのサブセットを実行します。 タスクには、開発、テストおよび他の作業を含めることができます。 たとえば、開発者はユーザー ストーリーを実装するタスクを定義し、テスト担当者はテスト ケースを作成して実行するタスクを定義します。

チームは、時間数または日数に従って作業を見積もるときに、タスクと [残存作業時間アクティビティ ] (オプション) フィールドを定義します。

Field

Usage


このタスクを完了するために必要な見積もり作業量。 通常、初期値を入力してもフィールド値は変更されません。 作業時間は、時間数または日数で指定できます。 このフィールドに関連付けられた固有の時間単位はありません。

このタスクを完了するための残存作業量。 作業の進行状況に応じて、このフィールドを更新します。 タスクをサブタスクに分割した場合は、サブタスクごとに時間を指定します。 作業は、チームで選択した任意の測定単位で指定できます。 このフィールドは、次のグラフと SQL Server レポートを計算するために使用されます。

タスクの実行に費やされた作業量。

チームでスプリント キャパシティをアクティビティ単位で見積もる場合に、このタスクが表すアクティビティの種類を選択します。

コードが組み込まれた、または、バグが修正された製品ビルド番号。

テスト進行状況の追跡

ユーザーストーリー及びコード欠陥に関するバグを使用して、テストの進捗を追跡します。 他の種類の問題の追跡については、「 他の問題の追跡」を参照してください。

ユーザー ストーリーのテスト

Web ポータルまたは Test Manager から、 ユーザー ストーリーまたはバグに自動的にリンクするテスト ケースを作成できます。 または、 [リンク] タブから、ユーザー ストーリーをテスト ケースにリンクできます。

テスト計画 Web ポータルのスクリーンショット。

テスト ケースには複数のフィールドがあり、その多くが自動化され、Test Manager とビルド プロセスに統合されています。 各フィールドの説明については、「ビルドとテストの統合フィールドに基づいてクエリを作成する」を参照してください。

テスト ケース フォームのスクリーンショット。

[ リンク ] タブには、テスト ケースのユーザー ストーリーとバグへのリンクがキャプチャされます。 ユーザー ストーリーとバグをテスト ケースにリンクすることで、チームは各項目のテスト中に行われた進行状況を追跡できます。 これらのリンクを定義すると、SQL Server ストーリーの概要 レポートに表示される情報がサポートされます。

コード障害を追跡

コードの欠陥を追跡するためのバグを、Web ポータル、Visual Studio、または Test Manager で作成できます。

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

次のフィールドとタブは、ほとんどの作業項目に表示されます。 各タブは、特定の情報を追跡するために使用されます。 一般的に使用されるタブには、 HistoryLinksAttachments があります

すべての作業項目の種類で必須である唯一のフィールドは [タイトル] です。 作業項目を保存すると、一意の識別子 ID が割り当てられます。 フォームでは必須フィールドが黄色で強調表示されます。 その他のフィールドの詳細については、「作業項目フィールドのインデックス」を参照してください。

Note

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

フィールドまたはタブ

Usage


説明を 255 文字以下で入力します。 タイトルは後で変更できます。

作業の実行を担当するチーム メンバーに作業項目を割り当てるか、空白のままにして後で割り当てを完了します。

作業項目を最初に作成すると、[ 状態 ] フィールドには、ワークフローの最初の状態 ( 新規未割り当てなど) が自動的に表示されます。 作業が進むにつれて、作業項目の現在の状態を反映するように 状態 を更新します。

作業項目を最初に作成するときに、既定の 理由 値 ( [作成済み][新しい作業項目] など) を設定します。 作業項目の 状態 が変わると、それに応じて 理由 の値を更新します。 作業項目の各 状態 は、既定の 理由 値に関連付けられています。

製品またはチームに関連付けられているエリア パスを選択するか、空白のままにして、後で適切な値を入力します。 使用可能な領域のドロップダウン リストを変更できます。 詳しくは、「区分パスを定義してチームに割り当てる」をご覧ください。

作業項目を完了するスプリントまたはイテレーションを選択するか、空白のままにして後で値を割り当てます。 イテレーションのドロップダウン リストを変更できます。 詳細については、「 イテレーション パス (スプリント) を定義し、チームイテレーションを構成する」を参照してください。

[履歴 ] タブ

作業項目 履歴 を表示すると、システムによってキャプチャされた項目に加えられたすべての変更が表示されます。 作業項目が更新されるたびに、詳細が履歴に追加されます。 変更日、変更作成者、および更新されたフィールドの一覧が表示されます。 [ 履歴 ] フィールドに書式設定されたテキストを追加することもできます。

[リンク ] タブ

リンクを追加して、他の作業項目との接続を作成します。 ハイパーリンク、変更セット、ソース ファイルなど、さまざまな種類のリンクがサポートされています。 ビルドで見つかったテスト結果など、作業項目へのリンク アイテムのリレーションシップを指定します。

添付ファイルを使用して、作業項目に関する補足情報をアイテムに含めます。 電子メール スレッド、ドキュメント、画像、ログ ファイル、またはその他の種類のファイルを添付します。

その他の問題を追跡する

問題は、進行状況をブロックしたり、ユーザー ストーリーの配布を妨げる可能性があるイベントを追跡するために使用されます。 一方、バグはコードの欠陥を追跡するために使われます。 チーム ダッシュボード[新しい作業項目] ウィジェットまたは [クエリ] ページの [新規] メニューから、問題を追加できます。

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

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

ビジネス価値を追跡する

[優先順位] フィールドを使用して、さまざまなストーリーの値を区別できます。 あるいは、ストーリーの相対的な値を追跡するカスタム フィールドをユーザー ストーリー WIT に追加することができます。 詳細については、「 プロセスのフィールドをカスタマイズする」を参照してください。

バックログ リストの順序

[Stack Rank]\(スタック ランク\) フィールドは、ユーザー ストーリーの相対的なランク付けを追跡するために使用されます。 既定では、このフィールドは作業項目フォームには表示されません。 バックログ ページ上の項目のシーケンスは、項目を 追加する場所またはページ上の項目を移動する場所に応じて決定されます。 項目をドラッグすると、バックグラウンド プロセスによって [スタック ランク ] フィールドが更新されます。

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

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

ほとんどの作業項目の種類の場合、作業項目フォームに対してフィールドの追加、ワークフローの変更、カスタム ルールの追加、カスタム ページの追加を行うことができます。 カスタムの作業項目の種類を追加することもできます。 詳細については、プロジェクトで使用されるプロセス モデルに応じて、 継承プロセスのカスタマイズ または オンプレミスの XML プロセス モデルのカスタマイズ に関する記事を参照してください。