Читать книгу JIRA - Roman Simschek - Страница 8

1Einführung Scrum

Der Begriff Scrum lässt sich auf die beiden japanischen Wirtschaftswissenschaftler Nonaka und Takeuchi zurückführen. Sie schreiben in ihrem im Jahr 1986 erschienenen Artikel „The New Product Development Game“ über den von ihnen so genannten „Rugby-Approach“. Dieser bedient sich einer Analogie aus dem Rugby. Sie gehen davon aus, dass einer der außergewöhnlichsten Erfolgsfaktoren von sehr erfolgreichen Produktentwicklungsteams die Nähe des Teams während der Entwicklungsarbeit ist, so wie bei dem aus Rugby stammende Gedränge, welches Scrum genannt wird und bei dem viele Spieler eng zusammenstehen. Denn auch diese Teams arbeiten als kleine und selbstorganisierte Einheiten. Sie bekommen von außen nur eine grobe Richtung vorgegeben. Es bleibt in der Umsetzung jedoch ihnen überlassen, wie sie ihr gemeinsames Ziel erreichen. Und diese Art der Zusammenarbeit soll auch Projekte erfolgreich machen.

Dieser Rugby-Approach wurde dann mehr als zehn Jahre später von den Vätern von Scrum, Jeff Sutherland und Ken Schwaber, zu einem Rahmenwerk für Softwareentwicklungsprojekte weiterentwickelt: Und dieses Rahmenwerk nannten sie mit einem entsprechenden Verweis auf den Artikel von Nonaka und Takeuchi: Scrum. Letztlich ist Scrum also ein Rahmenwerk für agiles Projektmanagement. Die Kernelemente von Scrum sind:

Rollen

Events

Artefakte

Video anschauen: Einführung Scrum In diesem Video gibt der Autor Lars Rayher einen Einblick darin, was bei der Einführung vom Scrum mit Jira zu beachten ist.

www.agile-heroes.de/jirascrum

1.1Rollen

Für jede dieser Rollen ist klar beschrieben, was ihre Aufgaben sind und welche Kompetenzen und Verantwortungen sie haben. Es ist wichtig, dass jedes Mitglied des Scrum-Teams weiß, welche Rolle es hat und welche Erwartungen an diese Rolle gerichtet werden. Dies ist notwendig, um Scrum erfolgreich umzusetzen.

Development-Team

Das Development-Team ist das Herz von Scrum. Es ist für den wichtigsten Teil im Rahmen eines Scrum-Projektes zuständig: das Entwickeln des Produkts. Diese Arbeit wird selbstorganisierend und interdisziplinär durchgeführt. Letztlich geht man gemäß Scrum davon aus, dass das Development-Team hoch motiviert ist und selbstständig entscheiden kann, wie es das jeweilige Ziel erreicht. Das Development-Team kann zwar Aufgaben innerhalb des Teams mit unterschiedlichen Kompetenzen organisieren, dennoch bleibt es immer als Ganzes für die Erreichung des Ziels eines Sprints verantwortlich.

Product Owner

Der Product Owner vertritt die Interessen des Auftraggebers oder des Kunden. Er ist verantwortlich für den geschäftlichen Erfolg des Produkts. Er hat zu Beginn und während des Scrum-Prozesses die Aufgabe, in Abstimmung mit dem Stakeholder die Anforderungen des zu entwickelnden Produktes abzustimmen. Zudem hat er diese Produktmerkmale dann entsprechend auch strukturiert in Form eines Product Backlogs zu managen, dies ist sein wesentliches Werkzeug. Zudem ist der Product Owner für die Abnahme und den Release von Inkrementen zuständig und erhöht durch sein effektives Product Backlog Management den Wert des Produktes.

Scrum Master

