Extreme Programming (XP) – ein neuer Kodierungsstandard?

Was ist Extreme Programming (XP)?

Extreme Programming ist eine weitere Softwareentwicklungsmethodik in der Sammlung vieler anderer agiler Ansätze. XP basiert auf Werten, Prinzipien und Praktiken. Sein Hauptziel ist es, kleinen und mittelgroßen Entwicklungsteams die Möglichkeit zu geben, qualitativ hochwertige Software zu liefern, die an sich ändernde Geschäftsanforderungen angepasst ist.

Was Extreme Programming von anderen agilen Ansätzen unterscheidet, ist die Tatsache, dass sein Schwerpunkt auf den technischen Aspekten der Softwareentwicklung liegt. XP bestimmt genau, wie Entwickler arbeiten sollten, damit sie termingerecht hochwertige Software liefern können.

Kurz gesagt, bei Extreme Programming sind gute Programmierpraktiken… extrem wichtig.

Geschichte von XP

Die Anfänge von Extreme Programming gehen bis in die 1990er Jahre zurück. Es wurde von Kent Beck geschaffen, der auch als einer der siebzehn Unterzeichner des Agile Manifesto bekannt ist. Alles begann mit einem Projekt, an dem Kent Beck beteiligt war. In den drei Jahren der Projektentwicklung wurden keine großen Fortschritte erzielt. Als eine Person, für die die Teamleitung neu war, beschloss Beck, dass es am besten wäre, dem Team Techniken und Praktiken beizubringen, die für ihn selbst funktionierten. Sie setzten erfolgreich Praktiken wie Paarprogrammierung und TDD (Test-Driven Development) ein. Auf der Grundlage dieser Erfahrung beschrieb Kent Beck 1999 die Praktiken, Werte und Prinzipien der Extremprogrammierung in seinem Buch „Extreme Programming Explained: Embrace Change“.

Extreme Programming und andere Ansätze

Wie unterscheidet sich die Extremprogrammierung von traditionellen, nicht agilen Methodiken? Extremprogrammierung ist ein Teil des agilen Ansatzes, bei dem es wichtig ist, Änderungen nahtlos einzuführen. Statt sich an einen bestimmten, vom Anfang an festgelegten Plan zu halten, arbeiten Entwicklungsteams flexibel.

Extreme Programming unterscheidet sich stark von traditionellen Methodiken wie Waterfall.

Extreme Programming und Scrum

Man könnte fragen: na gut, aber bietet Scrum nicht schon alle oben beschriebenen Möglichkeiten? Scrum ist ein Framework, das Teams bei der Entwicklung komplexer Projekte auf iterative Weise unterstützt und den Entwicklern nicht vorschreibt, wie sie zu arbeiten haben. Der Hauptunterschied besteht darin, dass Extreme Programming, wie erwähnt, viel Wert auf gute Programmierpraktiken legt.

Außerdem steht Extreme Programming in direktem Zusammenhang mit der Programmierung und Scrum kann auf jedes Projekt angewendet werden, bei dem ein iterativer Ansatz sinnvoll ist.

Extreme Programming akzeptiert die Einführung von Änderungen in seine Komponenten (Meetings, Artefakte). Teams können und sollten sogar Artefakte nach ihren Bedürfnissen anpassen. Andererseits heißt es im Scrum Guide: „Obwohl es möglich ist, nur Teile von Scrum zu implementieren, wird das Ergebnis nicht Scrum sein“. Scrum ist ein Framework, das mit eigenen Prozessen und Methoden ergänzt werden muss. Es bedeutet, dass es nicht nur möglich ist, Extremprogrammierung und Scrum gleichzeitig zu verwenden, sondern es wird sogar dringend empfohlen.

Wie funktioniert Extremprogrammierung?

