4
アジャイルプロジェクトでは、要件管理は長期的にどのように機能しますか？
アジャイルプロジェクトの短期的な要件管理は、私にとっては解決された問題のようです。 スクラムアングルから、新しい要件または既存の要件への変更がユーザーストーリーを通じて提供されます。また、EpicまたはFeatureの下にグループ化されたユーザーストーリーにより、より複雑な要件の配信が容易になります。 もちろん、ユーザーストーリーは技術的には要件文書ではありません。これは、機能の垂直スライスと呼ばれることが多いものにマッピングされる、管理可能な作業グループです。また、これらのストーリーの範囲は、承認基準（AC）を使用して明確に定義できます。 そのため、ユーザーストーリーは正式な要件ではありませんが、ユーザーストーリーを参照することで、ユーザーの基本的な要件をかなり明確に把握できます。短期的に。 プロジェクトが進行するにつれて、ユーザーストーリーの数が増加するため、短期間で言います。したがって、増え続けるストーリーのリストを閲覧して要件を見つけることは、時間の経過とともに効率が低下します。 この問題は、以前のストーリーを拡張したり、置き換えたり、さらには無効にするユーザーストーリーを検討するとさらに悪化します。 ここで、プロジェクトでの開発の反復間の2年のギャップを想像してください（本番環境で安定）。元のチームはなくなり、すべての知識も失われました。 元のチームがこれが起こるとわかっていた場合（たとえば、ビジネスの性質）、その後のチームを支援するためにどのような対策を講じることができましたか？ 確かに、バックログはいくつかの情報を提供しますが、簡単に閲覧できる形式ではほとんどありません。 それでは、後続のチームがプロジェクトの状態を理解するために何ができるか、なぜそれがどのようにそこに到達したのかを含めて？ 私の経験では、次のことはうまくいきません。 バックログを要件ドキュメントとして読み取ることができるように、以前のユーザーストーリーを削除または更新するバックロググルーミング。 ドキュメントスプリント。チームメンバーがシステムの現在の状態をドキュメント化するタスクを担当します。 動作テストによる文書化。このアプローチは、私が仕事に近づいているのを見た唯一のものです。残念ながら、コード化された動作テストはネーミング問題の犠牲になります。テストはシステムを適切に文書化するかもしれませんが、変動する開発者チームが同じドメイン用語、表現、スタイルに従ってテストを作成することはほとんど不可能です。 繰り返しますが、 長期的にアジャイルプロジェクトの要件をどのように管理しますか？