ストーリーごとに要件仕様を作成するのは良い考えですか？

現在、私の現在のプロジェクトではアジャイルメソッドを使用しており、次のような大量のストーリーがあります。

• アシスタントとして、お客様に払い戻しを請求し、リクエスト時にお金をもらうことができるようにしたい

• 顧客として、私はアイテムを受け取ることができるように購入の代金を支払いたいです。

これまでに行った方法は、すべてのスプリントで最も重要なストーリーを選択し、それをいくつかの正式な要件仕様にまとめます（同じ仕様で似ているストーリーのいくつかをグループ化します）。ストーリーによっては、画面上のボタンまたはワークフロー全体の場合もあります。

問題は、ストーリーが多すぎるため、システムのどの部分にストーリーが関連しているかがすぐには明らかにならないことです。

それは開発者の時に機能し、すべてのスプリントは開発者が何をする必要があるか、そして彼らが行う必要がある変更を概説するスペックを取得します。しかし、このストーリーリストの維持とテストに関しては、バグの追跡が非常に難しくなり、一般的には仕様のみを維持することになります。これは、画面の機能の一部がさまざまな場所で文書化されているためです。ストーリーで分割。

ストーリーに基づいた仕様を書くことは良い考えですか？ストーリーを間違った方法で書きましたか？

これは物議を醸すかもしれませんが、ここに行きます！

私たちはリアルタイムシステムに取り組んできましたが、私の過去のボスの1人がアジャイルをやろうと提案しました！その上で管理を勝ち取るのは本当に簡単でした。しかし、言うのは簡単でした。

ストーリーのコンセプトは良いです-しかし、非常に前もっていると、それはかなりあいまいです。ストーリーとは本当に何ですか？実際の問題は、ストーリーの使用alone（およびユースケースについてもほぼ同じ）には、次のようないくつかの問題があることです。

1. 要件は、コンテキストから外れることはできません（大規模な繰り返しを何度も行っている場合を除きます）。特定の要件にも関連している仮定、背景知識、およびその他の要件があります。これらは、コンテキストの下でのみ、特定の順序の下でのみ意味があります。最も重要なものを最初に実装することはビジネス上理にかなっていますが、少なくともそれらを提出するときは、収集するときに最初から完全な参照を維持してください。要件の単語自体は複雑であり、ユースケース/ストーリーに限定されません。実際、ストーリーは実用的ですが、パフォーマンス、満たすべき制約、ビジネスルールなど、実用的でない可能性のある要件があります。

2. 要件は、サイズと数量化可能な方法で適切で ある必要があります。そうしないと、複数の大きなストーリーが必要になることはありません。正確に1つのストーリーを形成するものは何ですか？

   • 1つの完全な詳細シナリオですか？（例：ATMが取引を拒否したときの1つのストーリー）
   • ユーザーが実行する一連のアクションですか？（例：離脱に関する全文）
   • それとも、ユーザーインターフェイスの1つの画面ですか。（例えば、完全な話としての撤退画面）。
   • ストーリーを使用して、非常に明確なビジネスルールを実際にどのように数量化しますか 正直なところ、それは上記のどれでもかまいません。重要なのは、どれだけ細かく閉じ込められるかは、かなり個人的なスタイルです。それが動作する場合-それは問題ありません。

3. ドメインの知識は本当に必要です！ガラス、鋼、木材のさまざまな特性 を知っている建築家の簡単な例。この知識は、言うまでもなく、建物の要件ドキュメントの一部ではありません。同じように、あなたが銀行ソフトウェアを書いているなら-銀行に関する概念はたくさんあります。要件自体は、世界がどのように機能するかとは対照的に、ソフトウェアが何をすべきかを教えていないので扱いにくいものにするので、それらを述べてください。ストーリーにはそのような複雑な領域が含まれていますか？それともこれを除外しますか？

4. 世界をモデル化することは、まったくサポートされていない前提条件です。
   世界がどのように機能するかを理解することに焦点を当てたモデリングに関する多くの文献が背景知識です。モデリングは、要件が明確な意味を得る確固とした基盤を形成します。ただし、そのようなことは前もって行う必要があります。残念ながら、ほとんどのアジャイルプラクティスでは、より迅速で無駄のないデリバリーのために、先行モデリングの価値を拒否しています。しかし、物事がスケールしなければならないとき、私はまだそれが主要なショーのストッパーであると思います。多くのプロジェクトは、モデリングが無関係であるために成功するわけではありませんが、熟練したエンジニアは頭の中でそれらを知っており、あまり明確なガイダンスを必要としません。

だからあなたの質問に来る：

ストーリーに基づいた仕様を書くことは良い考えですか？ストーリーを間違った方法で書きましたか？

ユーザーストーリーには、お客様からの明確な判断としての価値があると思います。しかし、それらが不十分に構成されていて、詳細が不十分（またはあいまい）である場合、問題があります。より広い理解（ドメインの知識）とスコープ（全体の仕様）を蓄積するためのより大きな構造がない限り。より大きなこのようなシステム内のセグメントまたは要素のみのユーザーストーリー。

PS：私は（楕円形の図に示されているように）ユースケースについて正確な意見を持っています。（私はそれらを無駄なケースと呼んでいます）。ユースケースの記述を本当にスケーラブルで意味のあるものにするために私が見つけた唯一の信頼できるソースは、Cockburnによる効果的なユースケースの記述です。

