アジャイルチームの要件ドキュメントをどのように追跡しますか？
ユーザーストーリーがアジャイルの世界を支配していることを理解していますが、これらのアーティファクトはどのように保存されるので、チームに参加する新しい開発者は要件に迅速に対応できますか？
ユーザーストーリーが後で変更された場合、それはどのように更新され、アーティファクトとして保持されますか？多くのチームが、元のストーリーを追跡するのではなく、新しいチケット/機能リクエスト/バグレポートを開くだけだと思っています。
まず、@ DXMの答えのほとんどが、アジャイルでの私の経験と一致しません。
Agile Manifesto は、包括的なドキュメントは価値がある一方で、実用的なソフトウェアはより価値があると述べています。したがって、ドキュメントは確かに悪いことではありませんが、実際に機能するソフトウェアを作成するために役立つはずです。
プロセスとツール上の個人と相互作用
包括的なドキュメントを介して動作するソフトウェア
顧客とのコラボレーション契約交渉
計画に従った変更への対応
つまり、右側の項目には価値がありますが、左側の項目にはさらに価値があります。
コードを書き始める前に細部を徹底的に調査することは何度も無駄であることが判明しているため、ドキュメントは通常JIT（ジャストインタイム）で扱われます。つまり、実際にコーディングする内容を文書化します。
スクラムを行う一般的な方法の1つは、ユーザーストーリーを使用することです。ユーザーストーリーは、プロダクトオーナーによって管理され、プロダクトバックログに保持されます。プロダクトバックログは、ソリューションが実行する必要があるすべてのもののかなり高レベルのリストであり、ユーザーストーリーは、通常、リストの各項目を説明するための適切なサイズの方法です。ユーザーストーリーは必須ではありませんが、詳細をやりすぎず、代わりにコラボレーションを促すための良い方法のようです。
したがって、とにかく、ストーリーが完了すると、チームは受け入れ基準を満たすものを作成、テスト、および展開しますが、ストーリーはチャックされず、単にバックログで完了とマークされます-したがって、バックログには何らかの兆候があります各スプリントで何が行われたか、つまりストーリーとそれに関連付けられたポイント。これが速度の計算を可能にするものであり、それ自体が貴重な文書です。
そうは言っても、ユーザーストーリーは要件を理解するために必要なすべてのドキュメントかもしれませんが、より可能性が高いのは、顧客と開発チームの間の会話を生成するためのものです。そのため、その会話の周りにできることはいくつもあります。それが対面の場当たり的なものである場合、それはよくあることですが、アナリスト/開発者は、行われた決定を書き留めて、Wikiやドキュメントリポジトリ。メールの会話であれば、メールを保存できます。ホワイトボードセッションの場合は、携帯電話でボードの写真を撮って保存します。重要なのは、これらはコードを完成させるのに役立つものであり、方法や理由を自分のやり方で理解する必要がある場合に後で役立つ可能性があるということです。
要件を取得するもう1つの方法は、要件をテストケースにすぐに埋め込むことです（DXMが行っていたのはこの要件であると私は信じています）。とにかく各要件をテストする必要があるという点で、これは本当に効率的です。この場合、要件をテストツールに効果的に保存できます。
ストーリーが完成し、受け入れられた後、ユーザーが自分のニーズを変更した場合、おそらく新しいストーリーを作成する必要があります。ドキュメンテーションにWikiを使用する場合、新しいストーリーを元のストーリーにリンクし、同様に元のストーリーを新しいものにリンクして、それを見る人が変更があったことを知ることができます。これがWikiのいいところです。リンクするのは簡単で、かなり簡単です。テスト駆動アプローチを実行している場合、変更に対処するためにテストケースを更新するか、新旧が相互に排他的でない場合は、新しいストーリーの新しいテストケースを作成します。
最後に、それはあなたのニーズが何であるかに依存します。主なことは、人々が迅速に習熟することである場合、誰かが彼らを助けるためにオンボーディングドキュメントを書くことはおそらく良い考えです。だから誰かにそうしてもらいなさい。先ほど述べたように、Wikiはこの種のことを維持するための優れたツールであるため、検討するかもしれません アトラシアンのソリューション これは、Confluence WikiをJiraおよびGreenhopperと統合して、ストーリー/タスク/欠陥を追跡し、プロジェクト全般。他にもたくさんのツールから選択できます。
[update＃1]@MatthewFlynnが指摘したように、アジャイルや他の多くの（私の自身を含む）との彼の経験は、ここで提供しています。ここでの答えは、過去に自分のチームで何が機能し、何が機能しなかったかについての私の観察に基づいており、このテーマについて読んだ多くの本やブログと組み合わせています...
アジャイル開発への原動力のほとんどは、要件ドキュメントの排除を特に対象としています。
アジャイルはほとんどのドキュメントを排除しようとしますが、私はそれらのアイデアに同意しますが、すべてのドキュメントについて、要件ははるかに最大の雄牛の目で描かれています。その理由（IMO）は、要件ドキュメントが実際の作業コードおよびすべてのドキュメントから最も離れているためです。
- 最も正確でない
- 維持するのが最も難しい
- 最も役に立たない
次に開発するものについてチームを導くために、アジャイルは要件ドキュメントを、バックの最大の強打（現在と将来の両方）で最初に置かれる、次の優先順位の高いアイテムに取り組むべきものを特定するストーリーのバックログに置き換えます。そのリストで。
ただし、バックログを要件ドキュメントと混同しないでください。
- バックログでは、N個のストーリーだけに詳細を入力する必要があります。ストーリーが遠いほど、入力する詳細は少なくなります（つまり、半年間発生しないものを定義しようとして時間を無駄にしないでください）。 ）。
- 特定のポイントを超えると、「要件」アイテムは、2を超えるリリースサイクル（出荷可能増分（PSI）とも呼ばれます）を超えている場合、バックログに配置されるべきではありません。要件が重要である時点で完了しなければならないことがわかっている場合でも、それをバックログに追加する誘惑に抵抗してください。それが本当に重要な場合は、次のリリースで誰かが覚えているでしょう。誰もそれを覚えていない場合、おそらくそれは結局それほど重要ではなかったためです。
ストーリーが完了すると、そのストーリーはバックログから削除され、チャックされます（1）。繰り返しになりますが、ストーリーは必須ではありません。彼らはチームに次に何をすべきかを伝えるだけです。それらは歴史的な記録のためではありません。
ただし、適切なアジャイルプロセスでは、作業を提供するときはいつでも、その提供の一部はユニット/統合/受け入れテストでなければなりません。これらのテストには多くの目的があるため、非常に価値があります。完全なリストには入りませんが、それらの目的の1つは、現在の製品ソフトウェアのドキュメントです。
テストは、特定の入力と前提条件のセットが与えられた場合のソフトウェアの動作を文書化します。また、コードのパブリック（および内部）APIの使用方法についても説明します。また、セーフティネットとしても機能するため、新しい開発者がチームに入って不注意で何かを壊した場合、チェックインするとすぐにそのエラーがキャッチされます。
アジャイルプロセスは、自動化された単体テストを最大限に活用することを明らかに促進しますが、すべてのことを自動化できるわけではないことは誰もが知っています。ソフトウェアスイートには、常に手動で実行する必要がある一連のテストがあります。ただし、a）開発者は可能な限り自動化に積極的に取り組んでいる必要があり、b）QAチームは手動で一連のテストを定期的に実行して、機能の中断をできるだけ早く発見する必要があります。
（1） -「チャックされた」部分についていくつかの応答を得たので。アジャイルに移行してから5年間で、私のチームは1つのストーリーを捨てることはなく、スケジュールされたものの30％でさえ、延期されてから忘れられました。私の上司はそれらを「参照用に」保持したかったのですが、まだ誰もこれらの物語を見たことがありません。
人々は一般的にデータに執着しており、すでに持っているものを捨てるのは難しいと思いますが、手持ちの在庫を（物理的であれ、電気的であれ）手元に置いておくのは自由ではなく、考えれば考えるほど、同意します「チャッキング」。これは "アジャイルソフトウェア要件：チーム、プログラム、およびエンタープライズのリーン要件の実践"（p.190） -"ユーザーストーリーは実装後に安全に破棄できます。 、チームを友好的に保ち、交渉を促進しますが、受け入れテストはアプリケーションの存続期間中持続します...」
ユーザーストーリーが後で変更された場合、それはどのように更新され、アーティファクトとして保持されますか？多くのチームが、元のストーリーを追跡するのではなく、新しいチケット/機能リクエスト/バグレポートを開くだけだと思っています。
anyのドキュメントの管理は、アジャイルストーリーを使用しているか、大規模なフロントドキュメントを使用しているかに関係なく難しい場合がありますまた、負担を軽減するために、ドキュメントは最小限に抑え、テストと実装で行われている作業に合わせて段階的に更新する必要があります。しかしながら、OPが言及したように、単にドキュメントを更新することは、ソフトウェアが時間とともにどのように進化したかの履歴を失うリスクがあります。
これは本当に重要ですか？時々それはすることができます。ほとんどの場合、現時点ではテストとコード自体とともにストーリー/ UML /何でも表示したいだけですが、機能が特定の方法で実装された理由について質問が出された場合、機能が時間の経過とともにどのように変化したかを確認するために履歴を確認し、実装オプション[〜＃〜] x [〜＃〜]がオプション[〜＃〜] y [〜＃〜]の代わりに選択されました。
このようなアーティファクトを追跡するには、いくつかの方法があります。優れたオプションの1つは、ソースコードのバージョン管理と同様の方法でストーリーテキストをバージョン管理できるツールでストーリーを維持することです。 Wikiはこの点で非常に優れている傾向があり、同様に Trac または Redmine などのプロジェクト/問題管理ツールの一部も問題自体の変更履歴を保持します、およびこれらのシステム内のwikiページ。ただし、新しいストーリーや問題が古い関連する問題やストーリーに何らかの方法でリンクされるようにすることで、問題から機能への変更を追跡する機能を向上させるために、これをもう少し進めることができます。これは、古い問題/ストーリーIDを新しい問題/ストーリーのテキストに追加するのと同じくらい簡単ですが、バージョン管理システムへの変更をコミットするたびに、チェックインコメントに問題またはストーリーIDを含めることで大幅に改善できます。 。この方法は最大の価値がありますが、コミットが頻繁に行われ、1つのストーリーまたは問題に限定される場合に役立ちます。
もちろん、このタイプのアプローチでは、一貫性を保ち、コミットを小さく頻繁に維持し、ストーリーや問題/プロジェクト追跡システムを管理するチームが維持するために、すべてのチームメンバーによる注意とコミットメントが必要です。実装の現在の状態と以前に発生したすべての変更との間のリンクを提供するアーティファクトの上に。
それは以前に言われましたが、私はそれの要点はこれだと思います：
要件は多くの側面をカバーし、通常は複数のストーリーをもたらします。
ストーリーは、チームの作業をスプリントの時間境界内に収まるほど小さいチャンクで編成します。
多くの場合、特定の機能が正しく機能するために定義する必要のある多くの詳細があります。これは、これらの定義を個別の要件ドキュメントに保存しておくと便利になります。明確化、共通理解、および後で参照するためです。
伝説のオンラインペットショップの例を考えてみましょう。
- 物語は「ユーザーとして、私は領収書に印刷されたVATを見たい...」と言うかもしれません。現在、VAT（付加価値税）の計算は複雑な問題であり、このストーリーが示唆する以上の作業が必要になる可能性があります。
- VAT計算の実行を要求する追加のストーリーがあるかもしれません（たとえば、合計売上金額にVATレートを乗算します）。その計算のすべてのバリエーションを含めないでください。
- 最初に、チームは基本モジュールの提供に焦点を合わせます。たとえば、商品とその販売価格のリストを取得し、VAT額を返します。これは、スプリントの時間内にチームが達成できることです。
- VAT計算のすべての可能なケースをカバーするために、もっと多くのストーリーがあるでしょう。
- 多くの異なるVAT計算ルールを単一のスプリント全体にまたがって表示できるようにするには、VATを計算するためのさまざまな方法をすべてリストした個別の要件ドキュメントを保持することは理にかなっています。このドキュメントは、時間の経過とともに進化する可能性があります。実際、新しいセクションを追加することは、ストーリーの完了するタスクの一部になる可能性があります。
freemind を使用して、機能のリストを収集できます。それがどのように行われるか、 このチュートリアル （真ん中のどこか）を調べてください。
機能のリストを作成したら、ユーザーストーリーを作成します。これは、単純なテキストファイル、Word文書、または アジャイル管理ツール のような複雑なものを使用して実行できます。
ユーザーストーリーを終了すると、優先順位が付けられます。その後、ユーザーストーリーから、人々はタスクを作成し、タスクを実行してコードに実装します。
これはすべて、c＃プロジェクトが最初からどのように管理されているかを示しています アジャイルビデオキャストシリーズの秋 。