Feature-Driven Development Bewertung und Voraussetzungen einer erfolgreichen Anwendung

Transkript

1 Feature-Driven Development Bewertung und Voraussetzungen einer erfolgreichen Anwendung Kevin Meergans Hochschule Reutlingen Studiengang Medien- und Kommunikationsinformatik Seminar Auswahlthemen (SAT) bei Professor Dr. Frank Dopatka Abstract: Die folgende Arbeit setzt sich kritisch mit Feature-Driven Development (FDD) auseinander, einer agilen Methode, die 1997 entwickelt wurde, um die Nachteile traditioneller Prozesse in der Softwareentwicklung auszubessern. Diese Arbeit soll aufzeigen, wo wiederum die Schwächen FDDs liegen und welche Faktoren für die erfolgreiche Umsetzung des Prozesses nötig sind. Dazu werden, nach einer kompakten Vorstellung Feature-Driven Developments und seiner Konzepte, einzelne Aspekte des Prozesses gesondert betrachtet und bewertet, um zuletzt die entscheidenden Bedingungen für seine erfolgreiche Anwendung zusammenzufassen.

2 1 Einleitung Die Gewährleistung von Qualität sowie die Einhaltung von Deadlines und Budgets sind seit jeher die Hauptprobleme in der Softwareentwicklung, die sich seit den 60er Jahren durch die Unfähigkeit diese Risiken zu überwinden in einer Krise befindet. Um die Probleme in den Griff zu bekommen, wurden Prozesse entwickelt, die den Entwicklungsablauf leiten und kontrollieren sowie den wiederholbaren Erfolg sicherstellen sollten. Doch mit der Anwendung von Prozessen ergaben sich viele neue Probleme, während die bekannten Risiken der Entwicklung nur teilweise gesenkt werden konnten. Viele der, in dieser Arbeit als traditionelle Prozesse bezeichneten, Ansätze wurden in ihrem Bestreben die Entwicklung zu planen und zu kontrollieren so umfangreich, dass ihre strikte Befolgung und der damit verbundene bürokratische Aufwand mehr Zeit in Anspruch nahmen als die eigentliche Entwicklungsarbeit, während die Entwicklungsteams dadurch zur selben Zeit zunehmend demoralisiert und unzufrieden wurden. Dokumente wurden wichtiger als codierte Ergebnisse, die Befolgung des Prozesses wichtiger als nötige Anpassungen und kreative Softwareentwicklung. Vgl. [CLD99, S.187]. Als Gegenbewegung bildete sich die agile Bewegung, die sich zur agilen Allianz zusammenschloss und 2001 ihre gemeinsamen Werte im agilen Manifest niederschrieb. Unter anderem sollte der Fokus der Softwareentwicklung wieder mehr auf die Menschen und die Entwicklung funktionierender Software selbst gesetzt werden, während die ausufernde Bürokratie älterer Prozesse abgebaut werden sollte. Agile Softwareprojekte sollten zudem flexibel auf Veränderungen reagieren können, statt einem strikten Plan zu folgen. Vgl. [Hunt06, S.10f.]. Durch dieses Verschieben des Fokus auf die Entwicklung wurden jedoch agile Projekte für Manager ungleich schwieriger zu planen und zu verfolgen, da die Projekte keinem festen Plan mehr folgten, sondern sich flexibel den jeweiligen Bedingungen anpassten. Auch das Anfertigen von begleitenden Dokumenten wurde stark eingeschränkt und erschwerte die Kontrolle von Entwicklung und Ergebnissen seitens der Projektleitung entstand während eines großen objektorientierten Projektes für eine Bank in Singapur ein neuer Prozess, der zwar der agilen Bewegung angehört, allerdings ebenso versucht Vorzüge traditioneller Prozesse einzubinden. Zuvor war die Umsetzung in einem ersten Anlauf und unter Verwendung eines traditionellen Prozesses gescheitert, als das Projekt nach zwei Jahren und der Anfertigung unzähliger Dokumente abgebrochen und als nicht umsetzbar erklärt wurde, ohne dass es je zur Codierung gekommen war. Jeff De Luca, der Projektmanager des gescheiterten Vorhabens, hatte auch bei diesem zweiten Versuch die Leitung und vereinte seine Ansätze eines neuen Prozesses mit den Ideen von Peter Coad, der die Modellierung des Projektes leiten sollte, um einen Prozess zu entwickeln, der als Feature-Driven Development (FDD) bekannt wurde. Tatsächlich wurde das Singapur- Projekt, das zu dem Zeitpunkt eines der größten Java-Projekte weltweit war, mit FDD und unter den neuen Bedingungen noch zum Erfolg geführt und pünktlich sowie im 2

3 finanziellen Rahmen abgeschlossen. Vgl. [High02, S.269ff.]. Der im Laufe des Projektes entwickelte Prozess betont die Bedeutung des Menschen als wichtigsten Faktor in der Entwicklung und unterstützt durch seine Rolleneinteilungen und Konzepte Zusammenarbeit, Interaktion und Kommunikation sowohl innerhalb des Teams als auch mit dem Kunden. Zudem definiert FDD die auszuführenden Aktivitäten kurz und präzise auf nur wenigen Seiten, ganz im Gegensatz zu den umfangreichen traditionellen Prozessen, wie etwa dem Rational Unified Process (RUP). Damit sollen den Entwicklern kurze Anleitungen an die Hand gegeben werden, während die eigentliche Entwicklung und regelmäßige greifbare Ergebnisse, ein weiteres Anliegen der Erfinder, im Vordergrund stehen. Die Ansätze sind flexibel und anpassungsfähig und sollen kreative und innovative Entwicklungsarbeit fördern. Gleichzeitig stellt FDD neben diesen typisch agilen Ansätzen und einem Rahmen für das Vorgehen in der Entwicklung auch eine Reihe von Konzepten zur Planung und Kontrolle bereit, um Managern und Kunden die Verfolgung und Steuerung des Projektes zu erleichtern. Feature-Driven Development passt sich zudem der Tatsache an, dass Entwicklungskreisläufe zunehmend kürzer werden, um Risiken und vom Kundenwunsch abweichende Ergebnisse zu minimieren. Vgl. [CLD99, S.183ff]. Die erfolgreiche Anwendung FDDs in Singapur stellte eindrucksvoll unter Beweis, wie der Prozess die Umsetzung selbst derart großer Projekte effektiv unterstützte, ohne dass Bürokratie die Arbeit der Entwickler behinderte oder Rahmenbedingungen aus den Augen verloren wurden. Auch in der Fachliteratur sind kaum umfangreichere kritische Beiträge über Feature-Driven Development zu finden. Aus diesem Grund soll diese Arbeit neben den Vorzügen des Prozesses vor allem zeigen, wo die Schwächen und Risiken Feature-Driven Developments und seiner Konzepte liegen und welche Voraussetzungen nötig sind, damit ein FDD-Projekt erfolgreich wie das Singapur-Projekt durchgeführt werden kann. Dazu sollen dem Leser in den ersten drei Kapiteln zunächst, als Grundlage für das weitere Verständnis, die durch FDD definierten Rollen und Teilprozesse sowie wichtige Konzepte des Prozesses vorgestellt werden. In den anschließenden Abschnitten werden dann einzelne charakteristische Aspekte von Feature-Driven Development gesondert bewertet, um dann im letzten Kapitel die gewonnenen Erkenntnisse nochmals zusammenzufassen, um Faktoren für die erfolgreiche Anwendung FDDs herauszuarbeiten. 3

