Extreme Programming Agilität in der Softwareentwicklung

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Extreme Programming Agilität in der Softwareentwicklung im Rahmen des Seminars Software Management Jan Ernsting Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Susanne Gruttmann Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Motivation zur agilen Softwareentwicklung 1 2 Agilität und Modelle der Softwareentwicklung Agilität Wasserfall-Modell Extreme Programming Ausschnitt der XP-Techniken Programmieren in Paaren Testen Refactoring Einfaches Design Überblick der Abhängigkeiten Rahmenbedingungen für XP Management-Strategien im XP Coaching Planung XP als Evolutionstreiber 21 Literaturverzeichnis 22 i

3 Kapitel 1: Motivation zur agilen Softwareentwicklung 1 Motivation zur agilen Softwareentwicklung Das Verhältnis von Endanwendern und Entwicklern ist oft sehr angespannt. Falsch umgesetzte Anforderungen oder Mängel in Anwendungen sind nur ein Teil der Gründe für die Anspannung der beiden Gruppen. Das traditionelle Entwicklungsmodell weiß damit nur schwerlich umzugehen, da ein Pflichtenheft typischerweise den Umfang eines Systems festlegt und nach der Interpretation des Entwicklers implementiert wird. Zum Ende der Anwendungsentwicklung in diesem Umfeld werden dann häufig noch die Testaktivitäten verkürzt oder unter extremen Zeitdruck ausgeführt, sodass Mängel unter Umständen erst am Arbeitsplatz des Anwenders ersichtlich werden. Statt eine Punktladung zum Ende eines Projektes zu erwarten, sind Feedback- Mechanismen während der Entwicklung sinnvoll, die den Anwender mit einspannen, um Anforderungen optimal umzusetzen, sodass die Akzeptanz des Systems maximiert werden kann und den Anwender bei seiner Arbeit bestmöglich unterstützt. Dadurch kann das Verhältnis der Endanwender und Entwickler entspannt werden und bildet eine Grundlage, um gegenseitiges Misstrauen abzubauen und in wertvolles Vertrauen umzuwandeln, das bspw. langwierige Vertragsgespräche wie ein Relikt vergangener Zeiten wirken lässt. Das Prozessmodell des Extreme Programming (Abk. XP) bildet einen agilen Ansatz zur Softwareentwicklung. Es beinhaltet unter anderem die angesprochenen Feedback-Zyklen, aber auch Praktiken, die auf die Maximierung der Anwendungs- Qualität abzielen. So ist XP geeignet, um komplexere Systeme für Anwender und Kunden zu entwickeln und dabei die Kunden-Anforderungen nach bestem Vermögen umzusetzen. Um im Rahmen dieser Seminararbeit aufzuzeigen, wie Extreme Programming den Entwicklungs-Prozess stärken kann, werden zunächst grundlegende Strategieziele der Softwareentwicklung aufgezeigt. Daraufhin wird Agilität sowohl im Betriebswirtschaftlichen als auch im Speziellen also der Softwareentwicklung vorgestellt und erläutert. Als verbreitetes Modell wird dann das Wasserfall-Modell als Referenz positioniert. Ausgehend von dem zweiten Kapitel wird Extreme Programming in der ersten Version kurz umschrieben, um dann im Detail darauf einzugehen, wie XP-Praktiken dazu beitragen die marginalen Aufwände in der Softwareentwicklung zu stabilisieren. Letztlich werden Schwierigkeiten, in Bezug auf die Abhängigkeiten der Techniken untereinander, skizziert und Extreme Programming spezifische Management- Strategien vorgestellt. 1

4 Kapitel 2: Agilität und Modelle der Softwareentwicklung 2 Agilität und Modelle der Softwareentwicklung Das Software Management stellt einen wesentlichen Erfolgsfaktor bei der Erstellung einer Anwendung dar. Grady unterscheidet drei Management-Strategien, die er als wichtig hervorhebt [Gr92, S. 22]; in Ahnlehnung an Grady hat Balzert die Ziele dieser primären Strategien wie folgt aufgelistet [Ba98, S. 4]: Maximierung der Kundenzufriedenheit, Minimierung des Aufwands und der Zeit der Software-Erstellung, Minimierung von Fehlern. Ein Unternehmen kann sich je nach Umweltsituation entscheiden, ihre Entwicklung stärker nach einer Strategie als nach einer anderen auszurichten. Veranschaulichend kann die Strategieausrichtung einer Entwicklung in einem gleichseitigen Dreieck dargestellt werden. Die einzelnen Strategien bilden zu diesem Zwecke die Ecken. Abbildung 1: Teufelsquadrat [Sn05, S. 38] Das Teufelsquadrat nach Sneed bildet die vier üblichen Projektparameter, Qualität, Quantität, Aufwand und Projektdauer, auf die Ecken eines Quadrates wie in Abbildung 1 ab. Unter dem Begriff der Quantität wird der Umfang eines Systems verstanden. Der Aufwand repräsentiert die Ressourcen, die zum Einsatz kommen. Die Projektdauer und die Qualität bedürfen keiner weiteren Erklärung. Der grau, schattierte Bereich ist in der Flächengröße fixiert und drückt die Produktivität aus, die pro Zeiteinheit von einem Projektmiglied erbracht werden kann. Zwei Parameter können optimiert werden, die jeweils anderen beiden passen sich entsprechend an, sodass die Größe der Produktivitätsfläche unverändert bleibt, nicht jedoch seine Form [Sn05, S. 38f.]. 2