• Werte bestimmen Ziele für Teams. Sie dienen als Navigation, die Entscheidungen auf einer hohen, abstrakten Ebene leitet. Aufgrund der Abstraktheit der Werte und ihrer Allgemeingültigkeit ist es schwierig, konkrete Anweisungen zu erhalten. So kann beispielsweise die Aussage, dass „Kommunikation geschätzt wird“ sehr weit gefasst werden (z. B. bei täglichen Sitzungen werden nur Themen besprochen, die nichts mit den Bedürfnissen des Teams und des Kunden zu tun haben).
• Praktiken sind in gewisser Weise das Gegenteil von Werten. Werte sind allgemeine, theoretische Konzepte, wohingegen Praktiken bereits konkrete Prozesse sind, die die Spezifik dessen festlegen, was zu tun ist. Praktiken helfen also den Teams, Werte zu pflegen. Beispiel: Wert: Kommunikation. Praxis: Wissensaustausch im Team.
• Prinzipien sind bereichsspezifische Leitlinien, die die Kluft zwischen Praktiken und Werten überbrücken.
  

Extremprogrammierung basiert auf Werten, Praktiken und Prinzipien.

Feedback kann in vielen Formen und in unterschiedlichem Umfang erfolgen.

Bei der Paarprogrammierung sind Kommentare des anderen Entwicklers ein direktes Feedback. Gleiches gilt für das Feedback anderer Teammitglieder, einschließlich des Kunden, der ebenfalls als Teammitglied angesehen wird. Tests sind eine weitere Quelle für wertvolles Feedback. Wenn das Schreiben von Tests schwierig ist und viele Probleme verursacht, bedeutet es, dass die Architektur oder die im Projekt verwendeten Lösungen zu komplex sind und vereinfacht werden müssen.
Es kann dazu führen, dass das Team mehr Feedback erhält, als es verarbeiten kann. Dann besteht die Gefahr, dass in der Eile wichtigere Rückmeldungen vom Team übersehen werden. In einem solchen Fall sollte man analysieren, warum so viele Rückmeldungen eingehen und was korrigiert werden muss.

• Mut – Kent Beck definiert Mut als „Effektives Handeln angesichts der Angst“. Ein Entwickler hat viel zu befürchten und gleichzeitig viele Möglichkeiten, Engagement zu zeigen. Es erfordert Mut, Wahrheit zu sagen, insbesondere eine unangenehme Wahrheit, zum Beispiel über unrealistische Schätzungen. Feedback zu geben und zu erhalten erfordert ebenfalls Mut.
• Respekt – Ein Grundprinzip der Extremprogrammierung ist, dass sich jeder um die Qualität des Codes kümmert und sich in seine Arbeit engagiert. Kein Technologie-Stack, auch nicht das modernste, kann ein Projekt retten, wenn es an Respekt und Sorgfalt mangelt.

Prinzipien

Prinzipien in der Extremprogrammierung bieten mehr detaillierte Hinweise als Werte. Prinzipien verdeutlichen die Werte und machen sie klarer und eindeutiger. Zum Beispiel könnte man auf der Grundlage des Wertes „Mut“ sagen, dass eine größere Änderung des Codes empfohlen wird. Aber nach dem Prinzip der kleinen Schritte sind große Veränderungen riskant, daher sollten Veränderungen so klein wie möglich gehalten werden.

Menschen – Software wird von Menschen für Menschen entwickelt. Es ist eine offensichtliche, aber oft vernachlässigte Tatsache. Allerdings ist es wichtig, die Stärken und Schwächen von Menschen und ihre Bedürfnisse zu berücksichtigen, um Produkte zu schaffen, die sie gerne nutzen werden. Ein Arbeitsumfeld, das Leistungs- und Entwicklungsmöglichkeiten bietet sowie ein Gefühl der Zugehörigkeit vermittelt, ist ein Ort, an dem es leichter ist, Bedürfnisse von Anderen zu berücksichtigen.

