<< zurück

MBSE Home

weiter >>

2.2 Extreme Programming (XP)

Extreme Programming (in Kurzform: XP) ist eine „agile“ Softwareentwicklungsmethode, deren wesentlicher Kern in [Bec04] beschrieben ist. Obwohl XP als Vorgehensweise unter anderem in Softwareentwicklungsprojekten einer Schweizer Bank definiert und verfeinert wurde, zeigt schon die Namensgebung eine starke Beeinflussung durch die nordamerikanische, von Pragmatik geprägte Softwareentwicklungs-Kultur. Trotz des gewählten Namens ist XP allerdings keine Hacker-Technik, sondern besitzt einige sehr detailliert ausgearbeitete und rigoros zu verwendende methodische Aspekte. Diese erlauben es ihren Befürwortern zu postulieren, dass durch XP mit verhältnismäßig wenig Aufwand qualitativ hochwertige Software unter Einhaltung der Budgets zur Zufriedenstellung der Kunden erstellt werden kann. Statistisch aussagekräftige, über Anekdoten hinausgehende Untersuchungen von XP-Projekten gibt es mittlerweile einige [DD08, RS02, RS01].

XP erfreut sich in der Praxis einer hohen Popularität. Mittlerweile sind viele von Bücher über XP erschienen, von denen auch die ersten [Bec04, JAH00, BF00, LRW02] unterschiedliche Aspekte der Thematik sowie jeweils aktuelle Wissensstände der sich noch in Weiterentwicklung befindlichen Methodik detailliert betrachten oder Fallbeispiele durchgeführter Projekte illustrieren [NM01]. [Wak02, AM01] beinhalten vor allem praktische Hilfestellungen zur Umsetzung von XP, [Woy08] betrachtet kulturelle Aspekte und [BF00] diskutiert die Planung in XP-Projekten.

Eine kritische Beschreibung mit expliziter Diskussion von Schwachstellen von XP bieten [EH00a] und [EH01]. Darin wird unter anderem der fehlende Einsatz von Modellierungstechniken wie etwa der UML bemängelt und ein kritischer Vergleich zu Catalysis [DW98] gezogen. Eine dialektische Diskussion der Vor- und Nachteile von Extreme Programming beinhaltet [KW02]. Darin werden unter anderem die Notwendigkeit zum disziplinierten Vorgehen, die starken und gegenüber klassischen Ansätzen deutlich geänderten Anforderungen insbesondere an den Teamleiter und den Coach hervorgehoben.

Nachfolgend werden wesentliche Elemente von XP gemäß den Einführungen aus [Bec04, Rum01] dargestellt und diskutiert. Weiterführende Themen in der Literatur behandeln mittlerweile XP parallel mit anderen agilen Methoden [Han10, Leh07, Ste10, HRS09] und erhalten so ein Portfolio agiler Techniken, oder sie adaptieren agile Methoden für verteilte Teams [Eck09] oder behandeln die Migration von Unternehmen hin zu agilen Methoden [Eck11].

Übersicht über XP

XP ist eine leichtgewichtige Softwareentwicklungsmethode. Darin wird auf eine Reihe von Elementen der klassischen Softwareentwicklung verzichtet, um so eine schnellere und effizientere Codierung zu erlauben. Die dabei für die Qualitätssicherung möglicherweise entstehenden Defizite werden durch stärkere Gewichtung anderer Konzepte (insbesondere der Testverfahren) kompensiert. XP besteht aus einer Reihe von Konzepten, von denen im Rahmen dieses Überblicks nur die wesentlichsten behandelt werden.

XP versucht explizit nicht auf neue oder nur wenig erprobte methodische Konzepte zu setzen, sondern integriert bewährte Techniken zu einem Vorgehensmodell, das auf Wesentliches fokussiert und auf organisatorischen Ballast soweit wie möglich verzichtet. Weil der Programmcode das ultimative Ziel einer Softwareentwicklung ist, fokussiert XP von Anfang an genau auf diesen Code. Alles an zusätzlicher Dokumentation wird als zu vermeidender Ballast betrachtet. Eine Dokumentation ist aufwändig zu erstellen und oft sehr viel fehlerhafter als der Code, weil sie normalerweise nicht ausreichend automatisiert analysierbar und testbar ist. Zusätzlich reduziert sie die Flexibilität bei der Weiterentwicklung und Anpassung des Systems als schnelle Reaktion auf neue oder veränderte Anforderungen der Kunden, wie es in der Praxis häufig der Fall ist. Folgerichtig wird in XP-Projekten (außer dem Code und den Tests) nahezu keine Dokumentation erstellt. Zum Ausgleich wird dafür Wert auf eine gute Kommentierung des Quellcodes durch Codierungsstandards und eine umfangreiche Testsammlung gelegt.

