スクラムの非クロスファンクショナルチームのテスターとすべてのスプリントの初期の段階での私の個人的な洞察よりも、速度に関する最初の回答です。
そこに矛盾が見られます。チームがクロスファンクショナルでない場合は、テスターと開発者を区別します。この場合、速度計算でもそれらを区別する必要があります。チームがクロスファンクショナル テスターでない場合、ベロシティを実際に上げることはありません。あなたの速度は、開発者が実装できる最大のものになりますが、テスターがテストできるものを超えることはありません (すべてをテストする必要がある場合)。
スクラム マスターに相談してください。そうしないと、常に速度と見積もりに問題が生じます。
さて、テスターとスプリントの初期について。私はテスターとして 5 人の開発者がいるクロスファンクショナル チームで働いているので、この回答は少し個人的なものになるかもしれません。これは 2 つの方法で解決できます。a) 個別のテスト スプリントを追加して作業組織を変更するか、b) テスターの作業方法を変更します。
a) では、個別のテスト スプリントをクレートします。開発スプリントと並行して (数日ずらして) 行うことも、2、3 回の開発スプリントに 1 回行うこともできます。このソリューションについて聞いたことがありますが、この方法で作業したことはありません。
b) では、テスターに、テスト活動へのアプローチをレビューするよう依頼する必要があります。使用するプラクティスやツール、または従うプロセスにもよるかもしれませんが、この初期の段階で、どうして彼らが何もすることができないのでしょうか? 前に述べたように、私はクロスファンクショナル チームではなく、5 人の開発者と共にテスターとして働いています。開発者がタスクを終了するまで自分の作業を待つとしたら、特定のスプリントですべての機能をテストすることはありません。テスターが探索的テストのみを実行する場合を除き、機能がテスト環境にリリースされる前に行うべきことがあります。テスターが機能/コードを手に入れる前に、実行できる (または実行する必要がある) アクティビティがいくつかあります。以下は、機能がテスト環境にリリースされる前に私が行うこと
です
。
- ドラフト テスト ケースを準備する
- 可能なテスト データを確認する (実装されている変更がシステム内のデータを操作する場合、このデータのスナップショットを作成し、後で特定の機能がこのデータに対して行うことと比較する必要があります)
- まとめテストスイートのすべて
- 機能が開発されているときに開発者と通信します - こうすることで、実装されたソリューションをよりよく理解することができます (他の機能についてすでに気がついたときに尋ねるのではなく)
- 機能としてテストケースに必要な変更を加えることができます進化する
次に、機能が完成したら、次のことを行います。 - 以前は知らなかった詳細でテスト ケースを具体化します (些細なことですが、ボタン名が変更される場合や、ウィザードに追加のステップが表示される場合があります)
- テストを実行します
- 問題を提起します
。実際、私は実際にそれらのテストを実行するよりも、最初の部分 (テストの設計と適切なツールでのテスト スクリプトの準備) に多くの時間を費やしていることに気づきました。
コードがテスト環境にリリースされるのを待つのではなく、すぐにできる限りのことを行えば、この最初のギャップを埋めることができ、テスターがスプリントの終了前にアクティビティを完了できないリスクを最小限に抑えることができます。
もちろん、テスターが最初に行うことは常に少なく、最後にはより多くなりますが、この差を最小限に抑えるように努めることができます。そして、上記のように、最初に無駄にする時間がたくさんある場合でも、コーディングに関連するタスクを彼らに与えることはできません。一部の構成、一部のメンテナンス、ドキュメントの更新、その他。