 |
No matter how much time you
invest, no matter how thorough your
model
reviews, no matter how skilled your modelers are,
the
requirements are still going to change
throughout a project. Yet, in many situations
you need to be able to define, fairly early in a
software development project, what is going to
be delivered by the team for the current
release. Perhaps you're developing commercial
software which needs to be advertised long
before it's available, or perhaps you're
outsourcing development of the system and want
to know what you're going to get before you sign
the contract. Worse yet, you have a
defined delivery date and a fixed budget: sounds
like a classic "iron triangle" dilemma, doesn't
it? The fundamental question is how
do you meet these needs yet still remain agile? |
|
Solution
First, do some
initial
agile modeling to identify the
scope of the project via
requirements envisioning. This
will not only provide you
with an understanding of what
needs to be built, it also
provides you with a high-level
list of requirements which your
stakeholders can put in
priority order. Your goal
is to identify the requirements
to the point that you understand
what they mean, it is not to
fully document them. For
example, the requirement "Enroll
a student in a seminar" may be
sufficient detail for now, or
perhaps you need a
point-form version of a use case
of the use case to feel
comfortable, but you certainly
don't need a
fully documented version.
Create models which are just
barely good enough for your
current needs; remember that you
can always fill in the details
later on a
just-in-time (JIT) basis.
Second, prioritize your "finalized" list
of requirements and commit to
delivering the top X% no matter
what, but also promise to
deliver something from remaining
requirements if time permits.
A common value for X ranges from
60 to 80, your goal being to set
X at a reasonable level which
enables you to safely deliver
sufficient functionality for the
given schedule and budget.
Third, publicly
commit to only delivering
that X%, but strive to deliver
beyond that. Doing so puts
your development team in the
enviable position of under
promising and over delivering
while still being on time and on
budget.
Consequences
Early in the project you do
not have an exact definition of
what will be delivered, you
merely have one that you believe
is going to be close. Many
stakeholders are uncomfortable
with this approach and will
insist on more requirements
modeling up front than is
actually healthy for your
project. Expect some
interesting political battles as
a result.
 |
|
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.
|
