In-Depth
AM principles
- By Sott W. Ambler
- April 1, 2002
Readers familiar with Extreme Programming (XP) will recognize the similarity
among these core agile modeling principles and many of the principles of XP.
When applied to a software development project, these values set the stage for
a collection of Agile Modeling (AM) practices.
In addition to these core principles, Scott Ambler and others in the AM community
have defined several supplementary principles. These are listed on the Official
Agile Modeling Web site (http://www.agilemodeling.com/).
Assume Simplicity: Keep your models as simple as possible. Do not depict
additional features that you do not need today. Have the courage not to over-model
your system, and the confidence that you can model based on your existing requirements;
then refactor your system in the future as your requirements evolve.
Embrace Change: Requirements evolve over time, and so do people's understanding
of them. Project stakeholders come and go as your project moves forward, and
they can change their goals in unexpected ways. To maximize your effectiveness,
your approach to development must reflect this reality.
Enabling The Next Effort Is Your Secondary Goal: While you are working,
keep the future of the system you are developing in mind. Your project can still
be considered unsuccessful if you fail to deliver software that is robust enough
to be extended over time. As Alistair Cockburn likes to say, in the software
development game, your secondary goal should be to set up to play the next game.
Be sure you have an awareness of the nature of the next project -- whether you
are called upon to develop the next major release of your system, or are simply
involved in the operations and support of the current version. And you will
want to consider whether the next project will include members of your existing
team, and the importance of the next effort to your organization.
Incremental Change: When it comes to modeling, you do not need to get
it right the first time. In fact, it is very unlikely you could if you tried.
Furthermore, you do not need to capture every detail in your models. Consequently,
there is no point in trying to develop an all-encompassing model at the start
of a project. Instead, begin with a small model or perhaps a high-level model,
and evolve it over time in an incremental manner. Or simply discard each model
when you no longer need them. To put it simply, each model just has to be good
enough at the time.
Maximize Stakeholder Investment: Your project stakeholders are investing
resources -- time, money, facilities, etc. -- to have software developed that
meets their needs. Your team should not fritter those resources away. And they
deserve to have the final say in how those resources are invested. If it were
your time and money, would you want it any other way?
Model With A Purpose: Many developers worry about the level of detail
in their artifacts (models, source code, documents, etc.) and whether they are
sufficiently accurate. That is putting the cart before the horse. The first
thing you should consider is why you are creating a particular model, and for
whom. Perhaps you need to understand an aspect of your software better. Maybe
you need to communicate your approach to senior management to justify your project.
Possibly, you need to create documentation that describes your system to the
people who will be operating it and maintaining/evolving it over time. Once
you have a clear and valid purpose for your model, and an understanding of the
audience for it (even if that audience is just you), you can develop it with
a level of detail and accuracy that is appropriate for that purpose and that
audience. This principle also applies to changing existing models.
Multiple Models: Considering the complexity of modern-day software,
you need to take advantage of the wide range of modeling techniques available
to you. And you will probably need to use multiple models because each model
describes a single aspect of your software. You will not need every model for
every system you develop, but you will require at least a subset of the models.
Quality Work: Nobody likes sloppy work. The people doing the work do
not like it because it is not something they can be proud of. The people coming
along later to refactor the work do not like it because it is harder to understand
and update. And the end users will not like the work because it is likely to
be fragile or to not meet their expectations.
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, analyze those requirements or develop a user interface that
meets their needs [and] provides opportunities for rapid feedback.
Software Is Your Primary Goal: The goal of software development is to
produce software that meets the needs of your project stakeholders in an effective
manner. The primary goal is not to produce extraneous documentation, management
artifacts or models. Any activity that does not directly contribute to this
goal should be questioned and avoided if it cannot be justified in light of
this principle.
Travel Light: Every artifact that you create and keep will need to be
maintained over time. Whenever a change occurs, you will need to consider the
impact of that change on all models and then act accordingly. The fewer models
you keep, the less work you have to perform to support a change -- and the more
agile you are. Similarly, the more complex and/or detailed your models, the
more likely it is that a given change will be harder to accomplish. Every time
you decide to keep a model, you trade agility for the convenience of having
that information available to your team in an abstract manner. Never underestimate
the seriousness of this tradeoff. A development team that decides to 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 it is spending the majority of its time updating
documents instead of writing source code.
-- Printed with the permission of Scott W. Ambler
About the Author
Scott Ambler is president of Ronin International, a consulting company specializing in software process mentoring and architecture.