Scrum
Scrum ist ein Framework für Projektmanagement, das Teamarbeit, Verantwortungsverteilung und iterativen Fortschritt in Richtung eines klar definierten Ziels regelt.
Scrum basiert auf einer einfachen Prämisse: Man beginnt mit dem, was man sehen und wissen kann. Dann verfolgt man aufmerksam den Fortschritt eines Projekts und passt es laufend auf Grundlage der Beobachtungen an. Die drei Säulen von Scrum sind Transparenz, Kontrolle und Anpassung.
Der Namen des Frameworks, das oft Teil der agilen Softwareentwicklung ist, bezieht sich auf eine Rugby-Formation, bei der jeder Spieler eine fest zugewiesene Rolle übernimmt. Wenn es um die Produktentwicklung geht, gehören zu den Scrum-Rollen der Product Owner, der Scrum-Master und das Scrum-Entwicklungsteam.
Product Owner: Dieses Teammitglied dient als Verbindung zwischen dem Entwicklungsteam und den Kunden. Der Product Owner ist dafür verantwortlich, dass die Erwartungen an das fertige Produkt mitgeteilt und vereinbart werden.
Scrum-Master: Dieses Teammitglied dient als Moderator. Der Scrum-Master ist dafür verantwortlich, Scrum-Best-Practices durchzusetzen und das Projekt voranzubringen
Scrum-Entwicklungsteam: Das Team entwickelt und testet inkrementelle Versionen des Endprodukts
Der Scrum-Prozess
Der Scrum-Prozess ermutigt die Praktiker, mit dem zu arbeiten, was sie haben, und kontinuierlich zu evaluieren, was funktioniert und was nicht funktioniert. Die Kommunikation, die ein wichtiger Teil des Prozesses ist, erfolgt durch Treffen, die als Events bezeichnet werden. Zu den Scrum-Events gehören:
Daily Scrum. Das Daily Scrum ist ein kurzes Stand-up-Meeting, das jeden Tag am gleichen Ort und zur gleichen Zeit stattfindet. Bei jedem Meeting überprüft das Team die Arbeit, die am Vortag abgeschlossen wurde, und plant, welche Arbeiten in den nächsten 24 Stunden durchgeführt werden. Dies ist die Zeit, in der die Teammitglieder über alle Probleme sprechen, die den Projektabschluss verhindern könnten.
Sprintplanungstreffen. Ein Sprint ist bei Scrum ein Zeitrahmen, in dem die Arbeit abgeschlossen werden muss. Häufig werden 30 Tage festgelegt. Jeder beteiligt sich am Festlegen von Zielen und am Ende sollte mindestens ein Inkrement – ein brauchbares Softwareelement – produziert werden.
Sprint Retrospective. Eine Sprint-Retrospektive ist ein Meeting, das nach dem Ende eines Sprints abgehalten wird. Während dieses Meetings reflektieren alle über den Sprint-Prozess. Es kann auch eine Teambildungsübung angeboten werden. Ein wichtiges Ziel einer Sprint-Retrospektive ist die kontinuierliche Verbesserung des Prozesses.
Scrum-Artefakte
Ein Artefakt ist im allgemeinen Sprachgebrauch ein Objekt von historischem Interesse. In der Scrum-Produktentwicklung sind Artefakte Aufzeichnungen, anhand derer Entwickler erkennen können, was sie bereits erledigt haben und was sich noch in der Warteschlange befindet. Scrum-Artefakte, zu denen Produkt-Backlog, Sprint-Backlog, Produktinkrement und Burn-Down gehören, sollten in Sprintplanungs-Meetings konsultiert werden.
Produkt-Backlog. Dies bezieht sich auf die Punkte auf der To-Do-Liste. Während einer Sitzung zur Pflege des Produkt-Backlogs arbeitet das Entwicklungsteam mit dem Geschäftsinhaber zusammen, um die Aufgaben im Backlog zu priorisieren. Der Backlog kann während eines Prozesses, der als Backlog-Verfeinerung bezeichnet wird, genauer ausgearbeitet werden.
Sprint-Backlog. Hierbei handelt es sich um eine Liste von Aufgaben, die erledigt werden müssen, bevor ausgewählte Produkte im Backlog ausgeliefert werden können. Diese sind in zeitbasierte User Stories unterteilt.
Produktinkrement. Produktinkremente sind alle im Scrum-Prozess erstellten Produkte - alle Product Backlog Items – sowie das, was während aller vorherigen Sprints erstellt wurde. Produktinkremente spiegeln wieder, wie viel Fortschritt erzielt wurde.
Burn-Down. Der Burn-Down ist eine visuelle Darstellung der noch zu erledigenden Arbeit. Ein Burn-Down-Diagramm hat eine Y-Achse (Arbeit) und eine X-Achse (Zeit). Im Idealfall veranschaulicht das Diagramm einen Abwärtstrend, da die im Laufe der Zeit noch zu erledigende Menge an Arbeit bis auf Null abnimmt.
Die Geschichte von Scrum
Die Grundlage für das Scrum-Framework für Softwareentwicklung wurde erstmals 1986 von Hirotaka Takeuchi und Ikujiro Nonaka in einem Artikel der Harvard Business Review vorgestellt. In dem Artikel, der den Titel The New New Product Development Game trug, verwendeten die Autoren Metaphern, um zwei verschiedene Ansätze zur Verwaltung der Produktentwicklung zu beschreiben. Einige Teams waren wie Läufer in einem Staffellauf, die den Staffelstab weiterreichen und in einer geraden Linie arbeiten. Andere Teams waren Rugbyspieler, die zeitgleich dasselbe Spiel spielten und die Dinge je nach Bedarf hin- und hergaben.
Takeuchi und Nonaka kamen zu dem Schluss, dass der Ansatz des Staffellaufs, wie er durch das NASA-Phasenprogrammplanungssystem vertreten ist, veraltet sei. Sie glaubten, dass der Rugbystil den Unternehmen die notwendigen Instrumente an die Hand geben würde, um in einer multinationalen Geschäftswelt konkurrenzfähig zu sein.
Jeff Sutherland, John Scumniotales und Jeff McKenna verwendeten 1993 die Scrum-Softwareentwicklung bei der Easel Corp. Im Jahr 1995 präsentierten Ken Schwaber und Sutherland gemeinsam mit weiteren Vertretern – darunter McKenna und Scumniotales – bei OOPSLA ein einflussreiches Weißbuch mit dem Titel SCRUM Development Process. Das Ergebnis war ein grundlegender Wandel, der die Entwickler dazu brachte, die Effektivität des klassischen Wasserfall-Softwareentwicklungsmodells in Frage zu stellen.
Laut Scrum.org verwenden heute über 70 Prozent aller agilen Teams Scrum oder einen Scrum-Hybrid
Die drei Säulen von Scrum – Transparenz, Kontrolle und Anpassung – werden von fünf Werten getragen: Engagement, Mut, Konzentration, Offenheit und Respekt.
Engagement: Das Team ist selbstgesteuert, und alle Mitglieder widmen sich engagiert der Durchführung vereinbarter Arbeiten.
Mut: Das Team arbeitet als eine Einheit nimmt gemeinsam Erfolg oder Misserfolg in Kauf.
Konzentration: Das Team beschränkt Ablenkungen und konzentriert sich auf die Arbeit, die am jeweiligen Tag zu erledigen ist.
Offenheit: Dem Team wird Zeit gegeben, sich zu sammeln und auszutauschen, um zu entscheiden, was gelungen ist und was verbessert werden muss.
Respekt: Die Atmosphäre im Team ist von wechselseitigem Respekt geprägt. Die Teammitglieder erkennen ihre jeweiligen Schwächen und Stärken untereinander an. Einzelnen Teammitgliedern wird nicht die Schuld gegeben, wenn es um Fehlschläge und Verbesserungen geht.
