Etwas, das ich schon seit geraumer Zeit ärgerlich finde, ist, wie häufig viele in der Branche Begriffe wie „Scrum aber …“ in einem abwertenden Sinn verwenden und damit implizieren, dass Teams nur die wenigen Praktiken befolgen sollten, die Teil von Scrum sind. Die Realität ist, dass Scrum allein nicht ausreicht, um ein agiles Team in die Lage zu versetzen, wiederholt funktionierende Software über einen längeren Zeitraum hinweg zu liefern. Ob sie sich dessen bewusst sind oder nicht, die überwiegende Mehrheit der Teams, die sich selbst als Scrum-Teams bezeichnen, arbeiten als Scrum-XP-Hybrid oder als Scrum-Kanban-XP-Hybrid, bei dem sie zumindest eine Teilmenge der technischen Praktiken anwenden, die ihren Ursprung in XP haben.
Lassen Sie mich zu Protokoll geben, dass Teams, die nur den Scrum-Praktiken folgen, wahrscheinlich nicht langfristig erfolgreich sein werden, da zumindest eine Teilmenge der technischen XP-Praktiken ein Muss für den dauerhaften Erfolg eines agilen Lieferteams ist.
Ich habe festgestellt, dass es nicht genug Leute gibt, die verstehen, was Scrum beinhaltet und was nicht, also fangen wir dort an.
Was Scrum ist – eine Reihe von Managementpraktiken
Scrum ist die Anwendung empirischer Prozesskontrolle, was eine schöne Umschreibung dafür ist, dass wir Entscheidungen auf der Grundlage von Erfahrungen treffen sollten und nicht auf der Grundlage von hypothetischen Annahmen, die nicht in der Realität begründet sind.
Vereinfacht gesagt, besteht Scrum aus einer kleinen Reihe von Managementpraktiken, die Teams helfen sollen, effektiv zusammenzuarbeiten und Arbeit in einer iterativen Art und Weise zu liefern (lassen Sie mich noch einmal betonen – es gibt null technische Praktiken in Scrum).
Um den Inhalt des Scrum-Leitfadens kurz zusammenzufassen:
- Es gibt ein Scrum-Team, das aus Entwicklern, dem Product Owner und dem Scrum Master besteht.
- Es gibt Scrum-Ereignisse, die aus dem Sprint, der Sprint-Planung, dem Daily Scrum (in XP auch Daily Standup genannt), dem Sprint-Review und der Sprint-Retrospektive bestehen.
- Es gibt Scrum Artefakte, die aus dem Product Backlog, dem Sprint Backlog und dem Increment bestehen, wobei ein Increment existiert, sobald ein Item aus dem Sprint Backlog die Definition von Done erfüllt.
- Es gibt eine Definition von Done, bei der jedes Scrum Team ein gemeinsames Verständnis davon hat, was „done“ für ein beliebiges Product Backlog Item bedeutet. Beachten Sie, dass die Definition of Done im Gegensatz zu den Acceptance Criteria global angewendet wird, während Acceptance Criteria spezifisch für einzelne Product Backlog Items sind.
Was Scrum nicht ist
Entgegen der landläufigen Meinung ist keines der folgenden Dinge Teil von Scrum:
- User Stories. Die Work Items im Product Backlog oder Sprint Backlog eines Scrum-Teams werden als User Stories geschrieben (oft im Format „Als <Persona/Rolle> will ich <Ziel>, damit <erwünschtes Ergebnis>“), aber Scrum schreibt kein bestimmtes Konstrukt oder Format vor. Beachten Sie, dass User Stories Teil von XP sind.
- Estimation. Obwohl die überwiegende Mehrheit der Scrum-Teams auf irgendeiner Ebene eine Schätzung durchführt, ist die Praxis der Schätzung nicht Teil von Scrum.
- Velocity. Velocity ist ebenfalls nicht Teil von Scrum; der Begriff der Projekt-Velocity ist Teil von XP.
- Technische Praktiken. Wie bereits erwähnt, gibt es in Scrum keinen Begriff für technische Praktiken (CI, CD, Pair Programming, TDD, etc.). Die überwiegende Mehrheit der technischen Praktiken, die Teams typischerweise anwenden, haben ihren Ursprung in XP.
Was ist Extreme Programming?
Es ist mehr als zwei Jahrzehnte her, dass das erste Extreme Programming (XP)-Team gebildet wurde, das an einem Projekt namens Chrysler Comprehensive Compensation (C3) arbeitete. Die Methoden, die dieses Team einsetzte, stammen zu einem großen Teil aus den 1980er Jahren, als Kent Beck und viele andere mit besseren Methoden zur Softwareentwicklung experimentierten, d.h. mit einer Alternative zum „Wasserfall“-Ansatz, der zu dieser Zeit vorherrschend geworden war.
Die Visualisierung der Arbeit war schon immer ein wichtiges Mittel, um zu erfahren, wie agile Teams arbeiten. Daher empfehle ich jedem, der mehr über XP erfahren möchte, mit diesen Diagrammen zu beginnen:
- Extreme Programming Project (End-to-End-Diagramm)
- Iteration (Diagramm, das sich auf die Vorgänge innerhalb einer Iteration konzentriert; beachten Sie, dass das, was XP als Iteration bezeichnet, konzeptionell dem ähnelt, was Scrum als Sprint bezeichnet)
- Development (Diagramm, das sich auf die Interaktionen und Aktivitäten bei der Entwicklung konzentriert)
- Collective Code Ownership (Diagramm, das sich auf die zentralen technischen Praktiken konzentriert)
Hinweis: Eine visuelle Darstellung, die viele der Elemente aus den obigen Diagrammen auf einer Seite kombiniert, finden Sie in Bill Wakes Extreme Programming Overview.
Zusätzliche Lektüre über XP
Wenn die obigen Diagramme Sie so faszinieren, dass Sie mehr über XP lesen möchten, lesen Sie die folgenden Informationsquellen, die mehr oder weniger in der Reihenfolge „am kürzesten zu lesen“ > „am längsten zu lesen“ aufgeführt sind:
- Don Wells, Extreme Programming: a gentle introduction
- Martin Fowler, BeckDesignRules (siehe auch Xp Simplicity Rules)
- Kent Beck, Ward Cunningham, et al., Extreme Programming Core Practices (auch bekannt als die 12 XpXtudes)
- Don Wells, The Rules of Extreme Programming
- Ward Cunningham, et al.,Extreme Programming (auch bekannt als das WikiWikiWeb)
- Ron Jeffries, What is Extreme Programming?
- Kent Beck & Cynthia Andres, Extreme Programming Explained: Embrace Change (2nd Ed.)
Additional References
Alle Referenzen in diesem Abschnitt stammen von Don Wells‘ XP-Website, sofern nicht anders angegeben.
- Agile Modelle sind Gemälde, keine Fotografien (alle Modelle sind falsch; einige sind nützlich)
- Agile Process Proverbs (Worte, nach denen jedes Team leben sollte)
- Bill Wake, Arrange, Act, Assert (Muster für das Schreiben von Unit-Tests)
- Bill Wake, Sudoku Solver (interessante Variante von TDD)
- Bill Wake, Tests from a Hat (ein kreativer Ansatz zum Schreiben von Unit-Tests)
- Honest Plans (wie Schätzungen in der Praxis aussehen)
- Manage Your Goals Instead of Activities (Hauptunterschiede zwischen Wasserfall- und agiler Entwicklung)
- The Values of Extreme Programming (Einfachheit, Kommunikation, Feedback, Respekt, Mut)
- XP und Datenbanken (ein Muster basierend auf Gold > Silber > Bronze Datenbanken )