5 Kapitel 2: Agilität und Modelle der Softwareentwicklung 2.1 Agilität In der Betriebswirtschaftslehre ist Agilität als ein Erfolgsfaktor einer Organisation bestimmt. Eine Organisation wird als agil definiert, wenn sie adaptiv, aktiv und flexibel ist sowie mit der Unsicherheit ihrer Umwelt umgehen kann und wandlungsfähig ist. In Zeiten schnelllebiger Märkte und kurzer Produktzyklen ist es wichtig für Unternehmen Chancen und Risiken zu erkennen und sie bewusst wahrzunehmen [DK08, S. 40]. Zur Agilität in der Softwareentwicklung hat die Agile Alliance spezifischer 17 Personen, die agile Software-Praktiken beeinflusst haben ein Manifest verfasst. In dem Manifest werden Werte 1 gegeneinander abgewogen, die einen agilen Entwicklungsprozess prägen und wurden folgendermaßen verfasst [BB01]: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Der einleitende Satz hebt den agilen Prozess als Lernprozess hervor. Durch das Ausführen von agilen Prozessen und dem Leisten von Hilfestellungen wird der Lerneffekt gesteigert. Werden die vorgestellten Gewichtungen und die von Grady identifizierten Management-Strategien gegenüber gestellt, wird ersichtlich, dass ein agiler Prozess sich mindestens zwischen der Maximierung der Kundenzufriedenheit und der Minimierung von Fehlern einordnen lässt. Schließlich setzt Working Software bzw. funktionierende Software voraus, dass ein System eine minimale Anzahl an Fehler enthält. Dies bedeutet nicht, dass eine verständliche Dokumentation des Systems außer Acht gelassen werden kann, ihr jedoch im Zweifelsfall weniger Gewicht beigemessen wird [Ec04, S. 15]. Die Kundenzufriedenheit wird durch die Zusammenarbeit mit dem Kunden und das Reagieren auf Veränderungen maximiert, da eine Unternehmung gemeinsam mit dem Kunden dessen Wünsche und wahrscheinlich ändernde Anforderungen bestmöglich umsetzen kann. 1 Auf Basis der agilen Werte wurden 12 Prinzipien abgeleitet, die in einem agilen Prozess bedacht werden sollten. Sie sind über die Webseite des Manifestes abrufbar. 3

6 Kapitel 2: Agilität und Modelle der Softwareentwicklung Will ein Projekt ein agiles Prozessmodell anwenden, stellt bspw. XP oder Scrum einen Ausgangspunkt für ihr Vorgehen dar [Ec04, S. 13]. Ein agiler Prozess kann in seiner Rohform die Erwartungen und Wünsche eines Teams nicht komplett erfüllen und befriedigen, weil jedes Team durch seine Mitglieder sehr unterschiedlich geprägt ist. Aus diesem Grund bietet die Retrospektive die Möglichkeit ein Prozessmodell an die örtlichen Gegebenheiten anzupassen. Während der Retrospektive, die entweder nach Ende oder Abbruch einer Iteration stattfindet, wird der vorhandene Prozess auf zwei Ebenen hinterfragt [Ec04, S. 13]. Die Erste betrachtet den Stand bzw. den Status des Projektes, wobei auch auf Aspekte eingegangen wird, die den Fortschritt des Projektes behindern oder verlangsamen. Eine Frage, die sich ein Team auf der ersten Ebene stellen kann, wäre die, ob alle notwendigen Refactorings durchgeführt wurden. Auf der Zweiten, der Metaebene, das Prozessmodell kritisch hinterfragt. Bspw. kann ein Team die Überlegung anstellen, die Planung der Iterationen durch das sogenannte Schätzpoker 2 zu unterstützen, um so mehr Struktur in ihre Schätzungen und Planungen einzubringen. An dieser Stelle werden Schwierigkeiten mit größeren Teams ersichtlich, da es aufgrund der Vielzahl an Bedürfnissen der individuellen Entwicklern schwieriger wird, diese zu befriedigen. Würden viele Änderungen als Ergebnis einer Retrospektive am Prozessmodell oder am Prozess vorgenommen, um auf die Wünsche und Vorschläge der vielen Entwickler einzugehen, ist das Risiko groß, dass der Prozess keine inkrementelle Entwicklung durchläuft. Viele oder große Änderungen am Prozess behindern das Nachvollziehen des Erfolgs der Modifikationen. 2.2 Wasserfall-Modell Um die Vor- und Nachteile agiler Prozessmodelle greifbarer zu machen, wird als Referenzmodell das Wasserfall-Modell der Software-Entwicklung vorgestellt und zu Vergleichszwecken herangezogen. In der Praxis hat dieses Modell eine Zeit lang, unter anderem aufgrund seines einfachen und verständlichen Aufbaus, Verwendung gefunden [Ba98, S. 100] und wird auch aktuell eingesetzt. Das Wasserfall-Modell sieht vor, dass ein System in einem Prozess mit bis zu sieben aufeinander folgenden Stufen entwickelt wird, wie es in Abbildung 2 dargestellt ist. Die Anzahl der Stufen ist nicht fixiert ist und variiert je nach Definition des Modells zwischen fünf und sieben. Dabei sind Rückkopplungen zur jeweils vorigen Stufe bzw. Aktivität vorgesehen, um teure Überarbeitungen über mehrere Stufen 2 Im Abschnitt 4.2 wird diese Art der Aufwandsabschätzung erläutert. 4

