ユーザーストーリーが要件を含まず（カードに記述されている場合）、実装可能である方法

「ユーザーストーリーは要件ではなく、顧客が望むものを思い出させるだけであり、ストーリー内に要件を置くことはできません」と言われました。しかし、顧客がクレジットカードごとに異なる処理を望んでいる例を見てみましょう。テストケースを作成できるように、実装する必要のある厳密な要件があります。ユーザーストーリーにない場合、要件はどこに行くべきですか？

より低い要件がない場合、開発者はストーリーからどのように開発できますか？テスターはユーザーストーリーに基づいてテストケース（詳細なケース）をどのように作成できますか？DB制約、フィールドの検証などの要件は、ユーザーストーリーの外側にありますか？

この回答では、ユーザーストーリーとより低いレベルの要件を扱う方法に焦点を当てます。スクラムやアジャイルの美徳やその欠如については議論しません。グルについても話しません。

この回答は、あなたがスクラムに参加しているが、それをあなたのために機能させる方法をまだ見つけていないことを前提としています。

他の人が述べたように、ユーザーストーリーは、ユーザーがソフトウェアをどのようにしたいかをカバーすることを目的としています。ユーザーはデータベーステーブル、制約、アーキテクチャパターンなどの低レベルの実装を気にしないため、ユーザーストーリーにはそのような詳細はありません。

ただし、これらの詳細をどこにも記録してはいけないという意味ではありません。

開発者がユーザーストーリーを実装する場合、一般的なユーザーが知らない下位レベルの詳細を認識する必要があります。この情報は、SME、BA、プロダクトオーナー、あなたのアーキテクト、または他の専門家や技術的な人から得られます。

これは、ユーザーストーリーに低レベルの詳細を記録する必要があるということですか？いいえ（そしてはい）。

ストーリーが作成されて実装されるまでのある時点で、誰かがそれを実装する方法を考え出す必要があります。これは通常、ストーリーに関係する人々（ユーザー、アーキテクト、開発者など）との会話という形をとります。これらの会話は、ユーザーストーリーの実装の範囲を明確に示す明確な受諾基準をもたらすはずです。これらの詳細はどこかに記録する必要があり、それは本当にあなた次第です。ここで重要なのは、これらの詳細がユーザーストーリーの作成後に引き出されることです。これがあなたの第一人者が強調しようとしていることだと思います。

開発者として、より具体的な要件をユーザーストーリーに関連付ける方法が必要であることは明らかです。それをどのように行うかは、チーム次第です。

チームのメンバーがこれらの詳細をユーザーストーリーに残したくない場合は、それを尊重する必要があります。高レベルのユーザーストーリーを実装の詳細から解放することには利点があります。それは彼らを無駄にせず、あなたのバックログはあなたのユーザーとプロダクトオーナーが望んだものの歴史として読むことができます。開発者としてのニーズも知っておいてください。ユーザーストーリーにリンクするだけで誰もが満足できる妥協案を作成できるはずです。

うん、BS。そしてスクラムはアジャイルではありません。

私は、アジャイルを行う1つの方法があり、使用する「アジャイル」方法論の聖典に記載されているすべてのルールに従う必要があることを伝える、いわゆるアジャイル実践者の硬直性を嫌います。そのすべてのBS。

アジャイルとは、アジャイルであることです。

アジャイルは、最小限のオーバーヘッドで作業を完了することです。これは「ドキュメントなし」という意味ではなく、通常はアジャイルな役割でドキュメントを作成することになるため、ドキュメントを作成するプロセスを計画することなくドキュメントを作成するだけです。同様に、コーディング、テスト、および要件のキャプチャ。アジャイルプロセスで重要なのは、BSなしで迅速かつ効率的に仕事を遂行できるようにすることだけです。

したがって、この場合、ユーザー要件をカードに入れると、必要なコードを記述、テスト、文書化、実証することができます...要件をカードに入れて、チームが常に正しいことを指導者に伝えます。

開発チームの残りの人はどう思いますか？真のアジャイル方法論では、「ユーザーとの会話」なしに要件を前もって記述する必要があると考えている場合、それはそれであるはずです。ユーザーの会話が良いことだとチームが考えている場合は、彼らの話を聞いて、なぜ彼らがこれを考え、自分の仕事のやり方に自分自身を持ち込むのかを理解してください。

これをユーザーストーリーとは呼ばないでください。誰もが幸せになります。

