Webkrauts

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:

1. Planung (5 Tage vor Sprintbeginn)
2. Auswahl der User Stories für den Sprint
3. Priorisierung der User Stories
4. Aufwandsschätzung für die einzelnen Aufgaben
5. Kick-Off – Detailplanung (1. Tag)
6. Umsetzung (2. bis 9. Tag)
7. 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:

1. Todo: Alle zu erledigenden Aufgaben
2. In Bearbeitung
3. 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.