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

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!