Was ist Extreme Programming?

Extreme Programming (XP) ist ein agiles Framework für die Softwareentwicklung, das darauf abzielt, eine höhere Softwarequalität und eine höhere Lebensqualität für das Entwicklungsteam zu erreichen. XP ist das spezifischste der agilen Frameworks in Bezug auf geeignete technische Praktiken für die Softwareentwicklung.

Werte

Kommunikation

Softwareentwicklung ist von Natur aus ein Teamsport, der auf Kommunikation angewiesen ist, um Wissen von einem Teammitglied auf alle anderen im Team zu übertragen. XP betont die Bedeutung der richtigen Art der Kommunikation - von Angesicht zu Angesicht mit Hilfe eines Whiteboards oder eines anderen Zeichenmechanismus.

Feedback

Durch ständiges Feedback über ihre bisherigen Bemühungen können die Teams Verbesserungsmöglichkeiten erkennen und ihre Praktiken überarbeiten.

Einfachheit

"Was ist das Einfachste, was funktionieren wird?" Der Zweck ist, Verschwendung zu vermeiden und nur absolut notwendige Dinge zu tun, wie z.B. den Entwurf des Systems so einfach wie möglich zu halten, damit es einfacher zu warten, zu unterstützen und zu überarbeiten ist. Einfachheit bedeutet auch, dass du dich nur mit den Anforderungen befasst, die du kennst; versuche nicht, die Zukunft vorherzusagen.

Mut

Kent Beck definiert Mut als "effektives Handeln im Angesicht der Angst". Diese Definition zeigt, dass es wichtig ist, nach anderen Prinzipien zu handeln, damit die Ergebnisse dem Team nicht schaden. Du brauchst Mut, um organisatorische Probleme anzusprechen, die die Effektivität deines Teams beeinträchtigen. Du brauchst Mut, um etwas, das nicht funktioniert, aufzugeben und etwas anderes auszuprobieren. Du brauchst Mut, um Feedback anzunehmen und danach zu handeln, auch wenn es dir schwerfällt, es anzunehmen.

Respekt

Die Mitglieder deines Teams müssen sich gegenseitig respektieren, um miteinander zu kommunizieren, Feedback zu geben und zu akzeptieren, das eure Beziehung stärkt, und gemeinsam an einfachen Entwürfen und Lösungen zu arbeiten.

Prinzipien

1. Menschlichkeit: Der Mensch steht im Mittelpunkt des Entwicklungsprozesses, weshalb ein respektvoller und wertschätzender Umgang innerhalb des Teams essenziell ist.

2. Wirtschaftlichkeit: Effizienz und die sinnvolle Nutzung von Ressourcen sind entscheidend, um kostengünstig und produktiv zu arbeiten.

3. Gegenseitiger Vorteil: Zusammenarbeit sollte immer darauf abzielen, dass alle Beteiligten – Kunden wie Entwickler – durch ein Win-Win-Verhältnis profitieren.

4. Selbstähnlichkeit: Wiederkehrende Muster und Strukturen im Code und im Entwicklungsprozess helfen dabei, Komplexität zu reduzieren und bessere Vorhersagen zu treffen.

5. Verbesserung: Ständige Weiterentwicklung und Optimierung sind notwendig, um langfristig erfolgreich zu sein und sich an neue Herausforderungen anzupassen.

6. Diversität: Unterschiedliche Perspektiven und Fähigkeiten im Team fördern kreative Lösungen und Innovationen.

7. Reflexion: Regelmässige Reflexion und retrospektive Betrachtungen ermöglichen es, aus Erfahrungen zu lernen und kontinuierlich besser zu werden.

8. Fluss: Ein steter, ununterbrochener Arbeitsfluss hilft dabei, Effizienz zu maximieren und Wartezeiten zu minimieren.

9. Gelegenheit: Veränderungen und Herausforderungen sollten als Chancen gesehen werden, neue Fähigkeiten zu erlernen und sich weiterzuentwickeln.

10. Redundanz: Mehrfache Absicherung wichtiger Systemkomponenten erhöht die Zuverlässigkeit und verringert die Ausfallzeiten.

11. Fehlschlag: Fehler und Scheitern sind unvermeidlich und sollten als wertvolle Lernmöglichkeiten begriffen werden, um künftig besser zu agieren.

