The Intended Benefits of Mob Programming in the Context of XP


The four stated "values of XP" in Kent Beck's Extreme Programming Explained are communication, courage, feedback, and simplicity [Beck2000]. Mob programming provides an opportunity for maximal feedback and communication. During meetings, the entire team shares ideas about all aspects of code design. For part of the meeting, we split into two groups small enough that everyone can be involved in the discussion at some level. Then when we regroup, each developer has an opportunity to share those discussions with everyone else on the team. By looking at a different piece of randomly chosen code each week, all developers get feedback on coding and design decisions they have made in the past, without being singled out. Also, during refactoring and wrap-up, our peers review the programming decisions we make during the meeting. Naturally, discussions that begin during mob programming can continue outside the meetings, fostering an atmosphere of greater communication. We also hope that working together in this way may make us more open to pair programming outside the meetings.

Mob programming also fosters the value of courage. At one time, we merely looked at code during meetings. Now we change it on the spot, as soon as we see something that can be improved. It is important that we actually change code during the meeting, because this active engagement of the material promotes thought and discussion instead of passive spectatorship. We also encourage throwing away the code at the end of the meeting if the group feels that the changes made are not an improvement. We try to rotate the roles of driver and narrator throughout the group so that each developer has an opportunity to be courageous. Honest, open discussion is promoted during meetings, so opinions that may not be expressed outside of meetings (such as a deeply divided opinion within the group about a design decision) are confronted.

To be able to change code courageously, good test coverage is necessary. The test coverage of our code increases as a function of the meetings, because the previewers must make sure it is adequate before the meeting begins. Also, while we are changing code during meetings, the value and practice of testing can be reinforced.

Finally, our meetings value simplicity. The atmosphere has always been informal. We incrementally add structure only when we feel it is necessary. For example, we have found that we must preview the code. If we do not, the meeting is often spent debugging someone's application configuration, trying to get one test to succeed. Such episodes try everyone's patience and are totally unproductive. Also, by ensuring that there are already working tests, previewing makes it much easier to add tests as needed while refactoring. Finally, it is important that a couple of people have already looked at the code in some detail before the meeting, because the person who wrote the code may not be present and thus be unable to play the narrator role. Having a couple of people who understand the present state of the code helps start discussion. E-mailing the code in the body of an e-mail message to everyone in the group has also been successful in acquainting people with the code before the meeting so that people are more ready to begin discussion. We have found this much structure to be useful. We are always ready to remove any structure that turns out to be unnecessary.

We note finally that we have experimented both with two groups/projectors and one group/projector. One projector is a little easier to manage logistically. However, because our group is composed of about ten developers, having only one point of focus can make it difficult to include everyone in the process. With two projectors, we can try several different, generally more engaging formats. We can follow the format described earlier: split into two teams, each of which comes up with its own refactoring of the code, which is then compared with the other team's and discussed. We have found this format to be the most successful. We have also tried having one team refactor and the other team write tests. This latter format suffers from the problem that to refactor, you need working tests. Conversely, once you have written the necessary tests for the next refactoring step, often you must wait for that refactoring to occur before it makes sense to write additional tests. One team ends up waiting for the other. In any case, having two points of focus involves more people and shares the roles played more broadly within the group. Also, having two groups increases the diversity of ideas that are presented during the meeting.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net