Scrum in der Praxis

Unser Büro, Zimmer 2.21, ist zurzeit für die allgemeine Webentwicklung der Softwareforen Leipzig verantwortlich. Für die agile Software-Entwicklung nutzen wir Scrum in einer für uns angepassten Form. Sicherlich kennen viele von euch diese Methode und der ein oder andere hat sie auch schon mal in der Praxis angewendet. Ich persönlich arbeite gern in einem agilen Team. Aus diesem Grund möchte ich euch die Arbeit in unserem Team mit unserem neuen Scrum-Board vorstellen.

Scrum-Board

Seit ungefähr einem Monat haben wir wieder ein Scrum-Board an der Wand. Dies ist eine visuelle Unterstützung zu den ausführlicher beschriebenen Tickets in Jira. Man kann sofort erkennen, wer gerade an welchem Thema arbeitet und was noch zu erledigen ist. Im folgenden Bild könnt ihr unser aktuelles Board sehen.

 

Die unterschiedlichen Ticketarten sind farblich gekennzeichnet. Dabei sind die User Stories blau, Tasks grün und Bugs rot. Sie wandern am Board von links nach rechts und durchlaufen dabei den gesamten Lebenszyklus, angefangen bei „Backlog“, über „Offen“, „In Progress“, „QA“ bis zu „Done“.

Interessant zu wissen ist, dass ein Software Entwickler die Tickets in umgekehrter Reihenfolge, von rechts nach links, abarbeitet. Wenn es nicht zugeordnete Tickets gibt, sind zuerst welche aus der Spalte QA zu wählen, bevor neue, offene Tickets angefangen werden dürfen. Das hat den Effekt, dass die neuen Funktionalitäten dem Kunden schneller bereitgestellt werden können und nicht halbfertig in der QA liegen.

Lebenszyklus eines Tickets

Im Backlog landet zunächst alles, was vom Projektleiter priorisiert und freigegeben wurde. Wir als Team entscheiden dann je nach Priorität, welchen Themenkomplex wir bearbeiten möchten und verschieben die dazugehörigen Tickets in die Spalte Offen. Diese Tickets können jederzeit bearbeitet werden, wodurch sie einer Peron zugeordnet werden und in die Spalte In Progress (in Bearbeitung) wandern. Für die Zuordnung besitzt jedes Team-Mitglied seine eigenen, bedruckten Magneten. In der Spalte In Progress gibt es den Bereich Blockiert. Tickets in diesem Abschnitt können zum aktuellen Zeitpunkt nicht weiter bearbeitet werden. Aber spätestens beim nächsten Daily Scrum wird nach einer Lösung der Blockade gesucht.

Wenn ein Entwickler mit der Bearbeitung seines Tickets fertig ist, verschiebt er es in QA (Quality Assurance – Qualitätssicherung). Wir arbeiten in unserem Team nach dem 4-Augen Prinzip. Das bedeutet, dass der geschriebene Quellcode und alle weiteren Änderungen von mindestens 2 Personen angeschaut werden. Hier gibt es auch die Möglichkeit, dass neue Funktionalitäten durch eine externe QA von Personen außerhalb des Teams, z.B. dem Auftraggeber, begutachtet werden. Nach erfolgreicher QA kann das Ticket in die Spalte Done (Fertig) verschoben werden. Ansonsten geht es zurück zu Offen und wird weiter bearbeitet.

Wenn es ein Ticket bis ganz nach rechts in die Spalte Done geschafft hat, ist der Projektleiter am Ende jedes Sprints für die endgültige Abnahme verantwortlich. Danach verschwindet das Ticket vom Board. Wie man sieht waren wir seit der Einführung des Scrum-Boards sehr fleißig bei der Abarbeitung der Aufgaben. Die Spalte Done ist schon übervoll, sodass wir die Tickets zum Teil übereinander stapeln müssen. Da wird wohl bald wieder ein Review fällig, um die Spalte zu leeren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.