答えは、どこにいてもこれを書き留めることができると思います。

一般的に、いくつかの理由により、特定の実装はユーザーストーリーに含まれません。

1. 顧客が何を望んでいるかは知っていますが、どのように実装されるのかはわかりません。
2. 顧客は、より具体的な要件が関係していることを知っていますが、とにかくそれらを気にかけたり、理解したりしません。
3. 現時点では、特定の実装を完全に認識していると誰もが思っていますが、経験上、とにかくすべてが変更され、誰もそれを書き直したくないので、誰もそれらを書き留めたくありません。

必要に応じて追加のドキュメントを省略するルールはありません。クライアントがアクセスする必要があるかもしれませんし、そうでないかもしれません。特定の実装について、あなたが従うことができるかのように、あなたとクライアントとの間に何らかの契約を生成したい場合、それがうまくいかないとき、クライアントがそれに同意したことを責めると、あなたは間違っています。クライアントがクレジットカード処理の技術的な詳細を理解している場合は、これらのドキュメントをクライアントと共有し、場合によっては会話の一部にする必要があります。

スクラムコンサルタントがあなたに言っていることは、スクラムは要件を必要としないということなら、非常に貧弱なコンサルタントがいると思います。ユーザーストーリーは実際には要件ではなく、たまたま要件の1つであると言うのは間違っています。

さまざまな種類のソフトウェア要件は何ですか？

ビジネス要件

これらは一般に高レベルのビジネスニーズであり、一般的にはシステムに関するある種のエグゼクティブスタイルの声明に相当します。それは意図的に高レベルで幅広く、それ自体は非常に詳細にせずに実装することはできません。

ユーザー要件

これらは、あなたがよく知っているユーザーストーリーの要件です。彼らは一般的に付箋紙に収まることができます。

• アクター-通常はユーザーまたは利害関係者。
• 必要-ユーザーが必要とするアイテムまたは一般的な機能
• 理由-この必要性が存在する理由または背景
• 受け入れ基準-これは、ユーザー受け入れテストのフレームワークであり、スプリントデモ中に、プロダクトオーナーがユーザーストーリーを受け入れるかどうかを決定する方法です。

機能要件またはシステム要件

これはあなたのパズルの欠けている部分のようです。機能レベルの要件は、ユーザーレベルの要件に基づいて、システムレベルのアクターとシステムのプロパティ、およびシステムの動作と機能を定義します。これは、ストーリー形式で実行し、バックログに含めることもできます。これらの項目は独立している必要があり、1つのユーザー要件とは無関係に実装できます。

• アクター-何らかのシステムまたはコンポーネント。
• ニーズ-存在する必要があるシステムのニーズ、プロパティ、または動作のステートメント。
• 理由-システムでこれが必要な理由の背景
• 受け入れ基準-システムおよび統合テストの実行方法を伝達するために必要なシナリオ、動作、機能、およびフロー。要件に対してこれらのタイプのテストに合格すると、この機能要件が完了したことがわかります。これらは、ユーザーストーリーの外部ドキュメントに存在する可能性がありますが、スプリントでこれらのストーリーを割り当てる前に完了する必要があります。

機能要件はソリューションを定義するもので、プロセスのギャップとして説明しているように聞こえます。

言及する必要があるが、あなたの質問には重要ではない重要な要件タイプ：非機能要件、技術要件など

ユーザーストーリーは、ユーザーがシステムに期待するインターフェイスを説明することを目的とした特定の種類の人工物であり、低レベルの詳細が単にそこに属さない理由です。それらをそこに置くと、アーティファクトの意図を変えていることになり、米国の定義に適合しなくなります。

他の形式の仕様を使用して、低レベルの要件と設計上の決定をキャプチャします。これらの他の形式は、組織で解決し、特定の環境に合わせてカスタマイズする必要があるものです。

あなたの質問は次のようなものに非常に似ています

私にはこのCarFactoryがあり、自転車も作る必要がありますが、私たちのOOD "Guru"はそれを許可されていないと言います。このBSとは！？！

懸念事項の分離と、アーティファクトの凝集性を尊重します。コード内のものとプロセス内のものの両方です。

このアプローチの目的は、ユーザーのストーリーを制約することではなく、悪い要件を防ぐことだと思います。

私の経験では、ユーザーは一般的に要件を書くことができません。通常、開発者は要件を記述できません。ちょっと、それをまっすぐに認めましょう：要件を書くのは難しいです！

