Extreme Programming

aus Wikipedia, der freien Enzyklopädie

Extreme Programming (XP), auch Extremprogrammierung, ist ein flexibles Vorgehensmodell in der Softwaretechnik, das sich den Anforderungen des Kunden in wiederholten kleinen Schritten unter Verwendung von Rückkoppelungen sowie einer kommunikationsintensiven Herangehensweise zielgerichtet annähert. Es wurde von Kent Beck, Ward Cunningham und Ron Jeffries während ihrer Arbeit im Projekt Comprehensive Compensation System bei Chrysler als Vorgehen zur Erstellung von Software entwickelt. Das sogenannte C3-Projekt dauerte von 1995 bis 2000. Die zu entwickelnde Software wurde im Bereich der Lohnabrechnung eingesetzt ^[1].

Inhaltsverzeichnis 1 Grundlagen 2 Nutzen 2.1 Kundensicht 2.2 Programmierersicht 2.3 Projektsicht 2.4 Betriebswirtschaftliche Sicht 3 Vorgehen 3.1 Aufbauorganisation 3.2 Anforderungsmanagement 3.3 Planung 3.3.1 User Stories 3.3.2 Aufwandsabschätzung 3.4 Entwicklung und Abschluss 3.5 Abgrenzung zu herkömmlichem Vorgehen 4 Bestandteile 4.1 Werte 4.2 Prinzipien 4.3 Praktiken 4.3.1 Traditionelle Praktiken 4.3.2 Evolutionäre Praktiken 4.3.2.1 Hauptpraktiken 4.3.2.2 Begleitpraktiken 4.4 Flexibilitätsgrad vs. Steifheit 5 Diskussion 5.1 Ursprung und Abgrenzung 5.2 XP und das C3-Projekt 5.3 XP in anderen Projekten 5.4 Kritik 6 Siehe auch 7 Literatur 8 Weblinks 9 Quellen

[Bearbeiten] Grundlagen

XP entstand durch die Synthese zahlreicher Kerndisziplinen der Softwareentwicklung und basiert auf in der Praxis bewährten Vorgehensweisen und Standards (Best Practices).

XP bejaht die Ungewissheit, mit der die Softwareentwicklung verbunden ist, stellt aber keinen Freibrief zum Chaos aus. Es folgt vielmehr einem klaren, strukturierten Vorgehen und stellt die Teamarbeit, Offenheit und stetige Kommunikation zwischen allen Beteiligten in den Vordergrund. Kommunikation ist eine Grundsäule dieses Vorgehensmodells. Sollte die Kommunikation eines Teams gestört sein oder vom Vorgesetzten behindert werden, kann XP nicht funktionieren.

Die Arbeitsbelastung des Teams soll gleichmäßig verteilt werden, Überstunden sollen vermieden werden, um auch den Spaß an der Arbeit zu erhalten (siehe Traditionelle Praktiken) und somit langfristig die Arbeitsfähigkeit zu erhalten, sowie Fluktuation zu verhindern.

Die Methode berücksichtigt, dass der Kunde die wirklichen Anforderungen an die zu erstellende Software zu Projektbeginn meist noch nicht komplett kennt beziehungsweise das mit der Realisierung betraute Entwickler-Team nicht über alle (technischen) Informationen verfügt, um eine verlässliche Aufwandsschätzung über die notwendige Dauer bis zum Abschluss zu geben. Im Laufe eines Projektes ändern sich darüber hinaus nicht selten Prioritäten. Zu Beginn geforderte Funktionen der Software werden möglicherweise in einer anderen Form benötigt oder im Laufe der Zeit sogar komplett hinfällig.

Bei einer konsequenten Ausrichtung an XP soll die zu erstellende Software schneller bereitgestellt, sowie eine höhere Softwarequalität und Zufriedenheit des Kunden als mit traditionellen Ansätzen erreichbar sein. Der Kunde bekommt laut XP-Methodik ein einsatzbereites Produkt, an dessen Herstellung er aktiv teilgenommen hat.

Angefangen mit einer ersten kleinen Version der Software vergrößert sich der Entwicklungsrahmen ständig. Neue Funktionalität wird permanent entwickelt, integriert und getestet. Um zu der zu entwickelnden Funktionalität zu gelangen, werden gewöhnlich jeweils die Schritte Risikoanalyse, Nutzenanalyse, die Bereitstellung einer ersten ausführbaren Version (Prototyping) und ein Akzeptanztest durchgeführt. Das Modell lässt sich als agil, iterativ und inkrementell charakterisieren.

XP ist einerseits eine Summe von wichtigen einzelnen Bestandteilen (Werte, Prinzipien und Best Practices), andererseits auch ein strukturiertes Vorgehensmodell. Beides soll im Folgenden kontrovers diskutiert und der Nutzen kritisch betrachtet werden.

[Bearbeiten] Nutzen

Laut der Vertreter dieses Vorgehensmodells ist XP „gelebtes Risikomanagement“: in anderen Vorgehensmodellen wird das mit der Softwareerstellung verbundene Risiko häufig nicht unmittelbar berücksichtigt. XP pflegt einen impliziten Umgang mit dem Risiko. Es bejaht das Risiko, geht aktiv darauf ein und versucht es zu minimieren. Dieser implizite Umgang mit dem Faktor Risiko steht im Gegensatz zu eher expliziten Vorgehensweisen, wie der Aufstellung einer Risikoliste^[2]. Software-Entwicklungsprojekte sind unterschiedlichen Gefahren ausgesetzt, für die Extreme Programming Lösungen anbieten will.

[Bearbeiten] Kundensicht

Dem Kunden bietet XP, gerade durch seine kurzen Entwicklungszyklen, jederzeit die Möglichkeit, steuernd auf das Projekt einzuwirken. Dieser Nutzen steigt für den Kunden noch mit der Projektgröße oder -dauer. Dadurch soll im Besonderen erreicht werden, dass sich das Produkt aktuellen Anforderungen anpasst, statt überholten Anforderungen aus einer längst vergangenen Analysephase zu genügen und damit bereits bei Einführung veraltet zu sein. Zudem kann der Kunde bereits nach kurzer Zeit ein unvollständiges aber zumindest funktionstüchtiges Produkt einsetzen. Der Kunde ist optimalerweise jederzeit auf dem selben aktuellen Informationsstand bezüglich des Projektes wie das Entwickler-Team.

Ein häufiger Ansatz traditioneller Softwareerstellung ist: „Vielleicht brauchen wir irgendwann einmal diese oder jene Programmfunktionen“, auch Feature genannt. XP stellt dem gegenüber: Lass es! (vgl. auch YAGNI). Vor jedem der kurzen Entwicklungsschritte wird zusammen mit dem Kunden genau festgelegt, was wirklich sinnvoll ist, entwickelt zu werden. „Featuritis“ soll vermieden werden.

Eines der größten Risiken der Softwareentwicklung ist, dass dem Kunden ein Produkt bereitgestellt wird, das er in dieser Form nicht möchte. XP möchte dem durch ständige, aktive Einbeziehung des Kunden in den Entwicklungsprozess vorbeugen. Er kann sich Zwischenversionen ansehen und direkt Änderungswünsche äußern.

[Bearbeiten] Programmierersicht

Dem Programmierer möchte XP durch seine ständig wechselnden zusammenarbeitenden Paare und gemeinsamen Austausch und Abschätzung einen besseren Überblick über das Projekt und damit mehr Fachwissen sowohl über das Fachkonzept als auch die Technologien verschaffen. Es existiert keine strikte Rollentrennung, da die Aufgabenverteilung abhängig von Situation und Fähigkeiten geschieht. Der allgemeine Wissensaustausch und die stetige Kommunikation beugen einem Wissensmonopol vor. Dies soll den Einzelnen entlasten: Der Druck lastet auf einer Person, wenn diese sich als einzige an einem Modul auskennt. Durch die gleichmäßige Verteilung der Programmierer auf die Entwicklungsschritte ist die Arbeitsauslastung laut Methodik gleichmäßig zu verteilen.

Um Unbenutzbarkeit aufgrund von Programmfehlern sowie fehlerhafte Integration einzelner Komponenten zu vermeiden, werden bei XP viele und möglichst frühe Tests angestrebt. Jede Komponente besitzt einen Modultest (Unit-Test); in Java beispielsweise mit JUnit. Bei Feststellung eines Fehlers in einer Komponente während der Entwicklung wird ein Test entwickelt, der diesen lokalisiert. Eine tägliche Einbeziehung der einzelnen am Projekt beteiligten Entwickler mit automatischer Ausführung der Tests (Regressionstest) soll zu einer erheblichen Qualitätssteigerung führen. Fehler sollen so früher gefunden werden, denn je später ein Fehler gefunden wird, desto teurer ist meist dessen Behebung. Außerdem soll die testgetriebene Entwicklung zu einem leichter wartbaren Programmcode mit besserem Design führen.

[Bearbeiten] Projektsicht

