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

• Developing by Feature

• Individual Class (Code) Ownership

• Feature Teams

• Inspections

• Regular Builds

• Configuration Management

• Visibility of Progress and Results

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:

• Domain Walkthrough

• Design

• Design Inspection

• Code

• Code Inspection

• Promote to Build

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.