Die primären Ziele von XP sind die effiziente Entwicklung qualitativ hochwertiger Software unter Einhaltung von Zeit- und Kostenbudgets. Welche Mittel dazu eingesetzt werden, wird anhand der Werte, der Prinzipien, der grundlegenden Aktivitäten und der darin umgesetzten Entwicklungspraktiken in Pyramide in Abbildung 2.2 veranschaulicht.

Erfolgsfaktoren von XP

Nach mittlerweile einigen Jahren des Einsatzes von XP kristallisieren sich einige der für den Erfolg von XP-Projekten wesentlichen Faktoren heraus:

• Das Team ist motiviert und das Arbeitsumfeld für XP geeignet. Das bedeutet zum Beispiel, dass Arbeitsplätze für Pair Programming eingerichtet sind und die Entwickler in räumlicher Nähe untereinander und zum Kunden arbeiten.
• Der Kunde arbeitet in seiner Rolle aktiv am Projekt mit und steht für Fragen zur Verfügung. Die Studie [RS02] hat gezeigt, dass dies als einer der kritischen Erfolgsfaktoren zu werten ist.
• Die Wichtigkeit der Tests auf allen Ebenen erschließt sich, sobald Änderungen stattfinden, neue Entwickler hinzukommen oder das System eine gewisse Größe erhält und damit manuelle Tests nicht mehr durchführbar sind.
• Der in allen Bereichen diskutierte Zwang nach Einfachheit führt zum Weglassen von Dokumentation genauso wie zu einem möglichst einfachen Design und erlaubt daher eine signifikante Reduktion der Arbeitslast.
• Das Fehlen eines Pflichtenhefts und die Anwesenheit eines Kunden, mit dem auch während des Projekts über Funktionalität verhandelt werden kann, führt zu einer intensiveren Einbindung des Kunden in den Projektverlauf. Dies hat zwei Auswirkungen: Zum einen erlaubt es eine schnelle Reaktion auf sich verändernde Kundenwünsche. Zum anderen können so auch die Kundenwünsche durch das Projekt beeinflusst werden. Der Projekterfolg wird dadurch auch eine soziale Übereinkunft zwischen Kunden und Entwicklerteam und nicht nur eine objektiv überprüfte, auf Dokumenten basierende Zielerreichung.

Gerade der letzte Aspekt entspricht der XP-Philosophie, weniger zu kontrollieren und stattdessen mehr Eigenverantwortung und Engagement zu fordern. So könnte ein für alle Projektbeteiligten zufriedenstellenderes Ergebnis entstehen, als es mit festgeschriebenen Pflichtenheften in einer Welt der sich wandelnden Anforderungen möglich ist.

Grenzen der Anwendbarkeit von XP

XP ist in Bezug auf die Projektdokumentation und auf die Einbindung von Kunden eine durchaus revolutionäre Vorgehensweise. Entsprechend gibt es eine Reihe von Einschränkungen und Anforderungen an Projektgröße und Projektumfeld, die für XP gelten. Diese werden unter anderem in [Bec04, TFR02, Boe02] erörtert. XP ist vor allem für Projekte bis zu zehn Personen gut geeignet [Bec04], aber es ist eine offensichtliche Problematik, XP für große Projekte zu skalieren, wie dies zum Beispiel in [JR01] diskutiert wird. XP ist eben nur eine weitere Vorgehensweise im Portfolio der Softwaretechnik, die wie viele andere Techniken auch nur unter den gegebenen Prämissen eingesetzt werden kann.

Die Grundannahmen, Techniken und Konzepte von XP führen zu einer relativ starken Polarisierung der Meinungen. Auf der einen Seite glauben Programmierer manchmal, dass XP das Hacking zur Vorgehensweise erhebt. Auf der anderen Seite wird XP nicht ganz ernst genommen, weil es vieles irgnoriert, was in den letzten Jahrzehnten an Entwicklungsprozessen erarbeitet worden ist. Tatsächlich ist beides nur sehr bedingt richtig. Zum einen können Hacker tatsächlich leichter zu einer XP-artigen Vorgehensweise als zu einem Vorgehen nach dem RUP motiviert werden. Zum anderen erkennen viele Softwareentwickler bei genauerer Betrachtung bereits bisher gelebte Entwicklungspraktiken wieder. Außerdem ist XP in seiner Vorgehensweise sehr rigoros und erfordert Disziplin in der Umsetzung.