7 Kapitel 2: Agilität und Modelle der Softwareentwicklung Abbildung 2: Wasserfall-Modell [Ba98, S. 99] hinweg zu vermeiden [Ba98, S. 99]. Damit die Kopplungen zwischen den einzelnen Aktivitäten bzw. Stufen funktionieren können, laufen die einzelnen Aktivitäten sequenziell ab. Am Ende jeder Stufe steht ein fertiges Dokument, bspw. das Pflichtenheft als Ergebnis der Phase Software-Anforderungen; das Prozessmodell ist dokumenten-getrieben. Wird ein System nach dem Wasserfall-Modell entwickelt, so werden in der ersten Stufe sämtliche Systemanforderungen des Benutzers ermittelt und in der zweiten Stufe als Softwareanforderungen formuliert. Nach der Analyse ist in den darauffolgenden Aktivitäten keine Benutzerbeteiligung vorgesehen. Dennoch wirken sich manche Eigenschaften des Modells nachteilig aus. Der Dokumenten-Trieb des Wasserfalls führt unter Umständen dazu, dass die Dokumentation wichtiger wird als das eigentliche System [Ba98, S. 101]. Ändert der Benutzer in einer späteren Phase des Entwicklungsprozesses z. B. während der Codierung seine Anforderungen an das System, ist es schwer diese zu berücksichtigen, da die Anforderungen während der ersten Stufen festgelegt wurden. Durch die Festlegung des System-Umfanges und der Ressourcen werden nach dem Teufelsquadrat (sh. Abb. 1) Schwierigkeiten bei der Einhaltung von Terminen als auch der Qualität des Systems zu erwarten sein. 5

8 3 Extreme Programming Im folgenden Abschnitt werden die Grundzüge und Gedanken hinter Extreme Programming erörtert. Dabei wird die erste Version von XP unterstellt, weil ein Großteil der verfügbaren Literatur von dieser ausgeht. Außerdem bestehen zwischen den beiden Versionen nur geringfügige, für diese Ausarbeitung zu vernachlässigende Unterschiede, da die grundsätzlichen Ideen gleich geblieben sind [WRL05, S. 145]. Es wurden bspw. die Benennungen von Techniken und Prinzipien geändert sowie ein neuer Wert, der Respekt, hinzugefügt. Neben den Programmierern kommt dem Kunden eine wichtige Rolle in XP zu. Er ist im besten Falle zugleich Auftraggeber und Anwender des zu entwickelnden Systems. Sind dies verschiedene Personen, ist von einem zusätzlichen Kommunikationsaufwand auszugehen. Der Auftraggeber gibt die Ziele des Projektes vor, während der Anwender Fachwissen für die Entwickler beisteuert, damit die Anforderungen ohne größere Informationsverluste kommuniziert werden können [WRL05, S. 164]. Da für das Erfassen der Anforderungen sogenannte Story-Cards Verwendung finden, wird unter anderem vorausgesetzt, dass der Kunde gewillt ist das Projekt mit seinem Fachwissen aktiv zu unterstützen. Der Inhalt einer Story-Card ist die Beschreibung dessen was der Kunde vom System erwartet. Formulierungen, wie z. B. Ich möchte die aktuellen Geburtstage meiner Mitarbeiter auf einen Blick erfassen, sind gängig. Damit das System den Ansprüchen des Kunden so gut wie möglich gerecht werden kann, ist es wichtig, dass zwischen den Programmierer und dem Kunden reibungslos kommuniziert werden kann. Außerdem ist er befähigt die Anforderungen an das System jederzeit anzupassen, um z. B. neue Ideen einfließen zu lassen oder veränderte Umweltsituationen zu berücksichtigen. Ein zentrales Konzept von Extreme Programming ist die Orientierung der Entwicklung am Geschäftswert (engl. Business Value), welcher den Nutzen einer Anwendung für den Kunden wiederspiegelt. Positive Auswirkungen auf diesen Wert hat es, wenn die Programmierer die Story-Cards auch User Stories genannt umsetzen, die vom Kunden mit den höchsten Prioritäten versehen wurden. Agile Prozessmodelle wie Scrum und Extreme Programming verfügen über ein weiteres Konzept, das auf der Definition von Werten beruht. Bei XP sind dies in der ersten Version: Einfachheit, Kommunikation, Feedback und Mut, in der zweiten wurde das Wertesystem um Respekt erweitert. Beck hatte Respekt als Wert bereits in der ersten Version vorgestellt. Diesen Wert jedoch als unterhalb der Oberfläche der anderen vier [Werte] versteckt [Be03, S. 34f.] beschrieben und daher ursprünglich nicht explizit angeführt, aber mittlerweile im Zuge der Präzisierungen in der 6

9 zweiten Version des Manifests hinzugenommen. Das Leben der vorgestellten Werte in einem Projekt ist ein elementarer Schlüssel zum erfolgreichen Einsatz von XP. Auf den vier bzw. fünf Werten bauen 15 bzw. 14 Prinzipien auf, aus denen wiederum zwölf Techniken abgeleitet wurden, die in einem XP-Projekt eingesetzt werden sollten. Um den Umfang der Arbeit nicht zu sprengen, werden alle Techniken in Tabelle 1 auf Seite 8 kurz und knapp vorgestellt. In Anlehnung an das Werk von Wolf et. al. wurde die Übersicht angefertigt, wobei die Autoren die zwölf Techniken bereits um die Standup-Meetings und die Retrospektive erweitert haben, die XP in der zweiten Version berücksichtigt [WRL05]. 3.1 Ausschnitt der XP-Techniken Da die eingehende Erläuterung sämtlicher Praktiken in XP den Rahmen sprengen würde, werden im folgenden Abschnitt vier Techniken genauer dargestellt. Aufgrund der wechselseitigen Beziehungen der Techniken, auf die Abschnitt 3.2 eingegeht, werden mitunter Aspekte anderer Techniken beleuchtet. Die ausgewählten Techniken wirken sich maßgeblich auf den langfristigen Erfolg und Fortbestand eines XP-Projektes aus. Aus betriebswirtstschaftlicher Sicht besitzen die Praktiken in der Kombination eine hohe Relevanz, da sie sowohl Einfluss auf die Flexibilität und Qualität des Systems als auch deren Entwicklung nehmen. Denn das Programmieren in Paaren stellt sicher, dass unter anderem Wissen innerhalb des Teams aktiv ausgetauscht wird und der Entwicklungsprozess diszipliniert verfolgt wird. Durch das Testen wird ein Qualitätsniveau dauerhaft aufrecht erhalten und sichert das Team gegen Regressionen bzw. Rückschritte in der Entwicklung ab. Die Technik des Refactorings trägt dazu bei, das System immer ändern oder erweitern zu können. Anfängliche Kostenersparnisse werden mit Hilfe des einfachen Designs erreicht, da bewusst auf einen aufwendigen und zeitintensiven Entwurf des Systems verzichtet werden und durch die Änderbarkeit des Codes durch das Refactoring unterstützt wird. Im Zusammenspiel aller Techniken insbesondere durch die im folgenden, genauer vorgestellten Techniken wird eine Verbesserung der Aufwandskurve erreicht [Fo04]. Genauer gesagt, wird eine Stabilisierung der Kurve erzielt, sodass weitere Änderungen am System mit gleichen Aufwänden erzielt werden können. Abbildung 3 veranschaulicht den Gedanken hinter der Stabilisierung der Aufwände bei steigender Komplexität. Auf der linken Seite ist die in der Lehre vermittelte Aufwandskurve der traditionellen Entwicklung abgebildet, die exponentiell wächst. Dementsprechend einen höheren Aufwand verursacht, je komplexer ein System wird. Rechts 7

