Einstieg in Scrum und Kanban – Teil 1
Agile Ideen für Webentwickler
Bei größeren Webprojekten kann es schwierig, sogar hinderlich sein, im Voraus festzulegen, was am Ende wirklich benötigt wird. Agile Entwicklungsmethoden bieten einen anderen Ansatz: Mit wenigen Regeln und einem iterativen Vorgehen sollen die Projekte flexibler und einfacher werden. Methoden und Ideen wie Sprints, User Stories und Kanban Board eignen sich auch für kleinere Teams und Projekte.
Kanban und Scrum sind agile Vorgehensmodelle, die sich gegenwärtig großer Aufmerksamkeit erfreuen und seit Jahrzehnten erfolgreich eingesetzt werden – sowohl im Großen bei Weltkonzernen wie Toyota als auch auf individueller Ebene zur Selbstorganisation.
Unzählige Schulungsangebote, Fachvorträge und Bücher bieten einen guten Einstieg in die Methoden und deren Umsetzung in Entwicklungsteams oder ganzen Unternehmen. Anstelle einer weiteren Einführung in die Methoden findet ihr im Folgenden einen Überblick über die »agilen« Ideen und Werkzeuge sowie deren mögliche Anwendungen in der täglichen Arbeit – in Form einer Kombination von Kanban und Scrum. Diese bietet insbesondere für einzelne Webworker oder kleine Teams eine Chance, die Vorteile auch im »nicht-agilen« Umfeld zu nutzen.
Verbesserung in kleinen Schritten
Der Kern der beiden Vorgehensweisen – das Agile Manifest – hat folgende Kernaussagen:
- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
- Funktionierende Software ist wichtiger als umfassende Dokumentation.
- Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung.
- Schnelle Reaktion auf Veränderung ist wichtiger als die strikte Planung.
Das bedeutet nicht, dass Prozesse, Werkzeuge, Dokumentation, Vertragsverhandlungen und ein Projektplan unwichtig oder unnötig wären. Es geht mehr um die richtigen Prioritäten.
Insbesondere Kanban legt großen Wert darauf
- Prozesse zu standardisieren und kontinuierlich zu verbessern.
- Fehler zu vermeiden und die Kosten von Fehlern zu reduzieren.
- Im Kundentakt zu produzieren (nur das, was der Kunde wirklich benötigt, bei kontinuierlicher Anpassung der Planung an geänderte Anforderungen).
- Verschwendung zu reduzieren.
Es wird versucht, die Welt des Kunden mit dessen Augen zu sehen:
- Denken wie der Kunde beziehungsweise der Nutzer.
- Direkte Kommunikation zwischen den Entwicklern und dem Kunden.
- Priorisierung von Entwicklungszielen anhand ihres Wertes für den Kunden.
- Zeitnahe Lieferung und Verifizierung von Zwischenständen.
Die Werte sind daher Offenheit, Verantwortung und Einfachheit.
Die Kundenzufriedenheit wird hierbei durch einen kontinuierlichen und institutionalisierten Dialog gesteigert; die Entwicklung bewegt sich dabei »von 100% unbekannt« hin zu »100% fertig«. Änderungen an der Planung werden genauso berücksichtigt (und sind willkommen/eingeplant) wie die regelmäßige Lieferung fertiger Softwarestände.
Einfachheit
Das wichtigste Ziel agiler Methoden ist die Einfachheit. Viele Entwickler neigen dazu, technisch komplizierte Lösungen und interessante Zusatzfunktionalitäten zu entwickeln, die zur Lösung des Problems gar nicht benötigt werden. Die Vorteile der »einfachsten Lösung«:
- Es muss weniger Code produziert werden.
- Es muss weniger Code getestet werden.
- Weniger Funktionalität und Komplexität bedeutet meist eine einfachere Nutzung, geringeren Schulungsaufwand, was zu einer höheren Zufriedenheit bei den Nutzern führt.
- Die Komplexität der Lösung ist geringer, dadurch sinkt die Wahrscheinlichkeit, auf unerwartete Probleme zu stoßen.
- Die Gesamtkosten aus Sicht des Kunden sinken (Stichwort: »total cost of ownership«), da in Zukunft auch weniger Code gewartet werden muss.
- Das Projekt wird schneller fertig.
Daher führen weniger Funktionen und einfachere Lösungen fast automatisch zu zufriedeneren Kunden und Nutzern. Wie kann dies nun in der Praxis umgesetzt werden?
User Stories und Product Backlog – oder: »was soll entwickelt werden?«
Als User Story wird eine in Alltagssprache formulierte Anforderung aus Nutzersicht bezeichnet. User-Stories sollten in ein bis zwei Sätze gefasst werden und möglichst auf eine Karteikarte passen. Es ist sinnvoll, innerhalb eines Projektes eine einheitliche Struktur für User Stories zu wählen. Ein Beispiel mit dem Fokus auf die Benutzerrolle (zum Beispiel »Besucher der Webseite«, »Editor«): »Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> zu erreichen.«
- »Als Besucher der Webseite möchte ich dem Betreiber eine Nachricht zukommen lassen, um weitere Informationen zu einem Produkt anzufordern«.
- »Als Besucher der Webseite möchte ich dem Betreiber eine Nachricht zukommen lassen, um einen Termin auszumachen«.
- »Als Betreiber der Website möchte ich Nachrichten von Besuchern der Webseite als E-Mail erhalten, um direkt darauf reagieren zu können«.
In User Stories werden Ziele und Nutzen aus Sicht des Anwenders beschrieben, statt sich bereits auf eine Funktionalität und Implementierung zu begrenzen. Anstelle von »wie umsetzen« wird beschrieben was erreicht werden soll. Die Frage nach dem Ziel erleichtert es zudem, ungeeignete oder unnötig komplizierte Funktionalitäten leichter zu identifizieren, da der Nutzen des Anwenders klar im Vordergrund steht. Das gleiche gilt für Spielereien und subjektive Präferenzen. Folgende User Stories sind schwerlich vorstellbar:
- »Als Besucher der Webseite wünsche ich mir, dass Musik im Hintergrund gespielt wird, weil ich das total toll finde«
- »Als Besucher der Webseite wünsche ich mir, dass wichtige Textstellen unterstrichen sind, damit ich mir diese besser merken kann«
- »Als Besucher der Webseite möchte ich gefragt werden, bevor ich die Webseite schließen kann, damit ich nochmals bestätigen kann, ob ich wirklich die Seite verlassen will«
User Stories reduzieren Komplexität. Insbesondere zu Anfang eines Projektes sind viele Anforderungen noch sehr abstrakt. Kundenziele, die auf einer horizontalen Achse den gesamten Umfang des Projektes beschreiben, können durch weitere Verfeinerung in vertikaler Richtung immer detaillierter beschrieben werden.
Größere Themenblöcke werden als »Epic« bezeichnet. Dies können zum Beispiel Funktionalitäten wie Authentifizierung, die Nutzung eines Kontaktformulars oder die Anmeldung zu einem Newsletter sein. Aus »Als Besucher der Webseite möchte ich mich zu einem Newsletter anmelden, um eine Mail zu erhalten, sobald es Neuigkeiten gibt« (Epic) können dann weitere User Stories abgeleitet werden, die insbesondere aus Sicht verschiedener Nutzergruppen oder Bestandteile des Systems formuliert werden.
Praxistipps zur Strukturierung:
- User Stories sollten eine eindeutige Identifikationsnummer haben, um leicht in Bezug zueinander gesetzt werden zu können.
Beispiel: »Siehe auch: #2456, #3322« oder »Blockiert: #994, #4110«. - Zur leichteren Strukturierung bietet es sich an, eine Überschrift mit Modulzuordnung zu verwenden. Beispiel:
- Überschrift: »Newsletter: Anmeldung« (Modul: Funktion).
- User Story: »Um mich zum Newsletter anzumelden, möchte ich als Besucher der Webseite meine E-Mail-Adresse angeben können«.
Neben Epic und User-Stories gibt es noch Task (Aufgabe). Eine Task beschreibt die konkrete Umsetzung und somit das »wie« einer User Story. Beispiel:
- Orderstruktur und CSS Dateien anlegen.
- jQuery dem Projekt hinzufügen.
Als »Product Backlog« wird die Summe aller Epics, User-Stories und Tasks beschrieben, die das zu entwickelnde Produkt beschreiben.
Sprint Backlog und Kanban-Board
Im Scrum-Prozess erfolgt die Umsetzung in sogenannten »Sprints« – in sich geschlossene Zyklen – die üblicherweise eine Länge von zwei Wochen haben. Je nach Team, Projekt oder auch Projektphase sind natürlich auch kürzere oder längere Intervalle möglich. Insbesondere während der Einführung von Scrum kann es sinnvoll sein, für eine begrenzte Zeit im Wochenrhythmus zu arbeiten, um Erfahrungen zu sammeln und den Prozess zu etablieren.
Sehr stark vereinfacht besteht ein zweiwöchiger Sprint (10 Arbeitstage) aus folgenden Phasen:
- Planung (5 Tage vor Sprintbeginn)
- Auswahl der User Stories für den Sprint
- Priorisierung der User Stories
- Aufwandsschätzung für die einzelnen Aufgaben
- Kick-Off – Detailplanung (1. Tag)
- Umsetzung (2. bis 9. Tag)
- Präsentation der Ergebnisse in einer »Sprint Demo« (10. Tag)
Scrum ist ein sehr stark regulierter und strukturierter Prozess (circa 35 Regeln), mit sehr detaillierten Beschreibungen von Rollen und Verantwortlichkeiten.
Einige dieser Regeln lauten:
- Die Anzahl der zu erreichenden Ziele wird vor dem Sprint festgelegt. Muss während des Sprints eine Änderung vorgenommen werden, erfolgt dies durch einen sogenannten »Change Request«. Für jede zusätzliche Aufgabe wird eine mit vergleichbarem Aufwand aus den Sprintzielen entfernt. Für das Team stellt dieses Vorgehen eine zentrale Schutzfunktionen dar.
- Am Ende des Sprints steht immer ein nutzbares Arbeitsergebnis, das wiederum als Grundlage für die nächste Sprintplanung dienen kann. Konkret bedeutet das: Funktionalitäten so früh wie möglich nutzbar machen, um authentisches Feedback sammeln zu können.
- Die gleichbleibende Länge der Sprints ermöglicht eine gewisse Plan- und Vorhersagbarkeit der folgenden Sprints, da eine Metrik für die Team Geschwindigkeit (Velocity) abgeleitet werden kann. Im einfachsten Fall könnte dies »Anzahl der Stories / Sprint« sein, wobei aus vergangenen Erfahrungen natürlich immer nur begrenzt auf die Zukunft schließen lässt.
Kanban hat im Vergleich zu Scrum nur wenige Regeln. Die zentralen Ideen lauten:
- Visualisierung des Arbeitsprozesses.
- Begrenzung der Anzahl gleichzeitiger Aufgaben (»Work in Progress« - WiP).
Zentrales Element ist das »Kanban Board«: Es umfasst verschiedene Spalten, welche die einzelnen Prozessschritte abbilden. Beispiel:
- Todo: Alle zu erledigenden Aufgaben
- In Bearbeitung
- Fertig
Ein etwas detaillierteres Board in der Programmierung mit acht Schritten könnte so aussehen:
- Backlog
- Umsetzung
- Programierung
- Programmierung fertig
- Verifizierung
- Abnahme- und Akzeptanztests
- Testen
- Tests fertig
- Auslieferung
Kanban begrenzt dabei die Anzahl der gleichzeitig offenen Aufgaben im Status Bearbeitung (WiP) um eine Überlastung zu vermeiden. Wie würde also eine Verbindung der beiden Ansätze in der Praxis aussehen? Scrum lässt sich als Rahmen verwenden, um das Backlog zu strukturieren und Ziele für ein Team zu definieren, um dann die persönlichen Aufgaben für jedes einzelne Teammitglied mittels eines Kanban Boards zu organisieren. Ein Beispiel für ein Team aus jeweils einem Redakteur, Designer, Frontend- und Backend-Entwickler:
- Sprint Länge: zwei Wochen.
- Jedes Teammitglied erhält ein persönliches Kanban Board.
- Die beiden Entwickler sind Vollzeit im Projekt verfügbar.
- Die beiden Entwickler werden mit netto 40 (von ca. 75 möglichen) Arbeitsstunden im Sprint geplant, um über ausreichend Puffer zu verfügen.
- Die Entwickler bearbeiten gemeinsam das Sprint Backlog, aber strukturieren ihre persönlichen Aufgaben auf jeweils eigenen Kanban Boards.
- Der Redakteur wird im Scrum je Sprint flexibel eingeplant, wobei dies zwischen 0% zum Projektstart und 100% zum Projektende (Testen) variiert. Sein Kanban Board umfasst auch andere Projekte und berücksichtigt insbesondere täglich neu auftretende Aufgaben im Kontakt mit dem Kunden.
- Notwendige Zulieferungen des Designers müssen vor Beginn des jeweiligen Sprints vollständig vorliegen, weshalb diese nicht im Scrum geplant werden.
- Der Designer profitiert durch die Visualisierung seiner Aufgaben durch ein Kanban Board insbesondere, da er jederzeit »zeigen« kann, woran er gerade arbeitet. Darüber hinaus unterstützt die Begrenzung des WiP den kreativen Prozess.
- Die Sprint Demo bringt alle Beteiligten zusammen und ermöglicht, die Arbeitsergebnisse zu diskutieren.
Im morgigen zweiten Teil geht es um den Praxiseinsatz, Werkzeuge und die Frage, wie ein Vertragsentwurf für ein agiles Projekt aussehen könnte.
Kommentare
nikosch
am 22.12.2013 - 18:16
- Funktionierende Software ist wichtiger als umfassende Dokumentation.
- Schnelle Reaktion auf Veränderung ist wichtiger als die strikte Planung.
Bei solchen Aussagen kann ich als Softwareentwickler nur den Kopf schütteln…
- Im Kundentakt zu produzieren (nur das, was der Kunde wirklich benötigt, bei kontinuierlicher Anpassung der Planung an geänderte Anforderungen).
- Verschwendung zu reduzieren.
… und in diesen Anforderungen sehe ich sogar einen Widerspruch.
„Funktioniert (irgendwie)“ hat nichts mit nachhaltiger Entwicklung zu tun, eine fehlende „strikte Planung“ bedeutet, immer wieder mal bei Null anzufangen, und „im Kundentakt zu produzieren“ lässt sich wohl besser beschreiben: Monatelang kommt gar nix und dann ist die Deadline plötzlich übermorgen. Dumm nur, wenn dann die Dokumentation fehlt.
Das mag alles für den Kunden wunderbar praktisch und günstig sein, ich frage mich nur, wie ein Dienstleister hier eine vernünftige Projekt-, Budget- und Zeitplanung kalkulieren soll. Es hat schon seinen Grund, warum „agil“ immer mehr zum Schimpfwort in der Branche wird. Nach Solutions und Code-Ninjas sind die agilen Entwicklungsprozesse triumphierend in den Beratersprech eingezogen und wurden von entsprechend veranlagten Kunden willig angenommen. Warum auch nicht - der Kunde hat dadurch nur Vorteile, die sich letztlich unter dem Stichwort Unverbindlichkeit zusammenfassen lassen.
Bernhard Welzel (Autor)
am 23.12.2013 - 07:35
Der Einwand das "agil" immer mehr zum Schimpfwort wird ist mehr als berechtigt; dies liegt nach meiner Einschätzung jedoch nicht an der Vorgehensweise selbst, sondern an einem fehlenden Verständnis und einer inkonsequenten Umsetzung.
Ich möchte versuchen an einem konkretes Beispiel aus einem Scrum-Projekt zu zeigen wo die Mißverständnisse liegen könnten: Es wird mit einer Sprintlänge von einer Woche entwickelt. Am Ende der ersten Woche findet ein Demo-Meeting gemeinsam mit allen Beteiligten statt, und eine erste nutzbare Version der Software wird vorgeführt. Und auf Basis dieses Entwicklungsergebnisses kann dann im Dialog entschieden werden, wie es in der nächsten Woche weitergeht. Also genau das Gegenteil von: "es kommt monatelang nichts".
Was die Dokumentation betrifft, so sagt das Manifest nur aus "ist wichtiger als". In meinen Projekten gibt es aufgrund der Art der Softwarentwicklung (also Test Driven Development, Peer Programming und striken Code Reviews) eine sehr hohe Abdeckung mit aktueller Dokumentation - und dies vom ersten Tag an. Neben der Dokumentation im Quelltext selbst (die durch das Build Tool auch in eine Metrik gegossen wird) ist eine zusätzliche Dokumentation auf Komponenten und Architekturebene quasi schon zwingend notwendig um überhaupt mit der Entwicklung beginnen zu können.
Und ja - es gibt die "Code-Ninjas" und "Hacker" und das alles mögliche als "agil" verkauft wird. Das hat aber nichts mit Agiler Entwicklung zu tun. Agil bedeutet ja gerade nicht "mal kurz irgendwas irgendwie zusammen zu basteln" - im Gegenteil. Für den Kunden wird es vom ersten Tag an deutlich verbindlicher. JA - der Kunde kann am Ende jedes Sprints alles neu Priorisieren. Aber genau das ist der Vorteil: anstelle den ersten Entwurf der Lösung über längere Zeit hinweg zu entwickeln wird so früh wie möglich mit (potentiellen Nutzern) getestet. Und vielleicht wird auch das Ergebnis des Sprints komplett verworfen - was aus Sicht der Gesamtkosten sehr effizient sein kann, da die Richtungskorrektur so früh wie möglich geschieht und Verschwendung dadurch minimiert wird.
Eine weitere Erfahrung die ich immer wieder in der Praxis mache: nach der Einführung agiler Prozesse sind Überstunden und "Todesmärsche" ( für die Entwickler) quasi nicht mehr anzutreffen - bei gleichzeitig drastisch höherer Kundenzufriedenheit. ABER: dieser Effekt tritt nur ein wenn wirklich agil entwickelt wird. Sprich: auch die strikten Vorgaben des Prozesses eingehalten werden.
Kallee
am 28.12.2013 - 14:06
Was wäre wenn ...
... ich 6 Arbeitsstunden in coden und doku aufteilen darf?
- zur Auswahl stehen:
#1: 3h coden+3h doku -> fast fertiges programm mit komplexer doku
#2: 5h coden+1h doku -> fertiges programm mit einfach gestalteter doku
Laut der Scrumregel würde man hier die zweite Variante wählen.
In meinen Augen soll die Regel einfach nur verhindern, dass in kritischen Fällen die Entscheidung Richtung Funktion anstatt Dokumentation geht. Es bringt dem Kunden halt nix wenn die Doku der Hammer aber das Programm *Schrott/nicht fertig* ist. Anders herum kann der Kunde noch detailierte Doku nachfordern, aber schonmal mit seinem gewünschten Programm vorlieb nehmen.
Meine Auffassung zur Scrumdokuregel:
Scrum sagt Doku ist wichtig, aber nicht die erste Geige.
Guten Rutsch und alles Liebe
Kallee
nikosch
am 23.12.2013 - 11:22
Vielen Dank für die Antwort.
Die Kommentare sind geschlossen.