Scrum Iterative and agile
Oktober 8, 2019
Aus dem Unterricht des CAS Mobile Business und Ecosystems mit Dozent Ari Byland berichtet Daniel Keller
Improving the Profession of Software Delivery
Das Scrum Framework wird in der Softwareentwicklung für komplexe Produkte verwendet. Dabei hilft es die Probleme zu verstehen und Anpassungen zeitnah umzusetzen. Hierbei stellt es sicher, dass die Kunden bekommen was sie wollen. Ein für den Kunden zufriedenstellendes Produkt, ist auch der beste Motivator für die Mitarbeiter. Deshalb ist der Einsatz von Scrum zwar nicht die Lösung für alles, aber ein guter Ansatz um komplexe Probleme zu lösen. Alles Andere ist Verschwendung an Ressourcen und Lebenszeit.
Das Credo:
- Zusammenarbeit ist wichtiger als Prozesse und Tools.
- Produkt ist wichtiger als eine detaillierte Spezifikation.
- Zusammenarbeit mit dem Kunden ist wichtiger als Verträge.
- Flexibler auf Änderungen reagieren ist wichtiger als einem Plan zu folgen.
Warum Scrum:
- Scrum macht Probleme über die ganze Entwicklungsdauer Transparent.
- Änderungen können jederzeit in die Produktion mit einfliessen.
- das Produkt stellt von Anfang an einen Wert dar.
- das Risiko reduziert sich mit jedem Sprint.
Das Scrum Lebenselixier
- Den Mut haben das Richtige zu tun und an komplexen Problemen zu arbeiten.
- Jeder Fokussiert sich auf den Sprint und die definierten Ziele.
- Bekenntnis zu den Zielen des Teams.
- Das Team respektiert sich gegenseitig.
- Team und Stakeholder sind einander gegenüber offen bezüglich der Arbeit und den Herausforderungen.
Framework
Das Scrum Team besteht aus dem Product Owner, dem Entwicklungsteam und dem Scrum Master. Es organisiert sich selbstständig und die Teilnehmer sind funktionsübergreifend eingesetzt. Das Team liefert Produkte iterativ (sich der Lösung schrittweise nähernd) und inkrementell aus.
Roles
Der Produkt Owner ist verantwortlich für die Maximierung des Produktnutzens. Deshalb behält er den Überblick über das grosse Ganze. Er ist während dem Sprint für das Team verfügbar und bezieht den Kunden in die Arbeit mit ein. Die ganze Organisation muss seine Entscheide respektieren. Deshalb können Anpassungen an den Elementen im Product Backlog nur über ihn erfolgen. Seine Aufgaben sind:
- Definition der einzelnen Elemente im Backlog (z.B. mit dem Team).
- Priorisierung der Elemente im Backlog.
- Optimiert den Nutzen der Arbeit des Entwicklungsteams.
- Vermittelt dem Scrum Team klar und deutlich den Nutzen der Backlog-Items und die nächsten Arbeitsschritte.
- Stellt sicher, dass alle die Elemente im Backlog verstehen.
Das Developement Team besteht aus Spezialisten, welche die Arbeit am geplanten Lieferobjekt durchführen bis es funktionsfähig ist. Dafür organisieren und koordinieren sie ihre Arbeit innerhalb des Teams selbstständig. Deshalb kommen Ihnen folgende Aufgaben zu:
- Sie organisieren sich selber im Entwicklungsteam.
- Sie setzen ihre Fähigkeiten funktionsübergreifend ein.
- Mitglieder haben keine Rollen innerhalb des Teams.
- Es gibt keine Hierarchie innerhalb des Teams.
- Sie verfügen über unterschiedliche Fähigkeiten und sind gemeinsam für das Ganze verantwortlich.
Der Scrum Master ist verantwortlich für die Vermittlung und Einhaltung der Regeln gemäss Scrum. Des weiteren vertritt er das Scrum Team gegen Aussen und koordiniert die Interaktionen. Deshalb gehört folgendes zu seinen Aufgaben:
- das Coaching des Entwicklungsteams und des Product Owners.
- das beseitigen von Hindernissen.
- Scrum in der Organisation initiieren und vertreten.
Artifacts
Das Product Backlog ist die geordnete Liste von allem (Features, Funktionen, Anforderungen, Verbesserungen und Korrekturen) was für das Produkt umgesetzt werden muss. Zudem ist es die einzige Quelle von Anforderungen für das Produkt. Deshalb ist jede Anpassungen im Product Backlog erfasst. Dadurch ist sie nie komplett und wird während dem gesamten Projekt ständig aktualisiert. Der Produkt Owner ist verantwortlich für diese Liste.
Das Sprint Backlog ist eine Auswahl von Anforderungen aus dem Product Backlog. Diese sind für den Sprint in einzelne Arbeitsschritte aufgeteilt. Zudem werden während dem ganzen Sprint Arbeitsschritte ergänzt oder entfernt. Nur das Entwicklungsteam verändert das Sprint Backlog während dem Sprint.
Das Increment ist die Lieferung am Ende des Sprints, welche aus der Summe des Aktuellen und aller vergangener Sprints besteht. Es ist ein verwendbares Produkt und kann falls nötig als Release gebraucht werden.
Events
Der Sprint ist das Herzstück von Scrum. Er dauert einen vordefinierten Zeitraum von einem Monat oder weniger und dient der Abarbeitung der Elemente vom Sprint Backlog. Ein Funktions- und wenn möglich Release-fähiges Increment ist das Resultat eines jeden Sprints. Der Sprint startet sofort nach dem Ende des Vorhergehenden. Es gilt:
- Es gibt keine Anpassungen welche das Ziel gefährden.
- Die Qualität wird nicht reduziert.
- Der Lieferumfang wird ständig präzisiert (gemäss aktuellem Wissensstand)
- Er kann nur durch den Product Owner abgebrochen werden.
Beim Sprint Planning wird der nächste Sprint geplant. Dafür sind bei einem 1-monatigen Sprint 8 Stunden und die folgenden Themen vorgesehen:
- Was kann im nächsten Lieferobjekt geliefert werden.
- Was wird benötigt um das Ziel im Sprint zu erreichen.
Der Daily Scrum ist ein tägliches internes Meeting für das Entwicklungsteam. Bei diesem Treffen werden die vergangenen 24 Stunden besprochen und nächsten 24 Stunden geplant. Dafür sind 15 Minuten und die folgenden Themen vorgesehen:
- Was wurde in den letzten 24h für die Zielerreichung getan.
- Was ist in den nächsten 24h zu tun.
- Gibt es Hindernisse welche die Erreichung des Ziels gefährden.
Die Sprint Review ist ein Meeting im Anschluss an den Sprint und es nehmen das Scrum Team und alle Stakeholder daran teil. In diesem Treffen wird der Sprint analysiert und es können Anpassungen im Product Backlog durchgeführt werden. Dafür werden bei einem 4-wöchigen Sprint 4 Stunden eingeplant und das Treffen hat folgenden Inhalt:
- Was ist erledigt und was noch nicht.
- Was lief gut, was schlecht.
- Demonstration der Arbeit.
- Diskussion über Anpassungen zum Produkt Backlog (neue Erkenntnisse oder Marktsituationen).
Das Sprint Retrospective ist eine Gelegenheit für das Scrum Team sich selber zu analysieren und Verbesserungen für den nächsten Sprint einfliessen zu lassen. Die Diskussion soll positiv und produktiv verlaufen, wofür der Scrum Master verantwortlich ist. Dafür werden bei einem 4-wöchigen Sprint 3 Stunden eingeplant und die Diskussion hat folgenden Inhalt:
- Wie verlief der letzte Sprint bezogen auf Personen, Beziehungen, Prozesse und Tools.
- Was wurde gut erledigt und was kann verbessert werden.
- Einen Plan erstellen wie Verbesserungen umgesetzt werden können.
Prüfung zum Scrum Master
Nach Absolvierung des PSF Kurses (Grundlagen) ist es möglich die Prüfung zum Scrum Master abzulegen. In den ersten zwei Wochen nach Erhalt des Links kann ein Probelauf durchgeführt werden. Nach Ablauf dieser zwei Wochen, ist dies nicht mehr möglich. Folgende Inhalte eigenen sich als Vorbereitung für die Prüfung: