Feature-Driven Development: An Agile Alternative to Extreme Programming

produce object models for their respective portions of the domain, and then they return and review and compare each others models for consistency, correctness, completeness and clarity. Eventually they arrive at a domain object model that captures and conveys the key abstractions and relationships of the system.

Build a List of Features
With the initial domain model in place, the team then produces a list of features, where a "feature" is defined as a small, deliverable client-valued piece of functionality that is succinctly expressed using the format:

action result object [parameters]

Or, more precisely, with the following grammatical structure:

action {a|the} result {of|to|from|for|...} object [{with|for|of|...} parameters]

These are captured in traditional requirements documents, such as use-cases or formal specifications, and referenced in the corresponding use-cases and designs. Features are then grouped into subject-areas (or subject-domains) containing one or more feature-sets of several individual features. Each subject-area tends to take on the name of a core capability, such as " subject-name management."

Feature-sets within a subject-area can be integration-tested together, and each feature within a feature-set maps to a method in the domain-model. In business systems, a subject-area often maps to a business-function or business-domain, a feature-set to a particular business-process within that domain, and a feature to a particular business-activity or business-transaction within the overall business process/workflow.

Once an initial feature-list has been compiled and collated into feature-sets and subject-areas, a system review is conducted with domain experts/analysts and other stakeholders to evaluate the list for correctness, completeness, and consistency.

Plan by Feature
With a features list in place, the feature-sets and features are analyzed and estimated, and the feature-sets (or major feature-sets, depending on the size of the system) are sorted into a sequence of (possibly nested) time-boxes for releases, major-milestones (e.g., at least quarterly) and iterations (at least monthly, preferably 2-4 weeks). The sequencing is based on customer-assigned priorities, estimates, and technical dependencies among the feature-sets. Feature-sets are assigned to individual feature-teams (each led by a chief-programmer) and classes from the domain-model are assigned to individual developers, who are responsible for the creation and maintenance of the class.

Design by Feature & Build by Feature
Note that, thus far, the FDD process has been very different from other agile methods in that it does a substantial amount of up-front requirements, analysis, modeling, and planning for the entire system. FDD still tries to limit this to the minimally sufficient set of artifacts, and keep them as streamlined as is convenient, but it nonetheless performs this amount of up-front activity for requirements, modeling, and planning.

Once development is ready to start, the FDD feature-production "machine" kicks-in to high-gear: Iterations of the sequence "Design by Feature" & "Build by Feature" begin churning out tangible working results at a frequent and steady pace (about every two weeks, or less).

• Chief programmers select small groups of features to form "Chief-Programmer Work Packages" (CPWPs) which are the basic units of integration with the other feature-sets and feature-teams.
• The CPWPs are planned at a regular intervals (no less than bi-weekly), and the classes involved are identified and the class-owners are assigned the corresponding development tasks.

• The feature-team then collaborates to devise very detailed sequence diagrams and develops the interfaces and declarations for the corresponding classes and methods.

• A design inspection is held, and once successfully passed, the class-owners develop the code and unit-tests for their classes, then integrate their created/updated classes and conduct code-inspections.

• When all updates are inspected and the chief-programmer is satisfied with the results, the completed work-package and its features are "promoted" to the "main build" and the development and build processes