Was ist Scrum @ HIS?
Vieles wurde über agile Softwareentwicklung und Scrum bereits gesagt und geschrieben und die Meinungen dazu gehen manchmal weit auseinander. Dieser Artikel will einen kurzen Überblick des Scrum Frameworks geben und die wichtigsten Begriffe klären und richtet sich an alle Entwickler, Business Analysten, Tester, Projektleiter, welche mit Scrum konfrontiert sind.
Scrum wurde in den neunziger Jahren von Ken Schwaber und Jeff Sutherland entwickelt und ist eine Vorgehensweise, welche die Komplexität in der Produktentwicklung beherrschbar machen will.
Scrum unterstützt die agile Vorgehensweise, deren Hauptmerkmal das Anerkennen der Tatsache ist, dass Lösungen zu einem komplexen Problem iterativ erarbeitet werden müssen. Weder der Weg noch das Ziel sind im Vornherein genau bekannt. Häufig ist es nicht einfach, die Stakeholder von der Effizienz dieses Vorgehens zu überzeugen.
Komplex versus Kompliziert:
«Komplex ist eine Problemstellung dann, wenn sowohl das Was (Requirements) als auch das Wie (Technology) nur teilweise bekannt sind.»
Ut perspiciatis, unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam eaque ipsa, quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt, explicabo.
In diese Sinne komplexe Problemstellungen sind in der modernen Softwareentwicklung häufiger die Regel als die Ausnahme. Hier kann Scrum erheblich dabei helfen, Komplexität durch empirisches, inkrementelles und iteratives Vorgehen zu reduzieren.
Das Scrum Framework
Rollen
Kern des Scrum Frameworks ist das Scrum Team. Das Scrum Team ist als Ganzes verantwortlich für die Entwicklung des Produktes und besteht aus den folgenden Mitgliedern:
1 – 8 Developer:
Developer sind für die Entwicklung der vom Product Owner definierten Anforderungen verantwortlich. Dies beinhaltet sämtliche dazu notwendigen Tätigkeiten wie z. Bsp. Entwicklung, Testing, Business Analyse etc.
1 Scrum Master:
Der Scrum Master ist für die zweckmässige Anwendung des Scrum Frameworks verantwortlich. Er überprüft die Einhaltung der Regeln und schult das Scrum Team. Zudem beseitigt er Störeinflüsse, welche die Arbeit des Scrum Teams behindern können. Hat sich das Scrum Team erfolgreich etabliert, kann der Scrum Master die Rolle des Change Managers übernehmen.
1 Product Owner:
Der Product Owner ist für den wirtschaftlichen Erfolg des zu entwickelnden Produktes verantwortlich. Er dient als Bindeglied für die Anforderungen zwischen den Stakeholdern (Fachbereich, Sponsoren, Management) und dem Scrum Team (IT Umsetzung). Er führt das Produkt Backlog, welche sämtlichen Anforderungen enthält und verfeinert und priorisiert diese.
Artefakte
Das Scrum Framework sieht folgende Artefakte vor:
Product Backlog
Das Product Backlog ist eine geordnete Auflistung der Anforderungen an das Produkt. Das Product Backlog ist dynamisch und wird ständig weiterentwickelt. Alle Arbeit, die das Entwicklungsteam erledigt, muss ihren Ursprung im Product Backlog haben. Der Product Owner ist für die Pflege des Product Backlogs verantwortlich. Er verantwortet die Reihenfolge bzw. Priorisierung der Einträge.
Sprint Backlog
Das Sprint Backlog ist der aktuelle Plan der für einen Sprint zu erledigenden Aufgaben. Es umfasst die Product-Backlog-Einträge, die für den Sprint ausgewählt wurden, und die dafür nötigen Aufgaben (z. B. Entwicklung, Test, Dokumentation). Das Sprint Backlog wird laufend nach der Erledigung einer (Teil-) Aufgabe von den Team-Mitgliedern aktualisiert. Dies dient zur Übersicht des aktuellen Bearbeitungsstands.
Definition of Done / Definition of Ready
Zum Kern von Scrum gehört eine Transparenz über den Fortschritt des Produkts und des Sprints – innerhalb und außerhalb des Teams. Während das Produktinkrement den Fortschritt am deutlichsten sichtbar macht, so sind dennoch andere Techniken zur Fortschrittstransparenz notwendig.
Die Definition of Done (DoD) ist ein gemeinsames Verständnis des Scrum Teams, unter welchen Bedingungen eine Arbeit als fertig bezeichnet werden kann. Sie enthält für gewöhnlich Qualitätskriterien, Einschränkungen und allgemeine nicht-funktionale Anforderungen. Mit zunehmender Erfahrung des Scrum Teams entwickelt sich die Definition of Done weiter. Sie enthält dann strengere Kriterien für höhere Qualität.
Die Definition of Ready (DOR) folgt dem Ansatz der Definition of Done. Sie soll sicherstellen, dass ein Eintrag im Produkt Backlog vom Team implementiert werden kann, also wirklich alle notwendigen Vorbedingungen und Inputs verfügbar sind, beispielsweise stabile und freigegebene Interfacedokumente (ICDs). Zudem muss ein gemeinsames Verständnis über den Inhalt des Eintrags vorhanden sein. Verantwortlich für die Einhaltung der DOR ist der Produkt Owner. Nur Einträge, die Ready sind, können in einen Sprint übernommen werden.
Product Increment
Das Inkrement ist die Summe aller Product-Backlog-Einträge, die während des aktuellen und allen vorangegangenen Sprints fertiggestellt wurden. Am Ende eines Sprints muss das neue Inkrement in einem nutzbaren Zustand sein und der Definition of Done entsprechen.
Ereignisse
In Scrum wird anstatt von Meetings von Events gesprochen. Diese sind durchwegs durch feste Zeitfenster begrenzt (timeboxed), welche nicht überschritten werden sollten. Dies dient der besseren Fokussierung.
Sprint Planning (Dauer 8 Std. für einen Monatssprint):
Bei der Sprintplanung wird sowohl das Was wie auch das Wie der aus dem Product Backlog umzusetzenden Anforderungen im Team bestimmt. Das Resultat spiegelt sich im Sprint Backlog wider.
Daily Scrum (Dauer max. 15 Minuten):
Zu Beginn eines jeden Arbeitstages trifft sich das Entwicklerteam zu einem Daily Scrum, bei dem Scrum Master und Product Owner häufig anwesend, jedoch nicht aktiv beteiligt sind, falls sie nicht selbst Backlogelemente bearbeiten. Zweck des Daily Scrum ist der Informationsaustausch. Im Daily Scrum werden keine Probleme gelöst – vielmehr geht es darum, sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen. Dazu hat sich bewährt, dass jedes Teammitglied mit Hilfe des Taskboards sagt, was es seit dem letzten Daily Scrum erreicht hat, was es bis zum nächsten Daily Scrum erreichen möchte, und was dabei im Weg steht.
Sprint Review (Dauer max. 4 Std. für einen Monatssprint):
Das Sprint Review steht am Ende des Sprints. Hier überprüft das Scrum-Team das Inkrement, um das Product Backlog bei Bedarf anzupassen. Das Entwicklungsteam präsentiert seine Ergebnisse und es wird überprüft, ob das zu Beginn gesteckte Ziel erreicht wurde. Das Scrum Team und die Stakeholder besprechen die Ergebnisse und was als Nächstes zu tun ist.
Im Sprint Review ist die Beteiligung von Kunden und Anwendern wichtig, da diese die fertige Funktionalität des Inkrements benutzen und validieren können. Hieraus ergibt sich wichtiges Feedback für die weitere Produktgestaltung.
Das Ergebnis des Sprint Review ist das vom Product Owner notierte Feedback der Stakeholder. Dies ist eine notwendige Information bei der weiteren Gestaltung des Product Backlogs im nächsten Product-Backlog-Refinement.
Es ist Aufgabe des Product Owners, die entwickelten Funktionalitäten zu begutachten. Anhand der im Sprint Planning festgelegten Bedingungen entscheidet er, ob sie abgenommen werden können oder nicht. Dabei soll er keine Kompromisse eingehen: Ein Team hat auch dann sein Ziel verfehlt, wenn es eine „fast fertige“, aber noch nicht getestete Funktionalität liefert. In diesem Fall kehren die nicht fertiggestellten User Stories in das Product Backlog zurück und werden vom Product Owner neu priorisiert. Die Abnahme ist aber nicht primärer Gegenstand des Sprint Reviews, bei dem es vorrangig um das Feedback der Stakeholder geht. Die Abnahme der Funktionalitäten des Produktinkrements wird daher häufig im Rahmen des Sprints umgesetzt.
Sprint Retrospektive (Dauer max. 3 Std. für einen Monatssprint):
Die Sprint-Retrospektive steht am Ende eines Sprints. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen. Der Scrum Master unterstützt das Scrum Team darin, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden. Die Retrospektive ist ein gemeinsames Ereignis des Scrum Teams.
Weiterführende Literatur und Ressourcen:
Es existiert eine reiche Auswahl an weiterführender Literatur zum Thema. Nachfolgend einige Vorschläge:
