Extreme Programming

Entwickelt wurde Extreme Programming – oftmals einfach mit XP abgekürzt – Mitte der 1990er Jahre von Kent Beck, Ward Cunningham und Ron Jeffries während ihrer Arbeit in einem Projekt bei Chrysler Comprehensive Compensation System zur Entwicklung eines Lohnabrechnungssystems für die Chrysler Corporation. Als Team sahen sie sich mit einer Reihe von Herausforderungen konfrontiert, darunter knappe Fristen, wechselnde Anforderungen und das Fehlen einer klaren Richtung. Sie begannen mit verschiedenen Ansätzen zu experimentieren, und entwickelten schließlich eine Reihe von Prinzipien und Praktiken, die unter Softwareentwicklern schnell an Popularität gewannen und fortan in vielen Organisationen genutzt wurden.

Nachdem das Konzept in einer Reihe von Artikeln beschrieben wurde, präsentierte Beck XP 1996 auf der Konferenz Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) einem größeren Publikum und veröffentlichte 1999 das Buch “Extreme Programming Explained: Embrace Change”.² Das Buch bietet einen Überblick über die Methodik und die ihr zugrunde liegenden Prinzipien sowie praktische Anleitungen für die Implementierung von XP in Softwareentwicklungsprojekten.

Verschiedene Perspektiven auf Extreme Programming

Bei der Entwicklung von Software prallen verschiedene Interessen und Perspektiven der beteiligten Personen bzw. Personengruppen aufeinander. Damit das Miteinander funktioniert, müssen diese Interessen und Perspektiven explizit berücksichtigt werden. Oder anders formuliert: Der individuelle Nutzen der beteiligten Personen(-gruppen) ist ein wesentlicher Erfolgsfaktor für das Gelingen des Vorhabens.

Unterscheiden lassen sich folgende Personengruppen bzw. Perspektiven:

Kundenperspektive: Extreme Programming geht davon aus, dass ein Kunde zu Projektbeginn nicht alle Anforderungen kennt und auch nicht in der Lage ist, diese fachlich korrekt zu strukturieren bzw. zu priorisieren. Es ist daher normal, dass der Kunde im Laufe einer Entwicklung neue Anforderungen identifiziert, seine Meinung zu bestehenden Wünschen ändert oder einzelne Aspekte anderes priorisiert. Für den Kunden ist daher ein Vorgehen wichtig, bei dem er steuernd auf die Entwicklung Einfluss nehmen kann.

In XP sorgen kurze Entwicklungszyklen, regelmäßiger Austausch und Feedback dafür, dass der Kunde tatsächlich eine Software erhält, die seinen Ansprüchen und Erwartungen entspricht. Jedoch hat diese Flexibilität seinen Preis: Einerseits verpflichtet sich der Kunde, während der gesamten Entwicklung mit einem definierten Entwicklungsteam aktiv zusammenzuarbeiten, andererseits erkennt er auch, dass ein formaler Ansatz mit einer umfassenden Lastenheft– oder SRS-Spezifikation wenig sinnvoll ist. In gewisser Weise sind steter Austausch, Vertrauen und offene Kommunikation eine wichtige Basis für die Zusammenarbeit der Beteiligten.

Entwicklerperspektive: Kurze Entwicklungszyklen sind auch für Entwickler vorteilhaft, da sie bereits nach kurzer Zeit Rückmeldung von anderen Beteiligten – Kunden, Kundenstellvertreter, Anwender, Key User oder interne Manager – erhalten. Somit sinkt ihr Risiko, falsche Dinge zu entwickeln oder Dinge falsch zu entwickeln.

Kurze Entwicklungszyklen bieten zusätzliche Vorteile:

• Aufwandsschätzungen, die idealerweise im Team erfolgen, werden genauer, da die Menge der Anforderungen sinkt, die innerhalb einer Iteration realisiert werden sollen.
• Die Implementierung von Test wird verhältnismäßig einfacher und die Beseitigung möglicher Fehler vermutlich weniger aufwändig.
• Und das Team erhält die Möglichkeit, sich als Team zu begreifen. Gemeinsam gilt es, Nutzen für den Kunden zu erzielen, gemeinsam gilt es, die nächste Iteration erfolgreich zu gestalten, gemeinsam gilt es Qualität zu produzieren.

