 |
Agile Modeling (AM) defines a collection of
core
and supplementary
principles
that when applied on a software development project set the stage for a collection of modeling
practices.
Some of the principles have been adopted from eXtreme Programming (XP) and are well documented in
Extreme
Programming Explained, which in turn adopted
them from common software engineering techniques.
For the most part the principles are presented with a focus on their
implications to modeling efforts and as a result material adopted from XP may be presented in
a different light. |
|
The AM principles are organized
into two lists, core principles
which you must adopt to be able to claim that you're
truly taking an
Agile Model Driven Development (AMDD) approach and
supplementary principles
which you should consider tailoring into your software
process to meet the exact needs of your environment.
In January 2005 I added a third list,
deprecated principles which
I've decided to remove in the second release of the AMDD
methodology in order to simplify it.
| Core Principles |
Supplementary Principles |
|
|
|
-
Model
With A Purpose. Many
developers worry about whether their artifacts -- such as models, source
code, or documents -- are detailed enough or if they are too detailed, or
similarly if they are sufficiently accurate.
What
they're not doing is stepping back and asking why they're creating the
artifact in the first place and who they are creating it for. With respect to modeling, perhaps you need to understand an aspect of your
software better, perhaps you need to communicate your approach to senior
management to justify your project, or perhaps you need to create
documentation that describes your system to the people who will be operating
and/or maintaining/evolving it over time. If you cannot identify why
and for whom you are creating a model then why are you bothering to work on it all?
Your first step is to identify a valid purpose for creating a model and the
audience for that model, then
based on that purpose and audience develop it to the point where it is both
sufficiently accurate and sufficiently detailed. Once a model has fulfilled its goals you're finished with it for
now and should move on to something else, such as writing some code to show
that the model works. This principle also applies to a change to
an existing model: if you are making a change, perhaps applying a known
pattern, then you should have a valid reason to make that change (perhaps to
support a new requirement or to refactor your work to something cleaner).
An important implication of this principle is that you need to know
your audience, even when that audience is yourself. For example, if you are
creating a model for maintenance developers, what do they really need?
Do they need a 500 page comprehensive document or would a 10 page overview
of how everything works be sufficient? Don't know? Go talk to
them and find out.
-
Maximize
Stakeholder ROI. Your project
stakeholders are investing resources -- time, money,
facilities, and so on -- to have software developed
that meets their needs. Stakeholders deserve
to invest their resources the best way possible and
not to have resources frittered away by your team.
Furthermore, they deserve to have the final say in
how those resources are invested or not
invested. If it was your resources, would you
want it any other way? Note: In AM v1
this was originally called "Maximize Stakeholder
Investment". Over time we realized that this
term wasn't right because it sounded like we were
saying you needed to maximize the amount of money
spent, which wasn't the message.
-
Travel Light.
Every artifact that you create, and then decide to keep, will need to be
maintained over time. If you decide to keep seven models, then
whenever a change occurs (a new/updated requirement, a new approach is taken
by your team, a new technology is adopted, ...) you will need to consider
the impact of that change on all seven models and then act
accordingly. If you decide to keep only three models then you clearly
have less work to perform to support the same change, making you more agile
because you are traveling lighter. Similarly, the more
complex/detailed your models are, the more likely it is that any given
change will be harder to accomplish (the individual model is
"heavier" and is therefore more of a burden to maintain).
Every time you decide to keep a model you trade-off agility for the
convenience of having that information available to your team in an abstract
manner (hence potentially enhancing communication within your team as well
as with project stakeholders). Never underestimate the seriousness of
this trade-off. Someone trekking across the desert will benefit from a
map, a hat, good boots, and a canteen of water they likely won't make it if
they burden themselves with hundreds of gallons of water, a pack full of
every piece of survival gear imaginable, and a collection of books about the
desert. Similarly, a development team that decides to develop and
maintain a detailed requirements document, a detailed collection of analysis
models, a detailed collection of architectural models, and a detailed
collection of design models will quickly discover they are spending the
majority of their time updating documents instead of writing source
code.
- Multiple
Models. You potentially need to use multiple
models to develop software because each model describes a single
aspect of your software. “What
models are potentially required to build modern-day business
applications?” Considering the complexity of
modern day software, you need to have a wide range
of techniques in your intellectual modeling toolkit
to be effective (see Modeling
Artifacts for AM for a start at a list and
Agile Models Distilled for detailed descriptions). An important point is
that you don't need to develop all of these models for any given system, but
that depending on the exact nature of the software you are developing you
will require at least a subset of the models. Different systems,
different subsets. Just like every fixit job at home doesn't require
you to use every tool available to you in your toolbox,
over time the variety
of jobs you perform will require you to use each tool at some point.
Just like you use some tools more than others, you will use some types of
models more than others. For more details regarding
the wide range of modeling artifacts available to
you, far more than those of the UML as I show in the
essay Be
Realistic About the UML.
-
Rapid Feedback.
The time between an action and the feedback on that action is
critical. By working with other people on a model, particularly when
you are working with a shared modeling technology (such as a whiteboard, CRC
cards, or essential modeling materials such as sticky notes) you are
obtaining near-instant feedback on your ideas. Working closely with
your customer, to understand the requirements, to analyze those
requirements, or to develop a user interface that meets their needs,
provides opportunities for rapid feedback.
-
Assume Simplicity.
As you develop you should assume that the simplest solution is the best
solution. Don't overbuild your software, or in the case of AM don't
depict additional features in your models that you don't need today.
Have the courage that you don't need to over-model your system today, that
you can model based on your existing requirements today and refactor your
system in the future when your requirements evolve. Keep your models
as simple as possible.
-
Embrace Change.
Requirements evolve over time. People's understanding of the
requirements change over time. Project stakeholders can change as your
project moves forward, new people are added and existing ones can
leave. Project stakeholders can change their viewpoints as well,
potentially changing the goals and success criteria for your effort.
The implication is that your project's environment changes as your efforts
progress, and that as a result your approach to development must reflect
this reality.
You need an
agile approach to change management.-
Incremental Change.
An important concept to understand with respect to modeling is that you
don't need to get it right the first time, in fact, it is very unlikely that
you could do so even if you tried. Furthermore, you do not need to
capture every single detail in your models, you just need to get it good
enough at the time. Instead of futilely trying to develop an all
encompassing model at the start, you instead can put a stake in the ground
by developing a small model, or perhaps a high-level model, and evolve it
over time (or simply discard it when you no longer need it) in an
incremental manner.
- Quality Work.
Nobody likes sloppy work. The people doing the work don't like it
because it's something they can't be proud of, the people coming along later
to refactor the work (for whatever reason) don't like it because it's harder
to understand and to update, and the end users won't like the work because
it's likely fragile and/or doesn't meet their expectations.
-
Working Software Is Your Primary Goal.
The goal of software development is to produce
high-quality working software that meets the needs of your project
stakeholders in an effective manner. The
primary goal is not to produce extraneous
documentation, extraneous management artifacts, or
even models. Any activity that does not
directly contribute to this goal should be
questioned and avoided if it cannot be justified in
this light.
-
Enabling
The Next Effort Is Your Secondary Goal.
Your project can still be considered a failure even
when your team delivers a working system to your
users – part of fulfilling the needs of your
project stakeholders is to ensure that your system
robust enough so that it can be extended over time.
As Alistair Cockburn likes to say, when you
are playing the software development game your
secondary goal is to setup to play the next game.
Your next effort may be the development of
the next major release of your system or it may
simply be the operations and support of the current
version you are building.
To enable it you will not only
want to develop quality software but also create
just enough documentation and supporting materials so that the people playing
the next game can be effective.
Factors that you need to consider include
whether members of your existing team will be
involved with the next effort, the nature of the
next effort itself, and the importance of the next
effort to your organization.
In short, when you are working on your system
you need to keep an eye on the future.
-
Content Is More Important Than
Representation.
Any given model could have several ways to represent it. For example,
a UI specification could be created using Post-It notes on a large sheet of
paper (an essential or low-fidelity prototype), as a sketch on paper or a
whiteboard, as a "traditional" prototype built using a
prototyping tool or programming language, or as a formal document including
both a visual representation as well as a textual description of the
UI. An interesting implication is that a model does not need to be a
document. Even a
complex set of diagrams created using a CASE tool may not become part of a
document, instead they are used as inputs into other artifacts, very likely
source code, but never formalized as official documentation. The point
is that you take advantage of the benefits of modeling without incurring the
costs of creating and maintaining documentation.
-
Open And Honest Communication.
People need to be free, and to perceive that they are free, to offer
suggestions. This includes ideas pertaining to one or more models,
perhaps someone has a new way to approach a portion of the design or has a
new insight regarding a requirement; the delivery of bad news such as being
behind schedule; or simply the current status of their work. Open and
honest communication enables people to make better decisions because the
quality of the information that they are basing them on is more accurate.
To simplify AM, I chose to remove several principles in
January of 2005. Although these are still valid
ideas which are not going away, but they just won't be
considered "first order principles" anymore. I found over the years that as I training and
mentored people in
AMDD that I didn't need to discuss them very much
for people to understand the approach. The
principles which I removed are:
| v1 Principle |
Description |
Reason for Removal |
| Everyone
Can Learn From Everyone Else |
You can never truly master something, there
is always opportunity to learn more and to
extend your knowledge. Take the opportunity to
work with and learn from others, to try new ways
of doing things, to reflect on what seems to
work and what doesn't. Technologies change
rapidly, existing technologies such as Java
evolve at a blinding pace and new technologies
such as C# and .NET are introduced regularly.
Existing development techniques evolve at a
slower pace but they still evolve -- As an
industry we've understood the fundamentals of
testing for quite awhile although we are
constantly improving our understanding through
research and practice. The point to be made is
that we work in an industry where change is the
norm, where you must take every opportunity to
learn new ways of doing things through training,
education, mentoring, reading, and working with
each other. |
This is a great idea, one that seems to be
followed by the vast majority of agilists, but
it's very general and therefore does not need to
be a principle of a specific modeling
methodology. |
| Know Your Models |
Because you have multiple
models that you can apply you need to know their
strengths and weaknesses to be effective in their
use. |
Knowing what you're doing is always a good
idea, but did it really need to be an explicit
principle? Likely not. |
| Know
Your Tools |
Software, such as diagramming tools or
modeling tools, have a variety of features. If
you are going to use a modeling tool then you
should understand its features, knowing when and
when not to use them. |
Same issue as knowing your models. |
| Local Adaptation |
Your approach to software development must
reflect your environment, including the nature
of your organization, the nature of your project
stakeholders, and the nature of your project
itself. Issues that could be affected include:
the modeling techniques that you apply (perhaps
your users insist on concrete user interfaces
instead of initial sketches or essential
prototypes); the tools that you use (perhaps
there isn't a budget for a digital camera, or
you already have licenses for an existing CASE
tool); and the software process that you follow
(your organization insists on XP, or RUP, or
their own process). You will adapt your approach
at both the project level as well as the
individual level. For example, some developers
use one set of tools over another, some focus on
coding with very little modeling whereas others
prefer to invest a little more time modeling. |
I'm a firm believer that you should tailor a
software process to meet your exact needs.
However, that doesn't mean that this idea needs
to be part of AM, instead it needs to be part of
your overall software process improvement (SPI)
strategy. |
| Work With People's Instincts |
When someone feels that something isn't
going to work, that a few things are
inconsistent with one another, or that something
doesn't "smell right" then there is a good
chance that that is actually the case. As you
gain experience developing software your
instincts become sharper, and what your
instincts are telling you subconsciously can
often be an important input into your modeling
efforts. If your instincts tell you that a
requirement doesn't make sense or it isn't
complete investigate it with your users. If your
instincts tell you that a portion of your
architecture isn't going to meet your needs
build a quick technical end-to-end prototype to
test out your theory. If your instincts tell you
that design alternative A is better than design
alternative B, and there is no compelling reason
to choose either one of them, then go with
alternative A for now. It's important to
understand that the value of courage tells you
that should assume you can remedy the situation
at some point in the future if you discover your
instincts were wrong. |
Same issue as everyone can learn from
everyone else. |
|
