Feature Driven Development(FDD)

#1 Develop an Overall Model

A initial project-wide activity with domain and development members under the guidance of an experienced object modeler in the role of Chief Architect.

A high-level walkthrough of the scope of the system and its context is performed. Detailed domain walkthroughs are then held for each area to be modeled. After each domain walkthrough, small teams are formed with a mix of domain and development staff who then compose their own models in support of that domain walk-through. The teams each present their models for peer review and discussion. One of the proposed models, or a merge of the models, is selected by consensus thus becoming the model for that domain area. A merge of the domain area model into an overall model is performed, adjusting model shape as required.The object model is then iteratively updated with content by the Design by Feature process #4.

#2 Build a Features List

An initial project-wide activity to identify all the features to support the requirements.

A team usually comprising just the Chief Programmers from process #1 is formed to functionally decompose the domain into Subject Areas, the business Activities within them and the Steps within each business Activity, thus forming the categorized features list. The top-level categorization for the features list comes from the partitioning of the domain by the domain experts in process #1.

#3 Plan By Feature

An initial project-wide activity to produce the development plan.

The project manager, development manager and the chief programmers plan the order that the features are to be implemented, based on feature dependencies, load across the development team and also on the complexity of the features to be implemented. The main tasks in this process are not a strict sequence. Like many planning activities they are considered together, with refinements made from one or more tasks and then considering the others again. A typical scenario is to consider the development sequence, then consider the assignment of business activities to chief programmers and in doing so, consider which of the key classes (only) are assigned to which developers (remember a chief programmer is also a developer). When this balance is achieved and the development sequence and assignment of business activities to chief programmers is essentially completed, then the class ownership is completed (beyond the key classes that were already considered for ownership).

#4 Design By Feature

A per-feature activity to produce the feature design package.

A number of features are scheduled for development by assigning them to a Chief Programmer. The Chief Programmer selects features for development from his "inbox" of assigned features. He may choose multiple features that happen to use the same classes (hence developers). Operationally, it is often the case that "sets" of features are scheduled for development at a time by the Chief Programmer. Such a set is called a Chief Programmer Work Package.The Chief Programmer then forms a Feature Team by identifying the owners of the classes (developers) likely to be involved in the development of the feature(s) he selects for development. This team then produces the Sequence Diagram(s) for the assigned feature(s). The Chief Programmer then refines the Object Model based on the content of the sequence diagram(s). The developers then write class and method prologues. A Design Inspection is held.

#5 Build By Feature

A per-feature activity to produce a completed client-valued function (feature).

Starting with the design package, the development class owners implement the items necessary for their class to support the design for this feature. The code developed is then unit tested and code inspected ? the order of which is determined by the Chief Programmer. After a successful code inspection, the code is promoted to the Build. 

Six Key Project Roles( FDD )

The Chief Architect(CA) is responsible for the overall design of the system.

The Chief Architect (CA) is responsible for the overall design of the system. Although the Chief Architect has the last say in FDD, he or she is responsible for running workshop design sessions where the team collaborates in the design of the system. This is a deeply technical role, requiring excellent technical and modeling skills, as well as good facilitation skills.

The  Chief Architect resolves disputes over design that the Chief Programmers cannot resolve themselves. For projects with both a complex problem domain and complicated technical architecture, the role may be split into domain architect and technical architect roles. The Chief Architect has the last say on all design issues. He or she steers the project through the technical obstacles confronting the project.