ユーザーがユースストーリーの一部として要件の用語で何かを書くことは有効だと思います。ただし、そうすることで自動的に要件になるわけではありません。 2つの相反する使用事例があることは小さな問題です。2つの矛盾する要件があることは、契約を破る大きな問題です。 その時代の前に一方を他方に促進する意味はありません。

過酷な視点は、人間性の認識から来ていると思います。ユーザーストーリーが要件を置く場所であると考えるようになったら、そうし始めます。情報などの要件を収集する他の手段よりもストーリーを使用することの本当の利点は、ストーリーがユーザーの自然な表現や表記で表現されることです。これにより、開発者が顧客の観点から考えている可能性が高くなります。完璧な世界では、寒さの要件の専門用語もそこに行くことができます。実際、このような言葉は、開発者が理解しやすい要件を把握し、アジャイル開発がユースストーリーを使用して発掘したい微妙な表現やニュアンスを見逃す傾向があります。

独自の決定を下す

「それでは、より低い要件がなければ、開発者は実際にどのようにストーリーを開発できるのでしょうか？」に対する答え。エンドユーザーのニーズに直交する詳細な要件（DB制約、フィールド検証など）は実際にはユーザーにとって重要ではありません。ユーザーのニーズが非常に異なるフィールド検証、非常に異なるDB構造、またはおそらく従来のDBで満たされない場合は、特定の実装を念頭に置いてユーザーにそのような情報を作成させることは逆効果です。システムの最終的な実装方法とは異なります。

あなたはプロの開発者であるため、実装の詳細について可能な限り専門的な決定を下してください。テーブルが必要なユーザーは、大工に自分が望む木材の種類を伝えることができますが、大工は、適切な荷重を処理するためにテーブルの脚の厚さを決定する必要があります。有意義な決定を下すための情報が不足している場合は、ユーザーと話し合う必要がありますが、詳細な要件ドキュメントのコンテンツの約90％は、漠然としたユーザーストーリーの常識と業界のベストプラクティス以外の情報を実際に必要としません。

これらの詳細はすべてarbitrary意的ではありません-悪い選択とより良い選択があり、実装の他の部分に影響を与えるため、文書化する必要がありますが、最終的には実装チームが決定できる実装の詳細ですユーザーのニーズとベストプラクティスへ。

標準的な自動車の例えだ-顧客が自動車を赤く塗装したい場合、ユーザーストーリーの適切な説明は、赤の色合いの方が良いかどうかを尋ねることですが、塗料の化学組成は違います。それにもかかわらず、雨で洗い流される水彩画で車を塗ることを選択しないことが期待されます。そうしないことがベストプラクティスです。

TL; DR

ユーザーストーリーは、製品に追加する価値とその理由を文書化するためのものです。実装の詳細は、（たとえば、どのように値を追加、テスト、測定、または検証する必要があります）物語によって制約されているが、それらの中に含まれていません。これらは、フレームワーク内の柔軟性と俊敏性を維持するために、意図的に別個のアーティファクトとして残されています。

仕様と実装の詳細は、受け入れテスト駆動開発（ATDD）、テスト駆動開発（TDD）、および行動駆動開発（BDD）のスクリプトやシナリオなど、他の成果物に最もよく取り込まれます。これらの特定のアーティファクトはスクラムフレームワークによって必須ではありませんが、他の効果的なプロセスコントロールがまだ整っていない場合、確かに良い出発点となります。

ユーザーストーリーは仕様ではありません

元のポスター（OP）は次の質問をしました：

[A]顧客はクレジットカードごとに異なる処理を希望しているため、テストケースを作成できるように実装および既知の厳しい要件があります。

ユーザーストーリーは、ある機能の実現値を、いくつか提供してコンテキスト実装についての会話を案内する、とに縛ら視点値の消費者機能によってもたらされる価値の恩恵を受ける。

全体のポイントユーザーストーリーの実装の詳細は規範的ではないということです。チームは、識別された価値を適切なコンテキスト内で価値のある消費者に提供する方法で、この機能を自由に実装できます。

実例

サンプルユーザーストーリー

これは、曖昧さの少ないユーザーストーリーのセットから始める方が簡単に説明できます。OPはINVESTニーモニックに続く実用的なユーザーストーリーを提供しなかったため、例のために1つを発明します。次の話を考えてください：

