Feature Driven Development

Agil nach V-Modell?

Dipl.-Inform. Henning Wolfhenning.wolf@it-agile.de

2

Überblick: Feature Driven DevelopmentWoher kommt FDD?

Voraussetzungen

5 (Teil-)Prozesse

Rollenmodell

Vorteile von FDD

Wie passt das ins V-Modell XT?

Fazit

Überblick

3

Jeff De Luca

1997 Singapore-Projekt17 Monate, 50 Entwickler

mit Peter Coad

Kontinuierliche Weiterentwicklung

http://www.featuredrivendevelopment.com

Beschreibung auf 10 Seiten:http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf

Woher kommt FDD?

Jeff De Luca

4

5 (Teil-)Prozesse

RollenmodellProjektleiterEntwicklungsleiterChefarchitekt (Chefmodellierer)Chef-ProgrammiererEntwicklerFachexperten

Was ist FDD?

5

Ziele:Domäne kennenlernenund verstehen

Fachliches Klassenmodell

Ggf. auch Sequenzdiagramme

Beteiligte: Chefarchitekt = Moderator

(Chef-)Programmierer

Fachexperten

Vorgehen:Meist Modeling In Color

Entwickle Gesamtmodell

6

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

Erstelle Featureliste

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)

7

Ziele:Projektplan erstellen

Aufwände und Termine klären

„Flow“ für alle Entwickler herstellen

Beteiligte: Projektleiter

Entwicklungsleiter

Chef-Programmierer

Plane je Feature

Vorgehen:Feature-Klassen-Beziehungen ermitteln

Class-Owner festlegen

Arbeitsbelastung ausbalancieren

Es ergeben sich Feature-Teams: Alle Class-Owner der beteiligten Klassen.

8

Zeitliche Abläufe

max. 6 Monate

2-3 Wochen für 6 Monate max. 2 Wochen/Feature

9

Ziele:Gemeinsamen Entwurf erstellen

Aus gemeinsamen Entwürfen lernen

Beteiligte: Feature-Team

ggf. Chefarchitekt

ggf. Chef-Programmierer

Entwirf je Feature

Vorgehen:Im Team

Klassen- und Sequenzdiagramme erstellen

Design-Inspektionen

Nach „Entwirf je Feature“ folgt immer direkt

„Konstruiere je Feature“ desselben Features!

10

Ziele:Produktivklassen erstellen

Tests erstellen

Programmieren verbessern/lernen

Beteiligte: Feature-Team

ggf. Chefarchitekt

ggf. Chef-Programmierer

Konstruiere je Feature

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!

11

Zeitlicher Ablauf: Parallele Teilprozesse

12

Hierarchisches Rollenmodell

Projekt-leiter

Chef-Entwickler

Chef-Entwickler

Chef-Entwickler

Entwick-lungs-leiter

Chef-Model-lierer

Entwickler Entwickler EntwicklerEntwickler EntwicklerEntwickler Entwickler Entwickler Entwickler

DynamischesFeatureteam

13

Wasserfall vs. Feature-Wirbel

Analyse

Entwurf

Konstruktion

Test

Feature 1

Feature 2

Feature n

…

Feature 1

Feature 2

Feature n

…

Feature 1

Feature 2

Feature n

…

14

Wasserfall vs. Feature-Wirbel

Analyse (grob)

Feature 1

Feature 2

Feature n

Entwurf

Konstruktion

Test Entwurf

Konstruktion

Test Entwurf

Konstruktion

Test

15

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

Vorteile von FDD

16

Wie passt das zum V-Modell XT?

Feature-Liste(UML-Color-

Modell)

17

Wie passt das zum V-Modell XT?

(Feature-Liste)UML-Color-

Modell

18

Wie passt das zum V-Modell XT?

Agile Projektdurchführungsstrategie

19

Wie passt das zum V-Modell XT?

InkrementelleProjektdurchführungsstrategie

20

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

Bei FDD fallen Lastenheft und Pflichtenheft zusammen

21

FDD bietet leichtgewichtige ModelleFeature-Listen zur AnforderungsbeschreibungColor-Modeling zur Kern-ArchitekturbeschreibungEin einfaches ProzessmodellEin klares Rollenmodell

FDD kann mit leichten An-passungen auch V-Modell-XT-konform werden

Für manches Projektsetting(Team, Kunde, Größe) ist FDD eine Alternative!

Fazit

22

Vielen Dank für die Aufmerksamkeit

19./20.Juni 200817./18.Juni 2008