アジャイルプロジェクトでは、要件管理は長期的にどのように機能しますか？

アジャイルプロジェクトの短期的な要件管理は、私にとっては解決された問題のようです。

スクラムアングルから、新しい要件または既存の要件への変更がユーザーストーリーを通じて提供されます。また、EpicまたはFeatureの下にグループ化されたユーザーストーリーにより、より複雑な要件の配信が容易になります。

もちろん、ユーザーストーリーは技術的には要件文書ではありません。これは、機能の垂直スライスと呼ばれることが多いものにマッピングされる、管理可能な作業グループです。また、これらのストーリーの範囲は、承認基準（AC）を使用して明確に定義できます。

そのため、ユーザーストーリーは正式な要件ではありませんが、ユーザーストーリーを参照することで、ユーザーの基本的な要件をかなり明確に把握できます。短期的に。

プロジェクトが進行するにつれて、ユーザーストーリーの数が増加するため、短期間で言います。したがって、増え続けるストーリーのリストを閲覧して要件を見つけることは、時間の経過とともに効率が低下します。

この問題は、以前のストーリーを拡張したり、置き換えたり、さらには無効にするユーザーストーリーを検討するとさらに悪化します。

ここで、プロジェクトでの開発の反復間の2年のギャップを想像してください（本番環境で安定）。元のチームはなくなり、すべての知識も失われました。

元のチームがこれが起こるとわかっていた場合（たとえば、ビジネスの性質）、その後のチームを支援するためにどのような対策を講じることができましたか？

確かに、バックログはいくつかの情報を提供しますが、簡単に閲覧できる形式ではほとんどありません。

それでは、後続のチームがプロジェクトの状態を理解するために何ができるか、なぜそれがどのようにそこに到達したのかを含めて？

私の経験では、次のことはうまくいきません。

• バックログを要件ドキュメントとして読み取ることができるように、以前のユーザーストーリーを削除または更新するバックロググルーミング。
• ドキュメントスプリント。チームメンバーがシステムの現在の状態をド​​キュメント化するタスクを担当します。
• 動作テストによる文書化。このアプローチは、私が仕事に近づいているのを見た唯一のものです。残念ながら、コード化された動作テストはネーミング問題の犠牲になります。テストはシステムを適切に文書化するかもしれませんが、変動する開発者チームが同じドメイン用語、表現、スタイルに従ってテストを作成することはほとんど不可能です。

繰り返しますが、

長期的にアジャイルプロジェクトの要件をどのように管理しますか？

これは、アジャイルプロジェクトのある部屋の暗黙の象のように思えます。どのようにしてそれらがカオスに進化するのを防ぐのですか？

アジャイル宣言を少し見てみましょう。アジャイルの欲求：

1. 早期かつ継続的な配達
2. 変化する要件を受け入れる
3. 動作中のソフトウェアを頻繁に配信する
4. 毎日一緒に働く開発者とビジネス関係者
5. やる気のある個人を中心にプロジェクトを構築し、必要な環境とサポートを提供し、仕事を成し遂げるために信頼する
6. コミュニケーションの主要モードとしての対面の会話
7. 進歩の主要な尺度としての作業ソフトウェア
8. 持続可能な発展
9. 卓越した技術と優れたデザインへの継続的な注意
10. シンプルさ-必要のない作業を最大化する
11. 定期的に、チームはより効果的になる方法を熟考し、それに応じて動作を調整および調整します

最後の4つを強調しました。どうして？プロジェクトが自重で崩壊するのを防ぐものだからです。

持続可能な開発とは、（願わくば）開発プロセス全体を監督する人、ソフトウェアを少しずつ成長させる以上に船を操縦できる人、プロジェクト全体の包括的なビジョンを持つ人、鋭い知識を持つ人がいることを意味しますソフトウェアアーキテクチャ、システム設計、ビジネスロジックの原則、UIの人間工学の知識。言い換えれば、建築家。

アーキテクトは「あなたがこれを要求したことは知っていますが、この他のものを構築すれば、混乱を招くこれらの他の3つの機能を回避し、コア要件に焦点を当てることができます。」彼はチームに技術的負債を減らす時間を与えてくれます。彼は、プロジェクトに包括的な構造と組織をもたらします。彼は、チームが集まる会議を呼び出し、「どうすればもっと良いことができるのか」と尋ねる人です。

そして、彼はマスター要件文書を管理しています。

