ユーザーストーリーに要件が含まれておらず（カードに書かれている場合）、まだ実装可能である方法
「ユーザーストーリーは要件ではなく、お客様が何を望んでいるかを思い出させるだけのものであり、ストーリー内に要件を置くことはできません」と言われました。しかし、顧客が異なるクレジットカードに対して異なる処理を望んでいる例を考えてみましょう。テストケースを作成できるように、実装および既知の厳密な要件があります。ユーザーストーリーにない場合、要件はどこにあるべきですか？
より低い要件がない場合、開発者はストーリーからどのように開発できますか？テスターはユーザーストーリーに基づいてテストケース（詳細なもの）をどのように作成できますか？ DB制約、フィールド検証などの要件は、ユーザーストーリーの外部にありますか？
この回答では、ユーザーストーリーと下位レベルの要件を扱う方法に焦点を当てます。スクラムまたはアジャイルの利点またはその欠如については説明しません。私はグルについても話しません。
この回答は、あなたがスクラムに参加しているが、それを機能させる方法をまだ見つけていないことを前提としています。
他の人が述べたように、ユーザーストーリーはsersがどのようにソフトウェアになりたいかをカバーすることを意図しています。ユーザーはデータベーステーブル、制約、アーキテクチャパターンなどの低レベルの実装に関することを気にしないので、ユーザーストーリーにはそのような詳細はありません。
ただし、これらの詳細がどこにも記録されるべきではないという意味ではありません。
開発者がユーザーストーリーを実装するときは、一般的なユーザーにはわからない下位レベルの詳細に注意する必要があります。この情報は、SME、BA、プロダクトオーナー、アーキテクト、またはその他の専門家や技術者からのものである可能性があります。
これは、低レベルの詳細をユーザーストーリーに記録する必要があることを意味しますか？いいえ（そしてはい）。
ストーリーが作成されて実装されるまでのある時点で、誰かがそれを実装するためにhowを考え出す必要があります。これは通常、ストーリーに関わる人々（ユーザー、アーキテクト、開発者など）との会話の形をとります。これらの会話は、明確なAcceptance Criteriaになるはずです。これにより、ユーザーストーリーの実装の範囲が明確になります。これらの詳細はどこかに記録する必要があり、それは実際にあなた次第です。ここで重要なのは、これらの詳細が引き出されることです後ユーザーストーリーが作成されました。これがあなたのguruが強調しようとしていることだと思います。
開発者として、より具体的な要件をユーザーストーリーに関連付ける方法が必要であることは明らかです。ちょうどhowそれを行うのは完全にチーム次第です。
チームの人々がこれらの詳細をユーザーストーリーに含めたくない場合は、それを尊重する必要があるかもしれません。高レベルのユーザーストーリーを実装の詳細から解放することにはメリットがあります。それはそれらを無駄のない状態に保ち、あなたのバックログはあなたのユーザーとプロダクトオーナーが望んだものの履歴として読むことができます。開発者としてのあなたのニーズも知らせてください。ユーザーストーリーへの単純なlinkingが全員を満足させる妥協案を解決できるはずです。
うん、そのBS。そして、スクラムはアジャイルではありません。
私は、アジャイルを行う1つの方法があり、彼らが使用する「アジャイル」方法論の聖典に記載されているすべてのルールに従う必要があることを伝える、いわゆるアジャイルプラクティショナーの厳格さを嫌います。そのすべてのBS。
アジャイルとは、アジャイルであることです。
アジャイルとは、最小限のオーバーヘッドで作業を行うことです。通常はより多くのドキュメントをアジャイルな役割で作成することになるため、これは「ドキュメントなし」を意味するのではなく、ドキュメントを作成するためのプロセスを計画する必要なく、ドキュメント作成に取り掛かります。同様に、コーディング、テスト、および要件の取得を行います。アジャイルプロセスで重要なのは、BSなしで迅速かつ効率的に仕事を遂行できるようにすることだけです。
したがって、この場合、ユーザー要件をカードに入れると、必要なコードを記述、テスト、文書化、および実証するのに役立ちます...要件をカードに入れて、チームが常に正しいことを教祖に伝えます。
開発チームの他のメンバーはどう思いますか？真のアジャイル方法論では、「ユーザーとの会話」なしで要件を前もって作成する必要があるとすべてのユーザーが考えれば、それがそれであるはずです。ユーザーの会話が良いことだとチームが考えている場合は、ユーザーの話を聞いて、なぜそう思っているのかを理解し、自分の仕事のやり方に自分を導いてください。
これをユーザーストーリーと呼ばないでください。そうすれば誰もが幸せになります。
答えは、好きな場所に書き留めることができると思います。
一般に、特定の実装はいくつかの理由でユーザーストーリーに含まれていません。
- あなたは顧客が何を望んでいるのか知っていますが、それがどのように実装されるのかは分かりません。
- お客様は、より具体的な要件があることを認識していますが、実際にはそれらを気にしなかったり、理解したりしません。
- 現時点では特定の実装を完全に認識していると誰もが思っていますが、経験上、すべてが変更され、誰もそれを書き直したくないため、誰もそれらを書き留めたくありません。
必要に応じて、追加のドキュメントを省略するルールはありません。たぶんクライアントはそれにアクセスする必要があり、そうでないかもしれません。あなたがそれに従うことができるかのように、特定の実装であなたとクライアントの間にある種の契約を生成することを望んでいて、それがうまくいかない場合、クライアントがそれに同意したと非難するのは間違いです。クライアントがクレジットカード処理の技術的詳細を理解している場合は、これらのドキュメントをクライアントと共有し、おそらくそれを会話の一部にする必要があります。
スクラムコンサルタントがあなたに言っているのは、スクラムは要件を必要としないということだとしたら、非常に貧しいコンサルタントがいると思います。ユーザーストーリーは実際には要件ではなく、たまたま一種の要件であることを伝えるのは誤りです。
ソフトウェア要件にはどのような種類がありますか？
ビジネス要件
これらは一般に高レベルのビジネスニーズであり、一般にシステムに関するある種のエグゼクティブスタイルの声明に相当するものです。それは意図的に高レベルで幅広いものであり、それだけでは、非常に詳細な情報なしに実装することはできません。
ユーザーの要件
これらは、よく知っているユーザーストーリーの要件です。彼らは一般的に付箋に収まることができます。
- Actor-通常、ユーザーまたは利害関係者。
- 必要-ユーザーが必要とするいくつかのアイテムまたは一般的な機能
- 理由-このニーズが存在する理由または背景
- 受け入れ基準-これは、ユーザー受け入れテストのフレームワークであり、スプリントデモ中に、プロダクトオーナーがユーザーストーリーが受け入れられるかどうかを決定する方法を示します。
機能またはシステム要件
これはあなたのパズルの欠けている部分のようです。ユーザーレベルの要件に基づいて、機能要件はシステムレベルのアクターとシステムのプロパティ、およびシステムの動作と機能を定義します。これはストーリー形式で行うこともでき、バックログに含めることができます。これらのアイテムはスタンドアロンである必要があり、1つのユーザー要件とは無関係に実装できます。
- Actor-ある種のシステムまたはコンポーネント。
- 必要-存在する必要があるシステムのニーズ、プロパティ、または動作のステートメント。
- 理由-システムでこれが必要な理由の背景
- 承認基準-システムおよび統合テストの実行方法を伝達するために必要なシナリオ、動作、機能、およびフロー。要件に対してこれらのタイプのテストに合格すると、この機能要件が完了したことがわかります。これらはユーザーストーリーの外部ドキュメントに存在できますが、これらのストーリーがスプリントに割り当てられる前に完了する必要があります。
機能要件は、プロセスのギャップとして説明しているように聞こえるソリューションを定義します。
言及する必要があるが、質問には重要ではない注目の要件タイプ：非機能要件、技術要件など...
このアプローチの目的は、ユーザーストーリーを制約することではなく、悪い要件を防ぐことだと思います。
私の経験では、ユーザーは一般的に要件を書くことができません。開発者は通常、要件を書くことができません。一体、それをそのまま認めましょう：要件を書くのは難しい！
ユーザーがユースストーリーの一部として要件専門用語で何かを書くことは有効だと思います。ただし、そうすることで自動的に要件になるわけではありません。 2つの矛盾する使用事例があることは小さな問題です。2つの矛盾する要件があることは、契約を破る大きな問題です。時間の前に一方を他方に昇格する意味はありません。
厳格な視点は、人間性の認識から来ていると思います。ユーザーストーリーを要件を置く場所として考え始めると、そうするようになります。情報などの要件を収集する他の方法よりもストーリーを使用することの本当の利点は、ユーザーの自然な表現と表記法で表現されていることです。これにより、開発者が顧客の視点から考えている可能性が高くなります。完璧な世界では、寒い要件の専門用語もそこに行くことができます。実際には、このような言葉は、開発者が理解しやすい要件に固執し、アジャイル開発がユースストーリーを使用して発掘したい微妙な表現やニュアンスを見逃しがちです。
自分で決める
「それで、より低い要件がない場合、開発者は実際にどのようにしてストーリーを開発することができますか？」非常にシンプルです-エンドユーザーのニーズに直交する詳細な要件（DB制約、フィールド検証など）は、実際にはユーザーにとって重要ではありません。非常に異なるフィールド検証、非常に異なるDB構造、またはおそらく従来のDBがまったくない場合でもユーザーのニーズを満たすことができる場合、特定の実装を念頭に置いてそのような情報をユーザーに作成させることは逆効果です。最終的にシステムが実装される方法とは異なります。
あなたはプロの開発者です。そのため、実装の詳細については、できる限りの専門的な決定を行ってください。テーブルが必要なユーザーは、大工にどの種類の木材を使いたいかを伝えることができますが、大工は、適度な荷重を処理するためにテーブルの脚の厚さを決定する必要があります。意味のある意思決定を行うための情報が不足している場合は、ユーザーと話し合う必要がありますが、詳細な要件ドキュメントのコンテンツの約90％では、漠然としたユーザーストーリーの常識と業界のベストプラクティス以外の情報は実際には必要ありません。 。
これらすべての詳細は任意ではありません-悪い選択とより良い選択があり、それらは実装の他の部分に影響を与えるので文書化する必要がありますが、結局のところ、これらは実装の詳細であり、実装チームが決定できます。ユーザーのニーズとベストプラクティス。
標準的な車の例え-顧客が車を赤く塗装することを望む場合、ユーザーストーリーの適切な説明は、塗料の化学組成ではなく、どの赤の色調がより良いかを尋ねることです。それでも、雨の中を洗い流す水彩絵の具で車を塗装することを選択しないことが予想されます。そうしないことをお勧めします。
TL; DR
ユーザーストーリーは、製品に追加する必要がある値とその理由を文書化するためのものです。実装の詳細（例：how値を追加、テスト、測定、または検証する必要がある）は、ストーリーによって制約されますが、その中には含まれません。それらは、フレームワーク内で柔軟性と俊敏性を維持するために、個別の成果物として意図的に残されています。
仕様と実装の詳細は、受け入れテスト駆動開発（ATDD）、テスト駆動開発（TDD）、および動作駆動開発（BDD）のスクリプトとシナリオなど、他のアーティファクトで最も頻繁にキャプチャされます。これらの特定のアーティファクトはスクラムフレームワークでは必須ではありませんが、他の効果的なプロセスコントロールをまだ用意していない場合は、それらが確かに良い出発点になります。
ユーザーストーリーは仕様ではありません
元のポスター（OP） 次の質問をした ：
[A]顧客は異なるクレジットカードに対して異なる処理を望んでいます。テストケースを作成できるように、実装および既知の厳しい要件があります...ストーリーにない場合はどこに置くべきですか？
ユーザーストーリーは、値を提供し、いくつかのコンテキストを提供する機能です実装についての会話、および機能によって提供される値から利益を得る値の消費者に関連付けられた視点を導きます。
ユーザーストーリーの全体ポイントは、実装の詳細が規範的ではないことです。チームは、識別された価値を適切なコンテキスト内でバリューコンシューマーに提供する方法で、機能を自由に実装できます。
うまくいった例
ユーザーストーリーの例
これは、あいまいさの少ないユーザーストーリーのセットから始めると説明が簡単になります。 OPは INVESTニーモニック に続く実用的なユーザーストーリーを提供しなかったので、例のために発明します。次の話を考えてみましょう：
Discoverカードでの支払いを希望するユーザーとして、
Discoverカードで購入するオプションが欲しい
私はVisa、Mastercard、またはAmerican Expressに限定されません。
これは、具体的な機能を提供し、チームが行う必要がある実装の決定を導くことができるいくつかのコンテキストを提供し、価値のある消費者をDiscoverカードを所有する顧客として識別します。これは一連の仕様ではありませんが、開発の反復中にストーリーを実装する最良の方法について、お客様やチームと適切に会話するために必要なものです。
分析と実装
実際の実装はチーム次第です。チームは以下を決定するためにいくつかの分析を行う必要があります。
- 新しい機能を実装する最も簡単な方法。
- さまざまな実装オプションのどれが、技術的負債を発生させることなく、今後のサポートを最も容易にするでしょう。
- オープンクローズとYAGNIの原則を適用して、新機能が過度に設計されずに堅牢であることを確認する方法。
アジャイルマニフェスト の中核となる原則の1つは、顧客とのコラボレーションです。部門を超えた自己組織化チームがユーザーストーリーによって提供されるガイドライン内で実装の詳細を検討するために顧客と協力できることが期待されています。
ユーザーストーリーがうまく記述されていない場合、またはチームがアジャイルフレームワークに必要な十分な分析を行うためのスキルやプロセスの成熟度を持っていない場合、これは明らかに必要以上に困難になります。全体の本は、適切な粒度で適切なユーザーストーリーを作成する方法をテーマに書かれています。残念ながら特効薬はありませんが、それはアジャイルチームにとって学習可能なスキルです。
テスト駆動型および動作駆動型設計
分析が適切であり、実装が正常であり、サポート可能であることを保証する最良の方法は、TDDおよびBDDプラクティスを使用することです。たとえば、上記の話を踏まえて、チームは次のような成果物を通じて計画された実装をキャプチャする必要があります。
テスト可能なシナリオでのキュウリの機能
これは、受け入れテストの開発を推進し、userアプリケーションの動作に対する期待を文書化するのに最も役立ちます。たとえば、ユーザーストーリーには、Discoverカードを使用してユーザーがチェックアウトする方法と、そのプロセスがユーザーにどのように見えるかを説明する1つ以上の関連するCucumber機能が必要です。
新しいコード機能の動作（内部実装の詳細ではない）を検証するRSpecテスト
これは、アプリケーション内の機能の意図した動作を文書化して検証するのに最も役立ちます。たとえば、ユーザーストーリーは、ユニットおよび統合テストの作成を促進し、Discoverカードを使用すると、アプリケーションが支払いゲートウェイを介した販売を承認するために必要なカード固有の動作を呼び出すことを確認します。
特定のツールは重要ではありません。 CucumberやRSpecが気に入らない場合は、チームに最適なツールや手法を使用してください。ただし、重要な点は、実装の詳細はユーザーストーリーに基づいてですが、によって規定されていません。代わりに、実装（または、必要に応じて仕様）は、共同で機能の開発中に解決する詳細です。
ユーザーストーリーは、ユーザーがシステムに期待するインターフェイスを説明することを目的とした1つの特定の種類のアーティファクトであり、低レベルの詳細はそこには属していません。それらをそこに置くと、アーティファクトの意図が変わり、米国の定義に適合しなくなります。
他の形式の仕様を使用して、より低いレベルの要件と設計決定をキャプチャします。これらの他のフォームが正確に何であるかは、組織で解決し、特定の環境に合わせてカスタマイズする必要があるものです。
あなたの質問は次のようなものに非常に似ています
私はこれを持っていますCarFactoryと私はそれにも自転車を作らせる必要がありますが、私たちのOOD "Guru"はそれを行うことは許可されていません。このBSとは！？！
コード内のものとプロセス内のものの両方の懸念の分離とアーティファクトのまとまりを尊重します。
ここにたくさんの良い答えがあります。うまくいけば、別の値にいくつかの値を追加できます...
チームが抱えている問題の1つは、アジャイル以外の方法からの移行です。
これは通常、何らかの形式のウォーターフォール手法であり、実際には、通常、コード行が記述される前にすべての技術要件を文書化することを試みます。
しかし、それは常にうまくいくとは限りません。多くの場合、機能しません。理由？要件が現実と一致することはめったにないからです。状況は変わります。したがって、アジャイルへの移行。
アジャイルを使用すると、ユーザーストーリーだけがユーザーの関心事になります。彼らは、ポイントAからポイントBに移動したいと考えています。How実装の観点からそこに到達する方法は、あなたの手にあります。誰かがあなたに技術的要件を伝えるのを待っているなら、それは実際にはアジャイルではありません。質問があれば尋ねてください。文書化が必要な場合は、文書化しますが、顧客がこれらすべての決定を下すのは望ましくありません。彼らは意見を持っているかもしれませんが、アジャイル環境では、それらの意見は（あなたのグルが示唆するように）会話の中で議論すべきです。
これはあなたのチームにとって負担であると感じるかもしれませんが、それは贅沢だと考えてください。あなたのチームは現在、ソリューションに多くの発言権を持っています。これは、ウォーターフォールモデルでは必ずしもそうではありませんでした。