Der Scrum Master ist die dienende Führungsperson und verantwortlich für die Implementierung der Scrum-Regeln. Wir sprechen hier gerne vom Regelhüter, Moderator und Coach. In englischer Sprache wird oft von „Servant Leader“ gesprochen. Der Scrum Master ist quasi für alles, was ein Scrum-Projekt charakteristisch macht, verantwortlich: die Scrum-Regeln. Er stellt sicher, dass alles während des Sprints nach den Regeln von Scrum abläuft. Er hat die Aufgabe, die anderen Teammitglieder im Scrum-Team dazu zu befähigen, die Regeln von Scrum für eine möglichst effiziente Projektarbeit anzuwenden. Er hat auch dafür Sorge zu tragen, allen, die nicht Teil des Scrum-Teams sind, zu vermitteln, wie die Interaktion mit dem Scrum-Team erfolgreich sein kann. Zudem unterstützt er alle dabei, diese Interaktionen so zu gestalten, dass sie einen maximalen Wert der Arbeit des Scrum-Teams sicherstellen und Hindernisse, sogenannte „Impediments“, zu beseitigen.

1.2Scrum-Prozess

Der Scrum-Prozess beginnt, wenn ein oder einige Stakeholder ein Produkt benötigen. Die Anforderungen an das Produkt werden dann in einem so genannten Product Backlog gesammelt. Das Product Backlog ist also die Zusammenfassung aller Produkteigenschaften, die das finale Produkt umfassen sollte.

Nachdem ein initiales Product Backlog entstanden ist, beginnt der Scrum Master mit dem Sprint Planning. Hier wird geplant, welche Produktfeatures im kommenden Sprint umgesetzt werden sollen. Diese Teilmenge der Produkteigenschaften wird dann in ein Sprint Backlog überführt. Das Sprint Backlog umfasst somit alle Produkteigenschaften, die im kommenden Sprint umgesetzt werden sollen. Diese werden im Sprint-Ziel zusammengefasst. Backlog-Items dürfen nur in das Sprint Backlog übergeben werden, wenn diese auf Ready sind; dazu muss ein Product Backlog Item beschrieben, priorisiert und geschätzt sein.

Abb. 1: Scrum-Prozess

Danach beginnt die Entwicklungsphase. Im Rahmen der Produktentwicklung erfolgt dann ein täglicher Austausch des Scrum-Teams im Rahmen des Daily Scrum. Nach Abschluss des Sprints sollten als Ergebnis neue Produkteigenschaften für das Produktinkrement hervorgebracht werden. Ein Produktinkrement ist hierbei ein fertiger Teil des Gesamtproduktes.

Nach dem Sprint besteht die Möglichkeit des Überprüfens und Anpassens in Form eines Sprint Reviews. So besteht einerseits die Möglichkeit für alle, die nicht selbst am Entwicklungsprozess beteiligt waren, Informationen über den aktuellen Entwicklungsstand zu erhalten, wie beispielsweise die Stakeholder. Zusätzlich ist der Product Owner im Sprint Review für die Abnahme des Inkrements verantwortlich, und Stakeholder haben die Möglichkeit Feedback zu geben, welches der Product Owner in seinem Product Backlog aufnehmen kann.

Das letzte Event im Sprint ist die Sprint-Retrospektive. Hier trifft sich das Scrum-Team und gibt Feedback zu Personen, Prozessen und Tools. Hierbei geht es nicht um das Produkt an sich, sondern um die Entwicklungsarbeit. Hierbei entstehen so genannte Improvements, also Verbesserungsmaßnahmen, wovon mindestens eines im nächsten Sprint umgesetzt werden muss.

Danach beginnt der nächste Sprint direkt mit dem Sprint Planning und der Prozess geht von vorne los. Dies soll Komplexität reduzieren und den Fokus auf die Entwicklungsarbeit steigern.

1.3Events

Events gemäß Scrum finden immer in persönlicher Form statt. Sie erfolgen regelmäßig, um kontinuierlich überprüfen und anpassen zu können. Alle Events haben ein festes Zeitfenster, in Scrum „Time Box“ genannt. Das bedeutet, dass für jedes Event ein Zeitrahmen vorgegeben ist, der auf jeden Fall eingehalten wird.