Dem Projekt bietet XP die Möglichkeit, Risiken zu minimieren. Unter richtiger Anwendung XPs soll der Kunde Software erhalten, deren Umfang ihn nicht überrascht. Das Team soll ferner gegen Krankheit einzelner nicht mehr so anfällig sein. Ein ehrlicher Umgang mit dem Kunden möchte die Glaubwürdigkeit und Zufriedenheit steigern und die Angst minimieren, die gewöhnlich zwischen Kunde („Was werden die wohl liefern?“, „Haben die mich verstanden?“) und Entwicklung („Was will er eigentlich genau?“, „Ob er zufrieden sein wird mit dem, was wir liefern?“) vorherrscht.

Aufwandsabschätzungen werden verlässlicher, da sie im Team getroffen und ständig einer kritischen Überprüfung (Review) unterzogen werden. Teamgeist wird laut XP gefördert. Jedem sollte klar sein, dass das Ziel nur als Einheit erreichbar ist. Sollte ein Projekt, zum Beispiel aus Kostengründen, vorzeitig eingestellt werden, besteht durch die regelmäßigen Iterationen dennoch ein zumeist einsatzfähiges Produkt.

In vielen Projekten gelingt es nicht, das Produkt in der gewünschten Zeit im gewünschten Umfang und mit den geplanten Ressourcen fertigzustellen. In XP soll nur das verwirklicht werden, was tatsächlich einen Nutzen für den Kunden hat. Durch ständigen Austausch mit dem Kunden sowie Prioritätsanalysen sollen die unbedingt zu erstellenden Funktionen identifiziert werden. Dabei sollte mit den Funktionen begonnen werden, die den größten Nutzen haben und das größte (technische) Risiko beinhalten.

[Bearbeiten] Betriebswirtschaftliche Sicht

Extreme Programming stellt aus wirtschaftswissenschaftlicher Sicht eine Form der Organisation dar, die direkt die Prozesse der Wertschöpfung beschreibt. In den Wirtschaftswissenschaften werden zur Bewertung von Extreme Programming auch Erkenntnisse anderer Sozialwissenschaften insbesondere der Soziologie genutzt. Unternehmen bietet sich Extreme Programming als eine strategische Alternative bei der Erstellung von Software an.

Dem Risikomanagement dient diese Alternative vor allem zur Steuerung von Risiken. Wie bei vielen Prozessen der Wertschöpfung sind besonders in der Softwareentwicklung Risiken meist operative Risiken: Die Wertschöpfung ist ineffektiv, wenn die Kundenwünsche nicht getroffen und gesteckte Ziele somit verfehlt wurden. Die Wertschöpfung ist ineffizient, wenn zum Erreichen des Ergebnisses ein zu hoher Aufwand entstand. Risikoverminderung und dadurch Effektivität und Effizienz sollen bei Extreme Programming durch deren Eigenschaften im Umgang mit Fehlern, Mitarbeitern und Kunden durchgeführt werden:

• Weniger Fehler beim Ergebnis
• Kompensation von Krankheitsausfällen
• Kundennahe Entwicklung

Ein möglichst genaues Erkennen von Risiken durch das Verfahren selbst soll über angepasste Aufwandsschätzungen eine Bewertung des zu akzeptierenden Risikos ermöglichen. Extreme Programming kann dagegen eine Risikoverlagerung erschweren. Aus der Sicht des Risikomanagements ist Extreme Programming also nur eine Möglichkeit, mit Risiken umzugehen, die Vor- und Nachteile besitzt.

Das Personalwesen in Unternehmen betrachtet Extreme Programming insbesondere auf seine Auswirkungen auf die Mitarbeiterzufriedenheit. Extreme Programming soll dabei bewusst oder unbewusst zum kooperativen Lernen beitragen. Für das Personalwesen ist dieses Verfahren also besonders aus Sicht der Personalentwicklung interessant. Durch höhere Mitarbeiterzufriedenheit und die Vermeidung von Überstunden soll die gesamte Produktivität erhöht werden. Die Praktik des Pair-Programming lässt allerdings – rein mathematisch betrachtet – Gegenteiliges vermuten. Die Vermeidung von Spezialistentum und individuellem Besitz von Passagen der Software dient der kollektiven Wissenskonstruktion und kann den Austausch von Entwicklern vereinfachen.

Die gesamte Betriebswirtschaftslehre ist in den letzten Jahren von der prozess- bzw. wertschöpfungsorientierten zur kundenorientierten- bzw. marktorientierten Unternehmensführung übergegangen. Auch wenn Extreme Programming die Wertschöpfung beschreibt, bietet es Möglichkeiten zur kundennahen Unternehmung. Über Extreme Programming soll – wie in anderen Branchen schon länger üblich – eine größere Einbindung des Kunden in den Wertschöpfungsprozess möglich sein. Wichtig wird dies umso mehr, wenn Software weniger als Faktorgut, sondern mehr als Vorprodukt erstellt und vertrieben wird.

Ebenfalls betrachtet werden muss Extreme Programming und dessen Aufwand aus Sicht des Informationsmanagements, das den Aufwand für den unbedingt notwendigen Informationsaustausch festlegt und ökonomisch bewertet. Genutzt werden dazu Erkenntnisse der Informations- und Kommunikationswissenschaft. Dabei kann insbesondere die Medienreichhaltigkeitstheorie eingesetzt werden: Weil die zu diskutierenden und kommunizierenden Sachverhalte in der Regel sehr komplex sind, werden auch sehr komplexe, reichhaltige Kommunikationsmedien gewählt: direkte, persönliche Gespräche. Kritisch zu hinterfragen ist hierbei die schwierige räumliche Verteilbarkeit der Entwicklungsprozesse sowie die Einbindung des Kunden, da möglicherweise eine räumliche Trennung zwischen Entwicklern und Kunden besteht.

[Bearbeiten] Vorgehen

[Bearbeiten] Aufbauorganisation

Neben dem Entwicklungsteam gibt es im Wesentlichen den Kunden und den Product Owner. Innerhalb des Entwicklerteams soll es keine Rollentrennung geben, so wird nicht unterschieden, wer im Team was für ein Spezialgebiet hat beziehungsweise welche besonderen Fähigkeiten er mitbringt. Jede Person im Team wird als Entwickler (Developer) bezeichnet. Ein Manager ist gewöhnlich eine Person mit Führungsbefugnis, also ein disziplinarischer Vorgesetzter. Dieser hat in XP eine geringe Wichtigkeit. Dagegen gibt es einen „Leiter“ des Teams, also jemand der die Kommunikation mit Kunden oder untereinander koordiniert. Auch der Nutzer der zu erstellenden Software kann das Team durch das Projekt führen. Die Unterscheidung zwischen Manager und „Leiter“ ist für agile Vorgehensmodelle typisch. Der Product Owner, der über die genaue Vorgehensweise entscheidet, trägt die Verantwortung. Product Owner im Sinne von XP kann beispielsweise ein Vertreter des Produktmanagements, ein Kunde oder ein Nutzer des Produktes sein. Die Rollen sind je nach Projekt und Umgebung unterschiedlich, häufig auch in Personalunion, verteilt.

Die Rollen bei XP

Rolle	Beispiel	Aufgaben
Product Owner	Produktmanagement, Marketing, ein User, Kunde, Manager des Users, Analyst, Sponsor	Hat Verantwortung, setzt Prioritäten, Entscheider für bestes ROI
Kunde	Auftraggeber, kann auch der Product Owner sein, kann, muss aber nicht User sein	Entscheidet, was gemacht wird, gibt regelmäßig Feedback, Auftraggeber
Developer	Bestandteil des Teams, das ganze Entwicklungsteam besteht aus Entwicklern: Programmierer, Tester, DB-Experten, Architekt, Designer	Entwickelt das Produkt
Projektmanager	Ist gewöhnlich der Product Owner. Kann auch Entwickler aber nicht Manager des Teams sein	Führung des Teams
User	Der Nutzer des zu erstellenden Produktes	Wird das zu erstellende Produkt nutzen

[Bearbeiten] Anforderungsmanagement

Der Umgang mit den Anforderungen und deren Verwirklichung, also dem Anforderungsmanagement, ist eine zentrale Komponente XPs. Durch eine Mischung verschiedener, in den folgenden Kapiteln dargestellten Maßnahmen soll die Qualität und Flexibilität der Software gesteigert werden, so dass der Zusammenhang zwischen dem Zeitpunkt der Anforderungsstellung und den damit entstehenden Kosten sich weitgehend linear darstellt.

Bei einem weitgehend linearen Verlauf einer ableitbaren Änderungskostenkurve wird auf eine vollständige Erhebung aller Anforderungen zu Beginn des Projektes verzichtet. Stattdessen werden die sich erst im Laufe der Umsetzung ergebenden Anforderungen berücksichtigt. Dieses Vorgehen resultiert aus den Beobachtungen, dass einerseits der Kunde zu Beginn des Projektes noch gar nicht genau weiß, was er möchte, andererseits sich diese Anforderungen im Laufe eines Projektes ändern. Darüber hinaus sind Fehler umso teurer, je später man sie findet. Im schlimmsten Fall erhält der Kunde nach einem langen Projekt etwas geliefert, was er in dieser Form gar nicht haben möchte. Stetiger Kundenaustausch, Offenheit für Änderungen und stetige Integration wirken diesen Risiken entgegen. Anforderungen werden nicht selten zunächst als Prototypen bereitgestellt. Dabei handelt es sich um Versionen, die noch nicht die volle, endgültige Funktionalität besitzen.

