Setting the Record Straight: Modeling and XP

November 2001: Agile Modeling

From what I gather based on conversations on the Agile Modeling (AM) mailing list ( http://www.agilemodeling.com/feedback.htm ), there are several common misconceptions about modeling on an Extreme Programming (XP) project. They often result from secondhand knowledge of XP; questionable sources of information regarding XP; difficulty seeing beyond the current environment, or an assumption that the word "extreme" implies no modeling or no documentation at all. In this column, I plan to set the record straight.

Modeling Is Part of XP
User stories are a fundamental aspect of XP, and artifacts such as Class Responsibility Collaborator (CRC) cards are common to XP efforts. As reminders to discuss requirements with your project stakeholders, user stories provide a high-level overview of system requirements. They're also used as a primary input into estimating and scheduling, and they drive the development of acceptance test cases. CRC cards are employed to explore structure, perhaps for conceptual modeling to understand the problem domain, or for design to work through your software's structure. User stories and CRC cards are both models, so modeling is clearly a part of XP. Whenever user stories and CRC cards aren't the best option, XP developers will also create sketches, often on a whiteboard or a piece of paper. In his pioneering XP tome, Extreme Programming Explained: Embrace Change (Addison-Wesley, 2000), Kent Beck includes hand-drawn sketches of class diagrams and other free-form diagrams.

Documentation Happens
Documentation is also an important part of XP. Ron Jeffries, in his recent essay, "Essential XP: Documentation," offers the following advice: "Outside your Extreme Programming project, you will probably need documentation: by all means, write it. Inside your project, there is so much verbal communication that you may need very little else. Trust yourselves to know the difference."

This statement has several interesting implications. First and foremost, the XP community recognizes that documentation should be produced for people external to your team—people whom AM would term "project stakeholders." Second, it points out that verbal communication among team members reduces the need for documentation within the team—because communication is facilitated by the close proximity of XP team members, as well as by other XP practices, such as pair programming and collective ownership. Third, however, it recognizes that sometimes teams do require internal documentation. This is consistent with the advice presented in Jeffries, Anderson and Hendrickson's Extreme Programming Installed (Addison-Wesley, 2001), in which the authors suggest that important communications with your project stakeholders can be captured as additional documentation attached to the index card with the relevant user story on it. Fourth, it suggests that XP team members should know when documentation is required—and act accordingly. Fifth, it implies that you should trust your team and give them control over their own destiny.

In an XP project, documentation is a business, not a technical decision. This is consistent with the AM philosophy (see "Be Realistic About the UML"—link below), as summarized in October's Agile Modeling newsletter. Jeffries says it best: "If there is a need for a document, the customer should request the document in the same way that she would request a feature: with a story card. The team will estimate the cost of the document, and the customer may schedule it in any iteration she wishes." ("Essential XP: Documentation," 2001)

The final word? If you need documentation, go ahead and write it.

XP and the UML?
Two interesting questions regarding XP and the UML should be addressed:

Can you use UML with XP? Yes. You can apply the artifacts of the UML—activity diagrams, class diagrams, collaboration diagrams, component diagrams, deployment diagrams, sequence diagrams, statechart diagrams and use case diagrams—in an XP approach to development.
How do you use UML with XP? Minimally, you should apply AM's practice of Applying the Right Artifact(s) and use UML artifacts on your XP project only where appropriate. Ideally, you should apply all of the principles and practices of AM when doing so.

Wait a minute. One of AM's principles is Multiple Models, which suggests that your intellectual toolkit must possess modeling skills pertaining to a wide variety of artifacts. Yes, the artifacts of the UML are a good start, but unfortunately, the UML is not sufficient for the real-world needs of business application developers, although we are lucky to have far more than the artifacts of the UML at our disposal (see "Artifacts for Agile Modeling: The UML and Beyond"). The problem, then? If the UML is not sufficient for the development of business applications, and if you're trying to develop such an application following the XP methodology, perhaps "How do you use UML with XP?" is the wrong question. Instead, try asking, "How do you model on an XP project?"(see "Agile Modeling and Extreme Programming").

References and Recommended Resources:

The Agile Modeling Home Page, Scott W. Ambler.
http://www.agilemodeling.com
This site describes the current state of the art for the Agile Modeling methodology.

"Agile Documentation," Scott W. Ambler. http://www.agilemodeling.com/essays/agileDocumentation.htm
This essay explores critical issues in effective document creation, including valid and invalid reasons for creating documentation, what "agile documentation" and "traveling light" really mean, and how can you make this advice work for you in practice.

"Agile Modeling and Extreme Programming (XP)," Scott W. Ambler. http://www.agilemodeling.com/essays/agileModelingXP.htm
This essay describes how to apply AM practices effectively on an XP project.

"Be Realistic About the UML," Scott W. Ambler. http://www.agilemodeling.com/essays/realisticUML.htm
Although the UML does describe an important subset of what you do need, it's not yet sufficient for business application development—and while Executable UML (xUML) sounds good, it may not live up to its promise.

"Artifacts for Agile Modeling: The UML and Beyond," Scott W. Ambler. http://www.agilemodeling.com/essays/modelingTechniques.htm
This essay presents a list of candidate modeling techniques, including the artifacts defined by the UML as well as structured modeling techniques such as data models and data flow diagrams (DFDs) and essential modeling techniques.

Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Scott W. Ambler
http://www.ambysoft.com/agileModeling.html
This book, to be published in February 2002, is the first ever written about the AM methodology.

Extreme Programming Explained: Embrace Change, Kent Beck (Addison-Wesley, 1999). http://www.amazon.com/exec/obidos/ASIN/0201616416/ambysoftinc
This is the seminal XP book, describing its principles, practices and philosophies. It's a must-read for anyone interested in XP.

"For Use: The Web Site for Practitioners of Usage-Centered Design," Larry Constantine and Lucy Lockwood
http://www.foruse.com
This Web site is a forum for professionals interested in software and Web usability, user interface design, user role models, use cases and task modeling, content and navigation models, user interface architecture and usability inspections.

Extreme Programming Installed, Ron Jeffries, Ann Anderson and Chet Hendrickson, (Addison-Wesley, 2000).
http://www.amazon.com/exec/obidos/ASIN/0201708426/ambysoftinc
This book describes how to apply XP within your project team.

"Essential XP: Documentation," Ron Jeffries. http://www.xprogramming.com/xpmag/expDocumentationInXp.htm
This essay, written by one of the leading XPerts in the industry, describes important philosophies and practices for effective documentation practices on XP projects.

More Insights

INFO-LINK

Agile Modeling


	To upload an avatar photo, first complete your Disqus profile. \| View the list of supported HTML tags you can use to style comments. \| Please read our commenting policy.