Feature Driven Development

Feature Driven Development

Feature Driven Development (Abk. FDD) ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Softwareentwicklung.

Inhaltsverzeichnis

Grundlagen

FDD wurde als schlanke Methode von Jeff De Luca im Jahre 1997 definiert, um ein großes zeitkritisches Projekt (15 Monate, 50 Entwickler) durchzuführen. Seitdem wurde FDD kontinuierlich weiterentwickelt. FDD stellt den Feature-Begriff in den Mittelpunkt der Entwicklung. Jedes Feature stellt einen Mehrwert für den Kunden dar. Die Entwicklung wird anhand eines Feature-Plans organisiert. Eine wichtige Rolle spielt der Chefarchitekt (engl. Chief Architect), der ständig den Überblick über die Gesamtarchitektur und die fachlichen Kernmodelle behält. Bei größeren Teams werden einzelne Entwicklerteams von Chefprogrammierern (engl. Chief Programmer) geführt.

FDD definiert ein Prozess- und ein Rollenmodell, die gut mit existierenden klassischen Projektstrukturen harmonieren. Daher fällt es vielen Unternehmen leichter, FDD einzuführen als XP oder Scrum. Außerdem ist FDD ganz im Sinne der agilen Methoden sehr kompakt. Es lässt sich auf 10 Seiten komplett beschreiben.

FDD-Prozessmodell

FDD-Projekte durchlaufen fünf Prozesse.

  1. Prozess #1: Entwickle ein Gesamtmodell (Rollen: alle Projektbeteiligte)
  2. Prozess #2: Erstelle eine Feature-Liste (Rollen: in der Regel nur die Chefprogrammierer)
  3. Prozess #3: Plane je Feature (Rollen: Projektleiter, Entwicklungsleiter, Chefprogrammierer)
  4. Prozess #4: Entwurf je Feature (Rollen: Chefprogrammierer, Entwickler)
  5. Prozess #5: Konstruiere je Feature (Rollen: Entwickler)

Prozessmodell in FDD

Die ersten drei Prozesse werden innerhalb weniger Tage durchlaufen. Die Prozesse 4 und 5 werden in ständigem Wechsel durchgeführt, weil jedes Feature in maximal zwei Wochen realisiert wird.

Prozess #1: Entwickle ein Gesamtmodell

Im ersten Prozess definieren Fachexperten und Entwickler unter Leitung des Chefarchitekten Inhalt und Umfang des zu entwickelnden Systems. In Kleingruppen werden Fachmodelle für die einzelnen Bereiche des Systems erstellt, die in der Gruppe vorgestellt, ggf. überarbeitet und schließlich integriert werden. Das Ziel dieser ersten Phase ist ein Konsens über Inhalt und Umfang des zu entwickelnden Systems sowie das fachliche Kernmodell.

Prozess #2: Erstelle eine Feature-Liste

Im zweiten Prozess detaillieren die Chefprogrammierer die im ersten Prozess festgelegten Systembereiche in Features. Dazu wird ein dreistufiges Schema verwendet: Fachgebiete (engl. Subject Areas) bestehen aus Geschäftstätigkeiten (engl. Business Activities), die durch Schritte (engl. Steps) ausgeführt werden. Die Schritte entsprechen den Features. Die Features werden nach dem einfachen Schema <Aktion> <Ergebnis> <Objekt> aufgeschrieben, z.B. „Berechne Gesamtsumme der Verkäufe“. Ein Feature darf maximal zwei Wochen zu seiner Realisierung benötigen. Das Ergebnis dieses zweiten Prozesses ist eine kategorisierte Feature-Liste, deren Kategorien auf oberster Ebene von den Fachexperten aus Prozess #1 stammen.

Prozess #3: Plane je Feature

Im dritten Prozess planen der Projektleiter, der Entwicklungsleiter und die Chefprogrammierer die Reihenfolge, in der Features realisiert werden sollen. Dabei richten sie sich nach den Abhängigkeiten zwischen den Features, der Auslastung der Programmierteams sowie der Komplexität der Features.

Auf Basis des Plans werden die Fertigstellungstermine je Geschäftsaktivität festgelegt. Jede Geschäftsaktivität bekommt einen Chefprogrammierer als Besitzer zugeordnet. Außerdem werden für die bekannten Kernklassen Entwickler als Besitzer festgelegt (engl. Class Owner List).

Prozess #4: Entwerfe je Feature

Im vierten Prozess weisen die Chefprogrammierer die anstehenden Features Entwicklerteams auf Basis des Klassenbesitztums zu. Die Entwicklerteams erstellen ein oder mehrere Sequenzdiagramme für die Features und die Chefprogrammierer verfeinern die Klassenmodelle auf Basis der Sequenzdiagramme. Die Entwickler schreiben dann erste Klassen- und Methodenrümpfe. Schließlich werden die erstellten Ergebnisse inspiziert. Bei fachlichen Unklarheiten können die Fachexperten hinzugezogen werden.

Prozess #5: Konstruiere je Feature

Im fünften Prozess programmieren die Entwickler die im vierten Prozess vorbereiteten Features. Bei der Programmierung werden Komponententests und Code-Inspektionen zur Qualitätssicherung eingesetzt.

Literatur

  • 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, 2., überarb. u. erw. Aufl., 2005, ISBN 3-89864-339-5. Das Buch enthält auch eine kurze Beschreibung von FDD. Teile dieses Wikipedia-Eintrages basieren mit freundlicher Genehmigung des dpunkt-Verlages auf der Beschreibung im Buch.
  • Michael Hüttermann: Agile Java-Entwicklung in der Praxis O'Reilly, 2007, ISBN 3-89721-482-2. Das Buch enthält auch eine kurze Beschreibung von FDD.

Weblinks


Wikimedia Foundation.

Игры ⚽ Нужно решить контрольную?

Schlagen Sie auch in anderen Wörterbüchern nach:

  • Feature Driven Development — (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry recognized best practices into a cohesive… …   Wikipedia

  • Feature driven development — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен …   Википедия

  • Test-driven development — (TDD ) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and… …   Wikipedia

  • Agile software development — poster Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self organizing, cross functional teams. It… …   Wikipedia

  • Agile Development — Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität (lat.agilis flink, beweglich ) in der Softwareentwicklung. Je nach Kontext bezieht sich der Begriff auf Teilbereiche der Softwareentwicklung – wie im Fall von Agile… …   Deutsch Wikipedia

  • Internet-Speed Development — What is Internet Speed DevelopmentInternet Speed Development is an Agile Software Development development method using a combined spiral model/waterfall model with daily builds aimed at developing a product with high speed.It was developed in the …   Wikipedia

  • List of software development philosophies — This is an incomplete list of approaches, styles, and philosophies in software development.* Agile software development * Agile Unified Process (AUP) * Behavior Driven Development (BDD) * Big Design Up Front (BDUF) * Brooks s law * Cathedral and… …   Wikipedia

  • Scrum (development) — Scrum is an iterative incremental process of software development commonly used with agile software development. Despite the fact that Scrum is not an acronym, some companies implementing the process have been known to adhere to an all capital… …   Wikipedia

  • Web application development — is the process and practice of developing web applications Fact|date=February 2007.RiskJust as with a traditional desktop application, web applications have varying levels of risk. A personal home page is much less risky than, for example, a… …   Wikipedia

  • Development communication — Development Communication, has been alternatively defined as a type of marketing and public opinion research that is used specifically to develop effective communication or as the use of communication to promote social development. Defined as the …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”