Fachhochschule Köln University of Applied Sciences Cologne. Fakultät 07 Informations-, Medien- und Elektrotechnik

Transkript

1 Fachhochschule Köln University of Applied Sciences Cologne Fakultät 07 Informations-, Medien- und Elektrotechnik Studiengang: Master of Information Engineering Institut für Nachrichtentechnik Labor für Informatik Seminar Informatik Thema: Agile Software-Entwicklung Student: Betreuer Daskalakis-Daivandy, Milad Matrikelnr.: Prof. Dr. rer. nat. Hans W. Nissen Abgabedatum: Hiermit versichere ich, dass ich diese Seminararbeit selbständig angefertigt und keine anderen als die angegebenen und bei Zitaten kenntlich gemachten Quellen und Hilfsmittel benutzt habe. Milad Daskalakis-Daivandy

2 INHALTSVERZEICHNIS 1. Agile Softwareentwicklung - eine Methodologie Entstehungsgeschichte Prinzipien: das Agile Manifesto 3 2. Implementierung der agilen SW-Entwicklung XP Die Problemsituation Vier Kontrollvariablen eines jeden Projekts Umgang mit Änderungen Vier Grundwerte Prinzipien und Aktivitäten Die Lösung: Zwölf Praktiken Andere Methoden Agile SW-Entwicklung und SPM Herkömmliches SPM am Beispiel des Wasserfallmodells Agiles SPM Fazit 29 Literaturverzeichnis 30 Abbildungsverzeichnis 32

3 1 Agile Softwareentwicklung eine Methodologie Dieses Kapitel erläutert die Gründe, die zur Begründung der agilen SW-Entwicklung führten, erklärt, weshalb es sich um eine Methodologie handelt und zählt die Kriterien auf, die diese Methodologie ausmachen. 1.1 Entstehungsgeschichte Die Prinzipien der agilen Softwareentwicklung entwickelten sich Mitte der 1990er Jahre als Gegenbewegung zum traditionellen dokumentlastigen Softwareentwicklungsprozess, der durch das Wasserfallmodell geprägt und sehr von bürokratischen Regularien durchzogen ist. Das Wasserfallmodell wird als nicht unbedingt praxiskonform für Softwareentwickler bezeichnet, da es in der Theorie darauf basiert, eine Phase perfekt abzuschliessen, bevor die Arbeit an der nächsten Phase begonnen wird; es sieht im Falle notwendiger Änderungen lediglich Rücksprunge von einer Phase zu einer vorhergehenden Phase vor, nicht aber von einer Phase zurück zu einer nicht direkt benachbarten Phase. Dies ist sehr praxisfern, da sich in der Regel die Ergebnisse der initialen Anforderungsanalyse noch im späteren Projektverlauf ändern können ( der Kunde weiss nicht in jedem Fall von Anfang an, was er will ), bzw. in der Verfikationsphase festgestellt wird, dass die Implementierung nicht deckungsgleich mit den Kundenanforderungen ist. Mit anderen Worten: das Wasserfallmodell weicht in vielen Fällen, ganz besonders dann, wenn nicht genügend Erfahrungswerte bzgl. des zu entwickelnden Softwaretyps seitens der Softwareentwickler vorhanden sind, von der Realität der Softwarentwicklung, in der Backtracking zwischen den Phasen nötig ist, ab (vgl. [6]). Dies ist in den beiden folgenden Abbildungen, die einer Software-Engineering-Vorlesung der australischen Monash University entstammen, schematisch dargestellt. Dort wird das traditionelle Wasserfallmodell als ein geordnetes, einfaches und leicht verständliches Modell vorgestellt, das einen einfachen Managementprozess garantiert; das einzige Problem bestehe jedoch darin, dass nicht einmal die einfachsten Softwaresysteme tatsächlich auf exakt diese Weise entwickelt werden (vgl. [4]). 1

4 Abb. 1 Wasserfallmodell Abb. 2 Realität der Softwareentwicklung mit dem Wasserfallmodell 2

5 1.2 Prinzipien: das Agile Manifesto Im Frühjahr 2001 fanden sich 17 wichtige Befürworter (darunter auch die Begründer des Extreme Programming) agiler Methoden aus der Softwareindustrie zusammen, um basierend auf ihren beruflichen Erfahrungen und Überzeugungen einen gemeinsamen Nenner herauszuarbeiten, der als Leitfaden für die agile Softwareentwicklung dienen sollte. Das Ergebnis, das Agile Manifesto, besteht aus zwölf simplen Leitlinien, die in ihrer Gesamtheit auch Neulingen auf dem Gebiet der agilen Softwareentwicklung bzw. Interessenten bereits ein aussagekräftiges Bild vermitteln (vgl. [3]; es folgt die freie Übersetzung ins Deutsche durch den Autor): 1. Unsere höchste Priorität gilt der Kundenzufriedenheit mittels früher und kontinuierlicher wertvoller Softwarelieferungen. 2. Heisse Anforderungsänderungen selbst in späten Entwicklungsphasen willkommen. Agile Prozesse beziehen ihren Erfolg aus Änderungen, um den Wettbewerbsvorteil des Kunden sicherzustellen. 3. Liefere im Rahmen von wenigen Wochen bis zu wenigen Monaten regelmässig funktionstüchtige Software; kürzere Zeitabstände bevorzugt. 4. Die wirtschaftlich Verantwortlichen und Softwareentwickler müssen über die Projektdauer hinweg täglich zusammenarbeiten. 5. Entwickle Projekte mit motivierten Leuten. Gib' ihnen die nötige Umgebung und Unterstützung und trau' ihnen zu, dass sie den Auftrag erledigen. 6. Die effizienteste und effektivste Methode der Informationsvermittlung innerhalb eines Entwicklungsteams ist das persönliche Gespräch im gleichen Raum. 7. Funktionstüchtige Software ist der primäre Massstab für Projektfortschritt. 8. Agile Prozesse begünstigen tragfähige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten dazu in der Lage sein, unbegrenzt eine konstante Geschwindgkeit aufrechtzuerhalten. 9. Beständiger Fokus auf technische Exzellenz und gutes Design fördern die Agilität. 10. Einfachheit die Kunst, nicht erledigte Arbeiten zu maximieren ist essentiell. 11. Die besten Architekturen, Anforderungen und Designs ergeben sich aus sich selbst organisierenden Teams. 12. In regelmässigen Zeitabständen überlegt sich sich das Team, wie es effektiver werden kann und passt sein Verhalten dann dementsprechend an. 3

6 Das Agile Manifesto adressiert also verschiedene Ebenen: Planung Kundenzufriedenheit durch regelmässige funktionstüchtige Softwarereleases Softwarerelease als Hauptphasenergebnis Soziales direkte und persönliche Zusammenarbeit aller Projektbeteiligten Selbstorganisation und Eigenverantwortung wichtig Fähigkeit zur Selbstkritik des Teams Technisches gutes Design technische Exzellenz Im folgenden Kapitel soll gezeigt werden, wie die o.g. Prinzipien anhand der Software- Engineering-Methodologie Extreme Programming, auch XP genannt, in die Praxis umgesetzt werden. 4

