JIRA. Roman Simschek
Читать онлайн книгу.
href="#fb3_img_img_d4ed681c-71e0-517c-898d-6adc97f0717e.jpg" alt="image"/>Rollen
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.
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