Agile Softwareentwicklung mit Feature-Driven Development

Transkript

1 Agile Softwareentwicklung mit Feature-Driven Development Fabian Chanton und Sven Schumacher Berner Fachhochschule Technik und Informatik CH-2501 Biel, Schweiz Zusammenfassung: In der Arbeit Agile Softwareentwicklung mit Scrum wurden die Vorteile der Agilen Softwareentwicklung erläutert und der Prozess Scrum vorgestellt. In der vorliegenden Arbeit wurde nun ein weiterer agiler Prozess vorgestellt: Feature-Driven Development (kurz FDD). Feature-Driven Development ist ein relativ strenger Prozess, der eine genaue Vorgehensweise in Form von Rollen und Prozessen definiert. Dadurch lässt sich FDD gut in bestehende, traditionelle Strukturen integrieren. Das wiederum erleichtert den Umstieg von einem traditionellen Prozess auf FDD erheblich. Aus diesem Grund ist FDD sehr gut als Einstieg in die Welt der agilen Prozesse geeignet. FDD legt grossen Wert darauf, dass der aktuelle Fortschritt des Projekts jederzeit bestimmbar ist. Dazu definiert es eine Reihe von raffinierten, exakten Praktiken, welche einfach angewendet werden können. Durch seinen Umfang ist FDD nur bedingt für kleine Teams und Projekte geeignet, es kann aber selbst für enorm grosse Projekte angewendet werden. 1. Einleitung In den letzten Jahren zeigte der Trend in der Softwareentwicklung immer mehr in die Richtung von agilen Entwicklungsmethoden. Es existiert eine Vielzahl von verschiedenen agilen Prozessen, die alle ihre Vor- und Nachteile haben. Oftmals ist der Umstieg von einem traditionellen auf einen agilen Prozess mit gravierenden Veränderungen im gesamten Unternehmen verbunden. Dies hält einige Projektverantwortliche davon ab, auf agile Prozesse umzusteigen. Der agile Prozess Feature-Driven Development (FDD), vorgeschlagen von Peter Coad, Eric Lefebvre und Jeff de Luca, eignet sich sehr gut für solch einen Umstieg, da er sich hervorragend in bestehende, traditionelle Unternehmensstrukturen integrieren lässt. Das Ziel dieser Arbeit ist es, FDD näher zu erklären. Es sollte dem Leser am Ende möglich sein, zu Entscheiden, ob sich der Einsatz von FDD für seine Projekte lohnt.

2 2 Agile Softwareentwicklung mit FDD 2. Agile Softwareentwicklung Um FDD verstehen zu können, muss man zunächst einmal verstehen, wie agile Prozesse funktionieren. Den Lesern, welche noch nicht mit agilen Prozessen vertraut sind, wird empfohlen Kapitel 2 der Arbeit Agile Softwareentwicklung mit Scrum [2] zu lesen. Dieses Kapitel führt in den Begriff der agilen Softwareentwicklung ein und definiert diesen näher. 3. Feature-Driven Development 3.1. Vorbemerkungen In diesem Kapitel soll FDD näher beschrieben und erklärt werden, so dass der Leser am Ende des Kapitels beurteilen kann, ob sich der Einsatz von FDD in seinem konkreten Fall lohnt. Dazu werden zunächst die Rollen erläutert, welche in FDD definiert werden. Anschliessend folgt eine Beschreibung der Best Practices, die von FDD empfohlen werden. Zum Schluss wird auf die verschiedenen Prozesse von FDD eingegangen, sowie dessen Möglichkeiten zur Messung des erzielten Fortschritts Rollen Vorbemerkungen Dieses Kapitel behandelt die verschiedenen Rollen, die von FDD definiert werden. Diese Rollen lassen sich grob in Schlüsselrollen, Nebenrollen (oder Unterstützungsrollen) und zusätzliche Rollen einteilen. Im Folgenden werden die Charakteristiken der einzelnen Rollen näher beleuchtet, wobei der Schwerpunkt bei den Schlüsselrollen liegt. Diese sind die wichtigsten Rollen für ein Projekt und beeinflussen das fertige Produkt (die Software) in massgebender Weise. Anschliessend werden noch die Nebenrollen beschrieben, welche eher unterstützend am Projekt teilnehmen. Schlussendlich werden noch kurz die zusätzlichen Rollen erwähnt, welche meist nicht direkt im Team integriert sind Schlüsselrollen Project Manager Der Project Manager ist der administrative Verantwortliche für das Projekt. Er sorgt dafür, dass alle benötigten Ressourcen vorhanden sind. Sein oberstes Ziel ist es, dem Team eine möglichst produktive Umgebung zu schaffen. Um dies zu erreichen,

3 Agile Softwareentwicklung mit FDD 3 organisiert er nicht nur die Ressourcen, sondern er schirmt das Team auch gegen Störungen von aussen ab. Der Project Manager muss die verschiedensten Ressourcen organisieren und verwalten können. Die Palette an Ressourcen, für die der Project Manager zu sorgen hat, reicht von technischer Ausrüstung wie Flipcharts, Laptops oder Beamer, über verfügbare Räumlichkeiten für Sitzungen, bis hin zu genügend qualifizierten Mitarbeitern. Da der Project Manager für die Ressourcen verantwortlich ist, fällt es auch in seinen Aufgabenbereich das Budget zu verwalten. Eine weitere Aufgabe des Project Managers besteht darin, den aktuellen Fortschritt des Projektes zu überwachen. Zum einen ermöglicht dies eine effiziente Verwaltung von Ressourcen und Budget, zum anderen sollte der Project Manager in regelmässigen Abständen die Auftraggeber über den aktuellen Status des Projektes aufklären. Die Rolle des Project Managers sollte von einem sehr erfahrenen und flexiblen Mitarbeiter eingenommen werden, der über ausgezeichnete organisatorische Fähigkeiten verfügt. Zusätzlich sollte der Project Manager ein hervorragender Teamleiter sein, der es versteht, ein Team zu motivieren. Chief Architect Der Chief Architect ist der Verantwortliche für das allgemeine Design der Software. Obwohl der Chief Architect in designspezifischen Fragen immer das letzte Wort hat, hat er nicht die Aufgabe, das gesamte System alleine zu entwerfen. Vielmehr unterstützt er die anderen Entwickler während gemeinsamer Designsitzungen. Man muss sich den Chief Architect also nicht als einen Komponisten vorstellen, der alleine ein Meisterwerk komponiert. Es sollte jedoch klar sein, dass diese Rolle massgeblichen Einfluss auf das finale Design nimmt. Des Weiteren hilft der Chief Architect Konflikte und Unklarheiten aufzulösen, welche die Chief Programmer nicht selber beseitigen können. Wie bereits erwähnt, hat der Chief Architect bei designrelevanten Konflikten das letzte Wort. Dadurch wird unter anderem verhindert, dass die untereinander gleichgestellten Chief Programmer sich in ewigen Diskussionen und Debatten verlieren, sollten sie nicht in der Lage sein, einen Kompromiss zu finden. In solchen festgefahrenen Situationen ermöglicht ein Machtwort des Chief Architects das produktive Weiterarbeiten. Natürlich sollte der Chief Architect versuchen, seine Autorität so selten wie möglich auf diese Weise zu verwenden, da dies in der Regel dem Klima im Team schadet. Ähnlich dem Project Manager, der sämtliche finanziellen und ressourcenbedingten Probleme aus der Welt zu schaffen versucht, ist das Ziel des Chief Architects, die Beseitigung aller technischen Probleme. Dazu unterstützt er die Entwickler in ihren Design-Tätigkeiten und behält stets das generelle Design des Systems im Auge. Der Chief Architect muss über ausgezeichnete technische Fähigkeiten verfügen und vor allem ein exzellenter Modellierer sein. Bei der Schlichtung von Konflikten zwischen den Chief Programmern ist sicherlich ein gewisses diplomatisches Geschick gefragt, sowie einige Erfahrung im Leiten von Teams.