[Bearbeiten] Planung

Im Rahmen der Planung wird gewöhnlich folgende Unterscheidung vorgenommen: ein Release beinhaltet die Funktionen, die insgesamt und für sich geschlossen die Bereitstellung einer neuen Version des Produktes rechtfertigen. Um zu dem Release zu kommen, ist ein Release-Plan aufzustellen, der im Wesentlichen aus Iterationen besteht. Unter anderem abhängig von der geschätzten Dauer des Release werden die Iterationen in Anzahl und Dauer festgelegt. Normale Iterationen dauern zwischen einer und vier Wochen. Der Zeitpunkt der Fertigstellung wird als Zeitintervall diskutiert, dessen Größe im Laufe des Releases aufgrund gewonnener Erkenntnisse und durchgeführten Fortschritts ständig abnimmt.

Die innerhalb der Iterationen umzusetzenden einzelnen Neuerungen werden mit dem Kunden durch User Stories, einer schlankeren Form der Anwendungsfälle (Use Cases), beschrieben. User Stories beschreiben die Funktionsanforderungen an ein System aus Sicht eines Akteurs. Eine User Story folgt dem Muster „Als xxx kann ich xxxx, um xxxx“, wobei das um auch weggelassen werden kann, falls die Absicht klar erkennbar ist. Diese Formulierung dient als Vorlage (Template) der abzuarbeitenden Anforderungen und ist situationsabhängig änderbar.

Das ganze Team ist bei der Erstellung beteiligt. Die abzuarbeitenden Anforderungen werden auf einzelnen Karten (Story Cards) geschrieben und für alle sichtbar an ein Medium platziert.

Anmerkung: Neben diesem Vorgehen ist es auch üblich CRC-Models auf CRC-Cards zu verfassen. Class Responsibility Collaboration-Models nehmen sich dabei einen Akteur im System vor und beschreiben dessen Verantwortlichkeiten und Interaktionen mit anderen Akteuren.

[Bearbeiten] User Stories

Den User Stories werden Prioritätswerte zugeordnet. Dazu muss das Team zusammen mit dem Kunden zunächst Klarheit gewinnen, welche User Stories das höchste Risiko bezüglich Zeitplan, Kosten oder Funktionalität besitzen und welche User Stories dem Produkt den höchsten respektive den niedrigsten Mehrwert bieten, wobei ein Diagramm hilfreich sein kann. Das Release sollte mit den User Stories begonnen werden, die das höchste Risiko und den höchsten Nutzen auf sich vereinen. Danach sind diejenige User Stories zu verwirklichen, die geringes Risiko aber hohen Nutzen haben. Anschließend geht das Team die User Stories an, die geringes Risiko und geringen Nutzen auf sich vereinigen. Die Fertigstellung von User Stories mit geringem Nutzen aber hohem Risiko ist zu vermeiden.

Neben einer Abschätzung nach Nutzen und Risiko ist für die Entscheidung, welche User Stories in dem Release beziehungsweise in den ersten Iterationen umgesetzt werden sollen, noch eine Analyse der Kundenwünsche von Bedeutung. Dabei bedient sich ein XP-Projekt häufig des Kano-Modells. In einer systematischen Kundenbefragung werden Fragen in funktionaler Form und in dysfunktionaler Form gestellt. Es lässt sich anschließend bestimmen, welche User Stories unbedingt fertiggestellt werden müssen (Must-haves), welche linearer Natur sind (je mehr, desto besser, Kundenzufriedenheit steigt linear) und welche Exciters sind (der Kunde rechnet nicht wirklich mit diesen Features, nutzt das Produkt auch ohne. Es lässt sich dadurch der Preis erhöhen.). Die gewonnenen Erkenntnisse werden diskutiert.

XP zeichnet sich dadurch aus, dass die Betrachtung der Größe einer Einheit, wie Release oder Iteration, unabhängig von ihrer Dauer ist.

[Bearbeiten] Aufwandsabschätzung

Bei der Release-Planung sind User Stories noch recht grobkörnig. Beschäftigt sich ein Team mit einer User Story genauer, so wird sie, zusammen mit dem Kunden, detaillierter beschrieben. User Stories werden gewöhnlich in Story Points abgeschätzt, wobei auch eine Abschätzung in idealen Tagen möglich ist. Story Points sind relative Aufwandsabschätzungen, also der Entwicklungsaufwand für eine Story im Vergleich zu anderen. Dabei kann es sein, dass erste Abschätzungen im Verlaufe des Projektes geändert werden. User Stories werden in einem Planning Poker, auch als Planning Game bekannt, in mehreren Runden vom ganzen Team auf eine Punkte-Anzahl geschätzt.

Nachdem User Stories abgeschätzt, priorisiert und einer Iteration zugewiesen wurden, beginnt das Team mit der Umsetzung. User Stories werden zu Beginn der Iteration in feinkörnige, technische Arbeitspakete (Tasks) zerlegt, die gewöhnlich einen Umfang von Stunden besitzen. Das Team führt diese Zerlegung durch und schätzt die Dauer eines jeden Tasks. Es wird allerdings noch nicht festgelegt, wer den Task zugeteilt bekommt. Zu Beginn der Arbeiten nehmen sich die Entwickler jeweils ein Arbeitspaket, gewöhnlich nach Fähigkeiten. Dieser Vorgang wird im Team kurz diskutiert. Nach der anfänglichen Zuweisung der Arbeitspakete wird ein weiterer Task begonnen, wenn ein Teammitglied Zeit dafür findet, also seinen letzten Task abgeschlossen hat.

Die Implementierung einer User Story, also der Funktionalität, ist erst abgeschlossen, wenn alle einzelnen Tasks dieser User Story abgearbeitet und die Tests geschrieben und alle erfolgreich durchlaufen sind. Der Demonstration dieser Vorgehensweise soll eine Tabelle mit Aufwandsabschätzungen in einer fiktiven Arztpraxis dienen. Jeder Arzt hat eine Software, welche ihm hilft seine Patienten und die Termine zu verwalten.

User Stories mit Aufwandsabschätzung in Story Points

Story No.	Story	Abschätzung (Story Points)
1	Als Arzt kann ich alle Patienten sehen, die ich am Tage habe.	3
2	Als Arzt kann ich über die Gesundheitsgeschichte meiner Patienten Auskunft geben.	5
3	Als Assistentin kann ich einem Patienten einen Termin geben.	2
4	Als Assistentin kann ich einem Patienten eine Verschreibung ausdrucken.	1

Der Begriff Velocity (Geschwindigkeit) beschreibt den Durchsatz des Teams, also die Anzahl der innerhalb einer Iteration erreichten Story Points. Die Bestimmung der Velocity hilft abzuschätzen, wie lange die Entwicklung der gewünschten Funktionalität für ein Release dauert beziehungsweise wie viele Iterationen notwendig sind. Es ist normal, dass die Geschwindigkeit des Teams nicht immer die gleiche ist.

[Bearbeiten] Entwicklung und Abschluss

Täglich gibt es eine kurze Besprechung (Stand-up Meeting), bei der jeder Entwickler berichtet, was er am Vortag geleistet hat, was er heute leisten möchte und wo es gegebenenfalls Probleme gab. Ferner werden situationsabhängig Arbeits-Paare gebildet (Pair Programming). Im Laufe des Tages findet, während die Entwickler die Funktionalität und die Tests programmieren, weiterer stetiger Austausch (Pair Negotiations) statt.

Kann eine User Story in einer Iteration nicht abgeschlossen werden, zum Beispiel weil die Tests nicht erfolgreich waren oder sich die Abschätzung als zu knapp beziehungsweise der Umfang als zu groß herausgestellt hat, so wird sie gewöhnlich in mehrere kleinere aufgeteilt oder komplett in die nächste Iteration verschoben. Auch während einer Iteration kann sich durch ändernde Prioritäten des Kunden oder durch neue Erkenntnisse an der Zusammenstellung der Iteration etwas ändern. Ist die Iteration abgeschlossen, schauen sich Vertreter des Managements, der Kunde (Akzeptanztest) oder andere Personen, die an dem Produkt Interesse haben (Stakeholder), das Produkt in der aktuellen Ausbaustufe an und geben Rückmeldungen (Feedback). So ist es denkbar, dass der Kunde während des Akzeptanztests neue Prioritäten setzt oder weitere Ideen hat.

