Feature-Driven Development: An Agile Alternative to Extreme Programming

[article]

control, status accounting, and auditing and 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 by feature, with six milestones per feature: domain walkthrough, design, design inspection, code, code inspection, and promote-to-build (planned and actual dates are tracked)
• Features and 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.
• Regular build and integration plans are made and monitored using CPWPs that are then promoted to the main build.
• CPWPs are more than just a build or a branch/label. They contain all the information necessary to perform CM audits on the promoted build, such as unique identification of each work-package; completed line-items for the status of each delivered feature; outputs from the tasks defined in the task-descriptions of the feature-development plan; 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 design/code is promoted to the next level of development readiness.
• The use of both change tracking and version control tools is mandated for carrying out the CM-related activities of FDD.

Notice how FDD embraces, rather than eschews, documentation and traceability while still taking great strides to keep it as light and simple as possible. The feature-lists and detailed domain model are the enabling mechanisms for traceability and status reporting. They also make substantial use of tools and technologies to automatically track and report status/progress of features.


In some ways, FDD attempts to use feature sets and features as configuration items not merely for the functional requirements baselined, but for the development and product

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!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09