In 30 seconds
- Work is organized around small, client-valued features.
- Five processes: model, list features, plan, design and build by feature.
- Each feature should take two weeks or less.
Origins
Jeff De Luca developed FDD in 1997 for a large banking project in Singapore, with Peter Coad contributing the modelling approach. It was designed to work for larger teams than early XP.
The five processes
- Develop an overall domain model
- Build a feature list
- Plan by feature
- Design by feature
- Build by feature
The first three happen up front briefly; the last two repeat for each feature.
Small, client-valued features
Features are named action, result, object, such as calculate the total of a sale. Each should take two weeks or less. Bigger work is grouped into feature sets, similar to epics.
Myth vs reality
Myth · FDD is heavyweight.
Reality · Up-front modelling is brief; delivery is iterative.
Myth · FDD has no testing.
Reality · Inspections and unit tests are part of each feature build.
Myth · Features are the same as user stories.
Reality · Similar size, but phrased around the domain model.
FAQ
What roles does FDD use?
Chief architect, chief programmers, class owners and others.
Is FDD still used?
Less often by name, but feature-centric planning is common.
When does FDD fit?
Larger teams with a complex domain that benefits from a shared model.