|
The goal of this FAQ is to help you to understand the
Agile Modeling (AM) methodology a bit better.
1. AM Fundamentals
1.1 What is Agile Modeling (AM)?
1.2 What is an agile model?
1.3 How does AM fit in?
1.4 What pain does AM address?
1.5 What benefits does AM provide?
1.6 How do I get started with AM?
1.7 How does AM relate to the
Agile Alliance (AA)?
2. AM in Practice
2.1 What is Agile Model Driven Development (AMDD)?
2.2 Do extreme programmers (XPers) model?
2.3 How much modeling do I need to do up front?
2.4 How much modeling
should we do during development?
2.5 When do I stop modeling?
2.6 When should we update our models
and documents?
2.7
Are models and documents different?
2.8 How much documentation do I need to write?
2.9 What do I do
when I have an idea for a new requirement?
3. AM and
"Other" Modeling Approaches
3.1 Can the UML be agile?
3.2 Why should we embrace changing requirements?
3.3 What is the difference between AM and "traditional
modeling"?
3.4 Where do CASE tools fit in?
3.5 Where does the Model Driven Architecture (MDA)
fit in?
Agile
Modeling (AM) is a practice-based methodology for
effective modeling and documentation of software-based
systems. Simply put, Agile Modeling (AM) is a collection of values,
principles, and
practices for modeling software that can be applied on a software development
project in an effective and light-weight manner.
The secret to AM isn’t the modeling techniques
themselves -- such as use case models, class models,
data models, or user interface models -- but how they’re
applied. You may take an agile modeling approach
to requirements,
analysis,
architecture,
and design.
AM is not a prescriptive process, in other words it
does not define detailed procedures for how to create a
given type of model, instead it provides advice for how
to be effective as a modeler. AM is not about less modeling, in fact many developers will
find that they are doing more modeling following AM than
they did in the past.
AM is “touchy-feely”, it’s not hard and
fast – think of AM as an art, not a science.
Read the essay What
Is(n't) Agile Modeling? for greater details.
Agile
models are more effective than traditional models
because they are
just barely good enough,
they don't have to be perfect. A paper prototype
could be an agile model, a whiteboard sketch could be an
agile model, a Visio diagram could be an agile model, or
a physical data model (PDM) created using a CASE tool
could be an agile model. The type of model, or the
tool with which it was created doesn't really matter.
What is important is that the model is just good enough
for the task at hand.
An important concept to understand
about AM is that it is not a complete software process.
AM’s focus is on effective modeling and
documentation. That’s it.
It doesn’t include programming activities,
although it will tell you to prove your models with
code. It
doesn’t include testing activities, although it will
tell you to consider testability as you model.
It doesn’t cover project management, system
deployment, system operations, system support, or a
myriad of other issues.
Because AM’s focus in on a portion of the
overall software process you need to use it with
another, full-fledged process such as
XP, DSDM,
SCRUM,
or
RUP as depicted in the figure
below.
You start out with a base process, such as XP or
UP or perhaps even your own existing process, and then
tailor it with AM (hopefully adopting all of AM) as well
as other techniques as appropriate to form your own
process that reflects your unique needs.
Figure.
AM enhances other software processes.
Within many traditional environments modeling and
documentation are almost always dysfunctional efforts
which rarely add value and sometimes even cause a
project to grind to a virtual halt under the weight of
the artifacts being generated. As a result many
developers think that modeling and documentation are a
waste of their time, and in traditional environments
they're often correct. It doesn't have to be this
way.
AM describes techniques which enable your modeling
and documentation efforts to be very streamlined and
effective, you can gain the benefits of modeling without
the dysfunctional costs of useless documentation.
Don't get me wrong, you still document, it's just that
you do so in a very smart way.
The benefits of AM are:
- Cost effectiveness. AM defines a
collection of values,
principles
and practices
pertaining to effective, light-weight modeling and
documentation. By creating models and documents
which are
just barely good enough
you
maximize stakeholder ROI.
- It defines explicit techniques for agile
projects. AM addresses the issue of how agile
developers model and document on software projects taking an
agile approach such as eXtreme Programming
(XP), Dynamic Systems
Development Method (DSDM), or
SCRUM. To quote Kent Beck from eXtreme Programming
Explained (XPE)
"We will continually refine the design of a system,
starting from a very simple beginning. We
will remove any flexibility that doesn't prove useful." Contrary to the claims of some of XP's detractors you do in
fact invest time modeling when taking an XP approach, but only when you have no
other choice. Sometimes it is significantly more
productive for a developer to draw some bubbles and lines to think through an
idea, or to compare several different approaches to solving a problem, than it
is simply start hacking out code. Read the
essay
Agile
Modeling and XP for more details.
-
To improve modeling and documentation on prescriptive
processes. AM addresses the issue of how to model effectively on a
Unified Process (UP) project, common instantiations of
which include the
Rational
Unified Process (RUP) and the
Enterprise
Unified Process (EUP). The RUP and EUP includes several modeling-oriented workflows --
Requirements, Business Modeling, Analysis & Design,
Enterprise Business Modeling, Enterprise Architecture -- which when applied at face value can become quite
burdensome. AM helps to improve the effectiveness of your modeling
efforts on an UP project (or any project for that matter).
Read the essay
Agile
Modeling and The Unified Process for more details.
My advice is to
ease into AM gradually. You should actively
strive to keep your approach to modeling as
collaborative and simple as possible. Recognize
that you only need to create models which are
just good enough for your task at hand -- models
don't need to be perfect (they never are) nor do they
need to be complete, they just need to fulfill the needs
of their audience right now.
Model with others whenever possible, in particular
the audience for your model, to ensure that you
understand their needs. Of course, you should read
and try to adopt as many of the
principles and
practices of AM as you can.
The essay
Where Do I Start? provides detailed advice by job
role and the article
Pitching Agile to Senior Management provides some
good advice too.
We support the Agile
Alliance. |
AM recognizes that the
values of agile development, as promoted by the
Agile
Alliance, are key to your being effective. The Agile Alliance
manifesto promotes:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
|
AMDD is the
agile version of Model Driven Development (MDD).
The following figure
depicts a high-level lifecycle for AMDD for the release
of a system. The
initial modeling activity
includes two main sub-activities,
initial requirements
envisioning and
initial architecture
envisioning. These are
done during cycle (iteration) 0, the first
iteration before you start into development cycles.
The other activities –
iteration modeling,
model storming,
reviews,
and
implementation – potentially occur during any cycle,
including cycle 0. The time indicated in
each box represents the length of an average session:
perhaps you’ll model for a few minutes then code for
several hours.
The fundamental idea is that you do
just enough modeling to determine your strategy for
proceeding. In the case of initial envisioning you want
to model just enough to identify and agree to the initial
scope of your work as well as the potential architecture for
your solution. During
iteration modeling, part of your iteration planning
efforts, you will do just enough modeling to understand what
you need to do that iteration. With
model storming you will work
through higher level issues that are not well addressed with
code. This might be an
inclusive modeling session with your
stakeholder(s) to understand their requirements, or
could be a quick design session with other developers to
determine how to build something.
Figure 2. Taking an AMDD
approach on a project.
2.2 Do extreme programmers (XPers) model?
Yes. They create
user stories,
free-form sketches, and
acceptance tests on a regular basis. XP even
has the practice "Stand-Up Design Session" which is
another term for
model storming. What XPers do is take a very
agile approach to their modeling efforts, in fact AM has
it's roots in XP. This is different from
traditional modeling,
and as a result when many traditionalists first look at
XP they think that XPers aren't modeling at all because
the XPers are
traveling light. See
Agile Modeling Throughout the XP Lifecycle for a
detailed discussion.
2.3 How much modeling do I need to do
up front?
Just enough to give you a basic understanding of the
high-level requirements and of a potential architectural
solution. Don't create a detailed CASE tool
model when a Visio diagram will do. Don't create a
Visio diagram when a whiteboard sketch will do.
Don't write a detailed use case when an index card with
bullet points will do. Everything works in your
documents and models, but not always when you go to
build it. The longer you spend up front modeling,
the longer you defer the benefit gaining concrete
feedback by
proving your models with code.
You don't need to get the details right away and even
if you do they'll change anyway. If you can do the
detailed modeling up front, then surely you could also
do it on a
just in time (JIT) basis as well.
2.4 How much modeling should we do during
development?
Just enough to get the job done, and the best way to
do that is to
model with a purpose and to
model with the audience for your work. When
you know why you're creating a model, and what your
audience (e.g. programmers, stakeholders, ...) then you
can model just enough. If you don't know what they
want, then you're forced to guess what they need and
will often do far more than what is required.
Better still, because you model with the audience for
your model(s) they learn as you do the work, the end
result being that they will need far less written
documentation than if they hadn't been involved.
When the model fulfills its immediate purpose
(therefore it doesn't make much sense to continue
working on it) OR you're stuck (therefore you should
stop being stuck and go work on something else for
awhile). This idea is captured in the practice
Iterate To Another Artifact.
Only
when it hurts enough to warrant the investment
of your valuable time. Too many projects get
bogged down by bureaucrats striving to get "complete
documentation", or "fully consistent" documentation,
or "fully traceable" documentation or some such
nonsense. The end result is that far too much
time is wasted on updating documentation, and not
enough on software development. Take an
agile approach to documentation and travel as
light as possible.
Yes, in fact they're orthogonal concepts. What
I mean by that is that models are not necessarily
documents and documents are not necessarily models.
A whiteboard sketch is a model, but it's not a very good
document. A pocket novel is a document, but it's
not really a model. Sometimes
models evolve into documents, but more often than
not they're
discarded once they're no longer needed.
Why is this an important distinction? Because
many programmers equate the term model to document, and
because they're experiences with documentation almost
always prove bad, they think that modeling isn't a very
good idea. Many developers first experience with
traditional modeling is to be handed mounds of
requirements and design documentation which they don't
understand, and then they rarely follow, or they're
asked to create mounds of documentation after the fact
because some bureaucrat wants to make it look as if the
team followed the official documentation-heavy process.
Frustratingly, many developers take a near-AM approach
in practice, often sketching on whiteboards and paper,
but they don't realize that they're modeling because
they're not using a CASE tool or
they're not producing useless documentation. Hopefully
AM will help to make developers aware that modeling can
be quite effective in practice.
Just enough to get the job done, and that's often
far less than you need.
Travel as light as possible and take an
agile approach to documentation in general.
Developers are really smart people who often have
ideas for features which they believe that a system
should exhibit. That's great! However, they
need to remember that
stakeholders are the source of requirements, not
developers, so what they need to do is suggest the
requirement to their stakeholder(s). The
stakeholder(s) should consider it and prioritize it
accordingly, putting it on
the stack with all of the other requirements.
The developers should then implement the requirement
when it hits the top of the stack.
Yes. You can apply the UML is a very agile
manner or in a very non-agile manner, it's really up to
you. Keep your
models simple,
use the simplest tools, and
model just enough to get the job done and you'll
stay fairly agile.
An important issue, however, is that the
UML really isn't sufficient for business application
development, so you need to learn more than just UML
techniques if you want to get the job done.
Luckily, as you can see at
Agile
Models Distilled, there are a lot of options
available to you.
Absolutely. People change their minds for many
reasons, and do so on a regular basis. They'll be
working with an existing system and realize that they
missed a requirement. Or, you'll show them your
work to date and they'll realize that what they asked
for really isn't what they want after all. Or
perhaps a competitor will release a new product which
implements features that your product doesn't.
Perhaps new legislation requires new features, or
changes to existing features, in your software.
If you try to "freeze" the requirements early in the
lifecycle you pretty much guarantee that you won't build
what people actually need, instead you'll build what
they initially thought they wanted. That's not a
great strategy. A
better approach is to treat requirements like a
prioritized stack: each iteration you take a bunch of
requirements off the stack and implement them, allowing
your stakeholders to add to, remove from, or
reprioritize existing items on the rest of the stack.
It's easy to support changing requirements, you just
need to choose to do so.
This is hard to answer because I don't know what
"traditional modeling" within your environment. In many
organizations the traditional approach to modeling is to
develop relatively detailed models before coding begins.
Sometimes these models are kept up to date, sometimes
they are not, and sometimes they're even used to
generate code (often a good thing). Each of these
models are often created by a single, expert person who
typically spends most of their time working alone.
There is often a requirements/business analyst who
elicits requirements from stakeholders and then captures
the information in a requirements document. This
requirements document is provided to the architect who
develops a high-level architecture model. This model is
the used by the designer(s) who create detailed design
model(s), which in turn are provided to the programmers
who may or may not actually follow them. This
approach to model sounds great in theory, but typically
results in a lot of documentation being written which
for the most part gets ignored during the actual
development process. In other words, it's merely
bureaucratic window dressing.
In some organizations the traditional approach to
modeling is to start with some modeling up front, to
abandon the effort of maintaining it during development,
then once the system is delivered they go back
(sometimes) and "clean up" the documentation to make it
look as if they actually did the modeling. This is
completely dysfunctional, but it happens.
With Agile Modeling you
model with others, you should never work alone
because it's simply too dangerous to do so (you'll
inject errors without realizing it). You model
just enough for the goal at hand because you know you
can come back to the model later if you need to.
You
travel as light as possible,
discarding temporary models (most models should be
temporary) and keeping only the models which you
actually need. You work closely with stakeholders,
using
inclusive modeling techniques which support
active stakeholder participation. This means
that a lot of your modeling is done with
simple tools, although sometimes you'll use a
complex CASE tool if it adds value.
3.4 Where do CASE tools fit in?
One of the practices of AM is to
Use the Simplest Tool, and sometimes the simplest
tool is a Computer Aided Software Engineering (CASE)
tool. If the tool adds actual value, and is the
best one available to you, then use it.
Personally, I find most CASE tools to be a colossal
waste of time, either they're too hard to use or they're
oriented towards traditional, documentation-heavy
approaches. If the tool doesn't generate and
reverse engineer code, and do it very easily, then
there's a pretty good chance that it's not adding value.
3.5 Where does the Model Driven Architecture (MDA)
fit in?
For business application development the MDA is
proving to be
virtually inconsequential, arguably nothing more
than a marketing campaign for the CASE tool vendors.
For embedded software development MDA appears to have
gained significant ground. If you're thinking
about taking an MDA approach I highly suggest that you
determine if you're ready for the MDA. If it
is, then the
Roadmap for Agile MDA is likely a good starting
point.
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.
|
