Agile Sofwareentwicklung mit XP Lukas Feuz und Marc Bettler Fachhochschule Technik und Informatik CH-2501 Biel, Schweiz feuzl1@bfh.ch bettm1@bfh.ch Abstract: Bei Softwareentwicklungsprojekten sind die Anforderungen an das Endprodukt häufigen Änderungen unterworfen. Da bei Sequentiellen Prozessen wie dem Wasserfallmodell nur sehr schlecht auf diese Änderungen reagiert werden kann, entstehen vielfach erhebliche Probleme. Aus dieser Problematik heraus entstanden die Grundprinzipien der agilen Softwareentwicklung. Diese Prinzipien wurden im sog. agilen Manifest zusammengefasst und sollten die Softwareentwicklung im Allgemeinen verbessern. Schliesslich entstanden agile Softwareentwicklungsprozesse, welche auf dem agilen Manifest aufbauen. XP ist ein solcher agiler Entwicklungsprozess. Bei der Entwicklung mit XP wird bewusst auf aufwändige Dokumentationsarbeit verzichtet, stattdessen werden täglich kurze Meetings abgehalten. Die Produktivitätssteigerung wird vor allem durch mehr Freude an der Arbeit und weiteren psychologischen Effekten erzielt. Zusätzlich wird versucht durch Praktiken wie Pair-Programming die Qualität des Endproduktes zu steigern.
2 Lukas Feuz und Marc Bettler Agile Sofwareentwicklung Das agile Vorgehen in der Softwareentwicklung ist eine Alternative zu den traditionellen Softwareentwicklungsprozessen, wie z. B. das Wasserfallmodell oder dem V-Modell, die immer mehr als zu schwergewichtig, zu dokumentenlastig und zu bürokratisch angesehen werden. Agile Prozesse verfolgen einen anderen Ansatz. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Ziel der agilen Softwareentwicklung ist es, den Softwareentwicklungsprozess zu optimieren. Grundsätzlich soll dies durch die Verschlankung des gesamten Prozesses erfolgen. Dafür rückt die agile Softwareentwicklung die Projektziele, den Kunden, sowie die Werte, Prinzipien und Methoden für die Zielerreichung in den Mittelpunkt. Wichtigstes Ziel im gesamten Prozess ist eine funktionierende Software für den Kunden und die erfolgreiche Integration wechselnder Anforderungen an diese Software. Diesem Ziel ist alles andere untergeordnet, wie eine möglichst detaillierte Planung, vollständige Spezifikationen, umfassende Dokumentationen oder eine ausgereifte, technisch einwandfreie Architektur. Ein agiler Prozess ist sehr kommunikationsintensiv, soll leicht umzusetzen und flexibel anzupassen sein, er soll leichtgewichtig und dynamisch ablaufen. Um mehr über die agile Softwareentwicklung an sich zu erfahren, möchten wir auf die Arbeit von Fabian Chanton und Sven Schumacher über Agile Sofwareentwicklung mit Scrum verweisen.
Agile Sofwareentwicklung mit XP 3 extreme Programming Bestandteile XP besteht aus Werten, Prinzipien und Praktiken. Die Zusammenstellung dieser Bestandteile orientiert sich an Kent Beck. Es existiert keine eindeutige Definition von XP, wobei allerdings die Diskussionen und Ausführungen der Originalverfasser XP am stärksten prägen. Werte XP definiert vier Werte die von zentraler Bedeutung sind: Kommunikation, Einfachheit, Feedback und Mut. Laut XP ist es, ohne stetige Beachtung dieser Werte, nicht möglich erfolgreich Software zu entwickeln. Das Team kommuniziert stetig, um Informationen auszutauschen. Der Prozess der Softwareentwicklung selbst fordert ein hohes Mass an Kommunikation. Ein stetiger Austausch aller Beteiligten, also auch zwischen dem Entwicklungsteam und dem Kunden wird vorausgesetzt. Die Tatsache, dass auch Personen zu Wort kommen, die bei der gerade diskutierten Sache keine Spezialisten sind, bringt mehr Feedback und Verantwortungsgefühl gegenüber dem Produkt mit sich. Stetige Kommunikation mit dem Kunden, Aufnahme seines Feedbacks und Erfüllung seiner Wünsche ist Wichtiger als formale Preisverhandlungen. XP sucht die möglichst einfache und schnelle Lösung von Problemen. Dies wird in erster Linie dadurch erreicht, dass während einer Iteration das Problem den Fokus des gesamten Teams geniesst und so mögliche Fehlerquellen schneller ans Licht kommen. Des Weiteren werden Fehler auch vermieden, wenn stets die einfachste Lösung realisiert wird. Wichtig bei der Kommunikation ist, dass sich jeder zu Wort meldet. Auch Entwickler sollen die Kommunikation offener gestalten und darauf hinweisen, wenn eine Anforderung nicht in einer Iteration umgesetzt werden kann. Mit diesen Kommunikationsmitteln sollen herkömmliche Störfaktoren, wie etwa den natürlichen Konkurrenzkampf innerhalb des Teams, minimiert und die Qualität des Endproduktes gesteigert werden. Prinzipien Die Brücke zwischen den abstrakten Werten und konkret anwendbaren Praktiken bilden die Prinzipien von XP. In der ersten Auflage wurden diese mit den fünf Grundprinzipien deklariert: Unmittelbares Feedback Ein Feedback sollte so schnell wie möglich eingeholt werden. Aus der Lernpsychologie weiss man, dass der zeitliche Abstand zwischen Aktion und
4 Lukas Feuz und Marc Bettler Feedback eine entscheidende Rolle für den Lernerfolg spielt. Je kürzer die Differenz, desto grösser der Lernerfolg. Gleichzeitig wird durch unmittelbares Feedback verhindert, dass unnötig lange in die falsche Richtung gedacht oder gearbeitet wird. Einfachheit anstreben Einfache Lösungen haben etliche Vorteile gegenüber komplizierten Lösungen. Sie sind schneller zu erarbeiten, so dass schneller ein Feedback zurückkommt. Einfache Lösungen sind einfacher zu verstehen und damit leichter zu kommunizieren. Desweiteren sind einfache Lösungen schneller änderbar, wodurch flexibler auf geänderte Gegebenheiten reagiert werden kann. Inkrementelle Veränderungen Auch wenn Einfachheit angestrebt wird, werden Softwaresysteme im Laufe der Entwicklung so komplex, dass Änderungen unerwartete Seiteneffekte verursachen können. Wenn aber immer nur kleine Veränderungen vorgenommen werden, bleiben diese Seiteneffekte überschaubar. Veränderungen wollen Fortschritt bedeutet Veränderung. Nur, wer Veränderungen will, wird mit Fortschritt belohnt. Man muss neue Dinge wagen und Fehlschläge riskieren, immer in dem Bewusstsein, dass man aus Fehlern lernt. Qualitätsarbeit Kein Softwareentwickler programmiert gerne schlechte Software. Softwareentwickler liefern gerne Qualitätsarbeit. Das erhöht die Arbeitszufriedenheit und damit wiederum die Produktivität. In einem Projekt muss daher die Möglichkeit geschaffen werden, Qualitätsarbeit abzuliefern. Allerdings muss klar definiert sein, wer bestimmt, ob eine hohe oder niedrige Qualität vorliegt. Softwareentwickler haben ihre eigenen Qualitätsmassstäbe, welche nicht mit denen der Anwender verwechselt werden dürfen. Letztlich geht es darum, für die Anwender hochqualitative Software zu entwickeln. Unmittelbares Feedback durch die Anwender hilft, möglichst häufig die Gebrauchsqualität bewerten zu lassen und Erfolgserlebnisse zu produzieren. Traditionelle XP-Praktiken Einfaches Design Es soll die einfachste Lösung angestrebt werden. Also diejenige, die genau das Gewünschte oder Geforderte erreicht und nicht mehr. Allgemeine, generische Lösungen oder vorbereitende Massnahmen für spätere Erweiterungen werden bewusst vermieden. Hierbei sind die Akronyme KISS ( Keep it small and simple ) und YAGNI ( You ain t gonna need it ) vorbereitet.
Agile Sofwareentwicklung mit XP 5 Pair-Programming XP setzt auf das Vier-Augen-Prinzip und setzt zwei Programmierer vor einen Computer. Der eine codiert (der Driver), der andere plant und denkt mit (der Partner). Die Rollen werden regelmässig vertauscht und die Partner gewechselt. Diese Methode steigert den Wissenstransfer und fördert bei Anfängern das Lernen von Spezialisten. Zugleich mindert dieses Vorgehen die Gefahr, dass das Projekt abhängig von einem einzelnen ist. Durch ständiges Codereview wird die Qualität des Codes optimiert und Fehler werden schneller gefunden. Testgetriebene Entwicklung Bei der testgetriebenen Entwicklung werden zuerst die Modultests geschrieben und erst dann wird die eigentliche Funktionalität programmiert. Dadurch befasst sich der Entwickler früh mit dem Design und erkennt Fehlerquellen schon bevor sie existieren. Die Tests werden nach jedem Zwischenschritt durchgeführt und liefern Feedback über den Entwicklungsstand. Es wird zwischen Regressionstest und Modultest unterschieden. Während Modultests einzelne Module testen, prüft ein Regressionstest die kollektive Funktionalität aller, also auch von alten, unveränderten Modulen einer der früheren Iterationen. Ebenfalls sind Performancetests üblich, die Leistungs- und Geschwindigkeitsmerkmale gegenüber den geforderten Werten prüfen. Refractoring Ständige Architektur-, Design- und Codeverbesserungen fördert die Qualität des Codes und ebenfalls das frühzeitige Erkennen von Anti-Patterns. XP befürwortet die Existenz von noch nicht perfektem Code. Stattdessen sind alle Teile einem stetigen Review unterworfen und die Behebung von Fehlern wird sofort durchgeführt. Alternativ kann ein Fehler auch als Bug definiert werden, um ihn in einer späteren Iteration zu beheben. Planning Game Hinter dem Begriff Planning Game versteckt sich eine Diskussionsrunde mit Entwicklungsmannschaft und Kunden. Hier werde neue Versionen spezifiziert und der Aufwand deren Umsetzung abgeschätzt. Gemeinschaftliches Code Eigentum Aktivitäten und Aufgaben werden zunächst nicht an Einzelpersonen verteilt, sondern an das ganze Team. Laut Methodik existiert das Bewusstsein und die Verpflichtung nur als Team erfolgreich sein zu können. Pair-Programming und wechselnde Entwicklergruppen sollen entgegenwirken, sodass einzelne Personen Teile als ihr Eigentum betrachten. Fortlaufende Code Integration Das Zusammenführen einzelner Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen. Laut XP wird die Routine immer höher, je öfter Integriert wird. Dies hat zur Folge, dass Fehler früher aufgedeckt werden und die
6 Lukas Feuz und Marc Bettler mit der Integration verbundenen Kosten beinahe auf Null reduziert werden, da die Integration zu einem täglichen Schritt gehört. Kundeneinbeziehung XP versucht den Kunden vollständig in den Entwicklungsprozess zu integrieren und möglichst eng mit einzubeziehen. Der Kunde gibt die Iterationsziele mit einer Auswahl der zu realisierenden User-Stories vor und hat kurz danach die Möglichkeit Akzeptanztests durchzuführen. Story-Cards dienen als Medium, um die kurzen Anwendungsfälle in Form von User-Stories aufzunehmen. Der Kunde muss immer anwesend oder erreichbar sein. Alternativ können anstatt User-Stories und Story- Cards auch CRC-Modelle und CRC-Cards verwendet werden. Keine Überstunden (40 Stundenwoche) Um die Freude an der Arbeit, die Konzentration der Entwickler und vor allem die Qualität des Produkts nicht zu gefährden, werden Überstunden bei XP nicht geduldet. Nachweislich sinkt die Produktivität eines Entwicklers durch Überstunden. Arbeit ausserhalb der regulären Arbeitszeit wird im Einzelfall zwar geduldet, keinesfalls aber besonders entlohnt oder erwartet. Überstunden zeugen normalerweise von Planungsfehlern. Kurze Releasezyklen (Iterationen) Um Fehler zu vermeiden und vor allem regelmässige Feedbacks vom Kunden zu erhalten baut XP auf kurze Iterationen. Eine Iteration wird in XP als eine zeitlich und fachlich in sich abgeschlossene Einheit definiert. Metapher Da in Softwareprojekten Missverständnisse zwischen Kunde und Entwicklungsmannschaft ein häufig gesehenes Problem darstellen, versucht XP mit der Metapher entgegen zu wirken. Das Hauptproblem besteht hier darin, dass der Entwickler Mühe mit der Fachsprache des Kunden hat und umgekehrt. XP sucht also eine inhaltlich ähnliche Alltagsgeschichte, eine sog. Metapher, die von beiden Seiten verstanden wird. Ein zusätzliches Glossar kann dieses Problem beinahe beseitigen. Coding Standards Das Team hält sich bei der Programmierarbeit an Standards, die in einer Programming Guideline definiert werden. Es geht um die Prinzipien, wie Variable, Klassen und Methoden benannt werden und um allgemeine Coding Standards. Laut XP ist es nur mit solchen Standards möglich, dass jeder Programmierer in allen Bereichen der zu entwickelnden Software arbeiten kann.
Agile Sofwareentwicklung mit XP 7 extreme Programming, die zweite Auflage Kent Beck hat Ende 2004 die zweite Auflage des XP Manifests extreme Programming explained veröffentlicht. Während die XP Werte nur mit dem Wert Respekt ergänzt wurden, sind die Prinzipien und die Praktiken deutlich verändert worden. Für die Änderungen gibt es vier Ursachen: Präzisierungen: So ist nicht mehr von kurzen Releasezyklen die Rede, sondern die Zeiträume für Zyklen werden genau definiert (Wochenzyklus und Quartalszyklus) Vereinfachungen: Die XP Technik der Metapher haben nur wenige verstanden, geschweige denn angewendet. Daher gibt es die Metapher nicht mehr als eigenständige Technik. Erfahrungen: Es ist deutlich geworden, dass XP keinen Freiraum für Weiterbildung und Reflexionen lässt. Es haben sich dazu einige XP Erweiterungen herausgebildet, die sich nun in der Technik Freiraum wiederfinden. Neue Herausforderungen: Auch für die Teams, die XP bereits erfolgreich und komplett einsetzen, hat sich Kent Beck einige neue Herausforderungen ausgedacht. Um die zweite Auflage von XP zu verstehen, ist ein grundlegendes Verständnis von XP vorausgesetzt. Wer XP bereits kennt, muss nicht komplett umlernen, um die XP Neuerungen anwenden zu können. Die grundsätzlichen Ideen sind gleich geblieben. Sie kommen teilweise nur in anderen Verpackungen daher. Bestandteile Werte Die vier Werte Kommunikation, Feedback, Einfachheit, und Mut wurden um den Wert Respekt ergänzt. Jeder Projektbeteiligte respektiert die anderen Projektbeteiligten. Keiner ist mehr oder weniger wert als andere. Ausserdem verweist Kent Beck explizit darauf, dass die fünf Werte um projektspezifische Werte ergänzt werden können. Prinzipien Die Prinzipien wurden fast vollständig neu formuliert. Es gibt nun 14 Prinzipien, die eine Brücke bilden zwischen den abstrakten Werten und den konkret anwendbaren Praktiken. Diese Prinzipien sollten immer Berücksichtigung finden.
8 Lukas Feuz und Marc Bettler Menschlichkeit Softwareentwicklung ist eine menschliche Aktivität, bei der die sozialen Beziehungen der Projektbeteiligten eine entscheidende Rolle spielen. Die Projektorganisation darf nicht nur auf geschäftlichen Interessen ausgerichtet sein. Die geschäftlichen Interessen müssen ausbalanciert werden mit den Bedürfnissen der Projektmitglieder. Wirtschaftlichkeit Softwareprojekte müssen wirtschaftlich sein, indem sie mehr Geld einbringen, als sie kosten, die Kundenbindung erhöhen und neue Marktsegmente erschliessen. Softwareprojekte, die sich nicht rechnen, sind niemals ein Erfolg. Beidseitiger Vorteil Kent Beck nennt den gegenseitigen Vorteil als das wichtigste Prinzip in XP. Jede Aktion soll jedem Betroffenen einen Vorteil verschaffen (Win-Win-Situation). Es ist leicht, Probleme zu lösen, wenn dabei Nachteile für die Betroffenen akzeptiert werden. Allerdings beeinträchtigen solche Lösungen die Arbeitsleistung der Betroffenen. Selbstgleichheit Lösungen, die an einer Stelle funktionieren, lassen sich häufig auf andere Kontexte übertragen, auch auf ganz andere Grössenordnungen. Verbesserung Nichts ist perfekt. Alles kann und muss ständig verbessert werden. Insbesondere sollte man sich nicht dadurch von der Arbeit abhalten lassen, dass man nicht weiss, wie die Lösung aussieht. Durch das Umsetzen von nicht perfekten Lösungen lernt man viel, und dadurch kommt ein kontinuierlicher Verbesserungsprozess in Gang. Vielfältigkeit Menschen sind sehr verschieden. Die Vielfältigkeit ist manchmal unangenehm, aber sie birgt auch grosse Potenziale. XP anerkennt die Vielfältigkeit der Projektmitglieder und versucht, diese in bessere Lösungen einfliessen zu lassen. Wenn es zwei unterschiedliche Entwurfsvorschläge gibt, ist das kein Problem, sondern eine Chance. Reflexion Gute Teams machen nicht nur gute Arbeit, sie reflektieren auch über ihre Arbeit. Sie denken darüber nach, wie und warum sie ihre Arbeit machen, und können so ihre Lösungen verbessern.
Agile Sofwareentwicklung mit XP 9 Fluss Die Aktivitäten in einem XP Projekt liefern einen ständigen Fluss an Software, die immer ein Stückchen besser wird. Dieser Fluss steht im Gegensatz zu Phasenmodellen, in denen grosse Ergebnisbrocken in langen Zeitabständen geliefert werden. Gelegenheiten wahrnehmen Klassisch werden Probleme gelöst, um zu überleben. In XP werden Probleme als Chancen für Veränderung aufgefasst. Redundanzen Es soll keine Redundanzen im Quellcode geben, aber im Entwicklungsprozess. Relevante Probleme sollen nicht nur durch einen Mechanismus überwacht werden, sondern durch mehrere. So ist sichergestellt, dass ein Problem auch dann gelöst wird, wenn einzelne Mechanismen ausfallen. In XP wird beispielsweise das Problem von Programmfehlern durch Komponententests, Akzeptanztests und Programmieren in Paaren minimiert. Fehlschläge hinnehmen Fehlschläge lassen sich nicht vermeiden und sind sogar hilfreich, wenn man etwas daraus lernt. Insbesondere ist es besser, etwas auszuprobieren, als lange Diskussionen zu führen. Qualität Man kann die Qualität nicht senken, um Kosten zu sparen oder einen frühen Termin zu halten. Qualitätsarbeit ist die Voraussetzung dafür, stolz auf seine Arbeit zu sein. Nur Entwickler, die stolz auf ihre Arbeit sind, sind mit vollem Engagement dabei. Kleine Schritte Jede Veränderung wird in kleinen Schritten vorgenommen, um Risiken zu reduzieren. Die Schritte erfolgen in schneller Folge, so dass trotzdem eine hohe Entwicklungsgeschwindigkeit resultiert. Akzeptierte Verantwortung Verantwortung kann nicht zugewiesen werden, sie muss akzeptiert werden. Zusammen mit der Verantwortung kommt die Autorität. Ein Entwickler, der sich eine User Story nimmt, akzeptiert die Verantwortung für das Design, die Programmierung und das Testen dieser Story. Damit hat er die Autorität, über das Design für die Story zu entscheiden.
10 Lukas Feuz und Marc Bettler Praktiken In der zweiten Auflage von XP unterscheidet Kent Beck zwischen Primärpraktiken und Folgepraktiken. Die Folgepraktiken setzen die Primärpraktiken voraus. Der Einsatz der Folgepraktiken, ohne dass die Primärpraktiken funktionieren, kann sogar gefährlich sein. Primärpraktiken Beieinander sitzen Alle Projektbeteiligten sollen möglichst nah beieinander sitzen, idealerweise in einem Raum. Das erleichtert die direkte Kommunikation und reduziert damit Reibungsverluste. Komplettes Team Das XP-Team soll alle Qualifikationen enthalten, die für das Projekt erforderlich sind. Damit sind technische aber auch fachliche Qualifikationen gemeint. Dadurch kann das Team schnell voranschreiten, ohne auf die Verfügbarkeit von externen Ressourcen warten zu müssen. Informative Arbeitsumgebung Die Arbeitsumgebung des Teams soll über den aktuellen Projektstand informieren. Das betrifft die noch offenen Aufgaben und den Zustand des Systems. Pair-Programming Das Programmieren in Paaren ist schon immer eine der auffälligsten XP-Techniken gewesen. Sie bleibt unverändert in der zweiten Auflage von Kent Beck. Stories Die Anforderungen werden in einem XP-Projekt als informelle Geschichten (Stories) aufgeschrieben. Während XP in der ersten Auflage forderte, dass die Anforderungen immer vom Kunden zu schreiben seien, lässt XP jetzt mehr Flexibilität zu. Zunächst ist nur wichtig, dass Stories existieren. Dass diese von einem Kunden stammen sollten, wird erst mit der Folgetechnik "Echte Kundenbeteiligung" gefordert. Zyklen Eine Iteration dauert eine Woche, ein Release ein Quartal (3 Monate).
Agile Sofwareentwicklung mit XP 11 Freiraum Entwickler brauchen zwischendurch Zeit, um sich mit den Neuerungen ausserhalb des Projekts vertraut zu machen. Ansonsten werden sie schnell vom technologischen Geschehen abgehängt. Sie sind dann im nächsten Projekt weniger gut einsetzbar. Zehn-Minuten-Build Es darf maximal zehn Minuten dauern, das Projekt zu übersetzen und die Tests auszuführen. Diese Forderung mag in grossen Projekten unerfüllbar scheinen. Mit einer geschickten Aufteilung in Komponenten kann man der Forderung aber auch in grossen Projekten sehr nahe kommen. Dann wendet man die Forderung auf jede Komponente an. Das Zusammenbauen der Gesamtanwendung kann dann wieder länger dauern. Kontinuierliche Integration Diese Technik bleibt unverändert. Testgetriebene Entwicklung Das Testen lag immer schon im Zentrum von XP. Kent Beck präzisiert diese Technik noch. Tests werden vor dem zu testenden Code geschrieben, und die Tests müssen automatisiert ausführbar sein. Inkrementeller Entwurf Der Softwareentwurf soll inkrementell erfolgen, also schrittweise entlang der Anforderungen. Der Entwurf soll immer nur die nächsten, konkret bekannten Anforderungen berücksichtigen. Folgepraktiken Echte Kundenbeteiligung Wenn das Team die Arbeit der Stories und den inkrementellen Entwurf beherrscht, sollte ein echter Kunde integriert werden. Team-Kontinuität Es ist in vielen Organisationen gängige Praxis, dass Entwickler parallel in mehreren Projekten arbeiten. Das erhöht die Kommunikationsaufwände, und die Entwickler müssen häufig einen Kontextwechsel vollziehen. Beides reduziert ihre Produktivität deutlich. Alle Projektmitglieder sollen 100% ihrer Arbeitszeit im Projekt verbringen. Die personelle Fluktuation im Projekt sollte minimiert werden. Häufiger Personalwechsel bringt hohen Kommunikations- und Einarbeitungsaufwand mit sich.
12 Lukas Feuz und Marc Bettler Schrumpfende Teams Hier geht es darum, die Produktivität von XP-Projekten zu erhöhen mit dem Ziel, einen Entwickler freizusetzen. Dieser Entwickler kann dann in einem anderen Team mitarbeiten und seine Erfahrungen aus dem XP-Projekt in das andere Projekt transferieren. Ursprungsursachen-Analyse Dabei geht man einem Problem systematisch auf den Grund, um die Ursache des Problems zu identifizieren und zu beseitigen. Die Ursprungsursachen-Analyse kann man nur durchführen, wenn man sehr wenige Probleme hat oder nur ausgesuchte Probleme analysiert. Gemeinsamer Code Jeder Entwickler darf den kompletten Quellcode verändern. Diese Technik ist eine Folgetechnik, weil sie durchaus Gefahren birgt. Wenn sich das Team nicht gemeinsam verantwortlich fühlt, führt gemeinsamer Code schnell zur Verwilderung der Systemstruktur. Code und Tests Ausser dem Quellcode und den Tests werden keine weiteren Dokumentationen erstellt oder gepflegt. Der Code soll seinen Zweck kommunizieren. Was dann noch an Dokumentation fehlt, wird durch den Test bereitgestellt. Eine Codebasis Es gibt nur eine Codebasis. Branches sind nur kurzzeitig erlaubt. Auch diese Technik birgt Gefahren. Nur wenn die Fehlerzahl sehr gering ist, kann man auf Branches verzichten. Bei hoher Fehlerzahl auf Branches zu verzichten, führt zu instabilen Releases. Tägliche Ausbreitung Der aktuelle Systemstand soll täglich an die Anwender verteilt werden. Diese Technik muss bei der Projektplanung berücksichtigt werden. Wenn die Anwender jeden Tag ein System vorfinden, das ganz anders zu benutzen ist als das vom Vortag, werden sie schnell auf die Barrikaden gehen. Neue Anforderungen müssen so eingeplant werden, dass die Anwender nicht bei ihrer Arbeit behindert werden. Vertrag mit verhandelbarem Umfang Es wird kein klassischer Festpreisvertrag vereinbart, sondern ein Vertrag mit festem Budget und verhandelbarem Funktionsumfang.
Agile Sofwareentwicklung mit XP 13 Bezahlung pro Benutzung Der Kunde zahlt das System nicht pro Release, sondern zahlt Funktionen pro Benutzung. Dadurch ziehen Kunde und Softwareentwickler bei der Entwicklung an einem Strang. Der Kunde kann seinen Geschäftswert an Einzelfunktionen binden. Eine häufige Benutzung der Funktionen generiert für den Kunden hohen Geschäftswert. Gleichzeitig werden Umsätze für die Softwareentwickler generiert. Die Entwickler versuchen also, das System so zu verbessern, dass die geschäftswertgenerierenden Funktionen häufiger verwendet werden. Rollen Damit das Funktionsprinzip von XP auch problemlos funktioniert müssen bestimmte Rollen im Team besetzt sein. Die 4 wichtigsten sind hier sehr kurz beschrieben: Der Programmierer Im Gegensatz zu herkömmlichen Softwareentwicklungsprogrammen besteht seine Arbeit nicht nur darin, dem Computer zu verstehen zu geben, was er will, sondern muss auch mit anderen kommunizieren können. Normalerweise sind Programmierfreaks nicht sehr kommunikativ, beim Extreme Programming ist die Kommunikation nur schon aufgrund des Programmierens in Paaren das A und O. Der Kunde Ein Kunde muss die UserStorys schreiben und bei Fragen der Programmierer gewisse Geschäftsentscheidungen treffen. Er muss genau wissen was für ihn oberste Priorität hat, aber, und das ist fast wichtiger, er muss auch Meinungen der Programmierer annehmen können. Dies bedeutet bei einem engen Terminplan, nachzugeben und unwichtige Systemanforderungen nach hinten verschieben zu können. Der Kunde muss ausserdem in der Lage sein, je nach dem auch mit Hilfe des Teams, Funktionstests zu schreiben. Bei einem fehlenden Tester wird diese Rolle dem Kunden zugeschrieben. Der Terminmanager Der Terminmanager verhilft auf Grund seiner Erfahrung zu genauen Aufwandabschätzungen. Es liegt ausserdem an ihm zu entscheiden, ob das Team den Liefertermin einhalten kann, oder ob etwas geändert werden sollte. Er führt Protokoll über die Funktionstests und soll die Teammitglieder hin und wieder daran erinnern, wie lange sie bereits an einer Aufgabe arbeiten. Der Coach Der Coach ist das Mitglied mit der meisten Erfahrung im Team. Es liegt an ihm dafür zu sorgen, dass das Team nicht eine falsche Richtung einschlägt. Ein guter Coach zeigt dem Team allerdings nicht, was es falsch gemacht hat, sondern bringt das Team darauf, es selbst zu sehen. Es ist nicht unbedingt notwendig, dass der Coach ein
14 Lukas Feuz und Marc Bettler Technikfreak ist, soziales Verständnis ist als Coach wichtiger. Je reifer das Team, umso weniger Arbeit hat ein Coach. Anwendungsszenario Nachdem die für XP relevanten Begriffe geklärt sind und ein Überblick über die Prinzipien und Praktiken gegeben wurde, wird in diesem Abschnitt das Vorgehen von XP anhand eines Anwendungsbeispiels verdeutlicht. Zu Begin des Projekts treffen sich Programmierer, der Coach, der Terminmanager und der Kunde zu einem ersten Planning Meeting. Hier werden die User Storys erstellt und es wird im Kollektiv entschieden, welche in der nächsten Iteration implementiert werden sollen. Bei der Entscheidung werden Faktoren wie die Wichtigkeit, Aufwand und andere Prioritäten miteinbezogen. Sobald klar ist, was zu tun ist, werden die Programmierer in Zweierteams aufgeteilt. Nun beginnt die eigentliche Arbeit. Wichtig ist hier, dass sich jedes Teammitglied an die Prinzipien und Praktiken von XP hält. Der Coach behält sich das Recht vor, Teammitglieder auf Verstosse hinzuweisen. Jeden Tag trifft sich die gesamte Entwicklermannschaft zu einem Daily Meeting. Ein solches dauert ca. 15Min. und soll helfen Probleme zu lösen, Absprachen mit dem Kunden zu treffen und natürlich den aktuellen Projektstand abzuklären. Je nach Vorgabe werden hier auch gleich die Programmiererteams, die ja nach XP möglichst oft ändern, gewechselt. Ist eine Iteration abgeschlossen (normalerweise 1 Monat), so wird ein Build erstellt und die Entwicklermannschaft trifft sich wieder zu einem Planning Meeting. Die Userstorys werden ausgewählt und der Entwicklungsprozess schreitet wie oben voran. Sind keine unbearbeiteten Userstorys vorhanden, so gilt das Projekt als abgeschlossen. Für die erfolgreiche Entwicklung steht im Vordergrund, dass die von XP definierten Werte, Praktiken und Prinzipien stets eingehalten werden. So müssen Interventionen durch den Coach, den Kunden oder den Terminplaner immer in den dafür vorgesehenen Meetings vollzogen werden. Laut XP ist die Wirkung einer Intervention so am grössten. Wann XP nicht eingesetzt werden kann XP eignet sich nicht für die folgenden Fälle in einer Unternehmenskultur, bei der die Teams genaue Vorgaben zum Vorgehensmodell bekommen, z.b. wenn zuerst eine ausführliche Spezifikation erstellt werden muss wenn ein zu hoher Erfolgsdruck herrscht, oder nicht erfüllbare Aufgaben gestellt werden bei Teams mit mehr als 10 Mitgliedern wenn Technologien im Einsatz sind, die die flache Kostenkurve für spätere Änderungen nicht ermöglichen, z.b. Entwicklung von Hardware wenn Build und Test nicht innerhalb kurzer Zeit durchgeführt werden können, z.b. bei langen Compilierzeiten
Agile Sofwareentwicklung mit XP 15 falls kein Kunde vor Ort zur Verfügung steht wenn die räumlichen Gegebenheiten ungünstig sind, z.b. bei vielen kleinen weit voneinander entfernten Räumen Fazit XP stellt ein Software-Entwicklungsprozess dar, welcher sich auf einfachen, klaren Prinzipien, Methoden und Werten abstützt. Im Vordergrund stehen Prinzipien und Methoden für die Zielerreichung in den Mittelpunkt. Wichtigstes Ziel im gesamten Prozess ist eine funktionierende Software für den Kunden und die erfolgreiche Integration wechselnder Anforderungen an diese Software. In der zweiten Auflage vom 2004 hat Kent Beck die Prinzipien und Methoden stark neuen Erkenntnissen angepasst. XP mit einigen Anpassungen könnte sich gut für studentische Projekte eignen.
16 Lukas Feuz und Marc Bettler Glossar Akzeptanztest Ein Abnahmetest, Akzeptanztest oder auch User Acceptance Test (UAT) ist ein Test der gelieferten Software durch den Kunden. Oft sind Akzeptanztests Voraussetzung für die Rechnungsstellung. Dieser Test kann bereits auf der Produktivumgebung mit Echtdaten durchgeführt werden. Bei einem solchen Test wird das Blackbox Verfahren angewendet, d. h. der Kunde betrachtet nicht den Code der Software, sondern nur das Verhalten der Software bei spezifizierten Handlungen (Eingaben des Benutzers, Grenzwerte bei der Datenerfassung, etc.). Eine Abnahme kann aber auch aus einem Review der Testprotokolle des Systemtests bestehen. Anti-Pattern Ein Anti-Pattern bezeichnet in der Softwareentwicklung ein häufig anzutreffender schlechter Lösungsansatz eines Problems. Es ist das Gegenstück zum Entwurfsmuster (Pattern). Integrationstest Integrationstest bzw. Interaktionstests testet die Zusammenarbeit voneinander abhängiger Komponenten. Komponententest Der Komponententest, Modultest oder Unit Test ist ein Test auf der tiefsten Ebene. Dabei werden einzelne Komponenten auf korrekte Funktionalität getestet. Häufig wird der Modultest durch den Softwareentwickler durchgeführt. Die Testobjekte sind Module, Units oder Klassen. Systemtest Der Systemtest ist die Testphase, bei der das gesamte System gegen die gesamten Anforderungen (funktionale und nicht funktionale Anforderungen) getestet wird. gewöhnlicherweise findet der Test auf einer Testumgebung statt und wird mit Testdaten durchgeführt. In der Regel wird der Systemtest durch die realisierende Organisation durchgeführt. User Story Eine User Story ist eine in Alltagssprache formulierte Softwareanforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze.
Agile Sofwareentwicklung mit XP 17 Quellennachweis extreme Programming, 2., überarbeitete und erweiterte Auflage von Henning Wolf, Stefan Roock und Martin Lippert http://www.wikipedia.org http://www.extremeprogramming.org/ http://www.frankwestphal.de/extremeprogramming.html