Agile Softwareentwicklung

Feature Driven Development

25.08.2010
Feature Driven Development (FDD) wurde 1997 von Jeff De Luca und Peter Coad als schlanke Methode für die Softwareentwicklung entworfen. Im Laufe der Zeit wurde die Methode kontinuierlich weiterentwickelt.

FDD stellt den Begriff "Feature" in den Mittelpunkt der Entwicklung. Ein Feature ist dabei definiert als etwas, was in den Augen des Kunden nützlich ist. Jedes Feature stellt somit einen Mehrwert für den Kunden dar. Die Beschreibung eines Features erfolgt in einem Satz nach dem Schema:

Action

Result

Object

Berechne

das Saldo

des Kontos

Features sind also sehr feingranulare Funktionen. Oftmals bestehen zwischen den Features Abhängigkeiten. Zusammenhängende Features werden zu so genannten Feature Sets gruppiert. Die Beschreibung eines Feature Sets folgt dabei dem Muster:

Action

-ing

object

Mak-

-ing

a product sale

Feature Sets wiederum werden zu übergeordneten fachlichen Gruppen, den Major Feature Sets, zusammengefasst. Die Major Feature Sets werden beschrieben nach dem Schema:

<object>management - Beispiel (in Englisch): "product sale management"

Für die Umsetzung dieser Features sieht FDD Prozesse, Rollen und Best Practices vor. Alle drei Bereiche werden auf den folgenden Seiten ausführlich beschrieben.

Hier vorab die Bewertung des FDD-Vorgehens durch BQI Research.

Bewertung BQI Research

Foto: BQI

FDD deckt die Aspekte des Systemdesign/technische Konzeption (SD) vollständig ab. Nicht ganz so gut sieht es beim Projekt-Management (PM), Qualitäts-Management (QM), Requirements-Management (RM) und bei der Implementierung (IMP) aus. Wenig Abdeckung gibt es für Test (T) und Integration/Einführung (INT). Wartung (W) und Betrieb (B) werden überhaupt nicht unterstützt.

Das Rollenmodell

Das Rollenmodell von FDD unterscheidet Schlüsselrollen, unterstützende Rollen und zusätzliche Rollen.

Schlüsselrollen sind:

Unterstützende Rollen sind:

Zusätzliche Rollen sind:

Typischerweise werden - zumal in kleinen Teams - die Mitarbeiter mehrere Rollen ausfüllen.

Das Prozessmodell

Das Prozessmodell umfasst fünf Prozesse:

FDD-Prozessablauf (Wikipedia)
Foto: BQI

Die drei ersten Prozesse werden dabei in der Regel nur einmal durchlaufen. Die beiden letzten Prozesse hingegen bilden die Realisierung der Features ab und laufen zyklisch.

Entwicklung Gesamtmodell:

Ziel dieses ersten Prozesses ist es, Konsens über Inhalt und Umfang des zu entwickelnden Systems zu erhalten, sowie das fachliche Kernmodell zu entwickeln. Dazu 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.

Erstellung Feature-Liste:

Im zweiten Prozess werden die im ersten Prozess festgelegten Systembereiche, die Features, definiert. Dabei wird das eingangs erwähnte dreistufige Schema (Major Feature Sets, Feature Sets und Features) verwendet. Ein Feature darf maximal zwei Wochen für die 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.

Planung 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 (Class Owner List).

Entwurf je Feature:

Der Chef-Programmierer analysiert das ihm zugeordnete Feature und stellt, auf der Basis der involvierten Klassen, das Feature-Team zusammen. Ein Domain Walkthrough wird durchlaufen, das Objektmodell verfeinert, das Design des Features festgelegt und schließlich im Rahmen einer Inspektion überprüft.

Konstruktion 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. Über die inkrementelle Entwicklung pro Feature hinaus legt FDD keine Iterationen fest. Bei größeren Projekten ist es jedoch sinnvoll, formelle Meilensteine zu definieren, an denen Teile des endgültigen Produktes vorgeführt werden können. Somit kann der Fortschritt auch in tatsächlich lauffähigem Code dokumentiert werden.

Best Practices

Best Practices sind Methoden und Vorgehensweisen, die sich in vielen Projekten bewährt haben. FDD sieht die Verwendung folgender Best Practices vor:

Domain Object Modeling:

Zu Beginn eines jeden Projektes gilt es, sich einen möglichst guten Überblick über den Problembereich zu verschaffen. Hierfür sieht FDD die Erstellung eines Domain-Objektmodells vor. Das Domain-Objektmodell umfasst dabei nur Geschäftsobjekte, die in der Regel persistent sind. GUIs und Control-Objekte spielen zu diesem Zeitpunkt noch keine Rolle - diese würden den Blick auf das Geschäftsobjektmodell erschweren.

Developing by Feature:

Features sind kleine und überschaubare Einheiten, die sich in maximal zwei Wochen realisieren lassen. Jede Funktion die zu komplex ist, um in dieser Zeit umgesetzt zu werden, wird so lange weiter detailliert, bis man die entsprechende Größe erreicht. Dadurch wird es einfacher, korrekte Funktionalität zu liefern und das System zu erweitern bzw. zu modifizieren.

