Theorie "Agile Methode Extreme Programming"

Extreme Programming, kurz XP, ist eine Methode, die das Lösen einer Programmieraufgabe in den Vordergrund stellt und dabei einem formalisierten Vorgehen geringe Bedeutung beimisst. Mit dieser Methode nähert man sich den Kundenanforderungen in kleinen Schritten an. Es fand seinen Ursprung im Projekt "Comprehensive Compensation System" des ehemaligen Daimler Chrysler Konzerns und fußt auf der Anwendung bewährter Methoden (best practices). In diesem Projekt wurde XP als agiles Vorgehensmodell für die Erstellung von Software entwickelt.

Diese agile Arbeitsmethode basiert auf den Werten der Einfachheit, Kommunikation, Feedback, Mut und Respekt. Neben den fünf Values (Werten) kennt XP auch Principles (Prinzipien) und Practices (Techniken), die sich auch in Kanban wiederfinden - wenn auch anders formuliert.

Ähnlich dem Scrum Framework kennt XP ebenfalls Rollen. Diese sind im Wesentlichen der Kunde (Auftraggeber), der Product Owner (intern, häufig Projektmanager) und das Entwicklerteam.

Rahmenbedingungen¶

Values¶

Grundlage des Extreme Programmings bilden fünf Werte, die die Arbeit des Projektteams verbessern sollen.

Communication¶

Alle Projektmitglieder sollen möglichst direkt miteinander kommunizieren. Dadurch lassen sich Missverständnisse schneller ausräumen und Fragen können schneller und gezielter beantwortet werden.

Courage¶

Sich an Werten zu orientieren und die dabei praktizierte, offene und direkte Kommunikation erfordern Mut. Eine kontinuierliche Anpassung an Veränderungen und die Reduzierung der Kundenanforderungen auf das Wesentliche sind besonders für die Projektbeteiligten, die das Handeln nach diesen Werten nicht gewohnt sind, eine Herausforderung.

Feedback¶

Durch das direkte, zeitnahe und kontinuierliche Kundenfeedback lässt sich die Qualität des Produktes verbessern. Eine mögliche Fehlentwicklung kann schnell erkannt und gebannt werden. Der Kunde bekommt das Produkt, das er benötigt.

Respect¶

Der Kunde respektiert das Know-how der Entwickler und umgekehrt. Jeder gibt und erfährt den Respekt und die Wertschätzung, die jedes Projektmitglied verdient.

Simplicity¶

Einfache Lösungen lassen sich schneller implementieren als komplexe Lösungen und sind in aller Regel kostengünstiger. Deshalb wird immer versucht, die einfacheren Lösungen zu finden.

Principles¶

XP basiert auf Prinzipien, die sich aus den Werten ableiten. Die einzelnen Prinzipien dienen dem Grundverständnis von XP.

Accepted responsibility¶

Verantwortung übernehmen: Verantwortung wird nicht delegiert oder zugewiesen, sondern angenommen. Dadurch identifiziert der Zuständige sich deutlich stärker mit seiner Aufgabe.

Assume simplicity¶

Einfachheit anstreben: Einfache Lösungen sind schneller zu implementieren, kostengünstiger und lassen sich einfacher verstehen und warten. Je niedriger der Komplexitätsgrad einer Lösung, desto einfacher kann Feedback gegeben werden.

Concrete experiments¶

Gezielte Experimente: Um potenzielle Risiken zu reduzieren, werden Entscheidungen durch zielgerichtete Experimente untermauert.

Embracing change¶

Veränderung wollen: Die Projektbeteiligten zeigen sich Veränderungen gegenüber aufgeschlossen und unvoreingenommen.

Honest measurement¶

Ehrliches Messen: Für die Lenkung des Projektes und den Projektfortschritt sind Messungen erforderlich. Diese sind von den Projektbeteiligten transparent, ehrlich und nachvollziehbar durchzuführen.

Incremental change¶

Inkrementelle Veränderung: Veränderungen sollten in kleinen Einheiten vorgenommen werden. Diese sind leichter nachvollziehbar und weniger komplex und abhängigkeitsbehaftet (dependencies) als umfangreiche Änderungen.

Local adaptions¶

An örtliche Gegebenheiten anpassen: XP wird an die lokalen Bedürfnisse und Gegebenheiten angepasst.

Open, honest communication¶