4 2 Grundlagen 2.1 Rollen in Feature-Driven Development Feature-Driven Development definiert sechs Schlüsselrollen, die im Anschluss kurz erläutert werden. Da es sich lediglich um Rollen handelt, können sich je nach Umfang und Komplexität eines Projektes auch mehrere Personen die Aufgaben einer Rolle teilen oder mehrere Rollen gleichzeitig von einer Person ausgefüllt werden. Vgl. [PF02, S.28f]. Projektmanager Der Projektmanager leitet das Projekt und ist für alle Fragen des Budgets, Personals, der Ressourcen, Räumlichkeiten und Ausstattung zuständig. Zudem berichtet er den Fortschritt des Projektes nach außen, während er gleichzeitig dafür sorgt, dass das Team weitestgehend ungestört seiner Arbeit nachgehen kann. Vgl. [PF02, S.28]. Development Manager Der Development Manager ist für die Leitung der Entwicklungsarbeit zuständig und kümmert sich um die Nutzung und Verteilung der Ressourcen. Er ist zudem der Ansprechpartner für die Chief Programmer, wenn diese Probleme oder Konflikte nicht untereinander lösen können. Vgl. [PF02, S.29]. Chief Architect Der Chief Architect ist hauptverantwortlich für den Grobentwurf des Systems. Er leitet die Modellierungsabschnitte und entscheidet über kritische Fragen sowie Entwurfsalternativen. Vgl. [PF02, S.28]. Chief Programmer Chief Programmer sind erfahrene Entwickler, die an Analyse und Entwurf des Systems mitwirken und kleine Teams von Programmierern in den Entwicklungsphasen der Features betreuen und leiten, vgl. [PF02, S.29]. Class Owner Class Owner sind Entwickler, die jeweils alleinig für den Entwurf, die Implementierung sowie Änderungen an einer Klasse verantwortlich sind, vgl. [CLD99, S.196]. Sie arbeiten unter der Leitung eines Chief Programmers in kleinen Teams an der Entwicklung von Features, vgl. [PF02, S.29]. Ein Entwickler kann dabei auch Class Owner mehrerer Klassen sein, vgl. [PF02, S.68]. 4

5 Domain Experts (Fachexperten) Domain Experts sind Fachexperten, die sich mit dem zu entwickelnden System und dessen Anforderungen auskennen. Bei ihnen kann es sich sowohl um zukünftige Benutzer als auch um Kunden oder Analysten handeln. Sie arbeiten in manchen Abschnitten des Projektes aktiv mit den Entwicklern zusammen und unterstützen über die gesamte Entwicklung hinweg das Team in beratender Funktion. Vgl. [PF02, S.30]. Zusätzlich gibt es noch einige unterstützende Rollen, vgl. [PF02, S.30], die das Entwicklungsteam bei dessen Arbeit unterstützen und bei der sonstigen Abwicklung und Durchführung des Projektes helfen. Diese sollen hier aber nicht weiter erläutert werden. 2.2 Konzepte Feature-Driven Developments Im Folgenden wird eine kurze Übersicht über wesentliche Schlüsselbegriffe und Konzepte von Feature-Driven Development gegeben. Feature Bei der Analyse der Systemanforderungen werden die funktionalen Anforderungen, die direkt für den Kunden von Bedeutung und Wert und damit selten technischer Natur sind, herausgearbeitet. Diese werden anschließend in kleine Blöcke, Features oder clientvalued functions" [PF02, S.39] genannt, gespalten, bis sie klein genug sind, um in maximal zwei Wochen vollständig umgesetzt zu werden. Dabei wird stets Wert darauf gelegt, dass die Features so formuliert werden, dass der Kunde den Nutzen jeweils direkt erkennt, die Bedeutung der Funktion für das System versteht und entsprechend Prioritäten für die Entwicklung setzen kann. Vgl. [PF02, S.39]. Zusammengehörige Features, die gemeinsam eine Aktivität beschreiben, können in Feature Sets zusammengefasst werden, die wiederum Teil einer Major Feature Set sein können, die ihrerseits einen Geschäftsbereich darstellt, vgl. [CLD99, S.185]. Class Ownership Den Entwicklern werden für die Entwicklung des Systems benötigte Klassen zugewiesen, für die sie anschließend als Class Owner alleinig verantwortlich sind, vgl. [PF02, S.43]. Feature Teams Jedem Chief Programmer werden mehrere Features zugewiesen, für deren jeweilige Umsetzung er mit den benötigten Class Ownern ein Feature Team bildet, vgl. [CLD99, S.196]. Da es sich um eine offene und dynamische Struktur handelt, kann sich die Zusammensetzung eines Teams von Feature zu Feature ändern und Class Owner können gleichzeitig Mitglieder mehrerer Feature Teams sein, vgl. [CLD99, S.196f]. 5

6 Auch die Chief Programmer, die als Leiter ihres Teams vor allem organisatorische Aufgaben wahrnehmen, können zur selben Zeit als Class Owner Mitglied eines anderen Feature Teams sein, vgl. [PF02, S.49]. Inspections Unter Inspections versteht man die Kontrolle von Entwürfen oder Code durch andere Entwickler mit dem Ziel, Fehler zu finden und damit die Qualität der Software sicherzustellen. In FDD entscheidet der jeweils für die Entwicklung eines Features zuständige Chief Programmer, was in speziellen Meetings durch wen kontrolliert wird, vgl. [PF02, S.185]. Dazu können bei Bedarf auch Entwickler außerhalb des Feature Teams hinzugezogen werden, vgl. [PF02, S.51]. Verfolgung des Fortschritts (Progress Tracking) Für jedes Feature sind innerhalb der Design by Feature-/ und Build by Feature- Abschnitte sechs Meilensteine definiert, mit denen jeweils ein anpassbarer prozentualer Entwicklungsfortschritt verbunden ist, vgl. [CLD99, S.198]. Dadurch ist es möglich, jederzeit den aktuellen Entwicklungsstatus eines Features festzustellen. Zusätzlich kann aus diesen Informationen auch der Fortschritt einer Feature Set oder der des gesamten Projektes mit großer Genauigkeit bestimmt werden. Abbildung 1: Die sechs Milestones, die jedes Feature durchläuft, vgl. [PF02, Table 5-3] Regelmäßige Ergebnisse/Berichte Durch die überschaubare Größe der Features können häufig und regelmäßig Arbeitsabschnitte abgeschlossen und greifbare Ergebnisse produziert werden, vgl. [CLD99, S.196]. Feature-Driven Development sieht wöchentliche Statusberichte an Team, Management und Kunden vor und liefert jeweils entsprechend angepasste Vorlagen zur Visualisierung des Fortschritts, vgl. [CLD99, S.199]. Dies erleichtert Managern die Planung und Kunden die Verfolgung des Projektes anhand verständlicher Berichte. 6

