 |
The first thing to do is read
An Introduction to Agile Modeling to gain an
understanding of the basic concepts. Regardless of your
role, 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 and should try to
ease into AM gradually. |
|
My specific advice for the major roles on software
development projects follows:
To understand how architecture changes within an
agile environment:
- High-level,
initial architecture
envisioning should be done at
the beginning of a project. The goal is to
identify a potential architectural solution, not to
document the details, typically using simple
techniques such as
free-form diagrams on
plain-old whiteboards (POWs). This effort
typically takes several hours or days.
- All architectures work on POWs, therefore you
need to
prove it with code.
- The details are modeled on a just-in-time basis
in
model storming
sessions, and then coded immediately afterwards.
- Your architecture will evolve over time as you
learn more about what your stakeholders need built.
- Because systems are complex, effective
architects understand how to apply a
wide range of modeling techniques.
- Architects should be
active participants on the project team, and
ideally should also code.
- Read
Agile Architecture Modeling for more details.
- The best architects are
generalizing specialists who have one or more
specialties (e.g. architecture), a broad
understanding of IT, and a good understanding of the
domain which they work in.
The Agile Data
site focuses on exactly this topic.
To understand how design changes within an agile
environment:
- Over the first couple of days a high-level,
initial architecture
model
is created using simple
techniques such as
free-form diagrams on
plain-old whiteboards (POWs).
- Recognize that the concept of a
"design phase" has been abandoned for
the concept that you need to model
throughout a project. Instead, your
design emerges over time to reflect the fact
that
requirements change over time.
- Because systems are complex, effective designers
understand how to apply a
wide range of modeling techniques.
- The details are modeled on a just-in-time basis
in
model storming
sessions, and then coded immediately afterwards.
- The quality of your application design is kept
high via
refactoring, a programming technique.
- The quality of your database design is kept high
via
database refactoring.
- The best designers are
generalizing specialists who have one or more
specialties (e.g. design), a broad understanding of
IT, and a good understanding of the domain which
they work in.
To understand how enterprise architecture changes
within an agile environment:
- Your goal should be to promote consistent,
proven architectural practices and strategies
amongst development teams.
- Start by
developing a vision, then
get involved with development teams and work
with them as part of the team to help them work to
that vision. Over time you'll develop
architectural
documentation, but don't invest much time at
first because the teams need vision and help from
you, not mounds of documentation.
- The most important thing your enterprise
architecture group can provide to teams is actual
help to follow the enterprise vision. The next
most important things are working examples (reference
architectures) and practical guidance (standards
and guidelines) for building systems.
- Your enterprise architecture will evolve over
time as you work with the project teams, because
you'll learn what works in practice and what the
developers actually need.
- The best enterprise architects are
generalizing specialists who have one or more
specialties, a broad understanding of
IT, and a good understanding of the domain in which
they work.
To understand the relationship between AM and
programming:
- The primary advantage of modeling is that it
provides one way for you to think before you build
something. You can draw a sketch on a whiteboard or
in a modeling tool to think something through and
the once you have a viable strategy then you can
prove your model with code.
- Whenever you run into a requirement you don't
understand, perhaps you have a new user story to
implement or the requirement simply isn't clear,
then you can
model storm with your
stakeholder(s) on a just-in-time (JIT) manner to
get the details that you need.
- Whenever you run into a technical issue, perhaps
you're not sure which strategy to implement
something is best suited for your current
architecture, or perhaps you simply need to think
through the high-level design before you get into
coding, then you should
model storm with a co-worker(s) (often your pair
if you're pair programming) to think it through
first.
- You don't need a big design document written up
before you write your code, and you don't even need
a lot of details, you just need to create models
which are
just barely good enough for your situation.
- I highly suggest that you take a
test-driven development (TDD) approach, as I
indicate in the
AMDD article, and pair program whenever
possible.
To understand the relationship between AM and project
management:
- You will likely need to schedule
initial envisioning sessions at the beginning of
the project.
- Organize your project into
short iterations. The functionality that
you implement in each iteration should be the
highest priority functionality, as defined by your
stakeholders, at the time. The
requirements stack changes throughout the
project, so don't invest much time planning ahead
because you'll only need to do a lot of updating.
- The best people to
estimate something are the people building it,
and they might need to do a little bit of modeling
to understand the feature that they're estimating.
- Modeling isn't a task that you schedule, it's an
activity that people do on a
just-in-time (JIT) basis throughout the project.
- You'll discover that
model reviews (requirement, architecture, ...)
really don't provide a lot of value on agile
projects, so expect to discover that you don't need
them after awhile (if at all).
I'm a QA/Test Professional...
To understand the relationship between AM and
validation activities:
- Agile models evolve over time and they are
just good enough
for the task at hand. The implication is that
it's unlikely that you'll have a "complete" model to
review, except at the end of the project.
- Because Agile Modelers work incrementally and
prove it with code
whenever they can you'll have working software to
validate very quickly, so reviewing models really
does become busy work. Everything works on a
whiteboard, or in a CASE tool, but not always in
code. Focus on the code.
To understand how requirements analysis changes
within an agile environment:
- High-level,
initial requirements
envisioning should be done at
the beginning of a project. This effort takes
days, not weeks or months. Your goal is to
understand the scope, not to get the details.
- Ideally the details are modeled, analyzed if you
will, on a just-in-time basis in
model storming
sessions.
- Recognize that the concept of a
"requirements phase" has been abandoned for the
concept that you need to do requirements analysis
throughout the project.
-
Requirements will change over time, and that's
perfectly ok.
Manage them as a prioritized, evolving stack.
-
Stakeholders actively participate in the
modeling effort, so adopt
inclusive modeling techniques which enable them
to do so.
- Because systems are complex, effective
requirements analysts understand how to apply a
wide range of modeling techniques.
- The goal is to understand the requirements, not
to write requirements
documentation. If you do write documentation,
keep it concise and useful for your audience and
strive to
single source information as much as possible.
- Recognize that you have a
wide range of models at your disposal.
-
Model with developers so that they understand
what the requirements are and you understand what
they're trying to build.\
-
The best requirements analysts are
generalizing specialists who have one or more
specialties (e.g. requirements elicitation), a broad
understanding of IT, and a good understanding of the
domain which they work in.
To be honest, you're likely hard to convince that AM
is a good idea, and you're likely right to be skeptical
-- just be open minded as well. Here's a few
important concepts that you need to understand:
- Modeling and documentation are important aspects
of
agile software development. The main
difference between agile and traditional approaches
are that we strive to
maximize stakeholder ROI and therefore we
focus on remaining as lean and effective as
possible.
- Your primary goal should be to
develop working software,
modeling and documentation should be secondary
to that.
- There is no co-relation between documentation
and project success, and in fact lots of arguably
unnecessary documentation seems to be associated
with project failure. Ever had a well defined
requirements document in place, but the
developers built something else? Or an
architecture model in place, but the programmers
ignored it? What you really want to strive for
is sufficient documentation that is
just barely good enough for your situation.
- Creating a large, well-defined requirements
document which is reviewed and accepted early in the
project lifecycle is a very risky and ineffective
way to work.
Requirements change for very good reasons, so
you should adopt techniques which enable you to
embrace change. Agilists manage
requirements as a
prioritized stack, each iteration they pull the
highest priority requirements (as defined by their
stakeholders) off the top of the stack and work on
them. The end result is that stakeholders have
complete control over what gets developed and how
much money gets spent on it (they simply stop
funding the project once they're happy with what's
been produced to date). In short, with agile
you get to see regular progress in the form of
working software, and you get the highest value
possible for your investment.
- You do need some
documentation, just nowhere near as much as you
think, and the documentation that does get produced
should be concise and contain only information that
couldn't be captured effectively in the source code.
Strive to
single source information.
- The best developers are
generalizing specialists who have one or more
specialties, a broad knowledge of development, and a
good understanding of the domain. Teams made
up of specialists can struggle to work together
effectively because they don't understand what each
other is doing, and have a tendency to create lots
of extra documentation because their skills are too
narrow to allow them to
capture information in the most appropriate manner.
- There's sufficient
anecdotal evidence, and even research evidence,
showing that agile software development is a good
idea. If you have several projects to do, and
you're struggling to succeed using your existing
approaches, doesn't it make sense to at least run an
agile pilot project to see if agile works in your
environment?
In AM
stakeholders, and in particular their active
participation as team members, are a critical factor to
the success of a project. You need to understand:
- The
rights and responsibilities of everyone on the
project.
- The basics of AM by reading
An Introduction to Agile Modeling.
- How you can be an active participant in the
modeling efforts through adoption of
inclusive modeling techniques.
- Recognize that it's ok for you to change your
mind, because we
manage requirements as a prioritized stack.
 |
|
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. |
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.
|
