Feature Driven Development

Größe: px

Ab Seite anzeigen:

Download "Feature Driven Development"

Heinz Kirchner
vor 9 Jahren
Abrufe

1 Feature Driven Development Agil nach V-Modell? Dipl.-Inform. Henning Wolf

2 Ü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

3 Woher kommt FDD? Jeff De Luca 1997 Singapore-Projekt 17 Monate, 50 Entwickler mit Peter Coad Kontinuierliche Weiterentwicklung Beschreibung auf 10 Seiten: Jeff De Luca 3

4 Was ist FDD? 5 (Teil-)Prozesse Rollenmodell Projektleiter Entwicklungsleiter Chefarchitekt (Chefmodellierer) Chef-Programmierer Entwickler Fachexperten 4

5 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

6 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

7 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

8 Zeitliche Abläufe max. 6 Monate 2-3 Wochen für 6 Monate max. 2 Wochen/Feature 8

9 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

10 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

11 Zeitlicher Ablauf: Parallele Teilprozesse 11

12 Hierarchisches Rollenmodell Dynamisches Featureteam Entwicklungsleiter Chef- Modellierer Projektleiter Chef- Entwickler Chef- Entwickler Chef- Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler Entwickler 12

13 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

14 Wasserfall vs. Feature-Wirbel Analyse (grob) Feature 1 Entwurf Konstruktion Test Feature 2 Entwurf Konstruktion Test Feature n Entwurf Konstruktion Test 14

15 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

16 Wie passt das zum V-Modell XT? Feature-Liste (UML-Color- Modell) 16

17 Wie passt das zum V-Modell XT? (Feature-Liste) UML-Color- Modell 17

18 Wie passt das zum V-Modell XT? Agile Projektdurchführungsstrategie 18

19 Wie passt das zum V-Modell XT? Inkrementelle Projektdurchführungsstrategie 19

20 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

21 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

22 Vielen Dank für die Aufmerksamkeit 17./18.Juni /20.Juni

Ähnliche Dokumente

Feature Driven Development

Feature Driven Development Driven Development Die andere agile Methode Dipl.-Inform. Henning Wolf [email protected] Überblick Warum mit FDD beschäftigen? Woher kommt FDD? Was ist FDD? 5 (Teil-)Prozesse Rollenmodell Vorteile