Sicherlich richtig ist, dass XP eine leichtgewichtige Softwareentwicklungsmethode ist, die explizit als Gegengewicht zu schwergewichtigen Methoden wie dem RUP [Kru03] oder dem V-Modell XT [HH08] positioniert ist. Wesentliche Unterschiede stellen die Konzentration alleine auf den Code als Ergebnis und die Einbeziehung der Bedürfnisse der Projektbeteiligten dar. Der interessanteste Unterschied ist aber die gesteigerte Fähigkeit von XP auf Änderungen des Projektumfelds oder der Anforderungen der Anwender flexibel zu reagieren. Aus diesem Grund gehört XP zur Gruppe der „agilen Methoden“.

Die Fehlerbehebungskosten in XP-Projekten

Eine der grundlegenden Annahmen in XP stellt wesentliche Erkenntnisse der Softwaretechnik infrage. Während man bisher davon ausgegangen ist, dass die Kosten zur Behebung von Fehlern oder zur Durchführung von Änderungen wie in [Boe81] beschrieben exponentiell mit der Zeit steigen, geht XP davon aus, dass diese im Projektverlauf abflachen. Abbildung 2.3 zeigt diese beiden Kostenkurven schematisch.

In XP wird angenommen, dass die Änderungskosten sich mit der Zeit nicht mehr dramatisch erhöhen [Bec04, Kap. 5]. Diese Annahme von XP ist nicht empirisch belegt, birgt aber wesentliche Implikationen für die Anwendbarkeit von XP. Wird davon ausgegangen, dass mit XP die Kostenkurve abgeflacht werden kann, dann ist die initiale Entwicklung einer weitgehend korrekten und für alle noch kommenden Anforderungen ausbaufähigen Architektur tatsächlich nicht mehr essentiell. Die gesamte Wirtschaftlichkeit des XP-Ansatzes basiert daher auf dieser Annahme.

Es gibt allerdings Anhaltspunkte, die zumindest für eine gewisse Abflachung der Kostenkurve in XP sprechen. Durch die Nutzung besserer Sprachen wie Java, besserer Web- und Datenbanktechnologie und die Verbesserung der Entwicklungspraktiken, die sich auch in Codierungsstandards widerspiegeln, sowie bessere Werkzeuge und Entwicklungsumgebungen können Mängel schneller und umfassender behoben werden. Auch Mängel, die nicht an einer Stelle lokalisiert sind, können aufgrund des gemeinsamen Codebesitzes ohne größere Planung und Diskussionsrunden behoben werden. Der Verzicht auf Dokumentation verhindert die Notwendigkeit erstellte Dokumente konsistent zu halten. Demgegenüber steht der Aufwand, die automatisierten Tests nachzuziehen. Allerdings bietet die Automatisierung den wesentlichen Vorteil einer effizienten Erkennung von nicht mehr korrekten Tests gegenüber dem aufwändigen Korrekturlesen von schriftlicher Dokumentation.

Einer der wesentlichsten Indizien für eine reduzierte Kostenkurve ist aber die Vorgehensweise in kleinen Iterationen. Fehler und Mängel, die sich in einer Iteration lokalisieren lassen, haben nur innerhalb dieser Iteration eine mit der Zeit exponentiell ansteigende Wirkung. In darauf folgenden Iterationen bleibt die Wirkung allerdings begrenzt, so dass dann nur noch ein langsamer Anstieg der Fehlerbehebungskosten zu erwarten ist. Die iterative Vorgehensweise, eventuell gekoppelt mit der Dekomposition des Systems in Subsysteme führt daher möglicherweise zu der in Abbildung 2.4 dargestellten Kostenkurve, die zum Beispiel auch in dem Auktionsprojekt zu finden war.¹

Abhängig von der Lokalisierbarkeit des Fehlers innerhalb eines Teils des Systems kann in der verursachenden und den unmittelbar darauf aufbauenden Iterationen ein gewisser Anstieg der Fehlerbehebungskosten entstehen. In späteren Iterationen sollte sich dann nur noch der Aufwand zur Identifikation des Mangels und seiner Quelle erhöhen. Für Mängel in der Architektur, die damit viele Teile des Systems betreffen, tritt die Sättigung allerdings erst sehr spät und auf hohem Niveau ein, so dass es sich im Allgemeinen lohnen dürfte einen gewissen initialen Aufwand in die Architekturmodellierung zu investieren.

Obwohl also gewisse Argumente zumindest partiell für die erreichbare Kostenreduktion sprechen, muss ein Beleg dieser Aussage durch Zahlenmaterial erst durch die Untersuchung einer ausreichenden Menge von XP-Projekten erfolgen.

Es kann jedoch als Vorteil von XP angesehen werden, dass durch die Entwicklung automatisierter Tests, die kontinuierliche Integration, das Pair Programming, die kurzen Iterationszyklen und das permanente Feedback mit den Kunden die Wahrscheinlichkeit, Fehler frühzeitig zu finden, erhöht wurde.

Beziehung zwischen XP und CMM