7 2.3 Prozesse in Feature-Driven Development In Feature-Driven Development gibt es fünf Teilprozesse, die jedes Projekt durchläuft. Diese sollen im Folgenden kurz beschrieben werden. Abbildung 2: Die fünf Teilprozesse in Feature-Driven Development, vgl. [PF02, Figure 4-3] 1. Develop an Overall Model In diesem ersten Abschnitt des Projektes arbeiten Fachexperten und Entwickler zusammen, um aus den Anforderungen des Kunden ein Objektmodell des gesamten Geschäftsbereiches des zu entwickelnden Systems zu erstellen. Dazu schildern die Fachexperten zunächst im Groben und später präziser und detaillierter auf einzelne Teile oder Teilbereiche bezogen, welche Fähigkeiten das zu entwickelnde System haben muss. Auf diesen Informationen aufbauend erstellen die Entwickler in Zusammenarbeit mit den Experten, meist in kleinen Gruppen, ein grobes Gerüst des Systems beziehungsweise Objektmodelle der einzelnen Bereiche, die letztendlich nach Evaluation und Diskussion in ein einzelnes Modell zusammengeführt werden. Zudem erstellt das Team bereits eine Informal Features List" [CLD99, S.191], in der bereits identifizierte sowie mutmaßlich benötigte Features erfasst werden. Vgl. [CLD99, S.191]. Aktuellere Versionen der Prozesse, wie sie in [PF02] formuliert werden, sehen eine solche Liste allerdings nicht mehr vor und erfassen sämtliche Features erst in Prozess Build a Features List Mit Unterstützung durch die Fachexperten identifiziert, gruppiert und gewichtet das Team alle Features, die zur Umsetzung der Systemanforderungen benötigt werden. Kriterium hierfür ist jeweils der Wert beziehungsweise die Bedeutung, den eine Funktion für den Kunden besitzt. Grundlage für diesen Prozess sind sowohl die Informal Features List, falls erstellt, als auch die Klassendiagramme der Modellierungsphase, aus denen weitere benötigte Systemfunktionen abgeleitet und zerlegt werden, bis sie klein genug sind, um als Feature in die Liste aufgenommen zu werden. Ergebnis des Prozesses ist eine komplette Features List, die, gewichtet und hierarchisch in Feature Sets und Major Feature Sets gegliedert, die Grundlage für die weiteren Entwicklungsschritte darstellt. Vgl. [CLD99, S.192]. 7

8 3. Plan by Feature Auf Basis der Features List wird in diesem Teilprozess die Reihenfolge bestimmt, in der die aufgelisteten Features am sinnvollsten entwickelt werden können. Hier müssen unter anderem Faktoren, wie die Komplexität sowie etwaige Beziehungen der Features untereinander, beachtet werden. Weiterhin wird ein Abschlussdatum für jede Feature Set vereinbart, aus denen sich auch ein Projektplan sowie ein Gesamtabschlussdatum bestimmen lassen. Zur Vorbereitung der eigentlichen Umsetzung der Features werden zudem die Klassen an Class Owner sowie Feature Sets an die Chief Programmer übergeben, die im Folgenden die Verantwortung für deren Entwicklung tragen. Vgl. [PF02, S.67f]. Bei den folgenden beiden Prozessen handelt es sich um iterativ für jedes Feature durchgeführte Aktivitäten. Ihre Dauer beschränkt sich also auf maximal zwei Wochen bis zur Fertigstellung des jeweiligen Features. 4. Design by Feature Der Reihenfolge der Planungsphase folgend, wählt der zuständige Chief Programmer jeweils ein Feature aus und bildet zusammen mit den Besitzern, der zu dessen Umsetzung benötigten Klassen, ein Feature Team. Die Inhalte eines kollektiv erarbeiteten detaillierten Sequenzdiagramms des aktuellen Features dienen sowohl als Vorlage für die spätere Implementierung als auch zur Anpassung und Erweiterung des Gesamtmodells aus Prozess 1. Die Class Owner schreiben bereits die Gerüste ihrer Klassen und zugehörigen Methoden und legen beispielsweise Parameter und Rückgabewerte fest. Eine Inspection des Entwurfs stellt die nötige Qualität sicher und schließt den Prozess ab. Vgl. [CLD99, S.194]. 5. Build by Feature Die Class Owner vervollständigen die vorbereiteten Klassen, indem sie die Methoden implementieren und diese anschließend mit Unit Tests testen. Eine durch das Feature Team durchgeführte Inspection des Codes schließt im erfolgreichen Fall die Arbeit an der Klasse ab. Sobald alle Klassen fertig gestellt sind und der Chief Programmer die Integration getestet hat, gilt das Feature als abgeschlossen und es wird mit dem Entwurf des nächsten Features begonnen. Vgl. [CLD99, S.195]. 2.4 Weitere Definitionen Extreme Programming (XP) Extreme Programming ist ein agiler Ansatz zur Softwareentwicklung, der wie FDD als Gegenbewegung zu den traditionellen Prozessen entstand. XP legt großen Wert auf Prinzipien wie Kommunikation und Einfachheit und ermöglicht Entwicklern schnell auf geänderte Anforderungen zu reagieren. Extreme Programming unterstützt zudem, ähnlich wie FDD wenn auch mit anderen Mitteln, Teamwork und setzt den Fokus auf die 8

9 erfolgreiche Entwicklung der Software und das Team selbst. Einige der verwendeten Ansätze sind Pair Programming, Collective Code Ownership und Test-Driven Development. Vgl. [Hunt06, S.16]. 3 Bewertung ausgewählter Konzepte und Aspekte Feature-Driven Developments In den folgenden Abschnitten werden zunächst ausgewählte Konzepte FDDs gesondert betrachtet und jeweils die Vorzüge gefolgt von den Risiken der jeweiligen Aspekte erörtert. Anschließend werden nach demselben Vorgehen die Ansätze Feature-Driven Developments in den Bereichen Kundenbeteiligung, Anpassbarkeit und Änderungen untersucht. 3.1 Class Ownership Class Ownership ist eines der zentralen Konzepte in Feature-Driven-Development und steht streng der Collective Ownership gegenüber, wie sie beispielsweise in Extreme Programming (XP) verwendet wird. Die beiden Ansätze sollen im Folgenden gegenübergestellt werden, um die Vorzüge und Nachteile von Class Ownership besser herauszuarbeiten. Collective Ownership sieht vor, dass sich die Programmierer die Verantwortung für den gesamten Code teilen und dieser jederzeit durch jeden Entwickler des Projektteams geändert werden darf, wodurch Verzögerungen durch Wartezeiten auf Änderungen eines anderen Entwicklers entfallen, vgl. [PF02, S.45]. Dennoch können auch diverse Risiken und Nachteile mit dem Einsatz von Collective Ownership verbunden sein. Durch die Beteiligung vieler Programmierer an der Codierung ist es deutlich schwerer konsistente, effiziente und elegante Klassen zu schreiben, wodurch aufwändige Verbesserungen und Refactoring nötig sind, vgl. [PF02, S.45]. FDDs Ansicht zu Refactoring wird kurz am Ende des Kapitels geschildert. Gerade in Teams, in denen Erfahrung, Ausbildung und Talent der Entwickler stark schwanken, ist es unwahrscheinlich, mit Collective Ownership einheitlichen, lesbaren Code zu erhalten, ohne dass dieser zuvor mehrfach überarbeitet und angepasst werden muss. Sinnvolle Änderungen an einer Klasse oder Programmeinheit setzen zudem voraus, dass dem Entwickler deren Funktionsweise bekannt ist. Folglich müssen sich Programmierer, die den Code bearbeiten wollen, erst zeitaufwändig einarbeiten, wenn durch die Änderungen keine anderen Teile des Programms beeinträchtigt werden sollen. Der durch oben genannte Gründe unter Umständen uneinheitliche Code erschwert zusätzlich das schnelle Verständnis. Die strikte Etablierung, Durchsetzung und Einhaltung von Programmierstandards kann hier jedoch Abhilfe schaffen. 9

