Kent Beck: Extreme Programming

Kent Beck: Extreme Programming

Kent Beck
Übersetzung: Ingrid Tokar
Extreme Programming: die revolutionäre Methode für Softwareentwicklung in kleinen Teams.

2000, 186 Seiten, Hardcover
Addison-Wesley

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Das Buch Extreme Programming (XP) von Kent Beck beschreibt und begründet die gleichnamige Softwareentwicklungsmethodik mit ihren Werten, Prinzipien, Verfahren, Vorteilen und Einsatzmöglichkeiten.


Struktur

Kent Becks Buch ist dreigeteilt: als erstes wird die Ausgangslage für XP – das sogenannte „Problem“ – beschrieben. Auf dieses folgt eine eingehendere Beschreibung der „Lösung“ nämlich XP selbst. Abgeschlossen wird das Buch durch den dritten Teil „XP implementieren“ in dem detailliert auf diverse Einsatzszenarien eingegangen wird.

Inhalt

Teil 1 – Das Problem

Der erste Teil des Buches, der sich hauptsächlich mit Realitäten des beruflichen Alltags aus Sicht der Programmierer, Manager und teilweise Kunden – und gleichzeitig in einem gewissen Umfang mit Lösungen von Problemen, die aus diesen Realitäten resultieren – beschäftigt, ist in neun Kapiteln untergliedert.

Das erste Kapitel identifiziert Projektrisiken als Grundproblem der Softwareentwicklung. Beck schreibt:

Die Softwareentwicklung kann die Erwartungen nicht erfüllen. Dieses Scheitern hat weitreichende Auswirkungen im geschäftlichen und menschlichen Bereich. Wir müssen einen neuen Weg finden, Software zu entwickeln.

S. 3

Extreme Programming als Entwicklungsmethodik gibt eine Antwort darauf, wie diverse Projektrisiken, wie z.B. Terminverzögerungen, Fehler, Personalwechsel usw. besser kontrolliert werden können.

Die ökonomische Seite der Softwareentwicklung (vgl. Kapitel 3) lässt sich auf vier Optionen reduzieren: Einstellen, Ändern, Aufschieben oder Wachsen eines Projektes. Auch wenn

die Berechnung des Wertes dieser Optionen […] zu zwei Teilen Kunst, zu fünf Teilen Mathematik und zu einem Teil Augenmaß [ist]

S. 12

lässt sich laut Beck die Unsicherheit in einem Projekt durch XP reduzieren. Somit ist der Wert des Einsatzes von Extreme Programming direkt abhängig von der Höhe der Unsicherheit (ergo des Risikos). Empfohlen wird XP bei vagen oder sich ständig ändernden Anforderungen (S. 13).

Ein Softwareprojekt lässt sich demnach durch vier Variablen mit sehr komplexen Interdependenzen modellieren: Kosten, Zeit, Qualität und Umfang. Während die Betrachtung der ersten drei Variablen üblich ist, ist die Berücksichtigung der Variable Umfang selten, wie der Autor feststellt. Seiner Ansicht nach ist der Umfang eines Projektes jedoch die wichtigste der vier Größen, hauptsächlich weil dieser in der Anfangsphase eines Projektes üblicherweise allen Beteiligten unklar ist. Ein richtiger Umgang mit dieser Größe kann somit die anderen drei entscheidend auf positiver Art und Weise beeinflussen. Ein interessantes Problem, das Projekte ebenfalls stark beeinflussen kann, wird erwähnt aber nicht weiter vertieft: „höhere Kosten [werden] oft durch nicht zur Sache gehörige Ziele wie Status oder Prestige bedingt“ (S. 17).

Kapitel 5 widerspricht der üblichen Annahme eines exponentiellen Wachstums der Kosten von Änderungen in der Software in Abhängigkeit von der aktuellen Entwicklungsphase. Die Paarung von technologischen Fortschritten und bessere Programmierverfahren mache es möglich die Kosten von Änderungen auch in späteren Phasen niedrig zu halten, was eine der Prämissen für XP ist. Somit führen objektorientierte Programmierung, ein einfaches Design, automatisierte Tests und Übung im Umgang mit Änderungen automatisch zu geringeren Änderungskosten. XP sei dabei wie Autofahren, Aufmerksamkeit und ständige Korrekturen seien vonnöten, um nicht vom Kurs abzukommen.

