 |
One of the more controversial concepts in Agile
Modeling is that
agile models and
agile documents
are sufficient for the task at hand, or as I like to say
they are "just barely good enough (JBGE)". In
this article I make the following critical points about a
model or document (an artifact) being just barely good
enough:
|
|
For some reason people think that JBGE
implies that the artifact isn't very good, when in fact
nothing could be further from the truth. When you
stop and think about it, if an artifact is JBGE then by definition it is at the most
effective point that it could possibly be at.
Figure 1 summarizes the value curve for an
artifact being just barely good enough. Value
refers to the net benefit of the artifact, which would
be calculated as benefit - cost. The
dashed line is at the point where the artifact is JBGE: anything to the left of the
line implies that you still have work to do, anything to
the right implies that you've done too much work.
When you are working on something and it isn't yet
sufficient then you can still invest more effort in it
and gain benefit from doing so (assuming of course you
actually do work that brings the artifact closer to it's
intended purpose). However, if an artifact is
already JBGE (or better) then doing more work on it is clearly
a waste: once an artifact fulfills its intended purpose
then any more investment in it is simply busy work.
The diagram is a little naive because it is clearly
possible for the value to be negative before the
artifact becomes barely good enough although for the
sake of argument I'm going to assume that you do a good
job right from the beginning.
Figure 1. Cost analysis of
just barely good enough.
Ideally all of your artifacts should be JBGE, as you see in the diagram.
Unfortunately, it isn't an ideal world. You'll
often put too much effort into an artifact,
unintentionally overshooting the mark as you work on it. For example,
do I really need the arrowhead on the rightmost end of
the value curve in Figure 1?
If not, then the diagram is more than just barely good
enough. Agile modelers are only human and they are
not always going to do a perfect job, so realistically
some artifacts are going to be more than just barely
good enough. The secret is to learn how to detect
when you've reached the point of something being just
barely good enough and then to stop working on it.
Easy to say, hard to do.
2. Just Barely Good Enough is
Situational
The fundamental challenge with JBGE is situational. For example, I often drawn
UML Sequence diagrams on a whiteboard to explore
complex logic and then
discard it once I'm done with it. In this case
the whiteboard diagram is fine because it helps me to
solve the issue which I'm thinking through with
whomever I'm working. But, what if we're in a
situation where we'll need to update this logic later on
AND will want to do it via the diagram instead of via
source code? Clearly a hand-drawn sketch isn't
good enough in this case and we'll want to create a
detailed diagram using a sophisticated
CASE tool.
We'd still create an agile model even though it is much
more sophisticated than a sketch because JBGE reflects the needs of the situation
(remember, agile modelers
Model With A Purpose).
To
determine if
an artifact
is JBGE you
must
actively
work with
the direct
audience of
that
artifact.
In the case
of system
overview
documentation
that would
be the
maintenance
programmers,
in the case
of a user
manual that
would be the
end users,
and in the
case of a
sketch
sequence
diagram that
would be the
programmer
implementing
the
corresponding
code.
Without
knowing what
the audience
wants, you
cannot
realistically
create
something
which is
JBGE,
putting you
in a
situation
where you're
motivated to
put far more
effort into
the artifact
than you
need to.
This often
proves to be
wasted
effort,
because
chances are
very good
that the
artifact
will fall
prey to the
"they
aren't going
to read it
(TAGRI)"
principle.
To ensure
that you
know what
the audience
of an
artifact
wants, you
need to
ensure good
communication
with them
and better
yet strive
for
active
stakeholder
participation.
Some people seem to think that artifacts which are
JBGE will be of low quality. The reality is that
they are of
sufficient quality for the job at hand. This isn't
an excuse for doing a poor quality job because quality
is in the eye of the beholder: the audience for an
artifact determines if it is sufficient, not the creator
of it. If your stakeholders require an excellent,
detailed artifact then it is JBGE when it reaches that point of
being excellent and detailed.
An artifact can move along this value curve in both
directions throughout it's lifecycle. Your needs
may change, becoming either more complex or less so, and
therefore you may choose to update your artifact(s)
accordingly. If the artifact becomes less than
good enough then you will need to consider updating it.
If an artifact is more than good enough should you
rework it? Only if it is harming your efforts
elsewhere. For example, a hand drawn diagram would
have been sufficient for Figure 1
although at the time that I drew it I didn't have easy
access to any writing materials (such as paper or a
whiteboard) so I used Microsoft Visio instead. Later,
when I did have access to such materials I didn't bother
to replace the diagram because that would also have been
useless busy work. Yes, I invested too much effort
when I created the diagram because it took me almost 15
minutes to draw it with Visio yet I could have drawn
this diagram on a whiteboard, taken a picture of it, and
cleaned it up with software in less than five minutes.
But, investing an additional five minutes to change the
format of the diagram wouldn't make any sense.
For a second example, let's say I don't like the
current heading along the X axis and believe that
"Expenditure" would be better. Would it be worth
the effort of starting up Visio, reading in the
document, updating it, generate the GIF, upload the
image to my ISP, edit the HTML for this page to rework
the text to match the diagram, upload the HTML, open up
my browser and look at this article to ensure that I got
it right, do any necessary fixes and subsequent uploads,
and then commit the changes to version control?
Sounds like at least five to ten minutes of effort for
almost no value. Agile modelers
Update Only When It Hurts, and the current X axis
heading doesn't hurt enough to warrant this investment
(actually, I think the current heading makes sense).
In fact, this sort of update would actually decrease the
value of this article because the cost is greater than the
benefit.
 |
|
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.
|
