アジャイルユーザーストーリーで必要な実装の詳細を与える/取得する方法は？
ユーザーストーリーと一般的なアジャイルについて質問があります。ユーザーストーリーに関するいくつかの記事を読みましたが、はっきりしないことがありました。たとえば、この article には次の文があります。
ユーザーストーリーは、望ましい結果の概要を示す簡単な言語の数文です。詳細には触れません。
ただし、多くの場合、詳細なしでは機能を実装できません。
いくつか例を挙げましょう。
バックエンド：
現在のバックエンドでは外部サービスを使用する必要があります。バックエンドは、外部サービスのいくつかのエンドポイントを呼び出す必要があります。
どのエンドポイントを呼び出す必要があるか、どのような要求のコンテンツにする必要があるか、どのような順序でエンドポイントを呼び出す必要があるかなど、重要なことがいくつかあります。したがって、これらは私が認める本当に技術的な詳細であり、おそらく外部サービスに関する情報を取得するために必要な通信/研究です。誰がその責任を負っていますか？
フロントエンド：
アプリケーションに追加された新しいページ。ここには、ボタンのキャプション、カラーコード、ユーザーへのメッセージ（情報、警告、エラー）のような重要な詳細情報もあります。
誰がそれを定義するべきか、ストーリーライターまたは開発者？これはユーザーストーリーの一部にする必要がありますか？
私も statement のようなユーザーストーリーについて読みます、
「ユーザーストーリーはアジャイルアプローチの一部であり、要件について書くことからそれらについて話すことに焦点を移すのに役立ちます。すべてのアジャイルユーザーストーリーには、1つまたは2つの文章、さらに重要なことに、目的の機能に関する一連の会話が含まれます。」
私は本当にコミュニケーションに反対しているわけではありませんが、結局のところ、口頭でのコミュニケーションは永続的ではなく、情報が失われる可能性があるため、結果は私の意見のどこかに書いておくべきです。
要約すると、私が読んだ内容に基づいて、ユーザーストーリーは実装方法についてではなく、実装する必要があることについてです。方法も重要であると思います。物事は良い方法と悪い方法で実行でき、後で判明すると、何かが悪いことであり、それを修正するのにコストがかかりますが、情報を共有する方法を見つけることができませんでした。 。
牛乳が一杯欲しい。
どんな牛乳？
気にしないで。牛乳だけ。
暖かいですか寒いですか？
何でもミルクをください。
2％または...
牛乳！
大丈夫ここにあなたの牛乳です。
ええ、期限までに販売されていない牛乳をください。
ユーザーストーリーは、望ましい結果の概要を示す簡単な言語の数文です。それらは故意に設計のため、詳細には触れません。ユーザーストーリーにデザインを要求しないでください。多くのデザインがユーザーストーリーを満たします。ユーザーストーリーは、必要なエクスペリエンスに関するものです。解決策ではありません。
ユーザーが体験を感じながらユーザーストーリーが時間の経過とともに変化しても、驚かないでください。この経験を得ることを避けようとする多くの時間を無駄にしないでください。まあ、それが誰も殺さない限り。
[実装の詳細]誰が定義する必要がありますか、ストーリーライターまたは開発者ですか。
詳細は開発者が担当します。実装の詳細は、ユーザーストーリー、要件、またはテストには含まれません。それらはコードに属します。
ユーザーや他の利害関係者は、システムの実装方法を気にする必要はありません。彼らが気にする必要があるのはそれが何をするかではなくそれがそれをする方法です
多くの機能やユーザーストーリーを適切に実装するには追加の詳細情報が必要であることは間違いありません。しかし、利害関係者の観点から、これらの詳細は常に実装ではなく動作を具体化します。
適切な実装を実現できるように、システムの動作に関する十分な詳細を提供するのは利害関係者次第です。思いつくのはあなた次第です行動に対する利害関係者の期待を満たす実装で。
利害関係者は、システムをどのように組み合わせるかについての技術的な詳細を提供する資格も関心もありません。利害関係者が「Javaでこれを書くべきだと思う」または「マイクロサービスを使うべきだと思う」などと言った場合は、「技術的な詳細について心配させてください」と最初に言う必要があります。私を雇った。」
（たとえば）マイクロサービスを実際に使用する必要があるかどうかを調べるには、 非機能要件について関係者に質問します。
- ソフトウェアを使用するユーザーは何人ですか（「どのアーキテクチャを使用する必要があるか」ではありません）？
- システムの予想される応答時間はどのくらいですか（「どの言語、フレームワーク、およびデータベースを使用する必要があるか」ではありません）？
- どのような種類の計算が必要になりますか（「OLAPキューブ）が必要ですか」ではありません）？
- どれだけのデータが保存されますか（「必要なディスクの数」ではありません）？
これらはすべて、技術的な問題ではなく、ビジネスの観点から回答できる質問です。
質問が単に「どこにこれらの詳細を書き留めるのか」である場合、答えは「ユーザーストーリーを書き留めたのと同じ場所です」です。
簡単な答えは、「自己組織化」チームに必要な詳細の数を決定させることです。スプリント計画（または個別の全チームグルーミングセッション）の一環として、チームはPOとストーリーについて話し合い、ストーリーがスプリントに入る準備ができているかどうかについて最終的なコールを持ちます。他のコメンターからのテーマを繰り返すために、このディスカッションは、ストーリーを作業するメンバーに残された「方法」ではなく「何」に焦点を当てています。そうは言っても、whatが実現可能であることを保証するため、またはアーキテクチャの方向性を提供するためにhowの一部について説明する場合があります。ただし、円滑に進めるには、あまりにも多くの「解決策」に対して慎重に警告します。
チームワーク全般に関する大規模な研究文献に基づいて、ディスカッションのすべての合意をストーリーカードの簡単な箇条書きリスト（紙でもデジタルでも）として記録することをお勧めします。これにより、後で何があったかを思い出そうとして時間を無駄にすることがなくなります。決定しました！これにより、先に進む前に、カードの言語（ユーザーストーリー、承認基準、および契約のリスト）にサインオフするように全員に依頼することで、誤解による時間の浪費も防ぎます。