Die Kapiteln 7 und 8 listen und beschrieben die Werte und die Prinzipien des XP und zeigen die komplexen Zusammenhänge zwischen diesen auf. Als die vier Werte des XP werden Kommunikation, Einfachheit, Feedback und Mut identifiziert. Respekt wird dabei als Grundwert, auf den die vier Werte aufgesetzt sind, angesehen. Aus diesen Werten werden eine Reihe Prinzipien abgeleitet, die einerseits in eingen Grundprinzipien und einer Menge sekundärer Prinzipien unterteilt werden. Die Grundprinzipien sind (vgl. S. 37 f):

  • Unmittelbares Feedback,
  • Anstreben von Einfachheit,
  • Inkrementelle Veränderungen,
  • Wollen und Akzeptieren von Veränderungen,
  • Qualität.

Sekundären Prinzipien sind unter anderen (siehe S. 38 ff):

  • Lernen lehren im Gegensatz zu doktrinären Aussagen,
  • Spielen, um zu gewinnen im Gegensatz zu spielen, um nicht zu verlieren,
  • Offene, ehrliche Kommunikation,
  • Übernahme von Verantwortung,
  • Ehrliches Messen im Gegensatz zur Simulation von Genauigkeit, die nicht gegeben ist.

Das letzte Kapitel des ersten Teils bespricht die vier grundlegenden Arbeitsschritte der Softwareentwicklung, die das Objekt der Vorschriften von XP sind. Diese nicht weiter reduzierbaren Schritte sind:

  • Programmieren
  • Testen
  • Zuhören
  • Entwerfen.

Dabei wird dem Arbeitsschritt Testen, seiner Wichtigkeit und seinen potenziellen Gefahren fast genauso viel Raum anbelangt, wie den anderen drei Schritten zusammen.

Teil 2 – Die Lösung

Der zweite Teil des Buches, der etwas umfangreicher als der Erste ist, beschreibt die Lösung des Autors auf die im ersten Teil identifizierten Probleme. Teil zwei besteht aus den Kapiteln 10 bis 18 und beginnt mit einem Überblick der im Rahmen von XP einzusetzenden Verfahren. Diese sind (vgl. S. 54 f.):

  • Das Planungsspiel, das als leichtgewichtiger Prozess zur Schätzung von Arbeitspaketen und zum Festlegen von Prioritäten vorgesehen ist
  • Kurze Releasezyklen
  • Die Metapher, die „einen Großteil dessen [ersetzt], was sonst häufig mit ‚Architektur‘ bezeichnet wird.“ (S. 56)
  • Einfaches Design
  • Testen
  • Refactoring
  • Pair Programming
  • Gemeinsame Verantwortlichkeiten
  • Continuous Integration
  • 40-Stunden-Woche
  • Kunde vor Ort
  • Programmierstandards

Obwohl jedes einzelne Verfahren für sich genommen Schwächen hätte, die in Vergangenheit immer wieder aufgezeigt wurden (S. 63), gleiche deren gemeinsames Verwenden die Schwächen aus und verstärke die positiven Effekte. Dabei unterstreicht der Autor, dass die flache Kurve für Änderungskosten im Gegensatz zur anhin gültigen exponentiellen Kurve die Verwendung dieser Verfahren überhaupt sinnvoll möglich macht. Im 11. Kapitel wird beschrieben, welche positiven Effekte von den einzelnen Verfahren zu erwarten sind, wie sie in Relation zueinander stehen und weswegen die vorherrschende Meinung zu den einzelnen Verfahren falsch sei unter den beschriebenen Umständen. So wird z.B. dem potenziellen Vorwurf, dass eine gemeinsame Verantwortlichkeit für den gesamten Code zu einer instabileren Codebasis und mehr Integrationsprobleme führen würde entgegnet, dass durch kurze Integrationsintervalle, Tests, Pair Programming und Programmierstandards dieses ansonsten bestehende Risiko sehr stark abgeschwächt werde.

Der Rest des zweiten Teils geht auf die einzelnen Aspekte der Softwareentwicklung detaillierter ein: Leitungsrollen und deren Aufgaben (Kapitel 12), erforderliche Arbeitsumgebung für eine erfolgreiche Implementierung von XP (Kapitel 13), wie ist zu planen (Kapitel 15), zu entwickeln (Kapitel 16), die Software zu designen (Kapitel 17) und diese zu testen (Kapitel 18).