10 Name der Technik Planungsspiel Kurze Releasezyklen Metapher Einfaches Design Testen Refactoring Programmieren in Paaren Gemeinsame Verantwortlichkeit Fortlaufende Integration Nachhaltiges Tempo Kunde vor Ort Programmierstandards Retrospektive Standup-Meetings Beschreibung Der Kunde verfasst und priorisiert Anforderungen, Entwickler schätzen vor der Priorisierung einer Anforderung den Aufwand Software früh und häufig liefern Die Metapher beschreibt die primäre Funktion eines Systems Das einfachste Design wählen, das die Anforderungen erfüllt Erst automatisierte Tests schreiben und dann den Produktiv-Code Unschönheiten im Entwurf sofort beheben Zwei Entwickler arbeiten immer zusammen an einer Aufgabe Alle Entwickler arbeiten an und verantworten einen gemeinsamen Code-Bestand Änderungen am Code mehrmals täglich in den Code-Bestand integrieren Die Entwicklung findet mit einer gleichmäßigen Gewschwindigkeit statt Der Kunde und die Entwickler arbeiten am gleichen Ort Alle Entwickler halten sich an kurze, gemeinsame Programmierstandards Regelmäßige Reflektion über die Handlungen des Teams Tägliche Treffen aller Projektbeteiligten, um über den Projektfortschritt zu informieren Tabelle 1: Übersicht der XP-Techniken 8

11 Abbildung 3: Kostenkurve des Wasserfall-Modells und XP davon ist die in XP erwartete Kurve dargelegt, die mit steigender Komplexität gegen einen Wert konvergiert, sodass die marginalen Aufwände trotz steigender Komplexität nicht nennenswert wachsen. Dieser Wert liegt mittel- und langfristig unter dem der traditionellen Kurve [Be03, S. 21ff.] Programmieren in Paaren Programmieren in Paaren (engl. Pair Programming) ist eine Methode der Softwareentwicklung. Dabei arbeiten jeweils zwei Entwickler gemeinsam an einem Computer. Die Person, die über die Kontrolle von Maus und Tastatur verfügt, wird als Fahrer bezeichnet. Während der Fahrer bspw. einen Algorithmus in der Programmiersprache Java verfasst, ruht sich die andere Person jedoch nicht aus. Sie ist als Partner konzentriert bei der Arbeit und beobachtet die Eingaben des Fahrers. Dadurch stellt der Partner sicher, dass z. B. Randbedingungen des Algorithmusses überprüft, die Programmierstandards eingehalten oder Testfälle geschrieben werden. Durch diese implizit vorhandene Kontrollstruktur werden zwei wichtige Aspekte in der Softwareentwicklung gestärkt [WK00, S. 111]. Zum einen wird die Produktivität gesteigert, da es aufgrund der Partnerrolle unwahrscheinlich ist, dass der Fahrer anderen Aktivitäten nachgeht, die dem Ziel der Programmierung nicht zuträglich sind. Dazu zählt bspw. das Prüfen des privaten -Kontos. Durch die Anwesenheit des Partners ist immer eine Person vorhanden, die dafür sorgt, dass die Arbeit Fortschritte macht und Ergebnisse produziert werden. Auf der anderen Seite sichert der Partner die Qualität, indem er den Fahrer unter anderem auf syntaktische oder semantische Fehler hinweist. Zusätzlich haben beide Programmierer sei es der Fahrer oder der Partner ein Interesse an korrektem, fehlerfreiem Quelltext, da dieser aufgrund der gemeinsamen Verantwortlichkeit dem gesamten Team gehört. So gesehen stellt der Partner das schlechte Gewissen des Fahrers in Person dar und sollte auf der Behebung der zuvor beschriebenen Probleme beharren. Dennoch wird als Gegenargument zum Pair Programming mitunter angeführt, 9

