[Fwd: SD's Agile Modeling: Setting the Record Straight--Modeling and XP]

[Bradford Castalia <Castalia@azstarnet.com>]

Now that we've embarked on "ICL-lite" as an "extreme programming"
project I'd like to make a few comments.

First, I'm trying to contain my enthusiasm for this project while
sharing the enthusiasm that I'm experiencing coming from you. Not
only am I looking forward to a successful outcome, but I'm also
anticipating having fun with you all along the way. :-) We seem
to have started out well. We have a good combination of skills
and, I hope, our complementary interests will propel us across
the rough spots.

Having started well I'd like to be sure we stay "real". Our
complementary interests may be subject to stresses that, if we
can anticipate them, may be turned to our advantage. Perhaps
the most obvious potential for divergence is in how we deal with
the do-it-now vs do-it-right dilemma. Compromises will need to be
made to strike a good balance.

By declaring this an XP project we are implicitly suggesting how
we are going achieve the needed balance in a dynamic and
constructive way. Still, XP is intended to achieve do-it-right by
accomplishing a lot of do-it-now. And it does this with a set of
techniques that involve significant, if perhaps somewhat
"unorthodox", disciplines. While we are not working in the context
of a commercial enterprise and, at this point, we are our own
clients, there are specific activities that we might want to
consider undertaking.

Communication is crucial to XP. This is typically achieved by the
closeness of the participants; to the extent of requiring paired
programmers to share a workstation in some cases. We're not that
close. But we must establish and maintain close communication. I
suggest we establish an email list - we can call it ICL-XP (or
whatever) - and use it often and without reservation. The intent
is to use it like we were working in the same room and just blurt
out whatever comes to mind about the project.

Running use cases (what I've been calling scenarios) and assembling
class cards (what we've been calling interface definitions) are
also important activities. In a business situation we'd put in at
least a full day (probably more) doing this to launch the project,
and then iterate this often as the project progresses. Our weekly
meetings are good, but it is going to be a challenge to thoroughly
run the use cases and assemble effective class cards with such
short, spaced interaction without getting frustrated and resorting
to ad hoc hacking.

The email newsletter below (sans advertising) raises and addresses
the kinds of issues we face. It is specifically targeted towards
people involved in XP projects and promotes "Agile Modeling" as a
means to achieve the necessary balance by using techniques that
have been shown to be effective. Our scale, of course, is much
smaller, but the issues are essentially the same. And the
techniques work just as well when adapted to our scale. I think
that we are already doing some of the things, in our own fashion,
that Agile Modeling and XP call for. Perhaps you'll see things
here (including amongst the numerous references that Scott Ambler
offers) that you think would be worth using in our project.

It's good to be working with you!

BC


-------- Original Message --------
Subject: SD's Agile Modeling: Setting the Record Straight--Modeling and XP
Date: Fri, 30 Nov 2001 16:00:00 -0700
> From: Agile Modeling <agilemodeling@softwaredevelopment.email-publisher.com>
To: castalia@azstarnet.com

November 2001
Setting the Record Straight: Modeling and XP

Welcome to the Agile Modeling newsletter, edited by Software
Development Senior Contributing Editor Scott Ambler. This monthly
e-mail newsletter is a free service for subscribers to Software
Development magazine and SD Online.


Setting the Record Straight about Modeling and XP

>From what I gather based on conversations on the Agile Modeling (AM)
mailing list (
http://click.softwaredevelopment.email-publisher.com/maaaeBraaQGK2a9GNF8b/
), 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" (see link below), 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.

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:

1. 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. 

2. 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"--link
below). 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"--link below.)

*********************************************** 

References and Recommended Resources:

The Agile Modeling Home Page, Scott W. Ambler.
http://click.softwaredevelopment.email-publisher.com/maaaeBraaQGK4a9GNF8b/
This site describes the current state of the art for the Agile Modeling
methodology.

"Agile Documentation," Scott W. Ambler.
http://click.softwaredevelopment.email-publisher.com/maaaeBraaQGK5a9GNF8b/
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://click.softwaredevelopment.email-publisher.com/maaaeBraaQGK6a9GNF8b/
This essay describes how to apply AM practices effectively on an XP
project.

"Be Realistic About the UML," Scott W. Ambler.
http://click.softwaredevelopment.email-publisher.com/maaaeBraaQGK7a9GNF8b/
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://click.softwaredevelopment.email-publisher.com/maaaeBraaQGK8a9GNF8b/
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://click.softwaredevelopment.email-publisher.com/maaaeBraaQGK9a9GNF8b/ 
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://click.softwaredevelopment.email-publisher.com/maaaeBraaQGLaa9GNF8b/
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://click.softwaredevelopment.email-publisher.com/maaaeBraaQGLba9GNF8b/
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://click.softwaredevelopment.email-publisher.com/maaaeBraaQGLca9GNF8b/ 
This book describes how to apply XP within your project team.

"Essential XP: Documentation," Ron Jeffries.
http://click.softwaredevelopment.email-publisher.com/maaaeBraaQGLda9GNF8b/ 
This essay, written by one of the leading XPerts in the industry,
describes important philosophies and practices for effective
documentation practices on XP projects.

***********************************************

GET THE MAGAZINE
If you are a professional software developer, you may qualify for a
free subscription. Find out more at
http://click.softwaredevelopment.email-publisher.com/maaaeBraaQGLfa9GNF8b/

FEEDBACK AND PROBLEMS
Send letters to the editor to aweber@cmp.com.
Send technical questions or problems to webmaster@sdmagazine.com.

AGILE MODELING is a monthly newsletter brought to you by CMP Media LLC,
publisher of Software Development magazine.

Copyright 2001 CMP Media LLC