アジャイルプロジェクトで長期的に要件管理はどのように機能しますか？
アジャイルプロジェクトの短期的な要件管理は、私にとって解決された問題のようです。
スクラムアングルから、新しい要件または既存の要件への変更がユーザーストーリーを通じて提供されます。また、エピックまたはフィーチャーの下にグループ化されたユーザーストーリーは、より複雑で大規模な要件の提供を促進します。
もちろん、ユーザーストーリーは技術的に要件ドキュメントではありません。これは、機能のVertical Sliceと呼ばれることが多いものにマッピングされる、管理可能な作業のグループです。そして、これらのストーリーの範囲は、受け入れ基準（AC）を使用して明確に定義できます。
したがって、ユーザーストーリーは正式な要件ではありませんが、ユーザーストーリーを閲覧することで、ユーザーストーリーの基本的な要件をかなり明確に把握できます。短期的には。
短期的に言うと、プロジェクトが進むにつれてユーザーストーリーの数が増えるからです。したがって、増え続けるストーリーのリストを参照して要件を見つけることは、時間の経過とともにますます効率が悪くなります。
この問題は、以前のストーリーを拡張、置換、または無効化するユーザーストーリーを検討する場合にさらに悪化します。
ここで、プロジェクトの開発反復間の2年のギャップを想像してください（本番環境で安定）。元のチームはなくなり、すべての知識も失われました。
元のチームがこれが起こることを知っていた場合（たとえば、それがビジネスの性質である場合）、その後のチームを支援するためにどのような措置をとることができますか？
確かに、バックログはいくつかの情報を提供しますが、簡単に参照できる形にはなっていません。
それで、whyとhowを含めて、後続のチームがプロジェクトの状態を理解するために何ができるでしょうか？
私の経験では、次のことは機能しません。
- Backlog groomingバックログを要件ドキュメントとして読み取ることができるように、以前のユーザーストーリーを削除または更新します。
- Documentation Sprintsここで、チームメンバーはシステムの現在の状態を文書化する必要があります。
- 行動テストによる文書化。このアプローチは、私が作業に近づくのを見た唯一のものです。残念ながら、コード化された動作テストはネーミング問題の犠牲者です。テストでシステムを適切に文書化することはできますが、変動する開発者チームに同じドメインの用語、表現、スタイルに従ってテストを記述させることはほとんど不可能です。
繰り返しますが、
長期的にアジャイルプロジェクトの要件をどのように管理しますか？
これは、アジャイルプロジェクトが行われている部屋で、暗黙のうちに象になっているように見えます。どうすれば、アジャイルが混乱に発展するのを防ぐことができますか？
アジャイルマニフェストを少し見てみましょう。アジャイルの欲望：
- 早期の継続的デリバリー
- 変化する要件を受け入れる
- 動作するソフトウェアを頻繁に配信する
- 毎日一緒に働く開発者とビジネス関係者
- やる気のある個人を中心にプロジェクトを構築し、必要な環境とサポートを提供し、仕事を成し遂げることを信頼する
- コミュニケーションの主要なモードとしての対面会話
- 進歩の主要な尺度としての実用的なソフトウェア
- 持続可能な開発
- 卓越した技術と優れたデザインへの継続的な注意
- シンプル-必要のない作業を最大化
- チームは定期的に、より効果的になる方法を検討し、それに応じてその動作を調整および調整します
最後の4つを強調表示しました。どうして？それは、プロジェクトが自重で崩壊するのを防ぐためのものだからです。
持続可能な開発とは、開発プロセス全体を監督する人、ソフトウェアを少しずつ成長させることを超えて船を操縦できる人、プロジェクト全体の包括的なビジョンを持つ人、鋭い知識を持つ人が（できれば）いることを意味しますソフトウェアアーキテクチャ、システム設計、ビジネスロジックの原則、およびUIエルゴノミクス。言い換えれば、建築家。
アーキテクトは、「あなたがこれを要求したのは知っていますが、これとは別のものを構築すれば、混乱を招く他の3つの機能を回避し、コア要件に焦点を当てることができます。」彼はチームに技術的負債を減らす時間を与える人です。彼は、プロジェクトに包括的な構造と組織をもたらす人物です。彼は、チームが集まる会議を呼び出して、「どうすればもっと上手くできるか？」
そして、彼はマスター要件ドキュメントを管理している人物です。
本 Mastering the Requirements Process で、著者は3種類の顧客、3種類のソフトウェアプロジェクトがあることを維持しています：うさぎ、馬、象。ウサギは、非公式の要件のみを必要とする小さなソフトウェアプロジェクトです。小さなスプリントで顧客と直接作業し、プロジェクトの範囲は合理的に制限されており、ソフトウェアは比較的短い時間枠で完了します。象は、多くの事前の計画、膨大な量のドキュメント、および長い期間を必要とする巨大なプロジェクトです。これらはおそらくアジャイルではありませんが、アジャイルを使用して構築できる小さなプロジェクトに分割できます。
アジャイルの観点からやや混乱しているのは、Horseプロジェクトです。それらは繰り返し作成でき、短いスプリントを使用できますが、要件の収集と計画のプロセスにある程度の規律がなければ、簡単にRailsから実行できます。これらは、統制のとれた要件収集プロセスの恩恵を受けることができるプロジェクトであり、プロジェクト全体の包括的なビジョンを維持しながら、プロジェクトの成長に応じてこれらの要件を注意深く調整および変更できます。
個人的な観点から、私は約12人の開発者の小さなチームと協力しています。いつでも、数千行のコードから100,000を超えるコードまで、3つのソフトウェアプロジェクトに同時に取り組んでいる可能性があります。お客様はうさぎだと思っていますが、実は馬です。顧客は従事していますが、日常的には従事していません。
断然私たちの最も弱い領域は、特定のテスト可能で測定可能な要件を収集し、プロジェクトの範囲に対する顧客の期待を管理することです。しかし、私たちはそれに取り組んでいます。
質問は完全に明確ではありませんが、要件トレーサビリティに関心があるようです。私の経験では、アジャイルで迷子になる傾向がある1つのアイデアは、ビジネス要件は顧客がシステムに求めていることであり、一方でユーザーストーリーは実際機能的です要件その状態方法システムは動作します。 「ユーザーとして、私はXができるようになりたいです。」しかし、それはユーザーストーリーで失われる可能性がある要件を満たすために行われます。
私の経験でうまく機能しているのは、ビジネス要件とユーザーストーリーを双方向でリンクすることです。 BR＃1はストーリーAとBで実現できます。ストーリーCはBR＃2と＃3をカバーする場合があります。これをプロジェクトトラッカーやスプレッドシートなど、使用しているものに配置します。
長期的には、これにより、お客様が求めていること（BR）と、システムがそれらの要件を達成するために行っていること（ストーリー）を関連付けることができます。これは、維持するのに煩わしくないかなり最小限のドキュメントである必要があり、誰も必要としないドキュメントを作成しないというアジャイルの考え方を維持し、最新に保つのは面倒です。
また、新しいプロジェクトメンバーは、履歴を裏付けるためにレビューする必要があるものがあるため、スピードを上げる方法も提供しますwhyソフトウェアはそれを実行します。
私は実際には、元の開発者がもう利用できない大きなWebショップのかんばんメンテナンスプロジェクトで働いています。
すべてのuserstory/requirement/bugfixにはticketnumberがあり、すべてのsourcecode-changeはsourcecontrol-comment-fieldのticketnumberにリンクされています。
sourcecontrol-checkin-s（svn）は、対応するチケットを原子的に更新して、チケットにすべてのsourceconrtol-changesetsへのリンクがあるようにします。
モジュール/関数が新しく実装された場合、ソースコードにもチケット番号があります。
チケットシステム（redmine）では、チケットは次のように相互にリンクされています（重複している、バグである、改良されている...など）。
チケットを追跡して、時間の経過に伴う要件の変化を確認できます。
例：「orderConfirmation-Web-page」で何かを変更する必要があります。ページのソースコードに「created for "＃4711"」というコメントが表示されるので、新しいチケットを古いチケット「4711」またはその後継の1つにリンクできます。
個人的には、システムが何ができるかに関するドキュメントのソースとして、ユーザーストーリーを破棄します。ドキュメントを作成するためのアクティブな手順が取られていない限り（これは、従来のクライアントの一部に対して行ったものです）、アプリケーションベースは実際に最も優れたドキュメントです。
しかし、それは新しいことではありません。
よりスケールされたバージョンのアジャイル（ SAFe など）を使用している場合、実装バックログではない他のバックログが存在します。基本的には次のようになります。
- ポートフォリオバックログ（エピックと予算の戦略的計画）
- プログラム/リリースバックログ（機能とエピック）
- プロジェクト/チームバックログ（ストーリー、スパイク、バグ）
チームバックログレベルで文書化することはお勧めしません。細かすぎて、そのレベルの詳細に行きたいと思う人はめったにいません。チームバックログの以前のストーリーと矛盾するリリースがストーリー内にある可能性があることは言うまでもありません。
代わりに、リリースバックログレベルで作業してリリースレベルのドキュメントを提供することをお勧めします。これらのストーリーは、特定のリリースに割り当てられるとめったに爆発しないため、特定のリリース内で何が行われているかを確認するための安定した迅速な方法になる場合があります。