12 dass zwei Programmierer als Paar weniger produktiv entwickeln als zwei Programmierer im Alleingang. Das im vorigen Absatz angeführte Argument beschreibt, wie durch die Paarung eine gesteigerte Aufmerksamkeit und damit gesteigerte Produktivität erzielt werden kann. Zusätzlich fehlt die empirische Grundlage, die das Gegenargument bekräftigen. Studien, die in der universitären Lehre unter anderem von Williams und Upchurch [WU01] sowie Braught et. al. [BEW08] durchgeführt wurden, zeigten, dass Studierende vom Programmieren in Paaren sehr profitierten. Dieser Profit wurde sowohl in der Qualität der erstellten Programme als auch in dem Lernerfolg der Beteiligten widergespiegelt. Kurzfristig ist sicherlich mit einer höheren Produktivität bei Einzelprogrammierern auszugehen, jedoch werden Programmierer auf lange Sicht besser mit dem Komplexität eines Software-Systems umgehen können als würden sie einzeln mit der Entwicklung am System beauftragt. Das Gegenargument wird außerdem durch die Tatsache geschwächt, dass viele Programmierer in Notsituationen auf Pair Programming zurückgreifen [JAH01, S. 111]. Der Autor dieser Arbeit hat diese Erfahrung in der Praxis einer Softwareentwicklungsfirma gesammelt. Dabei hat er bspw. bei schwerwiegenden Fehlern die Hilfe von Kollegen hinzugezogen; in anderen Fällen wurde er um Hilfe gebeten. Bei konsequentem Einsatz von Pair Programming tritt eine Kosteneinsparung durch den geringeren Bedarf an leistungsstarken PC ein. Schließlich arbeiten dann jeweils zwei Entwickler an einem Arbeitsplatz zusammen, sodass die Anzahl an Workstations reduziert werden kann. Es sei zusätzlich darauf hingewiesen, dass die Rollen der beiden Programmierer nicht statisch vergeben werden. Das heißt, dass die Programmierer im Laufe ihrer Zusammenarbeit des Öfteren einen Rollentausch vornehmen. Der Tausch findet unter anderem dann statt, wenn der Partner dem Fahrer eine Idee nicht verbal, sondern nur explizit im Quelltext ausdrücken kann oder will. Außerdem kann der Partner einen Wechsel vorschlagen, wenn er das Gefühl hat, dass der Fahrer nicht weiterkommt [JAH01, S. 113]. Dadurch wird bspw. verhindert, dass das Arbeiten zur Routine wird und dadurch die Konzentration sinkt oder ein aussichtsloser Pfad verfolgt wird. Im Zuge dessen wird das Risiko reduziert, das unbeabsichtigt Fehler in die Software einfließen. Des Weiteren werden die Paare in häufigen Abständen neugemischt; denkbar sind halbtägliche Wechsel, wobei dies in den jeweiligen Teams angepasst werden kann. Ein weiterer Punkt ist der Wissensaustausch, der durch häufige Paarwechsel gefördert wird. Wolf, et. al. beschreiben, wie das Programmieren in Paaren die Weitergabe von Wissen innerhalb eines Teams begünstigt [WRL05, S. 99]. Dabei benennen sie das Szenario, bei dem ein erfahrener Programmierer mit einem unerfahrenem 10

13 Programmierer zusammenarbeitet und das Wissen des Erfahrenen mit dem Unerfahrenen durch die direkte Interaktion ausgetauscht wird. Aufgrund dieses Austausches ist der Unerfahrene schneller in der Lage produktiv dem zu entwickelnden System beizutragen. Das zuvor beschriebene Erfahrungsgefälle zwischen den Programmierern ist jedoch nicht der einzige Vorteil in Bezug auf den Wissensaustausch. Beck erläutert einen weiteren Aspekt anhand einer Metapher [Be03, S. 101]. Dabei vergleicht er das Team mit einem Wasserbecken und illustriert wie folgt: Wenn jemand im Team eine wichtige neue Information findet, dann ist das so, als würde man einen Tropfen Farbstoff in ein Wasserbecken geben. Da die Paarungen ständig wechseln, wird die Information rasch im Team verbreitet, ebenso wie sich der Farbstoff rasch im Wasserbecken verteilt. Im Gegensatz zum Farbstoff wird die Information während der Verbreitung jedoch dichter, da in sie noch die Erfahrung und die Erkenntnisse aller Teammitglieder eingehen. Daraus resultiert insgesamt eine Wissensbasis, die im Team ständig erneuert wird und nicht zeitaufwendig in Wissens-Management- Systemen wie z. B. Wikis gepflegt werden muss. Durch Pair Programming und die einhergehende Wissensverbreitung wird außerdem ein wichtiges Projektrisiko minimiert, dessen Eintreten nicht exakt bestimmt werden kann. So führt der Ausfall eines Teammitgliedes in einem XP-Prozess nicht unmittelbar zu größeren Zeitverzögerungen bzw. Stillstand der betroffenen Projekte, da das Wissen auf das Team verteilt wurde. Diese Dezentralisierung von Wissen erhöht den sogenannten Truck-Factor, der besagt, dass der Faktor geringer ausfällt sobald der Fortschritt oder Erfolg des Projektes unmittelbar von einzelnen Teilnehmern abhängt [Bo05]. Bei einem Truck-Factor von 5 müssten folglich 5 Mitglieder des Projektes von einem Truck bzw. einem LKW erfasst werden, um einen Stillstand zu verursachen. Ein hoher Truck-Factor drückt also eine gewisse Unabhängigkeit von den Beteiligten eines Projektes aus, sodass es unwahrscheinlich ist, dass z. B. personelle Änderungen ein Projekt zum Scheitern bringen Testen Das Testen (engl. Testing) stellt eine weitere facettenreiche Technik im Extreme Programming dar. Im Kern handelt es sich um ein Prinzip, das die erwartete Funktionalität vor der Erstellung einer Implementation in einem Test festlegt. Dazu zählen vereinfacht dargestellt bspw. die zu erwartenden Ausgaben auf Eingaben oder die Fehlerbehandlung bei illegalen Eingaben. Durch die Möglichkeit das Verhalten eines Systems in Tests festzuhalten, bietet 11