Technische Unterstützung muss differenziert betrachtet werden. Einerseits wird bewusst auf technische Hilfsmittel verzichtet, so in etwa bei der Erstellung von User Stories. Diese werden gewöhnlich manuell erstellt. Andererseits wird die Technik aber auch exzessiv genutzt, so in etwa bei der automatisierten Integration und der automatisierten Durchführung von Tests. Darüber hinaus existieren Projektmanagement-Werkzeuge, die sich auf die speziellen Rahmenbedingungen und Anforderungen XPs konzentriert haben (siehe Tools).

[Bearbeiten] Abgrenzung zu herkömmlichem Vorgehen

Die zu entwickelnde Funktionalität wird kurz und formlos in User Stories beschrieben. Das meiste Wissen über die Funktionalität ihrer Entwicklung befindet sich in den Köpfen der Beteiligten. User Stories werden gewöhnlich nur relativ geschätzt. Zu Beginn einer Iteration wird deren Inhalt festgelegt. Anschließend kommt erst die Aufteilung der gewählten User Stories in Tasks. Neuartig an dem XP-Ansatz ist ebenfalls, dass nicht nur einzelne Personen sondern das ganze Team den jeweiligen Aufwand schätzt. Auch das Verfahren der Schätzung ist neu. Der Zeitpunkt, wann und wie die Tasks den einzelnen Entwicklern zugeteilt werden, ist ebenfalls ein Abgrenzungskriterium. Erst im Laufe der Iteration nehmen sich die einzelnen Entwickler je nach ihrer Verfügbarkeit eines Tasks an. Zu allen User Stories gibt es zahlreiche Tests. Eine User Story ist erst komplett abgeschlossen, wenn alle Tests erfolgreich abgelaufen sind. Der tägliche, kurze Austausch ist für die agile Methodik üblich.

[Bearbeiten] Bestandteile

XP besteht aus Werten, Prinzipien und Praktiken. Obwohl es auch andere maßgebliche Quellen gibt (siehe Weblinks und Literatur), orientiert sich die Zusammenstellung der Werte, Prinzipien und Praktiken an Kent Beck ^[3], dessen noch recht neue, evolutionäre Weiterentwicklungen XPs hier ebenfalls Berücksichtigung findet ^[4]. Es existiert keine eindeutige Definition von XP, wobei allerdings die Diskussionen und Ausführungen der drei Originalverfasser XP am signifikantesten prägen.

[Bearbeiten] Werte

XP definiert fünf zentrale Werte, abstrakte Elemente, die von zentraler Bedeutung sind. Es sind Kommunikation, Einfachheit, Feedback, Mut und Respekt, wobei Respekt erst später dazugekommen ist. Ohne stetige Beachtung der rudimentären Werte ist es laut XP nicht möglich erfolgreich Software zu entwickeln.

Das Team kommuniziert stetig, um Informationen auszutauschen. Der Prozess selbst erfordert hohe Kommunikationsbereitschaft. Es existiert ein stetiger Austausch aller Beteiligten, also auch zwischen dem Entwicklungsteam und dem Kunden. Es kommen auch Personen zu Wort, die in einer gerade diskutierten technischen Aufgabenstellung keine Experten sind. So werden sie miteinbezogen, es gibt zusätzliches Feedback und jeder fühlt sich dem Team und dem Produkt verpflichtet. Stetige Kommunikation mit dem Kunden, Aufnahme dessen Feedbacks und Erfüllung dessen Wünsche, also auch ein lauffähiges Produkt, das den Wünschen des Kunden voll entspricht, ist wichtiger als Vertragsverhandlungen. Die Kommunikation zeichnet sich ferner durch einen respektvollen Umgang miteinander aus, also im Team untereinander und mit dem Kunden. Verschiedene Meinungen werden akzeptiert.

Die Entwickler sollen mutig sein und die Kommunikation offen gestalten. Falls eine Anforderung nicht in einer Iteration umgesetzt werden kann, wird in einer ehrlichen Art und Weise direkt darauf hingewiesen. Es muss eine Atmosphäre geschaffen werden, die herkömmliche Störungen (wie unnatürlichen Konkurrenzkampf innerhalb des Teams zu Lasten des Produktes) minimiert. Um die Offenheit und den Mut zu fördern und gruppendynamischen, psychologischen Schwierigkeiten entgegenzutreten, kann bewusst ein Doomsayer zur offenen, zeitnahen Aussprache von schlechten Nachrichten oder möglichen Schwierigkeiten oder auch ein Advocatus Diaboli eingesetzt werden.

Es soll die einfachste Lösung für eine Problemstellung realisiert werden. In jeder Iteration konzentriert sich das komplette Team genau auf die momentan umzusetzenden Anforderungen. Die Lösungen sind technisch immer möglichst einfach zu halten.

[Bearbeiten] Prinzipien

Die 14 Prinzipien sind eine Brücke zwischen den abstrakten Werten und den konkreten, anwendbaren Praktiken (siehe unten). Die Prinzipien sollten immer Berücksichtigung finden. Es sind Menschlichkeit, Wirtschaftlichkeit, Beidseitiger Vorteil, Selbstgleichheit, Verbesserungen, Vielfältigkeit, Reflexion, Lauf, Gelegenheiten wahrnehmen, Redundanzen vermeiden, Fehlschläge hinnehmen, Qualität, Kleine Schritte sowie Akzeptierte Verantwortung.

Software wird von Menschen entwickelt, Menschen bilden also den Faktor, dem laut XP besondere Aufmerksamkeit gilt. Durch Schaffung einer menschlichen Atmosphäre soll den Grundbedürfnissen der Entwickler (Sicherheit, Vollendung, Identifikation mit der Gruppe, Perspektive und Verständnis) entsprochen werden.

Die erstellte Software beziehungsweise eine einzelne Funktionalität muss einerseits wirtschaftlich sein und dennoch einen echten Wert bringen. Andererseits muss sie für beide Seiten von Vorteil sein und alle Beteiligten (Entwicklungsteam und Kunden) zufrieden stellen.

Die Wiederverwendung bestehender Lösungen, wozu beispielsweise die zahlreichen unterschiedlichen Tests, die stetig, automatisiert durchlaufen werden, gehören, ist sehr wichtig. Selbstgleichheit zeichnet sich auch dadurch aus, dass Tests immer zusammen mit der Funktionalität entwickelt werden. Wo allerdings Verbesserungspotential identifiziert wird, ist die Lösung anzupassen. Es ist jedem klar, dass erste Lösungen meist nicht optimal sind. Aus Feedback und selbst gewonnenen, neuen Erkenntnissen wird die Lösung stetig verbessert. Immer bessere Lösungen zu erkennen, gelingt nur durch stetige Reflexion und ein kontinuierliches Hinterfragen der jeweiligen Vorgehensweisen im Team. Die Produktivität dieses Verfahrens steigt proportional zur Uneinheitlichkeit des aus Personen mit unterschiedlichen Fähigkeiten und Charakteren bestehenden Teams. Verschiedene Meinungen werden nicht nur geduldet, sondern auch gefördert. Dafür muss ein Konfliktmanagement etabliert werden.

Die Lauffähigkeit der Software muss zu jedem Zeitpunkt garantiert sein. Obwohl kurze Iterationen mit permanentem Feedback dabei helfen, das Projekt in einem Lauf zu halten, müssen Fehlschläge dennoch miteinkalkuliert werden. Es ist durchaus üblich und wird akzeptiert, eine Umsetzung durchzuführen, die zunächst nicht optimal oder sogar fehlerhaft sein kann. Diese Schwierigkeiten müssen als Gelegenheit und Chance begriffen werden, das Produkt und das Team noch weiter reifen zu lassen. Ein offener, konstruktiver Umgang mit den Herausforderungen der Softwareentwicklung gelingt umso besser, je mehr alle Beteiligten bereit sind, ihre Verantwortung zu akzeptieren. Einem Entwickler eine Aktivität und Verantwortung nur disziplinarisch aufzutragen, reicht nicht aus, da er die Verantwortung aktiv annehmen und leben muss.

Ein weiterer wichtiger Punkt ist die hohe Qualität, die gemäß XP im Gegensatz zu anderen Faktoren wie Ressourcen, Funktionsumfang oder Endtermin nicht diskutabel ist. Hiermit unterscheidet sich diese Grundeinstellung von vielen anderen Methoden der Softwareerstellung, bei denen Software zu einem bestimmten Zeitpunkt und in einem definierten Funktionsumfang fertiggestellt werden soll, worunter fast immer die Softwarequalität leidet. Gerade die Qualität ist allerdings sehr wichtig, um das Produkt einsatzfähig, fehlerfrei und erweiterbar zu halten. Software mit gutem Design, hoher Qualität ist mittelfristig kostengünstiger, erweiterbarer und weniger fehlerbehaftet als schnell erstellte sogenannte Frickelsoftware.

Zu einer guten Qualität gehört auch die Vermeidung von Redundanzen; unnötig mehrfach oder wiederholt ausgeführter Schritte oder auch manuell ausgeführter automatisierbarer Schritte. Durch schnelle, kleine Schritte bleibt das Team flexibel und kann sich schnell neuen Rahmenbedingungen stellen sowie auf Feeback eingehen. Die negativen Folgen eines einzelnen kleinen, nicht erfolgreichen Schrittes können wesentlich schneller durch einen neuen Schritt kompensiert werden, als dies bei einem einzelnem größeren Schritt der Fall ist.

