Saturday, April 19, 2014

Agile in a Flash 30

ABCs of Pair Programming The Team
Agile in a Flash by Jeff Langr and Tim Ottinger (card #30)

> All production code
...must be developed by a pair
> Both parties contribute to the solution
...switching roles between “driver” and “navigator” frequently
> Change pairs frequently
...once to three times per day
> Develop at a comfortable workstation
...that accommodates two people side by side
> End pairing when you get tired

Constrain to no more than three-fourths of your workday

--

Pair programming—two programmers jointly developing code(7)—can be an enjoyable practice that results in better-quality solutions. Follow our ABCs of pairing to avoid applying it as a practice that’s neither effective nor fun.

Pairing on production code is a must—it’s a form of review—but you can still work solo on other tasks. See Card 32, When Not Pairing.

Pairing is not one person watching over another programmer’s shoulder. That seems like it would be a waste of time! Pairing instead is “two heads” collaborating on a better solution than either alone would produce.

The least obvious and most abused rule is that pairs should not remain joined at the hip for days at a time or more. That’d just result in more workplace violence! Instead, ensure that at least three people, not just two, contribute to and review a solution. This creates some context switching overhead, but adherence to agile quality practices (particularly TDD and refactoring) will minimize the overhead.

Pairing must be enjoyable and comfortable to be sustainable. Make sure your environment isn’t causing you pain, and don’t overdo it. We advise also keeping refreshing mints or gum on hand.

--
7. Lisa Crispin reminds us that pairing also works well for other efforts, including designing tests.

(Pair programming may or may not fit your team needs)


No comments:

Post a Comment