アジャイル プロジェクト管理のベストプラクティス

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

Azure Boards にはさまざまなアジャイル計画ツールがあり、その多くは互いに組み合わせて機能します。 この記事では、Azure Boards を初めて使うプロジェクト マネージャー向けのスタート ガイドを提供します。 あなたとチームがプロジェクトの計画と管理に最小限の追跡アプローチを採用したい場合は、このガイドから始めてください。 また、ウォーターフォール プロジェクト管理からアジャイル方式に移行する場合は、このガイドから始めてください。

この記事のほとんどのガイダンスは、クラウドとオンプレミスの両方のバージョンに対して有効です。 ただし、ロールアップ、分析、一部のポートフォリオ計画ツールなど、この記事に記載されている機能の一部は、現時点ではクラウドでのみ使用できます。

チームを構成する

Azure Boards は、作業を計画および追跡するための一連のアジャイル ツールを各チームに提供します。 各プロジェクトに既定のチームが定義されており、すぐに使い始めることができます。 開発チームまたは機能チームが複数ある場合は、機能チームごとに Azure DevOps でチームを定義することをお勧めします。 こうすることで、各チームは互いに協力しながら自律的に作業することができます。

ベスト プラクティスのヒント:

• 組織が提供したいバリュー ストリームに沿ってチームを構成します。
• 6 人から 12 人の開発者からなる開発グループごとにチームを定義します。
• プロジェクト管理機能チームへのロールアップをサポートするように開発チームを構成します。

構成チームの詳細については、次を参照してください。

• チームの階層の構成
• チームを作成または追加する
• アジャイル カルチャを採用する
• アジャイルを大規模なチームに拡大する

スプリントを構成する

イテレーション パスによって指定されたスプリントは、プロジェクトに対して定義され、チームによって選択されます。 スプリント周期は 1 週間から 4 週間以上の期間で変動する可能性があります。 また、リリース トレインを含む階層内でスプリントを定義することもできます。 あなたは、スプリントの終了時に完了することをチームがコミットする作業をスプリントに割り当てます。 これらの Azure Boards ツールは、チームの スプリント バックログ、タスクボード、予測と配信の計画へのスプリント割り当てに依存しています。 詳細については、「スクラム プラクティスを実装する」および「チームのデリバリー プランを見直す」を参照してください。

ベスト プラクティスのヒント:

• 製品グループ内のすべてのチームが使用するスプリントの頻度を定義します。

• 今後 6 か月から 12 か月の計画をサポートするイテレーションを少なくとも 6 回以上定義します。

• チームがイテレーションを使用してバックログ項目を管理する方法を決定します。

  • 割り当てられていないスプリント作業は、既定のバックログに割り当てられます。
  • 割り当てられていないスプリント作業は、指定された将来のバックログ スプリントに割り当てられます。

構成スプリントの詳細については、次を参照してください。

• イテレーション パスを定義して割り当てる
• イテレーション パスの定義とチーム イテレーションの構成

作業項目の種類を選ぶ

顧客要求と開発作業を把握するために、チームが使用できる作業項目タイプを判断します。 プロジェクトがアジャイル プロセスに基づいている場合は、User Story、Bug、Feature 作業項目の種類を使用することをお勧めします。

プロジェクトが Basic、Scrum、Capability Maturity Model Integration (CMMI) などの別のプロセスに基づいている場合は、次の選択肢があります。 各チームはバグを追跡する方法を判断します。

ベスト プラクティスのヒント:

• Feature 作業項目の種類を使用して、出荷する顧客機能をキャプチャします。

• バックログから機能や要件をすばやく追加し、後で詳細を入力します。

• Requirement 作業項目の種類を使用して、開発チームが所有する作業に機能を分割します。 さらに:

  • アジャイルの場合は、User Story 作業項目の種類を使用します。
  • 基本の場合は、Issue 作業項目の種類を使用します。
  • スクラムの場合は、Product バックログ作業項目の種類を使用します。
  • CMMI の場合は、Requirement 作業項目の種類を使用します。

• Bug 作業項目の種類を使用して、コードの欠陥をキャプチャします。

• 要件を機能にマッピングして、プロジェクト管理レベルで進捗を追跡します。

• スプリント内で完了するサイズ要件。

• スプリントまたは複数のスプリント内で完了する機能のサイズを設定します。

• エピックの作業項目のサイズを、四半期ごとまたはマイルストーンの目標に合わせて配信します。

• 開発者が [タスク] カテゴリーを使用して、必要に応じて作業を分割できるようにします。

プロジェクト マネージャーは、機能を管理します。 開発チームは要件を管理します。 親子リンクを使用してマッピングすると、機能の進捗を可視化できます。 チームのバックログに追加した各作業項目には、チームに設定された既定の区分パスとイテレーション パスが自動的に割り当てられます。

