Agile Softwareentwicklung

Agile Softwareentwicklung Yelve Yakut 29. Mai 2008 Inhaltsverzeichnis 1 Einleitung 1 2 Problematik 2 3 Vorgehensmodelle 2 3.1 Das Wasserfallmodell................................ 3 3.1.1 Aspekte................................... 3 3.1.2 Vorteile................................... 3 3.1.3 Nachteile.................................. 3 4 Agile Vorgehensmodelle 4 4.1 Das Agile Manifest................................. 5 4.2 Gegenüberstellung................................. 5 4.3 Unterteilung..................................... 6 4.4 Scrum........................................ 7 4.4.1 Rollen.................................... 7 4.4.2 Der Prozess................................. 8 4.4.3 Skalierbarkeit................................ 10 4.4.4 Fazit..................................... 10 4.5 Feature Driven Development........................... 11 4.5.1 Rollen.................................... 11 4.5.2 Der Prozess................................. 12 4.5.3 Skalierbarkeit................................ 16 4.5.4 Visualisierung................................ 16 4.5.5 Aspekt Orientierung............................ 17 4.5.6 Fazit..................................... 17 1 Einleitung Die folgende Ausarbeitung behandelt agile Vorgehensweisen in der Softwareentwicklung. Zuerst wird die Notwendigkeit für eine strukturierte Projektplanung in der Softwareentwicklung gezeigt. Konservative Prozesse und ihre Nachteile werden näher betrachtet um daraus die Notwendigkeit für neue Methoden abzuleiten. Verschiedene Formen agiler Vorgehensweisen werden dargestellt und anhand der Vorgehensweisen Scrum und Feature Driven Development konkretisiert. 1

Bemerkung: Im Folgenden werden die Begriffe Vorgehensweise, Prozess, Prozessmodell und Methode synonym verwendet. In Kapitel 3 wird der Begriff näher erklärt. 2 Problematik Das Projektmanagement mauserte sich seit ihren Anfängen vor ca. 100 Jahren zu einer festen Teildisziplin der Ingenieurswissenschaften. Seit dem Auftreten erster, großer Softwareprojekte versucht man die selben Verfahren auch in der Informatik anzuwenden. Dabei zeigen sich jedoch viele Probleme, denn die Projekte unterscheiden sich grundsätzlich voneinander. Vergleicht man Projekte der klassischen Ingenieursdisziplinen mit denen der Softwareentwicklung stellt sich heraus das letztere Gruppe an einem akuten Mangel an Informationen leidet. Kundenspezifikationen sind unklar. Architekturen sind unklar. So konkretisieren sich viele Informationen erst im Laufe des Projektes. Beispielsweise könnte erst in der Testphase festgestellt werden, dass ein geplanter Algorithmus von seiner Funktionsweise her zwar einwandfrei funktioniert, allerdings kann er trotzdem nicht eingesetzt werden, weil er bei der Verwendung mit mehreren Benutzern zu langsam ist. Probleme dieser Art lassen sich aufgrund der unendlichen Vielfalt von Algorithmen nur bedingt vorhersagen. Zum Vergleich sei der Hausbau beispielhaft aus [CD05] herangezogen. Dem Bauherrn und seinem Team ist die Architektur des Hauses bereits bei Baubeginn schon sehr genau klar. Änderungen an der Architektur stellen eher die Ausnahme das, weil man im Vorfeld durch eine gute Kenntnis der Naturgesetze schon sehr genau weiß, welche Vorhaben realisierbar sind und welche nicht. Ein Architekt weiß bereits im Voraus das sein geplantes Haus mit hoher Wahrscheinlichkeit nicht einstürzen wird. Folgende Statistik, erhoben von QSM veranschaulicht die Problematik. Richten Sie Ihr Augenmerk auf den Punkt der Requirements. Diese änderten sich bei den betrachteten Projekten im Mittel um ein Viertel! Von 210 Projekten im Zeitraum von 1997 bis 1999: Zeitplan: 83 Projekte verspäteten sich um etwa 67%. Kosten: 70 der Projekte verbrauchten 127% mehr Mittel als erwartet. Requirements: Änderung der Anforderungen im Mittel um 22%. Organisation: Bei 98 Projekten waren die ursprünglichen Zahlen nicht mehr aufzufinden. Für eine differenziertere Betrachtung müssen jedoch zuerst konventionelle Vorgehensweisen näher betrachtet werden. 3 Vorgehensmodelle Vorgehensmodelle im Allgemeinen versuchen einen generischen Weg zur Entwicklung von Software zu beschreiben. Sie beantworten die Fragen: Welche Rollen müssen besetzt werden?, Was muss getan werden? In welche Aktivitäten kann man die Prozesse unterteilen? und In Welcher logischen Reihenfolge stehen diese und wie lange dauern sie?. 2

