変更の管理

  • [アーティクル]

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

Azure DevOps には、変更を効果的かつ効率的に管理するのに役立つさまざまなツールと機能が用意されています。これは、プロジェクトの重要な部分です。 この記事では、変更を管理するための概要を説明し、アジャイル変更管理タスクを Azure DevOps がサポートするツールにマップします。

変更の必要性を判断する

次のいくつかのソースは、ソフトウェア開発プロジェクトで必要な変更に貢献できます。

  • ビジネス ニーズと顧客ニーズの変化
  • 新しい優先順位が生じる
  • 新しい情報が発生するか、依存関係が検出されると、機能要件が変更される
  • リソースと組織の変更
  • 開発またはテストに予想以上の時間がかかる
  • デプロイと継続的な操作の後に問題が発生する

変更を最小限に抑える

次の詳細を使用して、不要な変更を最小限に抑えます。

  • 明確な要件と受け入れ基準
  • プロジェクトのスコープと優先順位をクリアする
  • チームが合意した変更管理プロセスを明確にする
  • 計画作業に関する適切な見積もり
  • 新しい作業のネゴシエートされた要求
  • 要件
  • 変更が発生した場合のチーム内の適切なコミュニケーション
  • 変更要求に関する利害関係者や顧客からの入力
  • チーム メンバーは、問題が発生したときに問題を発生させるのに慣れる

変更管理に関するアジャイルのベスト プラクティス

Note

アジャイルは、プロジェクトを "スプリント" と呼ばれる短い反復サイクルに分割することによって機能するプロジェクト管理アプローチです。 アジャイルの中核となるのは、プロジェクトの開発に合わせて状況が変化するという前提に基づいています。 そのため、アジャイル プロジェクトでは、計画、設計、開発、テストのサイクルは決して行われません。 プロジェクトがフォームに入ると、引き続き変更されます。 —IMA

変更によって発生する問題を軽減するために、アジャイル プロジェクト マネージャーは多くのベスト プラクティスを採用します。 これらのプラクティスは、プロセスの制御、製品計画レベルでの変更の管理、スプリントの管理、変更基準の検討というグループに分かれています。

プロセスを制御する

変更管理プロセスをサポートするには、チームとビジネスの両方の目標を満たし、変更に対処するために必要な承認の数を最小限に抑え、継続的な改善プロセスでチームを支援します。

ヒント

継続的な改善は、プロセス、方法、およびプラクティスが可能な限り効率的かつ効果的であることを確認する方法です。 —アジャイルと継続的な改善の考え方

製品プラン レベルで変更を管理する

  • 製品計画と製品バックログを継続的に調整し、優先順位を付ける
  • 顧客のニーズが理解され、適切にスコープ設定され、伝達されていることを確認する
  • 依存関係とリスクについて製品バックログを分析する
  • コンティンジェンシー計画を作成する
  • 変更要求の分析とトリアージ
  • 現在の作業と計画された作業に対する変更要求のスコープの影響を決定する
  • 変更を受け入れる、または拒否するリスクを評価する
  • 必要に応じて簡易変更コントロール フォームを使用する

スプリントを管理する

  • スプリントの開始時に受け入れ基準と要件が十分に理解されていることを確認する
  • アジャイルの原則に従いながら、スプリントの開始後の変更の受け入れを最小限に抑える作業
  • 変更が発生したときにすべての利害関係者とチームを関与させておく
  • スコープの変更を制御し、スコープの不一面を最小限に抑える
  • 合意された元のスコープ外のプロジェクトに変更を加えるのを防ぎ、チームを保護する

ヒント

スコープ のクリーピングとは スコープ の不備は、プロジェクトの成果物または機能が最初に定義されたものから拡張されたときに発生します。追加の時間や予算に見合った変更はありません。

変更条件を検討する

変更を検討するときは、次の質問をします。

  • それはスプリントの目標に役立ちますか?
  • 変更に対する明確なビジネス価値はありますか?
  • リリース時に、スコープ変更の結果を使用する予定ですか?
  • 変更要求の緊急性は何ですか?
  • スプリント バックログに新しいスコープが追加された場合、削除できるものはありますか?

変更の追跡

変更を追跡するには、いくつかの選択肢があります。 最も軽量なものから堅牢なものまで、次の 1 つ以上の方法を使用できます。

  • ディスカッション、受け入れ基準の変更、または添付ファイルを通じて、要件作業項目内の要件に対する変更を追跡する
  • 作業範囲への変更の追跡をサポートするために、作業項目に変更タグを追加する
  • チームまたは組織内の変更を自動的に通知するように通知を設定する
  • スコープまたは別の作業の変更を追跡するバグを追加する
  • 変更要求の作業項目の種類を追加して、変更要求を正式に追跡し、製品バックログにログを記録する

これらのメソッドを使用すると、変更に関連する作業項目を一覧表示するクエリを生成し、チームで変更を確認してトリアージできます。 変更を追跡する方法は、自分とチームが変更の範囲を監視して報告する方法と一致する必要があります。

変更要求フォームを使用する

機能成熟度モデル統合 (CMMI) プロセスの次の図のような変更要求作業項目の種類を定義します。

変更要求作業項目フォームのスクリーンショット。

フォームは、次の領域への変更の影響をキャプチャします。

  • Architecture
  • ユーザー エクスペリエンス
  • テスト
  • 設計と開発
  • 技術文書

このフォームを採用することも、独自にカスタマイズすることもできます。 変更要求を他のユーザー ストーリーや要件と共にバックログに表示することもできます。

受け入れ基準が明確に定義されていることを確認する

要件またはバグ修正が完全に実装されているかどうかを確認する条件を明確に記述する、受け入れ条件で "完了" とは何かを定義します。 通常、作業項目内でこれらの条件をキャプチャする必要があります。 明確な受け入れ基準は、チームが作業を見積もり、基準が満たされていることを確認するためのテストを開発するのに役立ちます。

個々の要件とスプリントの受け入れ基準を指定できます。 受け入れ基準を共有して理解することで、すべてのチーム メンバーが作業の範囲を理解できます。

変更の監視とレポート

Teams は、作業項目のクエリ、チームのベロシティ チャート、スプリント バーンダウングラフ、リリース バーンダウン チャートを使用して変更を監視できます。

作業項目クエリ

クエリを使用すると、変更管理タグでタグ付けされた変更管理要求または作業項目の一覧を見つけてトリアージできます。

チームの速度と計画外の作業

チーム のベロシティ チャート には、いくつかの情報が表示されます。 このグラフは、計画された作業の量と完了した量を示しています。 スプリントの開始後にスプリントに作業が追加された頻度を視覚的に確認できます。

スプリントバーンダウンとスコープのクリーピング

スコープ の不調を確認するもう 1 つのグラフは、スプリント バーン ダウン チャートです。 Azure Boards を使用すると、各スプリントと各チームのスプリント バーンダウン チャートを確認して、各スプリントに導入されたスコープの忍び寄りの程度を判断できます。

変更の通知を受け取る

Azure DevOps には堅牢なアラート システムが用意されています。このシステムでは、プロジェクト メンバーが自分、チーム、またはプロジェクトに対してアラートを設定できます。 作業項目、コード レビュー、ソース管理ファイル、ビルドに対する変更が発生すると、電子メール通知を受け取ることができます。