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

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Azure Boards でアジャイル プロセスを使う場合、エピック、フィーチャー、ユーザー ストーリー、タスク、問題/バグといった作業項目の種類 (WIT) は、チームがプロジェクトの進行状況を計画および追跡するのに役立ちます。 WIT を定義したら、かんばんボードを使い、それらの項目の状態を更新することで進行状況を追跡できます。

製品所有者とプログラム マネージャーは、フィーチャー、シナリオ、またはユーザー エクスペリエンスのポートフォリオを把握するために、ユーザー ストーリーをフィーチャーに割り当てます。 チームがスプリントで作業するときに、ユーザー ストーリーに自動的にリンクするタスクを定義します。 アジャイル プロセスを初めて使う場合は、まずセクション「アジャイルを使った作業の計画と追跡」を参照してください。

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

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

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

プロダクト バックログ ページでクイック追加パネルからユーザー ストーリーを作成します。 このページから、項目をドラッグ アンド ドロップして並べ替えることや、機能にマップすることもできます。

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

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

フィールド/タブ

使用方法

---

説明

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

受け入れ基準

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

値の領域

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

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

ストーリー ポイント

チームが好む任意の数値の測定単位を使って、ユーザー ストーリーを完成するために必要な作業量を見積もります。

このフィールドの値は、アジャイルのベロシティ グラフと予測ツールによって参照されます。 詳細については、「見積もり」のホワイト ペーパーを参照してください。

優先順位

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

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

リスク

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

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

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

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

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

注意

[ディスカッション] の作業項目フィールドはありません。 [ディスカッション] 領域に入力されたコメントで作業項目のクエリを実行するには、[履歴] フィールドでフィルター処理します。 [ディスカッション] テキスト ボックスに入力したテキストの完全な内容が [履歴] フィールドに追加されます。

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

他のユーザーにメンションするために行った最近の入力、作業項目へのリンク、または pull request へのリンクのメニューを開くには、 または を選ぶか、@、#、または ! を入力します。

名前または番号を入力すると、入力に合わせてメニュー リストがフィルター処理されます。 追加するエントリを選びます。 グループをディスカッションに参加させるには、@ とグループ名 (チームやセキュリティ グループなど) を入力します。

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

ディスカッションのコメントを編集または削除するには、[編集] を選ぶか、 アクション アイコンを選んでから [削除] を選びます。

コメントを更新したら、[更新] を選びます。 コメントを削除するには、削除の意思を確認します。

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

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

コメントにリアクションを追加するには、コメントの右上隅にあるスマイル アイコンを選びます。 または、コメント下部の既存のリアクションの横にあるアイコンから選びます。 リアクションを削除するには、コメントの下部にあるリアクションを選びます。 次の図は、リアクションを追加するエクスペリエンスの例と、コメントに対する反応の表示を示したものです。

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

Note

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

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

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

注意

[ディスカッション] コントロールで行った変更を保存すると、コメントのみが保存されます。 作業項目の種類に対して定義されている作業項目ルールは実行されません。

進捗状況の追跡

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

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

ワークフローを更新すると、チームは、新しい項目、進行中の項目、完了した項目を見分けることができます。 WIT のほとんどが、各ワークフローの状態から前方と後方の両方向への遷移をサポートしています。 これらのダイアグラムは、ユーザー ストーリー、バグ、タスクの WIT の主な進行と回帰の状態を示しています。

ユーザー ストーリー	Bug	タスク

ユーザー ストーリーの通常のワークフローの流れを次に示します。

• 製品所有者は、既定の理由である [新しいユーザー ストーリー] を使って、[新規] 状態のユーザー ストーリーを作成します。
• チームは、スプリントの作業を完了したと判断した時点で、状態を [アクティブ] に更新します。
• 関連付けられたすべてのタスクをチームが完了し、ストーリーの単体テストが成功すると、ユーザー ストーリーは [解決済み] に移行します。
• 受け入れ基準に従ってストーリーが実装され、受け入れテストが成功したことに製品所有者が同意すると、ユーザー ストーリーは [終了] 状態に移行します。

かんばんまたはタスクボードを使って状態を更新する

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

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

機能へのユーザー ストーリーの割り当て

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

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

