私は、私が働いているソフトウェア開発へのアジャイル アプローチに従うことを実験しています。これまでのところ問題なく動作していますが、イテレーションの終わりに向かって、ビルドに問題が発生し、1 日分の時間をかけて修正する必要がありました。テストに費やすべき時間でした。
その結果、QA にはイテレーションの終了前にテストを完了する十分な時間がありません。このシナリオにどのように対処しますか? イテレーション中に予期しない問題がタスクに影響を与える場合?
開発と QA の間で単一のハンドオフを行うことで、イテレーションで単一障害点が作成されました。QA への納品が間に合わなかったために、このイテレーションはすでに 1 日遅れています。QA を急ぐことで時間を稼ぐことは答えではありません。
より頻繁に QA に納品することで、この状況を改善できます。理想的には、機能が完成するたびにこれを行います。最後のビルドが失敗した場合、QA は前のビルドをテストするだけで済み、それ以降に実装された機能を次の反復に移動する必要があります。
それは QA のスケジュール次第です。開発者が次のイテレーションに取り組んでいる間、テストを続けさせてもらえますか?
はいの場合、テストを終了させます。
すでに持っているデータを使用して、次の反復を続行してください。1 つのボトルネックのために多くの人を引き留めたくはありません。次のイテレーションで、まだ報告されていないバグを修正するために少し余裕を持たせて、すべての開発者にフル イテレーションの価値よりもわずかに少ない作業を割り当てることができます。
いいえの場合は、次の反復を通常の反復として計画し、反復の最後に以前と同じようにテストします。
合意された方法でイテレーション出力をテストできない場合、通常、スプリントのゼロポイント (またはテスト可能なポイント) を取得します。その場では大変だと感じますが、それは賢明なことであることが判明しました.
(プロジェクトの最後のスプリントは明らかに異なります)
アジャイルの基準は、完了したストーリー/バックログ項目のみを完了としてカウントすることです。通常、完了の定義には「テスト中」を含める必要があります。したがって、まだテストされていないストーリーの功績は認められません。結局、次の反復でも同様の問題が発生する可能性があります。
QAがプロセスにどのように統合されているかについての質問からは、完全には明らかではありません。一般に、バグがスプリントから逃れることができないようにする必要があります。そうしないと、ベロシティが非常に信頼できなくなります。