7 2 Implementierung der agilen Softwareentwicklung Das zweite Kapitel präsentiert und charakterisiert die Softwareentwicklungsmethode XP (Extreme Programming) und zeigt auf, inwiefern XP die Prinzipien der agilen Softwareentwicklung implementiert. In einer Randnotiz werden im Alternativen zu XP aufgezählt, jedoch nur kurz und oberflächig. 2.1 XP Die Problemsituation Softwareentwicklung ist eine Kollaboration zwischen Kunden, Managern und Entwicklern oder besser: Softwareentwicklung erfordert eine Kollaboration zwischen Kunden, Managern und Entwicklern Vier Kontrollvariablen eines jeden Projekts Jedes Softwareprojekt lässt sich in Abhängigkeit von vier äusseren Kontrollvariablen bestimmen: Kosten, Zeit, Qualität und Umfang. Die Grundidee dieser Sichtweise besteht darin, dass drei dieser vier Variablen extern bestimmt werden, also von Kunden und Managern, und die resultierende vierte Variable in Abhängigkeit der drei anderen Variablen vom Entwicklungsteam festgelegt wird. Dabei ist darauf zu achten, dass die 3:1-Ratio unbedingt eingehalten wird; das Modell würde nicht funktionieren, wenn alle vier Variablen extern bestimmt würden, da das Entwicklungsteam auf diese Weise keinen nennenswerten Einfluss auf die Planung des Projekts hätte und somit unter alles andere, als optimalen Bedingungen ans Werk müsste; Software entsteht unter Kollaboration verschiedener Personengruppen (Kunden, Manager, Entwickler). Daher müssen alle Projektbeteiligten Zugriff auf diese vier Variablen haben, damit sie bewusst entscheiden können, welche sie bestimmen wollen. Gefällt allen Beteiligten der resultierende vierte Variablenwert nicht, können sowohl die ersten drei Variablenwerte geändert werden, als auch eine andere Variablenauswahl getroffen werden, bis ein resultierender vierter Variablenwert allen Projektbeteiligten gefällt. 5

8 Dass Kosten, Zeit, Qualität und Umfang sich gegenseitig bedingen, liegt dabei auf der Hand. Im folgenden sollen jeweils kurz Extremwerte für jede dieser vier Variablen beleuchtet werden. Kosten Steht zu Beginn viel Geld zur Verfügung, so kann sich dies durchaus vorteilhaft auswirken, da man nicht an allen Ecken sparen muss (Hardware, Entwicklungsumgebungen etc.); es kann sich aber unter Umständen auch als nachteilig herausstellen. Als anschauliches Beispiel dient das Szenario, in dem zu Projektbeginn vom Management oder unerfahrenen Entwicklern eine viel zu hohe Entwicklerzahl für den Projektstart festgelegt bzw. angefordert wird. Wenn für die Implementierung einer Funktionalität, die zu Beginn von einem fünfköpfigen Entwicklerteam durchgeführt werden kann, gleich 30 Entwickler verteilt auf sechs Teams festgelegt bzw. angefordert werden, ist dies nicht nur eine Verschwendung von Ressourcen, sondern auch eine Bremse: denn zwischen sovielen Menschen entsteht eine Menge Reibung, die aufzulösen u.a. einen sehr hohen Koordinationsaufwand erfordert. Vielmehr wäre es ratsam, ein Team beginnen zu lassen und dann mit der Zeit bei Bedarf das Team zu vergrösseren bzw. ein neues Team hinzuzuziehen. Rapides Wachstum steht konträr zum von XP propagierten langsamen, aber stetigen Wachstum, was später noch näher erläutert werden wird. Steht hingegen eindeutig zuwenig Geld zur Verfügung, wird das Entwicklerteam das Problem des Kunden nicht lösen können. Zeit Steht viel Zeit zur Verfügung, kann sich dies in verbesserter Qualität und grösserem Umfang auswirken. Dabei ist jedoch zu beachten, dass alle Projektbeteiligten das wertvollste Feedback (ein sehr wichtiger XP-Wert, auf den später näher eingegangen werden wird) aus Systemen erhalten, die im Produktionsmodus laufen. Je mehr Zeit man einem Projekt gibt, desto weiter werden i.d.r. die Systemtests für den Produktionsmodus nach hinten verschoben, desto später erhält man hochwertiges und nützliches Feedback, desto später kann man etwaige Fehler korrigieren, desto später wird also eine gute Qualität erreicht werden. Gibt man einem Projekt jedoch zu wenig Zeit, werden Kosten, Qualität und Umfang unweigerlich in Mitleidenschaft gezogen werden. Qualität Qualität als Kontrollvariable einzusetzen, ist fragwürdig, da jede Software qualitativ zumindest gut sein sollte. Es gibt aber Systeme, bei denen man sehr feine Abstufungen machen muss, da 6

9 Menschenleben davon abhängig sind und es versicherungstechnisch relevant ist (z.b. eingebettete Systeme, die i.d.r. sehr zeitkritisch sind und die damit einhergehenden Risikoparameter nach DIN 19250); zu Projektbeginn jedoch bewusst die Qualität unterhalb ein Niveau von gut zu schrauben, macht keinen Sinn. Umfang Je geringer der Umfang ist, desto höher ist die lieferbare Qualität innerhalb eines festen Zeitrahmens bzw. desto geringer die Zeit und günstiger die Kosten, wenn man die angestrebte Qualität (z.b. gut ) beibehält. Verglichen mit den anderen drei Variablen, variiert der Umfang häufig. Dies liegt darin begründet, dass die anfänglichen Anforderungen des Kunden an eine Software sich meistens während der Entwicklung ändern, da der Kunde zu Beginn nicht exakt weiss, was er wirklich will bzw. ob das, was er will, wirklich sein spezielles Problem löst. Auch die Entwickler können dies nicht direkt aus dem Stehgreif erkennen. Frühestens beim ersten Release oder beim ersten Prototypen wird der Kunde sagen können, was er für das nächste Release haben möchte. Dass sich die Anforderungen also während der Entwicklung ändern, ist meist unvermeidbar, eine Art ungeschriebenes Gesetz. Daher wäre es vorteilhaft, diesen Umstand nicht als Nachteil zu bedauern, sondern als Vorteil zu sehen und aktiv auszunutzen. Aus obigen Ausführungen geht hervor, dass lauffähiger Code in Aktion dem Kunden bei der Entscheidung, ob das Projekt in die richtige Richtung geht oder nicht, sehr behilflich ist. Je häufiger der Kunde also in einer bestimmten Zeit lauffähigen Code sieht, desto besser und schneller können etwaige Anpassungen gemacht werden und eine gute Qualität gewährleistet werden. Möchte man dieses Vorgehen formalisieren, würde man die Variablen Zeit, Qualität und Kosten fixieren und den resultierenden Umfang betrachten. Im Zuge der Entwicklung würde man kontinuierlich den Umfang an entstehende Bedingungen anpassen: wird beispielsweise die Zeit bis zum Releasetermin knapp, gibt es immer Funktionalitäten, die auf den nächsten Release verschoben werden können. Damit dieses Modell funktioniert, ist die Toleranz für Änderungen während der Entwicklung unabdingbar; dies wiederum setzt voraus, dass die durch Änderungen verursachten Kosten relativ gering sind. Jedoch müssen zusätzlich zwei Regeln eingehalten werden, damit das ganze auch funktioniert schliesslich wäre es undenkbar, kurz vor jedem Releasetermin wichtige Funktionalitäten auf das jeweils nächste Release zu verschieben. Zum einen sollte man Erfahrung darin sammeln, Schätzungen anzustellen und allen Projektbeteiligten (vor allem dem Kunden) aktuelle Ergebnisse zu übermitteln; je besser die Schätzungen, desto geringer die 7