Allerdings müssen Entwickler auch akzeptieren, dass der Programmcode unabhängig vom Ersteller dem gesamten Team gehört und intern Feedback von jedem erwartet und idealerweise auch erwünscht ist.

Projekt- und Organisationsperspektive: Die kontinuierliche Analyse und Verbesserung von Extreme Programming ist ein zentrales Element der Methode. Damit lehnt sich XP an die japanische Philosophie Kaizen an. Der Begriff wird aus den beiden japanischen Wörtern Kai (Veränderung) und Zen (zum Besseren) zusammengesetzt, wobei das Bestreben nicht darin fußt, von Anfang an auf Perfektion zu setzen, sondern permanente Verbesserung zu adressieren. Diese Perspektive betrifft sowohl das an der Entwicklung beteiligten Personen als auch die Organisation als Ganzes, und spiegelt sich in den Werten, Prinzipien und Praktiken der Methode wider.

Die Werte im Extreme Programming

Kent Beck definiert fünf Werte, auf denen Extreme Programming basiert:

• Einfachheit,
• Kommunikation,
• Feedback,
• Mut und
• Respekt.

Einfachheit besagt, dass die einfachste Lösung realisiert werden sollte, die den Anforderungen entspricht. Einfachheit wird damit zur Antwort auf Komplexität, die diese minimiert und bspw. den Dokumentationsaufwand reduziert.

Unerlässlich für den Erfolg der Entwicklung ist eine klare und kontinuierliche Kommunikation der Beteiligten. Sie ist die Basis zur Nutzung des vorhandenen Wissens der Projektbeteiligten. Häufig lassen sich bspw. Probleme mittels Kommunikation lösen, da einer der Beteiligten die Lösung bereits kennt.

Regelmäßiges Feedback von Kunden erhöht nicht nur die Qualität der Software, sondern fördert auch die Zufriedenheit im Team. Gleichzeitig reduzieren Rückmeldungen die Wahrscheinlichkeit von Fehlentwicklungen und senken folglich Aufwände zur Beseitigung dieser.

Mut ist die Basis für die ersten drei Werte Einfachheit, Kommunikation und Feedback. Ohne Mut gibt es keinen Austausch, kritische Dinge werden evtl. nicht angesprochen, Fehler verschwiegen oder unrealistische Wünsche nicht thematisiert.

Respekt beschreibt die Haltung zwischen den Beteiligten, zwischen Kunden und Entwicklern und untereinander zwischen den Entwicklern. Dabei werden sowohl Meinungen als auch Leistungen respektiert. (Das klingt evtl. in der Theorie einfacher als es manchmal in der Praxis ist.)

Prinzipien in Extreme Programming

Neben den Werten definiert XP auch 14 Prinzipien:

• Menschlichkeit,
• Wirtschaftlichkeit,
• Beidseitiger Vorteil,
• Selbstgleichheit bzw. Selbstähnlichkeit,
• Verbesserungen,
• Vielfältigkeit,
• Reflexion,
• Fluss,
• Gelegenheit,
• Redundanz,
• Fehlschlag,
• Qualität,
• kleine Schritte und
• akzeptierte Verantwortung.

Software wird von Menschen entwickelt. Menschlichkeit bedeutet, dass bspw. ein angemessenes Verhältnis zwischen Berufs- und Privatleben nicht nur die Arbeitsmoral und Motivation fördert, sondern auch die Effizienz aller Beteiligten verbessert. Zudem ist Menschlichkeit ein wichtiger Faktor für die Zusammenarbeit im Team, die Verantwortungsübernahme der Beteiligten und das gegenseitige Feedback.

Wirtschaftlichkeit adressiert die Absicht, Software gewinnbringend zu entwickeln. Trotz aller Menschlichkeit geht es auch darum, Gewinne zu erzielen. Natürlich muss die entwickelte Software die definierten Anforderungen des Kunden erfüllen, dabei sollte es aber die Kosten und Ressourcen so gering wie möglich halten. Hier gilt es ein richtiges Gleichgewicht zwischen Features, Kosten und Kundenzufriedenheit zu finden, um sicherzustellen, dass die Entwicklung wirtschaftlich sinnvoll ist.

Das Prinzip des beidseitigen Vorteils in Extreme Programming (XP) besagt, dass sowohl das Entwicklungsteam als auch der Kunde von der Zusammenarbeit profitieren sollten. Es geht darum, dass beide Parteien ihre Bedürfnisse und Erwartungen klar kommunizieren und aufeinander abstimmen, um ein gemeinsames Ziel zu erreichen: die Entwicklung einer qualitativ hochwertigen Software, die die Anforderungen des Kunden erfüllt. Dies erfordert eine enge Zusammenarbeit und eine offene Kommunikation, um sicherzustellen, dass das Projekt erfolgreich ist und sowohl das Team als auch der Kunde mit dem Ergebnis zufrieden sind.

Selbstgleichheit oder Selbstähnlichkeit adressiert die Wiederverwendung als Prinzip. Es geht darum, nicht immer das Rad neu zu erfinden, sondern Ansätze, Strukturen, Ideen aus bereits entwickelten Lösungen wiederzuverwenden. Dabei geht es aber nicht darum, eine vorhandene Lösung zu kopieren, sondern sie bei Bedarf als Bezugspunkt zu nutzen.

Erinnern Sie sich noch an Kaizen und die Projekt- bzw. Organisationsperspektive? Software lässt sich nicht von Grund auf perfekt entwickeln – sich ändernde Anforderungen, neue Wünsche oder Ideen, Fehler, Seiteneffekte verhindern dies. Zudem entwickelt sich Technik häufig weiter – was gestern fast unmöglich schien, funktioniert heute ohne großen Aufwand. Durch Verbesserungen steigen sowohl die Qualität des Produkts, als auch die Zufriedenheit des Kunden; Voraussetzung ist, dass insbesondere die Werte Kommunikation und Feedback gelebt werden.

Vielfältigkeit ist ein Prinzip, das die Zusammenstellung des Teams aus Mitgliedern mit unterschiedlichen Hintergründen, Fähigkeiten und Erfahrungen fordert. Vielfältigkeit ermöglicht es Teams, Probleme aus verschiedenen Blickwinkeln zu betrachten und Lösungen zu finden. Es geht darum, die Stärken jedes Mitglieds zu nutzen und die Zusammenarbeit der Teammitglieder zu fördern, um die Entwicklung der Software dauerhaft zu verbessern und erfolgreicher zu machen.

Bei der Reflexion geht darum, das Team in die Lage zu versetzen, sich selbst zu evaluieren und die Art und Weise der Zusammenarbeit zu verbessern. Der Austausch von Erfahrungen, die Identifikation von Problemen, die Veränderung von Vorgehensweisen und die gegenseitige Unterstützung tragen aktiv dazu bei, die Qualität der Software zu verbessern, die Produktivität zu steigern und die Zufriedenheit der Teammitglieder und des Kunden zu verbessern.

Eine grundlegende Idee von XP ist das Fluss-Prinzip. Es geht darum, während des gesamten Entwicklungsprozesses einen stetigen Arbeitsfluss aufrechtzuerhalten. Es geht darum, sicherzustellen, dass die Arbeit immer erledigt wird und dass das Team stetige Fortschritte bei der Fertigstellung des Projekts macht. Dies kann erreicht werden, indem das Projekt bspw. in kurze Iterationen unterteilt wird, in denen kleine Arbeitsschritte – bspw. in Form sogenannter User Storys – realisiert werden. Idealerweise kommt so das Projekt reibungslos voran. Darüber hinaus bezieht sich dieses Prinzip auch auf die Idee, Unterbrechungen und Ablenkungen zu minimieren, um die Konzentration und Produktivität des Teams aufrechtzuerhalten.

Probleme im Zuge von Softwareentwicklungen sind nicht unüblich. Probleme sind Gelegenheiten. Es gilt, Probleme als Chance zur Verbesserung und als Aspekt eines Lernprozesses zu begreifen. Ähnlich verhält es sich übrigens mit Feedback und Kommunikation – auch diese Werte lassen sich als Gelegenheit nutzen.

Das Prinzip der Redundanz wird im Entwicklungsprozess angewandt, indem mehrere Personen an der gleichen Aufgabe oder Funktion arbeiten oder indem es mehrere Möglichkeiten gibt, ein Problem zu lösen. Diese Redundanz trägt dazu bei, dass das Projekt auch dann fortgesetzt werden kann, wenn etwas schiefgeht oder ein unerwartetes Problem auftritt. Sie trägt auch dazu bei, Risiken zu mindern und die Qualität und Robustheit des Endprodukts zu verbessern.

