|
|
|
|
|
by noss
5014 days ago
|
|
I have done code reviews in a scrum team setting. Often there are tasks that only one team member will implement, it would simply be too many chefs to have two developers on it, and the others are needed to implement other things. What we found very useful is to do a pre-review of the existing code to discuss how it works, but this after everyone have done their own one-hour self-study of the code (actually, self-study time tends to be until one guy interrupts saying he grok it and can describe it). Then we discuss the approach for implementation, but only one guy go ahead and implement it. The other developers have similar reviews on their areas. Afterwards, when it has been implemented, we all come together and look at the implemented solution, again first with self study of the commits, then review sitting in front of the developers desk. By only being involved as a reviewer, you get a very good understanding of the implementation. You understand not only how it works, but why it was implemented that way. It also leads to more "talk about the code" in the team. Everybody gets a common understanding of some area, you can talk about code improvements. |
|