 |
The first published description of
AM appeared in the November 2000 issue of
Software Development under the name eXtreme Modeling
(XM). I then led the evolution of the technique, for
the most part via the Web although also at the XP 2001
conference held in Italy in May of that year. AM
started out fairly complex and it grew a bit into its
current form. In the time since I’ve been applying AM
on projects, mentoring people in its techniques,
teaching AM courses, and speaking about AM at a variety
of conferences. The one thing that I’ve noticed is
that many people struggle with its plethora of concepts
– five
values,
eleven core principles,
seven supplementary principles,
thirteen core practices, and
eight supplementary practices – so it shouldn’t be
any surprise that some people find AM complex. Sigh. |
|
A question that I get asked is how
can people get started with AM but perhaps not fully
adopt it all at once. Some organizations don’t want to
adopt just the core principles and practices at first,
let alone some of the supplementary ones. One common
situation is that the organization is very non-agile at
the present moment, that adopting all the AM core is
just too much to attempt at once. It is clear that many
people need a way to ease into AM slowly.
First, focus on improving
communication between people.
Modeling with others is
critical as is
active stakeholder participation. When
you use
simple tools it is much easier to model with
others because there isn’t a tool learning curve to
overcome, and simple tools also make it possible for
your stakeholders to actively model with you.
Second, you should strive to keep
things as simple as possible and to
travel as light as
possible. This is easy to talk about but often proves
quite difficult to do in practice, at least at first.
Using simple tools such as whiteboards and paper to
create models is a critical first step, showing you that
you don’t need sophisticated CASE tools to succeed.
Simple tools also make it much less painful to
discard
temporary models because you haven’t invested as much
effort in them.
Third, adopt techniques that enable
you to work in an evolutionary (iterative and
incremental) manner.
Creating several models in
parallel and
iterating to another artifact are crucial
practices, but this of course requires you to accept
that you need
multiple models. Keeping your models
small by working on them incrementally is also
important. Together, these techniques help to break you
of any "big design up front" (BDUF) habits that you may
have as well as any delusions that one single model is
the primary artifact that drives all your development
efforts. For example it is quite common for people to
insist that
data models or
use case models drive your
projects, and this may in fact be true for a very small
minority of projects, but often this attitude is the
result of political ambitions more than any thing else.
Proving it with code is a critical practice that
supports evolutionary development because it provides
the link from modeling to implementation, once again
helping you to break out of a
BDUF mindset.
|
In
short, to make this first step into AM you should
consider adopting following principles and practices:
|
 |
Upon adopting these concepts you’ll
discover that it is quite easy to add other ideas
incremental. For example, you’ll quickly discover that
you’re getting
rapid feedback by working in an
evolutionary manner, and likewise that
embracing change
makes sense in such an environment. Because you’re
working closely together to create models you’ll soon
see that
collective ownership makes things much easier
for you as does
displaying models publicly. As you gain
more experience with the modeling techniques, something
that happens quickly in an evolutionary environment,
that you get much better at
applying the right artifacts
for the situation.
In short, I think that you can see it is possible to
ease into AM over time. However, I want to make it
perfectly clear that to truly be “doing AM” you
must adopt the five values as well as all of the
core principles and
core practices.
This article has been excerpted from
The Object Primer 3rd Edition: Agile Modeling Driven
Development with UML 2.
 |
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. |
|
|
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.
 
|
