Feature Driven Development Agil nach V-Modell? Dipl.-Inform. Henning Wolf henning.wolf@it-agile.de
Überblick Überblick: Feature Driven Development Woher kommt FDD? Voraussetzungen 5 (Teil-)Prozesse Rollenmodell Vorteile von FDD Wie passt das ins V-Modell XT? Fazit 2
Woher kommt FDD? Jeff De Luca 1997 Singapore-Projekt 17 Monate, 50 Entwickler mit Peter Coad Kontinuierliche Weiterentwicklung http://www.featuredrivendevelopment.com Beschreibung auf 10 Seiten: Jeff De Luca http://www.nebulon.com/articles/fdd/download/fddprocessesa4.pdf 3
Was ist FDD? 5 (Teil-)Prozesse Rollenmodell Projektleiter Entwicklungsleiter Chefarchitekt (Chefmodellierer) Chef-Programmierer Entwickler Fachexperten 4
Entwickle Gesamtmodell Ziele: Domäne kennenlernen und verstehen Fachliches Klassenmodell Ggf. auch Sequenzdiagramme Beteiligte: Chefarchitekt = Moderator (Chef-)Programmierer Fachexperten Vorgehen: Meist Modeling In Color 5
Erstelle Featureliste Ziele: Alle Anforderungen in Form von Features liegen vor Basis für weiteres Vorgehen und Schätzung Beteiligte: Chef-Programmierer Anschließend Abstimmung mit Fachexperten Feature-Schema: <Aktion> <Ergebnis> <Objekt> Beispiel: Berechne Summe der Rechnungspositionen. Hierarchie der Features: Major Feature Set (Geschäftsbereich) Feature Set (Geschäftstätigkeit) Feature (Systemfunktion) 6
Plane je Feature Ziele: Projektplan erstellen Aufwände und Termine klären Flow für alle Entwickler herstellen Vorgehen: Feature-Klassen-Beziehungen ermitteln Class-Owner festlegen Arbeitsbelastung ausbalancieren Beteiligte: Projektleiter Entwicklungsleiter Es ergeben sich Feature-Teams: Alle Class-Owner der beteiligten Klassen. Chef-Programmierer 7
Zeitliche Abläufe max. 6 Monate 2-3 Wochen für 6 Monate max. 2 Wochen/Feature 8
Entwirf je Feature Ziele: Gemeinsamen Entwurf erstellen Aus gemeinsamen Entwürfen lernen Beteiligte: Feature-Team ggf. Chefarchitekt ggf. Chef-Programmierer Vorgehen: Im Team Klassen- und Sequenzdiagramme erstellen Design-Inspektionen Nach Entwirf je Feature folgt immer direkt Konstruiere je Feature desselben Features! 9
Konstruiere je Feature Ziele: Produktivklassen erstellen Tests erstellen Programmieren verbessern/lernen Beteiligte: Feature-Team ggf. Chefarchitekt ggf. Chef-Programmierer Vorgehen: Class-Owner programmieren Produktivklassen Class-Owner erstellen Tests Im Team erfolgen Code- Inspektionen Je Feature dauert Entwirf je Feature und Konstruiere je Feature nicht länger als 2 Wochen! 10
Zeitlicher Ablauf: Parallele Teilprozesse 11
Hierarchisches Rollenmodell Dynamisches Featureteam Entwicklungsleiter Chef- Modellierer Projektleiter Chef- Entwickler Chef- Entwickler Chef- Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler 12
Wasserfall vs. Feature-Wirbel Analyse Entwurf Feature 1 Feature 2 Feature n Konstruktion Feature 1 Feature 2 Feature n Test Feature 1 Feature 2 Feature n 13
Wasserfall vs. Feature-Wirbel Analyse (grob) Feature 1 Entwurf Konstruktion Test Feature 2 Entwurf Konstruktion Test Feature n Entwurf Konstruktion Test 14
Vorteile von FDD Klar beschrieben Weniger Hürden für viele Organisationen (im Vergleich zu anderen agilen Methoden) Skaliert gut Auch für große Projekte geeignet Initiale Modellierungsphase explizit vorgesehen (und auf angenehmer Abstraktionsebene) Passt gut zu Festpreiskonstellationen 15
Wie passt das zum V-Modell XT? Feature-Liste (UML-Color- Modell) 16
Wie passt das zum V-Modell XT? (Feature-Liste) UML-Color- Modell 17
Wie passt das zum V-Modell XT? Agile Projektdurchführungsstrategie 18
Wie passt das zum V-Modell XT? Inkrementelle Projektdurchführungsstrategie 19
Bei FDD fallen Lastenheft und Pflichtenheft zusammen Und bestehen aus: UML-Color-Model (der Kernkonzepte) Feature-Liste (feingranular) Das hat große Vorteile: Erstellung im direkten Dialog Unklarheiten können wechselseitig sofort geklärt werden Erleichtert Aufwandsschätzungen Granularität ist direkt zur Strukturierung des Projektes geeignet (deshalb feature-driven ) Schneller Entwicklungsstart möglich 20
Fazit FDD bietet leichtgewichtige Modelle Feature-Listen zur Anforderungsbeschreibung Color-Modeling zur Kern-Architekturbeschreibung Ein einfaches Prozessmodell Ein klares Rollenmodell FDD kann mit leichten Anpassungen auch V-Modell- XT-konform werden Für manches Projektsetting (Team, Kunde, Größe) ist FDD eine Alternative! 21
Vielen Dank für die Aufmerksamkeit 17./18.Juni 2008 19./20.Juni 2008 22