スクラムでスプリントの時間を計ってTDDに時間を割り当てるにはどうすればよいですか？
4週間のスプリントがあります。私が行っているのは、3週間の開発時間と、1週間の純粋な手動/自動テスト、安定化、および出荷保証テストです。
開発時間内にTDDを管理する方法は？私の以前の経験では、テストを作成して80％のカバレッジを取得するには、開発時間の約50％が必要です。同じことを実行すると、1週間半の開発しか得られず、十分ではありません。
私の実際の問題は、TDDに時間を割り当てる方法です。 TDDを必須にしたいのですが、これでは本当に難しくなります。これは私たちが使用している正しいアプローチだと思いますか、それとも何かが足りず、スクラムへのアプローチを変更していると思いますか？
TDDの背後にある考え方は、テストの作成は開発の一部であるということです。実際には開発+ユニットテストとして計算するべきではありません。それを表示するためのより良い方法は開発=機能+ユニットテストであり、ユニットテストの作成は別個ではありませんアクティビティ。開発者が機能に取り組んでいる間、彼らは単体テストも作成しています。
同様に、タスクボードに「ユニットテストの作成」用の個別のタスクを含めるべきではありません。ユニットテストは機能と一緒に実装する必要があり、実際には分離してはなりません。
1.5週間の開発とその後の1.5週間の単体テストのようなものであってはなりません。代わりに、3週間の開発を行い、完全にテストされた状態で機能を完成させたいと考えています。完了の定義で、機能のすべての部分が単体テストされることが指定されている場合、機能を実装することと単体テストを実行することとの間に分離があってはなりません。
QAの統合に関するその他の質問については、チームの一部としてQAリソースがあり、利用可能になったときに各機能をテストし、毎日（または毎晩）完全な回帰テストを行います。スプリントの3日目に機能の実装が行われた場合、QAはこの日からテストを開始します。理想的には、開発者が機能を実装すると同時にテストスクリプトを開発しました。
両者は協力して、多くの協力を得て作業する必要があります。チーム内の開発者とQAの間には多くのコミュニケーションがあります。 「ねえ、機能Aの準備ができたので、テストを開始できます。」および「機能Bのテストで次の問題が見つかりました。これを修正していただけますか？」すべてがテストされ、最後に機能することを目標に、スプリント中は常にこれを行ったり来たりしています。
それを毎晩実行される完全な回帰テストと組み合わせると、結果が公開され、スプリントの最終日までほとんど開発できます。テストは、過去2日間だけでなく、スプリントのすべての段階で行う必要があります。
最初に、3週間の開発と1週間のテストはnotスクラムであり、代わりにタイムボックス化されたウォーターフォールであることを言及する必要があります。スクラムの中心的な哲学は継続的な検査と適応であるため、プログラマーとテスターの間の相互作用を調べ、段階的に作業するように指導することを強くお勧めします。
正しいスクラムの答えは「チームに尋ねる」です。これが自己組織化、検査、適応に関するものだからです。彼らが解決する必要のある問題は、プログラマーが最大半日で小さなコードを書いて、テスターに何かを渡してテストする方法です。これは、機能が完全である必要があることを意味するのではなく、ソース管理に段階的に追加され、テスターによってテスト可能になるだけです。
TDDは、コーディングする前に、プログラマーがテストの方法を考え、テストに合格するために最小限のことを行うように促すため、検討するのに適したアプローチです。
TDDの背後にある考え方は、それ自体が時間を消費する一方で、他の領域で必要な時間を削減するというものです。コードをより速く記述し、バグ修正や手動テストにそれほど多くの時間を費やさないようにする必要があります。そうすれば、それに応じてこれらの側面を減らすことができます。
したがって、あなたの声明（私の強調）：
同じことに従うと、[x時間]の開発しか得られませんこれでは十分ではありません。
必ずしも真実ではありません。
これが実際に達成できることであるかどうかはあなた次第ですが、それが理論です:)
- スクラムで働き始めたばかりの場合、スプリントにとって4週間はかなり長い期間です。スプリントが短いと、早期に頻繁に失敗する可能性があります（悪いことではありません）。したがって、検査と適応により、プロセスを大幅に迅速に改善できます。また、変更に対してより反応的になることもできます。
私の以前の経験では、テストを作成して80％のカバレッジを取得するには、開発時間の約50％が必要です。
- TDDでは、開発時間IS開発+単体テスト時間。2週間の開発+1週間のテストではなく、3週間の高品質の開発が得られます。 ソフトウェア開発のコストのこのような大きな割合 はメンテナンスであり、品質は非常に重要であり、完了の定義とストーリーの受け入れ基準の両方に組み込まれている必要があります。
1週間の純粋な手動/自動テスト、安定化、および出荷保証テスト
- nwinklerはこれにかなり上で答えたので、私は彼が言ったことを繰り返しません。あなたがしていることは、本質的にすべてのスプリントの小さな滝です！必要に応じて、テストする各ストーリーのスプリントバックログに安定化/出荷保証タスク（またはその他）を作成します。明らかに、組織でテスターの役割を持っている場合、まだいない場合はスクラムチームに参加する必要があります
ここにいくつかの問題と改善が見られます。
- TDDは、カバレッジとテストの作成を保証するだけでなく、実際には設計パラダイムです。また、正しくTDDを実行している場合は、自動的に100％のカバレッジが得られます。そのプログラミング方法論。したがって、それをコーディング活動の一部と見なす必要があります。
- バックログを最適なサイズにスライスすることは、スプリントで適切な量の作業を行うための鍵です。作業が多すぎることに気付いた場合は、おそらく大きなバックログを意味します。バックログのサイズが正しい場合は、おそらくスプリントで実行できるよりも多くの作業を見積もっています。