 |
I am a firm believer that when you are
describing the scope of something, be it a system or in
the case of AM a methodology, that you should describe
both what it is and what it isn’t.
The following points describe the scope of AM: |
|
1.
AM is an
attitude, not a prescriptive process.
AM comprises a collection of values that agile
modelers adhere to, principles that agile modelers
believe in, and practices that agile modelers apply.
AM describes a style of modeling, when used
properly in agile environments, that results in better
quality software and faster development while avoiding
over-simplification and unrealistic expectations.
AM is not cookbook approach to development – if
you’re looking for detailed instructions for creating
Unified Modeling Language (UML) sequence diagrams or
drawing user interface flow diagrams then you need to
pick up one of the many modeling books listed in the
article
Modeling
Artifacts. In particular I highly suggest my own book The Object
Primer 3/e (although naturally I’m biased).
2.
AM is a
supplement to existing methods, it is not a complete
methodology. The
primary focus of AM is on modeling and its secondary
focus is on documentation.
That’s it.
AM techniques should be used to enhance modeling
efforts of project teams following agile methodologies
such as
eXtreme Programming
(XP),
Rational Unified Process (RUP), and
Feature Driven Development (FDD). AM can also be used
with prescriptive processes although will not be as successful the less agile the
process is.
3.
AM is a
way to work together effectively to meet the needs of
project stakeholders.
Agile developers work as a team with their
project stakeholders, who in turn take a direct and
active role in the development of the system.
There is no “I” in “agile” (Canadian
spelling, eh).
4.
AM is
effective and is about being effective.
As you read more about AM one of the things that
should become poignant to you is AM’s ruthless focus
on being effective.
AM tells you to maximize the investment of your
project stakeholders, to create a model or document when
you have a clear purpose and understand the needs of its
audience, to apply the right artifacts to address the
situation at hand, and to create simple models whenever
you can.
5.
AM is
something that works in practice, it isn’t an academic
theory. The goal of AM is to describe techniques for
modeling systems in an effective manner, one that is
both efficient and sufficient for the task at hand. These techniques have been examined
and discussed by several thousand modeling practitioners
on the
Agile Modeling mailing list
since February 2001.
6.
AM is not
a silver bullet.
Agile modeling is an effective technique for
improving the software development efforts of many
professionals. That’s
it, nothing more. It
isn’t magic snake oil that will solve all of your
development problems.
If you work hard; if you stay focused; if you
take AM’s values, principles, and practices to heart;
then you will likely improve your effectiveness as a
developer.
7.
AM is for
the average developer, but is not a replacement for
competent people.
AM’s values, principles, and practices are
straightforward, many of which you have likely been
following or wish you had been following for years.
You don’t have to walk on water to be able to
apply AM’s techniques, but you do need to have basic
software development skills.
The hardest thing about AM is that it prods you
to learn a wide range of modeling techniques, a long and
continuing activity. Learning to model can seem difficult at first, and it is, but
you can do it you choose to learn a technique at a time.
Having said that, the best developers are
generalizing specialists.
8.
AM is not
an attack on documentation.
Agile modelers create
documentation that
maximizes their investment in its creation and
maintenance. Agile
documentation is as simple as possible, as minimal as
possible, has a distinct purpose that is directly
related to the system being developed, and has a defined
audience whose needs are understood.
9.
AM is not
an attack on CASE tools.
Agile modelers use tools that provide positive
value by helping to make then more effective as a
developer. Furthermore,
they always strive to use the
simplest tool
that gets the job done, and sometimes that's a
sophisticated CASE tool.
10.
AM is not
for everyone. More
on this in When
Does(n't) Agile Modeling Make Sense?.
 |
|
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.
 
|