10 Wahrscheinlichkeit, dass Funktionalitäten auf das nächste Release verschoben werden müssen. Zum anderen sollte man die für den Kunden wichtigsten Funktionalitäten zuerst implementieren; auf diese Weise ist sichergestellt, dass im Falle weiterer Verschiebungen die wichtigsten Kundenanforderungen bereits implementiert sind Umgang mit Änderungen Wie bereits erwähnt, kann der Kontrollansatz über die vier Kontrollvariablen Kosten, Zeit, Qualität und Umfang mit Fokus auf dem Umfang nur funktionieren, wenn von allen Projektbeteiligten regelmässige Änderungen toleriert werden. Angesichts der Tatsache, dass die klassische Änderungskostenkurve der Softwareentwicklung ein exponentielles Kostenwachstum entlang der Entwicklungszeit aufweist, erscheint die Toleranz für Änderungen in einem Projekt, erst recht in fortgeschrittenen Stadien, als ein Luxus, den sich niemand leisten kann. Abb. 3 Kosten, die durch Planabweichungen während der Softwareentwicklung entstehen Ruft man sich das Wasserfallmodell in Erinnerung, macht die in Abb. 3 dargestellte Änderungskostenkurve durchaus Sinn: kostet eine Planänderung in der anfänglichen Planungsphase nur relativ wenig Geld (Änderung der Planungsdokumente und erneute Koordination aller Projektbeteiligter etc.), verursachen Planabweichungen in späteren Entwicklungsstadien weitaus höhere Kosten (Backtracking: zu Änderungen in der aktuellen Projektphase sind mit hoher Wahrscheinlichkeit auch Änderungen in allen vorhergehenden Phasen nötig). 8

11 Die klassische Änderungskostenkurve gibt es, wie der Name schon impliziert, etwas länger (dies gilt auch für das Wasserfallmodell); als sie entstanden ist, lag der Stand der (Software-)Technik weit hinter dem heutigen zurück. Entwicklungsumgebungen, bessere Programmiersprachen, öffentlich einfach zugängliche und qualitativ hochwertige Klassenbibliotheken, API- Beschreibungen etc. wie sie heute gang und gäbe sind, gab es nicht. Auf Basis der heutigen Möglichkeiten propagiert XP, dass eine gänzlich andere Änderungskostenkurve möglich ist (siehe Abb. 4). Abb. 4 Änderungskostenkurve nach Kent Beck Die Kosten steigen demnach zu Projektbeginn an und bleiben ab dem Design relativ konstant. Diese Behauptung ist dabei gar nicht so kühn, wie man erst denken mag, gibt es doch nicht nur bessere Programmiersprachen, sondern auch bessere Datenhaltung (objekt-orientierte Datenbanken, die es entgegen der klassischen relationen Datenbanken ermöglichen, Verhalten und Daten an einem Ort zu speichern; dies macht eine nachträgliche Änderung bzw. Ersetzung wesentlich einfacher), bessere Programmiermethoden, bessere Architekturen (verteilte Software, die Heterogenität unterstützt, wie z.b. Web Services), Entwicklungswerkzeuge (Kooperationswerkzeuge, Entwicklungsumgebungen mit integrierten umfangreichen Hilfsbibliotheken etc.) und Notationen (z.b. UML). Man sollte jedoch auch bedenken, dass mit jedem Release nicht nur Verbesserungen eingebaut werden, sondern auch Erweiterungen: die Software wächst also in ihrer Funktionalität (und somit auch in ihren Designmodellen, im Code und somit in ihren Kosten). Hinsichtlich Software, die regelmässig neue Releases hat, sähe demnach eine allgemeingültigere Änderungskostenkurve eher 9

12 aus, wie in Abb. 5. Sind Änderungskosten also eher geringer, wie in Abb. 4 und 5 gezeigt, verhalten sich alle Projektbeteiligten anders, als wenn sich die Änderungskosten wie in Abb. 3 verhielten. Wichtige Entscheidungen müssen auf diese Weise nicht schon während der Planungsphase getroffen, sondern können auf einen späteren Zeitpunkt verschoben werden, für den die Wahrscheinlichkeit wesentlich grösser ist, eine richtige Entscheidung zu treffen. Um diesen Vorteil sinngemäss zu nutzen, müssen folgende Regeln eingehalten werden: es ist ein einfaches Design mit Verzicht auf Elemente zu verwenden, die zwar noch nicht genutzt werden, die man jedoch in der Zukunft zu nutzen erwartet Einführung automatisierter Tests, so dass man Sicherheit darüber hat, nicht versehentlich das bestehende Systemverhalten verändert zu haben viel Erfahrung in Designveränderung sammeln, so dass man keine Bedenken davor hat, wenn die Zeit für Designänderungen reif ist Abb. 5 Änderungskostenkurve nach Scott W. Ambler Vier Grundwerte Als Methodologie für Softwareentwicklung propagiert XP eine Menge von konsistenten und somit vergleichbaren Werten zur Wahrung und Vereinigung wirtschaftlicher und menschlicher Interessen. In den vorherigen Kapiteln wurden bereits Kontrollvariablen für die Projektplanung vorgestellt und die Bedeutung vom Umgang mit Änderungen verdeutlicht; es ging vornehmlich um 10

13 projektwirtschaftliche Interessen (Zeit, Kosten, Qualität, Umfang). In diesem Kapitel geht es um die vier Grundwerte von XP, die darauf abzielen, die in einem Softwareprojekt entstehende Reibung menschlicher, technischer wie auch wirtschaftlicher Natur zu minimieren, damit alle Projektbeteiligten (Kunden, Manager, Entwickler) effizient miteinander kollaborieren können: Kommunikation, Einfachheit, Feedback, Mut. Kommunikation Jeder Projektbeteiligte sieht die Dinge aus einer individuellen Perspektive, die nicht mit den jeweiligen Perspektiven der anderen übereinstimmen muss. Das beginnt damit, dass ein Entwickler den Kunden nicht richtig verstanden hat, pflanzt sich fort, indem ein Entwickler einen anderen Entwickler missversteht und dass der Entwicklerteamleiter auf diese Weise dem Manager falsche Informationen kommuniziert. Das Ausmass der Fehlerfortpflanzung und -verdichtung kann verständlicherweise immens sein, aus kleinen Missverständnissen werden teure Fehler. Missverständnisse passieren nicht immer zufällig, sondern können aus einer bestimmten Erwartungshaltung heraus auftreten: ein typisches Beispiel ist ein Entwickler, der einen Manager nicht eindeutig über eine aktuelle Problemsituation aufklärt, da er aus eigener Erfahrung heraus entsprechende Repressalien befürchtet; daher gibt er dem Manager bewusst geschönte bzw. unvollständige Informationen, in der Hoffnung, bis zum nächsten Berichtstermin die Situation bereinigt zu haben. Dies ist jedoch der falsche Weg, da somit das Problem nicht allen Projektbeteiligten kommuniziert wird und somit zum einen weder die Erwartungshaltung aller Teilnehmer (vor allem Kunden und Manager) an die aktuellen Umstände angepasst wird und zum anderen nicht alle Teilnehmer aktiv an der Problemlösung beteiligt werden. Sollte das geheim gehaltene Problem also nicht bis zum nächsten Berichtstermin, wie vom Entwickler gehofft, behoben worden sein, stehen unweigerlich grosse Probleme für alle Projektbeteiligten ins Haus. Dies soll als eines von vielen Beispielen für mangelhafte Kommunikation dienen. XP zielt mittels bestimmter Methoden (Paarprogrammierung, Unit-Tests, Aufwandsschätzung für Aufgaben; dazu später mehr) darauf ab, zwischen allen Projektteilnehmern den richtigen Kommunikationsfluss zu erzeugen und aufrechtzuerhalten. Denn die o.g. Methoden funktionieren ohne eine Kommunikation zwischen allen Projektbeteiligten nicht. Natürlich kann Kommunikation auch in einem XP-Projekt behindert werden; aus diesem Grund ist ein Betreuer (dies kann ein erfahrener Entwickler aus dem Team oder aber auch ein angeforderter Externer sein) vorgesehen, der die Kommunikation auf nicht (vernünftig) kommunizierende Teilnehmer hin überwacht und diese wieder in den Kommunikationsfluss reintegriert. 11

