extreme Programming ( XP ) explained

Versprechungen

Paradigma

vier moralische Werte

Prinzipien

asymptotische Änderungskostenkurve

Basisaktivitäten

Praktiken

Als mentales Modell beschreibt Kent Beck ein Kontrollbrett mit Knöpfen, die für Praktiken stehen, die sich in der Erfahrung bewährt haben.
Dreht er nun alle Knöpfe bis zur 10 auf, verwundert es ihn wenig, daß das ganze Packet an Praktiken stabil, vorhersagbar und flexibel ist.

XP macht folgende Versprechungen:

Programmierern verspricht es, sie in die Lage zu versetzen, jeden Tag die wirklich wichtigen Dinge zu tun.
Sie müssen keine kritischen Situationen alleine bewältigen.
Sie werden in der Lage sein, alles in ihrer Macht stehende zu tun, ihr System erfolgreich zu machen.
Sie werden Entscheidungen zu treffen haben, die am besten sie machen können und solche Entscheidungen, für die sie nicht qualifiziert sind, werden sie nicht zu treffen haben.

Kunden und Managern verspricht sie, den größt möglichen Wert aus jeder Woche Programmierung herauszuholen.
Alle paar Wochen werden sie den konkreten Fortschritt in den Zielen sehen, um die sie sich sorgen.
Sie werden in der Lage sein, die Richtung des Projekts in der Mitte der Entwicklung zu ändern, ohne exorbitante Kosten erwarten zu müssen.

XP verwendet als Paradigma die Metapher des Autofahrens.
Fahren ist dabei nicht, das Auto in die richtige Richtung fahren zu lassen.
Beim Fahren geht es darum, ständig absolut aufmerksam zu sein und leichte Korrekturen in der einen oder leichte Korrekturen in der anderen Weise zu machen.
Das ist das Leben eines Programmierers: Selbst wenn es perfekt geht nimmt er die Augen nicht von der Straße. Wechsel ist die einzige Konstante.
Immer bereit sein sich ein bißchen in diese oder jene Richtung zu bewegen. Manchmal sogar in die entgegengesetzte Richtung.
Der Fahrer eines Softwareprojekts ist der Kunde. Wenn die Software nicht tut, was er will, haben die Entwickler versagt. Natürlich wissen Kunden nicht genau, was sie wollen.
Deshalb ist Softwareentwicklung wie Lenken, nicht das Auto gerade auf der Strasse auszurichten. Die Arbeit von Programmierern ist es dem Kunden das Lenkrad zu geben und Rückkopplung zu bieten, wo er sich auf der Strasse befindet.

Zu dem Paradigma des Autofahrens kommen vier moralischen Werte, die sowohl den menschlichen als auch den kommerziellen Bedürfnissen dienen:

Kommunikation
Einfachheit
Rückkopplung
Mut

Schnelle Rückmeldung
Unterstellte Einfachheit
Inkrementelle Änderungen
Qualitätsarbeit

Lehren zu Lernen
kleine Anfangsinvestitionen
Spielen, um zu gewinnen
konkrete Experimente
offene, ehrliche Kommunikation
Arbeiten mit den Leuten, nicht gegen sie
akzeptierte Veranwortlichkeit
leichtes Reisegepäck
ehrliche Messungen

Aus den vier moralischen Werten, den Prinzipien und der neuen Änderungskostenkurve wird eine Disziplin der Softwareentwicklung gebildet.
Softwareentwicklung besteht aus den vier Basisaktivitäten:

Codieren

Das Wichtigste an Code ist daraus zu lernen. Der Weg zu lernen ist, einen Gedanken zu haben und ihn zu prüfen, ob es ein guter Gedanke war.
Code schwankt nicht unter der Macht und Logik der Rhetorik; Code läßt sich nicht durch Schulnoten oder Verkaufszahlen beeindrucken;
er sitzt einfach da, glücklich genau das zu tun, was ihm gesagt wurde. Wenn er nicht tut, was gedacht wurde das ihm gesagt wurde, liegt das Problem woanders.
Code bietet die Möglichkeit klar und prägnant zu kommunizieren; er läßt die Logik und präzise Form von Ideen sichtbar werden.
Durch diese Kommunikation läßt es sich lernen; verwandte Ideen anderer resultieren in verwandtem Code.
Letztlich ist der Code das Artefakt der Softwareentwicklung, ohne das man nicht auskommt. Deshalb sollte er für alle Bewandnisse des Softwareengineering benutzt werden.
Zur Kommunikation: Ausdruck taktischer Intentionen, Beschreibung von Algorhitmen, mögliche zukunftige Erweiterungen oder Zusammenfassungen.
Zum Testen: einerseits das objektive Testen und andererseits das wertvolle Spezifizieren der Operationen des Systems