> Writing specs by stories? a good idea?

はい、あなたは相互依存性とあなたの物語の優先順位を管理することができます。

多くのユーザーストーリーを注文して管理するのに役立つストーリーマップに関する記事を次に示します。

この回答を書いている時点で、私はそれがテストではなく、ドキュメントに関するものであることに気づきました。最初にアジャイルマニフェストを読んでください：

[私たちは評価します] 包括的なドキュメントよりも実用的なソフトウェア

したがって、仕様を実行可能にする必要があります。つまり、仕様を完全に自動化された一連のテストとして記述します。

ストーリーに基づいた仕様を書くことは良い考えですか？

はい、私見です。「振る舞い主導の開発」または「例による仕様」と呼ばれています。ルビーには、その点で非常に役立つ素晴らしいツールキュウリがあります。

問題は、ストーリーが多すぎるため、システムのどの部分にストーリーが関連しているかがすぐには明らかにならないことです。

なぜそれをはっきりさせたいのですか？つまり、「テスト/コード」のトレーサビリティマトリックスが本当に必要なのでしょうか。テストを仕様として作成する利点は、テストが要件になるため、個別の「要件/テスト」のトレーサビリティが不要になることです。統合テストの目的では、ソフトウェアを個別の部分としてではなく、全体として扱う必要があります。

仕様テストでカバーされていないシステムの一部である「デッド」モジュールがあるかどうかを確認するには、カバレッジツールが必要になる場合があります。しかし、この特定のコードがどの仕様に対応するかを気にする必要はありません。特定の仕様から、システムのどの部分がそれに対応するかを知る必要があります。仕様の重複を心配する必要はありません。また、DRYの原則をコードに適用すると、同じコードを実行する数十の仕様になります。

それは開発者の時に機能し、すべてのスプリントは開発者が何をする必要があるか、そして彼らが行う必要がある変更を概説するスペックを取得します。しかし、このストーリーリストの維持とテストに関しては、バグの追跡が非常に難しくなり、一般的には仕様のみを維持することになります。これは、画面の機能の一部がさまざまな場所で文書化されているためです。ストーリーで分割。

重要なモジュールの1つの小さな変更によって何百もの統合テストが失敗することは珍しいことではありません。ユニットテストのステップです。

特定のテストが高レベルの要件をカバーしているか、またはその微妙な詳細をカバーしているかを判別できるように、テストをそのように構成する必要があります。後者の場合、このテストを統合テストスイートから分離する必要があります。単体テストの目的は、バグを特定することです。そのため、バグを導入した場合、テストは1つだけ失敗します。

ストーリーを間違った方法で書きましたか？

ストーリーは、ユーザーごと、たとえば「顧客」、「アシスタント」、または機能/画面/ワークフロー（「購入」、「払い戻し」）のいずれかでエピックに整理する必要があるだけだと思います。

また、仕様テストはユニットテストの代わりにはなりません。続きを読む

あなたは問題とそれを解決する方法について述べましたが、仕様とグループ化のいくつかの例、およびそれが製品の開発方法とどのように関連しているかを忘れてしまいました。

ストーリーで仕様を書いていますか？いいアイデア？

アジャイルはそれを禁止しません。アジャイルでは、持続可能なペースで最大のビジネス価値を提供するために必要なことをすべて実行できます。ですから、もしスペックを書くことがあなたがより多くのビジネス価値を提供する必要があるものであるならば、それをすることは絶対に問題ありません。

あなたの例は2つのユーザーストーリーを示しています。それらはおそらくビジネスロジックに何らかの形で関連していますが、それは非常に一般的なシナリオです。

機能をユーザーストーリーに反映させる必要がある場合は、ドキュメント、一部の図、または「仕様」など、最も適したものを再び使用できますが、開発したアプリケーションの複雑さが増すにつれて、これらのアーティファクトを維持するとコストがかかることを覚悟しておく必要があります。したがって、この場合に答える必要がある唯一の質問は、次のとおりです。私の仕様を使用しない場合、それ以上の費用がかかりますか？答えが「はい」の場合、より良いオプションを選択しました。

アジャイルは、チーム全体でアーキテクチャが共有されていて、チーム内で共有されている暗黙の知識として小規模から中規模のプロジェクトに最適です。反復計画では、選択したストーリーを調べ、現在の実装への影響について話し合い、ストーリーを完了するために必要ないくつかのタスクを記述します。そのような場合の実際のドキュメントは、自動受け入れおよび統合/ユニットテストを保持するテストスイートになります。SWまたはチームが成長したら、暗黙の知識は一部のドキュメントに部分的に移行する必要があります。

これが抽象化が大きな役割を果たす場所です。あなたは、関連する視点に関してストーリーを見る必要があります。ステートメントに名詞と動詞を集めて確認します。モデルを個人的な仮定に基づくことはできません。詳細にも注意してください。

ユーザーストーリーに基づいた仕様の記述は正確ではありません。あなたは余分な詳細を掘る必要があり、時には関係のない詳細を無視する必要があります。仕様は、モデルが完成し、アナリストの確認時に正確になったときに作成する必要があります。