14 Einfachheit Einfachheit im Softwaredesign und der -implementierung zu erzielen ist nicht immer einfach, da Entwickler dazu neigen, die Software auf zukünftige Änderungsanforderungen vorzubereiten, was die Planung und den Code für aktuell benötigte Funktionalitäten unnötig verkompliziert. Dieses Bestreben ist in der Befürchtung vor der exponentiell wachsenden klassischen Änderungskostenkurve (vgl. Kapitel ) verankert und macht in diesem Kontext durchaus Sinn. Geht man jedoch von einer an die durch heutige IT-Möglichkeiten gegebenen Situation aus, sind Änderungskostenkurven nach den Abb. 4 und 5 möglich; daher setzt der XP-Entwickler darauf, aktuell benötigte Funktionalitäten so einfach, wie möglich (und ohne Rücksicht auf evtl. zukünftige Änderungen) zu implementieren. Falls in Zukunft Änderungen nötig sein sollten, ist dies aufgrund der relativ niedrigen Mehrkosten kein Problem. Dabei liegt klar auf der Hand, dass sich Kommunikation und Einfachheit gegenseitig bedingen: je mehr man kommuniziert, desto besser wird allen Projektbeteiligten klar, was gebraucht wird und vor allem was (zumindest aktuell) nicht gebraucht wird; das System wird also simpler. Je simpler das System ist, desto pragmatischer fällt hingegen die Kommunikation aus. Was auch erwähnenswert ist: je einfacher das System, desto weniger Entwickler benötigt man (zu diesem Zeitpunkt). Sollten für zukünftige Änderungen mehr Programmierer benötigt werden, holt man sich diese dann nicht früher. Feedback Um den wichtigen Stellenwert, den Feedback in XP einnimmt, zu verdeutlichen, wird gerne die Metapher des Autofahrens herangezogen: anstelle mit grösster Vorsicht in die Ferne zu schauen und stets mittig zu fahren, ist es wichtiger, ständig aufmerksam zu sein, kleine Korrekturen zu machen. Trifft man etwa unerwartet auf eine Unfallstelle, nimmt man eine Umleitung und fährt nicht einfach hindurch, nur weil man die Strecke so geplant hat. Feedback führt die Kommunikation konsequent mit Fokus auf das System fort: Don't ask me, ask the system ([1], S. 31). Es geht darum, unfundiertem Optimismus eine Absage zu erteilen und sichereres und gültigeres Feedback mittels Zusammenarbeit aller Projektteilnehmer vom System zu erhalten. Feedback funktioniert dabei in zwei verschiedenen Zeitbereichen: kurzfristig und langfristig. Kurzfristiges Feedback erstreckt sich von Minuten bis hin zu wenigen Tagen: Entwickler schreiben Unit-Tests für evtl. anfällige Programmlogik und erhalten somit in relativ kurzen Zeitabständen konkretes Feedback über den Systemzustand. Eine weitere Möglichkeit sind vom Kunden angefertigte 'Geschichten' (Beschreibungen der gewünschten Systemeigenschaften), die von den Entwicklern hinsichtlich Qualität und Aufwand mittels Schätzungen beurteilt werden. Ein Manager 12

15 (oder auch ein anderer mit der Überwachung des Projektforschritts Beauftragter, z.b. ein Entwickler oder der bereits erwähnte Betreuer, vgl. Kap. 3.2) gibt dem ganzen Team bzgl. der aktuellen Aufgaben Feedback hinsichtlich des Zeitplans. Bei langfristigem Feedback (Wochen bis Monate) schreiben Kunden und Tester funktionale Tests für anhand o.g. 'Geschichten' implementierte Funktionen und erhalten somit konkretes Feedback über den aktuellen Systemzustand. Im Abstand von zwei bis drei Wochen überprüfen die Kunden dann den Zeitplan, um festzustellen, ob das ganze Team entsprechend schnell voranschreitet; bei Abweichungen vom Zeitplan müssen Planänderungen vorgenommen werden (vgl. Kap ). Sobald man sich auf Basis des Systemfeedback sicher ist, wird das System vom Entwicklungsmodus in den Produktionsmodus gesetzt, damit das Kundenunternehmen ein Gefühl dafür erhält, wie sich das System in Aktion verhält. Dadurch, dass die wichtigsten Kundenanforderungen bzw. 'Geschichten' zuerst implementiert worden sind, kann das System bereits vorzeitig in einen sog. frühen Produktionsmodus gehen, anhand dessen alle Projektbeteiligten das wertvollste Feedback erhalten, auf dessen Basis die weitere Projektplanung gemacht werden kann (vgl. Kap ). Typische Fragen sind: Sind Änderungen vorzunehmen? Falls ja, welche Änderungen? Falls nein, welche 'Geschichten' sind im folgenden zu implementieren? Dann werden die neuen 'Geschichten' im Entwicklungsmodus implementiert, das System mit den neuen Funktionalitäten im Produktionsmodus getestet etc.... Das Jonglieren zwischen dem Entwicklungs- und dem Support für den Produktionsmodus steht im Gegensatz zum klassischen Bestreben, das System solange im Entwicklungsmodus zu halten, wie nur möglich, da man im Produktionsmodus das System kaum noch verändern kann. In diesem Fall spricht wieder die Sorge über die klassische Änderungskostenkurve mit exponentiellem Wachstum entlang des Projektfortschritts (vgl. Kap ). Konkretes Feedback, Einfachheit und Kommunikation verhalten sich synergistisch: je mehr wertvolles Feedback vorhanden ist, desto einfacher verläuft die Kommunikation, was wiederum zu klaren Testfällen und -prioritäten führt. Laufen alle so entstandenen Systemtests, weiss man, dass das System fertig ist. 13