[Bearbeiten] Praktiken

Extreme Programming ist die Summe einzelner, gemeinsam zur Nutzenoptimierung eingesetzter Best Practices. XP definiert sich selbst mit diesen Prinzipien allerdings nicht als Allheilmittel. Da, wo es den individuellen Anforderungen nicht genügt, soll es angepasst werden. Viele Prinzipien greifen verzahnt ineinander. Einzelne Praktiken sind an sich nicht neu und werden teilweise bereits lange genutzt, oder sind sogar von trivialer, und doch oft unterschätzter Natur. Die Praktiken sind die greifbaren, konkreten Maßnahmen, die sich aus den Werten und den Prinzipien ableiten lassen.

Es lassen sich traditionelle und evolutionäre Praktiken unterscheiden. Die traditionellen sind in der XP-Welt weit verbreitet und genutzt. Die evolutionären nehmen verschiedene neue Erkenntnisse aus der jahrelangen Anwendung XPs auf. Sie verfeinern oder modifizieren die ursprünglichen Praktiken geringfügig und machen damit die Nutzung klarer und verständlicher.

XP wird häufig mit den traditionellen Praktiken verbunden, beziehungsweise darauf reduziert.

[Bearbeiten] Traditionelle Praktiken

Pair-Programming: Beim Pair-Programming teilen sich zwei Programmierer einen Computer – einer codiert (der Driver) und der andere denkt mit und hat das „große Bild“ im Kopf (der Partner). Die Rollen werden regelmäßig getauscht. Dieses Vorgehen steigert den Wissenstransfer. Anfänger sollen schneller von der Arbeit eines Spezialisten lernen. Das Wissen wird verteilt. Das Projekt ist nicht mehr so anfällig gegen den Ausfall eines einzelnen. Durch ständigen Review der Entwicklung und Kommunikation wird das Design verbessert und Fehler schneller gefunden (siehe auch Vier-Augen-Prinzip).

Kollektives Eigentum: Aktivitäten werden zunächst nicht an einzelne Personen verteilt, sondern an das ganze Team. Es existiert laut Methodik das Bewusstsein und die Verpflichtung, nur als Team erfolgreich sein zu können. Einzelne Teammitglieder besitzen kein Wissensmonopol. Pair-Programming und wechselhafte Einsatzgebiete sollen der Strömung entgegenwirken, dass einzelne Personen Teile als ihren Besitz betrachten.

Permanente Integration: Integration der einzelnen Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen (z. B. durch das Computerprogramm CruiseControl). Je häufiger integriert wird, desto höher wird laut XP die eintretende Routine. Fehler werden damit früh aufgedeckt. Die mit der Integration verbundenen Kosten sollen fast auf Null minimiert werden, da die Integration zu einem täglichen Schritt gehört, der weitestgehend vollautomatisiert und selbst stabil und durchgetestet sein muss.

Testgetriebene Entwicklung bzw. Permanentes Testen: Bei der testgetriebenen Entwicklung werden erst die Modultests (Unit-Test) geschrieben, bevor die eigentliche Funktionalität programmiert wird. Der Entwickler befasst sich dadurch früh mit dem Design des Codes und überdenkt seine Programmierarbeit genau. Die Tests werden nach jedem Programmierschritt ausgeführt und liefern Rückmeldung über den Entwicklungsstand. Man spricht in diesem Zusammenhang auch von Grey-Box-Tests. Die Tests sind automatisiert. Im Laufe einer Integration werden Integrationstests durchgeführt. Es wird zwischen Regressionstest und Modultest unterschieden. Während Modultests einzelne Module testen (Unit-Tests), ist ein Regressionstest die kollektive Ausführung aller Tests, um die unveränderte Lauffähigkeit der alten, bereits vor der Iteration existenten Funktionalität zu überprüfen. Auch Performancetests, bei denen die Leistungs- und Geschwindigkeitsmerkmale in Bezug auf die geforderten Werte gemessen werden, sind üblich. Der Entwickler bekommt Rückmeldung (Feedback), wie viele und welche Tests nicht erfolgreich waren. Ein Akzeptanztest ist die Präsentation eines Standes des Produktes, um die Zufriedenheit des Kunden und die Nutzbarkeit zu validieren.

Kundeneinbeziehung: Enge Einbeziehung des Kunden, d. h. der Kunde gibt das Iterationsziel mit einer Auswahl der zu realisierenden User Stories vor und hat zeitnah 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 zumindest greifbar sein. Neben User Stories auf Story-Cards existiert noch der Ansatz CRC-Modelle auf CRC-Karten zu verfassen.

Refactoring: Laufendes Refactoring, ständige Architektur, Design- und Code-Verbesserungen, auch um Anti-Patterns zeitnah zu beheben. XP bejaht die Existenz von Code, der zu Anfang nicht perfekt ist. Stattdessen sind sämtliche Teile einem stetigen Review unterworfen. Die Behebung von gefundenen, optimierungsfähigen Stellen wird gewöhnlich zeitnah durchgeführt oder als Fehler (Bug) definiert, der in einer späteren Iteration behoben wird.

Keine Überstunden: 40-Stunden-Woche, d. h. Überstunden sind zu vermeiden, weil darunter die Freude an der Arbeit, mittelfristig die Konzentrationsfähigkeit der Programmierer und somit auch die Qualität des Produktes leiden soll. Nachweisbar sinkt die Produktivität des Entwicklers durch Überstunden. Arbeit außerhalb der regulären Arbeitszeit wird im Einzelfall zwar geduldet, aber auf keinen Fall besonders entlohnt oder erwartet. Überstunden zeugen gewöhnlich einfach nur von falscher Planung.

Iterationen: Kurze Iterationen, um dem Kunden in regelmäßigen Zeitabständen einen lauffähigen Zwischenstand des Produkts zu liefern. Eine Iteration ist eine zeitlich und fachlich in sich abgeschlossene Einheit. Kurze Iterationen und damit verbundene Akzeptanztests erlauben schnelle Feedbackschleifen zwischen Entwicklung und Kunde.

Metapher: Da in traditionell aufgesetzten Softwareprojekten ein latentes Missverständnis zwischen Kunde und Entwicklungsteam (der Entwickler hat Schwierigkeiten mit der Fachsprache des Kunden und umgekehrt) ein häufiges Problem darstellt, werden die Anforderungen im fachlichen Vokabular des Kunden, optimalerweise auch von ihm selbst, in Form von User Stories beschrieben. Alle sprechen eine Sprache, was durch ein Glossar noch verstärkt werden kann. Es wird eine Metapher gewählt, eine logisch ähnliche, für beide Seiten verständliche Alltagsgeschichte.

Coding Standards: Das Team hält sich bei der Programmierarbeit an Standards, die erst die gemeinschaftliche Verantwortung des Teams bei dieser Aufgabe ermöglichen. Wechselnder Einsatz der Entwickler in allen Bereichen der Software ist ferner laut XP nur durch gemeinsame Standards praktikabel.

Einfaches Design: Es soll die einfachste Lösung, die genau das Gewünschte erreicht, angestrebt werden. Bewusst allgemein (generisch) gehaltene Lösungen oder vorbereitende Maßnahmen für potentiell zukünftige Anforderungen werden vermieden. Zum Thema Einfachheit sind die umgangssprachlichen Akronyme KISS und YAGNI verbreitet.

Planning Game: Neue Versionen der Software werden in einem Planning Game, auch als Planning Poker bekannt, spezifiziert und aufwandstechnisch abgeschätzt. Während dieses iterativen Vorgehens sind sowohl Entwicklungsmannschaft als auch Kunde anwesend.

[Bearbeiten] Evolutionäre Praktiken

Die evolutionären Praktiken wurden fünf Jahre nach den ursprünglichen Praktiken publiziert und ersetzen diese. Sie lassen sich unterteilen in Hauptpraktiken und ergänzende Begleitpraktiken. Inhaltlich sind die neuen Praktiken mit den alten, traditionellen Praktiken vergleichbar. Die Bezeichnungen der alten Praktiken wurden teilweise modifiziert oder in einzelne Unterpraktiken aufgeteilt. Zwei Praktiken sind weggefallen: die Praktik Metapher war zu schwer zu vermitteln und hat sich laut Literatur nicht durchgesetzt. Coding standards werden als rudimentär vorausgesetzt und nicht mehr explizit erwähnt.

[Bearbeiten] Hauptpraktiken

Die Hauptpraktiken sind: Räumlich zusammen sitzen, Informativer Arbeitsplatz, Team, Pair-Programming, Energievolle Arbeit, Entspannte Arbeit, Stories, Wöchentlicher Zyklus, Quartalsweiser Zyklus, 10-Minuten-Build, Kontinuierliche Integration, Test-First-Programmierung und Inkrementelles Design.

