TDD（スクラム）を使用しながらユーザーストーリーからコードに移行する
私はスクラムとTDDに取り掛かっていますが、あなたのフィードバックを得たいと思って混乱していると思います。私のバックログにユーザーストーリーがあり、TDDの一部として開発を開始するために、これまでの要件が必要であるとしましょう。
プロダクトマネージャーとQAがユーザーストーリーを受け入れて受け入れテストに分解する責任があると言うのは本当ですか？
受け入れテストは形式的である必要があるため、上記は正しいと思います。テストとして使用できますが、製品が要件であることを製品が承認できるように、人間が読める形式でも使用できます。
私が後でこれらの受け入れテストを受けて、それを私の要件として使用することも真実ですか？つまり、それらは私が（TDDを通じて）実装する一連のユースケースです？私は混乱をあまり作りすぎていないといいのですが、それが今私が考えている現在の流れです。
更新
最初の意図が不明確だったので、言い換えます。 TDDの使用中にユーザーストーリーをコードに変換するスクラムフローの詳細を知りたい。
開始点は明らかです。ユーザーは、ニーズ（または製品としてのユーザーの代表）を表面化します。これは、既知の形式で1〜2行の短い説明であり、製品のバックログに追加されます。
春の計画会議が開催されると、ユーザーストーリーがバックログから取得され、開発者に割り当てられます。
開発者がコードを作成するには、要件が必要です（特に、要件はテストの派生元であるためTDDで）。
要件はいつ、誰によって、どの形式でコンパイルされますか？
私が念頭に置いていたのは、製品とQAが受け入れテストを介して要件を定義することでした（私はFitNesseを使用して自動でソートすることを考えていますが、それは私が考えるコアではありません）。同時：
- 彼らは「完了」を適切に定義しています。
- それらは、開発者にテストの派生元を提供します。
これらがいつ記述されたかはわかりませんでした（スプリントの前にそれらが選択されると、追加の情報が届くか、ストーリーが選択されないため、無駄になる可能性があります。反復中に開発者がスタックするのを待っている可能性があります。 ..）
プロダクトマネージャーとQAがユーザーストーリーを受け入れて受け入れテストに分解する責任があると言うのは本当ですか？
主に。彼らは実際に実際の受け入れテストを書かないかもしれません。彼らはあなたが書いたものを承認するかもしれません。しかし、彼らは受け入れテストを承認します。はい。
受け入れテストは正式なものである必要があるので、テストとして使用できるだけでなく、製品が要件であることを製品が承認できるように、人間が読めるようにする必要があります。
無関係です。それらは自動化されたテストとして形式化されるかもしれません。または、それらは非公式であり、非公式の受け入れテスト基準から自動テストを作成するのはあなたの仕事かもしれません。
また。 「要件」はユーザーストーリーです。 「要件」と呼ばれるストーリーのさらに別のバージョンを作成する必要はありません。コーディングする前にストーリーについて詳しく説明したい人もいます。この要件を呼び出すことができますが、「デザイン」の方が優れています。 「精巧」は最高の言葉です。
私が後でこれらの受け入れテストを受け、それを私の要件として使用することも真実ですか？つまり、それらは私が（TDDを介して）実装する一連のユースケースです？
はい。ストーリーは受け入れテストにつながります。ストーリーは必須の動作です（つまり、「要件」）。ストーリーは、ソフトウェアの設計と開発を促進するテストにつながります。
それが今私が考えている現在の流れです。
これに対する「フロー」はそれほど多くありません。
ストーリー->受け入れテスト。
ストーリー->エラボレーション（ "design"、 "requirements"）->ユニットテスト->コード。
ストーリー->ユーザーが価値のあることを実行できること。
ストーリー->ストーリーポイント->速度計算。
パターンに注意してください。物語は主にすべてを動かします。
いつ、誰が、どの形式で要件がコンパイルされますか？
最初。 「要件」を定義します。ストーリー自体とどう違うのですか？
私が考えていたのは、製品とQAが受け入れテストで要件を定義することでした
通常はありません。
反復中に、開発者はそれらを待つのに行き詰まる場合があります。
不正解です。開発者はこれらを書くのを手伝うことができます（そしてしばしばそうします）それが「開発」のポイントです。明確に定義された「完了」するようにストーリーを詳しく説明します。
再び。疑問や質問がある場合は、実際にアジャイルマニフェストを読む必要があります。マニフェストは非常に明確です。開発者は製品の所有者、ユーザー、QA、および利害関係者である他のすべての人と話し合う必要があります。相互作用は実際には最も重要起こり得ることです。
受け入れテストに関して、エクストリームプログラミング（XP）の観点からお答えします。
私が最初に入って（そして本を読んで）いたとき、受け入れテストを開発/文書化するためにクライアント/ユーザーと協力することは本当に開発者の役割であると読んだ。 XP=の目標の1つは、ユーザー/クライアントと開発者の間の直接通信を増やすことです。これは、要件の誤通信によるコーディングエラーの可能性を減らすため、多くの場合理想的です。
私はTDDを約8年間行っており、上記のアプローチに従っています。クライアント/ユーザーがアプリケーションの開発に直接影響を与えている様子を見ることができるため、開発のスピードとシステムの満足度が向上したと思います。
私が（小さなクライアントで）遭遇した主な問題は、受け入れテストの指定に参加させるのが非常に難しいことです。 （通常、私は彼らのためにそれを行い、レビューのためにそれらを送信する必要があります。）私が扱った大規模なクライアントは通常この考え方を持っていたため、特定の受け入れテストを提供する準備ができていました。
私がスクラムについて読んだことから、それが受け入れテストの定義/作成に責任がある役割を定義しているのかどうかはわかりません。チームごとに異なる可能性があると思います。
私のアドバイスは、あなたは開発者として、テスト定義プロセスにできる限り参加すべきであるということです。そして目標は、スプリントの結果をできるだけ早くユーザーの前に表示することです。そうすることで、ユーザーが考え忘れていたすべて（または誤って伝えたこと）をできるだけ早く伝えることができます。
ユーザーストーリーはありません "ユーザーとしてXXXが欲しいので、YYY"！ユーザーストーリーはPOとの将来のコミュニケーションの約束です。それはあなたの問題をより詳細に解決します。必要な情報を取得するには、スプリント中にPOと通信する必要があります。
ユーザーストーリーには、コミュニケーションを約束する短い文よりも多くの機能があります。ユーザーストーリーの必要な部分は受け入れ基準です。受け入れ基準は、ユーザーストーリーにコミットする前に知っておく必要があります（ユーザーストーリーを推定する前に知っておく必要があります）。受け入れ基準は受け入れテストの入力です=受け入れテストは受け入れ基準をテストする必要があります。
したがって、TDDアプローチを使用してユーザーストーリーの作業を開始する場合、（QAではなく）最初に、受け入れ基準に基づいて自動受け入れテストを作成し、失敗したテストを取得する必要があります。受け入れテストに合格する前に、TDDを使用して必要なコードを実装し続けます。次の受け入れテストに進みます。それについても 別の質問 で書いた。