Die optimale Managementstrategie befindet sich zwischen den beiden Extremen: ein allmächtiger Managers und die Laissez-faire-Strategie, bei der jeder machen kann, was er will. Die optimale Strategie orientiert sich an den im ersten Teil postulierten XP-Prinzipien.

Im Kapitel 14 wird auf die Wichtigkeit der Trennung zwischen der geschäftlichen und technischen Verantwortung hingewiesen und die einzelnen Verantwortlichkeiten der beiden Seiten werden beschrieben. Das Prinzip des „ehrlichen Messens“ wird zum wichtigsten Managementinstrument erhoben. Messdaten müssen erhoben und visualisiert werden, es wird jedoch unterstrichen, dass ein XP-Projekt nicht anhand von Zahlen verwaltet werden könne:

Die Zahlen stellen eine Möglichkeit dar, sanft und unaufdringlich die Notwendigkeit von Veränderungen mitzuteilen. Das empfindlichste Barometer des XP-Managers für die Notwendigkeit von Veränderungen besteht darin, sich der eigenen Gefühle bewusst zu sein.

S. 73

XP sieht zwei Managementrollen vor, die auch von einer Person übernommen werden können: der Terminmanager und der Coach. Während der Terminmanager für das Erheben und Visualisieren von Messdaten und für das Leiten des Planungsspieles verantwortlich ist, hat der Coach die Entwickler zu unterstützen und den Zustand des Projektes aus technischer Sicht im Auge zu behalten. Zusätzlich dazu muss der Coach dem Management gegenüber den Prozess erklären können.

Im nächsten Kapitel hebt der Autor die Wichtigkeit der Arbeitsumgebung hervor und unterstreicht, dass XP besondere Anforderungen an die Raumorganisation hat. So muss ein Team zusammen in einem Raum sitzen können, Entwicklerpaare müssen zusammen arbeiten können und gleichzeitig soll es Rückzugsmöglichkeiten geben, wenn ein Mitarbeiter seine Privatsphäre wahren will.

Der Beschreibung der Planungsstrategie wird viel Raum anbelangt. Diese wird durch folgende Prinzipien geleitet:

  • Es wird nur so viel geplant, wie unabdingbar
  • Verantwortung für Arbeitspakete wird übernommen nicht zugewiesen
  • Der oder die Entwickler sind für die Schätzung der Arbeitspakete zuständig
  • Es wird nach Priorität geplant.

Die Planung zerfällt in zwei große Teile mit sehr ähnlichen Regeln: das Planungsspiel, das für die Kommunikation mit dem Kunden zuständig ist und das Iterationsplanungsspiel, das für die Planung einer Iteration gedacht ist. Entsprechend gibt es Storycards (Planungsspiel) und Taskcards (Iterationsplanungsspiel). Beide Teile unterteilen sich in jeweils drei Phasen:

  1. Erforschungsphase – Definition der Story- und Taskcards, deren Schätzung (nur bei Storycards), deren Aufteilung oder Kombinierung (nur Iterationsplanungsspiel).
  2. Verpflichtungsphase – Sortieren der Aufgaben (nur bei Storycards) bzw. Tasks übernehmen und schätzen (Iterationsplanung), Implementiergeschwindigkeit (Planungsspiel) bzw. Belastungsfaktor durch andere Aktivitäten (Iterationsplanungsspiel) festlegen, Versionsumfang festlegen bzw. für gleichmäßige Auslastung der Entwickler sorgen.
  3. Steuerungsphase – das Planungsspiel sieht folgende Aktivitäten vor: Aufteilung in Iterationen, bei Bedarf Plankorrekturen, Definition von neuen Storycards und Neueinschätzung des Aufwands nach Änderungen;
    das Iterationsplanungsspiel sieht Folgendes vor: Tasks implementieren, Arbeitsaufwände protokollieren, bei Bedarf Plankorrekturen und die Überprüfung fertiggestellter Storycards.

Die Entwicklungsstrategie lässt sich durch drei Methoden oder Prinzipien beschrieben: fortlaufende Integration, gemeinsame Verantwortlichkeit und Pair Programming.

Das 17. Kapitel handelt über die Art wie die Software im Rahmen von XP zu designen ist (d.h. wie seine Architektur aufzubauen ist):

Die Designstrategie von XP lautet, stets das einfachste Design zu verwenden, mit dem sich die aktuelle Testreihe fehlerfrei ausführen lässt.

S. 103