Tests sagen, wann man fertig ist - wenn der Test erfolgreich läuft ist man für den Moment fertig. Wenn einem kein Test, der schiefgehen könnte, mehr einfällt, ist man komplett fertig.
Tests sind Resourcen und Verantwortung zugleich. Eines der Prinzipien ist mit der menschlichen Natur zu arbeiten, nicht gegen sie.
Als Langzeit-Argument für das Testen steht, das man länger Anderungen am System machen kann und das das Vertrauen in das System mit der Zeit wächst, aber es ist aus individueller, kurzfristiger Sicht ein schwer durchsetzbares Argument.
Kurzfristig betrachtet ist Codieren und Testen zusammen schneller als nur Programmieren, der Zeitgewinn entsteht durch die Reduzierung des zeitaufwendigen Debuggens. Damit kann das persönliche Vertrauen zur geleisteten Arbeit, wegen der schnellen Rückmeldung, steigen.
Mitunter können Tests, die gar nicht erst gefahren werden können, größere Probleme im Design aufdecken. Schlechtes Testen kann auf der anderen Seite falsches Vertrauen erwecken und damit mehr schaden als nützen. Der Trick besteht darin, das richtige Niveau an Defekten zu finden, das tolerabel ist.

Programmierer wissen nichts und schon gar nichts darüber, was Geschäftsleute für interessant halten. Deshalb müssen sie fragen, um die Antworten der Tests mit den erwarteten vergleichen zu können oder  auch um einige ungewöhnliche Fälle aus Geschäftssicht zu erfahren. Um auf die Antworten vorbereitet zu sein, bedarf es einer adäquaten Kommunikationsstruktur.

Gestalten kreiert eine Struktur, die die Logik eines Systems organisiert. Ein guter Entwurf organisiert die Logik so, daß Änderungen an einem Teil des System nicht Änderungen an einem anderen nach sich ziehen. Gutes Gestalten gibt jedem logischen Teil genau ein Zuhause, legt die Logik nahe an die Daten auf denen sie operiert und erlaubt Erweiterungen des Systems durch Änderungen an nur einer Stelle.

Codiert wird, weil man nichts getan hat, wenn man nicht codiert.
Getestet wird, weil man nicht weiß, wann man fertig ist, wenn man nicht testet.
Zugehört wird, weil man nicht weiß was zu codieren oder zu testen ist, wenn man nicht zuhört.
Gestaltet wird, damit Codieren, Testen und Zuhören auf unbefristet fortgesetzt werden kann.

Planspiel

Den Geschäftsleuten obliegen die Entscheidungen über den Umfang, die Priorität, die Zusammensetzung und das Datum von Ausgaben/Versionen.
Den Technikern obliegen die Entscheidungen über Schätzungen, die Konsequenzen, den Prozess und detailierte Arbeitsvorbereitung.
Da weder die Geschäftsleute noch die Entwickler ihre Entscheidungen in einem Vakuum treffen können, bedarf es eines Dialogs, bei dem die Techniker das Rohmaterial für Geschäftsentscheidungen liefern.

Ausgleich der Schwäche, die Entwicklung nicht mit einer vagen Vorstellung beginnen zu können:
Der Kunde macht den Plan
oder man hat genug Ideen, um dem Kunden eine grobe Vorstellung des Systems zu vermitteln
oder man erstellt kurzzeitige kleine Ausgaben, damit ein Fehler im Plan nur kurze Auswirkung hat
oder der Kunde ist im Haus beim Team, damit potentielle Änderungen und Verbesserung schnell zu machen sind.

Jede Ausgabe des Softwaresystems soll so klein wie möglich sein und dabei die wertvollsten Geschäftsanforderungen erfüllen. Die Ausgabe muß als Ganzes Sinn machen, nur die Hälfte zu liefern, um den Zyklus zu verkürzen, ist Unsinn.

Ausgleich der Schwäche, eventuell nicht nach ein paar Monaten anfangen zu können:
Das Planspiel hat die wertvollsten Geschichten herausgearbeitet, mit denen selbst ein kleines System Geschäftswert hat.

