Wir leben heute in einer schnellebigen Zeit. Einer Zeit in der morgen schon etwas, was heute noch für richtig und wichtig befunden wurde, nicht mehr gilt. Vor noch wenigen Dekaden war auch die Softwareentwicklung starren Strukturen unterworfen. Der Kunde/Stakeholder trat mit einem Softwarewunsch an eine Firma heran. Diese setzte sich mit Lasten- und Pflichtenheften auseinander, plante das komplette Projekt durch, nur um am Ende festzustellen, dass es nicht den Erwartungen des Stakeholders entspricht.
Um den stetigen Änderungen entgegenzutreten wurden agile Vorgehensmodelle entwickelt, die sich eben diesen Änderungen anpassen können. Eines dieser möglichen Vorgehensmodelle ist SCRUM. Im Gegensatz zu zB Kanban, wurde SCRUM speziell für die Softwaretechnik entworfen und betrifft das Projekt- ud Produktmanagement im besonderen.
Was ist Scrum?
Was ist SCRUM genau? Es ist ein Vorgehensmodell, also eine Methode, keine Software. Auch wenn es spezielle Software für den Einsatz gibt (Projekt- oder Ticketsysteme), so ist nicht zwingend ein solches Programm einzusetzen.
SCRUM hat 4 Leizsätze:
- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
- Funktionierende Software ist wichtiger als umfassende Dokumentation
- Zusammenarbeit mit dem Auftraggeber ist wichtiger als die Vertragsverhandlung
- Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.
Auch ergänzende 12 Grundprinzipien wurden dazu erstellt:
- Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen
- Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden
- Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne
- Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten
- Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen
- Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht
- Funktionierende Software ist das wichtigste Fortschrittsmaß
- Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können
- Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität
- Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell
- Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams
- In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an
All das zusammen ist dem Agilen Manifest entnommen (siehe [MASD]).
Die Basis der Arbeit bilden grob definierte Ziele, die User Stories genannt werden. Gibt es mehrere zu einem ähnlichen Thema, so fasst man sie zu „Epics“ zusammen. Eine User Story ist ähnlich aufgebaut, wie: „Als Mitarbeiter in der Logistik möchte ich meine Waren digital erfassen können.“ Ob hierzu ein User Interface eingebaut werden muss, oder eine Kamerasoftware, die einen Barcode einliest, ist hier noch nicht wichtig. Basierend auf [Coh04] schreibt A. Krallmann in [OS], über die Userstories:
- User-Stories sind dazu da, um Kommunikationen zwischen dem Fachbereich und Entwickler zu erzwingen; sie können für Iterationsplanungen verwendet werden und verschieben eine detailliertere Ausarbeitung auf später.
- Akzeptanztests sind dazu da, um Details zu einer User-Story zu dokumentieren.
- User-Stories sind transient und überleben nicht die Iteration, in der sie implementiert werden.
- Die Nachteile von User-Stories sind insbesondere bei größeren Projekten deren Verwaltung, die Traceability zwischen ihnen und sie ersetzen keine Dokumentation des zu entwickelnden Systems.
Trotzdem haben diese Userstories Vorteile. Gerade durch die Tatsache, das das Team darüber diskutiert, werden mehrere Sichtweisen berücksichtigt, die die Userstory bereichern.
Nach der gemeinsamen Formulierung werden diese dann im „Product Backlog“ abgelegt. Dazu später mehr.
Völlig von der Rolle
Auch wenn gerade darüber diskutiert wird, weitere Rollen in das Konstrukt aufzunehmen, so gibt SCRUM aktuell drei Rollen vor:
- Product Owner
- Entwicklungsteam
- Scrum Master
Auf Kundenseite gibt es:
- Stakeholders (Entscheidungsträger)
- Users (Nutzen)
Product Owner
Luis Reyes, CC-BY-NC-SA, blog.luis-reyes-plasencia.info
Der Product Owner ist für den wirtschaftlichen Erfolg verantwortlich und pflegt das „Product Backlog“ zuständig. Dies ist ein Ort, an dem die Eigenschaften des Produktes (die künftigen) definiert werden. Mit dem Entwicklungsteam und den Stakeholdern werden hier neue Anforderungen eigepflegt. Der Product Owner ist derjenige, der regelmäßig mit den Stakeholdern spricht und versucht, Ihre Bedürfnisse zu verstehen. Auch ist er derjenige, der die Prioritäten der User Stories festlegen kann. Die ständige Priorisierung erfolgt meist aus einer Kosten-Nutzen-Relation. Das bedeutet, dass mit Scrum schnell vorzeigbare und nutzbare Ergebnisse vorliegen.
Team
Das Entwicklungsteam besteht aus drei bis neun Mitgliedern. Idealerweise hat jedes Mitglied andere Kenntnisse und Fähigkeiten, so das auch komplexere Projekte umgesetzt werden können. Das Team organisiert sich selbst, und lässt sich weder vom Scrum Master, noch vom Product Owner vorschreiben, wie Backlogeinträge umgesetzt werden. Die Schätzung des Umfangs einzelner Einträge obliegt ebenfalls dem Team. Vor einem neuen Sprint entnimmt das Team aus dem Product Backlog einige User Stories, und bricht sie auf einzelne Aufgaben (Tasks) herunter. Letztere sollten in spätestens einem Tag erledigt sein. All dies fließt in den Sprint Backlog ein.
Der Sprint Backlog ist derjenige, welches sich das Team selbst gibt. Es schätzt den Aufwand pro User Story, und übernimmt so viele Aufgaben, wie möglich in den Sprint.
Der Sprint selbst ist eine ständige Iteration. Nach dem Sprint ist vor dem Sprint. Er kann jeweils eine Woche oder auch einen Monat dauern. In jedem Fall ist es wichtig, am Ende ein funktionales Produkt auszuliefern.
Scrum Master
Jetzt fehlt zuletzt noch die dritte Rolle: der „Scrum Master“. Er kann Bestandteil des Teams sein, muss er aber nicht. So wirkt er als Coach und verantwortlich für das Gelingen des Teams. Zudem räumt alle Hindernisse aus dem Weg, wie möglicherweise mangelnde Kommunikation, persönlichen Spannungen im Team oder Störungen in der Zusammenarbeit mit dem Product Owner. Diese Rolle erfordert Fähigkeiten im situativen Führen (siehe zB Ken Blanchard).
Der Sprint
Wie ist der Ablauf eines Sprints?
Zu Beginn steht die Planungsphase. Es wird festgelegt, was entwickelt wird, und ebenfalls wie es entwickelt wird. Was entwickelt werden soll, wird vom Product Owner festgelegt.
Definition of Done
Das Team erarbeitet gemeinsame Akzeptanzkriterien (Definition of Done). Somit wird auch die Frage danach beantwortet, wann eine Arbeit als fertig zu gelten hat. Anfangs benötigt dieser Schritt vielleicht etwas mehr Zeit. Aber durch weitere Iterationen und wachsender Erfahrung werden auch hier Grundlagen gelegt, die für weitere Iterationen gelten können. Grundsätzlich gilt es auch in einer Scrum-Umgebung reguläre Tests, sowie eine Entwicklerdokumentation anzufertigen. Auch diese Positionen kosten Zeit und müssen implementiert werden. Schlußendlich jedoch spart es Zeit, da diese Schritte zur Gewohnheit werden, und der Qualitätsstandard gehalten, oft noch weiter übertroffen werden kann.
Wie bereits erwähnt, kann (und sollte) der Product Owner die Priorisierung festlegen. Dennoch obliegt es dem Team zu entscheiden, was im folgenden Sprint umgesetzt wird. Gemeinsam formuliert das Team ein Ziel des Sprints, einen Forecast (wahrscheinliches Sprintende).
Im zweiten Teil des Sprints wird vom Team das Wie besprochen. Dies alles fließt nun in den Sprint-Backlog ein.
Das Scrum Manifest macht zur Umsetzung des Backlogs keine Festlegungen, was sowohl ein einfaches unterteiltes Whiteboard sein kann, sowie ein professionelles Computerprogramm.
Author: Wikimedia Commons contributors, Publisher: Wikimedia Commons, the free media repository, Permanent URL: https://commons.wikimedia.org/w/index.php?title=File:ScrumBoard_(png).png&oldid=219089599
In meinem letzten Unternehmen im Fintech Bereich hatten wir ein großes Board, unterteilt in: ToDo, In Progress, To Verify und Done. Anhand der Begriffe lässt sich die deutsche Bedeutung ableiten. Sinn dieser sehr offenen Art und Weise ist es, Transparenz zu leben. Jeder kann einsehen, wie weit das Team gekommen ist und ob und wo es hakt. Hier kann dann frühzeitig dagegen angegangen werden.
Der Daily Scrum ist ein tägliches, etwa 15 Minütiges Treffen des Teams, in dem besprochen Wird, wie der aktuelle Status ist. Falls dabei festgestellt wird, dass eine Aufgabe länger als geschätzt dauert, wird sie aufgeteilt. Größere Probleme, die die Meetingzeit überschreiten, werden dem Scrum Master übermittelt.
Ist der Sprint beendet, beginnt der Sprint Review. Hier findet die Präsentation bei Kunden statt. Eingehendes Feedback wird vom Product Owner aufgenommen und für die weitere Gestaltung des Product Backlogs (möglicherweise auch zur Priorisierung) verwendet. Der Sprint Review dauert ca. 1 Stunde pro Sprint. Durch ständige Iterationen wird sowohl das eigentliche „Fertigwerden“, als auch die Produktqualität zur Routine.
Mit der wichtigste Punkt für das Team ist die Retrospektive. Hier wird ehrlich die Arbeitsweise überprüft, und Möglichkeiten gefunden, sich besser, effizienter und effektiver zu organisieren. Um die Offenheit zu fördern, findet dieses Meeting nur mit dem Team und dem Scrum Master statt. Insgesamt ist die Retrospektive aber ein Teil, der dem Team beim wachsen hilft. Jedes Individuum lernt für sich, und auch die Gruppe lernt besser zusammenzuarbeiten.
Der letzte Punkt des Sprints ist zugleich der Beginn des neuen: Product Backlog Refinement. Hier werden Einträge geordnet, Einträge gelöscht, neue Einträge hinzugefügt, Einträge werden Detailiert oder zusammengefasst, Userstories werden geschätzt und Releases werden geplant.
Somit wurde ein kompletter Schaffenszyklus eingeführt, verbessert, abgenommen und abgeschlossen.
Auf manche Punkte wie zB das „Planning Poker“ zur Aufwandschätzung und ein paar andere bin ich an dieser Stelle nicht weiter eingegangen, das dieser Post nur einen Einstieg in die Welt von Scrum geben sollte.
Quellen:
* [WP] Seite „Scrum“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 30. Juni 2018, 09:54 UTC. URL: https://de.wikipedia.org/w/index.php?title=Scrum&oldid=178749076 (Abgerufen: 5. Juli 2018, 19:02 UTC)
* [MASD] Manifesto for Agile Software Development, URL: http://agilemanifesto.org/ (Abgerufen: 5. Juli 2018, 19:03 UTC)
* [Coh04] M. Cohn, User Stories Applied, Addison-Wesley, 2004
* [OS] A. Krallmann, Modellbasiertes Requirements Engineering, Objekt Spektrum 04/2018, S. 51
