私のチームは開発アプローチとしてアジャイルを使用しています。現在、各タスクには、todo、進行中、テスト、完了の4つの状態があります。
コードレビューを開始したばかりですが、コードレビュータスクを作成する必要があるのか、コードレビューの時間を見積もりに追加する必要があるのでしょうか。
レビューは、実装やテストと同様に、タスクを完了するために実行する必要がある作業の一部です。そのため、レビュー作業はタスクの見積もりに含める必要があります。
実装とテストの状態がすでに異なるので、タスクのコードがレビューされていることを示すために追加の状態を追加することは理にかなっています。
余談ですが、実装されたタスクをレビューまたはテストのためにすぐにピックアップできないことが多い場合(他のチームメンバーが他のタスクで忙しいため)、カンバンのような「待機状態」を「レビュー準備完了」や「テスト準備完了」などのタスク。これにより、「準備完了」状態のタスクが山積みになるため、レビューやテストのフェーズでボトルネックが発生する可能性があるかどうかを明確にすることができます。また、コードを記述した人は、レビュー担当者/テスターを割り当てる必要がない(または担当者に依頼する必要がない)ことを意味します。
場合によります。
個人的には、コードレビュー作業のためのタスクを用意するのが好きです。タスクを適切に見積もることができるからです。また、完了したかどうか、いつ完了したかを明確に示す追跡項目も作成します。また、コードレビューを行う担当者を明示的に割り当て、その作業のバランスを保つことができます。
しかし、私はまた、すべての作業がコードレビューを必要とするわけではなく、確かに常に正式なものであるとは限らないと考えています。
組織がeverythingのコードレビューを必要とする場合、すべてのタスクを作成するのは少し定型的な作業になり、個別の作業単位を表します。すべてに必要な場合は、個別にしたくない-「計画/コーディング/テストと同じくらい自然なもの」に染み込ませたい。したがって、ソフトウェア開発へのこのアプローチはほとんどの場所でやりすぎだと思いますが、他の場所では適切です。そのような場合は、コードレビューをプロセスの1ステップとして作成するようにします。個別のタスクではありません。
両方を使用しました。個別のレビュータスクがある場合、そのタスクに時間を割り当てることができ、誰でも見ることができます。しかし、ボード上で多くのタスクを取得します。ポストイット付きのホワイトボードを使用しているため、不動産が限られており、多少不利です。
現時点では、レビューのために別の状態を使用しています。これは、新しいスプリントに更新するときの手間が減ります。コードの機能をレビューするためにも使用します。私たちのチームでは、別の開発者がテクニカルコードレビューを行い、ドメインスペシャリストが機能レビューを行います。
現時点では、別の状態が推奨される方法です。
新しい状態を追加する前に、その状態を何に使用するかを検討することをお勧めします。その状態でサイクルタイムのように追跡しようとしているメトリックがある場合、それは有益かもしれません。それ以外の場合、完了の定義にコードレビューを含めることの何が問題になっていますか?
プロセスを複雑にするためだけにプロセスを複雑にする必要はないと思います。その状態を持つことに価値はありますか?物事がその状態にあることを知ることがあなたに与えるという情報をどうするつもりですか?