|
|
I firmly believe that you should test often and early, that if you can build something, you should validate it, and that if something isn't worth validating, it isn't worth building. These tenets pertain to agile models as well as other development artifacts. Although most agile models are discarded almost immediately--for example, whiteboard sketches are typically erased a few minutes after being drawn--some agile models evolve to become part of your permanent documentation. Therefore, it makes sense to validate these models.
There are several model validation strategies to choose from:
-
Implicit reviews. This review occurs as part of another activity within your software process; for example, the combination of Extreme Programming (XP)'s Pair Programming and Collective Ownership practices. On an XP project, everyone can work on any part of the code--and as a side effect, the code is continually being reviewed; with pair programming, at least two pair of eyes examine each line of code. Implicit reviews also work in Feature-Driven Development (FDD), which prompts developers to pow-wow with domain experts before breaking into smaller groups to create domain object models; then reforming to compare and combine the results in a follow-up modeling session. This follow-up modeling session is arguably an implicit review.
-
Impromptu model reviews. This is the most common technique for validating models, as it's the easiest to organize, often the result of a simple request such as "Sally and John, could you spend a few minutes looking at this diagram?" In this review, you show your work to a few people, get some quick feedback, update your work accordingly and then move forward.
-
Playacting. With this approach, your project stakeholders simulate working with the system based on the vision described in the models. With usage scenario testing, you take a scenario (perhaps part of a use case or several use cases in combination) and work through it a step at a time, following the logic through your domain model. I've used this technique effectively on several projects, having users walk through the responsibilities described in an object domain model.
-
Informal model reviews. This style of review is often called a walkthrough. Informal reviews are scheduled a few days ahead of time, and the material to be reviewed is made available before the review. Informal reviews often become modeling sessions in their own right because discussion between the reviewers and the creators of the model is encouraged. This is particularly applicable when the group decides to discuss potential solutions to identified issues.
-
Formal model reviews. Formal reviews are rigorous, with review agendas and formal review packages distributed before the review and minutes distributed afterward. A trained facilitator leads a formal review and reviewers follow predefined procedures. The goal is to identify problems, but not solutions, and in many formal reviews, the modelers are not allowed to interact with the reviewers.
Although these techniques are presented in the order of potentially most agile to potentially least agile, in the right situation, a formal review may be the most agile option available to you. For example, a team working on an air traffic control system may be required by federal regulations to submit to a series of reviews. Agility is relative: Depending on how you approach these reviews, they could be little more than an effort to conform to regulations, or very productive and valuable.
When developers and project stakeholders work together closely, you'll discover that your work is being validated as a matter of course and that specific reviews aren't as necessary as in lone-wolf efforts. You have several options for validating models, including several styles of reviews and several play-acting techniques. By keeping your approach simple, by focusing on communication and people issues, and by having a outlook, you'll find that you can easily validate models in an agile manner.
Recently on the Agile Modeling Mailing List:
Support for Maintenance
A few weeks ago, it was pointed out that maintenance issues
aren't often discussed within the agile community. Unfortunately,
this seems to be true, although there's some excellent material
out there. I pointed out that Agile Modeling (AM) includes a very
good discussion of agile documentation techniques for writing
effective system documentation. Charlie Poole and J.W. Huisman
have also written about their maintenance experiences at IONA
after the adoption of XP, describing how maintenance actually
became easier. Another list member said that agile's emergent
approach can be a better option than a traditional big-design
up-front (BDUF) approach when replacing a poorly documented
legacy system--a topic I'm sure someone will discuss in detail in
the future.
Are Use Cases Valid for All Systems?
This question was posed to the group, and it seems to be a
recurring theme in the IT community, as people seem to regularly
ask various flavors of it in modeling-oriented newsgroups.
Experience shows that when you want to describe how your users
work with your system, use cases are a good option. However, if
your users don't understand use cases, or if your underlying
process expects another type of artifact--for example, XP
requires user stories and FDD requires features--use cases aren't
a good option. The AM principle Multiple Models tells you that
you have a choice of artifacts, and its practice Apply the Right
Artifact(s) advises you to pick the best one(s) for the job.
Therefore, use cases aren't always valid, although in many cases,
they're a very good option.
Limits of Communication
An interesting conversation started when someone pointed out that
in some circumstances, pictures communicate some things, to some
people, better than words. In other situations, words communicate
some things, to some people, better than pictures. Hence,
diagrams aren't always your best option, and your audience will
often determine how you'll render your models. Knowing your
audience is one aspect of AM's Model with a Purpose principle,
and the principle Content Is More Important than Representation
provides the "wiggle room" to move away from official notations
such as the UML to use the approach best suited to your
audience's needs.
Hot Links:
"Agile Documentation" by Scott W. Ambler.
www.agilemodeling.com/essays/agileDocumentation.htm
Agile Modeling Mailing List.
www.agilemodeling.com/feedback.htm
Cutter IT Consortium's Agile Home Page.
www.cutter.com/itjournal/agile.html
Link to a more detailed discussion of agile model validation from
this page.
"Extreme Maintenance" by Charles Poole and Jan Willem Huisman.
www.xpuniverse.com/2001/pdfs/Method02.pdf
Extreme Programming Explained--Embrace Change by Kent Beck
(Addison-Wesley, 2000).
www.amazon.com/exec/obidos/ASIN/0201616416/ambysoftinc/103-7190775-8163854
"A Lightweight Methodology for Design and Code Reviews" by Alan
Shalloway and Rhett Alden.
www.netobjectives.com/download/design%20reviews.PDF
The Object Primer, 2nd Edition: The Application Developer's Guide
to Object Orientation by Scott W. Ambler (Cambridge University
Press, 2001).
www.ambysoft.com/theObjectPrimer.html
"Object Testing Patterns" by Scott W. Ambler (Software
Development magazine, July 1999).
www.sdmagazine.com/documents/s=756/sdm9907o/9907o.htm
A Practical Guide to Feature-Driven Development by S. Palmer and
J.M. Felsing (Prentice Hall, 2002).
www.amazon.com/exec/obidos/ASIN/0130676152/ambysoftinc