Durch offene, gemeinsame Anordnung der Arbeitsplätze soll die Kommunikation optimiert werden. Diese Form ist aufgrund der besseren Kommunikationsmöglichkeiten einer räumliche Trennung der Beteiligten vorzuziehen. Der Arbeitsplatz muss ferner informativ sein, indem zum Beispiel aktuelle Tasks, der Stand des Projektes und andere wichtige Informationen am Arbeitsplatz immer gut sichtbar zu sein haben. Empfehlenswert ist es hier zum Beispiel, die User Stories zentral an eine Wand zu hängen.

Nicht nur räumlich vereint: Das Team ist laut XP wichtiger als die Individuen. Es fällt im Bewusstsein, nur als Gemeinschaft erfolgreich zu sein, gemeinsame Entscheidungen. Dies wird dadurch gefördert, dass die einzelnen technischen Aktivitäten in der Planung nicht einzelnen Personen, sondern dem Team zugeordnet werden. Probleme löst das Team ohne den Eingriff eines Managers von außen. Mit dem Thema selbstregulierendes Team befasst sich auch der Essay Die Kathedrale und der Basar. Pair-Programming mit abwechselnden Partnern soll diese Grundeinstellung weiterfördern.

Die Arbeit soll energievoll und gleichzeitig in einer entspannten kollegialen Atmosphäre ablaufen, da die Entwickler ohne Überstunden arbeiten und somit maximale Produktivität erlangen. Es werden Sicherheitspuffer einkalkuliert. Nicht einhaltbare Versprechen werden vermieden.

Die zu entwickelnde Funktionalität wird in Form von Stories beschrieben, beispielsweise User Stories. In einem wöchentlichen Zyklus wird entschieden, welche Kundenwünsche als nächstes in Angriff genommen werden. Das Projekt selbst wird in einem quartalsweisen Zyklus geplant. Die vorgegebenen Zyklen sind Richtwerte, deren Größen im täglichen Einsatz variieren können.

Die Software bauen und alle Testläufe sollen in maximal zehn Minuten abgeschlossen sein. Durch diesen 10-Minuten-Build werden die Kosten für Erstellung und das Testen der Software minimiert. Alle von einem Entwickler gemachten Änderungen sollten circa alle zwei Stunden bereitgestellt werden. Diese kontinuierliche Integration soll einem potentiellen Chaos vorbeugen, falls die Entwickler ihre Änderungen und Erweiterungen am Produkt sehr selten in das zentrale Datenhaltungssystem (Repository), beispielsweise CVS, einstellen würden. Alle Kollegen haben zeitnah die Änderungen zur Verfügung. Sowohl die zehn Minuten beim Build als auch die zwei Stunden bei der Integration sind Zielvorgaben, die in konkreten Projekten variieren können. Gerade bei großen Projekten mit einer großen Menge an Quelltext und Entwicklern wird ein Build deutlich länger dauern und die Integrationsintervalle nicht selten größer sein. Die Praktiken betonen nur die Richtung und geben einen Idealwert vor, der angestrebt werden sollte. Durch Automatisierung lässt sich die Build-Zeit weitestgehend minimieren.

Die Entwicklung ist ferner gekennzeichnet durch den Test-First Programmierung-Ansatz: vor der Realisierung der Funktionalität muss der Test geschrieben werden. Ein inkrementelles Design, das neue Erkenntnisse und Feedback aufnimmt, verbessert das Design der Software stetig.

[Bearbeiten] Begleitpraktiken

Die Begleitpraktiken sind: Richtige Kundeneinbeziehung, Inkrementelles Deployment, Team Konstanz, Schrumpfende Teams, Ursachliche Analysen, Geteilter Code, Codierung und Testen, Eine zentrale Codebasis, Tägliches Deployment, Verhandelbarer, vertraglicher Funktionsumfang und Zahlen-pro-Nutzung.

Der Kunde nimmt aktiv an der Entwicklung teil. Er ist Bestandteil der regelmäßigen Treffen und wird aktiv miteinbezogen. Die Einbeziehung zeigt sich auch beim zu entwickelnden Funktionsumfang, der verhandelbar bleiben muss. Mehrere kleinere Verträge anstatt eines großen Vertrags können in derartig betriebenen Projekten Risiken minimieren und die Flexibilität erhöhen. Da iterativ stetig neue Versionen bereitgestellt werden, muss die finanzielle Kompensation des Kunden unabhängig von der Anzahl der bereitgestellten Versionen sein. Der Kunde zahlt nicht für jede Version der Software, sondern pro Nutzung.

Das Team soll einerseits von seiner Konstanz leben, kann aber auch personell verkleinert werden. Das Entwicklerteam muss über mehrere Projekte hinweg das gleiche sein. Es erwirbt im Rahmen der Produktentwicklung die Fähigkeiten als Team zusammenzuarbeiten, die für weitere Projekte genutzt werden sollen. Sobald das Team leistungsstärker und produktiver wird, sollte seine Arbeitslast, trotz einer Verlagerung von Ressourcen zu anderen Teams, konstant bleiben.

Dem Code als dem im Zentrum stehenden Medium kommt eine zentrale Rolle zu. Er wird in einer zentralen, datenbankähnlichen Struktur (Repository) gehalten. Es existiert nur eine offizielle Version (Codebasis) des Systems. Dieser Code wird, bildlich gesprochen, zwischen den Entwicklern geteilt. Jeder Entwickler im Team muss in der Lage sein, auch „fremden“ Code jederzeit ändern zu können (siehe Collective Code-Ownership). Neben dem Code existieren immer die Tests, die zusammen mit dem Code die einzigen zu erstellenden, durch die Entwicklungsarbeit bereitgestellten Medien („Artefakte“) sind. Alle anderen Medien, wie zum Beispiel die Dokumentation, werden allein aus Code und Tests generiert.

Um Schwierigkeiten früh zu identifizieren, wird ein inkrementelles Deployment (die Überführung der Anwendung auf das Zielsystem) durchgeführt. Wenn Altsysteme durch neue Software ersetzt werden sollen, so muss ein Teil nach dem anderen ersetzt werden. Dieses Vorgehen soll die Umstellung planbarer machen. Das Deployment ist täglich inkrementell durchzuführen. Jeden Tag soll eine neue Version der Software produktiv gestellt werden. Dies macht das Deployment zur Routine, minimiert dessen Kosten und Fehler und ermöglicht stetige Integrations- und Akzeptanztests. Falls einmal ein technisches Fehlverhalten eintritt, muss eine ursächliche Analyse durchgeführt werden.

[Bearbeiten] Flexibilitätsgrad vs. Steifheit

Eine der theoretischen Grundlagen des Extreme Programming ist der Flexibilitätsgrad des zu entwickelnden Software-Systems. XP geht von einem mindestens proportionalen Zusammenhang zwischen dem Gegenteil der Flexibilität, der sogenannten Steifheit, und den Pflege-Kosten zur Fehlerbehebung oder Erweiterung des Systems aus. Je flexibler ein Software-System, desto geringer sind die Pflege-Kosten, je steifer, desto höher.

Einige Steifigkeitskriterien:

• Die Anzahl überflüssiger bzw. ungenutzter Features
• Eine schlechte, fehlende, schwer verständliche oder zu umfangreiche Dokumentation
• Ein schwer verständlicher oder steifer Entwurf
• Fehlende Regressionstests
• Ein schwerfälliges Gesamtsystem

Die Flexibilitätskriterien sind das Gegenteil der Steifigkeitskriterien, zum Beispiel ein leicht verständlicher und flexibler Entwurf.

Einige der als Bestandteil des Extreme Programming definierten Mechanismen dienen laut XP der Erhöhung der Flexibilität:

• Die testgetriebene Entwicklung sorgt für ein ausreichendes Vorhandensein von Regressionstests und eine verbesserte Testbarkeit der Software.
• Das ständige Refactoring führt zur Fehlerbeseitigung, einem leicht verständlichen und flexiblen Entwurf sowie einer guten Dokumentation.
• Die kontinuierliche Integration erfordert zwangsläufig ein leichtgewichtiges Gesamtsystem.
• Um die zu entwickelnde Fachlichkeit zu bestimmen und zwischen Kunde und Entwicklungsteam auszuarbeiten, werden User Stories eingesetzt.

[Bearbeiten] Diskussion

[Bearbeiten] Ursprung und Abgrenzung

In Abgrenzung zu traditionellen Vorgehensmodellen wie dem ab 1970 genutzten Wasserfallmodell, bei dem der Softwareentwicklungsprozess in aufeinanderfolgenden Phasen organisiert wird, durchläuft der Entwicklungsprozess in XP immer wieder iterativ in kurzen Zyklen sämtliche Disziplinen der klassischen Softwareentwicklung (zum Beispiel Anforderungsanalyse, Design, Implementierung, Test). Durch diese inkrementelle Vorgehensweise werden nur die im aktuellen Iterationsschritt benötigten Merkmale verwirklicht (implementiert). XP ist dadurch leichtgewichtiger: Es wird keine komplette technische Spezifikation der zu entwickelnden Lösung vorausgesetzt (so gibt es beispielsweise kein Pflichtenheft).