複数の機能を出荷する必要がある大規模なイニシアチブまたはシナリオがある場合は、親子リンクを使用してエピック カテゴリーにグループ化します。

作業項目の種類の詳細については、次を参照してください。

• 機能とエピックを定義する
• バックログの作成
• バックログを整理する

製品計画を作成する

機能バックログを使用して製品計画を作成します。 その後、開発チームは製品バックログを使用して製品計画を作成します。 定期的に、製品計画を見直し、改善する必要があります。

機能バックログ

プロジェクト マネージャーは、機能バックログに機能を追加することで製品計画を開始します。 各機能は、顧客のニーズに対応するリリース可能な成果物を表す必要があります。

プロダクト バックログ

開発チームは、製品バックログにユーザー ストーリーを追加します。 ユーザー ストーリーには、チームの既定のエリア パスとイテレーション パスが自動的に割り当てられます。 次に、チームは機能の実装に必要な作業を表す各機能の下に、それらのストーリーをマップします。 スプリント内で完了できるように各ユーザー ストーリーのサイズを設定する必要があります。

各バックログを調整する

次のタスクを実行して、各バックログを定期的に確認します。

• 実行する作業を定義します。
• ドラッグ アンド ドロップ方式を使用して作業項目を並べ替え、優先順位順に表示されるようにします。
• 作業項目を開き、詳細を追加します。
• チーム メンバーまたはスプリントに作業を割り当てます。
• 配信の正常なエコシステムをサポートするために必要な技術的負債と機能以外の作業をキャプチャします。
• 親のない作業を、その作業が属する機能にマッピングします。
• 要件のサイズを見積もって、チームの速度を決定し、予測をサポートします (オプション)。

ベスト プラクティスのヒント:

• バックログを定期的に調整します。
• 機能と要件のサイズが適切であることを確認します。
• 機能と作業の受け入れ基準と完了の定義を定義します。
• マップされていない作業を機能にマッピングします。
• 実行するバックログ タスクをサポートするように表示オプションを設定します。
• バックログを予測します。

詳細については、以下を参照してください:

• 機能とエピックを定義する
• バックログの作成
• バックログ ビューを構成する
• プロダクト バックログを予測する

タグを使ってクエリとフィルター処理をサポートする

作業項目タグを使うと、チーム メンバーは作業項目にアドホック タグを割り当てることができます。 これらのタグを使用して、バックログとボードをフィルター処理できます。 また、それらを使用して作業項目に対してクエリを実行することもできます。 チームの役に立つタグにするには、チームでタグを使う方法に関する一般的なガイダンスを用意します。 このガイダンスをプロジェクト Wiki などの中央の場所で文書化することを検討してください。

次の画像は、Web タグ付きのカードを表示する Web キーワードでフィルター処理されたボードを示しています。

ベスト プラクティスのヒント:

• チームでタグを使用する方法に関するポリシーを用意します。
• タグを使用してクエリ、フィルタ処理、レポートをサポートする方法を示します。
• タグを使用して、チーム間またはプロジェクト間の依存関係を識別することを検討してください。

詳細については、以下を参照してください:

• リストとボードの分類およびフィルター処理のために作業項目タグを追加する
• ボードをフィルター処理する
• プロジェクト用 Wiki の作成。

予測とマイルストーン計画

どの機能をいつリリースできるかについて分析するには、予測ツールを使います。 このツールでは、各要件の [ストーリー ポイント]、[工数] または[サイズ] フィールドに見積もりを指定する必要があります。 作業項目を単純な数で予測する場合は、要件の見積もりに 1 の値を割り当てます。

機能バックログを優先度順に並べる

プロジェクト マネージャーは、常に機能のバックログを優先順位の高い順に作成し、最初に完了することが最も重要な機能を開発チームに伝える必要があります。

ここで、機能バックログは、出荷する機能のシーケンスを示しています。

親機能に基づいて要件バックログに順序を付ける

機能をリリースするために必要な要件を満たしていることを確認します。 次の図に示すように、要件バックログは、リリースしたい機能に従って順序付けられます。 この順序付けは、機能をリリースするにはその機能のすべての要件が完了している必要があることを前提としています。 また、各ユーザー ストーリーにはストーリー ポイントが割り当てられます。

要件バックログを予測する

各要件に見積もりを割り当てると、チームのベロシティを設定できます。 次の例では、速度に 12 を指定していますが、これはチームがスプリントごとに平均 12 ストーリー ポイントを完了できることを示すことと同等の意味を示します。 予測ツールは、チームが今後 6 スプリント以内に完了できる要件と機能を示します。 計画ツールを使用すると、予測されたスプリントに要件を割り当てることができます。

