Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Mar 8 '11 at 20:31

This question came from our site for professional and enthusiast programmers.

add comment

5 Answers

up vote 3 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
I was wondering when someone was going to mention pairing. Between that and unit testing you get a lot of review. –  JeffO Mar 8 '11 at 21:39
    
I read this as "stand up, fire someone, and ask them to come over and discuss the code you have just developed." Thanks for making my day. –  Will Morgan Sep 4 '12 at 15:56
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Scrum doesn't say or advise anything regarding schedule. It does expect you to deliver value on a regular basis. It also provides moments in which you can inspect and adapt your process so as to get better (better not necessarily meaning faster). –  Ryan Cromwell Mar 8 '11 at 21:36
    
Yes, Scrum does not state making a full schedule as part of it. Still, i meant "planning" when i refered to schedule, planning meaning that your client expects some value in a given time, so they could perform the exchange between money v/s value (if you consider that you are providing develop/programming services). –  Ron-Damon Mar 8 '11 at 21:42
    
In that matter, your client should have a budget to spend in a given time (to pay you, for instance) and he may have a schedule to attend to. I work as a service provider, that's why i cannot left this fact aside. –  Ron-Damon Mar 8 '11 at 21:50
    
Contracts aside, Scrum teams deliver value not services. We develop/program as a means to deliver that value. –  Ryan Cromwell Mar 8 '11 at 21:59
    
I don't believe you could separate the terms "value" and "service" friend. I also believe this is very off-topic now. –  Ron-Damon Mar 8 '11 at 22:14
show 2 more comments

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.

share|improve this answer
    
I would think that, in general, unit tests are what would prevent bad changes. –  John Saunders Mar 8 '11 at 19:59
    
@John Saunders: Consider code reviews as another type of unit test. –  Gilbert Le Blanc Mar 8 '11 at 20:00
    
@Gilbert: I could do that, but then I wouldn't get their benefit for regression testing. I'd prefer to spend the time on writing more and better unit tests. –  John Saunders Mar 8 '11 at 20:02
    
@John Saunders, @Gilbert Le Blanc code reviews are performed by another developer, unit test are generally done by the original developer, the new perspective can be vital. –  whatsthebeef Mar 8 '11 at 20:08
    
I've had good luck with unit tests (the test lists are agreed ahead of time) and automated code analysis, possibly combined with a style analysis tool like StyleCop. But then, I don't often work with junior developers. –  John Saunders Mar 8 '11 at 20:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.