Nach Jahren der Anwendung von aus heutiger Sicht traditionellen Vorgehensmodellen wie dem Wasserfallmodell haben es, aus Sicht der XP Vertreter, die Projektverantwortlichen nur unzureichend verstanden, die Probleme und Risiken der Softwareentwicklung in den Griff zu bekommen. Viele Projekte kamen nie zu einem Abschluss oder überstiegen zeitlich und/oder kostentechnisch die Planung. Viele, gerade über lange Zeiträume laufende Projekte, deckten mit Abschluss zwar die zu Beginn spezifizierten Anforderungen ab, berücksichtigten allerdings unzureichend, dass Anforderungen sich ändern können oder erst im Laufe eines Projektes dem Kunden wirklich klar ist, wie das Produkt aussehen soll. Über Erfolg und Schwierigkeiten von Softwareprojekten liefert der Chaos-Report von The Standish Group regelmäßig fundierte Untersuchungen, wie beispielsweise 1994 ^[5].

Die folgende Tabelle stellt den von XP identifizierten Kerndisziplinen den historischen, weitverbreiteten Ansatz mitsamt seinen Risiken der Softwareentwicklung gegenüber. Nicht XP einsetzende Unternehmungen können ein Vorgehensmodell besitzen, welche sich – bewusst oder unbewusst – mit diesen Disziplinen positiv auseinandersetzen.

Verbreitete XP-Kerndisziplinen und Risiken bei herkömmlicher Herangehensweise

Praktik	Richtiges Vorgehen nach XP	Traditionelles oder falsches Vorgehen/Risiko nach XP
Kommunikation	Stetiger Austausch wird gefördert und erwartet.	Jeder muss zunächst mal seine Aufgaben lösen.
Mut	Offene Atmosphäre.	Angst vor versäumten Terminen und Missverständnissen mit Kunden.
Kollektives Eigentum	Programmcode, Dokumente etc. gehören dem Team.	Jeder fühlt sich nur für seine Artefakte verantwortlich.
Pair Programming	Zu zweit am Rechner.	Jeder will und muss zunächst auf seine ihm zugewiesenen Aufgaben schauen.
Integration	Stetige Integrationen erlauben Feedback und erhöhen Qualität.	Selten Integrationen, da vermeintlich unnütz und Zeitverschwendung.
Testgetriebene Entwicklung	Testen hat sehr hohen Stellenwert.	Testen kostet nur Zeit. Wenige manuelle Tests.
Kundeneinbeziehung	Der Kunde wird zur aktiven Mitarbeit aufgerufen.	Der Kunde ist selten wirklicher Partner sondern nur die „andere Seite des Vertrages“.
Refactoring	Suboptimales Design und Fehler werden akzeptiert.	Fehler sind verpönt. Erstellte Artefakte laufen angeblich immer direkt perfekt.
Keine Überstunden	Einhaltung der regulären Arbeitszeit.	Stetige, regelmäßige Überschreitung der regulären Arbeitszeit.
Iterationen	Ein Release wird in viele handliche Iterationen unterteilt.	Iterationen sind nicht nötig, es wird an einem Release gearbeitet.
Stand-up Meeting	Täglicher, strukturierter Austausch.	Große, lange, seltenere Projektmeetings. Die Personenanzahl und der Inhalt sind häufig zu aufgebläht.
Dokumentation	Wo es sinnvoll ist.	Wichtiges Artefakt. Alles muss standardisiert dokumentiert sein. Dokumentation wird aber nicht genutzt.
Metapher	Ein gemeinsames Vokabular.	Kunde und Entwicklung sprechen in zwei Sprachen, häufig aneinander vorbei.
Team	Das Team ist sehr wichtig. Es existieren keine Rollen. Feedback wird von jedem erwartet.	Spezialistentum. Abschottung. Wissensmonopole.
Standards	Standards, wo es sinnvoll erscheint.	Überregulierung. Starrer Prozess.
Qualität	Inhärenter Bestandteil.	Der Faktor, der als erster vernachlässigt wird, wenn Zeit oder Geld knapp werden.

Neben der bekannten und verbreiteten agilen Methode XP hat auch Scrum einen gewissen Bekanntheitsgrad erlangt. Neben vielen Ähnlichkeiten zu XP gibt Scrum in bestimmten Bereichen Vorgaben bezüglich Iterationslänge, Protokollierung und Verfahren. Scrum nutzt ein eigenes Vokabular. Der kleinste gemeinsame Nenner aller agilen Vorgehensmodellen ist das „Agile Manifest“ ^[6]:

Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.

Lauffähige Software hat Vorrang vor ausgedehnter Dokumentation.

Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.

Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.

Eine weitere gerne in diesem Zusammenhang angeführte Disziplin ist das Feature-Based Programming, eine Methodik welche den Schwerpunkt ebenfalls auf die bereitzustellende Funktionalität legt.

Ähnlichkeiten zwischen XP und Kaizen, einem in Japan vor allem in der Autoindustrie entwickelten Konzepts (Kontinuierlicher Verbesserungsprozess) zur Sicherung der Qualität im Fertigungsprozess und einer Optimierung der Fertigungs- und Managementkosten mittels „schlankerer“ Ansätze (lean production), sind nicht zu übersehen.

Gerade aufgrund der wachsenden Nutzung wird XP weiter optimiert: je mehr Projekte nach XP entwickeln, desto mehr Rücklauf geht in die Entwicklung von XP. Da es auch eine Summe von Best Practices ist, lässt sich sagen: „Es wird in der Praxis für die Praxis angepasst“.

[Bearbeiten] XP und das C3-Projekt

Das C3-Projekt wurde ursprünglich nach dem Wasserfallmodell und mit der Hilfe eines externen Dienstleisters umgesetzt. Nachdem nach knapp einem Jahr kein wesentlicher Fortschritt zu verzeichnen war, wurde der Entwicklungsansatz geändert. C3 wurde im Jahr 2000 nach dem Zusammenschluss der Unternehmen Daimler und Chrysler zu DaimlerChrysler eingestellt. Es wurde zwar eine lauffähige Software bereitgestellt, allerdings nicht in sämtlichen zu Beginn geplanten Ausbaustufen. Während des Projektes gab es Schwierigkeiten, den vor Ort vorhandenen Kundenrepräsentanten zu ersetzen, nachdem dieser nach einem Burnout ausgeschieden sein soll. Ferner wurden die Anforderungen sehr häufig gewechselt, und die Kommunikation gestaltete sich aufgrund der Mitarbeiterfluktuation schwierig. Die Einstellung des Projektes wurde damit begründet, dass das Management das Interesse an dem Projekt verlor ^[7][8].

Anderen Quellen nach stellte das erfolgreiche Projekt eine zuverlässige, kostengünstige und erweiterbare Software bereit. Neue Mitarbeiter konnten schnell integriert werden. Das System war drei Jahre produktiv und bis zum Schluss sowohl ein technischer als auch wirtschaftlicher Erfolg. Eingestellt wurde es aus zwei Gründen: Es wurde in Smalltalk entwickelt, obwohl Java in dieser Zeit ungemein an Popularität und Verbreitung gewann. Die Unternehmung wollte kein System weiterentwickeln, welches auf einer selten genutzten Sprache wie Smalltalk aufbaute. Der andere Grund wäre die Finanzierung: Zunächst wurde das Projekt als Pilotprojekt für objektorientierte Technologien direkt von der IT-Abteilung finanziert. Der Bitte der IT an andere Abteilungen, die Finanzierung für spätere Ausbaustufen zu übernehmen, wurde nicht nachgekommen. Das Projekt wurde daraufhin eingestellt ^[4].

[Bearbeiten] XP in anderen Projekten

Heute, über zehn Jahre nach den ersten XP-Schritten, erfreuen sich XP und andere agile Methoden wachsender Beliebtheit. Untersuchungen von „Forrester Research“ ergaben, dass in Nordamerika und Europa 2005 circa 14 Prozent aller Projekte mit agilen Methoden durchgeführt wurden^[9] (von denen XP die verbreitetste ist) und viele andere einen Einsatz prüfen.

Zu den Nutzern XPs zählen sowohl Unternehmungen, welche kommerziell Software herstellen und vertreiben, als auch Unternehmen, deren Geschäft nicht die Erstellung von Software ist. Auswahl: Dresdner Kleinwort Wasserstein, Encyclopaedia Britannica, Fidelity, Progressive, Capital One, Royal & Sunalliance, Andrena Objects, Channel One, Daedalos International, Gemplus, it-agile, Qwest und O&O Services ^[10][11].

Viele Unternehmen berichten öffentlich von ihren Erfahrungen mit XP. Sie schildern, wie sie XP im Detail eingesetzt haben, welche Schwierigkeiten dabei auftraten, und wie der Erfolg einzuschätzen war. Symantec hat seine Änderung des Vorgehensmodells hin zu XP publiziert^[12]. Sabre Airline Solutions hat mit XP sowohl die Fehler in ihrer Software als auch die Entwicklungszeit reduziert ^[13].

