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