Sprint

Das Ziel des Sprints ist es, einen auslieferbaren Bestandteil des Produktes zu erstellen. Konkret sind die im Rahmen des Sprints umzusetzenden Produkteigenschaften im Sprint Backlog festgehalten. Der Sprint selbst ist kein eigenständiges Event, sondern die Klammer um mehrere Events, die innerhalb des Sprints stattfinden.

Sprint Planning

Ziel des Sprint Plannings ist, den jeweils laufenden Sprint zu planen. Der Sprint erfolgt in Form eines Präsenzmeetings, das immer als allererstes Event eines Sprints stattfindet. Das Sprint Planning findet einmal pro Sprint statt. Am Sprint Planning nimmt das gesamte Scrum-Team teil, also der Product Owner, der Scrum Master und das Entwicklungsteam. Das Sprint Planning dauert bei einem Sprint von vier Wochen maximal acht Stunden. Dauert der Sprint weniger als vier Wochen, so passt sich die Dauer des Sprint Plannings entsprechend an und ist ebenfalls kürzer.

Daily Scrum

Nachdem das Spring Planning abgeschlossen wurde, beginnt das Entwicklungsteam seine Arbeit. Konkret bedeutet dies, dass es die Aufgaben, die im Sprint Planning definiert wurden, im Team selbstorganisiert bearbeitet. Während dieser Entwicklungsarbeit trifft sich das Scrum-Team physisch einmal am Tag zum Daily Scrum. Dieses findet immer zur gleichen Zeit am gleichen Ort statt. Grund hierfür ist, dass die organisatorische Arbeit der Eventplanung und die Komplexität reduziert werden soll. Die Dauer des Daily Scrum ist auf maximal 15 Minuten beschränkt. Ziel des Daily Scrum ist, dass sich das Entwicklungsteam abstimmt und synchronisiert.

Innerhalb des Daily Scrum werden immer zuerst die Arbeit der letzten 24 Stunden transparent gemacht und ein Ausblick auf die Aufgaben der nächsten 24 Stunden gegeben. Das Entwicklungsteam verprobt hierbei den Fortschritt der letzten 24 Stunden bezüglich des Sprint-Ziels. Zudem analysiert es den Fortschritt bezogen auf die Backlog Items, die im Sprint Backlog sind. Hauptziel des Daily Scrum ist, die Wahrscheinlichkeit, dass das Entwicklungsteam das Sprint-Ziel auch erreicht, zu maximieren. Zusätzlich werden Hindernisse für das Sprint-Ziel mit dem Scrum-Team geteilt.

Sprint Review

Der Sprint Review findet immer am Ende jedes Sprints statt. Er dient dazu, die wichtigsten Ergebnisse aus dem Sprint zu präsentieren und um sie zu überprüfen und gegebenenfalls anzupassen. So kann der neueste Stand des Produktinkrements transparent gemacht werden, und das Product Backlog kann entsprechend aktualisiert werden.

Der Sprint Review findet in Form eines physischen Events statt. Der Product Owner lädt zu dem Meeting ein. Das gesamte Scrum-Team ist beim Sprint Review anwesend. Zudem sind auch die Stakeholder mit eingeladen. So erhalten sie einen Überblick über den neuesten Stand der Entwicklungsarbeit und können dem Entwicklungsteam gleichzeitig Feedback geben. Dies ermöglicht es, dass das Produkt überprüft und angepasst werden kann. Die Präsentation der Ergebnisse des Sprints dient im Wesentlichen dazu, Feedback zu ermöglichen und die Zusammenarbeit zu fördern. Der Sprint Review dauert maximal vier Stunden bei einem Sprint, der vier Wochen dauert. Wenn die Dauer des Sprints kürzer ist, sollte auch der Sprint Review entsprechend angepasst werden.

Sprint-Retrospektive