16 Mut Mut komplementiert die anderen drei Grundwerte. Liefern die Systemtests beispielsweise zum Ende der Entwicklung hin plötzlich viele Fehler, obwohl bis dahin alle Systemtests zufriedenstellend waren, könnte dies an einem Architekturfehler liegen, den es umgehend zu beheben gilt. Es liegt dabei klar auf der Hand, dass nach Korrektur der Architektur nicht mehr alle bis dahin positiven Systemtests wieder positiv ausfallen werden; die bisherigen Testfälle müssen also überarbeitet bzw. teilweise ganz verworfen und gegen neue ersetzt werden. Ein anderes Beispiel ist das Verwerfen von bereits geschriebenem, aber sehr schlechtem Code, nachdem man bereits einen ganzen Arbeitstag darin investiert hat. Anstatt aufgrund des bisherigen Zeitaufwands stur an diesem schlechten Code festzuhalten, kann es hilfreich sein, ihn zu verwerfen und am nächsten Tag frisch ans Werk zu gehen. Das mag nicht kategorisch die beste Lösung sein, kann aber in vielen Fällen hilfreich sein. Beide Beispiele zeigen, dass manchmal Mut erforderlich ist, um unkonventionelle Wege bei der Problemlösung zu gehen. Ohne die anderen drei Grundwerte führt diese Form von Mut jedoch eher zu undiszipliniertem und ziellosem Programmieren, also 'Hacken' (im negativen Sinne). Eine gute Kommunikation zwischen allen Projektbeteiligten wirkt sich positiv aus, indem die Entwickler sowohl den Kunden, als auch den Manager über die möglichen Risiken und Nutzen einer relativ radikalen Planänderung aufklären und somit zuversichtlicher ans Werk gehen können. Einfachheit hat den Vorteil, dass man viel mutiger an die Änderung eines einfachen Systems herangeht. Mut wiederum komplementiert Einfachheit: sobald man eine Möglichkeit zur Vereinfachung des Systems sieht, kann man sich dran versuchen. Zu guter letzt unterstützt Feedback Mut durch die Systemtests: sobald man den Code geändert hat, testet man den Code und wird die Änderung in Abhängigkeit von den Testergebnissen übernehmen, verändern oder verwerfen. So stimmig diese vier synergistischen Grundwerte auch sind: ohne gegenseitigen Respekt innerhalb des Entwicklerteams, idealerweise aber zwischen allen Projektbeteiligten, werden diese vier sozial und wirtschaftlich äusserst wichtigen Grundwerte nicht greifen. Respekt ist also das Fundament für diese vier Grundwerte: If members of a team don't care about each other and what they are doing, XP is doomed. ([1], S. 35) Diese vier Grundwerte müssen nun in die Praxis umgesetzt werden; es werden also Methoden benötigt, die diese Grundwerte verstärken, ihnen genügen und sie zur Gewohnheit machen. Das ist 14

17 das Thema des folgenden Kapitels Prinzipien und Aktivitäten Aufbauend auf den vier Grundwerten definiert XP einige grundlegende Prinzipien: schnelles Feedback, Einfachheit voraussetzen, inkrementelle Änderungen, Akzeptanz von Änderungen, Qualitätsarbeit. Dass qualitativ hochwertiges Feedback wichtig ist, wurde bereits erläutert. Je schneller man also qualitativ hochwertiges Feedback erhält, desto besser die Qualität des Systems (vgl. Kap , Feedback). Indem man jedes Problem wie ein einfach zu lösendes Problem behandelt, vermeidet man eine unangemessen hohe Lösungskomplexität (die durch zu weite Vorausplanung im Softwaredesign entsteht; vgl. Kap , Einfachheit), was viel Zeit spart, die man besser in tatsächlich komplexe Probleme steckt. Die Bedeutung von inkrementellen Änderungen und ihrer Akzeptanz wurde bereits am Beispiel der Kosten als Kontrollvariable (vgl. Kap , Kosten), den moderneren Änderungskostenkurven nach Beck und Bramble (vgl. Kap ) und der Metapher des Autofahrens (vgl. Kap , Feedback) erläutert: entlang des Projektverlaufs ändert sich meist nahezu alles zumindest ein wenig: der Plan, das Design, das Team. Und Qualitätsarbeit ist unabdingbar (vgl. Kap , Qualität). Zusammen mit den vier Grundwerten führen die o.g. Prinzipien zu vier Aktivitäten: Programmieren, Testen, Zuhören, Designen. Programmieren Dass Software nicht ohne Programmieren (code- oder modellorientiert) entsteht, liegt auf der Hand. Programmcode liefert jedoch mehr, als nur die fertige Software. Programmcode dient zum einen als Kommunikationsmittel mit anderen Entwicklern: möchte ein Entwickler seinem Kollegen eine Idee erklären, fällt dies mittels Programmcode wesentlich präziser und i.d.r. schneller aus, als verbal. Dies kann sich so fortsetzen, dass beide Entwickler ihre Ideen präzise über den Programmcode kommunizieren (siehe Kap , Paarprogrammierung) und somit die anfänglich unbestätigte Idee des einen Entwicklers zu effizientem Programmcode wird, mit dem beide Entwickler übereinstimmen. Zum anderen fungiert Programmcode selbst als Indikator: ein erfahrener Programmierer wird an der Effizienz seines Programmcode ab einem bestimmten Zeitpunkt (in Kombination mit Tests und der Paarprogrammierung eher früher, als später) erkennen, ob die intendierte Programmcodestruktur für die zu implementierende Funktionalität wirklich geeignet ist. 15

18 Testen Wie bereits an einigen Stellen erwähnt, ist das Testen von implementierten Lösungen eine sehr wichtige Aktivität, gibt es allen Projektbeteiligten doch bei entsprechend vernünftigen und objektiven Testfällen konkretes Feedback über den aktuellen Zustand des Systems, Daten, die für die weitere Projektdurchführung massgeblich sind; es gibt sogar eine Softwareentwicklungsmethode (vgl. [7]), bei der erst der Testfall spezifiziert und dann der Programmcode geschrieben wird, der zum Bestehen dieses Tests nötig ist. Die Testentwerfer (die Entwickler schreiben Unit-Tests, die Kunden spezifizieren und evtl. schreiben funktionale Tests) haben dabei eine grosse Verantwortung: geht es doch nicht darum, Tests mit Rücksicht auf die Implementierung (i.e. dem Programmcode) zu spezifizieren, sondern darum, alle möglichen Systemschwächen, die man sich vorstellen kann, festzuhalten und zu testen. Tests sind jedoch nicht nur für die Entwicklungszeit vorgesehen, sondern entlang der Lebenszeit der Software; dies macht schon allein daher Sinn, dass die Entwicklungszeit gemessen an der Lebenszeit einer (guten) Software relativ gering ist. Entlang der Lebenszeit einer Software können Jahre nach dem ersten Release Szenarien eintreten, die niemand während der Entwicklungszeit vorhergesehen hat. Daher sind automatisierte Tests nicht nur während der Entwicklung ein Garant dafür, (un)erwartete Fehler zu registrieren. Desweiteren steigt die Zuversicht der Entwickler mit dem durch regelmässig durchgeführte Tests konkreten Feedback: der Entwickler weiss, ob er gute oder schlechte Arbeit geleistet hat. Neben dieser psychologischen Komponente kommt noch der Vorteil, dass der Verbund aus Programmieren und Testen auf regelmässiger Basis die Zeitanforderung für Debugging reduziert. Zuhören Zur Expertise von Entwicklern gehört primär der Systementwurf und das Programmieren. Wenn es jedoch um die zu implementierende Fachlogik geht, liegt das benötigte Wissen in erster Linie beim Kunden, der seine Geschäftsprozesse (und die dabei zum Einsatz kommende Softwarelandschaft) besser kennt. Daher ist es unabdingbar, dass die Entwickler dem Kunden richtig zuhören, gerade wenn es um die Entwicklung von Unit-Tests geht. Gleichzeitig müssen die Entwickler dem Kunden bei der Beschreibung der gewünschten Funktionalitäten im Kontext der bestehenden Geschäftsprozesse auch Feedback darüber geben, welche Funktionalitäten wohl eher einfach zu implementieren sind und welche sich als harte Nüsse erweisen könnten. Auf diese Weise versteht auch der Kunde das zu lösende Problem besser (vor allem aus wirtschaftlicher Sicht hinsichtlich des Projektverlaufs). Damit die Kommunikation strukturiert und präzise abläuft und unnötige Kommunikation vermieden 16

