Feature-Driven Development: An Agile Alternative to Extreme Programming

• are repeated for the next batch of features that make-up the next CPWP.

Notice that not all of the design is "up front" before implementation begins. The domain modeling work performed at the beginning fleshes out the overall shape of the problem domain and design model, but detailed design and dynamic interactions are done during the "Design by Feature" phase.

FDD Best Practices
And that is the essence of the FDD process. It has the ability to fit securely in-between a set of front-end system engineering process of creating initial high-level requirements, and a back-end process of system build/package, and independent system-level testing. It also resembles more traditional plan-based development in its approach to requirements, design and planning.

Throughout the FDD process, the set of key or "best" practices that form the "gears" of the "FDD machine" are:

• Domain Object Modeling (typically using Color Modeling, though not always explicitly stated) done highly collaboratively with a chief architect and domain experts
• Iterative/incremental Development driven by Feature-sets and features as the units of integration, build, and promotion

• Feature Teams (led by "Chief Programmers")

• Individual Code Ownership (on a per-class basis)

• Inspections and Reviews (for models/designs, feature-lists, and code)

• Regular Builds

• Configuration Management

• Visible and meaningful Reporting of Status/Results

The first five practices above are evident from the description of the five processes of FDD. The later three practices are a bit less apparent, and all strongly relate to CM, so let's discuss the CM aspects of FDD in a bit more detail in the next section.

FDD and SCM
Juha Kolska's 2003 report on"  Software Configuration Management in Agile Methods" describes FDD as one of the few agile methods that explicitly mentions software CM (not just version control) and specific software CM practices as a key element. FDD contains the following practices which relate to configuration planning, identification & baselining, control, status-accounting, and auditing & reviews:

• Requirements are explicitly captured, and traceability is explicitly maintained from requirements to features, to model-elements, to source-code classes and tests

• Features are tracked (" Track by Feature" ) with six milestones per feature: domain walkthrough, design, design inspection, code, code-inspection, promote-to-build (planned and actual dates are tracked)

• Features & feature-sets have status and progress visibly reported to the development team, to project/program leads, and to stakeholders and upper management. FDD defines the content and format for each of these different types of status-accounting reports

• New requirements and features are subject to explicit change-control once development plans are made and development begins

• Change authorization happens by allocating feature-sets to feature-teams, assigning features (and CPWPs) to chief-programmers, and assigning individual owners to control all source-code changes to individual classes/modules ( Does Class Ownership really work? ).

• Regular build & integration plans are made and monitored using Chief-Programmer Work-Packages (CPWPs), which are then promoted to the "main build." 

• CPWPs are more than just a "build" or a branch/label; CPWPs contain all the information necessary to perform CM audits on the promoted build, such as

1. unique identification of each work-package
2. completed line-items for the status of each delivered feature
3. outputs from the tasks defined in the task-descriptions of the feature-development plan
4. lists of all the deliverables in each work-package

 It should be noted that FDD does not specify the precise content of CPWPs.

• Each feature-team uses a feature-team integration "area" (an integration "workspace" and/or a feature-team integration branch) to base their current in -progress work of the appropriate "main build" version, and to develop, test, and promote changes and work-packages from the feature-team area to the "main build."

• Formal design reviews/walkthroughs and code-inspections are required and tracked before the