見積もりを適切に行い、チームのベロシティを予測できるようになることは、プロセス改善に役立つチーム目標です。

機能ボードを更新する

機能のリリース時期を予測したら、各機能のイテレーション パスを更新できます。 次の図に示すように、ボードのカードにこれらのフィールドを追加することで、機能に値を割り当てます。

マイルストーン計画

マイルストーン マーカーは、配信計画を除いて、Azure Boards の作業追跡では使われません。 配信計画には [カレンダー] ビューがあり、マイルストーン マーカーを定義できます。 詳細については、「Azure Boards でチーム デリバリー プランを見直す」を参照してください。

次のオプションの 1 つ以上を使用して、作業項目をマイルストーンとしてマークできます。

• 作業項目のタイトルの先頭または末尾に「マイルストーンという単語を追加します。
• 「マイルストーン」という作業項目タグを追加します。
• 「マイルストーン」というカスタム フィールドを追加し、それをマイルストーンの選択リストに追加します。
• [先行タスク/後続処理] または [関連] リンクの種類を使用して、マイルストーン作業項目に作業項目をリンクします。
• マイルストーン作業項目を、完了を目標とするスプリントに割り当てます。

依存関係の管理

Microsoft Project では、他のタスクの完了に依存するタスクをリンクすることで管理します。 Azure Boards で依存関係を管理するには、[先行処理/後続処理] リンクの種類を作業項目に追加することで、同様のリンクを追加できます。 これらのリンクは、作業項目の [リンクの追加] ダイアログから追加します。

[リンクの追加] ダイアログ

Azure Boards は、関連する作業を追跡するための多くのリンクの種類をサポートしています。 依存関係のある作業を追跡するには、[先行処理/後続処理] リンクの種類を選びます。 作業項目をリンクする簡単な方法は、依存関係の生成または使用に参加する作業項目にタグを追加することです。 タグを使用するクエリを作成したら、必要なリンクを追加します。

次の [リンク の追加] ダイアログは、後続リンクの種類を使用して 2 つの作業項目をリンクする方法を示しています。

作業項目の関係を視覚化する

実用最小限の製品 vs. クリティカル パス管理

Azure Boards にはクリティカル パスのネイティブ ビューが用意されていません。 アジャイル手法では、クリティカルパス管理よりも実用最小限の製品 (MVP) が好まれます。 MVP を使用すると、Epic、Feature、User Story、Task の作業項目の種類に優先順位を付けることで、最短パスと依存関係を特定できます。 詳細については、「アジャイル プロジェクトのクリティカル パス」および「Azure DevOps でリーン スタートアップを実行する」を参照してください。

ベスト プラクティスのヒント:

• 依存関係管理に参加している作業項目に dependency タグを追加します。
• 先行タスク/後続タスクのリンクの種類を使用して、他のチームまたは他のプロジェクト内で所有されている作業の依存関係を追跡します。
• 依存関係を追跡、追加、トリアージするためのクエリを作成します。
• 配信計画を使用して、別のチームからの依存関係がある作業を表示します。
• Work Item Visualization Marketplace 拡張機能を使って、作業項目フォーム内の特定の作業項目の依存関係を視覚化します。

詳細については、以下を参照してください:

• 作業項目をオブジェクトにリンクする
• 配信計画を使って依存関係を追跡する

スプリントでの作業

開発チームはスプリントを使うと、事前に選んだ一連の作業を完了することに集中できます。 スプリントに割り当てられた作業は、チームのスプリント バックログに表示されます。 スプリント バックログは、ポートフォリオ バックログに対してではなく、プロダクト バックログに対してのみ定義されます。

スプリントの間、作業の状態を毎日更新することで、次の画像に示すように、スプリント バーンダウン グラフでスプリントの進行状況を簡単に追跡できます。

ベスト プラクティスのヒント:

スプリントごとに、次のタスクを実行します

• チームで各スプリントを計画します。
• チームのスプリント バックログを使用して、スプリントの成果物を確認します。
• 各スプリント作業項目がチーム メンバーに割り当てられていることを確認します。
• 各作業項目のスコープがスプリント内で完了することを確認します。
• 作業の受け入れ基準が明確に定義され、理解されていることを確認します。
• 作業が [新規]、[アクティブ] から [完了] 状態に移行した時に、スプリント作業項目の状態を更新し、スプリントのバーンダウンを追跡します。
• チームの作業が依存する依存関係について他のチームと確認します。
• スプリント バーンダウン チャートを使用して、スプリントの進捗を監視します。

詳細については、以下を参照してください:

• バックログ項目をスプリントに割り当てる
• スプリント バーンダウンの構成と監視
• 機能とエピックを定義する

進行状況と機能の成果物を確認する

進行状況と成果物を確認するために使う 3 つの主なツールは次のとおりです。

