Feature Driven Development

from Wikipedia, the free encyclopedia

Feature Driven Development (FDD) is a collection of work techniques, structures, roles and methods for project management in the context of agile software development .

Basics

FDD was defined as a lean method by Jeff De Luca in 1997 to carry out a large time sensitive project (15 months, 50 developers). Since then, FDD has been continuously developed. FDD puts the concept of features at the center of development. Each feature represents added value for the customer. Development is organized on the basis of a feature plan. The chief architect plays an important role as he always has an overview of the overall architecture and the technical core models. With larger teams, individual development teams are led by chief programmers.

FDD defines a process and role model that harmonize well with existing classic project structures. Therefore, many companies find it easier to implement FDD than XP or Scrum . In addition, FDD is very compact in the sense of agile methods. It can be completely described on 10 pages.

FDD process model

FDD projects go through five processes.

Process # 1: Develop an overall model (roles: all project participants)
Process # 2: Create a feature list (roles: usually only the chief programmers)
Process # 3: Plan for each feature (roles: project manager, development manager, chief programmer)
Process # 4: Design each feature (roles: chief programmer, developer)
Process # 5: Construct per feature (roles: developer)

Process model in FDD

The first three processes are completed within a few days. Processes 4 and 5 are carried out in constant alternation because each feature is implemented in a maximum of two weeks.

Process # 1: Develop an overall model

In the first process, technical experts and developers, under the direction of the chief architect, define the content and scope of the system to be developed. In small groups, specialist models are created for the individual areas of the system, which are presented to the group, revised if necessary, 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 programmers detail the system areas defined in the first process in features. A three-stage scheme is used for this: Subject areas consist of business activities that are carried out by steps. The steps correspond to the features. The features are written down according to the simple scheme <Action> <Result> <Object>, e.g. B. "Calculate Total Sales". A feature can take a maximum of two weeks to be implemented. The result of this second process is a categorized list of features, the top-level categories of which come from the subject matter experts from process # 1.

Process # 3: Plan per feature

In the third process, the project manager, development manager and chief programmer plan the order in which features are to be implemented. They are based on the dependencies between the features, the workload of the programming teams and the complexity of the features.

The completion dates for each business activity are set on the basis of the plan. Each business activity is assigned a chief programmer as owner. In addition, developers are defined as owners for the known core classes (class owner list).

Process # 4: design per feature

In the fourth process, the chief programmers assign the upcoming features to development teams based on class ownership. The development teams create one or more sequence diagrams for the features and the chief programmers refine the class models based on the sequence diagrams. The developers then write the first class and method bodies. Finally, the generated results are inspected. In the event of technical uncertainties, the technical experts can be called in.

Process # 5: Construct per feature

In the fifth process, the developers program the features prepared in the fourth process. During programming, component tests and code inspections are used for quality assurance.

literature

  • Peter Coad, Eric Lefebvre, Jeff De Luca: Java modeling In Color With UML: Enterprise Components and Process Prentice Hall International, 1999, ISBN 0-13-011510-X
  • Stephen R. Palmer, John M. Felsing: A Practical Guide to the Feature-Driven Development Prentice Hall International, 2002, ISBN 0-13-067615-2 .
  • Henning Wolf, Stefan Roock, Martin Lippert: eXtreme Programming dpunkt, 2nd, revised. u. exp. Ed., 2005, ISBN 3-89864-339-5 . The book also includes a brief description of FDD. Parts of this Wikipedia entry are based on the description in the book with the kind permission of dpunkt Verlag.
  • Michael Hüttermann: Agile Java Development in Practice O'Reilly, 2007, ISBN 3-89721-482-2 . The book also includes a brief description of FDD.

Web links