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 teampeople whom AM would term "project stakeholders."
Second, it points out that verbal communication among team members reduces the
need for documentation within the teambecause 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 requiredand
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 UMLactivity
diagrams, class diagrams, collaboration diagrams, component diagrams, deployment
diagrams, sequence diagrams, statechart diagrams and use case diagramsin
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 developmentand 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.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.