With the
first activity being to build an object model, some may conclude FDD is a
model-driven process. It is not. While the model is central to the process, an
FDD project is like a Scrum or eXtreme Programming project in being requirement-driven.
Small, client-valued requirements referred to as features drive the project;
the model merely helps guide. Formally, FDD defines a feature as a small,
client-valued function expressed in the form: <action> <result>
<object> (e.g., “'calculate the total of a sale'”) [Palmer-1]. By small,
we mean a feature typically takes 1-3 days to implement, occasionally 5 days
but never 10 or more days to implement.
Unlike
Scrum and eXtreme Programming that use a flat list of backlog items or user
stories, FDD organizes its features into a three level hierarchy that it
unimaginatively calls the feature list. Larger projects/teams need this extra
organization. It helps them manage the larger numbers of items that are
typically found on an FDD features list than on a Scrum-style backlog.
To define
the upper levels in the feature list hierarchy, the team derives a set of
domain subject areas from the high-level breakdown of the problem domain that
the domain experts naturally used during the object modeling sessions. Then
within these areas, the team identifies the business activities of that area
and places individual features within one of those activities. Therefore, in
the features list we have areas containing activities that in turn contain
features.
In practice,
building the features list is a formalization of the features already discussed
during the development of the object model. For this reason, lead developers or
Chief Programmers can perform this task using the knowledge they gained during
the modeling (FDD refers to lead developers as Chief Programmers in honor of
Mills/Brooks idea of ‘surgical teams’ [Brooks]). Other members of the modeling
team including the domain experts provide input to, and verification of the
list as necessary.
Not only
does this avoid the problems often encountered when customers/domain experts
that are unused to doing this sort of formal decomposition try to do it, it
provides another level of assurance that the Chief Programmers do understand
what is required.
In
addition, the ubiquitous language the model provides helps phrase features
consistently. This helps reduce frustration in larger teams caused by different
domain experts using different terms for the same thing or using the same terms
differently.
