Feature-driven development

The primary unit of work in a Feature-Driven Development (FDD) process is a feature. Those features are the end result of a detailed System Modeling effort, focusing on creating one-to-many domain models in significant detail, mapping out where features live in the system's domain, how (or if) they are expected to interact with each other—the sort of information that should come out of use cases, data structures, flow models, and Interprocess Communication models. Once the overall model is established, a feature list is constructed and prioritized, with a specific view to at least trying to keep the implementation time frame of each feature in the list at a reasonable maximum—two weeks seems to be the typical limit. If an individual feature is expected to take more than the longest acceptable time, it is subdivided until it can be accomplished and delivered in that time period.

Once the complete feature list is ready for implementation, iterations around completing those features are planned around a fixed time period. In each iteration, features or sets of features are assigned to developers, singly or in groups. Those developers work out a final implementation design, and review and refine it if needed. Once the design is deemed solid, development and testing of code to implement the design take place, and the resulting new code is promoted to the build- or distribution-ready code base for deployment.

FDD goes hand-in-hand with several development best practices—automated testing, configuration management, and regular builds so that, if they aren't a full, formal Continuous Integration process, they are very close to being one. The feature teams are generally small, dynamically formed, and intended to have at least two individuals, at a minimum, on them, with the intention of promoting collaboration and early feedback, especially on a features' designs and implementation quality.

FDD may be a good option for large and complex systems—by breaking work down into small, manageable features, even development in the context of very large, very complex systems is going to be maintainable with a good success rate. The processes around getting any individual feature up and running are simple and easily understood. Barring occasional check-ins to make sure that development isn't stalling for some reason, FDD is very lightweight and non-intrusive. Feature teams will usually have a lead developer associated with them, who has some responsibility for coordinating the development efforts and refining implementation details when and if needed. That does mean, however, that the lead developer is less likely to contribute to the actual code, particularly if they are spending much of their time executing coordination or design-refinement efforts, or mentoring other members of the team.