10 Die Vorteile von Collective Ownership können allerdings auch durch das Verhalten mancher Entwickler gefährdet werden. Programmierer könnten es ablehnen, dass von ihnen geschriebener Code von jemand anderem geändert wird, wenn sie von der bestehenden Qualität überzeugt sind oder die Fähigkeiten des anderen anzweifeln. Hier gibt es viel Potenzial für Konflikte innerhalb des Entwicklungsteams. Es besteht das Risiko, dass einige wenige, von sich überzeugte, Entwickler dominant das Recht auf Änderungen für sich beanspruchen und letztendlich am Umfang der vorgenommenen Aufgaben scheitern, vgl. [PF02, S.44]. Darunter können Teamgeist und der weitere Zusammenhalt der Programmierer leiden, was sich letztendlich hemmend auf den Fortschritt in der Entwicklung auswirken wird. Class Ownership, wie sie in FDD eingesetzt wird, löst die meisten Probleme, die Collective Ownership betreffen. Für jede Klasse gibt es einen Experten, der alle Details kennt und Fragen seiner Kollegen bezüglich des Codes oder Designs schnell und präzise beantworten kann. Änderungen lassen sich zudem schnell und konsistent einfügen, da der entsprechende Class Owner sich nicht erst einarbeiten muss und Aufbau sowie Funktion seiner Klassen kennt. Nicht zuletzt tragen auch persönliche Gefühle der Entwickler, wie Stolz und Verantwortungsbewusstsein dazu bei, dass sie die Qualität ihrer Klassen auf hohem Niveau halten. Vgl. [PF02, S.43]. Letzteres auch um bei den Inspections einen guten Eindruck zu hinterlassen. Mit Class Ownership ist vor allem sichergestellt, dass es für jede Klasse einen Verantwortlichen gibt, während es bei Collective Ownership Programmteile geben kann, für die sich niemand direkt zuständig fühlt. Des Weiteren sind Konflikte unter den Programmierern unwahrscheinlicher, da jeder Entwickler seinen eigenen Zuständigkeitsbereich hat. Gerade bei größeren Projekten ist Class Ownership sinnvoll um Einarbeitungs- und Änderungszeiten zu minimieren, während Collective Ownership mit wachsender Projektgröße und ohne entsprechende Einteilung der Entwickler zunehmend problematisch wird. Trotz aller Vorteile lässt sich auch Class Ownership nicht ohne Risiken anwenden. Ein Problem besteht etwa in dem drohenden Verlust des Wissens über eine Klasse, wenn der zugehörige Class Owner das Projektteam verlässt, vgl. [PF02, S.43]. Die Einarbeitung eines neuen Entwicklers braucht Zeit und kann, insbesondere zu kritischen Zeitpunkten, wenn etwa andere Entwickler auf Veränderungen der Klassen angewiesen sind, für Verzögerungen bei der Entwicklung von Features sorgen. Etwas unterstützend können hier die Inspections wirken, durch die andere Entwickler bereits etwas mit den entsprechenden Klassen vertraut sind, da sie sich mit dem entsprechenden Code auseinandergesetzt haben. Ebenfalls möglich ist die Einarbeitung eines neuen Entwicklers durch den ausscheidenden Class Owner, sollte der Ausstieg absehbar sein. 10

11 Umständlich können auch umfassende Änderungen in Code oder Design sein, wenn sie mehrere voneinander abhängige Klassen betreffen, vgl. [PF02, S.43]. In diesem Fall müssen die Class Owner zusammenarbeiten und sich absprechen, um die Änderungen erfolgreich durchzuführen. Dies kann sich schwierig gestalten, da manche Class Owner, durch die Mitgliedschaft in mehreren Feature Teams gleichzeitig, unter Umständen gerade an etwas anderem mit größerer Dringlichkeit arbeiten oder es sich um komplexe Beziehungsgeflechte von Klassen handelt. Verzögerungen kann es auch geben, wenn ein für Änderungen benötigter Class Owner durch Krankheit oder ähnliches ausfällt. Organisatorisch muss die Projektleitung zudem sicherstellen, dass die Auslastung der Class Owner fair verteilt ist, um Unmut und Überarbeitung zu vermeiden. So sollten die Klassen, die einem Entwickler zugewiesen werden, möglichst aus einem Bereich des zu entwickelnden Systems kommen, um den Programmierern nicht die Kenntnis zu vieler Details abzuverlangen und die Bildung von Experten für einzelne Programmteile zu fördern. In diesem Zusammenhang kann es beispielsweise auch sinnvoll sein, ganze Klassenhierarchien, solange es der Umfang zulässt, an einen Programmierer zu übergeben, da sonst gerade Änderungen unnötigen Aufwand fordern. Es sollten auch nicht zu viele komplexe Klassen einem Entwickler zugewiesen werden. Zusätzlich problematisch kann die Anwendung von Class Ownership werden, wenn ein verhältnismäßig kleines Team an einem größeren oder besonders komplexen Projekt arbeitet. Dann kann es besonders schwierig sein, die Klassen zu verteilen ohne eine Überlastung mancher Programmierer zu riskieren oder die Vorteile des Konzeptes zu verlieren, wenn die Entwickler zu viele Klassen auf einmal betreuen müssen. Letztlich können auch durch Class Ownership Konflikte zwischen den Entwicklern entstehen, da für sämtliche Fehler im Code oder Verzögerungen jeweils die entsprechenden Class Owner als direkte Schuldige ausgemacht werden können und unter Umständen den Ärger der anderen Programmierer auf sich ziehen. Refactoring Insgesamt spielt Refactoring eher eine untergeordnete Rolle in Feature-Driven Development, das seinerseits vielmehr betont und anstrebt, so viel wie möglich gleich beim ersten Mal richtig zu machen, vgl. [High02, S.284]. Hier spielt vor allem die Modellierung in Prozess 1 eine wichtige Rolle, um die Notwendigkeit von Refactoring während der Implementierung zu verringern, vgl. [High02, S.281]. So werden in dieser Phase bereits alle benötigten Klassen identifiziert sowie alle wichtigen Strukturen und Beziehungen in einem Gesamtmodell festgelegt, das die Entwickler während des gesamten Projektes zur Orientierung und Anpassung nutzen können. Auch Inspections, die Einteilung in Feature Teams und eben die Class Ownership tragen unterstützend dazu bei, dass konsistente und effiziente Klassen geschrieben werden, die möglichst wenige Verbesserungen im Nachhinein benötigen. 11