4 4 Agile Softwareentwicklung mit FDD Development Manager Der Development Manager ist für die tägliche Verwaltung der Ressourcen während der Entwicklung verantwortlich. Seine Aufgabe ist es, die Ressourcen so unter den Teams zu verteilen, dass die Entwicklung möglichst produktiv fortgesetzt werden kann. Das Vermeiden von Situationen, in denen ein Weiterkommen, aufgrund von Abhängigkeiten zwischen Ressourcen und Features, nicht mehr möglich ist (ein sogenannter Deadlock), ist eine der Hauptaufgaben des Development Managers. Dazu ist es unter anderem nötig, Ressourcenkonflikte zwischen den Chief Programmern zu lösen, wo sich diese nicht einigen können. Da der Development Manager über die täglichen Ressourcenbedürfnisse der Teams bescheid wissen muss, sollte er immer ein Bild vom aktuellen Fortschritt des Projekts haben und ausserdem die zukünftige Planung des Projekts kennen. Dadurch kann der Development Manager weitsichtig die Ressourcenverteilung planen und so Engpässen frühzeitig vorbeugen. Bei Bedarf kann der Development Manager beim Project Manager zusätzliche Ressourcen anfordern. Der Development Manager muss über gute technische Fähigkeiten verfügen und sollte ein guter Teamleiter sein. Chief Programmer Die Chief Programmer sind erfahrene Programmierer, welche schon mehrere Softwareprojekte von Anfang bis Ende durchgeführt haben. Sie sind in die ersten drei Phasen von FDD involviert, in denen es darum geht, die Anforderungen an die Software zu analysieren und das grobe Design (die Architektur) der Software zu ermitteln. Den wichtigsten Teil ihrer Arbeit leisten sie jedoch während den letzten zwei Phasen von FDD. Während diesen Design- und Implementierungsphasen stellen sie die Feature Teams zusammen und leiten diese dann. Die Feature Teams setzen sich aus den Class Ownern derjenigen Klassen zusammen, die für das jeweilige Feature verändert werden müssen. Dies stellt den Chief Programmer vor einige Probleme. Einerseits muss er auf die Abhängigkeiten zwischen den Features achten, da manche Gruppen von Features in einer gewissen Reihenfolge entwickelt werden müssen. Andererseits muss der Chief Programmer die Verfügbarkeit der jeweiligen Class Owner beachten. Sind die Class Owner schon in anderen Feature Teams beschäftigt, muss der Chief Programmer die Entwicklung dieses Features nach hinten verschieben und ein anderes Feature wählen. Neben den Planungs- und Führungsaufgaben arbeiten die Chief Programmer auch als Entwickler. So ist jeder Chief Programmer auch gleichzeitig ein Class Owner und entwickelt aktiv am Projekt mit. Dadurch bleiben die Chief Programmer in Berührung mit den alltäglichen Problemen der Softwareentwicklung. Zudem schätzen es die meisten Chief Programmer, wenn sie aktiv am Entwicklungsprozess teilnehmen können. Die Chief Programmer müssen über ausgezeichnete technische Fähigkeiten verfügen und sollten von den übrigen Entwicklern sowie von der Verwaltung respektiert werden. Da sie zu Beginn jeder Iteration ein neues Feature Team zusammenstellen

5 Agile Softwareentwicklung mit FDD 5 müssen, welches sie später auch leiten, sind natürlich auch organisatorische Fähigkeiten sowie Kompetenzen im Leiten von kleinen Gruppen gefragt. Class Owner Die Class Owner sind die eigentlichen Entwickler der Software. Ihre Aufgabe ist es, unter der Leitung eines Chief Programmer, die Features zu designen, codieren, testen und dokumentieren. Der Name Class Owner (englisch für Klassen-Besitzer) rührt daher, dass jeder Entwickler einige Klassen besitzt, welche nur er verändern darf. Das bedeutet also, dass jeder Entwickler für einige Klassen verantwortlich ist und dass jede Klasse nur von einem Entwickler verändert werden darf. Diese Praxis wird im Kapitel über Best Practices näher beschrieben. Der Class Owner sollte selbstverständlich ein fähiger Softwareentwickler sein. Oftmals steigen erfahrene Class Owner mit guten sozialen Kompetenzen zum Chief Programmer auf. Domain Expert Domain Experts sind Spezialisten in der Domäne, auf die sich das System bezieht. Sie kennen die Anforderungen, die das System erfüllen muss, sowie die spezifischen Eigenheiten der Domäne. Bei einem medizinischen System könnten zum Beispiel Ärzte Domain Experts sein. Als Domain Experts kommen allgemein Benutzer, Auftraggeber, externe Spezialisten oder dergleichen in Frage. Oftmals handelt es sich bei der Gruppe der Domain Experts um eine Mischung aus verschiedenen Personen (z.b. einige Benutzer des neuen Systems und die Auftraggeber). Die Entwickler können sich auf das Wissen und die Erfahrung der Domain Experts in ihrem Spezialgebiet verlassen und darauf zurückgreifen, falls Unklarheiten entstehen. Manchmal bedarf es deshalb einer gewissen Geduld gegenüber den Entwicklern, da teilweise Zusammenhänge und Sachverhalte mehrmals erklärt werden müssen. Ein Domain Expert muss in der Lage sein, einem Entwickler die Domäne, oder einzelne Facetten davon, in beliebigem Detailgrad zu erklären. Deshalb sind gute Kommunikationsfähigkeiten und ein fundiertes Fachwissen die wichtigsten Eigenschaften, die ein Domain Expert mitbringen muss. Zudem sollte der Domain Expert motiviert sein, an dem Projekt mitzuarbeiten und das bestmögliche Endresultat zu erzeugen Nebenrollen Release Manager Der Release Manager ist dafür verantwortlich sicherzustellen, dass die Chief Programmer den aktuellen Fortschritt regelmässig melden. Zudem ist er darum bemüht, dass alle Beteiligten den Fortschritt des gesamten Projekts im Auge behalten können. Zu diesem Zweck verteilt er Berichte und Diagramme.

