Extreme Programming (XP)

Nachdem das Wasserfall-Modell bereits beschrieben wurde, erfolgt nun die Vorstellung der Vorgehensweise nach Extreme Programming (XP). XP ist als Beispiel ausgewählt worden, da es den extremsten Fall von agiler Vorgehensmethodik beschreibt.

Agile Vorgehensmodelle


Die Wurzeln von XP liegen im Project C3 (Chrysler Consolidated Compensation) bei Daimler Chrysler aus den Jahren 1997 und 1998 – einem internen Abrechnungssystem für Mitarbeiter. Nachdem das Projekt zu scheitern drohte, engagierte das Unternehmen Kent Beck, Ron Jeffries, Martin Fowler und weitere Personen, um es neu aufzusetzen – mit Erfolg. Kent Beck hat die dort entstandenen Ideen zu einer Methode zusammengefasst und sie im Buch »Extreme Programming Explained – EMBRACE CHANGE« publiziert.

XP ist ein Rahmenwerk das aus drei Hauptbestandteilen besteht.

  • Werte (Values)
  • Prinzipien (Principles)
  • Techniken (Practices)

Abbildung 5 aus [Beck2004] erläutert skizzenhaft die Rahmenbedingungen, die Kent Beck jeweils mit den Werten (Values), Prinzipien (Principles) und Techniken (Practices) verbindet.

XP

Abbildung 5 – Skizze Rahmenbedingungen


Werte von XP

XP beruht auf vier Werten:

  • Einfachheit (Simplicity): Einfache Lösungen sind kostengünstiger und schneller zu realisieren als komplexe Lösungen. Deshalb versucht XP immer die einfacheren Lösungen zu finden.
  • Kommunikation (Communication): Alle Projektmitglieder sollen intensiv miteinander kommunizieren. Durch persönliche Gespräche lassen sich Missverständnisse sehr schnell ausräumen; Fragen können ebenso schnell geklärt werden. Dadurch kann auf Dokumentation an einigen Stellen verzichtet werden.
  • Feedback: Um eine hohe Qualität zu erzielen, nämlich das zu erreichen, was der Kunde benötigt, werden sehr kurze Feedback-Schleifen verwendet, um dem Kunden kontinuierlich die Entwicklung zu zeigen. Hierdurch werden durch den Kunden Fehlentwicklungen sehr schnell gestoppt. Nicht nur durch den Kunden, sondern auch durch Tests wird Feedback erreicht.
  • Mut (Courage): Diese Werte einzusetzen und dabei offen zu kommunizieren erfordert sehr viel Mut, besonders für die Projektmitglieder, die das Handeln nach diesen Werten nicht gewohnt sind. Anforderungen des Kunden auf das Wichtigste zu reduzieren, kontinuierliches Feedback und Offenheit, sowie direkte Kommunikation mit dem Kunden und anderen Projektmitgliedern erfordert Mut.

Prinzipien von XP

XP basiert auf 15 Prinzipien, die sich aus den vier Werten ableiten. Die einzelnen Punkte werden an dieser Stelle zwar nur sehr verkürzt dargestellt, ein Grundverständnis für XP kann jedoch auch so aufgebaut werden.

  • Unmittelbares Feedback (Rapid Feedback): Feedback sollte zu allen Tätigkeiten so schnell wie möglich eingeholt werden, hierdurch werden auch gute Lerneffekte erzielt.
  • Einfachheit anstreben (Assume Simplicity): Einfache Lösungen sind einfacher zu verstehen, es kann schneller Feedback eingeholt werden.
  • Inkrementelle Veränderung (Incremental Change): Kontinuierlich kleine Veränderungen vorantreiben – große Änderungen haben meist viele Abhängigkeiten.
  • Veränderung wollen (Embracing Change): Veränderungen aufgeschlossen gegenüber stehen.
  • Qualitätsarbeit (Quality Work): Ermöglicht man dem Projektteam Qualitätsarbeit, erhöht sich die Arbeitszufriedenheit. Die Entscheidung über Qualität treffen die Anwender.
  • Lernen lehren (Teach Learning): Projektmitglieder sollen lernen, selbst zu entscheiden, was sie zur Erreichung ihrer Ziele benötigen. Beispielsweise sollen Entwickler selbst entscheiden, wie viele Tests sie schreiben müssen.
  • Geringe Anfangsinvestition (Small Initial Investment): Durch Konzentration auf die wichtigsten Funktionen werden schnell erste nutzbare Systeme geliefert.
  • Auf Sieg spielen (Play to win): Das Streben nach Sieg ist eine Einstellung in XP. Es ist eine andere Motivation Fehler zu vermeiden, oder auf Sieg zu spielen.
  • Gezielte Experimente (Concrete Experiments): Um Risiken zu Minimieren, werden Entscheidungen durch gezielte Experimente untermauert.
  • Offene, aufrichtige Kommunikation (Open, honest Communication): Es wird auf offene, aufrichtige Kommunikation geachtet. Alle Projektmitglieder werden motiviert dies durchzusetzen.
  • Instinkte des Teams nutzen, nicht dagegen arbeiten (Work with people’s instincts, not against them): Auf das Team vertrauen – auch wenn es ungewöhnliche Wege einschlägt, um ein Ziel zu erreichen.
  • Verantwortung übernehmen (Accepted Responsibility): Verantwortung soll nicht zugewiesen werden, sondern sollte sich genommen werden. Hierdurch entsteht eine sehr starke Identifikation mit den Aufgaben.
  • An örtliche Gegebenheiten anpassen (Local Adaptions): XP soll an die lokalen Bedürfnisse und Gegebenheiten angepasst werden, denn alle Punkte aus dem Lehrbuch lassen sich nicht in jedem Projekt einsetzen.
  • Mit leichtem Gepäck reisen (Travel light): Nicht zu viele Tools und Methoden vorgeben, das Projekt sollte durch wenige, aber effektive Tools unterstützt werden.
  • Ehrliches Messen (Honest Measurement): Einige Messungen sind erforderlich, um Projekte zu lenken. Die Messungen müssen von den Projektmitgliedern ehrlich durchgeführt werden.