12 3.2 Inspections Wie viele andere Konzepte Feature-Driven Developments sind auch die Inspections kein wirklich neuer Ansatz in der Softwareentwicklung. Richtig eingesetzt können sie jedoch sehr effektiv sein, um Fehler in Entwurf und Implementierung zu finden, vgl. [PF02, S.49]. Allein durch die Beteiligung mehrerer unterschiedlich erfahrener und denkender Entwickler an dem Prozess erhöht sich die Chance, Fehler und andere Probleme aufzudecken. FDD begünstigt den wirkungsvollen Einsatz von Inspections zudem durch seine anderen Konzepte, wie etwa Feature Teams oder auch die Features selbst, durch deren überschaubare Größe meist gewährleistet werden kann, dass die Treffen nicht allzu lange dauern und damit effektiv bleiben. In den Sitzungen kann zudem Wissensaustausch zwischen den Entwicklern stattfinden, vgl. [PF02, S.50]. Schließlich müssen sich die Programmierer vor den Treffen, in denen die Inspections stattfinden, jeweils mit dem Code oder Entwurf der anderen auseinandersetzen, um für das Meeting vorbereitet zu sein. Dabei und in den Treffen selbst, etwa in Diskussionen oder durch Vorschläge erfahrener Kollegen, können auch unerfahrene Entwickler dazulernen und letztendlich ihre Fähigkeiten verbessern. Programmierer halten zudem Standards und Richtlinien eher ein, wenn sie wissen, dass sich das ganze Feature Team mit ihrem Code oder Entwurf aktiv beschäftigen wird, vgl. [PF02, S.50]. Dies hilft die Einheitlichkeit von Klassen zu verbessern und erleichtert damit wiederum die Durchführung der Inspections, da die Einarbeitung leichter fällt. Zusätzlich fördern richtig durchgeführte Inspections den Zusammenhalt innerhalb des Teams, da die Arbeit aller Mitglieder und nicht nur die einzelner Entwickler Ziel der Kontrolle und Prüfung ist, vgl. [PF02, S.50]. Diese Gleichbehandlung kann manchen Entwicklern, ebenso wie die Tatsache, dass viele Inspections nur innerhalb des Feature Teams durchgeführt werden, dabei helfen, die Angst oder Nervosität zu nehmen, die sie anfangs möglicherweise gegenüber den Meetings empfinden. Damit die Inspections erfolgreich sind und alle voneinander profitieren, ist es essentiell wichtig, dass die Atmosphäre bei den Meetings positiv ist und dass die Teammitglieder respektvoll und fair miteinander umgehen. Die Diskussion der Arbeitsergebnisse darf nicht zu Bloßstellung oder gar Beleidigung und Streit führen, vgl. [PF02, S.51]. Daher ist Respekt vor der Arbeit des Anderen und die Aufstellung von Regeln für die Treffen im Vorfeld sehr wichtig, deren Einhaltung auch durchgesetzt werden muss. Konflikte durch Entwickler, die ihre Kollegen zu scharf kritisieren oder sehr empfindlich auf Kritik reagieren, lassen sich trotz allem unter Umständen nicht vermeiden und müssen individuell geklärt werden, damit das Ziel des Treffens nicht aus den Augen verloren wird. Da letztendlich der Chief Programmer des Feature Teams über Inhalt der Inspection entscheidet, ist es seine Aufgabe darauf zu achten, dass sich kein Entwickler zu Unrecht ständigen Kontrollen ausgesetzt sieht, um Unmut im Team zu vermeiden. 12

13 Insgesamt kann es durch Inspections zu diversen Verzögerungen für die Entwicklung von Features kommen, wofür diverse Gründe verantwortlich sein können. Sollte beispielsweise ein Feature im Umfang doch einmal den Rahmen einer Sitzung sprengen, muss diese zu einem späteren Zeitpunkt fortgeführt werden, um die Konzentration und Aufmerksamkeit der Teilnehmer nicht zu strapazieren. Des Weiteren kann sich der Abschluss der Inspection durch nötige Nachbesserungen von Code und Entwürfen, die bereits in einer vergangenen Sitzung abgelehnt wurden, gleich mehrfach nach hinten verschieben, da in diesem Fall jedes Mal erneut geprüft werden muss, ob das Ergebnis ausreichend ist und mit dem nächsten Schritt begonnen werden kann. Notwendige Bedingung für die erfolgreiche Durchführung der Treffen ist zudem, dass sich jeder teilnehmende Entwickler ausreichend vorbereitet und sich selbstständig im Vorfeld in die zu prüfenden Programmteile einarbeitet. Nur wenn die Programmierer bereits Notizen angefertigt haben, kann das Meeting zügig, wie es in FDD vorgesehen ist, durchgeführt werden. Sind die Teilnehmer schlecht vorbereitet, muss die Inspection auf einen späteren Zeitpunkt verschoben werden, wenn nicht riskiert werden soll, dass Fehler übersehen werden. Um die effektive Anwendung von Inspections zu gewährleisten, ist also neben einer guten Organisation der Treffen und Team- und Kritikfähigkeit der Teilnehmer vor allem Disziplin auf Seiten der Entwickler gefragt. 3.3 Feature Teams Die in Feature-Driven Development eingesetzten Feature Teams können in Kombination mit den Rolleneinteilungen in Chief Programmer und Class Owner sowie den anderen Methoden wie den Inspections sehr effektiv sein. Die Teams werden je nach Bedarf flexibel zusammengestellt, anstatt die Entwickler in feste Gruppen einzuteilen. Dadurch ist immer der gesamte, von der Entwicklung des aktuellen Features betroffene, Code innerhalb des Teams gehalten, wodurch Wartezeiten auf Entwickler außerhalb entfallen, vgl. [PF02, S.48]. Somit kann das Team in der Entwicklung relativ unabhängig und autonom agieren. Verzögert sich die Entwicklung eines Features, können die anderen Teams in der Regel problemlos an ihren Features weiterarbeiten. Zusätzlich fördert die Einteilung in Feature Teams die nebenläufige Entwicklung innerhalb des Projektes, da mehrere Teams parallel an verschiedenen Features arbeiten können. Dies ist selbst für Features möglich, die Teil einer Funktion desselben Geschäftsbereichs sind, da benötigte Class Owner an der Umsetzung mehrerer Features gleichzeitig beteiligt sein können. Als Leiter und Betreuer führen die erfahrenen Chief Programmer ihr Team und sind für die erfolgreiche Umsetzung der Features verantwortlich, vgl. [PF02, S.47]. 13