タスクを定義する

チームがスプリントで作業を管理する場合、スプリント バックログ ページを使って、達成する作業を個別のタスクに分割できます。

タスクに名前を付け、必要な作業を見積もります。

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

チームは時間または日数を使用して作業を見積もる場合、タスクと、[残存作業] フィールドと [アクティビティ] (省略可能) フィールドを定義します。

フィールド/タブ

使用方法

---

最初の見積もり

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

残存作業

このタスクを完了するための残存作業量。 作業の進行状況に応じて、このフィールドを更新します。 このフィールドは、キャパシティ グラフ、スプリント バーンダウン チャート、バーンダウンとバーン レート、残存作業、すべてのイテレーションの状態という各 SQL Server レポートの計算に使われます。 タスクをサブタスクに分割した場合は、サブタスクごとに時間を指定します。 作業は、チームで選択した任意の測定単位で指定できます。

実績作業

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

アクティビティ

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

ビルドに統合

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

テスト進行状況の追跡

ユーザー ストーリーとコードの欠陥を使ってテストの進行状況を追跡します。

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

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

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

(リンク タブ) には、テスト ケースのユーザー ストーリーとバグへのリンクが取り込まれます。 ユーザー ストーリーやバグをテスト ケースにリンクすると、チームで各項目のテストの進行状況を追跡できます。 これらのリンクを定義することで、ストーリーの概要レポートのレポートに表示される情報をサポートできます。

コード障害を追跡

バグは Web ポータルや Visual Studio から、または Test Manager でテストを実行しているときに作成できます。

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

次のフィールドとタブは、ほとんどの作業項目に表示されます。 各タブは、[履歴]、[リンク]、または [添付ファイル] など、特定の情報の追跡に使われます。 この 3 つのタブでは、変更の履歴、リンクされた作業項目の表示、ファイルの表示と添付機能を使用できます。

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

注意

プロセスとプロジェクトに加えられたカスタマイズによって、追加のフィールドが必要になることがあります。

フィールド/タブ

使用方法

---

タイトル

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

割当先

作業の実行を担当するチーム メンバーに、作業項目を割り当てます。

State

作業項目が作成されたときの、状態の既定値はワークフローの最初の状態です。 作業の進行状況に応じて、現在の状態を反映するように更新します。

理由

まず既定値を使用します。 状態を変更したときに更新します。 各状態には、既定の理由が関連付けられます。

領域

製品またはチームに関連付けられている区分パスを選択するか、計画会議で割り当てられるまでの空白のままにします。 区分のドロップダウン リストを変更するには、区分パスの定義とチームへの割り当てに関する記事を参照してください。

反復

作業を完了させる必要があるスプリントまたはイテレーションを選択するか、空白にしておいて後で計画会議で割り当てます。 イテレーションのドロップダウン リストを変更するには、「イテレーション パス (スプリント) の定義とチーム イテレーションの構成」を参照してください。

(履歴)

システムで記録された監査証跡を確認し、追加情報を記録します。

作業項目が更新されるたびに、情報が履歴に追加されます。 履歴には、変更が行われた日付、変更を行った人、および変更されたフィールドが含まれます。 書式設定されたテキストを [履歴] フィールドに追加することもできます。

(リンク)

ハイパーリンク、変更セット、ソース ファイルなど、すべての種類のリンクを追加します。

このタブには、作業項目に定義されているすべてのリンクも一覧表示されます。

(添付ファイル)

作業項目にファイル (電子メール スレッド、ドキュメント、イメージ、ログ ファイルなど) を追加して、詳細情報を共有します。

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

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

関連記事

• プロジェクトの作成
• 作業項目を追加してプロジェクトを管理する
• バックログを作成する
• かんばんボードを追加する
• スプリントを計画する

問題を追跡する

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

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

ビジネス価値を追跡する

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

バックログ リストの順序

[スタック順位] フィールドは、ユーザー ストーリーの相対的なランキングを追跡するために使われますが、既定では作業項目フォームに表示されません。 バックログ ページに表示される項目のシーケンスは、ページで項目を追加または移動した場所に従って決まります。 項目をドラッグすると、バックグラウンド プロセスでこのフィールドが更新されます。