Scrum ist eine Projektmethode oder auch Vorgehensmodell genannt zur agilen Softwareentwicklung. Agile Softwareentwicklung bedeutet, dass die Software flexibel ist, dass die Funktionstüchtigkeit sowie die Zusammenarbeit mit dem Kunden im Vordergrund stehen, Dokumentationen und Befolgung des ursprünglichen Plans aber zugunsten funktionierender Software eher in den Hintergrund rücken. Aus diesem Grund besteht Scrum nur aus wenigen Regeln. Diese definieren die Begriffe Aktivitäten, Artefakte und Rollen, später mehr dazu.
Der Ansatz von Scrum beruht darauf, dass viele Entwicklungsprojekte viel zu komplex sind, um schon im Voraus in einem vollumfänglichen Plan definiert zu werden. Ein wesentlicher Teil der Anforderungen und der Lösungsansätze ist zu Beginn meist unklar. Solche Unklarheiten lassen sich beseitigen, indem Zwischenergebnisse erzeugt werden. Anhand dieser lassen sich die fehlenden Anforderungen einfacher und effizienter finden und umsetzen.
Ein langfristiger Plan existiert dennoch und nennt sich Product Backlog. Dieser wird permanent verfeinert und verbessert. Der Detailplan wird Sprint Backlog genannt. Für jeden Zyklus (Sprint) wird ein neuer erstellt, damit die Projektplanung auf das Wesentliche konzentriert wird.
Scrum ist eine empirische Methode, das heisst es sind folgende drei Grundsätze zu beachten: Transparenz, Überprüfung und Anpassung. Transparenz bedeutet, dass alle Fortschritte und Hindernisse regelmässig für alle sichtbar gemacht werden. Die Überprüfung definiert, dass in regelmässigen Abständen Produktfunktionalitäten geliefert und das Produkt wie auch das Vorgehen beurteilt werden. Die Anpassung hält offen, dass Anforderungen an das Produkt, Pläne und Vorgehen nicht ein für alle Mal festgelegt, sondern kontinuierlich detailliert und angepasst werden können. Durch ein solches Vorgehen wird die Komplexität der Aufgabe natürlich nicht reduziert, aber sie wird in kleinere und weniger komplexe Bestandteile zerlegt, in die Inkremente.
Das Hauptziel von Scrum besteht darin, eine schnelle und kostengünstige Entwicklung von hochwertigen Produkten zu ermöglichen. Dabei werden keine Lasten- oder Pflichtenhefter geführt. Anforderungen werden stattdessen in Form von Eigenschaften aus Anwendersicht formuliert. Die Liste der Anforderungen ergibt das Product Backlog. Diese Anforderungen werden Stück für Stück in zwei bis vier Wochen langen Intervallen (Sprints) umgesetzt.
Scrum ist für Teams einer geringen Grösse bis etwa maximal zehn Personen geeignet. Grössere Entwicklungsprojekte benötigen ein weitergehendes Vorgehen, das die Koordination mehrerer Teams organisieren kann.
Rollen
In Scrum sind drei verschiedene Rollen definiert: Der Product Owner, das Entwicklungsteam und der Scrum Master. Alle Beteiligten dieser Rollen ergeben zusammen das Scrum Team. Neben diesen Rollen, die für die Software zuständig sind, gibt es noch die Stakeholder. Diese sind Beteiligte wie z.B. der Auftraggeber und können den Fortschritt und die Zwischenergebnisse einsehen, da diese transparent sind. Stakeholder dürfen bei den meisten Aktivitäten zuhören.
Der Product Owner ist verantwortlich für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts. Er legt fest, welche Eigenschaften das Produkt am Ende eines Sprints haben muss. Er allein entscheidet über das Produkt, seine Eigenschaften und die Reihenfolge der Implementierung und muss somit die Balance zwischen Eigenschaften, Kosten und Auslieferungszeitpunkt im Blick behalten.
Der Product Owner hält regelmässig Rücksprache mit den Stakeholdern, um auf deren Wünsche eingehen zu können.
Das Entwicklungsteam ist für die Lieferung der Produktfunktionalitäten (Eigenschaften) in der vom Product Owner gewünschten Reihenfolge zuständig. Es muss die vereinbarten Qualitätsstandards einhalten, ist aber frei in der Umsetzung der gewünschten Funktionalitäten. Das Entwicklungsteam sollte in der Lage sein, die Ziele der jeweiligen Sprints möglichst ohne äussere Abhängigkeiten zu erreichen. Deshalb ist es von grossem Vorteil, wenn das Team interdisziplinär besetzt ist. Das Entwicklungsteam besteht aus drei bis neun Mitglieder. Es muss gross genug sein, um alle benötigten Kompetenzen zu vereinigen. Je grösser das Team, desto grösser der Koordinierungsaufwand.
Der Scrum Master ist dafür verantwortlich, dass das Vorgehensmodell Scrum gelingt. Er führt die Regeln von Scrum ein und überprüft deren Einhaltung. Er gehört zwar meist nicht dem Entwicklungsteam an, arbeitet aber mit diesem zusammen. Er leitet die Treffen und muss sich um die Behebung von Störungen und Hindernissen kümmern. Hindernisse können von mangelnder Infrastruktur über schlechte Kommunikation und Zusammenarbeit bis hin zu persönlichen Konflikten im Entwicklungsteam reichen. Der Scrum Master ist eine dienende Führungskraft, der keine Arbeitsanweisungen an einzelne Teammitglieder vergibt, sondern für den Prozess und die Beseitigung von Hindernissen verantwortlich ist.
Folgende Personen sind als Stakeholder definiert:
- Kunde/Auftraggeber
- Anwender
- Management
Artefakte
In Scrum existieren drei verschiedene Artefakte:Product Backlog:
Das Product Backlog ist eine Auflistung der Anforderungen an das Produkt. Es ist dynamisch und wird permanent weiterentwickelt. Verantwortlich für das Product Backlog ist der Product Owner. Er muss das Product Backlog pflegen und sich die Priorisierung der Eigenschaften vornehmen.
Das Product Backlog ist nicht vollständig, da zu Beginn eines Projekts meist nicht alle Anforderungen bekannt sind. Die Priorisierung erfolgt unter Gesichtspunkten wie wirtschaftlicher Nutzen, Risiko und Notwendigkeit.
Anforderungen im Product Backlog werden fachlich und anwenderorientiert definiert. Die Formulierung der Produkteigenschaften wird meist in User Stories umgesetzt und diese werden dann Product Backlog Item (PBI) genannt.
Sprint Backlog:
Im Sprint Backlog sind die zu erledigenden Aufgaben eines Sprints aufgeführt. Es umfasst einige der PBI's aus dem Product Backlog und unterteilt diese in Tasks.
Um es für alle Teammitglieder sichtbar zu machen, wird meist ein Taskboard genutzt.
Product Increment
Das Produktinkrement ist das Ergebnis aller PBI's, die während des aktuellen und allen vorangegangenen Sprints fertiggestellt wurden. Am Ende jedes Sprints muss sich das neue Produktinkrement in einem nutzbaren Zustand befinden.
Sprint
Der Sprint ist ein Arbeitsabschnitt, bei dem ein Inkrement einer Produktanforderung implementiert wird. Die Dauer eines Sprints umfasst ein bis vier Wochen. Alle Sprints haben idealerweise die gleiche Länge, um so dem Projekt einen Takt zu geben. Der Sprint ist zu Ende, wenn die Zeit um ist und wird nie verlängert. Des Weiteren sind keine Änderungen während eines Sprints erlaubt, die das Sprintziel beeinflussen. Der Sprint kann jedoch jederzeit durch den Product-Owner abgebrochen werden.
Aktivitäten
Ein Sprint setzt sich aus folgenden Aktivitäten zusammen:
Sprint Planning:
Am Anfang des Sprints wird definiert, was entwickelt wird und wie die Arbeit erledigt wird. Die Sprint Planung dauert maximal zwei Stunden pro Sprint-Woche.
Daily Scrum:
Zu Beginn jedes Arbeitstages trifft sich bei einem maximal 15-minütigen Daily Scrum das Entwicklerteam. Zweck des Daily Scrums ist der Informationsaustausch, um einen Überblick des aktuellen Stands der Arbeiten zu bekommen und dient nicht zur Lösung von Problemen.
Der Scrum Master und der Product Owner nehmen häufig an der Sitzung teil, sind jedoch nicht aktiv beteiligt.
Sprint-Review:
Am Ende eines Sprints steht das Sprint-Review. Hier wird vom Scrum Team das Inkrement überprüft und das Product Backlog bei Bedarf angepasst. Das Ergebnis wird vom Entwicklungsteam präsentiert und es wird geprüft, ob das Ziel erreicht wurde. Das Scrum Team bespricht mit den Stakeholdern die Ergebnisse und was es als Nächstes zu tun gibt.
Sprint-Retroperspektive:
Auch ein Teil der nach Beendigung eines Sprints ausgeführt wird. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter machen zu können. Der Scrum Master unterstützt das Team dabei, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden sollen.
Product Backlog Refinement (Backlog Grooming):
Das Product Backlog Refinement ist ein fortlaufender Prozess, bei dem der Product Owner zusammen mit dem Entwicklungsteam das Product Backlog weiterentwickelt.
Oft gibt es auch solche Treffen mit ausgewählten Stakeholdern, um die Anforderungen im Product Backlog besser beschreiben zu können.
