スクラムに関して 2 つの関連する質問があります。
私たちの会社はそれを実装しようとしていますが、私たちはフープを飛び越えていることを確認しています.
どちらの質問も「done は完了を意味します」に関するものです。
1) タスクの「完了」を定義するのは非常に簡単です - 明確なテスト受け入れ基準 - 完全にスタンドアロン - 最後にテスターによってテストされます
次のようなタスクで何をすべきか: - アーキテクチャの設計 - リファクタリング - いくつかのユーティリティ クラスの開発
それに関する主な問題は、それがほぼ完全に内部エンティティであり、外部からチェック/テストする方法がないことです。
たとえば、機能の実装はバイナリのようなものです。完了している (すべてのテスト ケースに合格する) か、完了していない (いくつかのテスト ケースに合格しない)。
私の頭に浮かぶ最善の方法は、別の開発者にそのタスクのレビューを依頼することです。ただし、完全に完了したかどうかを判断する明確な方法はありません。
では、問題は、そのような内部タスクの「完了」をどのように定義するかです。
2) デバッグ/バグ修正タスク
アジャイル方法論では、大きなタスクを行うことは推奨されていないことを知っています。少なくともタスクが大きい場合は、小さなタスクに分割する必要があります。
非常に大きな問題があるとしましょう - 大きなモジュールの再設計 (新しい時代遅れのアーキテクチャを新しいものに置き換えるため)。確かに、このタスクは数十の小さなタスクに分割されています。ただし、最後にデバッグ/修正のセッションがかなり長くなることはわかっています。
それは通常、ウォーターフォールモデルの問題であることを私は知っています。ただし、それを取り除くのは難しいと思います（特にかなり大きな変更の場合）。
デバッグ/修正/システム統合などに特別なタスクを割り当てる必要がありますか?
その場合、通常、このタスクは他のすべてに比べて巨大であり、小さなタスクに分割するのは難しい.
この巨大な一枚岩の仕事のために、私はこの方法が好きではありません。
別の方法があります。小さなタスク (バグに関連するもの) を作成し、それらをバックログに入れ、優先順位を付けて、アクティビティの最後に反復に追加することができます。
私はこの方法が好きではありません。タスクを見積もり、いつでも完了のマークを付けます。そして、新しい見積もりでバグの新しいタスクを開始します。したがって、実際の時間 = 推定時間という結果になり、これは絶対に良くありません。
この問題をどのように解決しますか？
よろしく、ビクター