6 6 Agile Softwareentwicklung mit FDD Diese Rolle kann in kleineren Projekten auch von einem Mitarbeiter übernommen werden, der dem Project Manager allgemein als Assistent zur Verfügung steht. Der Release Manager muss gründlich und geplant arbeiten können, um seine Aufgabe zu erfüllen. Language Lawyer Der Language Lawyer (manchmal auch Language Guru genannt) ist ein Experte für eine gewisse Programmiersprache oder eine gewisse Technologie. Er hat grosse Erfahrung in der Anwendung dieser Sprache und kennt ihre Eigenheiten und Finessen. Die Aufgabe des Language Lawyers ist es, die Entwickler beim Umgang mit dieser Sprache zu unterstützen und ihnen den Einstieg darin so leicht wie möglich zu machen. Gleichzeitig sollte ein Wissenstransfer stattfinden, so dass die Entwickler selbst immer mehr über die Sprache in Erfahrung bringen und bald ein problemloses Arbeiten damit möglich ist. Diese Rolle ist vor allem in Projekten nützlich, in denen Programmiersprachen oder Technologien zum ersten Mal eingesetzt werden. Da sich im Verlaufe des Projekts der Wissens- und Erfahrungsstand der Entwickler stetig verbessert, verliert diese Rolle an Bedeutung, je weiter das Projekt fortschreitet. Gegen Ende des Projekts kann meistens fast vollständig auf einen Language Lawyer verzichtet werden. Aus diesem Grund sind Language Lawyer meistens externe Berater die nur für ein bestimmtes Projekt hinzugezogen werden. Die wichtigste Eigenschaft, die ein Language Lawyer mitbringen muss ist natürlich das Fachwissen der Sprache oder Technologie, die neu eingesetzt wird. Ein Experte ohne fundiertes Fachwissen ist nicht von grossem Nutzen. Zusätzlich sollte er aber auch sein Wissen gut an andere weitergeben können. Er sollte ähnlich wie ein Domain Expert sehr gute kommunikative Fähigkeiten besitzen und genügend Geduld aufbringen können, um den Entwicklern neue Konzepte beizubringen. Build Engineer Der Build Engineer ist dafür verantwortlich, dass regelmässig eine lauffähige Version des Projekts (ein sogenannter Build) erstellt werden kann. Dazu verwaltet er die Versionskontrollsoftware und veröffentlicht Dokumente und Berichte. Zusätzlich entwickelt er Skripts, die für den Kompilations- oder Verteilungsprozess (englisch: build und deploy) notwendig sind (bspw. Ant-Konfigurationen). Mit der Existenz einer eigenen Rolle für diese Aufgabe wird der Wichtigkeit von regelmässigen, aktuellen Builds des Projekts Rechnung getragen. In grösseren Projekten kann diese Rolle sogar in verschiedene Unterrollen aufgeteilt werden, welche dann von mehreren Mitarbeitern eingenommen werden. Der Build Engineer muss in erster Linie technische Fähigkeiten mitbringen und sollte bereits über eine gewisse Erfahrung auf diesem Gebiet verfügen. Toolsmith Der Toolsmith (englisch für Werkzeugschmied) hat die Aufgabe, kleine Programme zu schreiben, welche den Entwicklern die Arbeit erleichtern. Dabei kann es sich

7 Agile Softwareentwicklung mit FDD 7 beispielsweise um grafische Editoren für Konfigurationsdateien oder Konvertierungsprogramme handeln, welche Daten von einem Format in ein anderes konvertieren. Oftmals wird der Toolsmith damit beauftragt, eine zentrale Website einzurichten, die dem Team als Wissensdatenbank dient. Da diese Programme in der Regel nur intern Verwendung finden und nicht etwa an Kunden weitergegeben werden, kann auch ein unerfahrener Programmierer diese Rolle wahrnehmen. Auf diese Weise wird ein unerfahrener Programmierer langsam in das Team integriert und hat die Gelegenheit Erfahrungen zu sammeln, ohne direkt an Software für Kunden zu arbeiten. Somit können sich die erfahreneren Entwickler auf das eigentliche Projekt konzentrieren. System Administrator Der System Administrator ist dafür verantwortlich, das Netzwerk und die Server, welche das Team benötigt, aufzusetzen, zu konfigurieren und zu warten. Darunter fallen auch Datenbanken und dergleichen. Bei besonders grossen Projekten kann diese Rolle in die drei Unterrollen Server Administrator, Network Administrator und Database Administrator aufgeteilt werden. Oftmals ist der System Administrator auch an der Verteilung und Installation des Projekts beim Kunden beteiligt, da er beispielsweise eine Datenbank einrichten muss. Der System Administrator sollte über gute technische Kenntnisse in den Bereichen Netzwerke und Datenbanken verfügen. Ausserdem sollte er in diesen Bereichen auch eine Gewisse Erfahrung mitbringen, besonders in Bezug auf grosse Systeme Zusätzliche Rollen Tester Die Tester sind dafür verantwortlich, zu überprüfen, ob die Software die Anforderungen erfüllt und ob sie noch Fehler enthält. Damit die Tester ihre Aufgabe erfüllen können, ist es wichtig, dass regelmässig aktuelle Versionen der Software erstellt werden. Die Tester können in das Team integriert werden, es ist aber auch möglich externe Firmen oder Abteilungen mit dieser Aufgabe zu betrauen. Deployer Die Deployer kümmern sich um die Verteilung des Systems beim Kunden. Sie sind also dafür verantwortlich, die Software beim Kunden in Betrieb zu nehmen. Dazu kann es nötig sein, alte Daten in neue Formate zu konvertieren. Auch diese Rolle kann in das Team integriert werden oder von Externen erfüllt werden. Technical Writer Die Technical Writer (Technische Autoren) sind dafür verantwortlich, die Benutzerdokumentation zu verfassen. So schreiben sie verschiedene Dokumente, wie etwa Handbücher, die schlussendlich dem Benutzer zusammen mit der Software zur Verfügung gestellt werden. In grossen Firmen kann es eine spezielle Abteilung für die

8 8 Agile Softwareentwicklung mit FDD Technical Writer geben, in kleinen Projekten müssen sie hingegen extern hinzugezogen werden Best Practices Vorbemerkungen FDD definiert eine Reihe von sogenannten Best Practices. Dies sind Vorgehensweisen, die sich in der Praxis als nützlich erwiesen haben. Diese Best Practices spiegeln sich auch in den Prozess- und Rollendefinitionen von FDD wieder. Im folgenden Abschnitt werden die Best Practices beschrieben, da sie das Fundament sind, auf dem FDD aufbaut Domain Object Modelling Domain Object Modelling wird dazu verwendet, sich ein klareres Bild der Domäne zu machen, in der das System zum Einsatz kommt. Dadurch verspricht man sich einerseits eine klarere Sicht auf die Anforderungen, welche das System erfüllen muss. Andererseits liefert ein Domain Object Modelling bereits einige Klassen, für welche dann Methoden usw. definiert werden können. Domain Object Modelling ist also ein guter Einstiegspunkt in ein neues Softwareentwicklungsprojekt. FDD hat dem Domain Object Modelling einen eigenen Prozess gewidmet, der später noch genauer erläutert wird Developing by Feature In FDD werden die Anforderungen an das fertige System in Form von sogenannten Features ausgedrückt. Der Begriff Feature wird in FDD wie folg definiert: Ein Feature ist eine kleine Funktionalität, die einen Wert für den Kunden besitzt und in der Form <Aktion> <Resultat> <Objekt> ausgedrückt werden kann. Ein Beispiel für ein solches Feature wäre: Berechne den Totalbetrag der Bestellung. Diese Definition stellt zum einen sicher, dass Features nicht zu gross definiert werden. Alles was nicht in der obigen Form dargestellt werden kann, ist zu gross und kann nicht mehr als Feature bezeichnet werden. Zum anderen wird mit der Definition gewährleistet, dass jedes Feature auch wirklich für den Kunden einen Mehrwert besitzt. Dadurch soll verhindert werden, dass viel Zeit für Funktionen verloren geht, die zwar technisch einwandfrei sind, jedoch keinen Wert für den Kunden haben. Des Weiteren sollte ein Feature in weniger als zwei Wochen (= typischer Iterationszyklus) implementierbar sein. Andernfalls sollte man das Feature in kleinere Features unterteilen.