14 Ihre Anzahl und damit die Anzahl der gleichzeitig arbeitenden Feature Teams bestimmt letztendlich das Maß der nebenläufigen Entwicklung und damit wiederum, wie zügig das Projekt vorankommt. Sie übernehmen zudem den Großteil an organisatorischen Aufgaben innerhalb des Teams, wie etwa das Anfertigen von Berichten und Dokumenten für das Management und ermöglichen damit den Class Ownern, sich auf die Entwicklung zu konzentrieren. Feature Teams als Struktur sind gerade auch für große Projekte sinnvoll, da die an der Entwicklung eines Features beteiligten Teams, unabhängig vom Umfang des Gesamtprojekts, klein und übersichtlich bleiben, was die Kommunikation und zügige Entwicklung erleichtert. Um die Effizienz der Feature Teams sicherzustellen ist, ähnlich wie bei der Class Ownership, vor allem die Auslastung der Entwickler zu beachten, die das Ausmaß der möglichen nebenläufigen Entwicklung einschränkt. So sollten Class Owner nicht Teil zu vieler Feature Teams auf einmal sein, um eine Überladung zu vermeiden, vgl. [PF02, S.162]. Zusätzlich müssen Features eventuell verschoben werden, wenn ein Class Owner bereits Mitglied mehrerer Teams ist und für die Entwicklung eines weiteren Features benötigt wird. Hier kann es auch zu Konflikten zwischen den Teamleitern kommen, wenn es darum geht, wessen Feature zurückgestellt werden muss, wobei allerdings die Feature List mit ihren Prioritäten Abhilfe schaffen sollte. Ferner muss auch die Auslastung der Chief Programmer beachtet werden, die wie in den Grundlagen dieser Arbeit angesprochen, auch Class Owner sind, damit diese sowohl ihre Entwickler- als auch ihre Teamleiteraufgaben ausführen können, ohne dass es zur Vernachlässigung einer der Tätigkeiten kommt. Ihnen sollten folglich nicht zu viele Klassen zum Besitz zugewiesen werden um sicherzustellen, dass sie genug Zeit für die Entwicklungsleitung der Features haben. Zusätzlich sollten einem Chief Programmer auch nicht zu viele Feature Sets aus verschiedenen Geschäftsbereichen des zu entwickelnden Systems zur Entwicklung übergeben werden, vgl. [PF02, S.151]. Vielmehr sollten die Sets möglichst Teil eines gemeinsamen Bereiches des Systems sein, sodass der entsprechende Chief Programmer erlangtes Wissen über diesen Bereich im Laufe der Entwicklung zum Vorteil einsetzen kann, um als Experte strittige Fragen klären zu können. Hier verhält es sich also ähnlich wie mit den Class Ownern. Die notwendige Balancierung der Auslastungen ist Aufgabe des Development Managers, vgl. [High02, S.277]. Mit der wachsenden Größe eines Feature Teams drohen dessen Vorzüge und die Effizienz anderer Ansätze, wie die der Inspections, verloren zu gehen. Es muss also sichergestellt werden, dass die nötigen Klassen für die Entwicklung eines Features nicht über zu viele verschiedene Entwickler verteilt sind. Da alle derartigen Probleme wohl kaum bereits in der Planungsphase in Prozess 3 aufgedeckt werden können, ist es unter Umständen nötig, die Zuständigkeiten unter den Entwicklern noch nachträglich zu verschieben. 14

15 Vor allem aber muss das Team als solches funktionieren und durch die Disziplin aller Mitglieder getragen werden. Wenn ein Entwickler schlechte Arbeit leistet oder für eine gewisse Zeit ausfällt, wird dadurch die planmäßige Entwicklung des ganzen oder bei der Mitgliedschaft in mehreren Feature Teams oder anderen Abhängigkeiten gleich mehrerer Features gefährdet. Durch die Flexibilität FDDs kann bei sämtlichen längeren Verzögerungen bereits mit der Umsetzung des nächsten Features begonnen werden. Allerdings muss, um die aufgeschobenen Features zu Ende zu bringen, jeweils das alte Feature Team wieder zusammengeführt werden, was voraussetzt, dass diese dann verfügbar und nicht bereits in zu vielen anderen Teams gebunden und ausgelastet sind. Da die Entwickler zudem zwischenzeitlich womöglich mit anderen Aufgaben und Klassen beschäftigt waren, ist, selbst bei Verfügbarkeit zumindest eine kurze Einarbeitung nötig. Hier drohen weitere Verzögerungen, wenn die Nacharbeit an aufgeschobenen Features nicht vernünftig eingeplant wird. 3.4 Prozess 1/Modellierung Von den fünf Prozessen soll der erste hier noch etwas genauer betrachtet werden, da gerade er, wie auch in den folgenden Abschnitten dargestellt wird, für den Erfolg eines Projektes entscheidend ist. Neben dem Objektmodell als offensichtlichem Ergebnis der Modellierung, kann der Prozess auch durch eine Reihe weiterer Vorzüge den weiteren Verlauf eines Projektes positiv beeinflussen. So ist die Zusammenarbeit der Teilnehmer während der Erarbeitung des Modells wichtig, um beispielsweise den Zusammenhalt im Team zu stärken, vgl. [PF02, S.125]. Die Entwickler und Fachexperten lernen zusammenzuarbeiten und ihre Kommunikation aufeinander abzustimmen, was für spätere Prozesse, an denen ebenfalls beide Gruppen beteiligt sind, sehr hilfreich ist, da Umgangsformen, Kommunikationskanäle und dergleichen in der Regel nach Prozess 1 bereits etabliert sind. Während den Diskussionen und der Evaluierung verschiedener Modellentwürfe können zudem Kenntnisse über das zu entwickelnde System unter den Teilnehmern der Modellierungsphase ausgetauscht werden, von denen sie über den Verlauf des Projektes profitieren können. Das Modell dient den Entwicklern zusätzlich als bildlich vorhandene Diskussionsgrundlage, auf die sie sich beziehen können um kritische Fragen, beispielsweise des Entwurfs, zu erörtern und zu klären. Insgesamt fördert Prozess 1 das Verständnis des zu modellierenden Geschäftsbereichs sowie die Kreativität und Innovation der Entwickler, vgl. [CLD99, S.186f]. Außerdem können sich manche Entwickler besser mit einem Projekt identifizieren und sind dadurch motivierter, wenn sie von Anfang an aktiv an der Entstehung beteiligt sind, anstatt lediglich ein bereits von Experten erstelltes Modell umzusetzen, in das sie sich zudem zunächst erst einarbeiten müssen. 15

