1. Entwickle ein Gesamtmodell
Fachexperten und Entwickler definieren unter Leitung des Chefarchitekten Inhalt und Umfang des zu entwickelnden Systems. In Kleingruppen, die jeweils aus einem Fachexperten und zwei bis drei Entwicklern bestehen, werden Fachmodelle für die einzelnen Bereiche des Systems erstellt, in der Gesamtgruppe vorgestellt, ggf. überarbeitet und schließlich integriert. Das Ziel dieser ersten Phase ist es, einen Konsens über Inhalt und Umfang des zu entwickelnden Systems herzustellen sowie das fachliche Kernmodell zu erarbeiten. Für die Modellierung wird meistens Color Modeling verwendet.

2. Erstelle eine Feature-Liste
Die Chefprogrammierer detaillieren die im Gesamtmodell festgelegten Fachgebiete in Features. Dazu wird ein dreistufiges Schema verwendet: Fachgebiete bestehen aus Geschäftstätigkeiten, die durch Schritte ausgeführt werden. Die Schritte entsprechen den Features. Features werden sehr prägnant nach dem einfachen Schema <Aktion> <Ergebnis> <Objekt> beschrieben, z.B. »Berechne Gesamtsumme der Verkäufe«. Die Realisierung eines Features darf maximal zwei Wochen benötigen. Die meisten Features dauern jedoch nur wenige Stunden oder
Tage. Das Ergebnis dieses Prozesses ist eine kategorisierte Feature-Liste.

3. Plane je Feature
Der Projektleiter, der Entwicklungsleiter und die Chefprogrammierer planen 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 dieses 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. Auf dieser Basis werden Feature-Pakete geschnürt und durch temporäre Feature-Teams realisiert.

4. Entwirf je Feature
Die Chefprogrammierer weisen die anstehenden Features den Entwicklerteams auf Basis des Klassenbesitztums zu. Die Entwicklerteams ergeben sich also dynamisch je Feature aus den Klassenbesitzern der zugehörigen Klassen. Diese Feature-Teams erstellen gemeinsam 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 gemeinsam zur Qualitätssicherung systematisch inspiziert. Bei fachlichen Unklarheiten können die Fachexperten hinzugezogen werden.

5. Konstruiere je Feature
Die Entwickler programmieren die im vorigen Prozess entworfenen Features.
Bei der Programmierung werden Codeinspektionen und Komponententests
zur Qualitätssicherung eingesetzt. »Entwirf« und »Konstruiere« werden je Feature nacheinander durchlaufen, sodass sie in der Praxis ineinander übergehen. Damit laufen in einem Projekt in der Regel viele dieser Prozesse gleichzeitig, weil Features parallel abgearbeitet werden.
Im Gegensatz zu anderen agilen Methoden fällt auf, dass es für Entwurf und Konstruktion der Features kein Iterationskonzept gibt. Das ist der vorgelagerten Modellierung und einer Vorstellung von Festpreisprojekten geschuldet. Eine kundengetriebene Umplanung der Inhalte zur Projektlaufzeit ist nur in sehr geringem Maße möglich. Eine inkrementelle Auslieferung ist bei passender zeitlicher Planung der Einzelfeatures jedoch problemlos machbar und auch erwünscht.

FDD bietet entscheidende Vorteile:

• Stellt elegante Strukturierungsmöglichkeiten für Anforderungen vor
• Ist auch für große und heterogene Projektteams gut geeignet
• Bietet durch sein Rollenmodell eine gesunde Basis für ein diszipliniertes Vorgehen
• Ist für Festpreisprojekte sehr gut geeignet
• Lässt sich leichter als andere agile Methoden in große Organisationen einführen

Die deutschsprachige FDD-Definition kann hier als PDF heruntergeladen werden.

Feature Driven Development, FDD, FDDI, the FDD logo, are trademarks of Nebulon Pty. Ltd.