14 das Testing dem Kunden ein Hilfsmittel um seine Anforderungen an das System in Testfällen auszudrücken. Gleichzeitig können die Entwickler nachvollziehen, ob sie den gewünschten Funktionsumfang korrekt implementiert haben. Hierbei ist es wichtig zwischen den verschiedenen Arten des Testing zu unterscheiden; die zuvor beschriebene Art fällt in die Kategorie der Akzeptanztests [WRL05, S. 70ff.]. Dabei legt der Kunde fest, welche Kriterien eine Anwendung zu erfüllen hat. Ein Kriterienkatalog beinhaltet Punkte wie die korrekte Berechnung von Ausgaben auf entsprechende Eingaben oder bestimmte Benutzbarkeitsmerkmale, z. B. die Erreichbarkeit des Startbildschirmes von jedem Punkt der Anwendung. Zur Unterstützung dieser Aufgabe existieren Tools wie FIT, das dem Kunden ermöglichen das Verhalten von Geschäftsregeln und ähnlichem in einem Wiki oder einer Excel- Tabelle zu pflegen [ov08b]. Ist das Verhalten einer Weboberfläche zu testen, stellt bspw. Canoo WebTest eine Möglichkeit dar [ov08a]. Manche Aspekte der Akzeptanz sind jedoch nicht automatisiert testbar und erfordern manuelle Durchführung; so kann die Lesbarkeit einer Website nur schwerlich automatisch getestet werden. Während der Programmierung eines Software-Systems schaffen die Entwickler mit Hilfe von Komponententests (engl. Unit Tests) eigenes Vertrauen in das von ihnen zu implementierende System. In XP wird der Ansatz der testgetriebenen Entwicklung eingesetzt, der besagt, dass bevor jeglicher Produktiv-Code geschrieben wird, ein Test die Existenz dieses Codes rechtfertigen muss. Die zweite Version von XP nennt Beck nicht mehr Testing, sondern Test-First Programming, um die Wichtigkeit des Testgetriebenen zu betonen. Die testgetriebene Entwicklung einer Funktionalität erfolgt in einem sich stetig wiederholenden 3-Phasen-Modell [We05, S. 51ff.]. In der ersten Phase wird der Test hinzugefügt und es wird genau so viel Produktiv-Code erstellt, bis der Test laufen kann und fehlschlägt. Dies bedeutet konkret, dass der Compiler zufrieden gestellt wird, sofern dieser aufgrund von Kompilier-Fehlern die Ausführung des Tests ausschlägt. Daraufhin implementiert man den Code, der den Test erfüllt, der üblicherweise in einem xunit-testfall erfasst wurde; JUnit ist eine Ausprägung für das Testen von Komponenten in Java [ov08c]. Da in diesem Schritt gemogelt werden darf, bspw. durch das harte Kodieren von Rückgabewerten, wird im dritten Schritt mit der Technik des Refactoring der Code vereinfacht, um Duplikationen und andere Gerüche 3 aus dem Quelltext zu entfernen. Da Testing das Schreiben der Testfälle vor dem Verfassen des eigentlichen Programmquelltextes vorsieht, werden die Ideen der Programmierer in den Tests wider- 3 Fowler verwendet diesen Begriff um Potenzial für Refactorings zu erkennen [FBB99, S. 75ff.]. 12

15 gespiegelt und formen auf diese Art und Weise die Schnittstellen des zukünftigen Systems. Die Formung der Schnittstellen durch die Tests prägen das Design der zukünftigen Anwendung maßgeblich, weshalb die testgetriebene Entwicklung auch als Designstrategie bezeichnet wird [We05, S. 91]. Insgesamt spannt die Menge der Komponententests Testsuite genannt sowie die Akzeptanztests eine Art Sicherheitsnetz für die Entwickler. Sollte eine ihrer Änderungen in dieses Netz fallen, werden sie automatisch darauf aufmerksam gemacht; im Gegensatz zur traditionellen Entwicklung bei der viele Fehler im Programm nicht automatisch entdeckt werden können, sondern erst in der Testphase, und aufgrund der Komplexität in der Programmierung übersehen werden. Durch die Testfälle wird automatisch beim Ausführen der kompletten Testsuite sichergestellt, dass der bestehende Funktionsumfang des betroffenen Systems nicht ungewollt reduziert wird. Diese Reduzierung beinhaltet z. B. das Einfügen von Fehlern, die für den Benutzer falsches Systemverhalten bedeuten können. Mängel in Programmen der traditionellen Softwareentwicklung, werden womöglich nicht von den Entwicklern bemerkt und letztlich an den Kunden ausgeliefert. Je später die Fehler behoben werden, sind die dafür notwendigen Aktivitäten mit umso höherem Aufwand bzw. Fehlerbehebungskosten anzusetzen [Ba98, S. 22f.]. Jedoch bleiben selbst Anwendungen, die mit Hilfe einer testgetriebenen Entwicklung zu Stande gekommen sind, nicht von Fehlern verschont. Die Wahrscheinlichkeit, dass Fehler während der Programmierung einfließen, ist aber geringer, da die Qualität insgesamt gestiegen ist [We05, S. 4f.]. Weitere Testtypen werden je nach Anwendungssituation relevant. Ein Profiler kann bspw. eingesetzt werden, um die Performance der Anwendung zu testen oder zu analysieren, sollte das System nicht die gewünschten Antwortzeiten bieten. Dabei werden Schwachstellen herausgestellt, die daraufhin optimiert werden können. Insgesamt sollte es jedoch nicht zu Problemen in puncto Performance kommen, da aufgrund des einfachen Designs weniger Objekte und Objektinteraktionen beteiligt sind [WRL05, S. 85f.] und das System somit performant sein sollte. Im Zusammenhang mit der fortlaufenden Integration wird sichergestellt, dass alle Komponententests fehlerfrei durchlaufen, da dies die Mindestanforderung an zur Integration stehenden Code ist. Dabei können neben den Unit Tests auch automatische Akzeptanztests durchgeführt werden, die jedoch eine Integration nicht abbrechen können, da sie in diesem Kontext lediglich als grober Indikator für den Projektfortschritt zu sehen sind. 13