Das Prinzip des Scheiterns bzw. des Fehlschlags basiert auf der Idee, dass es besser ist, früh und oft zu scheitern, als bis zu einem späten Zeitpunkt im Entwicklungsprozess zu warten. Dieses Prinzip ermutigt das Team, potenzielle Probleme frühzeitig zu erkennen und Schritte zu ihrer Entschärfung zu unternehmen, anstatt unnötig zu warten und kostspielige Verzögerungen und Nacharbeiten im späteren Verlauf des Entwicklungsprozesses in Kauf zu nehmen. Darüber hinaus bezieht sich dieser Grundsatz auch auf die Idee, Misserfolge zu akzeptieren und aus ihnen zu lernen, was dem Team ermöglicht, sich kontinuierlich zu verbessern und an veränderte Anforderungen oder unerwartete Probleme anzupassen.

Hochwertige Software flexibel zu entwickeln, ist ein Anspruch von Extreme Programming. In der Praxis können jedoch der Wunsch nach Wirtschaftlichkeit und der Zwang zu Kostensenkungen die Qualität einer Software beeinträchtigen. Um dies zu verhindern, adressiert XP Kosten nicht als Maßstab. Zudem werden auch keine Endtermine fixiert, da auch dies die Qualität beeinflussen könnte. Ohne zeitliche Flexibilität bleiben mögliche Verbesserungen auf der Strecke und Kundenwünsche unerfüllt.

Kleine Schritte sind ein zentrales Prinzip in XP. Durch kleine Schritte entsteht ein kontinuierlicher Fluss, so lassen sich Veränderungen zeitnah vornehmen, so lässt sich Feedback zu Features umsetzen. Gleichzeitig hilft das Prinzip dabei, Risiken von Fehlentwicklungen und die Wahrscheinlichkeit von Fehlschlägen zu minimieren.

Die akzeptierte Verantwortung ist das letzte der 14 Prinzipien. Es besagt bspw., dass ein Entwickler, der für die Bearbeitung einer User Story verantwortlich ist, für die Umsetzung und damit für den Entwurf, das Kodieren und das Testen Verantwortung übernimmt.

Praktiken in Extreme Programming

XP definiert Haupt- und Begleitpraktiken bzw. primäre und sekundäre Praktiken:³

Folgende 13 Haupt- bzw. Primärpraktiken werden genannt:⁴

• Räumlich zusammen sitzen,
• komplettes Team,
• informative Arbeitsumgebung,
• energievolle Arbeit,
• entspannte Arbeit,
• Pair Programming,
• Benutzergeschichten,
• wöchentlicher Zyklus,
• quartalsweiser Zyklus,
• 10-Minuten-Build,
• Continuous Integration,
• Test First Programming und
• inkrementelles Design.

XP postuliert einerseits, dass eine räumliche Nähe die Kommunikation der Beteiligten fördert, und anderseits, dass genügend Freiraum für eine individuelle Privatsphäre vorhanden sein muss. Der Arbeitsplatz sollte dahingehend “informativ” sein, dass alle wichtigen Informationen von jedem Arbeitsplatz gut sichtbar sind.⁵ Generell ist das Team wichtiger als das Individuum. Es trifft gemeinsame Entscheidungen, tauscht sich täglich aus und löst Probleme selbständig. Die Arbeit erfolgt idealerweise in einer kollegialen Atmosphäre, mit voller Motivation und ohne Überstunden. Sicherheitspuffer werden einkalkuliert und unerfüllbare Versprechen vermieden. Ziel ist die maximale Produktivität.

Die Funktionalität, die entwickelt werden soll, wird in Form von Benutzergeschichten – bspw. User-Storys – beschrieben.⁶ Kundenwünsche werden in wöchentlichen Zyklen realisiert, das Projekt mit seinen Releases wird quartalsweise geplant. Die vierteljährigen Zyklen eignen sich auch für den Austausch mit allen Beteiligten, um das bisher Erreichte, Herausforderungen und nächste Schritte zu besprechen.⁷