Techniken von XP

Die vier Werte und die 15 Prinzipien werden durch zwölf Techniken ergänzt. Diese Techniken sollen den Entwicklern helfen sich nach den Prinzipien zu verhalten.

Management-Techniken

  • Kunden vor Ort (On-Site Customer): Ein zentraler Ansprechpartner des Kunden muss ständig ansprechbar sein, um Anforderungen und Fragen direkt klären zu können.
  • Planungsspiel (Planning Game): Projekte nach XP verlaufen iterativ und inkrementell. Vor jeder Iteration werden die Inhalte der nächsten Iteration geplant. Alle Projektmitglieder (inkl. des Kunden) nehmen daran teil.
  • Kurze Releasezyklen (Short Releases): Neue Auslieferungen sollen in kurzen Abständen erfolgen. Kunden erhalten somit sehr schnell erforderliche Funktionen und können so sehr schnell Feedback in die Entwicklung einfließen lassen.

Team-Techniken

  • Metapher (Metaphor): Wenige klare Metaphern sollten das zu entwickelnde System beschreiben, sodass allen Projektmitgliedern der Kern des Systems klar ist.
  • Gemeinsame Verantwortung (Collective Ownership): Das gesamte Team ist für das System verantwortlich, nicht einzelne Personen. Jeder Entwickler darf an alle Codezeilen, somit ist jeder Entwickler in der Lage, die Aufgabe eines anderen Entwicklers zu übernehmen.
  • Fortlaufende Integration (Continuous Integration): Alle Änderungen am System werden sehr zeitnah integriert, somit bauen sich nicht zu viele Abhängigkeiten zwischen Änderungen auf.
  • Programmierstandards (Coding Standards): Zur gemeinsamen Verantwortung des Codes sollte es von allen einen gemeinsamen Standard für das Schreiben des Codes geben.
  • Nachhaltiges Tempo (Sustainable Pace): XP baut auf die Kreativität der einzelnen Projektmitglieder. Diese Kreativität lässt sich nicht erreichen, wenn das Projektteam dauerhaft Überstunden leistet. Es wird angestrebt, keine Überstunden zu leisten.

Programmier-Techniken

  • Testen (Testing): Alle Entwicklungen müssen getestet werden.
  • Einfaches Design (Simple Design): Das System sollte möglichst einfach gestaltet sein. So ist es einfacher zu verstehen, zu ändern und zu testen.
  • Refactoring (Refactoring): Sobald es erforderlich wird, die Struktur des Systems zu verändern, soll dies durchgeführt werden.
  • Programmieren in Paaren (Pair Programming): Es sitzen immer zwei Entwickler vor einem Computer, um die Qualität zu erhöhen und das Wissen besser zu verbreiten.

Umgang mit Anforderungen in XP

Anforderungen werden in XP in Form von User Storys auf Story Cards festgehalten. Der Kunde formuliert seine Anforderung auf einer Karteikarte in Form einer Story. Abbildung 6 zeigt ein Beispiel einer Story Card.

Story Card

Abbildung 6 – Story Card als Karteikarte


Diese Story wird vom Team grob geschätzt und vom Kunden mit Akzeptanzkriterien versehen. Wann welche User Story umgesetzt wird, wird in den jeweiligen vor einer Iteration stattfindenden Planning Meetings (Planungstreffen) festgelegt.

Die Story muss so formuliert sein, dass sie keine Technik beschreibt, jedoch so vollständig ist, dass Risiken analysiert und grobe Aufwände festgehalten werden können.

Die Details zu diesen User Storys werden erst während des Projektes vom Entwickler mit dem Kunden besprochen. Ist die Story realisiert, wird die Karte nicht aufgehoben, sondern vernichtet. Die Dokumentation der Anforderungen sind dann die geschriebenen Tests des Projektteams.

Fazit zum Einsatz von XP

Der Einsatz von Extreme Programming ist von Vorteil, wenn Anforderungen zu Beginn eines Projektes nicht vollständig vorliegen – was sehr häufig der Fall ist. Anforderungen können sich bei XP während des Projektes verändern und auch konkretisiert werden. Ebenfalls können durch falsch verstandene Anforderungen Fehler des Entwicklungsteams auf einfachem Weg behoben werden. Es wird bei XP darauf geachtet, dass die Teile eines Projektes zuerst realisiert werden, die den größten Nutzen versprechen. Somit erhalten die Auftraggeber sehr schnell die wichtigsten Funktionen.

XP hat einen hohen Anteil an Selbstorganisation. Dies setzt gewisse Mindesterfahrungen der Teammitglieder voraus. Ebenfalls setzt XP bei den Teammitgliedern auf Mut, speziell im Bereich Kommunikation. Ist dies mit den Teammitgliedern nicht möglich, ist der Einsatz von XP nicht unbedingt vorteilhaft.


Umgang mit Anforderungen

Diesen Artikel weiterempfehlen

    

Über den Autor

Die itemis AG ist ein unabhängiges IT-Beratungs­unternehmen, das leistungsfähige Software für Unternehmens­anwendungen, eingebettete Systeme und mobile Applikationen entwickelt – und über diese Themen bloggt.