 |
The practices of AM are synergistic because they
support and sometimes even enable one another.
To make AM work effectively you need to have an
understanding of how its practices fit together.
Figure 1 depicts the
relationships between AM’s practices, organizing them
in seven categories.
The first four categories – Validation,
Iterative and Incremental, Teamwork, and Simplicity –
consolidate AM’s core practices, the ones that you
most adopt in full to be truly able to claim that you
are agile modeling.
The supplementary practices in turn are
consolidated by the Documentation, and
Productivity categories.
Let’s start by considering how
the core practices relate to one another within each
category, then we’ll examine the
supplementary practices within each category, then
we’ll discuss how the categories
enable one another.
|
|
Figure 1. How the AM
practices fit together.
Let's examine the four categories
containing the core practices:
-
Teamwork. There are four practices –
Active
Stakeholder Participation,
Model With Others,
Display Models Publicly, and
Collective
Ownership – in the Teamwork category.
The practice Active Stakeholder Participation
is critical to your success because it is your project
stakeholders that you are building your system for, it
is these people whose requirements you need to
understand and fulfill.
In other words you need to work closely with your
stakeholders something that is supported by the practice
Model With Others – your stakeholders are
included in this “others” category.
When there are several people involved in a
modeling effort, at least one of which should be a
project stakeholder and another a developer, you are in
a position where you can work together synergistically
by benefiting from each others strengths and
counteracting each others weaknesses.
An agile modeler whose expertise is in business
process modeling and business rule definitions may miss
information that someone with a focus on structural
modeling techniques such as UML class diagrams or data
models would pick up on.
Similarly a direct user of your system would
provide different information to your team than would
senior management.
The point to be made is that not only do you want
to actively work with your project stakeholders you want
to do so in a team environment so that multiple points
of view and expertise are taken into account. The
practice Collective Ownership enhances teamwork
because when a single person “owns” a model they
quickly become a bottleneck for your modeling efforts,
whereas when anyone is allowed to work on a model you
can easily work on them together as a team. The practice Display Models Publicly makes it easy for
people to look back and forth between the models,
considering the information that the models convey all
at once, and hence enhance collaborative efforts between
them. This of course assumes that the models are within
sight of each other, or at least the ones that you are
currently working on are close to one another, a topic
that I cover in greater detail in Organizing an
Agile Modeling Room.
-
Iterative and Incremental.
This
category of AM practices includes Apply The Right
Artifact(s),
Create Several Models in Parallel,
Iterate To Another Artifact, and
Model in
Small Increments.
Each artifact, no matter what it is, has its own
strengths and weaknesses and no single model is
sufficient to describe major aspects of your project
such as its requirements or its architecture.
For example, in Agile
Requirements Modeling you will see that you
often need a combination of
use cases,
business rule
definitions, and
technical requirement definitions to
explore the requirements for your system.
It is very unlikely that your project
stakeholders will tell all of their usage requirements
all at once for your use cases, then switch gears to
tell you about all of their business policies to be
captured as business rules, then switch gears again to
tell you about all of their non-functional needs that
should be captured as technical requirements.
Instead they’ll tell you their requirements, as
they come to their minds, and will often double back on
what they said earlier to provide greater details or
even to change their minds.
Your requirements identification efforts can
often be very dynamic, and similarly so are your
analysis, architecture, and design efforts.
I believe the dynamism is the result of the way
that people think, our brains seem to connect
information in an apparently chaotic manner, the end
result being that ideas seem to “pop out of thin
air” or we have an “a-ha! experience”.
Agile modelers recognize that people think in
this dynamic manner, particularly collaborative groups
of people, and act accordingly. They Create Several Models in Parallel to collect the
wide range of information they are gathering. This
practice is clearly supported by the practice Apply
The Right Artifact(s) as well as Iterate To
Another Artifact – you may be capturing
information about a usage requirement in a use case when
your project stakeholder(s) begin discussing their needs
for an editing screen, something better specified by an
essential/abstract user interface (UI) prototype or
traditional
UI prototype. Iterating
back and forth between artifacts, one of which may very
well be program source code, is enabled by the practice Model
in Small Increments – you will typically work on a
little bit of one artifact, then another, then another,
and so on.
-
Simplicity.
This category contains
the core practices of Create Simple Content,
Depict
Models Simply,
Single Source Information, and
Use the Simplest Tools.
The two practices Create Simple Content
and Depict Models Simply focus on model
simplicity, and often going hand-in-hand during modeling
– by focusing on how to depict something simply
modelers often discover how to make whatever it is that
they are modeling simpler.
For example I have been involved in the
development of several
persistence layers, software conceptually similar to an Enterprise JavaBean (EJB) persistence container that encapsulates
persistent storage from your domain objects, and as a
result have been involved in some very complex
architecture and design efforts.
During one of them we were trying to figure out
how to create a simple diagram that we could provide to
application developers to help explain how to work with
the persistence layer and in the process discovered a
refactoring to make our design easier to understand.
The practice Single Source Information suggests that you
try to store information once and once only, preferably
in the most appropriate place possible. This
simplifies your documentation efforts as well as
traceability. Simplicity of process is enhanced by the practice
Use the Simplest Tools.
The simpler a tool is the easier it is to work
with, this decreases the barriers to entry for working
on your models and thereby increases the chance that
other people will in fact do so, including your project
stakeholders. By
using simple tools you increase the chance that you will
depict those models simply. Furthermore, when you use
simple/low-fidelity tools such as index cards, Post-It
notes, and whiteboards you put yourself into a situation
where you actively experience the effectiveness of
simple tools – subconsciously reinforcing the concept
that the simplest solution can in fact work very well, a
mindset that will hopefully reveal itself in a simpler
design for the system that you are building.
-
Validation.
This category consists of
the core practice Prove
it With Code. By actively seeking to prove a
model with code as soon as possible I quickly show that
my system works.
There are two categories of
supplementary practices:
-
Documentation.
This category consists
of three supplementary practices: Discard Temporary
Models,
Formalize Contract Models, and
Update
Only When It Hurts.
Your requirements, your understanding of those
requirements, and potentially even your understanding of
your solution are changing throughout your project
(remember the principle
Embrace Change). Many of your project artifacts, including models and
documents, will need to evolve to reflect these changes.
As you’ll see with the discussion of
agile
documentation one of the best ways to ensure that
you are taking an agile approach to your models and
documents is to update them only when it hurts. When following this practice if you find that a model isn’t
being updated it is an indication the model may not
provide your team with much value – if the model
doesn’t provide value then it should be considered
temporary and hence discarded.
However, remember that contract models, models
that define an interface between your system and
another, are unlikely to change much over time but
because of their importance are not candidates for
disposal. In
short, if a non-contract model isn’t being updated
over time it is a good indication that you don’t need
that model.
-
Productivity.
This category
is comprised of the practices Apply Modeling
Standards and
Apply Patterns Gently.
Agilists follow standards and guidelines, even
when modeling, because it promotes
consistency within your work.
Yes, you write your own set of guidelines, and
sometimes you do need to because of some unusual factor
within your environment, but with a little bit of
searching on the Internet you can quickly turn up
development guidelines such as the ones for Java.
Consider the practices of the
Teamwork category.
Active Stakeholder Participation is
supported by the practices of the Simplicity category
because simplicity lowers any barriers to participation.
Participation is also enabled by the Iterative
and Incremental practices, particularly Create
Several Models in Parallel because it open up more
opportunities for stakeholders to get involved.
The practices Collective Ownership and Model
With Others are supported by the Simplicity practices because they
lower barriers to participation.
Display Models Publicly is enhanced by the
Productivity practices, following standards and applying
patterns increases consistency and readability, and
reuse of existing resources such as common architectural
models provides a familiar base from which people can
start with your models.
Collective Ownership is supported by the
Iterative and Incremental practices, in particular Create
Several Models In Parallel and Iterate to Another
Artifact seem to promote several people working
together on whatever models are appropriate at the time.
The practices of the Simplicity
category are supported by those of several other
categories. The
practice Depict Models Simply is enhanced by Apply
Modeling Standards and Apply Patterns Gently
because both of these practices support modeling in a
common language (your chosen standards and hopefully
well-understood patterns).
Simplicity practices are enhanced by the
Documentation practices – when you Update Only When
It Hurts you are more likely to Depict Simply
Models and Create Simple Content because you
aren’t needlessly adding information to your models.
Now consider the Iterative and
Incremental practices.
The Teamwork practices clearly support these
practice, with several people involved there is a
greater chance that someone will know what the right
artifact is to apply to your situation enabling you to
iterate to it as needed.
The Validation practices give you the courage to
take an incremental approach, particularly when you Prove
It With Code, and by keeping testability in the back
of your mind you are more likely to want to work on
several models at once, and iterate between them,
because testing issues will likely need to be captured
in a variety of views.
The Documentation practices also promote an
incremental approach, particularly Update Only When
It Hurts, although Formalize Contract Models
often goes against the incremental grain because you
want to baseline interfaces with other systems as early
as possible. Iterate
to Another Artifact and Discard Temporary Models
are complementary because you often want to work on a
model and then move one once it has served its purpose.
The Simplicity practices are also important to
this category. When
you Use the Simplest Tools it makes it easier to
iterate back and forth between artifacts, you minimal
time starting the tool, and a focus on simple content
and simple depiction ensures that you have a minimal
learning curve remembering what the model communicates.
Finally, you typically
require several views to communicate or understand the
complexities of a system, and you will need to iterate
back and forth between appropriate artifacts to do so
effectively.
The Validation practices are
supported by the Simplicity practices – when you Create
Simple Content and Depict Models Simply you
make it much easier to Prove it With Code.
The Iterative and Incremental practices also
promote validation.
For example, when you Iterate to Another
Artifact a likely candidate to iterate to is source
code so that you can show that your model actually
works.
The Productivity practices are
enhanced by the Simplicity practices: It is easier to Apply
Patterns Gently with you are working with simple
models; it is easier to Apply Modeling Standards to
when you Depict Models Simply.
The Documentation practices are
supported by both the Simplicity and the Iterative and
Incremental practices.
The simpler your documentation is the easier it
is to work with – if your documentation is easy to
understand it gives you the courage to Update Only
When It Hurts because you know that you will be able
to do so easily, documentation that is harder to
understand is a greater risk to your project because you
can’t be as sure that you can update it as required.
The practices Update Only When It Hurts
and Discard Temporary Models clearly only work in
environments promoted by practices such as Iterate To
Another Artifact and Model in Small Increments.
 |
|
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.
|