“It was XP […] that produced the dramatic quality improvements […] You have the weaker people paired with the stronger people, and business knowledge and coding knowledge are transferred very quickly.”

– Sabre: ^[13]

Sabre macht XP für eine Steigerung in der Produktivität bei der Erstellung von Software um 42 Prozent verantwortlich.

[Bearbeiten] Kritik

XP gilt in verteilten Umgebungen als schwerer einsetzbar als herkömmliche Modelle. Der direkte Kontakt der Entwickler untereinander und zum Kunden ist problematisch, falls verschiedene Kunden existieren und/oder die Beteiligten räumlich getrennt arbeiten, zum Beispiel bei teilweise ausgelagerten (Outsourcing) Entwicklungen. Der „ideale Kunde“ ist manchmal nicht greifbar. Der Einsatz von XP in hochsensiblen Bereichen mit genau zu spezifizierenden Merkmalen bedarf besonderer Konzentration (beispielsweise im Automobilbereich). Sowohl Eigenheiten in der Aufbauorganisation als auch die Komplexität und Anforderungen an die zu entwickelnde Fachlichkeit lassen sich laut XP dennoch „meistern“. Auch größere Teams werden als nicht geeignet angesehen, nach XP zu entwickeln. Hier kann eine Aufteilung in viele kleine Teams helfen, wobei die optimale Einzelteamgröße bei bis zu ca. 10 Personen liegen sollte. Weniger kommunikationsfreudige Mitarbeiter können Schwierigkeiten haben, bei XP-Projekten mitzuarbeiten. Einzelne Entwickler dürfen nicht an dem Umfang ihrer entwickelten Funktionalität dynamisch entlohnt werden, da das Team im Vordergrund steht und entscheidet.

Darüber hinaus gibt es spezifische Unternehmensumgebungen, welche auf den ersten Blick die Nutzung von XP erschweren. Dazu gehören:

• Das Projekt wird weit im Voraus geplant.
• Das Projekt muss einen festen Fertigstellungstermin (Deadline) einhalten, und dabei eine genau festgelegte Anzahl an Funktionalität liefern.
• Das Projekt geht von einer Unternehmung zu einer anderen über (Outsourcing).
• Anforderungen werden nur ganz oberflächlich verstanden.
• Das Unternehmen selber ist recht starr und möchte, selbst bei Projekten, die bezüglich Deadline und Funktionsumfang gar nicht starr sind, nicht viel Flexibilität erlauben.

Diesen Punkten ist gemeinsam, dass sie eine unverhältnismäßig große Unsicherheit beinhalten und/oder eine Ungenauigkeit der Aufwandsschätzungen sehr große Konsequenzen hätte. In einer solchen Umgebung empfiehlt es sich laut XP, bei der Nutzung von XP sogenannte Funktionspuffer (Puffer im Funktionsumfang, Feature Buffers) und/oder Zeitpuffer (Puffer beim Fertigstellungstermin, Schedule Buffers) einzuplanen. Implizite Funktionspuffer in einer Größenordnung von 30 Prozent werden beispielsweise auch von Dynamic Systems Development Method (DSDM), einer weiteren agilen Entwicklungsmethode, angelegt.

Ein weiterer häufiger Kritikpunkt ist, dass XP für Festpreisprojekte nicht geeignet sei. Ansätze, um XP mit Festpreisprojekten zu vereinen, sind: Versicherungsprämien auf die Schätzung, User Stories (bzw. die Story Cards) werden zum Vertragsgegenstand, Prognosen von Risiken auf Produktivität und den verbleibenden Aufwand oder besondere Preismodelle wie Aufwandspreis mit Obergrenze, Phasenfestpreis oder Anforderungseinheitspreis. Dem Kunden sollte es davon unabhängig wichtiger sein, ein lauffähiges Produkt zu haben, welches voll seinen Wünschen entspricht.

Auch einzelne Praktiken stehen in der Kritik. So ist es teilweise schwer zu vermitteln, dass Pair-Programming laut XP tatsächlich eine Produktivitätssteigerung und besseres Design nach sich zieht. Viele halten zwei Personen an einem Rechner, von denen einer „nur zuguckt“, nicht für effizient. Auch die Bestrebung, immer das einfachste Design und die einfachste Lösung zu wählen, kann kontraproduktiv sein. Laut XP ist eine generische Lösung nicht anzustreben. Häufig sind allerdings spätere Änderungen oder Erweiterungen früh antizipierbar und könnten bereits früh im Design der Software berücksichtigt werden. Die stetige Erstellung von Testfällen und automatisierte, permanente Ausführung der Tests kann in sehr komplexen oder nebenläufigen Anwendungen und verteilten Systemen sehr schwierig sein.

[Bearbeiten] Siehe auch

• Agile Softwareentwicklung
• Crystal – Agiles Vorgehensmodell
• RUP – Vorgehensmodell
• Spiralmodell – Vorgehensmodell
• V-Modell – Vorgehensmodell
• Testaufwand

[Bearbeiten] Literatur

• Scott W. Ambler, Ronald E. Jeffries: Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, Wiley, John & Sons, ISBN 0-471-20282-7
• Kent Beck: Extreme Programming – das Manifest. Die revolutionäre Methode für Softwareentwicklung in kleinen Teams, Addison-Wesley, 2000, ISBN 3-8273-1709-6
• Alistair Cockburn: Agile Softwareentwicklung, mitp, ISBN 3-8266-1346-5
• Martin Fowler: Refactoring, Addison-Wesley, ISBN 3-8273-1630-8
• Ronald E. Jeffries: Extreme Programming Adventures in C#, Microsoft Press, 2004, ISBN 0-735-61949-2
• Ronald E. Jeffries et al.: Extreme Programming Installed, Addison-Wesley Professional, 2000, ISBN 0-201-70842-6
• Bernd Oestereich (Hrsg.), Dr. Peter Hruschka, Nikolai Josuttis, Dr. Hartmut Kocher, Dr. Hartmut Krasemann, Markus Reinold: Erfolgreich mit Objektorientierung, Oldenbourg, 2., aktual. und erg. Aufl., 2001, ISBN 3-486-25565-7
• Stefan Richter: Feature-based Programming, Addison-Wesley, ISBN 3-8273-2077-1
• Henning Wolf, Stefan Roock, Martin Lippert: eXtreme Programming: eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt, 2., überarb. u. erw. Aufl., 2005, ISBN 3898643395.

[Bearbeiten] Weblinks

Deutsch

• Podcast zum Thema Extreme Programming vom Chaosradio
• Artikel aus die Zeit
• Extreme Programming – Back to Basics?
• Was ist Extreme Programming? – von Frank Westphal
• OpenSource Entwicklung und ihre Dynamiken (mit Kapiteln über Agile Methoden und XP)
• XP-Tagebuch, ein Tagebuch von Entwicklern, die Extreme Programming betreiben.
• XP Days Deutschland, die jährliche XP Konferenz in Deutschland

Englisch

• Agile Alliance
• Extreme Programming: A gentle introduction.
• XP (Ron Jeffries)
• XP (Ward Cunningham)
• XP-The New Methodology (Martin Fowler)

Tools (Auswahl)

• ProjectCards (proprietär)
• VersionOne Agile Lifecycle Management (proprietär)
• XPlanner (frei)

[Bearbeiten] Quellen

1. ↑ Chrysler Comprehensive Compensation System: Chrysler Goes To “Extremes” (PDF, englisch), 9. Juni 2006
2. ↑ Tom DeMarco, Timothy Lister: Bärentango, Hanser Fachbuch, März 2003, ISBN 3-446-22333-9
3. ↑ Kent Beck, Dirk Andres: Extreme Programming Explained. Embrace Change. 1st Edition, Addison Wesley, 2000, ISBN 0201616416
4. ↑ ^{a b} Kent Beck, Dirk Andres: Extreme Programming Explained. Embrace Change. 2nd Edition, Addison Wesley, Dezember 2004, ISBN 0-321-27865-8
5. ↑ The Standish Group: The CHAOS Report (1994) (englisch), 12. Juni 2006
6. ↑ Ward Cunningham, Kent Beck et al.: Manifesto for Agile Software Development (englisch), 2001
7. ↑ Chrysler Comprehensive Compensation System Wiki: C3 Wiki (englisch), 16. Juni 2006
8. ↑ Keefer, AVOCA GmbH: Extreme Programming Considered Harmful for Reliable Software Development 2.0 (PDF, englisch), 16. Juni 2006
9. ↑ Forrester Research: Corporate IT Leads The Second Wave Of Agile Adoption (englisch), 30. September 2005
10. ↑ C2: Companies Doing Xp (englisch), 23. Juli 2006
11. ↑ Object Mentor, Inc.: Companies using XP, Customers (englisch), 23. Juli 2006
12. ↑ Dr. Dobb's: Going to Extremes (englisch), 17. Dezember 2001
13. ↑ ^{a b} Computerworld: Sabre takes extreme measures (englisch), 29. März 2004