When to do Code Review

Question

We have recently moved to a scrum process and are working on tasks and user stories inside of sprints. We would like to do code reviews frequently to make them less daunting. We are thinking that doing them on a user story level but are unsure how to branch our code to account for this.

We are using VS and TFS 2010 and we are a team of 6.

We currently branch for features but are working on changing to branching for scrum.

We do not currently use shelvesets and don't really want to implement if there are other techniques available.

How do you recommend we implement code review per user story?

Answer 1

It depends on the nature of the user stories.

It can be effective to create a branch for each user story, progress on different stories are visible, they can be passed around if needs be, if stories aren't completed in the sprint then the progress can stay in the branch for the next sprint. Final reviews can then be performed at the end of a user story in the use story branch and merged in if the code is up to standard.

To work in the manner stories need to be finely grained to prevent unmanagable merge tasks at the end of a sprint. Small stories will allow a steady update of the dev branch through the sprint that devs working on other user stories need to constantly pull from (basic VCM).

This does create process overheads having to create and merge branches constantly which in some cases can be resolved with automation scripts but the team still needs to be very comfortable with the VCS.

At the end of a sprint you merge your dev branch into integration/production etc.

I have also worked in teams where everyone works off one dev branch, on completion of a user story the code is pushed to that branch for review and testing and if someone pushes something that breaks the dev build they have to get the team beers in.

Answer 2

The most effective way to review code is to stand up, find someone, and ask them to come over and discuss the code you have just developed.

Don't use a tool unless you cannot find someone to review your code locally.

You can avoid code reviews altogether by pairing.

Answer 3

Is everyone on the team local? If so, just ask someone to come over and have a look before the code is checked in. Not local? Fire up your favorite screen-sharing program and call someone. I personally do this often. Sometimes I do it just to say "Hey, look what I did!"

I much prefer this style of ad-hoc code reviews to the style where someone is standing up and presenting their code to the team. Ad-hoc reviews can give you many (all?) of the benefits of pairing without the awkwardness. Also, your "reviewer" is more likely to ask questions and suggest improvements in an informal, one-on-one setting.

Answer 4

I believe code review is not a formal part of SCRUM, yet revisions are an independent tactic to achieve quality and improve your projects/team.

So, you would use SCRUM (or other agile development methodology) to ensure/improve PROJECT quality and keep on schedule. Also, a good tactic is to do product revision (not code) indepently from your normal QA/testing tasks. If this activity could be done in front of your team/partners/clients/audience it will be better.

You should use code (or other specific) revisions mainly to improve your TEAM, expecting results on a middle/long term basis. This will affect your PROJECTS, but in the long term as a product of your TEAM improvement.

So, to answer your question, i believe you are trying to push too much from SCRUM, and you should better consider revisions only as it is.

Answer 5

Isn't it obvious to do code reviews before checking in your code?

TFS doesn't work like GIT, so whenever you check code in to a branch or the trunk, it is available for everyone.

This means the review should happen at check-in so bad changes aren't propagated to everyones working copy.