Die Software wird mithilfe von Test First Programming – vor der Realisierung einer Funktionalität wird ein entsprechender Test geschrieben – und wechselnden Partnern beim Pair Programming entwickelt. Das Build der Software sollte nicht länger als zehn Minuten beanspruchen und sämtliche Codeänderungen der Entwickler sollten ca. alle zwei Stunden in einem zentralen Repository gespeichert werden. Gleichzeitig verbessert das inkrementelle Design, das Feedback und neue Erkenntnisse aufnimmt, kontinuierlich das Design der Software.

Folgende 11 Begleitpraktiken bzw. sekundäre Praktiken werden genannt:

• richtige Kundeneinbeziehung,
• inkrementelles Deployment,
• Team-Konstanz,
• schrumpfende Teams,
• ursachliche Analysen,
• geteilter Code,
• Code und Tests,
• eine zentrale Codebasis,
• tägliches Deployment,
• verhandelbarer, vertraglicher Funktionsumfang sowie
• Pay-per-Use.

Der Kunde spielt eine zentrale Rolle im Entwicklungsprozess, den er nimmt regelmäßig an Sitzungen teil und wirkt aktiv bei der Festlegung des zu entwickelnden Funktionsumfangs mit, der Gegenstand von Verhandlungen ist. Um gemeinsam mögliche Risiken zu minimieren und gleichzeitig die Flexibilität zu erhöhen, lässt sich der Funktionsumfang in kleineren Vereinbarungen fixieren. Je nach Kontext kann die Bezahlung variieren; es könnte bspw. sein, dass anstelle einer vereinbarten Bezahlung bei Release-Lieferung auch ein Bezahlmodell wie Pay-per-Use zum Tragen kommt, bei dem die aktive Nutzung der Software eine Bezahlung auslöst.

Damit das Entwicklungsteam die Fähigkeiten zur effektiven Zusammenarbeit erwerben kann, ist es sinnvoll, es über mehrere Projekte konsistent zu halten. Wird das Team im Laufe der Zeit kompetenter und produktiver, sollte seine Arbeitsbelastung konstant bleiben, selbst wenn Ressourcen auf andere Teams verlagert werden.

Der Code als zentrales Medium spielt im Entwicklungsprozess eine entscheidende Rolle. Er wird in einem Repository gespeichert, sodass nur eine gemeinsame Codebasis existiert. Entwickler werden ermutigt, auch den Code von Kollegen zu bearbeiten bzw. zu nutzen, was das kollektive Eigentum am Code fördert. Neben dem Code sind Tests ein entscheidender Bestandteil der Entwicklung. Andere Formen der Dokumentation werden allein aus Code und Tests generiert.

Um Schwierigkeiten frühzeitig zu erkennen, wird ein inkrementelles Deployment durchgeführt. Werden Altsysteme durch neue Software ersetzt, wird ein Teil nach dem anderen ausgetauscht, um so den gesamten Ablauf berechenbarer zu gestalten. Die Bereitstellung erfolgt schrittweise und täglich. Diese Routine minimiert Kosten und Fehler und ermöglicht sowohl eine kontinuierliche Integration als auch die Nutzung von Akzeptanztests. Beim Auftreten von Fehlern wird eine Ursachenanalyse mit dem Ziel durchgeführt, das erneute Auftreten des Fehlers zu verhindern und das Team in die Lage zu versetzen, dass es denselben Fehler nicht erneut produziert.

Vorteile und Nachteile von Extreme Programming

Extreme Programming bietet einige Vorteile, insbesondere im Vergleich zu dem zum Veröffentlichungszeitpunkt Mitte der 90er Jahre eher verbreiteten Wasserfallmodell:

• Es integriert den Kunden aktiv in die Entwicklung. Er kann seine Wünsche im laufenden Projekt kundtun, neue Anforderungen formulieren oder bestehende Anforderungen neu priorisieren. Er lernt das Team der Entwickler besser kennen, gewinnt Vertrauen in die Beteiligten und fungiert als “echter” Ansprechpartner.
• Kurze Entwicklungszyklen, frühzeitige Fehlererkennung und regelmäßiges Feedback sorgen für ein Produkt, das idealerweise den aktuellen Wünschen und Anforderungen des Kunden entspricht und somit wirklichen Nutzen stiftet.
• Die Werte definieren einen Rahmen des Miteinanders und einen gemeinsamen Anspruch an die qualitativ hochwertige Entwicklung von Software.
• Die Prinzipien helfen, das Miteinander greifbarer zu machen. In gewisser Weise hält die Realität Einzug in die Softwareentwicklung.
• Die Praktiken formulieren Hilfestellungen und Ansätze, die das Arbeiten erleichtern, und Qualität zu einem inhärenten Bestandteil machen.