19 wird, wendet XP spezielle Methoden an (dazu später mehr). Designen Gutes Softwaredesign ist ein Muss-Kriterium, sorgt es doch für die Vermeidung von Redundanz, für eine vernünftige Organisation der Programmlogik (Änderungen in einem Teil sollen nicht ungewollte Änderungen in einem anderen Teil bewirken), für die Nähe zwischen Daten und den auf ihnen operierenden Methoden etc. Dabei ist aber auch wieder darauf zu achten, dass der Grundwert der Einfachheit eingehalten wird; ein unnötig hoher Komplexitätsgrad verursacht zuviele Probleme. Gutes Design dient im Kontext von XP dazu, dass der Zyklus aus Programmieren, Testen und Zuhören stets aufrechterhalten werden kann; dies wäre ohne gutes Design nicht möglich, da man irgendwann an eine Stelle käme, an der man das System nicht mehr zum Absolvieren neuer Testfälle verändern könnte, ohne bei bereits bestandenen Testfällen zu versagen. XP soll also Methoden anwenden, die gutes Design fördern und schlechtes Design möglichst vermeiden Die Lösung: zwölf Praktiken XP wendet zur Durchsetzung der vier Grundwerte, der Prinzipien und Aktivitäten (vgl. Kap , ) zwölf Praktiken an, die im folgenden erläutert werden. Im Planungsspiel geht es darum, den gleichberechtigten Dialog zwischen wirtschaftlichen und technischen Belangen bzgl. des Softwareprojekts zu finden. Die wirtschaftlich Verantwortlichen (der Kunde) treffen Entscheidungen bzgl. des Softwareumfangs, der Prioritäten der zu implementierenden Funktionalitäten, der funktionellen Zusammensetzung von Releases ( Wieviele Releases?, Welche Funktionalitäten in welchem Release? etc.) und der Releasetermine. Diese Entscheidungen müssen auf Basis der Gegebenheiten des Kundenunternehmens getroffen werden, da seine Geschäftsfähigkeit mehr oder minder (in Abhängigkeit von Einsatzart, -ort und Grösse der in Auftrag gegebenen Software) durch diese Entscheidungen bestimmt wird. Andererseits können diese Entscheidungen nicht ohne die technischen Details getroffen werden, die die Entwickler bereitstellen: Zeitaufwandsschätzungen, Konsequenzen, detaillierte Planung ( Wann werden in einem Release welche 'Geschichten' zuerst implementiert? ). Die Entwickler müssen beispielsweise besonders riskante Funktionalitäten nach vorne verschieben dürfen, um das Gesamtrisiko des Softwareprojekts zu reduzieren. Es sollten kleine Releases angestrebt werden, damit alle Projektbeteiligten schneller zu wertvollem 17

20 Feedback kommen (vgl. Kap , Zeit und Umfang, Kap , Feedback). Ein Release muss dabei jedoch eigenständig Sinn machen: man sollte ein Release nicht nur seiner Kürze wegen mit unvollständigen Funktionalitäten ausstatten. Ein ideales Zeitfenster für ein Release sollte eher ein bis zwei Monate anstelle von sechs bis zwölf Monate gross sein. Ein XP-Projekt ist durch eine Metapher charakterisiert, die allen Projektbeteiligten das System hinsichtlich seiner Elemente (z.b. Objekte, Akteure etc.) und derer Relationen kommuniziert. Wendet man diese Metapher konsequent und konsistent an, verstehen alle Projektbeteiligten das System und seine Architektur besser, was demnach vor allem die Kommunikation, einen wichtigen Grundwert, verbessert, was wiederum eine wichtige Voraussetzung zur ständigen Verbesserung des Systems und seiner Architektur ist. XP propagiert einfaches Design, das (1) das Bestehen aller Tests, (2) das Vermeiden duplizierter Fachlogik (i.e. nicht-redundante Funktionalitäten) und (3) das Bestätigen aller wichtigen Entwicklerabsichten sicherstellt. Vereinfacht formuliert erreicht man dies, indem man nach Fertigstellung des Designs jedes Designelement entfernt, ohne die Punkte (1) (3) zu verletzen. Die moderneren Änderungskostenkurven nach Kent und Bramble (vgl. Kap ) ermöglichen es, dem Kredo Implement for today, design for tomorrow. (vgl. [1], S. 57) eine Absage zu erteilen. Gutes Testen ist ein absolutes Muss-Kriterium: Unit-Tests erhöhen die Zuversicht der Entwickler für das System, funktionale Tests die des Kunden, Testen im allgemeinem also die Zuversicht aller Projektbeteiligten für das System. Tests an den richtigen Programmstellen (nicht zwangsweise für jede einzelne Methode, sondern primär für Produktionsfunktionen) unterstützen das Refactoring, da Entwickler so relativ schnell herausfinden können, ob sich eine Funktionalität evtl. einfacher bzw. effizienter implementieren lässt. Paarprogrammierung sieht vor, dass zwei Entwickler an einem Rechner sitzen: der Eine kümmert sich um die Implementierung einer Methode, der Andere denkt strategischer im Systemkontext hinsichtlich des aktuell gewählten Wegs, überlegt sich Testfälle, die die Methode evtl. noch nicht bestehen würde und ob es nicht eine Möglichkeit zur Vereinfachung des Systems gibt, so dass die aktuelle Methode überflüssig würde. Dabei sind die Programmierpaare nicht konstant, sondern wechseln sich stetig ab, so dass eine effizientere Wissensverteilung (jeder Entwickler hat bestimmte Erfahrungsgebiete, die dynamisch benötigt werden) erzielt wird. Diese Dynamik setzt aber Programmierstandards voraus, die vom gesamten Entwicklerteam akzeptiert und eingehalten werden müssen. Beim Kollektivbesitz von Programmcode geht es darum, dass jeder Entwickler Codeänderungen auch an nicht von ihm geschriebenen Code vornehmen darf. Kontinuierliche Integration besagt, dass Programmcode nach wenigen Stunden, spätestens aber 18