Abbildung 1: Das Wasserfallmodell nach Winston Royce.[Roy70] 3.1 Das Wasserfallmodell Ein typisches Vorgehensmodell ist beispielsweise das in Abbildung 1 dargestellte Wasserfallmodell. Es gehört zu den sogenannten linearen, prozessorientierten Vorgehensweisen. Das Wasserfallmodell beschreibt das Vorgehen aus der Sicht der Planung, es werden also keine Vorschriften zur operationalen Ausführung der Prozessschritte gemacht. Linear meint hier das ein Schritt vollständig abgeschlossen wird bevor der Folgeschritt eingeleitet werden kann. Im Folgenden werden typische Aspekte, Vor- und Nachteile aufgelistet. 3.1.1 Aspekte Ein Schritt wird vollständig abgeschlossen bevor Folgeschritte eingeleitet werden. Ein- und Austrittsbedingungen für die Schritte sind festgelegt. Damit die Ergebnisse eines Teilprozesses von dem darauffolgenden verstanden werden können müssen diese gründlich dokumentiert sein. 3.1.2 Vorteile Wenn die Kundenwünsche völlig klar sind und sich im Laufe des Projektes nicht ändern können Kosten und Zeit eingespart werden. Big Design Up Front meint eine möglichst gründliche Planung. Ein Bug der sehr früh also beispielsweise in der Entwurfsphase erkannt wird wäre um ein vielfaches teuer gewesen wenn man ihn erst beim Testen gemerkt hätte. Da Ein- und Austrittsbedingungen für jeden Schritt festgelegt sind gibt es keine Unklarheiten über Zuständigkeiten. Durch den hohen Anteil an Dokumentation ist ein Großteil der Entscheidungen nachvollziehbar. Neue Teammitglieder können sich leichter einarbeiten da alles gut dokumentiert ist. 3.1.3 Nachteile 1. Sobald sich die Kundenwünsche im laufe eines Projektes ändern, muss die aktuelle Phase unterbrochen werden woraufhin wieder bei der Anforderungsanalyse die geänderten Aspekte betrachtet werden müssen. 3

2. Wenn in einer der frühen Phasen unsauber gearbeitet wird, kann auch von Bug Design Up Front gesprochen werden. Ein Bug der dort übersehen wird kostet automatisch sehr viel Geld und Zeit. Dies geschieht sogar zwangsläufig so, da es extrem schwierig ist das Problem schon in der Anforderungs- und Designphase vollständig zu verstehen. 3. Der Aufwand für die Dokumentation ist deshalb so hoch weil die Ergebnisse eines Teilprozesses von den darauffolgenden Prozessschritten nachvollzogen werden müssen. Dieses Vorgehen wird auch als Throw Over The Wall bezeichnet. Ein großer Batzen Ergebnisse und Dokumentation werden über eine metaphorische Mauer zum nächsten Prozessschritt geworfen. Die Empfänger müssen dann sehen wie sie damit zurechtkommen. 4. Es stellt sich relativ spät bzw. gar nicht heraus wie teuer ein einzelnes Feature ist. Eine realistische Kosten-Nutzen Schätzung ist erst sehr spät im Projekt machbar. Wenn der Kunde im Laufe des Projekts ein Feature als zu teuer empfindet, kann es nur noch schwer und mit hohem Kostenaufwand aus den durchlaufenen Prozessschritten entfernt werden. Des weiteren ist das Geld, das in die bisherigen Prozessschritte investiert wurde, verloren. 5. Erst sehr spät im Prozess ist es möglich dem Kunden eine Alpha-Version der Software vorzuführen. Dies erzeugt Unsicherheit auf beiden Seiten. 6. Jeder der Phasen benötigt ganz spezifische Fähigkeiten. Durch die Linearität der Phasen ist es schwierig die Ressourcen effizient einzuteilen. Entweder müssen die Mitarbeiter alle Phasen gut beherrschen oder die Firma muss mehrere Projekte versetzt laufen lassen. 7. Da die Arbeit nach Tayloristischem Motto aufgespalten wird, lassen sich eine Reihe von Nachteilen daraus ableiten: 8. 1. Die Identifizierung der Mitarbeiter mit dem Produkt sinkt. Dadurch wiederum das Qualitätsbewustsein und die Motivation der Beteiligten. Die haben schlecht entworfen und jetzt muss ich das implementieren. 9. 2. Nur wenige kennen inhaltlich den gesamten Prozess. Die Innovationsfähigkeit für Produkt und Aktivitäten wird eingeschränkt. Ich bin doch nur ein kleines Rädchen. Was soll ich schon ändern können. 4 Agile Vorgehensmodelle Aus all den Problemen und Nachteilen die aus herkömmlichen Vorgehensweisen entstehen, haben sich eine Reihe von agilen Vorgehensweisen entwickelt. Sie zeichnen sich durch folgende Punkte aus: Iterativ: Das Design kann durch Erkenntnisse aus den Implementierungs- und Test- Phasen beeinflusst werden. Kontinuierliche Releases in kurzen Intervallen: Der Kunde kann früh im Projekt Ergebnisse sehen. Und damit auch frühzeitig Fehler in den Anforderungen erkennen. Unkompliziert und leicht erlernbar: Der Prozess ist überschaubar und alle Beteiligten können ihn leicht nachvollziehen. Anpassungsfähig: Auf sich ändernde Bedingungen und Anforderungen kann mit wenig Aufwand eingegangen werden. Regelmäßige Kommunikation nach Innen wie nach Außen: Kommunikation fördert Motivation. Direkte Kommunikation ist ein viel besseres Mittel zur Informationsvermittlung als Dokumentation. Der Aufwand zur Dokumentation kann reduziert werden. 4

4.1 Das Agile Manifest Einige agile Vorgehensweisen wurden publiziert und an großen Softwareprojekten erprobt. Durch deren zunehmende Popularität und Erfolg keimte auch der Wunsch, Gemeinsamkeiten zu finden und diese niederzuschreiben. Am 13. Februar 2001 trafen sich namhafte Verfechter der agilen Bewegung und verfassten das Agile Manifest. [man] Das agile Manifest ist einerseits allgemein genug gefasst um künftigen Vorgehensweisen genug Raum für Innovation zu lassen, bringt aber andererseits genau auf den Punkt was agile Softwareentwicklung von herkömmlichen Vorgehensweisen unterscheidet und worauf es eigentlich bei der Softwareentwicklung ankommt. 1. Individuen und Interaktionen gelten mehr als Prozesse und Tools. Zwar sind wohldefinierte Entwicklungsprozesse und hoch entwickelte Entwicklungswerkzeuge wichtig, wesentlich wichtiger ist jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen. 2. Funktionierende Programme gelten mehr als ausführliche Dokumentation. Gut geschriebene Dokumentation kann zwar hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software. Außerdem ist eine intuitiv verständliche Software hilfreicher als umfangreiche Dokumentation, die sowieso niemand liest. 3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen. Ein Vertrag ist normalerweise die Grundlage für die Zusammenarbeit. Was der Kunde aber wirklich will, kann nur in ständiger Kommunikation mit ihm ermittelt werden. 4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans. Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Das Team muss darauf schnell reagieren können. 4.2 Gegenüberstellung Man kann nun sehen wie die Nachteile des Wasserfallmodells aus Kapitel 3.1.3 durch agile Vorgehensweisen adressiert werden. Zu Punkt 1: Zum einen sind die Vorgehensweisen direkt auf sich ändernde Bedingungen ausgelegt. Zum anderen stellt sich durch regelmäßige Kommunikation mit dem Kunden und regelmäßige Releases, viel früher heraus ob Anforderungen angepasst werden müssen. Durch die frühe Erkennung minimiert sich auch der Aufwand. Zu Punkt 2: Da in kurzen Iterationen gearbeitet wird, ist das Design meist auch auf diese beschränkt. Dadurch ist die Planung überschaubar und weniger fehleranfällig. Selbst planungslastige Vorgehensweisen wie Feature Driven Development(Kapitel 4.5) versuchen nicht alles im Vorfeld bis ins kleinste Detail zu planen. Entsprechend unwahrscheinlicher ist auch das Auftreten dieses Problems. Zu Punkt 3: Die Dokumentation verliert an Bedeutung, da die Throw Over The Wall Methode in agilen Verfahren nicht vorkommt. Intern wird ein hoher Kommunikationsaufwand betrieben damit jeder das Design, die Schnittstellen sowie die Domänenund Systemdetails kennt. Extern wird versucht Software möglichst intuitiv zu gestalten damit Dokumentation nicht mehr so wichtig ist. Zu Punkt 4: Durch häufige Iterationen wird früher klar wie hoch der Aufwand für ein Feature ist. Der Designaufwand beschränkt sich auf die aktuelle Iteration, so wird 5

Abbildung 2: Nebenläufige Prozessmodelle. auch nicht viel Planung in ein Feature investiert das sich bei einer Kosten-Nutzen Schätzung im Laufe des Projektes als unvorteilhaft herausstellt und unerwünscht ist. Vorgehensweisen wie z.b. Feature Driven Development(Kapitel 4.5) sind darauf ausgelegt diese Abschätzung möglichst genau zu betreiben. Dort kann der Kunde sehr leicht nachvollziehen wie lange ein Feature benötigt hat und voraussichtlich benötigen wird. Zu Punkt 5: Wieder zeigen sich die Vorteile der Iterativen Herangehensweise. Einige agile Prozesse erfordern von jeder Iteration das sie eine getestete und funktionsfähige Software als Ausgabe bereitstellt. Der Kunde kann ständig den Verlauf der Entwicklung ausprobieren. Bei den Prozessen wo das nicht explizit erfordert ist können die Iterationen so ausgelegt werden das beispielsweise die Iteration Nr.123 solch eine Vorversion zur Verfügung stellt. Zu Punkt 6: Entweder die gesamte Planung oder zumindest ein Großteil der Planung geschieht innerhalb der Iterationen. Da Iterationen jedoch in der Regel nicht länger als einen Monat dauern und man oft sogar mehrere Iterationen von mehreren Teams gleichzeitig bearbeiten lassen kann, lassen sich Ressourcen sehr viel leichter einteilen. Zu den Punkten 7, 8 und 9: Agile Vorgehensweisen räumen den Menschen einen höheren Stellenwert ein. Das Team steht bei Prozessen wie Scrum (Kapitel 4.5) im Mittelpunkt. Das maximiert die Identifizierung mit dem Produkt und bezieht den Mitarbeiter voll in den Prozess ein. Selbst eher hierarchisch organisierte Vorgehensweisen wie Feature Driven Development machen es sehr deutlich das ausnahmslos jeder Mitarbeiter in der Planungsphase auch den Prozessen beiwohnt, die auf einer höheren Hierarchieebene liegen. So weiß Jeder wie Design und Anforderungen entstanden sind und hat Einfluß auf die Prozessschritte. Des weiteren ist agilen Prozessen inhärent, leicht verständlich zu sein. Dann weiß nicht nur Jeder wie die Ergebnisse entstanden sind, sondern auch warum man ausgerechnet gerade an einem bestimmten Problem arbeitet. 4.3 Unterteilung Im Folgenden werden agile, prozessorientierte, nicht-linearen Modelle betrachtet. Hierfür werden diese weiter in nebenläufige, iterative und inkrementelle Prozesse aufgeteilt. Allgemeine, generische Varianten sind in den Abbildungen 2,3 und 4 dargestellt. 6

Abbildung 3: Iterative Prozessmodelle. Abbildung 4: Inkrementelle Prozessmodelle. 4.4 Scrum Direkt übersetzt bedeutet Scrum, das Gedränge. Das Wort stammt aus dem Rugby und beschreibt die Standardsituation um das Spiel nach einem Regelverstoß zu starten. [scr] Scrum ist ein agiler, iterativer Prozess, bei dem das Scrum-Team im Mittelpunkt steht. Erstmals veröffentlicht wurde der Prozess auf der OOPSLA ([JS97]) von Jeff Sutherland und Ken Schwaber, basierend auf einer Idee von Hirotaka Takeushi & Ikujiro Nonaka([HT86]). 4.4.1 Rollen Im Folgenden sind die Rollen des Scrum Prozesses aufgelistet. Die Rollen sind nicht Disjunkt, das heißt eine Person kann mehrere Rollen innehaben. Scrum Team: Betreibt die eigentliche Wertschöpfung. Design, Implementierung und das Testen der Software. Das Scrum-Team steht im Mittelpunkt der Softwareentwicklung. Es besteht aus nicht mehr als 10 Personen. Scrum Master: Delegierter des Scrum-Teams. Dient als Schnittstelle zur Außenwelt und hat die Aufgabe das Scrum-Team möglichst abzuschirmen. Hat keine Weisungsbefugnis innerhalb des Scrum-Teams. Er ist eher vergleichbar mit einem Schiedsrichter, denn er achtet auf die Einhaltung der Scrum-Regeln. Product Owner: Schnittstelle zwischen Kunde und Projekt. Er achtet darauf das Projekt- Intern alles auch aus Kundensicht seine Richtigkeit hat. Er ist maßgeblich für die Erstellung des Product-Backlog(Siehe Kapitel 4.5 und Abbildung 7) zuständig. Außerdem kümmert er sich um die Abnahme der Sprints, der Zwischenversionen und des Endproduktes. 7

Abbildung 5: Die Scrum-Phasen Pre-Game, Game und Postgame im Überblick. Management: Das Management schirmt das Scrum-Team auf höherer Ebene ab. Beispielsweise wenn sich ein Kunde unkooperativ zeigt. Es gibt grobe Anforderungen und stellt grobe Anforderungen. Es hat bei Unklarheiten das letzte Wort. 4.4.2 Der Prozess Abbildung 5 zeigt die allgemeine Vorgehensweise in Scrum. Die Pre-Game-Phase dient der allgemeinen Projektplanung und des Designs der Grobarchitektur. In der Game-Phase spielt sich die eigentliche Entwicklung in Iterationen, den sogenannten Sprints ab. Ein Sprint wird hierbei so gewählt das es nicht länger als 30 Tage dauert. Im Post-Game schließlich findet die Endabnahme statt, es werden abschließende Tests durchgeführt und die Dokumentation wird soweit nötig erstellt. Im Folgenden werden die einzelnen Prozessschritte und die daran beteiligten Rollen näher beleuchtet. Abbildung 6 soll hierbei der Übersicht dienen. Pre-Game In der Pre-Game-Phase geht es insbesondere um die Planung und das Design der Grobarchitektur. Die Projektplanung dient hierbei der Festlegung der Projekt-Rahmen-Bedingungen. Das Management bestimmt unter Einbeziehung der Beteiligten aus welchen Mitarbeitern die Teams bestehen oder auch welche Technologien und Werkzeuge zu verwenden sind. Sogar Code-Konventionen die eingehalten werden müssen werden während der Projektplanung festgelegt. Daraufhin wird eine erste Version des Product Backlogs, in Zusammenarbeit mit dem Product Owner, erstellt. In dem Stadium enthält das Backlog alle Funktionalitäten die das spätere Produkt erfüllen soll. Das Product Backlog ist praktisch eine Todo-Liste. Sie kann ganze Features enthalten oder auch sehr spezifische Bugfixes und Refactorings. Abbildung 7 zeigt dies beispielhaft. Es ist wichtig anzumerken das ein Product Backlog nicht in Stein 8

Abbildung 6: Eine detaillierte Ansicht des Scrum Prozesses. (1): Pre-Game, (2): Game, (3): Post-Game gemeißelt ist. Anfangs ist es sogar bewusst allgemein gehalten und ändert sich ständig im Laufe des Projekts. Auf der Grundlage des Product Backlog wird das Grobdesign erstellt. Im Design Review Meeting werden daraufhin erstellte Modelle überprüft und verbindlich ausgewählt. Game Im Anschluss auf die Pre-Game-Phase folgen die Iterationen bzw. die Sprints. Die eigentliche Entwicklung spielt sich in dieser Phase ab. Im Sprint Planing Meeting werden die Ziele innerhalb eines Sprint Backlog für den folgenden Sprint festgelegt. Das Ergebnis nennt sich auch Sprint Goal. Innerhalb des Sprints ist das Scrum Team auf sich gestellt und hat (fast) freie Wahl über Methoden und Herangehensweisen um das Sprint Goal zu erreichen. Damit die Entwicklung nicht aus dem Ruder gerät, werden tägliche Stand-Up-Meetings gehalten. Diese Meetings werden morgens veranstaltet und dürfen nicht länger als 15 Minuten dauern. Die Teammitglieder tauschen kurz Informationen aus. Folgende Fragen werden geklärt: Was hast du gestern getan?, Was wirst du heute machen? und Wurdest du durch etwas gehindert?. Wenn vorhanden ist es die Aufgabe des Scrum-Masters diese Störungen zu beseitigen. Bei diesen Meetings haben nur die sogenannten Pigs Rederecht. Pigs sind diejenigen Mitarbeiter die beim aktuellen Sprint aktiv zur Produktion des Endproduktes beitragen. Alle anderen Mitarbeiter sind Chickens und dürfen sich nicht in die Meetings einbringen. Das Sprint Review Meeting findet statt sobald das Sprint Backlog abgearbeitet ist oder maximal 30 Tage vergangen sind. In diesem Meeting wird in Zusammenarbeit mit dem Product Owner entschieden ob es einen weiteren Sprint geben wird. Wenn nicht macht man bei der Post Game Phase weiter.im Sprint gewonnene, neue Erkenntnisse werden in das Product 9

Abbildung 7: Beispiel eines Product Backlogs. Quelle: Mountain Goat Software Größter Scrum mit 600 Mitarbeitern [mgsa]. Backlog eingepflegt. Post-Game Nach einigen Sprints hat die Software den vom Kunden gewünschten zustand erreicht. Diesen gewünschten Zustand bestimmt hierbei der Product Owner. Das Ergebnis wird daraufhin integriert und ausführlich getestet und falls nötig auch dokumentiert. Bugs die in dieser Phase gefunden werden sind in das Product Backlog einzutragen und in einem neuen Sprint abzuarbeiten. 4.4.3 Skalierbarkeit Obwohl die Scrum Teams auf maximal 10 Personen beschränkt sind ist es möglich größere Scrums aufzubauen. Hierbei wird Fraktal vorgegangen. Scrums höherer Ordnung bestehen aus den Scrum Mastern der Scrums niederer Ordnung. Die Scrums höherer Ordnung gehen nach dem gleichen Schema vor, wobei die Stand-Up-Meetings nicht täglich stattfinden und länger als 15 Minuten dauern dürfen. Die Entscheidungen die dort getroffen werden, betreffen immerhin sehr viele Mitarbeiter und sind es wert ausdiskutiert zu werden. Mountain Goat Software hat mit dieser Methode einen Scrum von über 600 Mitarbeitern aufgebaut. Abbildung 8 zeigt dies beispielhaft für 243 Mitarbeiter. 4.4.4 Fazit Kurzum ist Scrum ein Musterbeispiel für agile Softwareentwicklung. Leicht überschaubar, iterativ, kommunikationsintensiv, anpassungsfähig und skalierbar. Den Scrum-Teams werden viele Freiheiten überlassen. Das fördert die Identifikation der Mitarbeiter mit dem Produkt und der Vorgehensweise. Durch die Freiheiten steigen jedoch auch die Anforderungen an die Fähigkeiten der Entwickler. Das Team muss interdisziplinär sein, sollten Projekterfahrung haben und einen hohen Anteil an Selbstständigkeit und Eigenverantwortung zeigen. Da keine Praktiken innerhalb der Sprints vorgegeben werden, können sich die Scrum Teams für Praktiken aus dem Extreme Programming entscheiden [Bec99]. 10

Abbildung 8: Ein Scrum of Scrums mit 243 Mitarbeitern. Quelle: [mgsb] 4.5 Feature Driven Development Feature Driven Development ist ein agiler Prozess, der durch seine geschachtelten Prozessschleifen ein gleichzeitig iterativer und inkrementeller Prozess ist. Jeff De Luca bekam die Aufgabe, ein als verloren geglaubtes Projekt, die Softwareplattform einer Bank in Singapur, zu reengineeren [ffd]. Für dieses Projekt erfand er FDD auf Basis von Ideen von Peter Coad. Für das Projekt standen 50 Entwickler und 15 Monate Zeit zur Verfügung. Es wurde innerhalb des zeitlichen und finanziellen Rahmens abgeschlossen. Später wurde FDD erstmals in [JDL99] veröffentlicht und in [SRP02] weiter verfeinert. 4.5.1 Rollen Im Folgenden ist die verhältnismäßig hierarchische Rollenverteilung des FDD aufgelistet. Jeder ist für einen bestimmten Teil des Projektes verantwortlich. Die Rollen sind nicht Disjunkt, das heißt eine Person kann mehrere Rollen innehaben. Insbesondere ist jeder Chefprogrammierer auch ein Klassenbesitzer. Projektmanager: Verantwortlich für den Zeitplan und die Ressourcenverteilung. Chefarchitekt: Er muss den gesamten Entwurf verantworten. Alle Meetings die das Gesamtmodell angehen stehen unter seiner Schirmherrschaft. Entwicklungsmanager: Plant gemeinsam mit dem Projektmanager die Ressourcenverteilung. Außerdem Organisiert er die tägliche Jobs der Programmierer. Chefprogrammierer: Erfahrener Programmierer. Fungiert als Teamleiter für die ihm zugeordneten Klassenbesitzer/Programmierer. Ist zuständig für Analyse, Entwurf und Implementierung von Features. Zu seinen Aufgaben gehört auch die regelmäßige Berichterstattung. 11

Abbildung 9: Die 5 Phasen des FDD im Überblick. Klassenbesitzer: Jeder Klasse ist genau ein Programmierer zugeordnet. Dieser ist dann der Klassenbesitzer. Nur er hat die Befugnis seine Klassen zu ändern(code Ownership). Da jeder Klasse ein Programmierer fest zugeordnet ist, wird es leichter für das Management die Leistungen der Mitarbeiter einzuschätzen und zu beurteilen. Domänenexperte: Der Domänenexperte ist der Kunde bzw. der Benutzer des Systems und kennt die Anforderungen. Er wird tief in den Entwicklungsprozess integriert. Berät in allen Fragen die das Gesamtmodell oder die Problemdomäne betreffen. Zusätzlich existieren in FDD folgende, unterstützende Rollen. Release Manager: Analysiert die Berichte der Chefprogrammierer und leitet daraus den Projektfortschritt ab. Programmiersprachen-Guru: Ist Experte für eine Programmiersprache und berät bei entsprechenden Fragen. Build Engineer: Betreibt Build- und Releasemanagement. Toolsmith: Entwickelt kleine Tools, die die tägliche Arbeit der Projektbeteiligten vereinfachen. Systemadministrator: Stellt die benötigte Infrastruktur bereit. Installiert die für das Projekt benötigte Hard- und Software. Tester: Prüft das System auf Korrektheit. Deployer: Konvertieren beim Reengineering-Prozess bereits existierende, alte Dateien in ein neues Format. Scribe: Schreibt online und gedruckte Benutzerhandbücher. 4.5.2 Der Prozess Abbildung 9 zeigt eine grobe Betrachtung von FDD. Zuerst wird anhand der Spezifikationen und in Zusammenarbeit mit den Domänenexperten die Problemdomäne modelliert(1). Dann erzeugt man eine Feature-Liste(2). Plant daraufhin die Implementierung von jedem Feature(3). In den folgenden Iterationen plant man zuerst die Features der aktuelle Iteration(4) und implementiert diese dann(5). Im Folgenden werden die einzelnen Prozessschritte und die daran beteiligten Rollen näher beleuchtet. Abbildung 10 soll hierbei der Übersicht dienen. Ein Merkmal von FDD ist das alle 12

Programmierer auch in den ersten 3 Planungsphasen an den Meetings teilhaben sollen. Da es nicht praktikabel ist mit allen gleichzeitig Meetings zu veranstalten, wird das Personal das weniger wichtig für das entsprechende Meeting ist, mittels Rotation eingeladen. Eine andere Besonderheit an FDD ist das jedes der fünf Prozessschritte jeweils Ein- und Ausgangskriterien hat und Möglichkeiten zur Überprüfung der Ergebnisse bietet. (1) Gesamtmodell In der ersten Phase geht es insbesondere um die Planung und das Design der Grobarchitektur in Form eines Domänenmodells. Unter Schirmherrschaft des Chefarchitekten wird in Zusammenarbeit mit den Domänenexperten das Gesamtmodell erstellt. Das Gesamtmodell besteht hierbei aus einer Reihe von Modellen die die Problemdomäne veranschaulichen sollen. Das Modell wird dann bei bedarf in Teilbereiche unterteilt und weiteren Teams zugeordnet die daraufhin parallel an detaillierteren Teilmodellen arbeiten. Eingangskriterien umreißen kann. Hierbei reicht es wenn der Kunde die Anforderungen an das System Überprüfung Da in dieser Phase die Domänenexperten sehr eng mit einbezogen werden und die Ergebnisse dem Team Vorgestellt werden ist keine weitere Überprüfung notwendig. Ausgangskriterien Es existiert das Gesamtmodell. (2) Feature-Liste Anhand des Gesamtmodells erstellt das Feature-List-Team eine priorisierte Feature-Liste. Beispielhaft ist eine Feature-Liste in Abbildung 11 zu sehen. Ein Feature besteht immer aus einer Aktion das auf einem Objekt ausgeführt wird und ein Ergebnis produziert. Es sind Entitäten die für den Kunden einen konkreten Wert darstellen. Weiterhin können Features in Featuresets gruppiert werden und weiter in Hauptfeaturesets auf der obersten Ebene zusammengefasst werden. Im Beispiel wäre Studienangelegenheiten ein Hauptfeatureset und Studentenverwaltung ein Featureset. Eine weitere Bedingung an die Features ist, das diese in maximal 2 Wochen implementierbar und testbar sein müssen. Ist das mal nicht der Fall werden entsprechende Features in einer weiteren Iteration in Teilfeatures aufgespalten. Außerdem ist darauf zu achten das im Feature-List-Team auch Domänenexperten sind um die Korrektheit der Ergebnisse zu gewährleisten. Phase 1 wurde erfolgreich abgeschlossen. Es existiert also ein Gesamt- Eingangskriterien modell. Überprüfung Wie in Phase 1 geschieht die Überprüfung automatisch da die Domänenexperten auch hier eng mit in die Planung einbezogen werden. Ausgangskriterien Eine priorisierte Feature-Liste mit einer Gliederung in Featuresets und Hauptfeaturesets existiert. 13

Abbildung 10: Eine detaillierte Ansicht von FDD. (1): Gesamtmodell (2): Feature-Liste (3): Planung je Feature (4): Entwurf je Feature (5): Konstruktion je Feature. 14

<Aktion> <Ergebnis> <Objekt> Studienangelegenheiten Studentenverwaltung Student hinzufügen Student anhand Filtermaske suchen LV-Verwaltung LV löschen Interne Angelegenheiten Mitarbeiterverwaltung Sekretärin hinzufügen Administrator löschen Datenbankadministration Backup der Datenbank in einer Datei erstellen Abbildung 11: Beispiel für eine nicht priorisierte Feature Liste. (3) Planung je Feature Der Projektmanager muss nun in Zusammenarbeit mit dem Entwicklungsmanager und den Chefprogrammierern den Zeitaufwand, die Abhängigkeiten und die Reihenfolge für die einzelnen Features einschätzen. Jedem Chefprogrammierer wird daraufhin ein Teil der Geschäftsdomäne zugeordnet. Entwicklungsmanager und Chefprogrammierer weisen den Programmierern die Klassen zu. Eingangskriterien Einteilung. Es existiert eine priorisierte Feature-Liste mit grober, domänenspezifischer Überprüfung Wie in den vorherigen zwei Phasen geschieht alles in Teamarbeit. Eine Überprüfung findet dadurch automatisch statt. Ausgangskriterien Die Planungs-Teams haben einen Projektplan erstellt die vom Entwicklungsmanager und dem Chefarchitekten abgesegnet werden müssen. Der Projektplan enthält Fertigstellungsdaten für alle Features, Featuresets und Hauptfeaturesets. Jeder Geschäftsdomäne ist ein Chefprogrammierer zugeordnet und jeder Klasse ein Programmierer. (4) Entwurf je Feature Die eigentliche Entwicklung spielt sich in dieser und der nächsten Phase ab. Die Chefprogrammierer haben die Aufgabe, gemäß dem Projektplan, ein Feature umzusetzen. Sie bilden hierfür mit den betroffenen Klassenbesitzern, Entwurfs-Teams. Dabei wird das Gesamtmodell weiter verfeinert und Sequenzdiagramme werden erstellt. Der Chefprogrammierer ist hierbei für die Qualität und die Stimmigkeit mit dem Gesamtmodell verantwortlich. Um das sicherzustellen, werden die Ergebnisse in einer Designinspektion vorgestellt. Aus dem Gesamtmodell können jetzt bereits Objekt-Stubs automatisch generiert werden. Klassen müssen in diesem Schritt von den Klassenbesitzern dokumentiert werden. Bei Unklarheiten können hier wieder die Domänenexperten hinzugezogen werden. 15

Eingangskriterien Ein detaillierter Projektplan existiert. Die Chefprogrammierer sind Geschäfsdomänen zugeordnet. Überprüfung Der Chefprogrammierer kann in der Designinspektion die Ergebnisse sehr detailliert überprüfen. Bei Unklarheiten können die Domänenexperten zu rate gezogen werden. Ausgangskriterien Die Chefprogrammierer haben die Ergebnisse abgesegnet. (5) Konstruktion je Feature In dieser Phase geschieht die eigentliche Implementierung. In der Planung wurde die Implementierung der Features bereits auf maximal 2 Wochen veranschlagt, so kann diese Phase auch nicht länger dauern. Die entwickelten Objekt-Stubs werden von den Klassenbesitzern ausprogrammiert. Zu den Aufgaben der Klassenbesitzer gehören die Unit-Tests für ihre Klassen. Dem Chefprogrammierer wiederum obliegt die Aufgabe das Zusammenspiel der Klassen zu testen. Nach erfolgreichem Durchlauf der Tests wird der Quelltext der Klassen einer Inspektion durch den Chefprogrammierer unterzogen. Fehler müssen hierbei sofort behoben werden. Erst wenn auch dies erfolgreich verlief, kann der Quellcode im Versionsmanagement eingecheckt werden. Das Ergebnis ist dann eine lauffähige Version. Eingangskriterien Kommentierte Objekt-Stubs. Detailierte Sequenzdiagramme. Überprüfung Die Überprüfung wird in dieser Phase sehr intensiv betrieben. Unit-Tests, System-Tests und sogar direkte Quellcodeinspektion sollen die Qualität des Produktes sichern. Ausgangskriterien Es existiert eine lauffähige Version die keine bekannten Bugs hat. 4.5.3 Skalierbarkeit Nach [SRP02] kann FDD auf beliebig große Projekte skaliert werden. Es ist sogar dafür ausgelegt. Jeff De Luca erfand Feature Driven Development für ein Projekt mit 50 Entwicklern. 4.5.4 Visualisierung Bei Feature Driven Development steht der Kunden und die Features die für ihn wertvoll sind im Mittelpunkt. Damit man sich möglichst gut versteht wird während der Planungsphase das Gesamtmodell zusammen mit den Domänenexperten, also dem Kunden, erstellt. So soll der Kunde aber auch während der Entwicklung den Überblick behalten. Hier sind Parking- Lot-Charts das Mittel der Wahl. Abbildung 12 zeigt eine mögliche Form der Präsentation. Farben geben darüber Auskunft, ob mit einem Feature begonnen wurde, ob es erledigt ist, oder ob es im Zeitplan hinterherhinkt. Die Zahl in den Klammern repräsentiert die Anzahl der zu implementierenden Features für das entsprechende Featureset. Die Buchstaben über den Kästen entsprechen den Namenskürzeln der zuständigen Chefprogrammierer. Bei den Fertigstellungsterminen wurde bewusst auf die Tagesangabe verzichtet, da eine Planung auf den Tag genau als unrealistisch angesehen wird. 16

Abbildung 12: Beispiel für einen Parking-Lot-Chart. 4.5.5 Aspekt Orientierung [JP04] beschreibt eine Möglichkeit FDD um die Aspekt Orientierung zu erweitern. Wie bereits in [TOHJ99] erkannt, ist es problematisch, Concerns in einem Formalismus zu zerlegen, in dem eine andere als die gewünschte Dekomposition dominant ist. Dieses Problem nett man auch tyranny of the dominant decomposition. Auf FDD konkretisiert bedeutet das: Man modelliert in Objekten möchte aber in Wirklichkeit mit Features arbeiten. Die dominante Dekomposition ist in diesem Fall die Objektorientierung. So lange man also mit Objekten arbeitet kann man dies effizient tun. Geht man jedoch von Features aus wird dieses Vorhaben allein dadurch schwierig das ein Feature nicht immer eins zu eins als Objekt implementiert werden kann. Ein Beispiel für solch ein problematisches Feature, ein sogenanntes cross cutting concern, ist das Logging. Man betrachte folgendes Feature: Operationen vom Typ X,Y,Z in eine Log-Datei schreiben. Dieses Feature ist schwierig zu implementieren da viele Klassen gelogt werden müssen. Man müsste also in allen Klassenmethoden das Logging einpflegen. Klassen die eigentlich ganz andere Features repräsentieren. Organisatorisch erschwert sich die Aufgabe weiter wenn man das Class-Ownership Problem berücksichtigt. So müsste der Chefprogrammierer für das Logging-Feature einen großen Teil der Programmierer heranziehen. Durch Aspekt Orientierte Programmierung lassen sich solche Probleme besser handhaben. Nach [JP04] kann FDD, mit nur leichten Modifikationen, durch AOP ergänzt werden. Beispielsweise durch Verwendung von Aspekt Orientierter Klassenmodellierung und durch eine Technik namens boundary condition exploration die eine Zwei-Ebenen-Aspekt-Architektur propagiert. Das Hauptproblem ist das Zusammenspiel der Features, so muss untersucht werden wie Features bzw. Aspekte interagieren und jeweils auf solche Weise gespalten werden das sich ein Teil der Implementierung mit der eigentlichen Problemdomäne beschäftigt und ein anderer Teil das korrekte Zusammenspiel zwischen den Features sicherstellt. 4.5.6 Fazit Der Kunde steht deutlich im Mittelpunkt von FDD. Der gesamten Prozess kann von ihm nachvollzogen werden. Da es in der Versionsverwaltung nur funktionsfähige Versionen gibt, können Ergebnisse schon sehr früh und im laufe des gesamten Projektes ausprobiert werden. 17

Weiterhin wird der Kunde in der gesamten Planungsphase stark mit eingebunden was noch weiter seine Identifikation mit dem Projekt steigert. Dank früher und intensiver Planung kann in FDD stark Modell-Orientiert gearbeitet werden. So können einem einige Arbeiten von Tools abgenommen werden. Dank der hierarchischen Struktur müssen nicht alle Programmierer auch Experten sein. Aufgrund dem hohen Maß an Kontrolle können Fehler frühzeitig erkannt und beseitigt werden. Daraus folgert sich aber das entscheidende Positionen wie der Chefarchitekt und Chefprogrammierer von Experten besetzt werden müssen, denn diese haben schließlich das Machtwort wenn es um wichtige Entscheidungen geht. Problematisch sind cross cutting concerns. Aufgrund der Code-Ownership müssen die Features in Klassen unterteilt werden, was bei quer schneidenden Features jedoch zu Problemen wie beispielsweise Cluttering führen kann. Eine Abhilfe kann hierbei jedoch die in Kapitel 4.5.5 beschriebene Aspekt Orientierte Programmierung schaffen. Ein Nachteil ist weiterhin, das Extreme Programming nicht vollständig eingesetzt werden kann. Aufgrund der Code Ownership kann kein Pairprogramming eingesetzt werden. Refactoring ist aus dem selben Grund auch nur Lokal möglich. Weiterhin wiederspricht das Konzept der Class/Code Ownership dem in XP angepriesenen Konzept der kollektiven Code- Ownership ([Bec99]). Literatur [Bec99] Kent Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999. [CD05] Timo Klimmer Carsten Dogs. Agile Software-Entwicklung kompakt. mitp, 2005. [ffd] Biography of jeff de luca. Website. http://www.nebulon.com/pr/bio.html. [HT86] Ikujiro Nonaka Hirotaka Takeushi. The new new product development game. Harvard Business Review, 1986. [JDL99] Eric Lefebvre Jeff De Luca, Peter Coad. Java Modeling in Color With UML: Enterprise Components and Process. Prentice Hall International, 1999. [JP04] [JS97] L. Blair J. Pang. Refining feature driven development - a methodology for early aspects. Technical report, Lancaster University, Bailrigg, 2004. Ken Schwaber Jeff Sutherland. Scrum development process. In OOPSLA Business Object Design and Implementation Workshop. Springer, 1997. [man] Manifesto for agile software development. Website. http://agilemanifesto. org/. [mgsa] Product backlog definition. Website. http://www.mountaingoatsoftware.com/ product_backlog/. [mgsb] Scrum of scrums. Website. http://www.mountaingoatsoftware.com/scrum_ team. 18

[Roy70] [scr] [SRP02] Dr. Winston W. Royce. Managing the development of large software systems. In IEEE WESCON, pages 328 338. TRW, 1970. Product backlog definition. Website. http://en.wikipedia.org/wiki/scrum_ %28rugby%29. John M. Felsing Stephen R. Palmer. A Practical Guide to Feature-Driven Development. Prentice Hall, 2002. [TOHJ99] Peri L. Tarr, Harold Ossher, William H. Harrison, and Stanley M. Sutton Jr. N degrees of separation: Multi-dimensional separation of concerns. In International Conference on Software Engineering, pages 107 119, 1999. 19