12. Qualität: Hohe Qualität des Codes und der Prozesse ist ausschlaggebend für langfristigen Erfolg und Kundenzufriedenheit.

13. Baby Steps: Kleine, inkrementelle Änderungen minimieren Risiken und erleichtern das Management von Projekten.

14. Akzeptierte Verantwortlichkeit: Jedes Teammitglied übernimmt Verantwortung für seine Aufgaben, was die Vertrauensbasis und Zuverlässigkeit im Team stärkt.

Praktiken

Sit Together

Da Kommunikation einer der fünf Werte von XP ist und die meisten Menschen darin übereinstimmen, dass ein Gespräch von Angesicht zu Angesicht die beste Form der Kommunikation ist, solltest du dein Team in einem Raum zusammensitzen lassen, in dem es keine Kommunikationsbarrieren gibt, wie z.B. Kabinenwände.

Whole Team

Eine funktionsübergreifende Gruppe von Menschen mit den notwendigen Rollen für ein Produkt bildet ein einziges Team. Das bedeutet, dass Menschen mit einem Bedürfnis und alle Personen, die an der Befriedigung dieses Bedürfnisses beteiligt sind, täglich zusammenarbeiten, um ein bestimmtes Ergebnis zu erzielen.

Informative Workspace

Richte deinen Teamraum so ein, dass die Kommunikation von Angesicht zu Angesicht erleichtert wird, dass die Mitarbeiter/innen bei Bedarf etwas Privatsphäre haben und dass die Arbeit des Teams für einander und für Interessierte ausserhalb des Teams transparent ist. Nutze Informationsradiatoren, um aktiv aktuelle Informationen zu kommunizieren.

Energized Work

Du bist bei der Softwareentwicklung und bei allen Wissensarbeiten am effektivsten, wenn du konzentriert und frei von Ablenkungen bist.

Energiereiches Arbeiten bedeutet, dass du dafür sorgst, dass du körperlich und geistig in der Lage bist, in einen konzentrierten Zustand zu kommen. Das bedeutet, dass du dich nicht überarbeitest (oder dich von anderen überarbeiten lässt). Es bedeutet auch, dass du gesund bleibst und deine Teamkollegen respektierst, damit sie gesund bleiben.

Pair Programming

Pair Programming bedeutet, dass die gesamte Produktionssoftware von zwei Personen entwickelt wird, die an derselben Maschine sitzen. Die Idee dahinter ist, dass zwei Gehirne und vier Augen besser sind als ein Gehirn und zwei Augen. Du bekommst eine kontinuierliche Überprüfung des Codes und kannst schneller auf Probleme reagieren, die eine Person nicht lösen kann.

Teams, die Pair Programming anwenden, haben festgestellt, dass es die Qualität verbessert und nicht doppelt so lange dauert, weil sie Probleme schnell lösen können und sich besser auf die Aufgabe konzentrieren können, wodurch sie weniger Code für die gleiche Aufgabe erstellen.

Stories

Beschreibe, was das Produkt für die Kunden und Nutzer tun soll. Diese Stories sind als kurze Beschreibungen von Dingen gedacht, die die Nutzer/innen mit dem Produkt machen wollen. Sie können für die Planung verwendet werden und dienen als Erinnerung für detailliertere Gespräche, wenn das Team dazu kommt, die jeweilige Story zu realisieren.

Weekly Cycle

Der wöchentliche Zyklus ist ein Synonym für eine Iteration. Bei XP trifft sich das Team am ersten Tag der Woche, um den bisherigen Fortschritt zu besprechen. Der Kunde wählt die Stories aus, die er in dieser Woche geliefert haben möchte, und das Team legt fest, wie es an diese Stories herangehen will. Das Ziel ist es, bis zum Ende der Woche getestete Funktionen zu haben, die die ausgewählten Stories umsetzen.

Die Absicht hinter der zeitlich begrenzten Lieferfrist ist es, etwas zu produzieren, das dem Kunden als Feedback vorgelegt werden kann.

Quarterly Cycle

Der vierteljährliche Zyklus ist gleichbedeutend mit einem Release. Er dient dazu, die Detailarbeit jedes Wochenzyklus in den Kontext des Gesamtprojekts zu stellen. Der Kunde legt den Gesamtplan für das Team in Bezug auf die gewünschten Funktionen innerhalb eines bestimmten Quartals fest. So hilft es dem Kunden auch bei der Zusammenarbeit mit anderen Interessengruppen, die eine Vorstellung davon haben müssen, wann die Funktionen verfügbar sein werden.

