Feature-Driven Development: An Agile Alternative to Extreme Programming


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 time boxes for releases, major milestones (e.g., at least quarterly) and iterations that run at least monthly, but preferably every 2 to 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. Classes from the domain model are then assigned to individual developers, who are responsible for the creation and maintenance of the class.

Design by Feature and 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 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 into high gear. Iterations of the sequence design by feature and build by feature begin churning out tangible working results at a frequent and steady pace of 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.
• CPWPs are planned at 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 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

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.