Agile Methoden
Das Wort Agil umfasst eine Reihe von Methoden und Methodologien, die einem Team helfen, effektiver zu denken, effizienter zu arbeiten und bessere Entscheidungen zu treffen. Diese regeln bspw. alle Bereiche der traditionellen Softwareentwicklung, einschließlich Projektmanagement, Softwaredesign und Softwarearchitektur sowie Prozessverbesserung. Jede dieser Methoden und Methodologien bestehen aus Verfahren, die rationalisiert und optimiert sind, um sie so einfach wie möglich zu gestalten.
Agil ist auch eine Denkweise, denn die richtige Denkweise kann einen großen Unterschied machen, wie effektiv ein Team die Praktiken anwendet. Sie hilft den Menschen in einem Team, selbst Probleme zu lösen und Informationen miteinander zu teilen, damit sie wichtige Projektentscheidungen treffen können, anstatt alle Entscheidungen durch eine Person alleine treffen zu lassen. Eine agile Denkweise offenbart die Planung, Gestaltung und Prozessoptimierung durch das gesamte Team. Unterstützt werden diese Praktiken mithilfe des kontinuierlichen Lernens aller Beteiligten durch Experimente in kurzen Feedbackzyklen und zur Verbesserung der Effizienz an Strukturen und Prozessen.
Im Februar 2001 veröffentlichte eine Gruppe von 17 Softwareentwicklern ein Manifest zur agilen Softwareentwicklung, welches einen Gegensatz zur traditionellen linearen Softwareentwicklung darstellt, bei der in ausführlichen Prozessen Pflichten- und Lastenheft erarbeitet und durch ein Entwicklungsteam in Programmcode überführt wurde. In diesem agilen Manifest gibt es vier Werte, die für eine erfolgreiche und effiziente Softwareentwicklung stehen: Individuen und Interaktionen über Prozesse und Tools, funktionierende Software über umfassende Dokumentation, Zusammenarbeit mit dem Kunden über Vertragsverhandlungen und Reagieren auf Veränderungen über befolgen eines Plans.
Laut einer Studie der GPM Deutsche Gesellschaft für Projektmanagement e.V. in Kooperation mit der Hochschule Koblenz im Jahr 2014 gehören Scrum, Kanban und Extreme Programming zu den am häufigsten verwendeten agilen Methoden.
Bedeutung von Scrum
Scrum ist ein Prozessrahmenwerk für die Entwicklung komplexer Produkte. Es folgt der Idee des schlanken Managements (Lean Management), wie es auch der Autohersteller Toyota betreibt. Scrum ist jedoch kein Akronym, sondern ein Begriff aus dem Rugby-Sport, wo er sich auf eine Möglichkeit bezieht, ein Spiel bspw. nach einer Verletzung neu zu starten.
Jeff Sutherland und sein Team schufen den Scrum-Prozess für die Softwarenentwicklung zuerst bei der Easel Corporation im Jahr 1993, indem sie die Konzepte aus dem Harvard Business Review Artikel mit Konzepten aus der objektorientierten Entwicklung, empirischer Prozessteuerung, iterativen und inkrementellen Entwicklung, Produktivitätsforschung und komplexen adaptiven Systemen kombinierten. In den 1990er Jahren nutze Sutherland es außerdem bei verschiedenen Unternehmen, wie VMARK, Individual und IDX Systems. Ken Schwaber, der mit Sutherland bei Individual gearbeitet hatte, formalisierte Scrum auf der OOPSLA Konferenz im Jahr 1995. Seitdem haben beide mehrere Scrum-spezifische Publikationen angefertigt.
Obwohl Scrum vielfach für die Softwareentwicklung verwendet wird, werden dessen Grundwerte und Prinzipien zum einen auch für die Entwicklung von unterschiedlichen Produkttypen und zum anderen für die Organisation von Arbeitsabläufen eingesetzt. Scrum setzt nachdrücklich auf die Mitwirkung des Kunden, selbstorganisierte Entwicklungsteams, priorisierten Aufgaben, einer offenen Kultur, Transparenz, einer regelmäßigen Überprüfung von Produkten, Prozessen und Methoden und der flexiblen Anpassung an ändernde Anforderungen. Es verfolgt die Idee von iterativen, inkrementellen Vorgehensmodellen, welche unter der Einhaltung fester Zeitrahmen (Time Boxing) regelmäßig wichtige Features liefern. Demzufolge stehen fünf Grundwerte im Mittelpunkt: Engagement, Fokus, Offenheit, Respekt und Mut.
Rollen
Ein Scrum Team besteht aus drei Rollen, dem Scrum Master, dem Product Owner und dem Entwicklungsteam. Was die einzelnen Rollen beinhalten, wird im Folgenden erklärt.
Eine zentrale Aufgabe des Scrum Master ist es, die Schulung des Entwicklungsteams und der Organisation in Scrum sowie agiler Vorgehensweisen zu übernehmen. Er bildet das Entwicklungsteam dahingehend aus, die Scrum Regeln bestmöglich einzusetzen und überprüft ebenso deren Einhaltung. Zudem unterstützt er das Entwicklungsteam bei deren Aufgaben und ist auf Verbesserungen fokussiert, ohne jedoch Personal- und Produktverantwortung zu übernehmen. Ferner moderiert er Scrum Ereignisse, wie bspw. die Scrum Retrospektive, und schützt das Entwicklungsteam gegen Störungen von außen. Dem Product Owner hilft der Scrum Master bei der richtigen Formulierung sowie der Priorisierung von Product Backlog Items, so dass nach jedem Sprint ein potentiell auslieferbares Produktinkrement entsteht. Innerhalb der Organisation arbeitet er gemeinsam mit anderen Scrum Mastern zusammen, um die Scrum Implementierung im Unternehmen zu verbessern und unterstützt Mitarbeiter und Stakeholder, die empirische Produktentwicklung zu verstehen.
Der Product Owner vertritt die Interessen aller Stakeholder und ist für den Erfolg des Produktes verantwortlich. Er achtet auf die Umsetzungsmöglichkeiten und arbeitet mit dem Entwicklungsteam eng zusammen, für das er stets verfügbar ist. Ist ein neues Produktinkrement nach dem Sprint fertiggestellt, überprüft er dessen Funktionalität und verantwortet dessen Auslieferung. Ebenfalls überwacht er fortwährend die Anforderungen der Stakeholder und führt diese in fachliche Anforderungen um, die im Product Backlog gesammelt und priorisiert werden.
Das Entwicklungsteam besteht aus drei bis neun gleichgestellten Entwicklern, welche sich weitestgehend selbst organisieren. Es ist für die Umsetzung der Sprint Backlog Items in ein fertiges Produktinkrement verantwortlich. Daher sollte das Entwicklungsteam interdisziplinär besetzt sein, also unterschiedliche Fachrichtungen aufweisen, umso die Effektivität zu erhöhen. Allgemein besitzt das Entwicklungsteam die Fähigkeiten, die vom Product Owner geforderten Anforderungen hinsichtlich der Umsetzung zu verstehen und zu bewerten.
Ereignisse
In Scrum erfolgt die Abarbeitung der Product Backlog Items in Iterationen, die Sprint heißen. Ein Sprint besitzt eine Länge von eins bis vier Wochen und liefert am Ende ein potentiell auslieferbares Produkt bzw. Produktinkrement, um damit einen Return on Invest zu generieren und den Kunden frühzeitig in der Entwicklung einzubinden. Es ist wichtig, dass Sprints über die gesamte Entwicklungsdauer einen konsistenten Zeitrahmen aufweisen, der immer wieder eingehalten wird und ein bestimmtes Ziel verfolgt. Eine feste Sprintlänge garantiert eine aussagekräftige Velocity, was die Kennzahl über die Produktivität eines Scrum Teams ist und als Planungsgrundlage für den Sprint dient. Scrum gibt zwar keine Mindestlänge vor, jedoch sollte der Sprint nicht kürzer als eine Woche dauern. Die folgende Abbildung 1 zeigt den Scrum Workflow, die Phasen eines Sprints und deren zeitliche Abfolge, welche anschließend erklärt werden.
Abbildung 1: Scrum Workflow (Quelle: Essential Scrum – A Practical Guide to the Most Popular Agile Process (Rubin, K. S.; 2013), S. 51.)
Im ersten Schritt der Sprint Planung muss der Product Owner ein Sprint-Ziel anhand der priorisierten Product Backlog Items definieren. Das Ziel muss hierbei eindeutig sein, da anschließend eine Schätzung über die Machbarkeit durch das Entwicklungsteam getroffen wird. Im zweiten Teil erfolgt eine detaillierte Planung, wie das Entwicklungsteam das Sprint-Ziel erreichen möchte, da das Ziel während des Sprints nicht mehr verändert werden darf.
Das Daily Scrum ist eine Besprechung, die täglich innerhalb eines Sprints abgehalten wird und maximal 15 Minuten dauern sollte. Es dient dem Austausch von Informationen über den aktuellen Stand und Fortschritt, an der nur das Entwicklungsteam teilnimmt. Währenddessen wird inhaltlich geklärt, was seit dem letzten Daily Scrum erreicht wurde, welches die nächsten Schritte sind und was einen Entwickler an der Bewältigung seiner Arbeit hindert.
Am Ende jedes Sprints findet ein Sprint Review statt, in dem gemeinsam mit den Stakeholdern das erstellte Produktinkrement inspiziert wird. Der Product Owner muss das Produktinkrement zu dem Zeitpunkt schon kennen bzw. gesehen haben und bekommt direkt Feedback von den Stakeholdern, ob das Sprint-Ziel erreicht wurde.
Während der Sprint Retrospektive diskutieren alle Scrum Team Mitglieder die Ergebnisse des letzten Sprints. Inhaltlich geht es darum, was im Sprint positiv oder negativ verlief und überführen Verbesserungen direkt in den nächsten Sprint. Der Scrum Master übernimmt hierbei die Verantwortung über Aktionen, die das Entwicklungsteam nicht verändern kann, wie bspw. organisatorische Herausforderungen und überträgt alle Hindernisse (Impediments) in die nächste Sprint Retrospektive, um die Auswirkung zu verfolgen.
Artefakte
Scrum Artefakte setzen sich aus Product Backlog, Sprint Backlog, Produktinkrement und der Definition of Done zusammen. Artefakte repräsentieren allgemein Wert und Arbeit und schaffen Transparenz, so dass das Scrum Team die Ziele im Fokus behält und entsprechend überprüft. Was die Artefakte im Einzelnen bedeuten, wird folgend erörtert.
Das Product Backlog wird vom Product Owner verwaltet und Einträge entsprechend den Anforderungen priorisiert. Jedes Product Backlog Item muss generell den DEEP-Kriterien entsprechen, was für detaillierte Angaben (Detailed appropriately), veränderbare Einträge (Emergent), geschätzt (Estimated) und priorisiert (Prioritized) steht und einerseits detailliert beschreibt, was zu erstellen ist und andererseits eine Schätzung besitzt, wie aufwändig die Umsetzung ist.
Das Sprint Backlog ist eine Liste aller Aktivitäten, die ein Entwicklungsteam während des Sprints umsetzt. Es ist zudem das Ergebnis der Sprint Planung und entspricht dem Sprint-Ziel. Der Aufwand eines Eintrages kann in Personenstunden geschätzt werden und sollte 16 Stunden nicht überschreiten. Ist dies dennoch der Fall, muss es in mehrere, kleinere Anforderungen zerlegt werden. Sprint Backlog Items besitzen für ein besseres Verständnis User Stories.
Scrum fordert, dass am Ende eines Sprints ein potentiell auslieferbares Produktinkrement entsteht. Auslieferbar heißt hierbei, dass keinerlei Arbeiten offen sind, um das Produktinkrement übergeben zu können. Es muss somit der Definiton of Done entsprechen und nicht an das nächste fachliche Team übergeben werden.
Die Definition of Done beschreibt alle Attribute und Arbeiten, welche erledigt werden müssen, damit ein Product Backlog Item als fertiggestellt gilt. Die Definition muss dem Scrum Team bekannt sein und wird stetig erweitert, um die Qualität zu erhöhen. Die Informationen dazu kommen u.a. aus der Sprint Retrospektive. Es hilft ebenfalls bei der Entscheidung, ob ein Produktinkrement am Sprintende auslieferbar ist.