9 Agile Softwareentwicklung mit FDD 9 Weil jedes Feature jeweils nur eine kleine Funktionalität darstellt und die Entwicklerteams pro Feature entwickeln, lässt sich der aktuelle Status des Projekts jederzeit recht genau bestimmen. Die Eigenschaft, dass jedes Feature in maximal zwei Wochen implementiert werden kann, ermöglicht eine ungefähre Prognose für die Fertigstellung des Projektes auf zwei Wochen genau Class Ownership In FDD ist jede Klasse einem Entwickler (Class Owner) zugeordnet. Nur dieser Entwickler darf Änderungen an der Klasse vornehmen. Dadurch weiss der Entwickler bereits Bescheid, wie die Klasse funktioniert, wenn er daran Änderungen vornehmen soll. Es entfallen damit lange Einarbeitungszeiten in fremde Klassen und Änderungen können effizient vorgenommen werden. Ausserdem können auf diese Art Missverständnisse verhindert werden. Als zusätzlicher positiver Effekt entwickelt der Class Owner einen gewissen Stolz für seine Klasse und versucht diese so gut wie möglich zu entwickeln, da sie direkt ihm gehört und die Qualität des Codes direkt auf ihn zurückzuführen ist Feature Teams In FDD werden die einzelnen Features von so genannten Feature Teams entwickelt. Diese bestehen aus dem Chief Programmer, der für das jeweilige Feature verantwortlich ist und den Class Ownern der Klassen, die von dem Feature betroffen sind. Das Zusammenstellen der Feature Teams kann ein sehr aufwändiger Vorgang sein, da möglicherweise manche Class Owner noch anderweitig beschäftigt sind. Aus diesem Grund hat jeder Chief Programmer immer mehrere Features, für die er verantwortlich ist. So versucht er ein Feature auszuwählen, welches derzeit keine Konflikte verursacht. Durch das Entwickeln in Feature Teams werden die Teams immer wieder neu gemischt und es entstehen die unterschiedlichsten Konstellationen von Mitarbeitern Inspections Inspections sollen die Qualität von Design und Code verbessern. Dazu werden besagte Designs und Codestücke vor dem gesamten Team vorgestellt und erklärt. Das Design oder der Code muss dann durch das Team (vor allem durch den Chief Programmer) genehmigt werden. Damit soll nicht etwa totale Kontrolle und ein Klima der Angst erzeugt werden. Vielmehr soll dadurch qualitativ hochwertiger Code entstehen und ein kollaboratives Umfeld ermöglicht werden. Statistisch gesehen sind Inspektionen das effektivste Mittel für die Erkennung von Fehlern, sie sind jedoch recht zeitaufwändig. Man hofft diese Zeit aber dadurch einzusparen, dass man Fehler früh erkennt, die sonst aufwändig gesucht hätten werden müssen Configuration Management Configuration Management beschreibt im Wesentlichen den Gebrauch von Versionskontrollsoftware (beispielsweise Subversion) in FDD. Die Vorzüge solcher

10 10 Agile Softwareentwicklung mit FDD Systeme in Bezug auf Quellcode sind weithin bekannt. FDD empfiehlt aber auch Dokumente und Verträge in ein solches System einzubeziehen. Auf diese Weise können auch deren verschiedene Versionen erhalten werden und der Ablauf des Projekts ist aus dem Versions-Verlauf der Dokumente ersichtlich. Manche Auftraggeber schreiben sogar vor, Verträge und dergleichen in ein Versionskontrollsystem aufzunehmen Regular Build Schedule FDD schlägt vor, regelmässig eine lauffähige Version des ganzen Systems zu erstellen (einen sogenannten Build). Einerseits werden so Kompatibilitäts- und Integrationsprobleme zwischen einzelnen Features frühzeitig erkannt. Andererseits kann dem Kunden jederzeit eine lauffähige Version des Systems präsentiert werden. Auch die Tester haben auf diese Art regelmässig eine aktuelle Version des Systems. Ohne regelmässige Builds verlieren die Tester möglicherweise viel Zeit mit Fehlern, die in der aktuellen Version bereits gar nicht mehr vorhanden sind. Die Frequenz mit der solche lauffähige Versionen erstellt werden sollten, variiert je nach Projekt Visibility of Results Um ein Projekt steuern zu können, brauchen die Verantwortlichen regelmässig genaue und korrekte Informationen über den aktuellen Fortschritt des Projekts. FDD legt grossen Wert darauf, dass vor allem der Project Manager ständig auf dem Laufenden ist. Zur Bestimmung des aktuellen Fortschritts bietet FDD einige einfache Methoden, welche im Wesentlichen den Anteil vollendeter Features als Masszahl nehmen. Ist eine grössere Genauigkeit gewünscht, können auch Features die noch nicht vollständig entwickelt wurden bewertet und in die Berechnung aufgenommen werden. Dazu müssen alle Chief Programmer regelmässig den Fortschritt an den Project Manager melden Prozesse Vorbemerkungen Nachdem die in FDD verwendeten Rollen und Best Practices eingeführt wurden, kann auf die einzelnen Phasen des FDD-Prozesses, welche wiederum als Prozesse bezeichnet werden, eingegangen werden. Dazu wird zuerst ein Überblick über die insgesamt 5 Prozesse gegeben, damit später die jeweiligen Detailerklärungen im Gesamtkontext verstanden werden können. Die einzelnen Prozesse werden stets nach dem gleichen Muster behandelt. Zuerst wird eine allgemeine Beschreibung gegeben, anschliessend diverse Anfangskriterien genannt, welche erfüllt sein müssen, bevor der Prozess begonnen werden kann. Nachfolgend werden die einzelnen Teilaufgaben des jeweiligen Prozesses, sowie die darin involvierten Rollen genannt und ob die Aufgabe