Wirtschaftlichkeit – XP-Entwicklungsteams orientieren sich bei der Softwareentwicklung an der wirtschaftlichen Realität und bewerten ständig die Risiken und Bedürfnisse des Projekts. Zum Beispiel wird eine Story (User Story) zuerst unter dem Gesichtspunkt des geschäftlichen Nutzens und nicht unter technischen Gesichtspunkten umgesetzt.

Gemeinsamer Nutzen – durch die Anwendung der Extremprogrammierung werden Lösungen vermieden, die einer Partei auf Kosten der anderen Vorteile bringen. Eine ausführliche Dokumentation und Spezifikation kann beispielsweise dazu beitragen, dass jemand anderes ein Problem versteht, während sie das Team von der Umsetzung ablenkt und diese verzögert.

Projektmanagement

Erfahren Sie mehr über den vollständigen Leitfaden zum agilen Projektmanagemen

Lesen Sie den Artikel und erfahren Sie mehr

Ähnlichkeit – wenn eine Lösung auf einer bestimmten Ebene funktioniert, kann sie auch auf einer höheren oder niedrigeren Ebene funktionieren. So ist zum Beispiel frühzeitiges und kontinuierliches Feedback auf verschiedenen XP-Ebenen wichtig.

• Auf der Entwicklerebene erhalten Entwickler Feedback zu ihrem Code, indem sie den Test-First-Ansatz anwenden, bei dem sie vor der Programmierung Unit-Tests erstellen.
• Auf Teamebene – das Tool CI/CD Pipeline erstellt und testet den Code mehrmals am Tag.
• Auf organisatorischer Ebene – wöchentliche und vierteljährliche Iterationen ermöglichen es den Teams, Feedback zu erhalten und ihre Arbeit gegebenenfalls zu verbessern.

Optimierung – nach dem Prinzip der Optimierung streben die Teams in der ersten Umsetzungsphase nicht nach Perfektion, sondern nach einer Umsetzung, die gut genug ist. Dank des Feedbacks von den Benutzern lernen sie dann ständig dazu und optimieren das Produkt.

Vielfalt – Entwickler profitieren von einer Vielfalt an Ansätzen, Fähigkeiten und Einstellungen. Diese Vielfalt führt jedoch häufig zu Konflikten.

Konflikte und Missverständnisse – sind eine Gelegenheit für das Entstehen besserer Ideen, wenn sich alle von den Werten Mut und Respekt leiten lassen. Man muss den Mut haben, eine abweichende Meinung zu äußern, und zwar auf eine empathische Weise. All dies ist eine Übung in effektiver Kommunikation.

Reflexion – Teams denken über ihre Arbeit nach und analysieren, wie sie besser werden können. Extreme Programming bietet hierfür viele Möglichkeiten. Nicht nur in wöchentlichen oder vierteljährlichen Zyklen, sondern bei der täglichen Arbeit.

Fluss – traditionelle Ansätze legen Phasen fest, die lange dauern und wenig Raum für Feedback und Korrekturmöglichkeiten lassen. XP-Softwareentwicklung findet im Rahmen von Aktivitäten statt, die die ganze Zeit in einem einheitlichen Wertfluss ablaufen.

Chance – Probleme sind bei der Softwareentwicklung unvermeidlich, aber jedes Problem ist eine Chance zur Verbesserung Es lohnt sich zu lernen, sie so zu betrachten, dass kreative Lösungen möglich werden und das Wiederauftreten von Problemen in der Zukunft verhindert wird.

Redundanz – das Redundanz-Prinzip besagt, dass bei einem kritischen Problem mehrere Taktiken zu dessen Lösung eingesetzt werden müssen. Es gibt keine einzelne Taktik, die kritische Probleme beseitigen kann. Die Lösung, die Extreme Programming vorschlägt, besteht darin, mehrere Qualitätsindikatoren festzulegen. Paarprogrammierung, Tests und kontinuierliche Integration (CI) sind hilfreich, um die gewünschte Qualität zu erreichen.