16 Der erste Prozess eines jeden FDD-Projektes hat außerdem starke Einflüsse auf den Umfang von Refactoring und nötige Änderungen im Verlauf der Entwicklung, worauf in den Abschnitten Class Ownership beziehungsweise Änderungen genauer eingegangen wird. Bei der Modellierung geht es nicht darum alle Details zu erfassen, sondern vielmehr ein Gerüst zu erstellen und bereits Klassen und deren Beziehungen aufzunehmen, vgl. [High02, S.274]. Folglich muss darauf geachtet werden, dass sich das Team während der Modellierungsphase nicht in Details verliert, sondern zügig den Prozess voran treibt, vgl. [PF02, S.115]. Außerdem ist lediglich das Anfertigen von Notizen bezüglich der Entwurfsalternativen oder Begründung eines ausgewählten Modellabschnitts im Prozess vorgesehen, vgl. [PF02, S.64]. Der Mangel an formellen Dokumenten macht es erforderlich, dass die Entwickler diese Notizen ausreichend gut und umfangreich anfertigen. Ist dies nicht der Fall, können sich im späteren Projektverlauf Probleme ergeben, wenn etwa unklar ist, weshalb etwas entsprechend modelliert worden war. Gerade auch bei Änderungen des Modells und Systemtests gegen das modellierte Konzept ist es wichtig, derartige Informationen berücksichtigen zu können, um die bestmögliche Abdeckung der Anforderungen des Kunden zu gewährleisten. Wie auch im Abschnitt Kundenbeteiligung vertieft wird, ist der Erfolg der Modellierung zudem stark von den Fähigkeiten der Fachexperten und ihrer Zusammenarbeit mit den Entwicklern abhängig. Beide Gruppen müssen team- und kritikfähig sein, um effektiv und ergebnisoffen die Modellierung durchzuführen. Auch die Fähigkeiten des Chief Architects sind sowohl im menschlichen als auch im fachlichen Gebiet gefragt. Er muss die Treffen leiten, die Einhaltung guter Umgangsformen durchsetzen und etwaige Konflikte lösen. Seine Entscheidungen haben Auswirkungen auf das gesamte Projekt und können im negativen Fall im späteren Projektverlauf zu komplexen Problemen führen, wenn beispielsweise falsche Design- Entscheidungen getroffen wurden, deren Behebung dann nur mit großem Aufwand noch möglich ist. Es empfiehlt sich also für die Projektleitung die Rolle des Chief Architects mit einem ausreichend erfahrenen und talentierten Modellierer zu besetzen, damit Prozess 1 zügig, vollständig und effektiv abgeschlossen werden und damit die positiven Wirkungen auf die Entwicklung haben kann, wie sie im ersten Teil des Abschnitts beschrieben wurden. 3.5 Kundenbeteiligung Feature-Driven Development sieht, wie auch andere agile Methoden, eine weit größere Kundenbeteiligung vor, als es bei den traditionellen Entwicklungsprozessen der Fall war. Bei letzteren beschränkte sich die Mitwirkung des Auftraggebers meist auf die Festlegung der Systemanforderungen und den finalen Abnahmetest, während der agile Ansatz regelmäßige Mitwirkung oder zumindest Rücksprache mit dem Kunden über den gesamten Verlauf eines Projektes vorsieht. 16

17 Bei FDD findet diese Kundenbeteiligung vor allem in Form der Einbindung von Domain Experts, bei denen es sich aber nicht zwingend um Kunden handeln muss, in den Entwicklungsprozess statt. Vor allem in den Prozessen 1 und 4 unterstützen sie die Entwickler mit Informationen und erarbeiten gemeinsam mit ihnen die Ergebnisse, etwa das Gesamtmodell. Die Domain Experts können aber auch in den meisten anderen Prozessen, vielleicht von Prozess 5 einmal abgesehen, unterstützend mitwirken und bei strittigen Fragen hinzugezogen werden. Diese weit reichende Beteiligung erhöht die Chance für das Projektteam, ein System zu entwickeln, das letztendlich dem Kundenwunsch entspricht. Gerade in der Modellierungsphase zu Beginn eines Projektes erhält das Entwicklungsteam durch die Zusammenarbeit mit den Fachexperten wichtige Kenntnisse über den Geschäftsbereich, für den das System entwickelt werden soll, vgl. [CLD99, S.186]. Auf diesem erlangten Wissen kann über den ganzen Entwicklungszeitraum hinweg aufgebaut werden, wodurch die Entwickler viele Fragen bereits untereinander klären können. Auf der anderen Seite sind die Auftraggeber durch regelmäßige Berichte und Lieferungen neuer Features stets gut über den Fortschritt und Status des Projektes informiert und können entsprechend sinnvolles Feedback über geänderte Prioritäten oder ähnliches geben. Damit aus dieser weit reichenden Einbindung des Kunden kein Nachteil entsteht, muss jedoch gewährleistet sein, dass die Experten stets verfügbar sind, wenn ihre Mitwirkung benötigt wird. Vor allem während der Modellierungsphase ist quasi eine Vollzeitbeteiligung der Domain Experts unerlässlich, soll der Prozess zügig abgeschlossen werden. FDD sieht etwa zwei Wochen Modellierung für sechs Monate Projektlaufzeit vor, vgl. [High02, S.274f]. Zudem ist gleich eine ganze Gruppe von Experten nötig, die sich speziell auf die jeweiligen Geschäftsbereiche vorbereiten und in Gruppen mit den Entwicklern das Modell erarbeiten müssen. Auch in späteren Prozessen ist es, um Verzögerungen zu vermeiden, nötig, dass zumindest ein oder zwei Domain Experts möglichst jederzeit verfügbar und mit den Details des Projektes vertraut sind, um Fragen schnell klären zu können. Offensichtliche Voraussetzung für die erfolgreiche Zusammenarbeit ist, dass die Experten auch tatsächlich über die erforderlichen Kenntnisse verfügen und dieses Wissen auch vermitteln können. Dabei ist es sehr von Vorteil, wenn die Fachexperten auch technisch etwas von der Entwicklung von Software verstehen, um die Kommunikation und Diskussion mit den Entwicklern, gerade in späteren Phasen des Projektes, zu erleichtern. 17

18 Fraglich und damit entscheidend für den Erfolg ist bei FDDs Ansatz, ob ein Auftraggeber dies alles gewährleisten kann. Gerade größere Kundenfirmen, die viele Projekte parallel in Entwicklung haben, können oder wollen unter Umständen nicht für jedes einzelne eine spezialisierte und jederzeit verfügbare Gruppe von Experten unterhalten, wenn diese dadurch für andere Aufgaben ausfällt. Unklar ist auch, ob Feedback zu erfolgten Lieferungen ausreichend schnell an das Projektteam weitergegeben werden kann, wenn die neuen Features erst innerhalb eines großen Unternehmens verteilt und anschließend durch die Mitarbeiter dort benutzt und bewertet werden müssen. Auch hier treten unter Umständen Verzögerungen auf, die die Dynamik eines FDD-Projektes zumindest behindern können. Der Grad zu dem die Kundenbeteiligung effektiv ist und eine zügige Entwicklung erlaubt, ist also stark vom Willen, der Organisation und der Bedeutung des Projektes für den Auftraggeber abhängig. Eine gute, robuste Planung des Projektes selbst ist ebenso wichtig als auch die Kompetenz und Teamfähigkeit der Experten. 3.6 Änderungen Wie bereits in der Anmerkung zu Refactoring angesprochen, versucht FDD möglichst viel auf Anhieb korrekt zu machen. Dies gilt auch für die Umsetzung und Identifizierung von Anforderungen und Features, für die in Prozess 1 der Grundstein gelegt wird, während in Prozess 4 noch Details der Umsetzung geklärt werden, vgl. [PF02, S.234]. Dennoch können während der Entwicklung Änderungen und die Eingliederung neuer Features durch neue Anforderungen oder geänderte Prioritäten seitens des Kunden anfallen. Während noch nicht umgesetzte Features leicht durch geänderte Varianten ersetzt werden können, gilt für alle anderen Fälle zur Kontrolle der Änderungen die so genannte "10% Slippage Rule" [PF02, S.235]. Jene besagt, dass ein Projekt bis zu 10% neuer Features aufnehmen kann, ohne dass Änderungen in der Planung nötig werden. Um einen Überblick zu haben, werden neu hinzugekommene Features auf einer separaten Liste geführt. Übersteigt deren Anzahl die festgelegte Grenze, hat die Projektleitung drei Optionen zur Auswahl, um das Projekt an die neuen Bedingungen anzupassen. Es kann entweder der Umfang des Projektes, durch Verschieben nicht notwendiger Features, verringert oder der Zeitplan durch eine Verlegung des Abschlussdatums auf einen späteren Zeitpunkt geändert werden. Die dritte Möglichkeit besteht in einer Vergrößerung des Projektteams. Vgl. [PF02, S.235ff]. Des Weiteren beschränkt sich die Modellierung des Systems auf den Geschäftsbereich des Kunden und nicht direkt auf dessen Anforderungen an das zu entwickelnde System. Während Änderungen in den Anforderungen wahrscheinlich sind, ist der modellierte Geschäftsbereich deutlich stabiler, was es Entwicklern erleichtert neue Features einzubauen, vgl. [PF02, S.38]. 18