• 機能ボード
• ロールアップ列がある機能バックログ
• 配信計画

機能ボード

機能ボードでも、進行状況を確認し、成果物の継続的なフローを確保することができます。 次の図は、カスタムされた [機能] ボードを示しています。これには、[詳細情報が必要]、[デック上]、[進行中]、[顧客ロールアウト] などの進行中の列が含まれています。 これらの列は、機能が提案、調査、設計、開発され、運用環境にデプロイされるときに、より自然な状態一式を提供します。

ロールアップ

進捗をすばやく視覚的に監視する方法の 1 つとして、機能バックログの使用が挙げられます。 次の画像に示すように、ロールアップ進行状況バーの列を追加することで、各機能で完了した作業項目の割合を確認できます。

配信計画と複数のチーム成果物

複数のチームに提供される機能を確認するには、配信計画を構成します。 配信計画は、複数のチームが配信を計画しているストーリーまたは機能のカレンダーを確認するための対話型ボードを提供します。

ベスト プラクティスのヒント:

• 機能ボードをカスタマイズして、チームのプロセスをサポートします。
• カードにフィールドを追加して、値をすばやく簡単に更新できるようにします。
• 機能のイテレーション パス (スプリント) を更新して、いつ出荷するかを明確にします。
• [機能] ボードを確認して、状態、ブロック/問題/リスク/変更、および更新状態を確認します。
• フィルタ機能を使用して、タグ付けされた項目、割り当て者機能、特定のスプリントなどに焦点を当てます。
• 機能バックログにロールアップ列を追加して、作業項目数の完了に基づいて全体的な進捗を監視します。
• 配信計画を使用して、複数のチームの機能を確認し、チーム間の依存関係について話し合います。

詳細については、以下を参照してください:

• ボードの列を管理する
• カードのカスタマイズ
• ボードをフィルター処理する
• ロールアップの進行状況または合計を表示する
• チーム 配信計画のレビュー

プロセスの改善

アジャイル方式の中心には継続的な改善があります。 プロセスを改善するには、目標を共有し、計画を共有する必要があります。 プロセス改善活動を開始するには、定期的な実習を通じてプロセス改善活動を追加することを検討してください。 次のようなニーズが考えられます。

• スプリントを計画します。
• スプリントの目標を設定します。
• 定期的に見直しを実施します。

目標を設定する際には、次の点を考慮してください。

• 顧客について何を学んでいますか? 理解しておく必要があること
• 測定対象のデータは何ですか? それは実行可能ですか? 測定する必要があるデータは何ですか?
• 成果物のフローはどのようになっていますか? それは期待通りですか? どこに改善を加えられますか?
• チーム メンバーは最善を尽くす権限を与えられていますか? 改善に役立つツールや情報は何ですか?
• 情報の共有はどのくらいうまくいっていますか? チームの共同作業はどのくらいうまくいっていますか?
• "チームによる技術的負債の管理とバグの解決はどのくらいうまくいっていますか?"

プロセス改善をサポートするために使用できるアジャイル ツールには、チームのベロシティ、チーム ダッシュボード、Retrospectives Marketplace 拡張機能があります。

チームのベロシティ

チームの速度チャートを見ると、チームがスプリントをどの程度適切に計画および実行しているかを理解できます。 次の例に示すように、速度チャートには、複数のスプリントの作業項目の計画、完了、遅延、および未完了の数が表示されます。 チームはこのグラフを確認することで、見積もりと実行がどのくらいうまくいっているか、またどのように改善できるかを判断できます。

チーム ダッシュボード

チームはダッシュボードを定義して、情報を共有し、作業の進行状況に関するリアルタイム データを監視できます。

ベスト プラクティスのヒント:

• チームが同意できるプロセス改善目標を特定し、それを書き留めて、定期的にレビューします。
• チーム ダッシュボードを使用して、情報と作業追跡グラフを共有し、自分とチームが定期的に確認します。
• スプリント計画会議で、プロセス改善に関連するスプリントの目標を少なくとも 1 つ特定してもらいます。
• 定期的に見直しを行い、うまくいったこと、うまくいかなかったこと、改善すべきアクションを把握します。
• 見直しマーケットプレース拡張機能で利用できる改善追跡ボードなど、改善追跡ボードを維持します。

詳細については、以下を参照してください:

• チームの速度を表示および構成する
• ダッシュボードの追加、名前の変更、削除
• スケーリングするアジャイル プラクティスを実装する
• Retrospectives Marketplace 拡張機能

次のステップ

関連記事

• 要件の管理
• バックログ項目の複数チーム所有権を操作する
• Azure Boards を使用して作業の計画と追跡を行う 11 個の理由

業界の記事

• アジャイルと継続的改善の考え方
• KAIZEN とは何か