 |
Model
storming is just in time (JIT) modeling: you
identify an issue which you need to resolve, you
quickly grab a few team mates who can help you,
the group explores the issue, and then everyone
continues on as before. It’s common on agile
projects, Extreme
Programmers (XPers) call it a stand-up design
session or a customer Q&A session, and it’s
clearly common on traditional projects as well.
Everyone model storms at some point and I think
that it’s about time we started talking about it
so we can find ways to get even better at it.
|
|
My
experience is that the vast
majority of modeling sessions
involve a few people, usually
just two or three, who discuss
an issue while sketching on
paper or a whiteboard. These
“model storming sessions” are
typically impromptu events, one
project team member will ask
another to model with them,
typically lasting for five to
ten minutes (it’s rare to model
storm for more than thirty
minutes). The people get
together, gather around a shared
modeling tool (e.g. the
whiteboard), explore the issue
until their satisfied that they
understand it, then they
continue on (often coding).
Analysis Model Storming
You will model storm to analyze
requirements. For example, a stakeholder may tell you that the
system you’re building must be able to edit student
information. Together you
create a sketch of what the screen will look like, see
Figure 1,
drawing several examples until you come to a common
understanding of what needs to be built. Sketches such
as this are
inclusive models because you’re using simple
tools and modeling techniques, this enabling the Agile
Modeling (AM) practice of
Active Stakeholder Participation. Note that
you may also have created a
model such as this as part of
your
iteration modeling efforts,
the "rules" aren't carved in
stone.
Figure 1. Screen
sketches.
Design Model Storming
Agile developers, including XPers, don’t always go straight to code
once they’ve chosen to work on a requirement (contrary
to what detractors of agile development will tell you).
This is because model storming is also very common for
architecture and design. Java programmers will often
work through complex code by sketching a quick
UML sequence diagram
(see Figure 2), XPers will create
Class Responsibility Collaborator (CRC) cards on
standard index cards (see Figure 3) to explore detailed structural
design problems, and Visual Basic programmers may choose
to draw flow charts to model a complex business rule
(see Figure 4).
Regardless of the model(s) that
you need to create, you're still
model storming.
Figure 2.
Service-level sequence diagram.
Figure 3.
Hand-drawn CRC Cards.
Figure 4. Flowchart for enrolling in the
University.
It's important to understand that
you don't require a whiteboard to model storm, you just
need a shared,
inclusive tool that people can work with easily.
For example, the CRC cards of
Figure 3
are written on index cards, not
drawn on a whiteboard.
Why Does This Work?
Why does
model
storming
on a JIT
basis
work
much
better
than
trying
to
model
everything
up front?
For
several reasons:
-
The
requirements
are
going to
change
throughout the project, like
it or not.
-
By
waiting
to
analyze
the
details JIT, you
have
much
more
domain
knowledge
than if
you had
done so
at the
beginning
of a
project.
For
example,
if a
requirement
is to be
implemented
three
months
into a
project,
if you
explore
the
details
of that
requirement
at that
point
you have
three
months
more
domain
knowledge
than if
you had
done so
at the
beginning
of the
project,
therefore
you can
ask more
intelligent
questions.
-
If
you've
been
delivering
working
software
on a
regular
basis
your
stakeholders
now
have
three
months
worth of
experience
with the
system
that
you've
built.
In other
words,
they can
give you
better
answers.
-
Modeling
everything
up front
in
detail appears
to
result
in
significant
wastage.
Yes, during iteration 0
you'll want to do some
initial requirements
envisioning and some
initial
architecture envisioning but that doesn't mean you
need to dive deep into the
details.
Having
said
that,
sometimes
you'll
need to
model
complex
requirements,
or
model
legacy
assets,
a bit
ahead of
actually
implementing
them.
This is
actually
a rare
occurrence,
regardless
of what
traditional
modelers
may hope
for, but
it does
happen
every so
often.
Adopting Model Storming
How do you support model
storming within your
environment? First, the
more whiteboard space the
better. Some companies are
reluctant to put up whiteboards,
apparently interior decorating
concerns such as having
attractive prints on the wall is
far more important to them than
making software development
teams effective. My advice
is to not only have a lot of
whiteboard space available to
people, you also need to ensure
that it’s visible to people once
they’re back at their
workstations so that they can
easily work from them. You’ll need
to develop a protocol for
working on the
whiteboards, particularly
when it’s ok to erase
something. Your team culture is
also critical to your success,
it must be acceptable to ask
people for help and in turn to
be asked to model with others.
You need to recognize that this
is a normal and effective way to
work. I can’t remember a
project where we didn’t model
storm, yet I also can’t remember
reading a book or article which
talked about this technique in
any great detail. Wouldn’t it
be nice if the IT industry could
start talking about what we
actually do in practice, instead
of what we think we should be
doing?
 |
|
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. |
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.
|