書籍「要求プロセスの習得」では、著者は3種類の顧客、3種類のソフトウェアプロジェクト、ウサギ、馬、象があると主張しています。ウサギは、非公式の要件のみを必要とする小さなソフトウェアプロジェクトです。顧客と小さなスプリントで直接やり取りし、プロジェクトの範囲はかなり制限され、ソフトウェアは比較的短い時間枠内で完了します。ゾウは、多くの事前計画、膨大な量のドキュメント、および長い期間を必要とする巨大なプロジェクトです。これらはアジャイルではないことは間違いありませんが、アジャイルを使用してビルドできる小さなプロジェクトに分割できます。

アジャイルの観点からやや混乱しているのは、ホースのプロジェクトです。繰り返し構築することもできますし、短いスプリントを使用することもできますが、要件の収集と計画プロセスにある程度の規律がなければ、簡単に実行できます。これらは、統制された要件収集プロセスの恩恵を受けることができるプロジェクトであり、プロジェクト全体の包括的なビジョンを維持しながら、プロジェクトの成長に応じてそれらの要件を慎重に調整および変更します。

個人的な観点から、私は約12人の開発者から成る小さなチームで働いています。いつでも、数千行のコードから100,000を超える3つのソフトウェアプロジェクトに同時に取り組んでいる可能性があります。私たちの顧客はウサギだと思っていますが、彼らは本当に馬です。顧客は関与していますが、毎日ではありません。

私たちの最も弱い分野は、特定のテスト可能な測定可能な要件を収集し、プロジェクトの範囲に関連する顧客の期待を管理することです。しかし、私たちはそれに取り組んでいます。

問題は完全に明確ではありませんが、要件のトレーサビリティに関心があるようです。私の経験では、アジャイルで迷子になりがちなアイデアの1つは、ビジネス要件は顧客がシステムに求めていることであり、ユーザーストーリーはシステムの仕組みを示す実際の機能要件であるということです。「ユーザーとして、私はXになりたい」ただし、それは要件を満たすために行われ、ユーザーストーリーでは失われる可能性があります。

私の経験でうまくいくのは、ビジネス要件とユーザーストーリーを双方向にリンクすることです。BR＃1は、ストーリーAとBによって実現されます。ストーリーCは、BR＃2と＃3をカバーします。これを、プロジェクトトラッカー、スプレッドシートなど、使用しているものに入れます。

長期的には、これは顧客が求めているもの（BR）とシステムが行うこと（ストーリー）をリンクして、これらの要件を達成するのに役立ちます。これは、維持するのが面倒ではない、最小限のドキュメントである必要があります。

また、新しいプロジェクトメンバーが、ソフトウェアが何をするのかという歴史の背後にある歴史を知るためにレビューするものがあるため、スピードを上げる方法を提供します。

私は実際に、元の開発者がもう利用できない大きなウェブショップのかんばんメンテナンスプロジェクトで働いています。

すべてのuserstory / requirement / bugfixにはチケット番号があり、すべてのsourcecode-changeはsourcecontrol-comment-fieldのチケット番号にリンクされています。

sourcecontrol-checkin-s（svn）は、対応するチケットを原子的に更新するため、チケットにはすべてのsourceconrtol-changesetsへのリンクがあります。

モジュール/関数が新たに実装された場合、ソースコードにもチケット番号があります。

チケットシステム（redmine）では、チケットは相互にリンクされています（重複、バグ、洗練、...）

そのため、チケットをフォローして、時間の経過に伴う要件の変更を確認できます。

例：「orderConfirmation-Web-page」で何かを変更する必要があります。ページのソースコードには、「＃4711」用に作成されたコメントが表示されるため、新しいチケットを古いチケット「4711」またはその後続の1つにリンクできます。

個人的には、システムができることに関するドキュメントのソースとしてユーザーストーリーを破棄します。文書を作成するための積極的な手順が取られていない限り（従来のクライアントの一部に対して行ってきました）、アプリケーションベースは本当に最高の文書です。

しかし、それは新しいことではありません。

（SAFeのような）より拡張されたバージョンのアジャイルを使用している場合、実装バックログではない他のバックログがあります。基本的には次のようになります。

1. ポートフォリオバックログ（叙事詩と予算の戦略的計画）
2. プログラム/リリースバックログ（機能とエピック）
3. プロジェクト/チームバックログ（ストーリー、スパイク、バグ）

チームバックログレベルで文書化することはお勧めしません。細かすぎて、その詳細レベルに行きたがる人はめったにいません。リリース内には、チームバックログの以前のストーリーと矛盾するストーリーが存在する可能性があることは言うまでもありません。

代わりに、リリースバックログレベルで作業して、リリースレベルのドキュメントを提供することをお勧めします。これらのストーリーは、特定のリリースに割り当てられるとめったに吹き飛ばされることはほとんどなく、特定のリリース内で作業中の内容を確認するための安定した迅速な方法になります。