Feature-driven development

Feature-driven development (FDD) is an agile software development methodology that organizes work around features – small, client-valued pieces of functionality – and delivers them in short, regular iterations. It was devised by Jeff De Luca in 1997 for a 50-person, 15-month project at a Singapore lending institution, with Peter Coad contributing the object-modeling approach on which the method’s design step rests. FDD was first set out in print by Stephen Palmer and Mac Felsing in A Practical Guide to Feature-Driven Development (2002).

FDD is iterative and incremental, but it carries out more up-front modeling than the other methods in the agile family. The domain is modeled collaboratively before delivery begins, and that model is then decomposed into the feature list that drives the rest of the project. This makes FDD a fit for larger teams working in a complex, reasonably well-understood domain, where a shared model up front reduces integration risk.

The five processes

FDD is defined by five processes. The first three are performed once at the start of a project; the last two repeat for every batch of features through to delivery.

  1. Develop an overall model. Domain experts and developers collaborate in a workshop to produce an object model of the domain, using Peter Coad’s modeling in color to distinguish kinds of classes by role.
  2. Build a features list. The team decomposes the overall model into a hierarchy of features. Features are grouped into feature sets, which are themselves grouped into major feature sets corresponding to business activities.
  3. Plan by feature. The feature list is sequenced and assigned. Chief programmers take ownership of feature sets, and the order of work is planned around dependencies and business priority.
  4. Design by feature. A chief programmer leads a small feature team through a design for a small batch of features, producing sequence diagrams and refining the model where needed.
  5. Build by feature. The feature team implements, tests, and integrates the features from that batch. A feature is only counted as complete once it has been inspected and integrated into the main build.

Features

A feature is a small piece of functionality that is meaningful to a client of the system. It is written in a standard form, <action> the <result> <by/for/of> <object>, eg. calculate the total of a sale or list the scheduled departures of an airport. The constraint that a feature be completable in under two weeks keeps work batches small and progress visible. A feature is either done or it is not, and the percentage of features complete is the project’s primary progress metric.

This use of "feature" is unrelated to the pejorative feature factory. The two terms share a word but describe different things. An FDD feature is a fine-grained unit of delivery, whereas a feature factory is a dysfunction in which a team is reduced to a pipeline of feature output.

Roles and feature teams

FDD assigns explicit ownership. A chief programmer, modeled on the surgical team's chief surgeon, leads design and integration for a set of features and mentors the team working on them. A feature team is a small, dynamically formed group that assembles for the duration of a feature batch and disbands when the work is integrated. This keeps knowledge flowing across the team rather than siloed, while still placing a single experienced developer in charge of each design.

Compared with other agile methods

FDD sits alongside Scrum, Extreme Programming (XP), DSDM, and Crystal Clear in the agile family, but differs in emphasis. Scrum prescribes time-boxed sprints and a set of ceremonies without prescribing engineering practice. XP prescribes engineering practices such as test-driven development without prescribing a planning unit. FDD prescribes both a planning unit, the feature, and an up-front modeling step, which makes it more prescriptive about design than its siblings. It suits teams large enough to need a shared model and a degree of coordination that lighter methods do not address.

See also

References

  • Palmer and Felsing (2002). A Practical Guide to Feature-Driven Development. Prentice Hall.