Dies wird damit begründet, dass zukünftige Anforderungen selten akkurat vorhergesehen werden können. Mehr Anforderungen führen zu einer komplexeren, flexibleren Architektur, die entsprechend mehr Kosten verursacht, wenn diese Anforderungen jedoch nie gestellt werden, dann handelt es sich jedoch durch das unnötige Vorsehen um Verschwendung. Das Design einer XP-Anwendung hat inkrementell durch ständiges Refactoring an die Anforderungen angepasst zu werden.

Das letzte Kapitel des zweiten Teils hebt nochmals die Wichtigkeit des Testens hervor und bestimmt welche Teilnehmer für welche Tests verantwortlich sind: die Entwickler schreiben dabei Unit-Tests und die Kunden schreiben, oder lassen schreiben, Funktionstests.

Teil 3 – XP implementieren

Im dritten und letzten Teil seines Buches beschreibt Kent Beck praktische Details seiner Entwicklungsmethodik. Die Kapitel 19 bis 27, die meist sehr kurz sind, machen diesen Teil aus. So wird über eine schrittweise Einführung von XP geschrieben, indem jeweils immer das größte aktuell identifizierte Problem mit XP-Ansätzen gelöst wird. Dabei funktioniert laut Beck XP am besten, wenn alle Verfahren angewendet werden. Eine Anpassung der Methodik wird jedoch explizit nicht ausgeschlossen, diese kann sogar notwendig sein:

Ich möchte damit [mit dem vorher Geschriebenen – Anm. des Rezensenten] nicht sagen, dass Sie alles genauso machen sollten, wie ich es hier sage oder dass es Ihnen sonst Leid tun wird. Sie müssen nach wie vor die Verantwortung für Ihren eigenen Prozess übernehmen – Genau das macht XP so schwierig – indem Sie Verantwortung für Ihren eigenen Entwicklungsprozess übernehmen, sind Sie dafür verantwortlich, auf Probleme aufmerksam zu werden und sie zu lösen.

S. 154

Die Schwierigkeiten in Projekten allgemein resultieren dabei aus der Feststellung, dass menschliche Zusammenarbeit überhaupt schwierig ist und der Tatsache, dass die Bildungsinstitutionen und zum Großteil auch die Unternehmen hauptsächlich auf individuelle Leistungen setzen, bzw. nur diese belohnen.

Kapitel 22 geht nochmals detaillierter auf die Rollen und deren Herausforderungen innerhalb XP ein. Diese sind: Programmierer, Kunde, Tester, Terminmanager, Coach, Berater und sogenannter Big Boss. Obwohl nach der Meinung des Autors viele Projekte für ein XP-Vorgehen geeignet sind, gibt es Fälle in denen XP nicht funktionieren würde:

  • Große Teams – bei über zehn Entwicklern (d.h. fünf Paare) wird es kritisch
  • Langsame Prozesse, die sich nicht ändern lassen (Bauen, Integration etc.)
  • Physische Verteilung des Teams auf einem oder mehreren Stockwerken (wobei eine Verteilung auf mehreren Standorten bei klaren Schnittstellen funktionieren könnte laut Beck)
  • Misstrauische Kunden, die nicht mit den XP-Prinzipien umgehen können.

Ebenfalls stellt Outsourcing ein Problem dar, da in solchen Fällen üblicherweise der gesamte Code zum Schluss als Artefakt zur Verfügung gestellt wird, was eine Weiterentwicklung durch ein neues Team sehr erschwert.

Dass XP genauso wie alle anderen Entwicklungsmethoden scheitern kann, stellt der Autor anhand seiner eigenen Erfahrung fest (S. 155).

Das letzte Kapitel fasst die Schlussfolgerungen zusammen und beinhaltet eine schöne und sehr offene Auflistung der Ängste des Autors, die aus seiner Sicht als Grundlage für XP angesehen werden können. Dies ist relevant, da aus Kent Becks Sicht alle Entwicklungsprozesse Ängste als Grundlagen haben:

Alle Methoden beruhen auf Angst. Man versucht, Gewohnheiten zu etablieren, die verhindern, dass sich die eigenen Ängste bewahrheiten. XP unterscheidet sich in dieser Hinsicht nicht von anderen Methoden. Der Unterscheid besteht darin, dass die Ängste in XP eingebettet werden. In dem Grad, in dem XP meine Schöpfung ist, reflektiert XP meine Ängste.

S. 165

