Re: Definition of Done: Code Review practices
From what I experienced the most effective were:
* Paired Programming - but not always possible - due to several factors (such as buy in from management, distributed teams)
* Live review before commit - works well on somehow technically aligned teams
* Code review published to code review system where code cannot integrate until one person says "ship it" - this is the standard approach we have now - ensuring the code is reviewed, the method goes well with distributed teams - you just have to have the tool :)
--- In firstname.lastname@example.org, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
> I'm trying to come up with a list of different ways of doing code reviews as they relate to a Scrum definition of done.
> In practice, I've seen:
> * A scheduled meeting for a code review, several show up and review code
> * Paired Programming
> * Live review by one other programmer just before code commit.
> * Code review published to code review system (like Atlassian Crucible, etc) with deadline by which reviewers can submit feedback.
> * Code review published to code review system (like Atlassian Crucible, etc) where code cannot integrate until one person says "ship it"
> * No code reviews
> * Code reviews only on special occasions or in certain parts of the code
> What other code review type practices have you seen?
> Charles Bradley
> Professional Scrum Trainer
> Scrum Coach-in-Chief