16 3.1.3 Refactoring Das Refactoring dient dazu den Code und die Tests leicht verständlich zu halten und um Änderungen am Code einfach durchführen zu können [FBB99, S. 54]. Während eines Refactorings wird das zu beobachtende Verhalten des Systems jedoch nicht geändert. Die durch das Testen aufgebaute Testsuite gibt den Entwickler Vertrauen in ihre Refactorings. Vor Beginn der Änderungen wird sichergestellt, dass alle Unit-Tests problemlos durchlaufen, dann werden die Refactorings in inkrementellen Schritten am System durchgeführt. Zwischen den Schritten wird die Testsuite ausgeführt, um die Gewissheit zu erlangen, dass das Systemverhalten nicht modifiziert wurde. Als Ergebnis sind keine Funktionalitätserweiterungen vorgesehen, viel mehr soll das Verständnis vom System gestärkt und die Aufwandskurve des Projektes niedrig gehalten werden [WRL05, S. 88]. Refactorings müssten folglich als wert-neutral in Bezug auf den Geschäftswert betrachtet werden. Jedoch werden sie durch neue Anforderungen mitunter erforderlich, um das System in die Lage zu versetzen, die Funktionalitäten zur Erfüllung einer Story umzusetzen, sodass ein Refactoring eine Wertsteigerung begünstigt. Die Liste an möglichen Refactorings ist lang und enthält einfache Dinge wie das Umbenennen von Methoden, um die Funktion einer Methode besser kommunizieren zu können [FBB99, S. 273f.], oder das Verschieben eines Datenfeldes in eine andere Klasse, um geänderte Verantwortlichkeiten in Klassen zu antizipieren [FBB99, S. 146f.]. Komplexer fällt bspw. das Ändern eines Bedingungsblockes mit mehreren parallelen if-else- oder einem switch-statement aus, die mit dem Wissen über den Typ eines Objektes unterschiedliches Verhalten demonstrieren [FBB99, S. 255ff.]. Mit Polymorphismus wird das gewünschte Verhalten in die entsprechenden Klassen verschoben, sofern die Klassen eine Vererbungsstruktur besitzen, die dieses zulässt. In der Oberklasse wird eine abstrakte Methode definiert, die von den Unterklassen überschrieben wird und die gewünschten Werte zurückgibt, sodass der Bedingungsblock zu Gunsten von Erweiterbarkeit und Lesbarkeit entfällt. Die Notwendigkeit zum Refactoring eines Systems wird durch die sogenannten Gerüche (engl. Smells) markiert [FBB99, S. 75ff.]. Duplizierter Code ist einer von verschiedenen Gerüchen und stellt eine mögliche Fehlerquelle dar. Eine Vereinheitlichung des duplizierten Code-Blockes führt dazu, dass zukünftige Änderungen nur an einer Stelle gepflegt werden müssen und andere Stellen im Code daher nicht vergessen werden können. Als weiterer Geruch reiht sich der lange Methoden-Rumpf ein, der als Relikt 14

17 der prozeduralen Programmierung in der objektorientierten Programmierung keine Daseinsberechtigung besitzt. Durch Einführen neuer Methoden, die passende Teile des alten Rumpfes zusammenfassen, wird die Lesbarkeit des Code erhöht [FBB99, S. 110ff.]. Insgesamt stellt das Refactoring eine Möglichkeit zur Beherrschung der Komplexität eines wachsenden Systems dar. Damit Refactorings optimal umgesetzt werden können, müssen die Entwickler den Quelltext gemeinsam verantworten. Das Refactoring bietet sich als Hilfestellung für die Technik des einfachen Designs an, um den einfachsten Architektur-Ansatz wählen zu können, und wird von der testgetriebenen Entwicklung benötigt Einfaches Design In XP wird nicht wie etwa bei dem Wasserfall-Modell eine komplette Aktivität auf den Entwurf bzw. das Design angesetzt. Vielmehr durchläuft das Design während der Entwicklung einen evolutionären Prozess, in dem die Architektur inkrementell angepasst wird. Im Zuge der Nachbesserungen wurde in der zweiten XP-Version der inkrementelle Entwurf als zusätzliche Technik benannt. Dennoch startet kein XP-Projekt komplett ohne ein Architektur-Konzept, es beschränkt sich lediglich auf das Nötigste. Es wird lediglich kein Design auf Vorrat erstellt, das möglicherweise nützlich sein könnte, die Verwendung also unsicher bzw. unwahrscheinlich ist [WRL05, S. 78]. Aufgrund der Ausrichtung am Geschäftswert wird das einfachste Design gewählt, das die Anforderungen des Kunden erfüllt, sodass die Entwicklung stets wert-maximierend voranschreitet. Des Weiteren birgt die Bevorratung von Architektur bzw. Design ein Risiko, insofern, dass das Bevorratete womöglich nicht von Tests abgedeckt wird und so einen potenziellen Mangel darstellen könnte [WRL05, S. 80]. Damit ein Design einfach bleibt oder wird, hat Beck 4 Regeln aufgestellt, die den Charakter eines einfachen Design prägen und nach ihrem Stellenwert absteigend priorisiert [Be03, S. 109]: 1. Das System (sowohl Code und Tests) sollte den Inhalt des Systems verständlich ausdrücken. 2. Das System sollte keinen duplizierten Code enthalten. 3. Das System soll die minimale Anzahl an Klassen haben 4. Das System soll die minimale Anzahl an Methoden haben. 15