Diesen Vorteilen stehen auch einige Nachteile, insbesondere im Vergleich zu heutigen Ansätzen gegenüber:

• Test First Programming und Pair Programming können in bestimmten Kontexten Vorteile haben, sie allerdings allgemein anderen Ansätzen vorzuziehen, ist nicht immer zielführend.
• In Organisationen zu arbeiten, deren Mitarbeiter Werte teilen, ist häufig vorteilhaft, lässt sich aber nicht wirklich erzwingen und vorgeben. Werte sind individuell, Organisation tun daher gut daran, für Arbeitsbedingungen zu sorgen, die ein Wirken in eine gemeinsame Richtung fördern.
• Auf das Wohlergehen von Entwicklern zu achten, ist sinnvoll, evtl. sollte sich dies aber tatsächlich auf die Arbeitsumgebung beziehen. Heutzutage ist es nicht unüblich, dass die Entwicklung von Software auch standortunabhängig erfolgen kann. Hier bspw. die gemeinsame Entwicklung vor Ort zu postulieren, ist daher eher kontraproduktiv.
• Implizit geht Extreme Programming davon aus, dass es eine Art idealer Kunde gibt, der bspw. auf eine umfassende Dokumentation verzichtet, der keine Spezifikation benötigt und für den fixierte Terminzusagen weniger wichtig sind. Implizit gibt es auch einen idealen Programmierer, der auf ein persönliches Code Ownership verzichtet, offenen für permanente Änderungen ist und selbstredend die Vorzüge von Test First Programming und Pair Programming schätzt. Möglicherweise treffen sich der ideale Kunde und der ideale Entwickler nie im wahren Leben.
• Generell beschreibt XP Werte, Prinzipien und Praktiken, dabei bleibt aber unklar, was passiert, wenn sich Teams entscheiden, eigene Werte zu definieren, anderen Prinzipien zu folgen oder Praktiken wegzulassen.

Die Meinungen variieren übrigens, ob der Name Extreme Programming Vorteil oder Nachteil ist. Einerseits klingt er im wahrsten Sinne des Wortes extrem und betont die klare Abkehr von vorherigen Vorgehensweisen. Andererseits wurde er von der Gegenwart überholt, insbesondere da viele Praktiken heutzutage üblich sind und sich bei genauerer Betrachtung wenig Extremes in dem Vorgehen findet.

Gemeinsamkeiten und Unterschiede zwischen Extreme Programming und Scrum

Mit Scrum gibt es einen Ansatz, der – ursprünglich ebenfalls in der Softwareentwicklung beheimatet – ein ähnlich agilen Ansatz propagiert. Wo liegen Gemeinsamkeiten und wo liegen Unterschiede?

Gemeinsamkeiten:

• Beide Ansätze formulieren Werte: Einfachheit, Kommunikation, Feedback, Mut und Respekt in XP, Selbstverpflichtung, Mut, Offenheit, Fokus und Respekt in Scrum. Auch wenn sich die Werte im Detail unterscheiden, so ist die Benennung von Werten eine Gemeinsamkeit.
• Beide Ansätze propagieren kurze Iterationen und ein iteratives Vorgehen mit regelmäßigem Austausch und kontinuierlichem Feedback. Zudem basieren sie auf Empirie (Wissen entsteht aus Erfahrung und Entscheidungen werden gemeinsam auf Grundlage von Beobachtungen getroffen) und Lean Thinking  (Verschwendung wird vermieden und der Fokus liegt auf dem Wesentlichen). 
• Generell ist die Nähe zum Agilen Manifest in beiden Ansätzen erkennbar; beide Vorgehensweisen schätzen bspw. funktionierende Software wichtiger als eine umfangreiche Dokumentation ein.
• Scrum definiert Verantwortlichkeiten bzw. Accountabilitys, Extreme Programming benennt die akzeptierte Verantwortung als Prinzip.
• Auch wenn es in Scrum mit dem Scrum Master, dem Product Owner und den Entwicklern besagte Verantwortlichkeiten gibt, und in XP verschiedene Perspektiven wie bspw. die Kunden- oder die Entwicklerperspektive beschrieben werden, so definiert kein Ansatz weitergehende Rollen.
• Scrum definiert explizit Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive), XP labelt Formate zum Austausch weniger explizit, aber auch dort gibt es die Planung von kurzen (wöchentlichen) Zyklen, den täglichen Austausch, das Review von Arbeitsergebnissen sowie den Austausch über die Verbesserung der Zusammenarbeit.

