| Newsgroups |
gmane.comp.programming.scrum.general |
| Organization |
Lean-Agile Partners, Inc. |
| Message-ID |
<[email protected]> |
Hi Esther,
On 10/2/15, 3:59 PM, Adam Sroka [email protected] [SCRUMDEVELOPMENT]
wrote:
> Do them as a group, like an actual review. Put the whole team in a room
> with a projector and critique a piece of everybody's work. That way you
> actually learn something. Plus, like I said, reviews are a remedy for not
> working on the code as a team. So, this is a gentler way to introduce that
> versus forcing people to pair.
>
> On the other hand, if you are sitting alone commenting on your teammate's
> code with a tool you are certainly doing it wrong. Not only are you missing
> an opportunity for a productive conversation, but you are reinforcing a
> culture of low fidelity communication and information hiding.
Just want to "second" what Adam has commented here. My own team moved
from waterfall to Agile by this route and quickly jelled as a team
through holding sessions all together with the code viewable by all on a
projector, as he describes.
We started by holding code reviews according to all the published
advice (because I was convinced by the data on it and thought we should
try it) - we'd set up a meeting, distribute the subject code beforehand,
then all show up to give their comments. It was very hard to schedule
everyone. By the time we did, the comments weren't very valuable. Our
tracking showed that we missed some problems even in the reviewed code.
So we shifted to the live sessions where we'd get together quickly,
make some mods to the code and explain why, and what other options there
were... we'd create some changes to our coding standard when all were
mentally in synch and agreeing on some improved way. This was immensely
valuable, but was no longer a "code review" in the original sense.
In fact, our Agile tests and tripwires in the code were more
effective at catching certain kinds of defects than the reviews were.
Our defect tracking proved that. The group sessions were tops for
creating shared understanding and common purpose. This plus the
automatic tests were why we stopped doing code reviews in the form that
is commonly called a code review. (I also agree with Wouter's comment
that they are not really reviews.)
Essentially, code review is better than cowboy coding, but both are
ancient history. Use a mob programming session.
- njv
--
............................................
Agile hardware? Yes! Agile safety-critical Embedded Systems too
Nancy Van Schooenderwoert, Lean-Agile Partners Inc.
US mobile: 781 301 1822 [email protected]
Twitter: @vanschoo http://www.leanagilepartners.com
............................................
------------------------------------
Posted by: Nancy Van Schooenderwoert <[email protected]>
------------------------------------
To Post a message, send it to: [email protected]
To Unsubscribe, send a blank message to: [email protected]