Offene, aufrichtige Kommunikation: Die Projektmitglieder praktizieren aktiv eine ehrliche, offene und direkte Kommunikation.

Play to win¶

Auf Sieg spielen: Diese Denkweise in XP zielt auf den Erfolg des Projektes ab. Die Entwickler sind nicht nur bestrebt fehlerfreie Programmfunktionen zu implementieren, sondern ein in sich stimmiges Gesamtpaket. Das bedeutet nicht, dass dies bei anderen Arbeitsmethoden nicht der Fall ist - bei XP geht es aber eben nicht nur um einen fehlerarmen Code.

Quality work¶

Qualitätsarbeit: Einen enormen Anteil an der Qualität des Produktes haben die Anwender durch ihr Feedback. Wohlformuliertes (sowohl negatives, als auch positives) Feedback ist ein wesentlicher Faktor für die Arbeitszufriedenheit des Entwicklerteams. Deshalb ist es erforderlich, dem Entwicklerteam die Umgebungsparameter so zu gestalten, dass Qualitätsarbeit möglich ist.

Rapid feedback¶

Unmittelbares Feedback: Die Rückmeldung zu den Aktivitäten sollte zeitnah eingeholt werden bzw. erfolgen. Feedback ist hier auch explizit ein Element der Qualitätssicherung.

Small initial investment¶

Geringe Anfangsinvestition: Durch die Fokussierung auf die wesentlichen Funktionen werden schnell erste nutzbare Prototypen umgesetzt.

Teach learning¶

Lernen lehren: Projektmitglieder sollen lernen, was sie für die Erreichung ihrer Ziele benötigen, z. B. welche und wie viele Software-Tests durch die Entwickler zu schreiben sind.

Travel light¶

Mit leichtem Gepäck reisen: Es gibt wenig Regulierung in Bezug auf Werkzeuge, Mittel und Methoden. Das Projekt sollte durch wenige, aber effektive Tools unterstützt werden.

Work with people's instincts, not against them¶

Instinkte des Teams nutzen, nicht dagegen arbeiten: Auch wenn ungewöhnliche Wege zum Erreichen des Ziels beschritten werden - dem Team ist das notwendige Vertrauen entgegenzubringen.

Practices¶

Die Werte und Prinzipien werden durch Techniken ergänzt. Diese Techniken sollen den Entwicklern helfen, sich entsprechend der Prinzipien zu verhalten.

Management-Techniken¶

Onsite customer (Kunden vor Ort): Um Anforderungen und Fragen direkt klären zu können, ist die Anwesenheit eines Ansprechpartners des Kunden erforderlich. Häufig übernimmt diese Rolle der Projektmanager.

Planning game (Planungsspiel): Vor jeder Iteration werden die Inhalte der nächsten Iteration mit allen Projektmitgliedern, inkl. des Kunden bzw. dessen Vertreter (interner Projektmanager), besprochen und geplant. Voraussetzung dabei ist, dass bekannt ist, wie lange für User Stories in der Vergangenheit gebraucht wurde und dass bekannt ist, wie gut die Qualität der Einschätzung der Programmierer ist.

Short releases (Kurze Releasezyklen): Neue Auslieferungen sollen in kurzen Zeitabständen, z. B. täglich, erfolgen. Kunden erhalten somit schnell und häufiger Zugriff auf neue oder veränderte Funktionen. Dadurch wird der Kunde in die Lage versetzt, zeitnah Feedback an das Entwicklerteam geben zu können und mögliche Fehlentwicklungen rasch zu signalisieren. Außerdem ermöglichen kurze Releasezyklen dem Kunden den frühestmöglichen Nutzen.

Team-Techniken¶

Coding standards (Programmierstandards): Jeder Entwickler darf alle Codezeilen bearbeiten. Um in der Praxis die gemeinsame Verantwortung des Codes umzusetzen, sollte ein gemeinsamer Standard für das Schreiben des Codes Anwendung finden.

Continuous integration (Fortlaufende Integration): Um zu viele Abhängigkeiten (dependencies) zu vermeiden und dem Kunden ein zeitnahes Feedback zu ermöglichen, werden die Änderungen zeitnah integriert.

Collective ownership (Gemeinsame Verantwortung): Jeder Entwickler kann und darf zu jedem Zeitpunkt alle Codezeilen bearbeiten. Damit werden Entwickler in die Lage versetzt, Aufgaben eines anderen Entwicklers zu übernehmen. Alle Entwickler sind gemeinsam, als Kollektiv (Team), für das Ergebnis verantwortlich.