Individual Class (Code) Ownership:

Im Gegensatz zum "Collective Code Ownership" (alle Entwickler sind gemeinsam für die Codebasis verantwortlich, wie es zum Beispiel XP vorsieht) propagiert FDD "Individual Code Ownership". Hierbei gibt es dedizierte Verantwortliche für einzelne Sourcecode-Stücke. Die Verantwortlichen sind für die Konsistenz, Performance und die konzeptionelle Integrität ihres Codes zuständig.

Feature-Teams:

Feature-Teams sind Teams die sich dynamisch formieren, um Features umzusetzen. Dadurch werden bei der Implementierung unterschiedliche Designvorschläge diskutiert, bevor die Festlegung auf ein Design erfolgt.

Inspections:

Als eine Maßnahme der Qualitätssicherung sieht FDD die Inspections vor. Dabei werden die Entwicklungsergebnisse von anderen Teammitgliedern begutachtet. Dies dient zum einen der Verbesserung der Codebasis, zum anderen wird der Wissenstransfer zwischen den Team-Mitgliedern gefördert. Inspections dienen zudem der effizienten Durchsetzung von Coding-Standards. Im Rahmen von FDD werden Code-Inspektionen typischerweise im Kontext der Feature Teams vorgenommen, wobei der Chef-Programmierer als Leiter des Teams auch den Grad der Formalität einer solchen Inspektion bestimmt.

FDD hat keinen integrierten Test, wie er etwa mit XPs "Test first" populär geworden ist. Das heißt nicht, dass diese Praxis im Rahmen von FDD nicht sinnvoll oder nicht integrierbar wäre. Sie wird nur nicht zwingend gefordert. Generell wird beim Thema Testen auf die jeweils bestehenden Qualitätssicherungsprozesse innerhalb der Organisation verwiesen. Jeder Entwickler sollte seinen eigenen "Smoke-Test" mit den von ihm codierten Komponenten durchführen.

Regular Builds:

Regelmäßige Builds des gesamten Produktes dienen zum einen der Sichtbarkeit des Projektfortschritts - gekoppelt an lauffähigen Code - und zum anderen (vor allem in großen Projekten) der Vorbeugung von dramatischen Integrationsproblemen. Die Häufigkeit solcher Builds ist im FDD nicht festgelegt. Abhängig vom Projekt kann ein wöchentlicher, täglicher oder auch ein kontinuierlicher Buildprozess die beste Wahl sein. FDD fordert nur, dass der Build regelmäßig stattfindet. Im Zweifel ist ein kurzer Zyklus die bessere Wahl.

Configuration Management:

Jedes Projekt sollte unabhängig vom Vorgehensmodell ein Konfigurations-Management haben. Das Konfigurationsmanagement ist die zentrale Basis für die Projektergebnisse und somit der "Single Point of Truth". Grundsätzlich sollten alle im Projekt erstellten Artefakte (Analyse, Design, Code, Testfälle etc.) dem Konfigurations-Management unterliegen.

Visibility of Progress and Results:

Die kontinuierliche Feinabstimmung des Projektverlaufs setzt voraus, dass der Projektfortschritt zeitnah und feingranular sichtbar gemacht wird. Der Grad der Granularität ist wiederum das einzelne Feature. FDD schlägt hierfür ein einfaches Report-Format auf der Basis von "Mini-Meilensteinen" vor. Folgende sechs Meilensteine werden bei der Entwicklung jedes Features festgelegt:

Die einzelnen Meilensteine sind so definiert, dass ihr Erreichen eine "binäre" Entscheidung ist. Der Domain Walkthrough ist abgeschlossen, das Design ist erstellt, das Design ist inspiziert, der Code ist erstellt, der Code ist inspiziert, der Code ist freigegeben für den nächsten Build.

Für das Erreichen eines jeden Meilensteins wird ein gewisser Prozentsatz am Gesamtaufwand zur Erstellung des Features angesetzt. Es werden hier keine Feature-spezifischen Schätzungen betrachtet, sondern Standardwerte, die den bisherigen Erfahrungswerten in der Organisation entsprechen. Palmer und Felsing empfehlen in ihrem Buch "A practical Guide to Feature DrivenDevelopment" für den Anfang folgende Werte:

Domain Walkthrough

1 Prozent

Design

40 Prozent

Design Inspection

3 Prozent

Code

45 Prozent

Code Inspection

10 Prozent

Promote to Build

1 Prozent

Auf dieser Grundlage lässt sich für jedes einzelne Feature ein prozentualer Grad der Fertigstellung berechnen. Der Grad mag zwar nicht völlig korrekt sein, aber da Features feingranulare Anforderungen (mithin klein) sind, ist auch der Fehler klein und meistens vernachlässigbar.

Auf derselben Grundlage werden auch die Pläne erstellt, indem jedes Team (beziehungsweise der jeweils betraute Chef-Programmierer) abschätzt, wie lange die Fertigstellung des Features dauern wird. Die Feinplanung der einzelnen Meilensteine wird wieder nach dem obigen Schema vorgenommen.