 |
To understand AM you need to understand
the difference between a model and an agile model. A
model is an abstraction that describes one or more
aspects of a problem or a potential solution addressing
a problem. Traditionally, models are thought of as zero
or more diagrams plus any corresponding documentation.
However non-visual artifacts such collections of CRC
cards, a textual description of one or more business
rules, or the structured English description of a
business process are also considered to be models. An
agile model is a model that is
just barely good enough.
But how do you know when a model is good enough?
|
|
Agile models are good enough when they exhibit
the following traits:
1. Agile models fulfill their purpose.
Sometimes you model to communicate, perhaps you
need to communicate the scope of your effort to senior
management, and sometimes you model to understand,
perhaps you need to determine a design strategy to
implement a collection of Java classes. For an agile model to be sufficient it clearly must fulfill
the purpose for which it is created.
2. Agile models
are understandable. Agile models are understandable
by their intended audience. A requirements model will be written in the language of the
business that your users comprehend whereas a technical
architecture model will likely use technical terms that
developers are familiar with.
The modeling notation that you use affects
understandability – UML use case diagrams are of no
value to your users if they don’t understand what the
notation represents.
In this case you would either need to use another
approach or educate them in the modeling technique.
Style issues, such as avoiding crossing lines,
will also affect understandability – messy diagrams
are harder to read than clean ones. The level of
detail in your models, see below, can also affect
understandability because a highly detailed model is
harder to comprehend than a less detailed one.
Simplicity, see below, is similarly a factor that
affects understandability.
3. Agile
models are sufficiently accurate.
Models often do not need to be 100% accurate,
they just need to be accurate enough. For example, if a street map is missing a street, or it shows
that a street is open but you discover it's closed for
repairs, do you throw away your map and start driving
mayhem through the city? Likely not. You
might decide to update your map, you could pull out a
pen and do it yourself or go to the local store and
purchase the latest version (which still might be out of
date), or you could simply accept that the map isn't
perfect but still use it because it is good enough for
your purposes – you can use it to get around because
it does accurately model most of the other streets in
your town. The reason why you don't discard your
street map the minute your find an inaccuracy is because
you don't expect the map to be perfect nor to you need
it to be. Similarly, when you find a problem in
your requirements model, or in your data model, you
would choose to either update the model at that point or
accept it as it is – good enough but not perfect.
Some project teams can tolerate inaccuracies
whereas others can't: the nature of the project, the
nature of the individual team members, and the nature of
the organization will decide this.
Sufficient accuracy depends both on the audience
of the model as well as the issues that it's trying to
address.
When I was a
teenager I worked in restaurants, starting out as a
dishwasher and working my way up to swing manager.
As a swing manager I was taught how to close out
the restaurant for the day, an important part of which
was closing the till at the end of the day.
The manager who taught me this was a firm
believer in having an accurate count of the money in the
till, and if it didn’t add up exactly to the sales for
the day we needed to recount.
Not only did this include counting the paper
money but the coins as well, an effort that on average
took twenty minutes each evening. A few months later she transferred to another restaurant and
a new manager took over.
We were closing together one night and he saw me
counting the coins and couldn’t believe I was wasting
my time counting them one by one.
He then showed me how he counted coins – in his
hands he’d pick up each denomination of coin one at a
time, look at them, guess how much they added up to, and
as long as his count was within a few dollars he’d
accept it and move on.
A twenty-minute activity was reduced to five
minutes because he realized that his count just needed
to be close and not exact.
He was getting home fifteen minutes earlier six
nights a week fifty weeks a year, a savings of
seventy-five hours a year over a thirty year career.
4. Agile
models are sufficiently consistent.
An agile model does not need to be perfectly
consistent with itself or with other artifacts to be
useful. If
a use case clearly invokes another in one of its steps
then the corresponding use case diagram should indicate
that with an association between the two use cases that
is tagged with the UML stereotype of
<<Include>>.
However, you look at the diagram and it
doesn’t! Oh
no, the use case and the diagram is inconsistent!
Danger Will Robinson, Danger!
Red alert! Run
for your lives! Wait
a minute, your use case model is clearly inconsistent
yet the world hasn’t come to an end.
Yes, in an ideal world all of your artifacts
would be perfectly consistent, but no, it often
doesn’t work out that way.
When I’m building a simple business application
I can tolerate some inconsistencies.
Granted, sometimes I can’t tolerate
inconsistencies – witness NASA’s recent learning
experience regarding the metric and imperial measuring
systems when they accidentally slammed a space probe
into Mars in 1999.
The point to be made is that an agile model is
consistent enough and no more, you very often do not
need a perfect model for it to be useful.
Regarding accuracy
and consistency there is clearly there is an entropy
issue to consider here as well. If you have an
artifact that you wish to maintain, what I call a
“keeper”, then you will need to invest the resources
to update it as time goes on.
Otherwise it will quickly become out of date and
effectively useless to you. For example, I can
tolerate a map that is missing one or two streets but I
can't tolerate one that is missing three quarters of the
streets in my town.
There is a fine line between investing just
enough effort to keep your artifacts accurate enough,
investing too much effort that you are needlessly
slowing your project efforts down, and not investing
enough to keep your artifacts useful to you.
5.
Agile models
are sufficiently detailed.
A road map doesn't indicate each individual house
on each street. That
would be too much detail and thus would make the map
difficult to work with. However, when a street is being
built I would imagine the builder has a detailed map of
the street that shows each building, the sewers,
electrical boxes, and so on in enough detail that makes
the map useful to him. This map doesn’t depict
the individual patio stones that make up the walk way to
each, once again that would be too much detail.
Sufficient detail depends on the audience and the
purpose for which they are using a model – drivers
need maps that show streets, builders need maps that
show civil engineering details.
Consider an
architecture model.
Depending on the nature of your environment a
couple of diagrams drawn on a whiteboard that are
updated as the project goes along may be sufficient.
Or perhaps several diagrams drawn using a CASE tool is
what you need. Or
perhaps the same diagrams supported with detailed
documentation is required.
Different projects have different needs.
In each of these three examples you are in fact
developing and maintaining a sufficiently detailed
architecture model, it's just that "sufficiently
detailed" depends on the situation.
6.
Agile models
provide positive value.
A fundamental aspect of any project artifact is
it should add positive value. Does the benefit
that an architecture model brings to your project
outweigh the costs of developing and (optionally)
maintaining it? An
architecture model helps to solidify the vision to which
your project team is working towards, which clearly has
value. But,
if the costs of that model outweigh the benefits, then
it no longer provides positive value.
Perhaps it was unwise to invest $100,000
developing a detailed and heavily documented
architecture model when a $5,000 investment resulting in
whiteboard diagrams would have done the job.
7.
Agile models
are as simple as possible.
You should strive to keep your models as simple
as possible while still getting the job done.
Simplicity is clearly affected by the level of detail in
your models, but it also can be affected by the extent
of the notation that you apply. For example, UML
class diagrams can include a myriad of symbols,
including Object Constraint Language (OCL), yet most
diagrams can get by with just a portion of the notation.
You often don't need to apply all the symbols available
to you so limit yourself to a subset of the notation
that still allows you to get the job done.
Therefore, the
definition is:
An agile model is a model that
fulfills its purpose and no more; is understandable to
its intended audience; is simple; sufficiently accurate,
consistent, and detailed; and investment in its creation
and maintenance provides positive value to your project.
An agile
definition is:
An agile model
is a model that is
just barely good enough.
A common
philosophical question is whether or not source code is
a model, and more importantly is it an agile model.
If you were to ask me outside of the scope of
this writing effort my answer would be yes, source code is a
model, albeit a highly detailed one, because it clearly
is an abstraction of your software.
I would also claim that well written code is an
agile model. Be
that as it may I will distinguish between
source code and agile models for the simple reason that
I need to treat the two different from one another –
agile models help to get you to source code.
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
|
|
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full description of
what I do, and how to contact me, can be
found here.
|
