Projektleitung in SCRUM

Wie funktioniert das?

In der Praxis bedeutet dies, dass der gesamte Prozess ständig optimiert und an die Bedürfnisse der Kunden angepasst wird. Team und die Produkt während der gesamten Dauer der Arbeiten an der Projekt. Verantwortung für die Verwaltung Produktentwicklung ist zwischen dem Product Owner (PO) und dem Designteam aufgeteilt. Der PO ist die Person, die für Entscheidungen bezüglich der Richtung der Produktentwicklung verantwortlich ist und eine ganzheitliche "Vision" davon hat, was das Produkt werden soll. Das Aufgabenmanagement basiert auf dem Kanban-Board (in Verbindung mit dem Sprint SCRUM-Board genannt). Jeder Teilnehmer des Prozesses kann dem Backlog Aufgaben hinzufügen, aber der OP ist für die Festlegung der Prioritäten verantwortlich. Das Projektteam ist für die "Umwandlung" der Ideen des PO in konkrete Aufgaben und die Planung ihrer Umsetzung verantwortlich.

Verlauf des Zyklus

Der Prozess ist in Iterationen (Sprints) unterteilt. Im Rahmen eines Sprints, der etwa 2 Wochen dauert, implementiert und testet das Projektteam den zuvor geplanten Teil der Funktionalität.

Der Sprint beginnt mit der "Planung", bei der das Team die Aufgaben bespricht und vorbereitet, die zuvor vom PO an die Spitze des Backlogs gesetzt worden sind. Danach wird der Schwierigkeitsgrad dieser Aufgaben geschätzt und sie werden entsprechend der Schwierigkeit mit Punkten bewertet. Bei relativ konstanter Teamzusammensetzung und konstanten Arbeitsbedingungen ist die Anzahl der in jedem Sprint erreichten Punkte wiederholbar und ermöglicht die Planung der künftigen Arbeit. Am Ende der Planungssitzung werden Aufgaben mit einer Gesamtpunktzahl ausgewählt, die innerhalb eines Sprints zu erledigen sind, und ein neuer Sprint beginnt.

In der Mitte des Sprints findet das Grooming statt. Dabei handelt es sich um ein Treffen, bei dem der Projektleiter dem Team weitere Erwartungen und Ideen vorstellt, während das Projektteam diese analysiert, in kleinere Aufgaben unterteilt und dem Projektleiter mögliche Vorschläge unterbreitet. Bei der Planung zukünftiger Aufgaben berät sich der OP mit Analysten, Benutzern, UX- und Grafikdesignern. Zusätzliche Analysen (Markt Forschung und Datenwissenschaft) werden in dieser Phase häufig benötigt. Erst nach der Analyse und Formulierung der sogenannten User Story wird der PO diese Stories in einem Backlog veröffentlichen. Die User Story sollte Informationen darüber enthalten, was der PO von einer bestimmten Aufgabe oder einer Gruppe von Aufgaben erwartet und welche Kriterien verwendet werden sollen, um zu erkennen, ob die Aufgabe abgeschlossen ist.

Während des Sprints werden täglich so genannte "Daily Standup Meetings" abgehalten. Bei diesen Treffen erzählt jeder Entwickler dem Rest des Teams, was er am letzten Tag gemacht hat und informiert eventuell über Probleme oder Blockaden, die seine weitere Arbeit behindern. Dank dieses Austauschs über den aktuellen Stand der Dinge lassen sich potenzielle Konflikte zwischen verschiedenen Aufgaben viel schneller erkennen und die Situation vermeiden, dass der Entwickler an einem Problem hängen bleibt und nicht weiterkommt. Das tägliche Standup soll so kurz wie möglich sein, aber gleichzeitig seine Funktion erfüllen. Die Standardformel des Meetings ermutigt das Team, es kurz zu halten.

Während des Sprints werden die Aufgaben auf dem SCRUM-Board entsprechend ihrem aktuellen Status verschoben. Die Auswahl der Spalten entspricht in der Regel dem Arbeitssystem des Unternehmens oder des Teams und ist mit dem Versionskontrollsystem und der Häufigkeit der Veröffentlichungen verbunden. Bei uns sieht das folgendermaßen aus:

• To do - Aufgaben, die noch erledigt werden müssen
• In Arbeit - Aufgaben in Arbeit
• Code Überprüfung - Aufgaben, die darauf warten, von einem anderen Entwickler überprüft zu werden
• Vorbereitet - Aufgaben von Entwicklern geprüft und akzeptiert
• Bereitgestellt - Aufgaben, die sich in einer Bereitstellungsinstanz befinden und auf die Genehmigung der Bestellung warten
• Angenommen - von der PO angenommene Aufgaben
• Erledigt - fertige Aufgaben, die sich auf der Produktionsinstanz befinden

Nach dem Sprint findet eine Retrospektive statt. Dabei handelt es sich um ein Treffen, das der Optimierung der Arbeit gewidmet ist. Das gesamte Team bespricht, was im letzten Sprint gut gelaufen ist und was verbessert werden muss. Wir beziehen uns auch oft auf die vorherige Retrospektive und überprüfen, ob wir alle Ideen zur Verbesserung der Arbeit umsetzen konnten. Die Probleme, die in der Retrospektive besprochen werden, können alles Mögliche sein, von Entwicklungswerkzeugen über Druck und Aufgabenschwierigkeiten bis hin zu Kommunikationsproblemen (sowohl zwischen den Entwicklern und dem Team als auch dem PO).

Verantwortlichkeiten des SCRUM-Masters

Die Person, die für die ordnungsgemäße Durchführung des SCRUM-Prozesses verantwortlich ist, ist der SCRUM-Master. Dies ist oft die unverständlichste Rolle im Team. Der SCRUM-Master hat keine Entscheidungsbefugnis. Entscheidungen werden gemeinsam vom Team und dem PO getroffen, während die Rolle des SCRUM-Masters darin besteht, Hindernisse für den ordnungsgemäßen Ablauf des Prozesses zu beseitigen.

Zu den Aufgaben des SCRUM-Masters gehören folgende:

• Durchführung von SCRUM-Meetings, einschließlich Planung, Grooming, tägliches Standup-Meeting und Retrospektive
• Sicherstellung, dass die Aufgaben auf dem SCRUM-Board regelmäßig vom Team gepflegt und vom PO nach Prioritäten geordnet werden
• Er fungiert als Bindeglied zwischen dem Team und dem PO; daher ist es oft der SCRUM-Master, der die schwierige Aufgabe hat, die Sprache der Programmierer in die Geschäftssprache zu übersetzen, und umgekehrt. Das liegt daran, dass in unserem Unternehmen der SCRUM-Master ein Entwickler ist, also eine technische Person. Der allgemeine Rahmen für die Arbeit des SCRUM-Masters erfordert dies nicht.
• Verhinderung, dass das Team vom Thema abweicht, und Überwachung der Tagesordnung bei Sitzungen
• Sorge für die Atmosphäre im Team - vor allem bei Besprechungen.
• Lösung von Konflikten, wenn sie auftreten.

Lesen Sie auch:

• Codests bewährte Verfahren für die Entwicklung von Software. Unser Ansatz für die Customer Journey
• Codest's gute Praxis für die Erstellung von Software: GitFlow
• Bewährte Praktiken von Codest für die Erstellung von Software. Wie setzen wir die Anforderungsanalyse um?