11 Agile Softwareentwicklung mit FDD 11 optional oder erforderlich ist. Abschliessend werden Möglichkeiten der Evaluation der Resultate präsentiert, sowie Abschlusskriterien aufgestellt Überblick Wie in Fig. 1 ersichtlich, setzt sich FDD aus 5 verschiedenen Prozessen zusammen. Begonnen wird mit dem Prozess Develop an Overall Model. Ziel dieses Prozesses ist das Anfertigen eines Domain Object Models, also die Modellierung der einzelnen Entitäten des Systems und deren zusammenwirken. Dies geschieht in Zusammenarbeit mit den Domain Experts, welche durch ihr business-spezifisches Wissen wesentlich zur Entstehung des Modells beitragen. Anschliessend wird aus den gewonnenen Erkenntnissen des ersten Prozesses eine sogenannte Feature List aufgestellt. Diese Liste enthält die Gesamtheit der für den Kunden relevanten Features. Mehrere Features können anschliessend in sogenannten Feature Sets gruppiert werden, diese stellen jeweils eine bestimmte Business- Aktivität dar. Ziel des dritten Prozesses ist es, die Entwicklung der ermittelten Feature Sets zu planen. Dazu müssen Prioritäten und Abhängigkeiten zwischen den einzelnen Feature Sets ermittelt und eine Sequenz erstellt werden, welche die Reihenfolge der Entwicklung festlegt. Anschliessend werden die Feature Sets den verantwortlichen Chief Programmern zugewiesen, sowie die konkreten Class Ownerships bestimmt. Nun kann mit der eigentlichen Entwicklung des Systems in den Prozessen 4 und 5 begonnen werden. Wie in Fig. 1 zu sehen ist, stellen diese beiden Prozesse den iterativen Teil des Vorgehensmodells dar. Hierzu wählt ein Chief Programmer eine kleine Gruppe von Features aus, welche in den nächsten Tagen (maximal 2 Wochen) implementiert werden sollen. Die für die Implementierung der Features verantwortlichen Entwickler erstellen in Folge des vierten Prozesseses zuerst ein Design, welches durch eine entsprechende Inspection evaluiert wird. Gibt der Chief Programmer grünes Licht, so werden die vorher untersuchten Features im fünften und letzten Prozess implementiert und abschliessend wieder durch eine Inspection bewertet. Ist der Chief Programmer mit dem Resultat zufrieden, so kann eine neue Iteration gestartet, also mit dem Design und der Implementierung einer neuen Gruppe von Features fortgefahren werden. Fig. 1. Die 5 FDD-Prozesse (von

12 12 Agile Softwareentwicklung mit FDD Process 1: Develop an Overall Model Beschreibung: Diese erste Phase eines Projektes hat zum Ziel, die Domäne der Problemstellung genau zu untersuchen und die einzelnen Entitäten, sowie deren Beziehungen zueinander in Form eines Domain Object Models zu erfassen. Die Erstellung des Modells geschieht unter Anleitung des Chief Architect. Diese Aktivität trägt wesentlich zum Verständnis des Systems bei, da alle Bereiche in Zusammenarbeit mit den Domain Experts in Form eines sogenannten Walkthroughs behandelt werden. Dabei wird so vorgegangen, dass zuerst ein sogenannter High- Level Walkthrough, also ein relativ oberflächlicher Durchgang des Systems durch die Domain Experts, gemacht wird. Dies erlaubt es den Entwicklern sich einen Gesamteindruck vom System und dessen Kontext zu machen. Anschliessend werden die einzelnen Bereiche der Domäne in weiteren Durchgängen detailliert betrachtet. Am Ende jedes Durchgangs werden kleine Teams gebildet, bestehend aus Entwicklern und Domain Experts. Jedes Team modelliert dabei für sich den gerade besprochenen Systembereich. Im Anschluss werden die verschiedenen Modelle von den Teams präsentiert. In der nachfolgenden Diskussionsrunde wird unter Mitwirkung des Chief Architect das beste Modell bestimmt oder mehrere Modelle zu einem verschmolzen. Dieser Vorgang wird solange wiederholt bis alle Teilbereiche modelliert wurden. Die einzelnen Modelle können anschliessend zu einem grossen, dem Domain Object Model, zusammengeführt werden. Das erstellte Modell stellt dabei auf keinen Fall die definitive Version dar. Es dient viel mehr als Grundlage für den vierten Prozess Design by Feature und wird in Folge der verschiedenen Iterationen sicherlich noch modifiziert und ergänzt. Anfangskriterien: Die Domain Experts, Chief Programmer, sowie der Chief Architect wurden bereits bestimmt. Aufgaben: Modellierungsteam bilden Project Manager erforderlich Das Modellierungsteam setzt sich primär aus permanenten Mitgliedern wie den Domain Experts oder den Chief Programmern zusammen. Es wird jedoch während den verschiedenen Modellierungsphasen durch weitere Entwickler ergänzt. Dabei sollte beachtet werden, dass bei der Auswahl dieser weiteren Entwickler wenn möglich rotiert wird, so dass möglichst alle in das Projekt involvierten Personen mit dem Prozess in Kontakt kommen. Domain Walkthrough durchführen Modellierungsteam erforderlich

13 Agile Softwareentwicklung mit FDD 13 Ein Domain Expert gibt einen Überblick über den zu modellierenden Domänenbereich. Dabei sollten in erster Linie Informationen gewonnen werden, welche dem allgemeinen Verständnis dieses Bereiches dienen, die konkrete Implementation des Bereiches spielt in diesem Schritt noch keine Rolle. Dokumente studieren Modellierungsteam optional In diesem optionalen Schritt kann das Team verfügbare Referenz- oder Anforderungsdokumente, wie beispielsweise Objektmodelle, erstellte Use-Cases, oder Handbücher, studieren. Modellierung in kleinen Gruppen Modellierungsteam erforderlich Das Modellierungsteam wird in kleinere Untergruppen von maximal 3 Mitgliedern unterteilt. Diese erarbeiten jeweils ihr eigenes Modell für den aktuellen Domänenbereich. Der Chief Architect kann, um den Teams den Fortschritt zu erleichtern, einen Ausgangspunkt in Form eines unvollständigen Basismodells geben, auf dessen Grundlage die einzelnen Teams ihre Modelle erarbeiten. Entwicklung eines Teammodells Modellierungsteam erforderlich Ein Mitglied pro Untergruppe präsentiert das erstellte Modell für den jeweiligen Domänenbereich dem Modellierungsteam. Der Chief Architect kann dabei alternative Modelle vorschlagen. Anschliessend wird der beste Vorschlag ausgewählt oder eine Kombination aus mehreren Vorschlägen gebildet. Verfeinern des Gesamtmodells Chief Architect, Modellierungsteam erforderlich Gelegentlich wir das Domain Object Model, also das Gesamtmodell, welches die einzelnen Domänenbereiche beinhaltet, um die neuen Modelle ergänzt, welche durch Iterationen der beiden vorhergehenden Aufgaben erstellt wurden. Modellnotizen erstellen Chief Architect, Chief Programmer erforderlich Alternative oder komplexe Teile der Modelle werden in Form von Notizen dokumentiert, so dass diese auch in Zukunft noch nachvollziehbar sind. Evaluation: Interne u. Externe Beurteilung Modellierungsteam, Benutzer erforderlich Domain Experts, welche aktiv am Prozess beteiligt sind, beurteilen das erstellte Modell und damit ihre eigene (interne) Arbeit. Eine sogenannte externe Beurteilung erfolgt, nur falls notwendig, durch die konkreten Benutzer des Systems oder andere Leute aus dem Business, um letzte offene Fragen zu klären, welche das Modell beeinflussen. Schlusskriterien: Um diesen Prozess abschliessen zu können, muss das Modellierungsteam ein Domain Object Model liefern, welches den Vorstellungen des Chief Architect entspricht.

14 14 Agile Softwareentwicklung mit FDD Dieses Modell beinhaltet: - Klassendiagramme, welche die Entitäten des Systems darstellen und deren Zusammenwirken veranschaulichen. Zudem sollten die ermittelten Operationen und Attribute für die einzelnen Entitäten dokumentiert sein - Sequenzdiagramme, falls vorhanden - Notizen, welche gewisse Designentscheidungen und deren Alternativen dokumentieren Process 2: Build a Features List Beschreibung: Ziel dieses Prozesses ist das Erstellen einer Liste mit allen Features, welche zur Erfüllung der Anforderungen des Systems nötig sind. Dazu wird ein Team gebildet, welches sich üblicherweise aus den in Prozess 1 involvierten Chief Programmern zusammensetzt. Basierend auf der Unterteilung der Domäne durch die Domain Experts in Prozess 1, separiert das Team die Domäne in eine Anzahl von Bereichen, den sogenannten Major Feature Sets. Jeder Bereich wird wiederum in Aktivitäten unterteilt, welche als Feature Sets bezeichnet werden. Jeder Schritt in einer solchen Aktivität wird Feature genannt. Das Resultat dieser Unterteilungen ist schliesslich eine hierarchisch gegliederte Features List. Anfangskriterien: Das Modellierungsteam hat den ersten Prozess erfolgreich abgeschlossen. Aufgaben: Features List Team bilden Project Manager, Developm. Manager erforderlich Aus den Chief Programmern, welche bereits in Prozess 1 involviert waren, wird das Features List Team gebildet. Features List erstellen Features List Team erforderlich Gemäss dem in der Beschreibung beschriebenen Vorgehen wird die Domäne durch das Team in Bereiche (Major Feature Sets) und diese wiederum in Aktivitäten (Feature Sets) unterteilt. Aus den einzelnen Schritten der jeweiligen Aktivitäten werden schliesslich Features ermittelt. Das Team kann Features aber auch anhand von anderen Dokumenten wie Use Cases, Objektmodellen oder Handbüchern ermitteln. Evaluation: Interne u. Externe Beurteilung Features List Team, Benutzer erforderlich

15 Agile Softwareentwicklung mit FDD 15 Mitglieder aus dem Modellierungsteam, welche aktiv am Prozess beteiligt sind, beurteilen das erstellte Modell und damit ihre eigene (interne) Arbeit. Eine externe Beurteilung erfolgt, nur falls notwendig, durch die konkreten Benutzer des Systems oder andere Leute aus dem Business, um letzte offene Fragen zu klären, welche die Features List beeinflussen. Schlusskriterien: Um diesen Prozess abschliessen zu können, muss das Team eine Features List abliefern, welche sowohl den Project Manager, als auch den Development Manager zufrieden stellt. Die Features List besteht aus: - Einer Liste der einzelnen Bereiche (Major Feature Sets) - Aktivitäten (Feature Sets) zu jedem Bereich - Features zu jeder Aktivität, also deren konkreten Schritte Process 3: Plan by Feature Beschreibung: Im Laufe dieses Prozesses wird die Planung für die Entwicklung erstellt. Der Project Manager, Development Manager und die Chief Programmer legen zusammen fest, in welcher Reihenfolge die in Prozess 2 ermittelten Features entwickelt werden. Hierbei werden Abhängigkeiten zwischen Features, sowie deren Komplexität und die Auslastung des Entwicklungsteams berücksichtigt. Im Gegensatz zu den anderen Prozessen sind die Aufgaben dieser Phase nicht als strikte Sequenz zu sehen, nein sie werden viel mehr abwechselnd durchgeführt, wie dies bei Planungsarbeiten oft der Fall ist. Verfeinerungen in einer Aufgabe können wiederum zu Anpassungen in anderen Aufgaben führen. Das typische Vorgehen für diesen Prozess beginnt mit der Festlegung der Reihenfolge der Entwicklung, also der konkreten Sequenz, nach welcher die Features implementiert werden. Anschliessend werden die Feature Sets auf die einzelnen Chief Programmer verteilt. Diese sind dann für die konkrete Zuweisung der Class Ownerships an die verschiedenen Entwickler verantwortlich. Anfangskriterien: Das Features List Team hat den zweiten Prozess erfolgreich abgeschlossen. Aufgaben: Planungsteam bilden Project Manager erforderlich Das Planungsteam besteht aus dem Project Manager, sowie dem Development Manager und den Chief Programmern.

16 16 Agile Softwareentwicklung mit FDD Entwicklungssequenz definieren Planungsteam erforderlich Das Planungsteam legt ein Datum, welches nur aus Monat und Jahr besteht, für den Abschluss jedes Feature Sets fest. Die Bestimmung dieses Abschlusstermins geschieht aufgrund folgender Grundlagen: - Abhängigkeiten zwischen den Features was die involvierten Klassen angeht - Verteilung des Aufwands auf die verschiedenen Class Owner - Komplexität des zu implementierenden Features - Frühes fertigstellen von Features mit hohem Risiko - Berücksichtigung externer Meilensteine wie Betas, Feedback oder Probevorführungen Feature Sets den Chief Programmern zuweisen Planungsteam erforderlich Das Planungsteam weist die einzelnen Feature Sets den Chief Programmern zu. Diese Zuweisung geschieht basierend auf: - Der Entwicklungssequenz - Den Abhängigkeiten zwischen den Features was die involvierten Klassen angeht - Der Verteilung des Aufwands auf die verschiedenen Class Owner (Achtung: Chief Programmer sind auch Entwickler) - Der Komplexität des zu implementierenden Features Class Ownerships festlegen Planungsteam erforderlich Das Planungsteam weist die einzelnen Features bestimmten Entwicklern zu und bestimmt damit die jeweiligen Class Ownerships. Zu beachten ist, dass ein Entwickler meistens mehrere Klassen besitzt. Diese Zuweisung geschieht basierend auf: - Der Entwicklungssequenz - Der erwarteten Häufigkeit der Nutzung der Klasse - Der Verteilung des Aufwands auf die verschiedenen Entwickler - Der Komplexität der Klasse Evaluation: Interne u. Externe Beurteilung Planungsteam erforderlich Da die Planung Teamarbeit ist, geschieht die Evaluation durch aktive Teilnahme des Project Manager, Development Manager und der Chief Architects und zwar durch Zuhilfenahme der während Prozess 1 gewonnenen Erkenntnisse. Schlusskriterien:

17 Agile Softwareentwicklung mit FDD 17 Um diesen Prozess abschliessen zu können muss das Planungsteam eine Planung abliefern, welche sowohl den Project Manager, als auch den Development Manager zufrieden stellt. Die Planung besteht aus: - Feature Sets und deren geplante Abschlusstermine (Monat und Jahr) - Major Feature Sets und deren geplante Abschlusstermine, welche vom letzten Abschlussdatum der enthaltenen Feature Sets abgeleitet werden - Zugewiesenen Chief Programmern zu den Feature Sets - Einer Liste der Klassen und deren Owner Process 4: Design by Feature Beschreibung: Dieser Prozess gehört zum iterativen Teil von FDD. Es wird stets eine Iteration dieses und des nächsten Prozesses pro Feature durchgeführt. Das Resultat dieses Prozesses wird als sogenanntes Design Package bezeichnet. Einem Chief Programmer wird eine gewisse Anzahl geplanter Features zugewiesen. Aus diesen ihm zugewiesenen Features wählt er typischerweise eine kleine Gruppe aus, welche nun durch das Team innerhalb einer gesetzten Frist zu entwickeln ist. Bei der Auswahl dieser Gruppe von Features wird er mit Vorteil solche auswählen, welche dieselbe Klasse und damit denselben Entwickler betreffen, diese Art von Gruppe wird Chief Programmer Work Package genannt. Im Anschluss bildet der Chief Programmer ein Feature Team, welches sich aus den Class Ownern zusammensetzt, die mit hoher Wahrscheinlichkeit in die Entwicklung der gewählten Features involviert sind. Diese beginnen anschliessend mit der Erstellung von Sequenzdiagrammen für die ihnen übertragenen Features. Auf der Basis dieser Diagramme wird der Chief Programmer anschliessend das Domain Object Model aktualisieren. Ein weiterer in diesem Prozess erledigter Schritt ist das Erstellen der Klassenskelette durch die Entwickler, so dass im nächsten Prozess auf der Grundlage dieser Skelette mit der Implementierung begonnen werden kann. Die Qualität des erstellten Designs wird schlussendlich mit einer Inspection evaluiert. Anfangskriterien: Das Planungsteam hat den dritten Prozess erfolgreich abgeschlossen. Aufgaben: Feature Team bilden Chief Programmer erforderlich Der Chief Programmer ermittelt die Klassen, welche in das Design der ausgewählten Features involviert sind. Durch die Class Ownership Liste kann er die benötigten Entwickler identifizieren und das Feature Team bilden. Einen Domain Walkthrough durchführen Domain Expert optional

18 18 Agile Softwareentwicklung mit FDD Auf Wunsch des Chief Programmer kann ein Domain Expert herbeigezogen werden, welcher zusammen mit dem Feature Team nochmals die kritischen Bereiche der Domäne durchgeht. Referenzdokumente studieren Feature Team optional Je nach Bedarf kann das Team die verfügbaren Referenzdokumente konsultieren, um komplexe Features besser zu verstehen. Sequenzdiagramme entwickeln Feature Team erforderlich Das Team erstellt Sequenzdiagramme zu den Features, dabei werden alle besprochenen Alternativen und die getroffenen Entscheidungen, sowie weitere Abklärungen, welche die Requirements angehen, dokumentiert. Domain Object Model verfeinern Chief Programmer erforderlich Der Chief Programmer stellt Speicherplatz zur Verfügung, auf welchem das Team die aktuellen Dokumente ablegen kann. Auf der Grundlage dieser Dokumente ergänzt der Chief Programmer das Domain Object Model um zusätzliche Klassen, Operationen und Attribute und nimmt Änderungen an existierenden Klassen vor. Klassenskelette erstellen Feature Team erforderlich Die Class Owner erstellen für die modellierten Klassen Skelette, fügen diesen also bereits die Parametertypen, Exceptions und Messages der jeweiligen Methoden hinzu. Design Inspection Feature Team erforderlich Das Team führt für das erstellte Design in Zusammenarbeit mit dem Chief Programmer eine Inspection durch. Dies kann entweder vor oder nach den Unit Tests geschehen. Je nach Bedarf erstellen die Teammitglieder pro betroffene Klasse eine To-Do Liste. Evaluation: Dieser Prozess wird anhand der oben beschriebenen Design Inspection evaluiert. Schlusskriterien: Um diesen Prozess erfolgreich abzuschliessen, muss das Feature Team ein korrekt evaluiertes Design Package abliefern. Das Design Package enthält: - Ein Memo, welches das Package für Dritte verständlich macht - Die herbeigezogenen Requirements, falls vorhanden - Die erstellten Sequenzdiagramme - Besprochene Alternativen - Das aktualisierte Domain Object Model - Die erstellten Klassenskelette - Die während der Inspection erstellten To-Do Listen

19 Agile Softwareentwicklung mit FDD Process 5: Build by Feature Beschreibung: Dieser Prozess gehört, wie oben bereits erwähnt, zum iterativen Teil von FDD. Ziel ist es, die während dem vierten Prozess erstellten Designs des aktuellen Work Packages zu implementieren und testen. Das Testen geschieht mittels Unit Tests und Code Inspections, wobei die Reihenfolge durch den Chief Programmer festgelegt wird. Nach erfolgreichem Testen der Implementation kann diese in den Build aufgenommen werden. Anfangskriterien: Das Feature Team hat den vierten Prozess erfolgreich abgeschlossen. Aufgaben: Klassen und Methoden implementieren Feature Team erforderlich Die Class Owner implementieren die ihnen übertragenen Klassen dem Design entsprechend. Des Weiteren sind sie für das Schreiben der Unit Tests verantwortlich. Code Inspection durchführen Feature Team erforderlich Das Feature Team führt entweder vor oder nach den Unit Tests eine Code Inspection durch. Die Reihenfolge wird, wie erwähnt, durch den Chief Programmer definiert. Dieser entscheidet auch darüber, ob die Code Inspection nur innerhalb des Feature Teams durchgeführt wird, oder ob noch weitere Mitglieder aus dem Projektteam anwesend sind. Unit Test Feature Team erforderlich Jeder Class Owner testet seinen Code um sicher zu stellen, dass alle verlangten Anforderungen erfüllt werden. Es liegt im Ermessen des Chief Programmer zu entscheiden, ob noch Tests geschrieben werden sollen, welche die Interaktion der Klassen untereinander überprüfen. In den Build aufnehmen Chief Progammer, Feature Team erforderlich Nach erfolgreichem testen einer Klasse durch Unit Tests und Code Inspections kann diese in den Build aufgenommen werden. Der Chief Programmer ist der Integrationspunkt für alle Features, welche dem Build hinzugefügt werden sollen. Evaluation: Dieser Prozess wird anhand der oben beschriebenen Unit Tests und Code Inspections evaluiert.

20 20 Agile Softwareentwicklung mit FDD Schlusskriterien: Um diesen Prozess erfolgreich abschliessen zu können, muss das Feature Team ein oder mehrere fertiggestellte und erfolgreich evaluierte Features in den Build aufgenommen haben Fortschritt des Projektes Eine kritische Aufgabe während der Realisation eines Projektes ist die Einschätzung des aktuellen Fortschritts. Also die Antwort auf die Frage nach dem momentanen Status, der konkreten Position des Projektes im Gesamtverlauf. Stützt man sich hierbei nur auf die Einschätzungen der Entwickler, so führt dies erfahrungsgemäss [1] zu ungenauen und daher für das Management unbrauchbaren Angaben. Wie wird diesem Verhalten in FDD nun begegnet? Der Ansatz ist so einfach wie genial, denn FDD verlangt von den Entwicklern keine prozentualen Einschätzungen, sondern legt den Grad der Vollständigkeit eines Features anhand klar definierter Meilensteine fest. Was bedeutet dies nun konkret? Die beiden iterativen Prozesse 4 und 5, während denen die eigentliche Entwicklung der Features stattfindet, werden gemäss Fig. 2 in sechs Meilensteine unterteilt. Fig. 2. Meilensteine Für das Erreichen der 6 Meilensteine gelten folgende Kriterien (die Nummer steht für den jeweiligen Meilenstein): 1. Der Domain Walkthrough wurde beendet 2. Die 3 Aufgaben Sequenzdiagramme erstellen, Verfeinerung des Domain Object Models, sowie Schreiben der Klassenskelette wurden fertiggestellt 3. Die Design Inspection wurde erfolgreich durchgeführt 4. Die Klassen und Methoden wurden implementiert und getestet 5. Die Code Inspection wurde erfolgreich durchgeführt und die nötigen Änderungen vorgenommen 6. Der Code für ein Feature wurde in das Versionierungssystem, und damit den Build, aufgenommen Wie in Fig. 2 ersichtlich, wird jeder Meilenstein mit einer Prozentangabe versehen. Diese gibt wieder, wie viel vom Gesamtaufwand am Ende dieses Meilensteins erledigt wurde. Erreicht das Team beispielsweise den Coding Meilenstein, hat diesen aber noch nicht abgeschlossen, so hat es insgesamt 1% + 40% + 3% = 44% des aktuellen Features bearbeitet. Wichtig ist hier, dass jeweils nur die abgeschlossenen Meilensteine mitgezählt werden. Dies hat zur Folge, dass der berechnete Wert auf dem bisher Erreichten und nicht auf einer Schätzung basiert. Die Prozentangaben sind natürlich als Richtwerte zu verstehen und können je nach Unternehmen angepasst

21 Agile Softwareentwicklung mit FDD 21 werden. Wie wird nun konkret vorgegangen wenn es darum geht dem Management den aktuellen Stand der Entwicklung zu kommunizieren? Das Vorgehen ist vergleichsweise simpel. Man iteriert über die einzelnen Features und bestimmt den Fortschritt anhand des letzten erreichten Meilensteins, wie gerade besprochen. Wird dies für alle Features innerhalb eines Feature Sets getan, so erhält man den Fortschritt für dieses Feature Set. Analog dazu kann bei den Major Feature Sets vorgegangen werden. Auf diese Weise kann eine zuverlässige Beurteilung des aktuellen Projektfortschritts erhalten werden. Der Darstellung und mathematischen Weiterverwertung dieser berechneten Zahlen sind keine Grenzen gesetzt. So könnten beispielsweise Diagramme erstellt werden, welche den Fortschritt pro Feature Set, Major Feature Set oder über das gesamte Projekt für Stakeholder und Management visuell eindrucksvoll darstellen. Eine beliebte Art der Darstellung des Fortschritts ist der in Fig. 3 ersichtliche Graph. Auf der X-Achse wird die verstrichene Zeit in Wochen dargestellt und auf der Y- Achse die zu diesem Zeitpunkt total fertiggestellten Features. Auf diese Weise kann die Wirksamkeit gewisser Aktionen oder Ereignisse, wie z.b. die Anschaffung einer Komponente von einem Dritthersteller oder der Aufwand für die Vorbereitung für eine Demo eindrücklich präsentiert werden. Dies kann die Kommunikation mit dem Management ungemein erleichtern, da mittels solcher Darstellungen faktisch argumentiert werden kann. Fig. 3. Mögliche Visualisierung des Fortschritts Damit sollten die Grundlagen zur Verfolgung des Projektfortschritts eingeführt worden sein. Die präsentierten Darstellungsformen stellen nur einen Teil der von den Erfindern vorgeschlagenen Visualisierungen dar. Bei weitergehendem Interesse werden die entsprechenden Kapitel des in den Referenzen angegebenen Buches [1] empfohlen.

22 22 Agile Softwareentwicklung mit FDD 4. Schlussfolgerung Feature-Driven Development ist verglichen mit anderen agilen Entwicklungsmethoden, wie Scrum oder Extreme Programming, ein eher schwergewichtiger Prozess. Denn FDD schreibt eine nicht zu unterschätzende Anzahl von Rollen und Prozessen vor. Doch gerade diese relativ starke Reglementierung dürfte es Projektverantwortlichen erleichtern, das Management davon zu überzeugen, den Umstieg von alten Vorgehensweisen wie dem Wasserfallmodell auf eine agile Softwareentwicklungsmethode zu wagen. Wo leichtgewichtige Prozesse wie Scrum oder Extreme Programming durch ihre wagen und bewusst offenen Regelungen bei manch konservativ eingestelltem Vorgesetzten noch für Ablehnung sorgen, vermag FDD durch sein klar definiertes Vorgehen schon eher zu überzeugen. Fest definierte Modellierungs- und Planungsphasen zu Beginn des Projekts werden Vertretern des Wasserfallmodells mit hoher Wahrscheinlichkeit bekannt vorkommen und zu einer besseren Akzeptanz des Prozesses beitragen. Trotz der Ähnlichkeit zum veralteten Wasserfallmodell gilt es zu betonen, dass FDD zu 100% den Werten und Prinzipien des agilen Manifests entspricht und damit eindeutig zu dessen Prozessen gerechnet wird. Was der Einsatz von FDD für ein konkretes Projekt angeht, so muss sicher festgestellt werden, dass dies erst bei Projekten mit einem bestimmten Umfang sinnvoll ist. Denn für kleinere Projekte und Firmen ist der Bedarf an qualifiziertem Personal relativ hoch, was eine vernünftige Umsetzung schwierig gestalten könnte. Bei Projekten, welche dieses Kriterium jedoch erfüllen, kann von allen Vorteilen von FDD, wie der guten Skalierbarkeit nach oben, der benutzerzentrierten Vorgehensweise durch das Prinzip der Features und insbesondere den vergleichsweise genauen Möglichkeiten zur Bestimmung des Projektfortschritts, profitiert werden. Abschliessend kann festgehalten werden, dass Projektverantwortlichen mit FDD ein starkes Instrument zur Strukturierung des Entwicklungsprozesses zur Verfügung steht, welches sich in Zukunft sicherlich einer wachsenden Anhängerschaft erfreuen dürfte. 5. Referenzen 1. Palmer, S., Felsing, J.: A Practical Guide to Feature-Driven Development. 76 (2002) 2. Chanton, F., Schumacher, S.: Agile Softwareentwicklung mit Scrum. (2008)