18 Wolf et. al. schreiben, dass durch die testgetriebene Entwicklung, die durch das Testen impliziert wird, diese Regeln geradezu erzwungen werden [WRL05, S. 81]. Ausgehend von der Entwicklung des einfachsten Design, das eben den simpelsten Ansatz darstellt, der gerade funktioniert, kann die Aussage formuliert werden, dass ein XP-Team mit leichtem Gepäck reist [Be03, S. 42]. Diese Umschreibung basiert auf einem Prinzip aus der ersten Version von XP 4 und betont, dass ein Team von jetzt auf gleich, wie Nomaden, auf Veränderungen, wie z. B. modifizierte Umweltsituationen, reagieren kann. Im Vergleich zur traditionellen Entwicklung stellt sich eine Kostenreduktion ein, weil Design-Entscheidungen erst zur realen Fälligkeit getroffen werden und nicht schon vor der Codierung, wenn noch nicht alle Anforderungen des Kunden bekannt sind. Außerdem lassen sich kleine, einfache Designs leichter anpassen als große, sodass der notwendige Aufwand geringer ausfällt. Diese Aufwandsreduzierung wird nicht zuletzt durch die Technik des Refactoring begünstigt. 3.2 Überblick der Abhängigkeiten Abbildung 4 zeigt die Abhängigkeiten der Techniken untereinander. So bedingt das einfache Design das Refactoring, um erfolgreich eingesetzt werden zu können. Beim Pair Programming ermahnt der Partner den Fahrer, wenn dieser vom testgetriebenen Ansatz abkommt und bspw. Geschäftslogik ohne einen Test implementiert. Ohne das Refactoring könnte die testgetriebene Entwicklung nicht angewendet werden, da es die grundlegende Technik für die dritte Phase darstellt. Aufgrund der Abhängigkeiten empfiehlt sich langfristig stets eine vollständige Einführung von XP, da dann sämtliche Vorteile in Kraft treten, wie z. B. die Stabilisierung der Aufwände. Wolf et. al. schlagen zwei Ansätze zur Einführung von XP vor. Zum eine komplette, einmalige Einführung der Praktiken und zum anderen eine schrittweise Unterweisung, bspw. für bestehende Projekte [WRL05, S. 242ff.]. 3.3 Rahmenbedingungen für XP Die Fokussierung von XP liegt unter anderem wegen der vorgestellten Techniken auf lauffähiger Software. Wird davon ausgegangen, dass der Aufwand der zur Entwicklung aufgebracht wird, fix ist, dann muss der Kunde gewillt sein, den Umfang des Systems ggf. zu reduzieren oder Änderungen am Fertigstellungstermin vorzunehmen, wie aus dem Teufelsquadrat (sh. Abb. 1) aufgrund der beiden festgelegten 4 In der zweiten Version wurde das einfache Design auf zwei andere Techniken verteilt. 16

19 Abbildung 4: Techniken stützen sich gegenseitig [Be03, S. 70] Parameter abgeleitet werden kann. Daher ist es schwierig mit XP ein Projekt durchzuführen, das am Ende der Laufzeit die gesetzten Ziele im vollen Umfang erreicht, dafür aber die meisten Ziele mit einer gewissen Qualität umgesetzt hat. Denkbar ist natürlich auch das Gegenteil, dass ein Team vor Ende der Projektlaufzeit sämtliche Ziele erreicht hat und weitere Funktionen implementieren könnte. Insbesondere bei Projekten mit langer Laufzeit (> 1 Jahr) wird es sehr schwierig Aussagen über die Zielerreichung zu treffen. Dies ist aber ein Problem, mit dem auch andere Prozessmodelle zu kämpfen haben, da auf lange Sicht große Planungsunsicherheit herrscht. Eine weitere Rahmenbedingung stellen physische Faktoren dar, wie z. B. getrennte Büroräume oder Einzel-Arbeitsplätze. Sind die Mitglieder eines Teams über mehrere Büroräume oder gar weitere Distanzen verteilt, wird ein Großteil der informellen Kommunikation unterbunden. Das Programmieren in Paaren fördert zumindest die informelle Verständigung innerhalb der Paare und erstreckt sich bei jedem Partnerwechsel weiter. Jedoch können die Entwickler bei einer physischen Trennung nicht von einer paar-übergreifenden, informellen Kommunikation profitieren. Schreibtische können ebenfalls einen physischen Störfaktor bilden, da viele Tische als Einzel-Arbeitsplatz dienen und an den Seiten, bspw. durch Schubfächer oder ähnlichem blockiert werden, oder aufgrund ihrer L-Form nur für eine Person 17

20 eine angenehme Sitzposition ermöglichen. Wolf et. al. empfehlen runde Tische für das Programmieren in Paaren, sodass der Rollentausch ohne großen Aufwand vorgenommen werden kann [WRL05, S. 102]. Dies bedeutet, dass der Fahrer dem Partner die Eingabegeräte nur zuzuschieben braucht, um den Tausch zu vollenden. Eingangs wurde in Abschnitt 2.1 darauf hingewiesen, dass große Teams mit der Einführung und Verwendung von agilen Prozessmodellen Probleme haben werden. Dies gilt auch für Extreme Programming, da bspw. Praktiken wie die gemeinsame Verantwortlichkeit bei größeren Teams aufgrund von nicht wahrgenommener Verantwortlichkeit früher verfallen. Als Maximum werden Teamgrößen von bis zu 12 Entwicklern angegeben; kleinere Teams aber zu favorisieren sind, die bspw. durch Aufspaltung des Projektes in logische Teilprojekte realisiert werden können [WRL05, S. 206f.]. Zu guter Letzt ist es notwendig, dass alle Beteiligten gewillt sind, die Werte, Prinzipien und Techniken anzunehmen, umzusetzen und zu leben. Die Regeln, die XP definiert, müssen diszipliniert eingehalten werden, was angesichts der Spielräume leichter gesagt als getan ist [WRL05, S. 241]. 18