Jedes XP Projekt wird von einer umfassenden Metapher geleitet. Die Metapher hilft allen Beteiligten die grundlegenden Elemente und deren Beziehungen zu verstehen.
Metapher ist der Ersatz für Architektur, um den Beteiligten eine koherente Geschichte zu geben, die leicht von Geschäftsleuten, Entwicklern und Kunden geteilt werden kann und mit Hilfe derer man kommunizieren kann.

Ausgleich der Schwäche, die Metapher ist nicht detailliert genug oder sogar falsch:
Man hat Rückmeldung von echtem Code und Tests, ob die Metapher in der Praxis funktioniert
oder der Kunde ist zufrieden, in der Metapher über das Sytem zu sprechen
oder man überarbeitet ständig das Verständnis, was die Metapher in der Praxis bedeutet.

Der richtige Entwurf erfüllt zu jeder Zeit,
daß alle Tests laufen,
daß keine Logik doppelt vorkommt, wie z.B. parallele Klassenhierarchien,
daß er jede wichtige Intention des Programmierers zeigt,
und daß er die wenigst möglichen Klassen und Methoden enthält.

Ausgleich der Schwäche, nicht genug Entwurf für den heutigen Code zu haben oder sich mit dem Entwurf in eine Ecke manövriert zu haben:
Man ist so geübt im Überarbeiten, sich keine Sorgen zu machen
oder die Metapher ist klar genug, zukünftige Entwurfsänderungen einen konvergenten Pfad folgen zu lassen
oder man ist zuversichtlich ein einfaches und kein dummes Design zu haben, weil man mit einem Partner programmiert.

Ein Programmbestandteil ohne automatisierten Test existiert einfach nicht.
Programmierer schreiben Tests für Einheiten(Modul), damit das Vertrauen in das Programm bei ihnen wächst und somit eventuell in die Software eingehen kann.
Kunden schreiben funktionale Tests damit ihre Zuversicht in die Operationen des Systems wächst und somit ebenfalls in das Programm eingehen kann.
Letztlich entsteht ein mehr und mehr vertrauenswürdiges Programm, das auch Veränderungen leichter und nicht schwerer verkraftet.

Ausgleich der Schwäche, nicht alle Tests schreiben zu können und Programmierer hassen Tests:
Der Entwurf ist so einfach, wie er nur sein kann; dann ist es nicht schwierig die Tests zu schreiben.
Man programmiert mit einem Partner, dem ein weiterer Test einfällt, oder man zieht ihm die Tastatur weg, weil er den nächsten Test auslassen will.
Die Programmierer fühlen sich gut, wenn alle Test erfolgreich abgeschlossen werden können.
Der Kunde hat ein gutes Gefühl bei dem System, wenn er seine Tests erfolgreich bestehen sieht.

Wenn ein Programmierer einen Programmteil implementiert, fragt er immer zunächst, ob er das bestehende Programm ändern kann, um die Fähigkeit einfacher zu ergänzen.
Wenn das Merkmal ergänzt wurde, fragt der Programmierer, ob die einfachere Lösung sichtbar ist und alle Tests immer noch laufen.
Diese Überarbeitungen bedeuten manchmal mehr Arbeit als unbedingt nötig, um eine Fähigkeit hinzuzufügen, aber sie stellt sicher, daß weitere Bestandteile leicht implementiert werden können.

Ausgleich der Schwäche, das System nicht kontnuierlich überarbeiten zu können, weil es zu lange dauert, es schwer zu kontrollieren ist und es leicht das System stören kann:
Man ist an das gemeinsame Eigentum gewöhnt und macht sich keine Sorgen, Änderungen zu machen, wo sie nötig sind.
Man hat einen Codierungsstandard, so daß man nicht umformatieren muß.
Man programmiert in Paaren, so daß man mehr Mut hat, schwierige Überarbeitungen anzugehen und man weniger leicht, etwas kaputt macht.
Man hat einen einfachen Entwurf, der die Überarbeitung leicht macht.
Man hat die Tests, so daß man schwierig etwas kaputtmachen kann, ohne es zu merken.
Man hat die Kontinuierliche Integration, so daß, wenn man etwas woanders kaputtmacht oder die Überarbeitung Konflikte verursacht, man es innerhalb kürzester Zeit erfährt.

Der gesamte Code, der produziert wird, wird von zwei Menschen an einer Maschine, mit einer Tastatur und Maus geschrieben.
Während der eine Programmierer überlegt, wie er diese eine Methode genau jetzt implementiert, denkt der andere mehr strategisch:
funktioniert der ganze Ansatz; gibt es andere Testfälle, die fehlschlagen; existiert eine Vereinfachungsmöglichkeit, damit das Problem verschwindet ?

Ausgleich der Schwäche, es könnte zu langsam sein oder man versteht sich nicht :
Der Codierungsstandard verhindert Kabbeleien über den Stil.
Das Paar schreibt zusammen die Tests damit sie ein gemeinsames Verständnis gewinnen, bevor sie implementieren.
Das Paar kennt die Metapher ihre Grundentscheidungen über Benennung und Design zu begründen.
Das Paar arbeitet innerhalb des einfachen Entwurfs, damit sie beide wissen, was vor sich geht.

Jeder Programmierer, der eine Möglichkeit sieht, wertvolle Ergänzungen an irgendeinem Teil des Codes zu machen, ist aufgefordert das zu jeder Zeit zu tun.

Ausgleich der Schwäche, mancheiner macht rechts und links etwas kaputt und die Kosten der Integration steigen dramatisch :
Man integriert nach kurzer Zeit, um die Möglichkeit von Konflikten zu verringern.
Man schreibt und fährt Tests, um die Möglichkeit etwas aus Versehen kaputt zu machen zu verringern.
Man programmiert paarweise, um die Möglichkeit Code zu zerstören zu verringern und die Programmierer lernen profitable Änderungen durchzuführen.
Man benutzt Codierungsstandard, um den Geschweifte-Klammern-Krieg zu verhindern.

Der Programmcode wird alle paar Stunden, höchstens nach einem Tag, getestet und integriert. Ein Paar lädt seinen aktuellen Code, am besten auf einer eigenen Integrationsmaschine,
und fährt alle Tests, bis diese 100% laufen. Geht etwas schief, kann es nur am letzten, integrierten Code liegen; also wird er weggeworfen, weil das Paar offenbar nicht genug wußte, was es nun gelernt hat.

Ausgleich der Schwäche, nicht schnell integrieren zu können, weil es zu lange dauert, zu viele Konflikte oder Möglichkeiten gibt, etwas zu zerstören :
Man kann schnell einen Test fahren, um zu sehen, daß man nicht zufällig etwas zerstört hat.
Man programmiert paarweise; also gibt es nur halb so viele Quellen der Veränderung, die zu integrieren sind.
Man überarbeitet, so daß kleinere Bestandteile die Möglichkeit von Konflikten zu verringern.

Mehr Arbeit als 40 Stunden pro Woche ist zu vermeiden; wenn es zwei Wochen hintereinander vorkommt, hat man eine ernsthaftes Problem mit dem Projekt.

Ausgleich der Schwäche, nicht genug Wertschöpfung in 40 Stunden erzielen zu können :
Das Planspiel gewährt mehr wertvolle Arbeit zu verrichten.
Die Kombination aus Planspiel und Testen vermindert unliebsame Überraschungen, die mehr Arbeit bedeuten. als man zu haben glaubte.
Zusammen helfen alle Pratiken sowieso mit Höchstgeschwindigkeit zu programmieren.

Ein echter Kunde, jemand der das System in Produktion benutzen wird, sollte vorort verfügbar sein, um Fragen zu beantworten, Diskussion zu ermöglichen und kleinere Prioritätsentscheidungen zu treffen.

Ausgleich der Schwäche, die Person kann sonstwo produktiver eingesetzt werden :
Sie produzieren Werte für das Projekt, weil sie Tests schreiben.
Sie produzieren Werte für das Projekt, weil sie kleinere Prioritäts- und Umfangsentscheidungen für die Programmierer treffen.

Um zu ermöglichen, daß die Programmierer an verschiedenen Teilen der Software arbeiten können und um den Tausch von Programmierpartnern zu erlauben, kann sich niemand zwei oder mehr Programmierstile leisten. Das gesamte Team muß sich auf einen Standard einigen.

Ausgleich der Schwäche, daß Programmierer eher kündigen, als sich an einen Codierungsstandardzu halten :
Die Programmierer fühlen sich als Mitglieder eines Gewinnerteams in einem XP Projekt

---

Literatur

Testen

Parrington, Norman: Software-Test; McGraw-Hill, 1990 isbn:3-89028-195-8
Alper, Marcel:Professionelle Softwaretests;Vieweg, 1994 isbn:3-528-05454-9
beide ungeeignet; klassisches Wasserfallmodell; Rolle des Entwicklers als Tester verpöhnt