Misserfolg – Ein Misserfolg ist kein Verlust, wenn daraus Schlüsse und Erkenntnisse gezogen werden. Entscheidungen zu treffen und schnell zu lernen, was nicht funktioniert, ist viel produktiver als Untätigkeit aufgrund von Unentschlossenheit.

Qualität – wir denken oft, wir müssten zwischen Qualität und Schnelligkeit wählen.
Das Gegenteil ist jedoch der Fall: Das Streben nach besserer Qualität erhöht die Schnelligkeit eines Teams (Team Velocity).

Ein Beispiel dafür ist Refactoring, das den Code verständlicher macht und Änderungen erleichtert. Dadurch sinkt die Wahrscheinlichkeit, dass Fehler in den Code eingeführt werden, was eine schnellere Lieferung eines größeren Werts erlaubt, ohne Fehler beheben zu müssen, und verstehen lässt, wofür der Code verantwortlich ist

Kleine Schritte – baby steps – große Veränderungen stellen ein Risiko dar. Extreme Programming reduziert dieses Risiko, indem es Änderungen in kleinen Schritten auf allen Ebenen vorschreibt.

Entwickler schreiben den Code in kleinen Partien, unter Verwendung von TDD (Test-Driven Development). Sie verbinden ihren Code mit dem Code des Hauptzweigs mehrmals täglich, nicht alle paar Wochen oder Monate. Die Entwicklung eines Projekts selbst erfolgt in kurzen Iterationen und nicht in langen Phasen.

Akzeptierte Verantwortung – in der Extremprogrammierung sollte die Verantwortung akzeptiert und niemals zugewiesen werden. Sie sollte mit der Befugnis einhergehen, Entscheidungen darüber zu treffen, wofür man verantwortlich ist. Das funktioniert auch umgekehrt. Schließlich wollen wir nicht, dass Menschen Entscheidungen treffen, wenn sie nicht mit den Konsequenzen rechnen müssen.

Rollen in der Extremprogrammierung

Rollen und ihre Verantwortlichkeiten im Rahmen von Extremprogrammierung:

Nach Kent Beck sollte ein erfahrenes oder anderweitig reifes XP-Team nicht auf starr definierten Rollen basieren. Es ist wichtig, daran zu denken, dass Rollen für Anfängerteams hilfreich sein können. Mit der Zeit können sie jedoch die Zusammenarbeit behindern.

• Kunde

Im Idealfall sollte ein echter Kunde/Product Owner vor Ort sein, um Fragen zu beantworten, Prioritäten für Storys zu setzen oder an Akzeptanztests teilzunehmen.

• Entwickler

In XP-Teams erstellen Entwickler Schätzungen für Aufgaben (tasks) und Storys (User Story), schreiben Tests und kümmern sich um die Implementierung.

• Coach

Im Rahmen des XP-Ansatzes ist es nicht erforderlich eine Person zu haben, die diese Aufgabe übernimmt. Eine solche Rolle im Team kann von einer Person übernommen werden, die bereits Erfahrung mit Extremprogrammierung hat. Die Aufgabe des Coaches besteht darin, dafür zu sorgen, dass das Team gute Praktiken anwendet, sie zu Gewohnheiten macht und nicht in alte Methoden der Softwareentwicklung zurückfällt.

• Tracker

Es ist die Person, die den Fortschritt des Teams im Auge behält und mit jedem Entwickler spricht. In Absprache mit den einzelnen Teammitgliedern können Blockaden und Engpässe ermittelt und Wege zu ihrer Beseitigung gefunden werden. Ein Tracker ist auch dafür verantwortlich, Metriken zu präsentieren, die das Zurechtkommen des Teams, seine Geschwindigkeit (Velocity) und Diagramme zum verbleibenden Aufwand (Burn-Down-Charts) zeigen. Häufig werden für die Erfassung solcher Kennzahlen Standardlösungen wie Scrum- oder Kanban-Boards verwendet, die automatisch Statistiken berechnen.

Prozesse in der Extremprogrammierung

Extreme Programming umfasst 5 Prozesse, die iterativ wiederholt werden:

• Planung – die erste Phase, in der sich der Kunde mit dem Entwicklungsteam trifft und seine Anforderungen in Form von Storys (User Storys) präsentiert, um das gewünschte Ergebnis zu beschreiben. Das Team bewertet dann die Stories und erstellt einen Release-Plan, der in Iterationen unterteilt wird, die für die Bereitstellung der erforderlichen Funktionen erforderlich sind, und zwar ein Teil nach dem anderen. Wenn einige Geschichten nicht bepreist werden können, kann ein sogenannter „Spike“ eingeführt werden, was bedeutet, dass weiteres Research erforderlich ist. Oft wird die Aufgabe in kleinere Storys aufgeteilt.
• Entwurf – es ist ein Teil des Planungsprozesses, der jedoch in einen separaten Prozess verlagert werden kann, um seine Bedeutung hervorzuheben. Dies hängt mit einem der Grundwerte von XP zusammen – der Einfachheit. Ein gutes Projekt führt Logik und Struktur in das System ein sowie vermeidet unnötige Komplexität und Redundanz.
• Implementierung – während dieses Prozesses schreibt man tatsächlich den Code, wobei spezielle XP-Praktiken wie etablierte Standards zum Schreiben von Codes, Pair Programming oder Continuous Integration angewendet werden.
• Testen – das ist die Grundlage von Extreme Programming. Es handelt sich um eine Aktivität, die sowohl Einzeltests, automatisierte Tests als auch Kundenakzeptanztests umfasst. Durch Kundentests wird überprüft, ob das System die ursprünglichen Anforderungen erfüllt.
• Zuhören – beinhaltet kontinuierliche Kommunikation und Rückmeldung. Kunden und Projektmanager sind an der Beschreibung der Geschäftslogik und ihres erwarteten Nutzens für das Unternehmen beteiligt.

Vor- und Nachteile von Extreme Programming

Extreme Programming kann auf jedes Softwareentwicklungsprojekt angewandt werden, jedoch sollten die Vor- und Nachteile dieses Ansatzes sowie die Unterschiede zwischen anderen agilen Frameworks berücksichtigt werden.

Vorteile der Extremprogrammierung

Der Einsatz von XP kann vorteilhaft sein und dazu beitragen, die Zeit und die Kosten der Softwareentwicklung zu reduzieren:

• Stabilität – wir erhalten ein stabiles, gut funktionierendes System durch Refactoring und ständiges Testen.
• Sauberer, prägnanter Code – leicht zu lesen und kann bei Bedarf in Zukunft geändert werden. Oben erwähnte Einfachheit ist dabei besonders hilfreich.
• Reduzierte Dokumentation – umfangreiche Anforderungsdateien werden durch Storys ersetzt.
• Ergebnisse, die den Erwartungen entsprechen – die Einbeziehung des Kunden in den Entwicklungs- und Testprozess kann sich direkt auf das Ergebnis auswirken. Sie stellt sicher, dass die Annahmen und geschäftlichen Anforderungen erfüllt werden, so dass der Kunde genau das erhält, was er braucht.
• Keine Überstunden – Maximale Reduzierung oder völliges Fehlen von Überstunden ist durch kurze Iterationen möglich, wobei man sich auf spezifische Anforderungen konzentriert und das liefert, was der Kunde tatsächlich erwartet. Je länger die Iteration dauert, desto größer die Gefahr, dass die Anforderungen nicht richtig verstanden werden und zusätzliche Zeit benötigt wird, um eine Lösung zu korrigieren, deren Entwicklung mehrere Wochen gedauert hat.
• Weniger Fehler – Pair Programming ermöglicht es, ein qualitativ besseres Produkt mit weniger Fehlern zu liefern. Gleichzeitig kann sich die Zusammenarbeit zwischen Entwicklern positiv auf ihr Verständnis von Annahmen und ihre Sicherheit in Bezug auf die Anforderungen auswirken
• Transparenz – ständige Kommunikation sorgt für ein hohes Maß an Transparenz und Verantwortlichkeit und ermöglicht es dem gesamten Team, sich über den Projektfortschritt und die Änderungen auf dem Laufenden zu halten.
• Schnelligkeit der Produktlieferung – ein minimalistischer, iterativer Ansatz bei der Softwareentwicklung bedeutet, dass fertige, brauchbare Komponenten sehr schnell bereitgestellt werden können. Außerdem werden nur notwendige Funktionen implementiert.

Nachteile der Extremprogrammierung

Andererseits, hat die Extremprogrammierung hat auch viele Nachteile, die bei der Wahl dieses Ansatzes für ein Projekt berücksichtigt werden müssen:

• Unscharfes Endergebnis – sehr oft hat der Kunde während des Projekts noch kein klares Bild (clear picture) vom Endergebnis. Das Fehlen einer solchen Vision macht es fast unmöglich, genaue Schätzungen über den Umfang der erforderlichen Arbeiten, die Kosten und den Zeitaufwand vorzunehmen.
• Unklare Anforderungen – die Dokumentation kann unzureichend sein sowie klare und transparente Anforderungen und Spezifikationen können fehlen. Es führt häufig zu einer Erweiterung des Projektumfangs.
• Einfluss von menschlichen Faktoren – Pair Programming erfordert mehr Zeit und liefert nicht immer die erwarteten Ergebnisse. Dies kann aufgrund von Charakterinkompatibilität geschehen.
• Einstiegsschwelle – ein schneller Wechsel von traditionellen Softwareentwicklungsmethoden zu Extreme Programming erfordert erhebliche strukturelle Veränderungen.
• Beschränkungen der Fernarbeit – Extreme Programming eignet sich am besten für Teams und Kunden vor Ort (on-site), da es
  persönliche Treffen erfordert. Es schränkt den Einsatz von XP in verstreuten Teams ein.
• Mehr Treffen – häufige Kundenbesprechungen nehmen viel Zeit in Anspruch, die für die eigentliche Implementierung verwendet werden könnte.
• Stress – manchmal haben Kunden nicht die Zeit, den Willen oder die Erfahrung, sich an der Produktentwicklung zu beteiligen. Termindruck kann zu Stress führen – vor allem, wenn das Team kein wertvolles Feedback erhält oder wenn jemand ohne oder mit nur geringen Prozesskenntnissen versucht, die Entwickler zu verwalten.

Wann sollte Extremprogrammierung eingesetzt werden?

Extremprogrammierung funktioniert gut in Teams, wenn:

• Funktionen des Systems, an dem sie arbeiten, sich alle paar Monate ändern.
• sich die Anforderungen ständig ändern oder mit einem Kunden zusammengearbeitet wird, der nicht genau weiß, was er von dem System erwartet.
• man das Projektrisiko verringern und Termindruck vermeiden möchte.
• das Entwicklungsteam klein ist (am besten 2 bis 12 Personen).
• enge Zusammenarbeit mit dem Kunden möglich ist.
• Einzeltests, automatisierte und funktionale Tests durchgeführt werden können.

Fazit

Projektmanagement

Erfahren Sie mehr über den vollständigen Leitfaden zum agilen Projektmanagemen

Lesen Sie den Artikel und erfahren Sie mehr

Wenn jedoch Zusammenarbeit und kontinuierliche Entwicklung für Ihr Team eine Priorität sind, dann ist Extremprogrammierung einen Versuch wert. Dieser hochflexible Ansatz stützt sich auf ständiges Feedback der Kunden, antizipiert Fehler, die unterwegs auftreten können, und erfordert die Zusammenarbeit der Entwickler wegen der Paarprogrammierung.

Extreme Programming stellt nicht nur sicher, dass ein Produkt geliefert wird, das einen Mehrwert für das Unternehmen darstellt, sondern erhöht auch die Produktivität der Entwicklungsteams.