Denk daran, dass bei der Planung eines vierteljährlichen Zyklus die Informationen über eine bestimmte Story auf einer relativ hohen Ebene liegen, dass sich die Reihenfolge der Lieferung von Storys innerhalb eines vierteljährlichen Zyklus ändern kann und dass sich die im vierteljährlichen Zyklus enthaltenen Storys ändern können. Wenn du in der Lage bist, den Plan wöchentlich nach jedem Quartalszyklus zu überprüfen, kannst du alle informieren, sobald die Änderungen bekannt werden, um Überraschungen zu vermeiden.

Slack

Die Idee hinter Slack in XP ist, dass du in deinen wöchentlichen und vierteljährlichen Zyklen einige Aufgaben oder Stories mit niedriger Priorität einbaust, die weggelassen werden können, wenn das Team bei wichtigeren Aufgaben oder Stories in Verzug gerät. Anders ausgedrückt: Berücksichtige die inhärenten Schwankungen bei den Schätzungen, um sicherzustellen, dass du eine gute Chance hast, deine Prognosen einzuhalten.

Ten-Minute Build

Das Ziel des Zehn-Minuten-Builds ist es, das gesamte System automatisch zu bauen und alle Tests in zehn Minuten durchzuführen. Die Begründer von XP schlugen einen Zeitrahmen von 10 Minuten vor, denn wenn ein Team einen Build hat, der länger dauert, wird er wahrscheinlich nicht so häufig ausgeführt, was zu einer längeren Zeitspanne zwischen den Fehlern führt.

Diese Praxis ermutigt dein Team, den Build-Prozess zu automatisieren, damit du ihn eher regelmässig durchführst, und diesen automatisierten Build-Prozess für alle deine Tests zu nutzen.

Diese Praxis unterstützt die Praxis der kontinuierlichen Integration und wird durch die Praxis der Test First Development unterstützt.

Continuous Integration

Bei der kontinuierlichen Integration werden Codeänderungen sofort getestet, wenn sie zu einer grösseren Codebasis hinzugefügt werden. Der Vorteil dieser Praxis ist, dass du Integrationsprobleme früher erkennen und beheben kannst.

Die meisten Teams fürchten sich vor dem Schritt der Code-Integration, weil sie dabei Konflikte und Probleme entdecken. Die meisten Teams gehen nach dem Motto vor: "Wenn es weh tut, vermeide es so lange wie möglich".

XP-Praktiker schlagen vor: "Wenn es weh tut, mach es öfter".

Die Überlegung dahinter ist: Wenn du bei jeder Code-Integration Probleme hast und es eine Weile dauert, bis du herausfindest, wo die Probleme liegen, solltest du vielleicht öfter integrieren, damit du Probleme leichter finden kannst, weil weniger Änderungen in den Build einfliessen.

Diese Vorgehensweise erfordert etwas mehr Disziplin und ist stark von Ten Minute Build und Test First Development abhängig.

Test-First Programming

Anstatt dem normalen Weg zu folgen: Code entwickeln → Tests schreiben → Tests ausführen

Folgt die Praxis der Test-First-Programmierung folgendem Weg:

Wie bei der kontinuierlichen Integration verkürzt Test-First Programming den Feedback-Zyklus für die Entwickler, um Probleme zu erkennen und zu beheben, und verringert so die Anzahl der Fehler, die in die Produktion gelangen.

Incremental Design

Die Praxis des inkrementellen Designs legt nahe, dass du im Vorfeld ein wenig Arbeit leistest, um die Breite des Systemdesigns zu verstehen, und dann in die Details eines bestimmten Aspekts dieses Designs eintauchst, wenn du bestimmte Funktionen lieferst. Dieser Ansatz reduziert die Kosten für Änderungen und ermöglicht es dir, bei Bedarf Designentscheidungen auf der Grundlage der aktuellsten verfügbaren Informationen zu treffen.

Ursprünglich gehörte Refactoring zu den 12 Kernpraktiken, wurde aber in die Praxis des Inkrementellen Designs integriert. Refactoring ist eine hervorragende Methode, um das Design einfach zu halten, und eine der am häufigsten empfohlenen Anwendungen von Refactoring ist die Beseitigung doppelter Prozesse.