In dem Artikel [Pau01] wurde durch einen der Autoren des Capability Maturity Models (CMM) festgestellt, dass XP und das Software-CMM [PWC⁺95] keine unvereinbaren Widersprüche darstellen, sondern sich ergänzen. XP besitzt demzufolge gute Entwicklungspraktiken, die Kernanforderungen des CMM erfüllen. XP bietet für viele vom CMM geforderte „key process areas“ (KPA) der fünf CMM-Levels teilweise eigenwillige, jedoch für den von der XP-Vorgehensweise abgedeckten Projektbereich gut geeignete Praktiken, die die Ziele des CMM adressieren. Der Artikel [Pau01] schlüsselt die Unterstützung der KPA’s durch XP in einer Tabelle einzeln auf, in der von 18 KPA’s sieben negativ und elf positiv bis sehr positiv bewertet wurden. Von den negativ bewerteten können allerdings das Trainingsprogramm aufgrund des Pair Programming von Experten mit Neulingen ebenfalls als positiver bewertet und das Management von Unterverträgen vernachlässigt werden. [Gla01] beschreibt übereinstimmend dazu, dass der XP-Ansatz ohne Mühe CMM-Level 2 einhält und der projektbezogene Anteil von CMM-Level 3 ebenfalls ohne viel Zusatzaufwand erreichbar ist. CMM-Level 3 erfordert allerdings projektübergreifende, unternehmensweite Maßnahmen, die durch XP nicht adressiert werden.

Zusammenfassend kommt [Pau01] zu dem nachvollziehbaren Schluss, dass XP gute Techniken beinhaltet, die Unternehmen durchaus in Betracht ziehen könnten, aber sehr kritische Systeme nicht ausschließlich mit XP-Techniken realisiert werden sollten.

Erkenntnisse aus den Erfahrungen mit XP

XP stellt einen leichtgewichtigen Prozess aus kohärenten Techniken zur Verfügung, der durch die Fokussierung auf den Code wesentlich effizienter gestaltet werden kann als zum Beispiel der RUP. Durch die Effizienz werden gleichzeitig weniger Ressourcen benötigt und der Prozess flexibler. Mit der gestiegenen Flexibilität wird eines der Grundprobleme der Softwareentwicklung, der Behandlung von sich über die Projektlaufzeit verändernden Anwenderanforderungen, gemildert.

Um die Qualität des entwickelten Produkts zu sichern, werden Pair Programming und rigorose automatisierte Tests gefordert, ohne aber auf eines der seit langem bekannten Testverfahren zurückzugreifen. Eine weitere Steigerung der Qualität und der Effizienz wird durch die permanente Forderung nach Einfachheit erreicht.

Aufgrund der vorliegenden Analyse von XP, die teilweise aus der Literatur und teilweise aus eigenen Projekterfahrungen unter anderem bei dem in Anhang D, Band 1 beschriebenen Auktionsprojekt beruht, lässt sich XP als eine für kleine Projekte im Bereich von ungefähr 3-15 Personen geeignete Vorgehensweise einstufen. Durch geeignete Maßnahmen, wie zum Beispiel der hierarchischen Dekomposition von größeren Projekten entlang von Komponenten [JR01, Hes01] und die damit einhergehenden zusätzlichen Aktivitäten, lässt sich XP begrenzt auf größere Aufgaben skalieren.

Umgekehrt kann jedoch auch versucht werden, die Größe der Aufgabe durch Verwendung innovativer Technik zu verringern. Dazu gehört die Wiederverwendung und Adaption eines vorhandenen Systems, soweit dies möglich ist.

Insbesondere gehört dazu aber die Weiterentwicklung von Sprachen, Werkzeugen und Klassenbibliotheken. Viele mit technischem Code behaftete Programmteile, zum Beispiel zur Ausgabe, Speicherung oder Kommunikation von Daten, sind sich strukturell ähnlich. Wenn diese Programmteile generiert und mit einer abstrakten Darstellung der Applikation zu lauffähigen Code komponiert werden können, dann ergeben sich weitere Steigerungen der Effizienz von Entwicklern. Dies gilt für den Produktionscode, aber vielmehr noch für die Entwicklung von Tests, die bei abstrakter Modellierung durch Diagramme außerdem besser verständlich sind.

Eine Verwendung einer ausführbaren Teilsprache der UML als High-Level-Programmiersprache muss dementsprechend zum Ziel haben, Modelle noch effizienter zu entwickeln und in Code umzusetzen und damit eine weitere Beschleunigung der Softwareentwicklung zu bewirken. Idealerweise reduziert sich der Entwurfs- und Implementierungsanteil eines Projekts soweit, dass ein Projekt vor allem aus der Erhebung von Anforderungen besteht, die effizient und direkt umgesetzt werden können.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>