21 nach einem Arbeitstag, integriert wird. Eine einfache Möglichkeit dafür ist ein dedizierter der Integration dienender Rechner: sobald dieser frei ist, setzt sich ein Programmiererpaar daran, lädt den aktuellen Release, lädt die selbstgemachten Änderungen, sucht nach Kollisionen (siehe Kollektivbesitz), löst diese auf und startet alle Tests (und macht, falls nötig, Änderungen am neuen geänderten Programmcode, bis 100% bestanden sind). Auf diese Weise ist klar geregelt, dass das aktuell am Integrationsrechner sitzende Programmiererpaar im Falle von nicht bestandenen Tests Änderungen machen muss, da vor der Integration ihrer Änderungen definitiv alle Testfälle zu 100% liefen. Falls diese Änderungen nicht dazu führen sollten, dass alle Tests bestanden werden, sollten die Änderungen verworfen und neu begonnen werden, da das aktuelle Programmiererpaar aller Wahrscheinlichkeit nach nicht genug über die bearbeitete Funktionalität gewusst hat. Die 40-Stunden-Woche ist wichtig und sollte im Normfall nicht überschritten werden, da einerseits niemand langfristig 60-Stunden-Wochen aufrechterhalten und gleichzeitig Kreativität, Konzentration und Spass aufrechterhalten kann. Zum anderen sind Überstunden in Folge (einmalig die Geschwindigkeit zu erhöhen ist kein Problem) nicht nur im Rahmen von XP ein klarer Indikator für ein ernsthaftes Projektproblem. Kunde vor Ort beschreibt die Praktik, bei der eine Person, die mit dem zu entwickelnden System nach Fertigstellung arbeiten wird, täglich mit dem Entwicklerteam zusammenarbeitet. Somit steht den Entwicklern ständig ein Ansprechpartner bereit, wenn es Fragen zu beantworten gilt, Unstimmigkeiten bzgl. bestimmter Funktionalitäten gelöst werden und kleinere Prioritäten gesetzt werden müssen. Dabei ist es nicht so, dass der Kunde vor Ort einen kompletten Wertausfall für den Kunden bedeutet: er ist zwar von seinen anderen Kollegen getrennt, wird aber mit Sicherheit einen Teil seiner regulären Arbeit schaffen können, da die Entwickler ihn sicherlich nicht täglich und rund um die Uhr mit Fragen bombardieren werden. Auf diese Weise erhalten die Entwickler bzgl. Programmierentscheidungen sehr schnelles Feedback. Diese zwölf Praktiken sind keine Neuerfindungen, wurden sie doch bereits in der Vergangenheit angewendet, grösstenteils als unbrauchbar empfunden und zugunsten komplizierterer Verfahren mit mehr Overhead verworfen. Im Rahmen von XP machen sie jedoch aus zwei Gründen Sinn: zum einen funktionieren diese Praktiken im Kontext der moderneren Änderungskostenkurven nach Beck bzw. Bramble wesentlich besser, als im Kontext der klassischen Änderungskostenkurve (vgl. Kap ). Zum anderen komplementieren die Praktiken einander: Schwächen einzelner Praktiken werden durch die Stärken anderer ausgeglichen. Die einzelnen Schwächen und die Komplementierung durch andere Praktiken werden im folgenden für jede Praktik erläutert. 19

22 Mit einem einfachen und groben Plan in die Entwicklung zu starten und ständig den Plan den aktuellen Gegebenheiten anzupassen würde zu lange dauern und Unmut beim Kunden auslösen. Wenn jedoch der Kunde mithilfe des gleichberechtigten Dialogs zwischen wirtschaftlichen und technischen Belangen des Planungsspiels auf Basis der Schätzungen und anderweitigen Feedbacks der Entwickler den Projektplan selbst kontinuierlich aktualisiert, auf Basis von kleinen Releases und dem Kunden schnelles Feedback vorliegt und etwaige Planungsfehler sich für maximal ein bis zwei Monate bis zum nächsten Release hin auswirken und das Entwicklerteam mithilfe des Kunden vor Ort sehr schnell und flexibel Änderungen implementieren und Unklarheiten beseitigen kann, ist es wahrscheinlich, dass das Softwareprojekt mit einem initial einfachen Plan, der entlang des Projektverlaufs ständig verfeinert wird, begangen werden kann. Im Rahmen einiger Wochen bis zu maximal zwei Monaten kleine Releases zu liefern, um in wenigen Monaten die Software in den Produktionsmodus zu stellen, könnte schwierig werden, wenn nicht Unterstützung durch das Planungsspiel (wichtigste Funktionalitäten zuerst) gegeben wäre. Die kontinuierliche Integration und das sorgfältige Testen sorgen für Kosten- und Fehlerreduktion, so dass sich kurz vor einem Release nicht plötzlich eine Menge an Integrationsarbeit und Fehlersuche und -behebung anhäuft. Indem einfaches Design für jeden Release ohne Bedenken an zukünftige Releases verwendet wird (die moderne Änderungskostenkurve greift auch hier wieder, ist sie doch ein Kernkriterium für agile Softwareentwicklung), werden ebenfalls Kosten und Programmcodekomplexität gesenkt, was kleiner Releases hinsichtlich Funktionalität und Qualität zugute kommt, mit dem ersten kleinen Release kurz nach Entwicklungsbeginn. Eine Metapher zu Projektbeginn zum partiellen Architekturersatz gerade in der Kommunikation zwischen allen Projektbeteiligten zu machen, kann mangels Details und Daten kaum nützlich sein. Liegt jedoch konkretes Feedback von echtem Programmcode mittels Tests und der kontinuierlichen Integration in Form kleiner Releases vor, ist der Kunde bereit, das Metapher- Konstrukt zur Kommunikation zu verwenden und wird kontinuierlich Refactoring betrieben, um die Praxistauglichkeit der Metapher zu testen (und sie ggfs. anzupassen), erscheint einem die Metapher für Kommunikationszwecke hinsichtlich der System- und Projektarchitektur sehr nützlich. Ein einfaches Design für kurzfristige Projektziele (i.e. für Funktionalitäten des aktuell neuen kleinen Release) könnte ein Bremsklotz für die kontinuierliche Erweiterung des Systems sein. Ist man jedoch an Refactoring gewöhnt und verfügt man über eine klare, alle gewünschten Funktionalitäten hinsichtlich des aktuellen und zukünftiger Releases umfassenden Metapher und gibt einem die Paarprogrammierung Sicherheit darüber, vom Partner bzgl. schlechten Designs 20