Metaphor (Metapher): Wenige, eindeutig formulierte Metaphern sollen das zu entwickelnde System beschreiben. Allen Projektmitgliedern soll die Aufgabe des Systems klar sein.

Sustainable pace (Nachhaltiges Tempo): Programmierer sollten nicht mehr als die Regelarbeitszeit arbeiten. Überstunden sind zu vermeiden oder zeitnah durch Erholung auszugleichen. Entwickler sind dann kreativer und engagierter, wenn sie ausgeruht sind.

Programmiertechniken¶

Pair programming (Programmieren in Paaren): Der gesamte Code wird von zwei Personen erstellt, die gemeinsam an einer Aufgabe an einem Arbeitsplatz arbeiten. Ein Programmierer hat die Kontrolle über den Rechner und kümmert sich hauptsächlich um den Code im Detail. Der andere Programmierer konzentriert sich mehr auf das große Ganze und überprüft ständig den Code, der von dem ersten Programmierer erstellt wird. Dieser Ansatz hilft, Quellcodefehler und Mängel im System zu vermeiden.

Refactoring: Darunter versteht man die Umstrukturierung des Quellcodes unter Beibehaltung seiner Funktionalität, um Fehler in der Struktur zu korrigieren oder Quellcode zu vereinfachen. Das Auftreten von Nebeneffekten (side effects) soll durch Komponententests vermieden werden.

Simple design (Einfaches Design): Je einfacher das System, desto einfacher, schneller und kostengünstiger kann es umgesetzt werden. Die weiteren, sich ergebenden Vorteile sind leichtere Wartbarkeit, Nachvollziehbarkeit, Test- und Erweiterbarkeit.

Testing (Testen): Der Quellcode ist mit automatisierten Komponententests zu validieren. Der Anwender prüft die Erfüllung der Anforderungen im Rahmen von Akzeptanztests, welche dazu dienen, dem Kunden zu zeigen, ab wann der Quellcode lauffähig ist und welche Aufgaben die Developer noch erledigen müssen.

Extreme Programming (XP) Lifecycle¶

Mit XP einen Mehrwert schaffen¶

Der Lebenszyklus von Extreme Programming lässt sich am besten anhand des wöchentlichen und des vierteljährlichen Zyklus beschreiben.
Zu Beginn werden vom Kunden ein Set an User Stories definiert, deren Größe vom Entwicklerteam geschätzt werden. Zusammen mit dem vom Kunden geschätzten relativen Nutzen, ergibt das einen Wert, welcher die relative Priorität der User Stories widerspiegelt.

Falls einige User Stories aufgrund unklarer technischer Umsetzung von den Entwicklern nicht abgeschätzt werden können, wird stattdessen ein "Spike" eingeführt. Spikes sind tiefergehende, zeitlich begrenzte Analysen dieser Stories und können vor Beginn einer Iteration oder parallel zu bereits laufenden Iterationen stattfinden.

Anschließend wird der Release-Plan aufgestellt. Dieser Plan umfasst alle User Stories, die in einem Release oder in einem bestimmten Quartal ausgeliefert werden sollen.

Nun kann mit den Zyklen begonnen werden, diese haben i. d. R. einen Umfang von ein bis zwei Wochen. Zu Beginn eines jeden Durchlaufs trifft sich das Team mit dem Kunden und entscheidet, welche Stories bearbeitet werden. Diese werden danach in Tasks unterteilt und innerhalb des anstehenden Zyklus umgesetzt.

Zwischen den Zyklen und meist an Wochenenden, findet eine Überprüfung des bisherigen Fortschrittes zwischen dem Team und dem Kunden statt. Dabei wird entschieden, ob das Projekt fortgesetzt werden soll oder ob bereits genügend Wert für einen Projektabschluss geliefert wurde.

Scrum vs. Extreme Programming¶

Abgrenzung zwischen Scrum und Extreme Programming¶

Scrum ist ein Framework, das keine Aussage über die Art und Weise der Realisierung eines Software-Projektes trifft. Extreme Programming hingegen ist eine Software-Entwicklungsmethode, eine agile Arbeitsmethode, die den gesamten Lebenszyklus eines Projektes umfasst.

Unterschiede¶