スクラム ボードでは、タスクは「To Do」から始まり、「In Progress」に進み、タスクが完了すると「To Verify」に移動してから「Done」になります。「To Verify」列は、タスクが完了し、他の誰かがそれを見て、テストし、コメントできるようになるときです。
これは、エラーやより良いコードなどに役立つことが証明されています。
同様の慣習を持っている人へ: 開発者がコメント/エラーに対処した後、もう一度確認しますか、それとも問題が解決されたと仮定してタスクを「完了」に移動しますか?
これが明確であることを願っています。あなたの考えを聞きたいです。
私の期限内では、特にコードがテストケースでカバーされていない場合、バグの修正により新しいバグが導入される可能性が 50 ～ 75% あります。私は確かにそれをもう一度確認します。
この質問はスクラムに固有のものではありません。アジャイル プロセス以外でもこの問題を見てきました。
答えは次のとおりです。検証で提起された問題によって異なります。些細な問題が発生し、担当の開発者が十分に年長である場合は、最初から問題を修正することを信頼してください。しかし、検証を行っている人が項目が複雑すぎると考えている場合、またはスクラム マスターが、開発者が 2 回目に正しく処理することを信頼できない場合は、ポストイットを [進行中] に戻します。
チェックする必要のない種類のエラーの良い例は、単純なタイプミスです。相互に依存する境界条件が多数ある場合の境界条件のエラーは、もう一度確認する良い例です。
To Verify 列はありません。タスクは、実装およびテストが完了するまで進行中です。テストされていないタスクを実行することはできません。なぜ他の誰かがそれをテストし、プログラマーに報告し、プログラマーが修正しなければならないのでしょうか? これは、ワークフローにレイテンシを追加するだけです。プログラマーは自分のコードをテストし、可能であれば単体テストを作成し、可能であればそれをアプリに統合して、自然なワークフローの一部としてここでテストする必要があります。そうすれば、彼は自分のバグを見つけて、すぐに修正できます。タスクを完了に設定すると、タスクが完全に実装されたことだけでなく、タスクにバグがないことも確信できます。
わかりました、それはほとんど意味がありません。バグが発見されるのはかなり後になってからになることもありますが、その場合はそれほど明白なバグではなく、通常、修正はそれ自体のタスクになります。
私が参加したプロジェクト (アジャイルと非アジャイルの両方) では、バグ修正は常に他の誰かによって検証されていました。多くの場合、新しいバグが導入されるため、修正について少し調べる必要があります。ビルドで忘れられたデバッグ コードを見たことさえあります。すべて正常に動作しますが、どこからともなく余分なファイルが表示されます。
また、開発者がバグへのすべてのパスを見つけられなかった、またはバグ レポートが不明確であったために開発者が間違った修正を行った可能性もあります。たとえば、何かが誤解されていて、正しい機能がバグとして報告されている場合などです。
作業が完了したときに確実に完了できるようにするには、修正のためのテストも自動テストに追加する必要があります。そうしないと、厄介なコーナーケースのバグが数か月後に再発します。
問題が個別に (つまり、問題を修正した人によってではなく) 検証されるまで、問題が解決されたと思い込まないでください。