23 korrigiert zu werden, hat einfaches Design durchaus Nutzen. Man kann argumentieren, dass das Schreiben von Unit-Tests und funktionaler Tests zu aufwendig ist. Einfaches Design und Paarprogrammierung reduzieren diesen Aufwand jedoch und die Projektmoral sowohl der Entwickler, als auch des Kunden steigt mit der Zuversicht durch Testen. Kontinuierliches Refactoring mag als zu zeitaufwendig und riskant hinsichtlich der Systemstabilität und der Projektkontrolle zu erscheinen, wendet man jedoch den Kollektivbesitz von Programmcode an, reduziert sich der Zeitaufwand. Programmierstandards und Paarprogrammierung unterstützen dies und sorgen für die Aufrechterhaltung der Systemstabilität. Einfaches Design, Testen und kontinuierliche Integration erhöhen Agilität und Flexibilität, die für Refactoring unabdingbar sind. Durch das Einhalten der 40-Stunden-Woche sind die Entwickler ausgeruhter, kreativer und vor allem konzentrierter. Paarprogrammierung birgt zuviel menschliches Konfliktpotenzial, könnte man meinen. Wenn man jedoch bedenkt, dass Programmierstandards engstirnige, unbedeutende und zeitaufwendige Diskussionen bzgl. des jeweils bevorzugten Programmierstils vermeiden, die 40-Stunden-Woche das Risiko für Überarbeitung, schlechter Arbeitsmoral und Laune stark reduziert, beide Entwickler die Tests gemeinsam entwerfen und somit zwei Perspektiven zur Qualitätsverbesserung einbringen, die Kommunikation und somit Designentscheidungen durch die von allen Projektbeteiligten akzeptierte Metapher verbessert werden und ein einfaches Design diese genannten Vorteile insgesamt begünstigt, kann Paarprogrammierung ihr Potenzial entfalten. Zudem begünstigt Paarprogrammierung auch die Kritikakzeptanz jedes Entwicklers. Kollektivbesitz von Programmcode klingt riskant hinsichtlich der Integrationkosten, könnte es doch dazu führen, dass die sprichwörtliche eine Hand des Teams nicht weiss, was die andere tut. Die kontinuierliche Integration reduziert jedoch Programmcodekonflikte, die ständigen Tests (Schreiben und Ausführen) und die Paarprogrammierung reduzieren die Wahrscheinlichkeit, dass durch den kollektiven Zugriff auf den gesamten Programmcode Fehler entstehen. Programmierstandards reduzieren nicht nur die Fehlerwahrscheinlichkeit, sondern vermeiden auch unnötige Programmierstilkonflikte. Kontinuierliche Integration erscheint hinsichtlich des sehr kurzen Zeitintervalls von wenigen Arbeitsstunden unrealistisch. Bedenkt man jedoch, dass durch die Tests recht schnell klar wird, ob die Programmcodeänderungen verwendet werden können oder nicht, dass durch die Paarprogrammierung die Anzahl der möglichen Änderungen halbiert wird (im Gegensatz zur Entwicklung ohne Paarprogrammierung, in der in einem bestimmten Zeitrahmen jeder Entwickler seine Änderungen in das Programm integrieren möchte) und dass durch Refactoring (und der daraus resultierenden Optimierung und Vereinfachung des gesamten Programmcode) das Konflikt- 21

24 und Fehlerpotenzial kontinuierlicher Integration stark reduziert wird, klingt diese Praktik praktikabel. Ein weiteres Kontra-Argument besagt, dass die 40-Stunden-Woche nicht genügend Gewinn bzw. Wert liefert. Dem ist entgegenzuhalten, dass das Planungsspiel den Entwicklern die wichtigsten Aufgaben zuerst liefert und in Kombination mit den Tests die Anzahl böser Überraschungen, die mehr Arbeit bedeuten, als man zuvor angenommen hat, reduziert. Zudem bewirken die zwölf Praktiken insgesamt eine unübertreffbar hohe Entwicklungsgeschwindigkeit schneller geht's nicht. Die Befürchtung, dass der Kunde vor Ort dem Kundenunternehmen schadet, ist unbegründet, bewirkt er doch durch das Schreiben funktionaler Tests und das Treffen kleiner Projektentscheidungen (Beantwortung kurzfristiger Fragen der Entwickler hinsichtlich Programmierentscheidungen) einen enormen Mehrwert für das Projekt und somit sein Unternehmen. Zudem wird er nicht die ganze Zeit mit den o.g. Aufgaben beschäftigt sein und kann somit unter Umständen (in Abhängigkeit von seiner eigentlichen Funktion) teilweise seiner normalen Tätigkeit nachgehen. Dass sich das Entwicklerteam nicht an Programmierstandards hält, ist eine berechtigte Sorge. Dabei muss man jedoch bedenken, dass XP komplett auf Kollaboration aufsetzt und jeden Entwickler dazu motiviert, Teil eines Gewinnerteams zu sein. Zudem wird sich jeder Entwickler spätestens bei der Paarprogrammierung und dem Refactoring an das Einhalten von Programmierstandards gewöhnen. Die folgende Abbildung visualisiert die bisher erläuterten gegenseitigen Wechselbeziehungen der zwölf Praktiken. Abb. 6 Die gegenseitigen Wechselbeziehungen zwischen den zwölf Praktiken 22

25 2.2 Andere Methoden Neben XP gibt es auch andere agile Methoden, doch gilt XP als eine der bekanntesten. Im folgenden sollen nur recht kurz Scrum und Crystal Clear angeschnitten werden. Scrum Scrum dient als Projektmanagement-Framework für agile Projekte: mit jeder Iteration, auch als Sprint (i.d.r. vier Wochen) bezeichnet, soll der grösstmögliche Gewinn erzielt werden. Scrum sieht sich selbst organisierende Entwicklerteams vor, deren Mitglieder auf täglicher Basis durch kurze Meetings ihre Ziele für den Sprint festlegen und aktualisieren bzw. an aktuelle Gegebenheiten anpassen. Die übliche Teamgrösse liegt bei vier bis neun Mitgliedern. Während des täglichen, ca. 15-minütigen Meeting, auch Scrum genannt, beantwortet jeder Entwickler folgende Fragen: Was habe ich seit dem letzten Scrum gemacht? Was plane ich zwischen jetzt und dem nächsten Scrum? Bin ich auf eine Hürde gestossen? Das Team sucht gemeinsam nach einer möglichen Lösung von Hürden und kanalisiert die Hürde zu Mitgliedern, die nach Meinung des Teams am ehesten zur Lösung fähig sind. Dabei gibt es drei Rollen: den Produktbesitzer, den Scrum-Master und das Teammitglied. Dem Produktbesitzer kommt eine ähnliche Rolle zu, wie dem Kunden vor Ort bei XP (vgl. Kap ). Der Scrum-Master soll den Projektfortschritt vereinfachen, das gesamte Team auf die wichtigsten Aufgaben fokussieren und für die Entsorgung der Hürden sorgen. Dabei werden drei Arbeitsrückstandslisten geführt: das Produkt-Backlog, Release-Backlog und Sprint-Backlog. Das Produkt-Backlog enthält alle Systemanforderungen nach absteigender Priorität geordnet, das Release-Backlog teilt jeweils eine Menge von Anforderungen in Releases auf und das Sprint-Backlog enthält die für den aktuellen Sprint zu implementierenden Anforderungen aus dem Produkt-Backlog (das Produkt-Backlog wird dabei von oben nach unten abgearbeitet, die hochprioren Anforderungen kommen also zuerst). Ein weiteres Mittel ist das sogenannte Burndown-Diagramm, das die noch zu implementierenden Anforderungen aus dem Sprint-Backlog enthält und während eines Sprint täglich aktualisiert wird. Am Ende eines Sprint trifft sich das Entwicklerteam mit allen Projektbeteiligten um zu zeigen, welche Aufgaben erledigt wurden und Prioritäten für den nächsten Sprint herauszuarbeiten. 23