Feature Driven Development
Feature Driven Development ( FDD abbr. ) is a collection of techniques, structures, roles and methods for project management in the context of agile software development.
Basics
FDD was defined as lean method by Jeff De Luca in 1997 to perform a great time- critical project (15 months, 50 developers). Since then, FDD has continually evolved. FDD provides the feature term in the center of development. Each feature represents an added value for the customer represents the development is organized by feature plan. An important role is played by the chief architect (English Chief Architect), who constantly keeps track of the overall architecture and the technical core models. For larger teams individual development teams of programmers chief (English Chief Programmer ) will be performed.
FDD defines a process and a role model, which combine well with existing traditional project structures. Therefore, many find it easier for companies to introduce FDD as XP or Scrum. In addition, FDD is very compact in the spirit of agile methods. It can be completely described on 10 pages.
FDD process model
FDD projects through five processes.
The first three processes are performed within a few days. The processes 4 and 5 are performed in constant change, because each feature is implemented in a maximum of two weeks.
Process # 1: Develop an overall model
In the first trial subject matter experts and developers define under the direction of the chief architect of the content and scope of the system to be developed. In small groups, specialized models for different parts of the system be created that presented in the group, if necessary, revised and finally integrated. The aim of this first phase is a consensus on the content and scope of the system to be developed as well as the technical core model.
Process # 2: Create a feature list
In the second process, the Chief Programmer detail the process set out in the first system areas in features.
For this purpose, a three-stage scheme is used: Subjects (English Subject Areas) consist of business activities (English Business Activities), which are executed by steps (English Steps).
The steps correspond to the features.
The features are written according to the simple scheme
In the third process, the project manager, the development manager and the chief programmer plan the order in which to be implemented in the features. They are based on the dependencies between the features, the capacity utilization of the programming team as well as the complexity of features.
Based on the plan, the completion dates for each business activity are defined. Each business activity gets assigned as the owner of a chief programmer. In addition, developers are known for the core classes specified as the owner (English Class Owner List ).
Process # 4: Design each feature
In the fourth process, the chief programmer, the upcoming features developer teams based on the Klassenbesitztums. Create teams of developers, one or more sequence diagrams for the features and the chief programmer refine class models based on sequence diagrams. The developers then write first class and method bodies. Finally, the results shall be inspected. For clarity, the technical experts can be consulted.
Process # 5: Construct each feature
In the fifth process, the developers program that prepared in the fourth process features. When programming, unit testing and code inspections are used for quality assurance.