 |
Feature-Driven Development (FDD) is
a client-centric, architecture-centric, and pragmatic
software process. The term “client” in FDD is used to
represent what Agile Modeling (AM) refers to as
project stakeholders or
eXtreme Programming (XP) calls customers. FDD was
first introduced to the world in 1999 via the book
Java Modeling In Color with UML, a combination of
the software process followed by Jeff DeLuca’s company
and Peter Coad’s concept of features. FDD was first
applied on a 15 month, 50-person project for a large
Singapore bank in 1997, which was immediately followed
by a second, 18-month long 250-person project. A more
substantial description is published in the book
A Practical Guide to Feature-Driven Development as
well as the
Feature Driven Development web site. |
|
As the name implies,
features are an important aspect of FDD. A feature
is a small, client-valued function expressed in the form
<action><result><object>. For example, “Calculate the
total of a sale”, “Validate the password of a user”, and
“Authorize the sales transaction of a customer”.
Features are to FDD as
use cases are to the
Rational Unified Process (RUP) and
user stories are to
XP – they’re a primary source of requirements and
the primary input into your planning efforts.
As you see in
Figure 1 there are five main activities in FDD that
are performed iteratively. The first is Develop An
Overall Model, the initial result being a high-level
object model and notes. At the start of a project your
goal is to identify and understand the fundamentals of
the domain that your system is addressing, and
throughout the project you will flesh this model out to
reflect what you’re building. The second step is Build
A
Features List, grouping them into
related sets and
subject areas. These first two steps map to the
initial envisioning effort of AMDD (see
Figure 2). Next you Plan By
Feature, the end result being a development, the
identification of class owners (more on this in a
minute), and the identification of feature set owners.
The majority of the effort on an FDD project, roughly
75%, is comprised of the fourth and fifth steps: Design
By Feature and Build By Feature. These two activities
are exactly what you’d expect, they include tasks such
as detailed modeling, programming, testing, and
packaging of the system.
Figure 1.
The FDD project lifecycle.
Figure 2.
The lifecycle of AMDD.
An FDD project starts by performing
the first three steps in the equivalent of the RUP’s
Inception phase or XP’s “iteration 0”, the goal being to
identify the scope of the effort, the
initial
architecture, and the initial high-level plan.
Construction efforts occur in two-week (or less)
iterations, similar to XP although a little extreme for
most RUP teams, with the team iteratively working
through all five steps as needed. As with other agile
software development processes, systems are delivered
incrementally by FDD teams.
There are six primary roles on an
FDD project: Project Manager, Chief Architect,
Development Manager, Chief Programmer, Class Owner, and
Domain Expert. An individual will take on one or more
roles on a project as you would expect. The concept of
a class owner is where FDD differs from XP. XP includes
a practice called
Collective Ownership the idea of which is that any
developer can update any artifact, including source
code, as required. FDD takes a different approach in
that it assigns classes to individual developers, so if
a feature requires changes to several classes then the
owners of those classes must work together as a feature
team to implement it. Just like programming pairs will
model storm to think something through before they
code it, so will feature teams.
FDD also defines a collection of
supporting roles, including:
-
Domain Manager
-
Release Manager
-
Language Guru
-
Build Engineer
-
Toolsmith
-
System Administrator
-
Tester
-
Deployer
-
Technical Writer
FDD’s five steps are supported by
several best practices. The first is domain object
modeling, the creation of a high-level class diagram and
supporting artifacts that describes the problem domain.
Developing by feature and individual class ownership are
also best practices, as is having developers work
together in feature teams. Inspections are an important
aspect of FDD, as they are with the RUP. FDD also
insists on regular builds, similar to XP, and
configuration management. Finally, FDD promotes a best
practice called reporting/visibility of results, similar
to XP and AM’s philosophy of
open and honest communication.
How would Agile Modeling (AM) be
applied on an FDD project? The principles and practices
can be clearly applied to FDD’s two modeling-oriented
steps – develop an overall model and design by feature.
The only apparent mismatch between the two processes is
FDD’s practice of class ownership and AM’s practice of
collective ownership, but I would argue that this
isn’t the case. FDD’s practice pertains to coding but
does not to modeling, on a FDD project people work
together in teams to model, along the lines of AM’s
model with others practice, and therefore several people
will be working on your shared collection of modeling
artifacts.
 |
|
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.
|