Discoverカードで支払うこと
を希望するユーザーとして、
Visa、Mastercard、American Expressに限定されないように、Discoverカードで購入するオプションを希望します。

これは、具体的な機能を提供し、チームが行う必要がある実装の決定を導くことができるコンテキストを提供し、価値消費者をディスカバーカード所有顧客として識別します。それは一連の仕様ではありませんが、開発の反復中にストーリーを実装する最善の方法について、顧客やチームと適切な会話をするために必要なものです。

分析と実装

実際の実装はチーム次第です。チームは、以下を判断するためにいくつかの分析を行う必要があります。

• 新しい機能を実装する最も簡単な方法。
• 技術的な負債を計上することなく、今後のサポートが最も簡単な実装オプションはどれですか。
• オープンフィーチャとYAGNIの原則を適用して、過剰な設計をせずに新しい機能を堅牢にする方法。

アジャイルマニフェストの中核となる原則の1つは、顧客とのコラボレーションです。機能横断的な自己組織化チームは、ユーザーストーリーで提供されるガイドラインの範囲内で実装の詳細を決定するために顧客と協力できることが期待されています。

ユーザーストーリーが適切に記述されていない場合、またはチームがアジャイルフレームワークに必要な十分な分析を行うためのスキルやプロセスの成熟度を持たない場合、これは明らかに必要以上に困難になります。適切なレベルの粒度で優れたユーザーストーリーを作成する方法をテーマに、本全体が書かれています。残念ながら特効薬はありませんが、アジャイルチームにとって学習可能なスキルです。

テスト駆動設計および動作駆動設計

分析が適切であり、実装が健全でサポート可能であることを保証する最良の方法は、TDDおよびBDDプラクティスを使用することです。たとえば、上記のストーリーを考えると、チームは次のような成果物を通じて計画された実装をキャプチャする必要があります。

• テスト可能なシナリオを備えたキュウリの機能。

  これは、受け入れテストの開発を促進し、アプリケーションの動作に対するユーザーの期待を文書化するのに最も役立ちます。たとえば、ユーザーストーリーには、ユーザーがDiscoverカードでどのようにチェックアウトできるか、およびそのプロセスがどのように見えるかを説明する1つ以上の関連するCucumber機能が必要です。

• 新しいコード機能の動作（内部実装の詳細ではなく）を検証するRSpecテスト。

  これは、アプリケーション内の機能の意図された動作を文書化および検証するのに最も役立ちます。たとえば、ユーザーストーリーは、Discoverカードを使用すると、支払いゲートウェイを介した販売を承認するためにアプリケーションが必要とするカード固有の動作を呼び出すことを保証する単体テストと統合テストの作成を促進します。

特定のツールは関係ありません。CucumberやRSpecが気に入らない場合は、チームに最適なツールや方法を使用してください。ただし、実装の詳細はユーザーストーリーに基づいているが、それによって規定されていないという点がポイントです。代わりに、実装（または必要に応じて仕様）は、機能を共同で開発する際に細かく調整する必要があります。

ここにはたくさんの良い答えがあります。うまくいけば、別の値を追加できます...

チームが抱えているかもしれない問題の1つは、非アジャイル手法からの移行です。

これは通常、何らかのウォーターフォールの方法論であり、実際には、通常、コード行を記述する前にすべての技術要件を文書化することを試みます。

しかし、それは常に機能するとは限りません。多くの場合、機能しません。理由？要件が現実とほとんど一致しないためです。物事は変わります。したがって、アジャイルへの動き。

アジャイルを使用すると、ユーザーストーリーだけがユーザーの関心事になります。彼らはフォームポイントAからポイントBを取得したいと考えています。実装の観点からそこに到達する方法はあなたの手にあります。誰かが技術的な要件を教えてくれるのを待っているなら、それは本当にアジャイルではありません。ご質問がある場合は、お問い合わせください。文書が必要な場合は文書化しますが、顧客がこれらの決定をすべてあなたに代わって欲しくないのです。彼らは意見を持っているかもしれませんが、アジャイル環境ではそれらの意見は（あなたの第一人者が示唆しているように）会話の中で議論されるべきです。

これはあなたのチームの負担であると感じるかもしれませんが、それは贅沢だと考えてください。あなたのチームは現在、ソリューションについて多くの意見を持っています。これは、必ずしもウォーターフォールモデルの場合ではありませんでした。