I am going through a great book right now.
Extreme Programming Perspectives.
It's a collection of write ups on Extreme Programming from
2002. A lot of them are very practical
and have some great ideas on how to do XP or to introduce it to a team.
Mob Programming
One article that I found very interesting and full of good
ideas was "Mob Programming and the Transition to XP" by Moses M.
Hohman and Andrew S. Slocum (found a link to a pdf post http://cf.agilealliance.org/articles/system/article/file/998/file.pdf
[1])
The article is only 5 pages… go ahead and read it J
"Mob" programming is pretty much what it sounds
like… You get your Dev team in a room and you… the mob… refactor some code…
But wait…
That sounds really, really inefficient …
10 guys and one keyboard and one screen! Insane!
You've brought pair programming to an even more insane level!
But that is not the real idea.
The Idea
I think the "Mob" programming idea can fulfill the
following goals
- Team Building
- Teaching the Team XP
- Test Driven Development
- The value of pairing
- Team ownership of the code
- Cross Training
So how do you do it?
Read the pdf for more details, but here is my short take on
it.
- Randomly select a piece of code (class).
- Find out who "owns" this code
- Give them some time to refresh their memory on how the code works.
- Give them some time to update test cases for the piece of code (They may even need to create the first test cases ever for this code)
- Prep for the mob (set up 2 machines in your conference room)
- Have the code "owner" present the code and explain what it does.
- Split into two groups (3-6 per group)
- give both groups 30-45 minutes to refactor the code (every mob member contributes)
- Bring the groups back together to present their refactored code.
- Decide which refactored code, if any, to keep
I think this type of "mob" programming meeting can
really benefit a group with little or no XP experience, even groups with no
test cases.
To get a team from nothing to a group of testing, pairing, XP
ninjas they need to learn the tools and be convinced of their benefits. I think this type of "mob" meeting
allows both to occur. It even allows it
to occur gently over time without needing to drink the kool-aid on the first
day.
But it's going to take some time. The first 2-4 meetings are just a warm up,
your group is going to trip, fall, skin their knees and even complain. But if they stick to it, I think it will
serve as a valuable tool to transform a development team and get them closer to
XP.
For those teams who are already pairing XP ninjas. I think this can be great for knowledge
share, team building, and building team code ownership.
References
[1] Mob Programming and the
Transition to XP
Moses M. Hohman, Andrew S.
Slocum
Accessed
08/2015
This post is a part of and epic, the Pair Programming Epic.
Epic Goal: Learn the art of pair programming.
No comments:
Post a Comment