19 Bei geänderten Anforderungen können aufgrund der geringen Größe und Abhängigkeiten gleich viele Features auf einmal von einer Änderung betroffen sein, was es notwendig macht, dass alle identifiziert und entsprechend angepasst werden, um spätere Inkonsistenz und Fehler im System zu vermeiden. Auch die drei Ansätze zur Anpassung des Projektes an neue Anforderungen sind nicht unproblematisch. Der Umfang lässt sich beispielsweise nur so lange problemlos reduzieren, wie unwichtigere Features für die aktuelle Iteration vorhanden sind. Sind bereits alle entbehrlichen Features aussortiert, muss entweder eine andere Option ergriffen werden oder mit dem Kunden müssen neue Prioritäten erarbeitet werden, vgl. [PF02, S.236]. Bei der Verschiebung eines Features zur Entwicklung in einer späteren Iteration muss zusätzlich streng auf die angesprochenen Abhängigkeiten geachtet werden. Eine zeitliche Ausdehnung des Projektes kann ebenso, wie umfangreiche Kürzungen des Umfangs, zu Unzufriedenheit des Kunden führen. Allerdings können regelmäßig erfolgte Fortschrittsberichte und Lieferungen von Features sowie die präzise Abschätzung der zusätzlich benötigten Entwicklungszeit bei den Gesprächen mit dem Kunden hilfreich sein und sorgen unter Umständen für das nötige Vertrauen. Durch eine Vergrößerung des Projektteams, die dritte Option, lässt sich zwar das Ausmaß der nebenläufigen Entwicklung erhöhen, allerdings müssen sich die neu dazu stoßenden Entwickler zunächst einarbeiten, da sie vermutlich weder an Modellierung noch an Planung beteiligt waren. Zudem müssen Strukturen und Kommunikation der Teams neu abgestimmt werden. Hilfreich und diese Nachteile mindernd kann es sein, einen Entwickler aus dem bestehenden Team, der bereits zumindest zu einem gewissen Grad mit dem Projekt vertraut ist, zum Chief Programmer zu ernennen und ihn weitere Programmierer einlernen zu lassen, vgl. [PF02, S.237]. Die Lösungsansätze sind insgesamt betrachtet zwar einfach und logisch, müssen aber wohl überlegt und geplant sein um erfolgreich zu sein. Zusätzliche Voraussetzung für das unproblematische Einfügen von neuen Features ist vor allem, dass die Modellierung und die Ausarbeitung der Feature List gründlich und umfangreich erfolgt sind. Wenn in diesen Phasen eine größere Zahl Features übersehen wird, die dann im Verlauf der Entwicklung noch hinzugefügt werden muss, verstärken sich die Probleme der einzelnen Lösungsansätze und Kürzungen werden umfangreicher und komplizierter, falls sie überhaupt noch durchgeführt werden können. Auch zeitliche Probleme wachsen und lassen sich durch Verstärkungen des Teams nur bedingt effektiv beheben. Aufgrund dieser Problematik ist die erfolgreiche Anwendung von FDD insbesondere für Projekte, deren Anforderungen sich sehr häufig ändern, eher schwierig. 19

20 3.7 Anpassbarkeit/Kombinierbarkeit Feature-Driven Development zeichnet sich durch seine große Flexibilität aus. Der Prozess kann und muss in bestimmten Bereichen sogar an besondere Bedingungen einzelner Projekte angepasst und mit anderen Konzepten und Methoden kombiniert werden. Denn FDD liefert mit Feature Teams, den Rolleneinteilungen und Berichten vor allem Strukturen, Richtlinien und Konzepte für das Management und die Organisation eines Projektes, während Fragen der konkreten Entwicklung und Implementierung weitestgehend offen gelassen werden. Hier werden vielmehr lediglich unterstützende Ansätze, wie beispielsweise die Inspections, geliefert. Für die Entwicklung in Prozess 5 muss also auf andere Methoden zurückgegriffen werden, die das Hauptaugenmerk auf die eigentliche Codierung legen. Diese müssen entsprechend angepasst werden, um mit den FDD-Konzepten in Einklang zu sein. FDD kann auch zur Unterstützung anderer Entwicklungsprozesse eingesetzt werden, um deren Schwächen auszubessern. So kann Feature-Driven Development beispielsweise mit Extreme Programming oder anderen agilen Methoden kombiniert werden, um den Projekten zusätzlich Struktur und Planbarkeit zu geben und gerade große Projekte besser zu kontrollieren, vgl. [Hunt06, S.192]. Weiterhin liefert FDD keine eigenen ausgeprägten Ansätze für das Erschließen und Sammeln der Anforderungen des Kunden an das Projekt, wie es vor der Modellierung in Prozess 1 stattfinden sollte. Auch für das Testen des entwickelten Systems und dessen Komponenten werden, abgesehen von den in Prozess 5 erwähnten Unit Tests, keine Angaben gemacht. Die fünf Prozesse können allerdings in bereits bestehende, etablierte Aktivitäten für Anforderungen und Tests eingefügt werden, um diese Auslassungen zu füllen, vgl. [PF02, S.260]. Hier ist beispielsweise sogar eine Kombination mit traditionellen Entwicklungsprozessen wie dem Rational Unified Process möglich, um dessen Aktivitäten als Rahmen für die Entwicklung zu nutzen, während die Projekte durch FDD flexibler werden und sich leichter anpassen lassen, vgl. [Hunt06, S.205]. Der Einsatz von FDD verringert zudem die Bürokratie in der eigentlichen Entwicklungsphase und erlaubt dadurch ein effektiveres Vorgehen und bessere Qualität des Codes sowie eine Anpassung an kürzere Projektkreisläufe, vgl. [PF02, S.261]. Die in FDD beschriebenen Strukturen und Hierarchien, allen voran die Feature Teams und unterstützende Konzepte wie Class Ownership und Inspections, lassen sich zudem auch ohne größere Probleme oder unverhältnismäßig zusätzlich entstehenden Aufwand auf große Teams anwenden und erlauben damit auch das Bewältigen und Kontrollieren umfangreicher Projekte. 20