In agilen Projekten wird bei queoflow nach dem Scrum-Ansatz entwickelt. Dabei fallen im Projektalltag viele Fachbegriffe, diese werde ich in diesem Artikel etwas näher erläutern.

Das Vorgehensmodell Scrum wurde durch Ken Schwaber und Jeff Sutherland auf der OOPSLA im Jahr 1995 im Rahmen eines Whitepapers vorgestellt, um den Prozess in Softwareentwicklungsprojekten effizienter zu gestalten. In ihrem Buch „Agile Software Development with Scrum“ beschreiben Mike Beedle und Ken Schwaber Scrum als Management-Framework zur Verbesserung von Flexibilität und Risikovermeidung in Softwareentwicklungsprojekten.

Scrum zerlegt dabei nicht den Entwicklungsprozess, sondern das gesamte Produkt in Einzelschritte. Diese Schritte werden Sprints genannt und sollten nicht länger als vier Wochen andauern. Die Zielstellung eines Sprints ist es, nach Beendigung in der Lage zu sein, eine potenziell auslieferungsfähige Anwendung (Product Increment) bereitzustellen. Diese Anwendung wird dann durch den Kunden und das Team geprüft und die Erfahrungen aus der Überprüfung in den nächsten Sprint eingearbeitet.
Dabei definiert Scrum genau drei Rollen für die am Prozess beteiligten Personen. Der Product Owner stellt fachliche Anforderungen und priorisiert diese. Dabei trifft er die entsprechenden Entscheidungen zeitnah und arbeitet sehr eng mit dem Team zusammen. In seiner Verantwortung liegt die kontinuierliche Pflege des Product Backlogs sowie des Releaseplans. Das Team setzt die Anforderungen des Product Owner um. Es besteht daher idealerweise aus allen Personen, die für die Lieferung des Product Increment erforderlich sind. Dabei verantworten sie die Umsetzung der einzelnen Arbeitspakte des Sprints selbst.

Das Team steuert eigenständig die Arbeitsmenge die innerhalb eines Sprints umgesetzt wird. Dafür trägt es dann aber auch die Verantwortung für deren Qualität und die Lieferung des Sprints. Der Scrum Master ist dafür verantwortlich, dass der Prozess entsprechend Scrum eingehalten wird. Er beseitigt Hindernisse die das Team oder den Product Owner bei der Einhaltung behindern und schult alle Beteiligten auf das Verständnis ihrer Rolle.

Der Product Owner  hat eine grobe Vorstellung/Vision von dem Ziel, das er erreichen möchte (der große Würfel aus Abbildung 1). Da dieser Würfel unter Umständen sehr groß ist, wird er durch laufende Pflege in eine Reihe von Funktionen aufgeteilt, die in einer priorisierten Liste – dem sogenannten Product Backlog – gesammelt werden.

Anschließend beginnt über eine Reihe definierter Meetings und Aktivitäten die iterative Abarbeitung und laufende Pflege des Product Backlog, wobei jeder Sprint mit dem Sprint Planning beginnt. Dabei wählt das Team aus der priorisierten Liste (Product Backlog) die Funktionen/Aufgaben aus, die es in der definierten Dauer eines Sprints (maximal 4 Wochen) schaffen kann und überführt diese in einen kleineren Würfel, das sogenannte Sprint Backlog. Bei der Planung werden die Funktionen in Aufgaben zerlegt und diese mit einer Aufwandsschätzung versehen.

Nach der abgeschlossenen Sprint-Planung beginnt das Team in der sogenannten Sprint-Ausführung (dem eigentlichen Sprint) unter Anleitung des Scrum Master mit allen Aufgaben, die erforderlich sind, um die Funktionen fertigzustellen. Dabei bedeutet Done, dass im Team eine große Zuversicht darüber besteht, dass alle Arbeiten zur Bereitstellung einer Funktion mit entsprechendem Kundennutzen abgeschlossen sind. Das Daily Scrum (Meeting) ist ein tägliches, 15-Minütiges Treffen der Teammitglieder mit dem Ziel, den Austausch über die anstehenden Aufgaben des Tages bzw. Hürden des letzten Tages anzuregen.

Das QS Meeting ist wie das Daily Scrum Bestandteils eines Sprint Day. Dabei werden schwierige Passagen bzw. Stellen, an denen es zu Problemen kommt bzw. kommen könnte, gemeinsam besprochen und durch das Team geprüft. Welche Elemente im QS Meeting besprochen werden, entscheidet das Team autark.

Im Sprint Review stellt das Team das Resultat des Sprints vor. Es werden nur funktionsfähige Komponenten vorgestellt. Das Feedback der Kunden fließt in das Product Backlog und somit in die Planung der nächsten Sprints wieder mit ein.

Durch die Sprint Retrospective wird jeder Sprint am Ende noch einmal analysiert, wobei der Fokus auf der Untersuchung der Arbeitsprozesse und der Identifikation etwaiger Hürden liegt, die dann durch den Scrum Master beseitigt werden.