Ängste des Autors sind unter anderem das Treffen schlechter geschäftlicher Entscheidungen, mangelnder Stolz auf eigene Leistungen und das Ausüben irrelevanter Tätigkeiten auszuüben. Zwischen diesen Ängsten und dem was er Jahre später zu seiner Mission ansieht, besteht eine enge Verbindung.

Diskussion

XP ist zweifelsohne eine der bekanntesten agilen Entwicklungsmethodologien neben Scrum und Kanban, auch wenn laut des 13. jährlichen State of Agile Survey (2018) 54% der Befragten Scrum, 5% Kanban und lediglich 1% XP im Einsatz haben. Auch wenn der extreme Ansatz vielen wohl zu extrem war, handelt es sich bei Extreme Programming um ein offenes, ehrliches Buch, das XP als mögliche Lösung für die Minimierung von Risiken in Projekten, die gewisse Merkmale aufweisen, geeignet sein kann. Die Voraussetzung, dass die vorgeschriebenen Verfahren angewendet (teilweise Anpassungen jedoch möglich), die Prinzipien eingehalten, die Werte gelebt werden und die definierten Rollen passend besetzt sind, muss jedoch gegeben sein. XP ist kein „Silver Bullet,“ da sogar von Kent Beck höchstpersönlich geleitete XP-Projekte gescheitert sind (S. 155).

Das Buch ist ein Muss für alle, die XP einsetzen wollen, seien es Entwickler, Projektleiter oder Auftraggeber.  Es führt einerseits zu einem besseren Verständnis der technischen Aspekte des XP, aber auch, zumindest in einem gewissen Umfang, zu einem besseren Verständnis des Ursprungs von XP. Der Autor tritt dabei oft als greifbarer Mensch auf.

Seinem ersten Buch über XP lässt Kent Beck ein Jahr später (2000) sein zweites folgen: Planning Extreme Programming, das er zusammen mit Martin Fowler verfasst hat. Im Jahre 2004 folgt die zweite Auflage von Extreme Programming, Extreme Programming Explained: Embrace Change zusammen mit Cyntia Andres als komplette Neufassung der ersten Auflage.

Obwohl Vieles von dem im Buch Geschriebenen einleuchtend ist und die Argumentationsstränge klar nachvollziehbar sind, lässt es sich aber nicht ignorieren, dass das gesamte Konstrukt weniger auf kontrollierte Experimente als auf einige wenige Projekte begründet ist, die von außergewöhnlichen Entwicklern geleitet wurden. Es drängt sich die Frage auf, ob nicht eher diese außergewähnlichen Menschen den Erfolg der Projekte begründet haben. Simon Johnson hat diesen Effekt pointiert in seinem Artikel Meditation Driven Development beschrieben.


Zum Autor

Kent Beck ist einer der prominentesten Entwickler weltweit. Er ist unter anderem Begründer der Entwicklungsmethodik Extreme Programming (XP) und Entwickler der SUnit-Bibliothek zum Schreiben von Unit-Tests in Smalltalk. SUnit wurde durch Beck in Zusammenarbeit mit Erich Gamma nach Java unter dem Namen JUnit portiert.

Kent Beck ist ebenfalls einer der 17 initialen Unterzeichner des Agilen Manifestes und der Begründer bzw. nach eigener Betrachtung „Wiederentdecker“ des Test Driven Development-Ansatzes (TDD) dessen starker Verfechter er ist.

In seiner langjährigen Karriere war er für diverse Unternehmen tätig, unter diesen für Apple Computer und Facebook. Aktuell ist er unter anderem als Entwickler bei Three Rivers Consulting, Inc. und als Leiter für Junit.org tätig.

Er sieht seine eigene Mission darin „Geeks“ zu verhelfen sich sicherer in der Welt zu fühlen.

Er ist unter anderen Autor folgender Bücher:

  • Smalltalk Best Practice Patterns. Prentice Hall. (1997)
  • Extreme Programming Explained: Embrace Change. Addison-Wesley. (1999)
  • Test-Driven Development by Example. Addison-Wesley. (2002)
  • JUnit Pocket Guide. O’Reilly. (2004)

Informationen über Kent Beck im Katalog der Deutschen Nationalbibliothek.

Quelle: Die Information über den Autor sind seinem LinkedIn-Profil und der Wikipedia-Seite über ihn entnommen – letzter Zugriff am 15.03.2020.


Folgende Bücher könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Als studierter Psychologe und Software Engineer war er sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Mit der Gründung der Rezensionsplattform nososo hat er sich entschieden eigene Wege zu gehen.

Schreibe einen Kommentar