ストーリーごとに要件仕様を作成するのは良い考えですか？
現在、私の現在のプロジェクトではアジャイルメソッドを使用しており、次のような多くのストーリーがあります。
アシスタントとして、お客様に払い戻しを依頼して、要求時にお金をもらうことができるようにしたい
顧客として、私はアイテムを受け取ることができるように購入の代金を支払いたいです。
これまでに行った方法は、すべてのスプリントで最も重要なストーリーを選択し、それをいくつかの正式な要件仕様にまとめることです（同じ仕様で似ているストーリーのいくつかをグループ化します）。ストーリーによっては、画面上のボタンまたはワークフロー全体の場合もあります。
問題は、ストーリーが多すぎるため、システムのどの部分にストーリーが関連しているかがすぐには明らかにならないことです。
それは開発者の時に機能し、すべてのスプリントは開発者が何をする必要があるか、そして彼らが行う必要がある変更を概説するスペックを得るだけです。ただし、このストーリーリストの維持とテストに関しては、バグの追跡が非常に困難になり、一般的には仕様のみを維持することになります。これは、画面の機能の一部が、ストーリーで分割。
ストーリーに基づいた仕様を書くことは良い考えですか？ストーリーを間違った方法で書きましたか？
これは物議を醸すかもしれませんが、ここに行きます！
私たちはリアルタイムシステムに取り組んできましたが、私の過去のボスの1人がアジャイルをやろうと提案しました！その上で管理を勝ち取るのは本当に簡単でした。しかし、それは言うより簡単でした。
ストーリーのコンセプトは良いですが、非常に前向きであるとは、かなりあいまいです。ストーリーとは、本当に？実際の問題は、ストーリーalone（およびユースケースでもほぼ同じ）を使用すると、次のようないくつかの問題が発生することです。
要件がコンテキスト外になることはありません（非常に多くの繰り返しを何度も行っている場合を除きます）。特定の要件にも関連している前提条件、背景知識、およびその他の要件があります。これらは、コンテキストの下でのみ、特定の順序の下でのみ意味があります。 最も重要なものを最初に実装することはビジネス上理にかなっています少なくともそれらを提出するとき-収集するときは最初から完全な参照を維持してください。要件の単語自体は複雑で、ユースケース/ストーリーに限定されません。実際、ストーリーは実用的ですが、パフォーマンス、満たすべき制約、ビジネスルールなど、実用的でない可能性のある要件があります。
要件は、サイズと数量化可能な方法で適切である必要がありますさもなければ、複数の大きなストーリーが必要になることは決してありません！正確に1つのストーリーを形成するものは何ですか？
- それは1つの完全な詳細シナリオですか？（たとえば、ATMがトランザクションを拒否したときの1つのストーリー）
- それは、ユーザーが実行する一連のアクションですか？（例：引き出しに関する詳細なストーリー）
- それはユーザーインターフェースの1つの画面ですか？（例：完全なストーリーとしての引き出し画面）.
- ストーリーを使用して、非常にくっきりとしたビジネスルールを実際にどのように数量化しますか？正直なところ、それは上記のいずれかになります。重要なのは、どれだけ細かく閉じ込められるかは、かなり個人的なスタイルです。それが動作する場合-それは問題ありません。
ドメインの知識これは実際に必要です！知っているアーキテクトの簡単な例ガラス、鋼、木材のさまざまな特性。この知識は、言うまでもなく建物の要件ドキュメントの一部ではありません。同じように、あなたが銀行ソフトウェアを書いているなら-銀行についての概念はたくさんあります。 要件自体として扱いにくいので、ではなく、[////]ソフトウェアが何をすべきか世界の仕組み。ストーリーにはそのような複雑な領域が含まれていますか？それともこれを除外しますか？
世界のモデリングは前提条件として完全にはサポートされていません。
世界がどのように機能するかを理解することに焦点を当てたモデリングに関する多くの文献が背景知識です。モデリングは、要件が明確な意味を持つための確固たる基盤を形成します。ただし、そのようなことは前もって行う必要があります。残念ながら、ほとんどのアジャイルプラクティスでは、より迅速で無駄のないデリバリーのために、先行モデリングの価値を拒否しています。しかし、物事がスケールしなければならないとき、私はまだそれが主要なショーストッパーであると思います。多くのプロジェクトは、モデリングが無関係であるために成功するわけではありませんが、熟練したエンジニアは頭の中でそれらを知っており、あまり明確なガイダンスを必要としません。
だからあなたの質問に来る：
ストーリーに基づいた仕様を書くことは良い考えですか？ストーリーを間違った方法で書きましたか？
ユーザーストーリーは、お客様からの明確な判断として価値があると思います。しかし、それらが不十分に構成されていて、詳細が不十分（またはあいまい）である場合、問題があります。より広い理解（ドメインの知識）とスコープ（全体の仕様）を蓄積するためのより大きな構造がない限り。より大きなこのようなシステム内のセグメントまたは要素のみのユーザーストーリー。
PS：私はユースケースについて正確な意見を持っています（楕円形の図に示されているように）。適切なコンテキストと適切な粒度でそれらを配置しない限り、それらは良い仕事をしません。 （私はそれらを役に立たないケースと呼びます）。ユースケースの記述を本当にスケーラブルで意味のあるものにするために私が見つけた唯一の信頼できるソースは 効果的なユースケースの記述Cockburn です。
この回答を書いている時点で、私はそれがテストに関するものではなく、ドキュメントに関するものであることに気づきました。まず アジャイルマニフェスト を読んでください：
[私たちが重視すること]包括的なソフトウェアよりも機能するソフトウェア
したがって、仕様を実行可能にする必要があります。つまり、仕様を完全に自動化されたテストのセットとして記述します。
ストーリーに基づいた仕様を書くことは良い考えですか？
はい、私見です。 「振る舞い主導の開発」または「例による仕様」と呼ばれています。 Rubyには、すばらしいツール cucumber があります。
問題は、ストーリーが多すぎるため、システムのどの部分にストーリーが関連しているかがすぐには明らかにならないことです。
なぜそれをはっきりさせたいのですか？つまり、「テスト/コード」のトレーサビリティマトリックスが本当に必要なのでしょうか。テストを仕様として作成する利点は、テストが要件になるため、個別の「要件/テスト」のトレーサビリティが不要になることです。統合テストの目的では、ソフトウェアを個別の部分としてではなく、全体として扱う必要があります。
仕様テストでカバーされていないシステムの一部である「デッド」モジュールがあるかどうかを確認するには、カバレッジツールが必要になる場合があります。しかし、この特定のコードがどの仕様に対応するかを気にする必要はありません。特定の仕様から、システムのどの部分がそれに対応するかを知る必要があります。仕様の重複を心配する必要はありません。そして、もしあなたのコードに [〜＃〜] dry [〜＃〜] 原則を適用すると、同じコードを実行する何十ものスペックが存在するでしょう。
それは開発者の時に機能し、すべてのスプリントは開発者が何をする必要があるか、そして彼らが行う必要がある変更を概説するスペックを得るだけです。ただし、このストーリーリストの維持とテストに関しては、バグの追跡が非常に困難になり、一般的には仕様のみを維持することになります。これは、画面の機能の一部が、ストーリーで分割。
重要なモジュールの1つの小さな変更によって何百もの統合テストが失敗することは珍しいことではありません。ユニットテストのステップです。
特定のテストが高レベルの要件をカバーしているか、またはその微妙な詳細のみをカバーしているかがわかるように、テストをそのように構成する必要があります。後者の場合、このテストを統合テストスイートから分離する必要があります。単体テストの目的は、バグを特定することです。そのため、バグが発生した場合、テストは1つだけ失敗します。
ストーリーを間違った方法で書きましたか？
私は、ユーザーごとにストーリーをエピックに編成する必要があると思います。 「お客様」、「アシスタント」、または機能/画面/ワークフロー別（「購入」、「払い戻し」）。
また、仕様テストは単体テストの代わりにはなりません。 続きを読む
> Writing specs by stories? a good idea?
はいストーリーの相互依存性と優先度を管理できる場合。
これは、ストーリーマップに関する記事で、多くのユーザーストーリーの注文と管理に役立ちます。
問題とその解決方法について説明しましたが、仕様とグループ化のいくつかの例、およびそれが製品の開発方法とどのように関連しているかを忘れてしまいました。
ストーリーで仕様を書いていますか？いいアイデア？
アジャイルはそれを禁止しません。アジャイルでは、持続可能なペースで最大のビジネス価値を提供するために必要なことをすべて実行できます。ですから、仕様を書くことがより多くのビジネス価値を提供する必要がある場合、それを行うことは絶対に問題ありません。
あなたの例は2つのユーザーストーリーを示しています。それらはおそらくビジネスロジックに何らかの形で関連していますが、それは非常に一般的なシナリオです。
ユーザーストーリーに機能をバックトラックする必要がある場合は、ドキュメント、一部の図、または「仕様」など、最も適したものを再び使用できますが、開発したアプリケーションの複雑さが増すにつれて、これらのアーティファクトを維持するとコストが高くなることを覚悟する必要があります。したがって、この場合に答える必要がある唯一の質問は次のとおりです：スペックを使用しない場合、コストがかかりますか？答えが「はい」の場合、より良いオプションを選択します。
アジャイルは、チーム全体でアーキテクチャが共有されていて、チーム内で共有されている暗黙の知識として小規模から中規模のプロジェクトに最適です。反復計画では、選択したストーリーを調べ、現在の実装への影響について話し合い、ストーリーを完了するために必要ないくつかのタスクを記述します。そのような場合の実際のドキュメントは、自動受け入れおよび統合/ユニットテストを保持するテストスイートになります。 SWまたはチームが成長すると、暗黙の知識は一部のドキュメントに部分的に移行する必要があります。
これが抽象化が大きな役割を果たす場所です。あなたは、関連する視点に関してストーリーを見る必要があります。ステートメント内の名詞およびverbsを収集し、それらを確認します。 モデルを個人的な仮定に基づくことはできません。また、詳細にも注意してください。
ユーザーストーリーに基づいた仕様の記述は正確ではありません。あなたは余分な詳細を掘る必要があり、時には関係のない詳細を無視する必要があります。仕様は、モデルが完成し、アナリストの確認時に正確になったときに作成する必要があります。