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

  • [アーティクル]

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

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

Note

チームがかんばんまたはスクラム メソッドの実践に取り組んでいる場合は、「ボードとかんばんについて」または「スクラムの実装に関するチュートリアル」を参照してください。

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

チームを構成する

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

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

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

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

スプリントを構成する

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

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

  • 製品グループ内のすべてのチームが使用するスプリントの頻度を定義します。
  • 今後 6 か月から 12 か月の計画をサポートするイテレーションを少なくとも 6 回以上定義します。
  • チームがイテレーションを使用してバックログ項目を管理する方法を決定します。
    • 割り当てられていないスプリント作業は、既定のバックログに割り当てられます。
    • 割り当てられていないスプリント作業は、指定された将来のバックログ スプリントに割り当てられます。

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

作業項目の種類を選ぶ

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

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

次の図は、アジャイル プロセスのバックログ作業項目の階層を示しています:

  • ユーザー ストーリーとタスクは、作業を追跡するために使用します。

  • バグはコードの欠陥を追跡します。

  • エピックと機能は、大規模なシナリオで作業をグループ化するために使用します。

    アジャイル作業項目の種類を示す図。

各チームは、バグの処理設定を構成することで、ユーザー ストーリーやタスク作業項目と同じレベルでバグ処理項目の管理方法を構成できます。 このような作業項目の種類を使う方法については、アジャイル プロセスに関する記事を参照してください。

注意

"要件" では、ソフトウェア製品に対するユーザーの期待を指定します。 Azure Boards では、要件はプロダクト バックログに表示される作業項目によって定義されます。 これらは、プロジェクトに対して選択されたプロセスに基づいて、User Story (アジャイル)、Product バックログ項目 (スクラム)、Issue (Basic)、または Requirement (CMMI) 作業項目の種類に対応します。 また、製品バックログに表示される作業項目の種類を管理する [Requirements] カテゴリにも属します。

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

  • Feature 作業項目の種類を使用して、出荷する顧客機能をキャプチャします。
  • バックログから機能や要件をすばやく追加し、後で詳細を入力します。
  • Requirement 作業項目の種類を使用して、開発チームが所有する作業に機能を分割します。 さらに:
    • アジャイルの場合は、User Story 作業項目の種類を使用します。
    • 基本の場合は、Issue 作業項目の種類を使用します。
    • スクラムの場合は、Product バックログ作業項目の種類を使用します。
    • CMMI の場合は、Requirement 作業項目の種類を使用します。
  • Bug 作業項目の種類を使用して、コードの欠陥をキャプチャします。
  • 要件を機能にマッピングして、プロジェクト管理レベルで進捗を追跡します。
  • スプリント内で完了するサイズ要件。
  • スプリントまたは複数のスプリント内で完了する機能のサイズを設定します。
  • エピックの作業項目のサイズを、四半期ごとまたはマイルストーンの目標に合わせて配信します。
  • 開発者が [タスク] カテゴリーを使用して、必要に応じて作業を分割できるようにします。

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

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

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

製品計画を作成する

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

機能バックログ

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

機能バックログを示すスクリーンショット。

プロダクト バックログ

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

製品バックログを示すスクリーンショット。

各バックログを調整する

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

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

ヒント

完了した作業に割り当てられた見積もりや、スプリント中に完了した作業項目の単純な数に基づいて、チームのベロシティを監視できます。 [予測] 機能を使用するには、値を [ストーリー ポイント]、[工数]、[サイズ] フィールドに割り当てる必要があります。 要件を見積もらない場合は、要件の見積もりに値 1 を割り当て、作業項目の数に基づいて予測ツールを使用できます。

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

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

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

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

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

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

キーワード検索を使用してフィルター処理されたかんばんボードを示すスクリーンショット。

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

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

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

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

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

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

プロジェクト マネージャーである場合、機能バックログを常に優先度順に並べ、最初に完了する必要がある最も重要な機能を開発チームに伝えます。

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

機能の親順に並べられた機能バックログを示すスクリーンショット。

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

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

機能の親順に並べられた要件バックログを示すスクリーンショット。

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

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

画像全体を表示するには、画像をクリックして拡大します。 閉じるアイコン 閉じるアイコン を選択して閉じます。

機能の親順に並べられた要件バックログの予測を示すスクリーンショット。

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

機能ボードを更新する

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

更新されたイテレーション パスを含む [機能] ボードを示すスクリーンショット。

マイルストーン計画

マイルストーン マーカーは、配信計画を除いて、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 拡張機能を使って、作業項目フォーム内の特定の作業項目の依存関係を視覚化します。

Note

マーケットプレース拡張機能は Azure Boards のサポートされている機能ではないため、製品チームではサポートされていません。 これらの拡張機能を使用する上での質問、提案、または問題については、対応する拡張機能に関するページを参照してください。

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

スプリントでの作業

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

バーンダウン グラフのスプリント

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

分析スプリント バーンダウン グラフを示すスクリーンショット。

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

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

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

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

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

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

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

機能かんばんボード

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

画像全体を表示するには、画像をクリックして拡大します。 閉じるアイコン 閉じるアイコン を選択して閉じます。

カスタマイズされた列を含む [機能] ボードを示すスクリーンショット。

ロールアップ

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

進行状況バーの列オプションを示す機能バックログを示すスクリーンショット。

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

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

配信計画のコールアウトのスクリーンショット。

対話型計画要素

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

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

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

プロセスの改善

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

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

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

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

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

チームのベロシティ

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

チーム速度チャートの例を示すスクリーンショット。

チーム ダッシュボード

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

チーム ダッシュボードの例を示すスクリーンショット。

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

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

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

次のステップ

Azure Boards の構成とカスタマイズ

業界の記事