Unterschiede:

• Sowohl XP als auch Scrum haben eine enge Verbundenheit mit dem Agilen Manifest.⁷ Während Extreme Programming jedoch “eigene” Prinzipien formuliert, verzicht Scrum darauf. Auch explizite Praktiken werden in Scrum nicht formuliert, implizit finden sich jedoch auch diese bspw. in Form definierter Commitments.
• Beide Ansätze haben ihren Ursprung in der Softwareentwicklung, XP ist dort auch heutzutage beheimatet, Scrum hingegen definiert sich inzwischen als Framework für die Entwicklung und Instandhaltung komplexer Produkte und Dienstleistungen, das seit vielen Jahren in unterschiedlichen Bereichen und Industrien für die Produktentwicklung und im Projektmanagement verwendet wird. 
• Ein großer Unterschied lässt sich in der Vermarktung und Verbreitung erkennen: Scrum wird mithilfe des Scrum Guides – im englischen Original kompakt mit 14 Seiten – beschrieben. 2020 wurde bereits die 7. Version veröffentlicht. Diese ist in 80 Sprachen übersetzt. Unabhängig davon, ob es sich dabei um Ursache oder Wirkung handelt, zeigt es, dass Scrum weltweit – und das auch branchenübergreifend – eine große Bedeutung genießt. XP hingegen besitzt weder eine entsprechende Reputation, noch eine vergleichbare Verbreitung.

Impuls zum Diskutieren:

Eignet sich XP für Festpreisprojekte, den Einsatz in verteilten Umgebungen oder bei Vorhaben mit fixierten Fertigstellungsterminen?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] In manchen Publikationen wird Extreme Programming auch als Vorgehensmodell oder als Sammlung von Best Practices beschrieben. Andere Veröffentlichungen ordnen den Ansatz als implizites Risikomanagement ein, der Risiken implizit adressiert, ohne explizite Verfahrensweisen – bspw. in Form von dokumentierten Risikolisten – zu verwenden.
[2] Extreme Programming Explained: Embrace Change, Second Edition
[3] In der ersten Auflage des Buches von Kent Beck wurden 12 Praktiken genannt: Pair Programming, kollektives Eigentum, permanente Integration, testgetriebene Entwicklung bzw. permanentes Testen, Kundeneinbeziehung, Refactoring, keine Überstunden, Iterationen, Metapher, Coding-Standards, einfaches Design und Planning Game. In der 2. Auflage waren es dann wie beschrieben 13 Primär- und 11 Sekundärpraktiken. Die ursprünglich genannten Aspekte werden auch als traditionelle und die neuen Ausführungen als evolutionäre Praktiken beschrieben. Sie konkretisieren oder modifizieren die ursprünglichen Ausführungen, um die Nutzung klarer und verständlicher zu machen. Inhaltlich wurden die Systemmetapher, die schwer umzusetzen war, und die Programmierstandards gestrichen.
[4] Ron Jeffries formulierte mit Customer Tests eine weitere XP Hautpraktik.
[5] Offensichtlich wurde die räumliche Nähe als Praktik formuliert, bevor eine effiziente, zielgerichtete Arbeit im Homeoffice möglich schien. Auch die Visualisierung von Informationen an Wänden im Zuge eines “informativen Arbeitsplatzes” wirkt in Anbetracht heutiger Softwarelösungen etwas “einseitig” bzw. teilweise “überholt”. Hier finden Sie einen Beitrag über die Vorteile von Remote Work.
[6] Immer wieder wird im Internet behauptet, dass die User Story auf Scrum zurückgeht. Das ist falsch. Ihren Ursprung hat sie in XP als Element im Planning Game. Das Planning Game gilt als traditionelle Praktik.
[7] Nicht nur die drei Erfinder von XP (Beck, Cunningham und Jeffries) haben das Agile Manifest unterzeichnet, auch die beiden Erfinder von Scrum (Jeff Sutherland und Ken Schwaber) gehören zu den 17 Erstunterzeichnern.

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.