FDD-Reisebericht: Features beschreiben und organisieren

Im Feature-Driven-Development werden feingranulare Features für Planung, Realisierung und Tracking verwendet. Dabei gilt, dass ein Feature maximal 2 Wochen Realisierungszeit benötigen darf. Meistens sind die Features aber viel kleiner (z.B. 1 Tag).

Interessant ist, dass FDD ein festes Beschreibungsschema für Features hat:

<Aktion> <Ergebnis> <Objekt>


So entsteht ein einfacher Satz wie "Berechne Summe der Auftragspositionen".

Damit man in großen Projekten die Übersicht nicht verliert, werden Features zu Feature-Sets zusammengestellt. Dabei empfiehlt sich eine feste Richtlinie, wie Feature-Sets gebildet werden. FDD schlägt für Geschäftsanwendungen vor, Feature-Sets nach Geschäftstätigkeiten zu bilden, z.B. "Auftragsannahme".

Hat man es mit sehr vielen Feature-Sets zu tun, werden diese wiederum in Major Feature-Sets gruppiert, wieder nach einer festen Richtlinie. FDD schlägt für Geschäftsanwendungen vor, Major Feature-Sets nach Geschäftsbereichen zu organisieren, z.B. "Einkauf".

In meinem aktuellen Projekt haben wir die Anforderungen auf das FDD-Schema umgestellt und damit einige positive Erfahrungen gemacht:

• Wir verwalten unsere Anforderungen in einem Issue-Tracker (Mantis). Der FDD-Satz bildet die Zusammenfassung der Anforderung. Dadurch sind i.d.R. die Zusammenfassungen in einer Übersichtsliste so aussagekräftig, dass man in Diskussionen die Details gar nicht mehr braucht. Früher sind wir mit der Übersichtsliste der Anforderungen und dem Ausdruck der Details zu jeder Anforderung in Abstimmungsmeetings gegangen. Heute haben wir nur noch die Übersichtsliste dabei. Es ist alles viel übersichtlicher geworden.


• Durch die Feature-Beschreibungsform fällt leicht auf, wenn man versehentlich mehere Dinge in einer Anforderung zusammengeworfen hat. Man trennt Anforderungen eher auf und das Risiko sinkt, dass man was Wichtiges übersieht (versteckte Features).


• Durch das Feature-Beschreibungsschema sind unsere Features kleiner geworden. Insbesondere haben wir keine Features mehr, die sehr groß sind. Das ist besonders wichtig, weil wir gerade die großen Anforderungen immer wieder gnadenlos unterschätzt haben.


• Wenn Anwender / Kunden Anforderungen beschreiben, passen die Beschreibungen in der Regel nicht ins FDD-Schema und in den Details finden sich häufig auch mehrere Anforderungen. Wir formen die Anforderungen dann in die FDD-Form um.


• Die Gruppierung in Feature-Sets ist für das Tracking mit Parking-Log-Diagrammen sehr nützlich. In Mantis setzen wir die Kategorien als Feature-Sets ein und verwenden als Richtlinie Feature-Set=Geschäftstätigkeit.


• Major-Feature-Sets bilden wir in Mantis als eigene Projekte an.

Post bewerten