TDD（スクラム）を使用しながらユーザーストーリーからコードに移行する

私はスクラムとTDDに取り掛かっていますが、いくつかの混乱があると思います。フィードバックについてお聞きしたいと思います。バックログにユーザーストーリーがあり、TDDの一部として開発を開始するために、これまでの要件が必要であるとしましょう。

プロダクトマネージャーとQAがユーザーストーリーを受け入れて受け入れテストに分解する責任を負うべきだと言うのは本当ですか？

受け入れテストは形式的である必要があるため、上記は正しいと思います。テストとして使用できるだけでなく、製品が要件であることを製品が承認できるように、人間が読める形式でも使用できます。

私が後でこれらの受け入れテストを受けて、それを私の要件として使用すること、つまり、それらが（TDDを介して）実装する一連のユースケースであることも本当ですか？私は混乱をあまり作りすぎていないといいのですが、それが今私が考えている現在の流れです。

更新
当初の意図は不明確だったので、言い換えます。TDDの使用中にユーザーストーリーをコードに変換するスクラムフローの詳細を知りたい。
開始点は明らかです。ユーザーはニーズ（または製品としてのユーザーの代表）を表面化します。これは、既知の形式で1〜2行の短い説明であり、製品のバックログに追加されます。
春の計画会議がある場合、ユーザーストーリーはバックログから取得され、開発者に割り当てられます。
開発者がコードを作成するには、要件が必要です（特に、要件はテストの派生元であるため、TDDで必要です）。
いつ、誰が、どの形式で要件がコンパイルされますか？
私が頭に浮かんだのは、製品とQAが受け入れテストを介して要件を定義することです（私はFitNesseまたはソートを使用して自動で考えていますが、それは私が考えるコアではありません）同時に2つの目的を果たすのに役立ちます：

1. 彼らは「完了」を適切に定義しています。
2. それらは、開発者にテストの派生元を提供します。

これらがいつ記述されたかはわかりませんでした（スプリントが選択される前に追加情報が届くか、ストーリーが選択されないため、繰り返しの間に開発者がスタックを待機する可能性があるため、これは無駄になります）。 ..）

プロダクトマネージャーとQAがユーザーストーリーを受け入れて受け入れテストに分解する責任を負うべきだと言うのは本当ですか？

主に。彼らは実際に実際の受け入れテストを書かないかもしれません。彼らはあなたが書いたものを承認するかもしれません。しかし、彼らは受け入れテストを承認します。はい。

受け入れテストは正式なものである必要があるため、テストとして使用できますが、製品が要件であることを製品が承認できるように、人間が読める形式でも使用できます。

無関係です。それらは自動化されたテストとして形式化されるかもしれません。または、非公式であり、非公式の受け入れテスト基準から自動テストを作成するのはあなたの仕事かもしれません。

また。「要件」はユーザーストーリーです。「要件」と呼ばれるストーリーのさらに別のバージョンを作成する必要はありません。コーディングする前にストーリーについて詳しく説明したい人もいます。この要件と呼ぶことができますが、「デザイン」の方がいい言葉です。「精巧」は最高の言葉です。

私が後でこれらの受け入れテストを受け、それを私の要件として使用することも真実ですか？つまり、それらは私が（TDDを介して）実装する一連のユースケースです？

はい。ストーリーは受け入れテストにつながります。ストーリーは必須の動作です（つまり、「要件」）。ストーリーは、ソフトウェアの設計と開発を促進するテストにつながります。

それが今私が考えている現在の流れです。

これに対する「フロー」はそれほど多くありません。

ストーリー->受け入れテスト。

ストーリー->エラボレーション（ "design"、 "requirements"）->ユニットテスト->コード。

ストーリー->ユーザーが価値のあることを実行できること。

ストーリー->ストーリーポイント->速度計算。

パターンに注意してください。物語は主にすべてを動かします。

いつ、誰が、どの形式で要件がコンパイルされますか？

最初。「要件」を定義します。ストーリー自体とどう違うのですか？

私が考えていたのは、製品とQAが受け入れテストを介して要件を定義することでした

通常はありません。

反復中に、開発者はそれらを待つのに行き詰まる場合があります。

不正解です。開発者はこれらを書くのを手伝うことができます（そしてしばしばそうします）。それが「開発」のポイントです。ストーリーを明確にして「完了」します。

再び。疑問や質問がある場合は、実際にアジャイルマニフェストを読む必要があります。マニフェストは非常に明確です。開発者は、製品の所有者、ユーザー、QA、および利害関係者である他のすべての人と話し合う必要があります。相互作用は実際に起こり得る最も重要なことです。

受け入れテストに関しては、エクストリームプログラミング（XP）の観点からお答えします。

私が最初に本を読んだとき（そして本を読んでいたとき）、私は実際にクライアント/ユーザーと協力して受け入れテストを開発/文書化することが開発者の役割であることを読みました。XPの目標の1つは、ユーザー/クライアントと開発者の間の直接的なコミュニケーションを増やすことです。これは、要件の誤った伝達によるコーディングエラーの可能性を減らすため、多くの場合理想的です。

私はTDDを約8年間行っており、上記のアプローチに従っています。クライアント/ユーザーがアプリケーションの開発に直接影響を与えている様子を見ることができるため、開発のスピードとシステムの満足度が向上したと思います。

私が（小さなクライアントで）遭遇した主な問題は、受け入れテストの指定に参加させるのが非常に難しいことです。（通常、私は彼らのためにそれを行い、レビューのためにそれらを送信する必要があります。）私が作業した大規模なクライアントは通常この考え方を持っていたため、特定の受け入れテストを提供する準備ができていました。

私がスクラムについて読んだことからは、それが受け入れテストの定義/作成に責任がある役割を定義しているのかわかりません。チームによって異なる場合があると思います。

私のアドバイスは、あなたは開発者として、テスト定義プロセスにできる限り参加すべきであるということです。そして目標は、スプリントの結果をできるだけ早くユーザーの前に表示することです。そうすることで、ユーザーが考え忘れていたすべて（または誤って伝えたこと）をできるだけ早く伝えることができます。

ユーザーストーリーは「ユーザーとしてXXXが欲しいので、YYY」ではありません。ユーザーストーリーはPOとの将来のコミュニケーションの約束です。それはあなたの問題をより詳細に解決します。必要な情報を取得するには、スプリント中にPOと通信する必要があります。

ユーザーストーリーには、コミュニケーションを約束する短い文よりも多くの機能があります。ユーザーストーリーの必要な部分は受け入れ基準です。受け入れ基準は、ユーザーストーリーにコミットする前に知っておく必要があります（ユーザーストーリーを推定する前に知っておく必要があります）。受け入れ基準は受け入れテストの入力です=受け入れテストは受け入れ基準をテストする必要があります。

したがって、TDDアプローチを使用してユーザーストーリーの作業を開始する場合、（QAではなく）最初に、受け入れ基準に基づいて自動受け入れテストを作成し、テストの失敗テストを取得する必要があります。受け入れテストに合格する前に、TDDを使用して必要なコードを実装し続けます。次の受け入れテストに進みます。それについては別の質問でも書いた。