Übersicht

Agile Softwareentwicklung sollte aus drei verschiedenen Blickwinkeln betrachtet (und verstanden) werden:

• Teamwork
• Mindset (die Philosophie)
• Projektmanagement

Die Vorgeschichte

Wiki

1995 erfand Ward Cunningham das Wiki. Ein radikal neuer Ansatz, um digital zusammenzuarbeiten.

Alle können jederzeit alles verändern
&
Es gibt eine vollständige Historie.

Programmierstile

1996 wurde mit Extreme Programming neue Wege in der Erstellung von Software beschritten.

Statt erst alles durchzuplanen, bekommen User sofort eine (minimal funktionsfähige) Software. User werden sofort in die Entwicklung einbezogen.

Daraus wurde CI/CD.

Die Philosophie

Aus diesen Erfahrungen entstand 2001 das
Manifest für Agile Softwareentwicklung

Signatory: Metaspatial

Methodik

Die Ideale des Manifest für agile Softwareentwicklung wurden als Methodik im Scrum Guide von Jeff Sutherland und Ken Schwaber konzipiert und werden kontinuierlich weiter entwickelt.

Methodik

Es gibt andere bekannte Methoden wie sie z.B. im Kanban Guide definiert sind.

Techniken verschiedener Methoden
können kombiniert werden und sich ergänzen.

Agiles Projektmanagement

Das Projektmanagement kann Scrum (oder Kanban) als Methode für Softwareentwicklung (z.B. mit Komponenten aus XP) wählen.

Scrum Handbuch

Das Projektmanagement erarbeitet individuell für jedes Projekt ein Scrum Handbuch.

Vetragliches

Das Scrum Handbuch sollte gemeinsam durch AG und AN erarbeitet und verbindlich beschlossen werden.

Agile Softwareentwicklung

Agiles Projektmanagement basiert auf der Annahme,
dass Änderungen im Plan
unvermeidbar sind.

Statt alles
Unvorhergesehene
im Voraus zu planen
(was offensichtlich unmöglich ist),
wird der Plan selbst flexibel gestaltet.

Scrum

Scrum ist eine Methode, bei der Aufgaben in regelmäßigen Iterationen von 2 bis 4 Wochen (einem Sprint) geplant und durchgeführt werden, bis das Produkt fertiggestellt ist.

Konkrete Arbeitspakete werden jeweils nur für einen Sprint zusammengestellt.

Vorteile

Das Projektrisiko wird erheblich reduziert.

• Probleme werden frühzeitig erkannt
• Potentielle Verzögerungen werden identifiziert
• Ursachen können identifiziert werden
• Gegenmaßnahmen können sofort ergriffen werden
• Der Plan wird kontinuierlich an die Realität angepasst

Nachteile

Auch agil geführte Projekte können komplett scheitern, davor ist nichts sicher. Oft liegt das aber an mangelnder Konsequenz bei der Anwendung agiler Methoden.

Gefährliches Halbwissen führt im Regelfall zu Schwierigkeiten

Rollen

• Team (5 bis 9 Personen)
• Product Owner (1 bis 2)
• Scrum Master (1)
• Stakeholder (beliebig viele)

Team

• entscheidet WIE eine Aufgabe umgesetzt wird
• entscheidet WIE VIELE Aufgaben im nächsten Sprint erledigt werden
• berichtet täglich über den Fortschritt
• berichtet täglich über Probleme

Product Owner

...pflegt kontinuierlich das Backlog.

• Erläutert dem Team welche Aufgaben anstehen
• Priorisiert die Aufgaben
• Ist ständig über den Stand der Aufgaben informiert

Product Owner unterschätzen anfangs
oft
immer
den Aufwand, um das Backlog zu pflegen!

Scrum Master

Achten auf die Einhaltung der Regeln.

• Schützen das Team
• Moderieren Besprechungen
• Kümmern sich darum, dass Probleme gelöst werden

Alle, die ein Interesse an dem Projekt haben,
aber nicht direkt daran arbeiten:

Stakeholder

• Business Owner
• Endanwenderinnen
• Management
• IT-Abteilung

Haben keinen direkten Einfluss auf das Projekt,
nur mittelbar über den Product Owner.

Artefakte

Drei Haupt-Artefakte werden regelmäßig gepflegt:

• User Stories
• Product Backlog
• Sprint Backlog

User Story

Die Aufgabe; Was soll erzielt werden?

• Product Owner beschreibt die Aufgaben
• Sollte innnerhalb eines Sprints erledigt werden
• Hat immer ein klares "Definition of Done"
• Team schätzt Aufwand und Risiko

Task

Wie wird die Story umgesetzt

• User Stories werden durch Tasks konkretisiert.
• Tasks werden vom Team formuliert.
• Ein Task (Aufgabe) ist präzise genug formuliert, um innerhalb von wenigen Stunden oder Tagen erledigt werden zu können.
• Ein Task hat immer ein klares "Definition of Done".
• Das Team bearbeitet immer nur Tasks aus dem aktuellen Sprint Backlog.

Product Backlog

Das Product Backlog enthält alle User Stories, die benötigt werden, um die Vision umzusetzen.

Anfangs gibt es nur wenige klare Stories im Product Backlog, das laufend von Product Owner gepflegt wird.

Sprint Backlog

• ...enthält alle User Stories für einen Sprint.
• ...wird im Sprint Planning vom Team bestückt.

Product Owner kann nur die Priorität
der User Stories ändern.

Spezialfälle

Wie werden Bug-Tickets behandelt? Ein Beispiel:

• Bug-Tickets gehen mit einer Timenbox (1h) direkt in das Sprint Backlog.
• Das Team analysiert der Fehler und schätzt das Ticket
• Product Owner entscheidet über die Priorität.
• Falls das Bug-Ticket hoch priorisiert wird, bleibt es im Sprint und es werden entsprechend viele andere Tasks herausgenommen.
• Andernfalls geht das Bug-Ticket ganz normal in das Product-Backlog.

Weitere Spezialfälle...

Es gibt immer jede Menge Spezialfälle, die im gleichen Duktus bearbeitet werden können. Wenn sich Spezialfälle häufen, wird eine generelle Lösung dafür gefunden und in die agile Methodik eingefügt.

Meetings Fix

Im Vorgehensmodell gibt es drei feste Haupt-Meetings:

• Sprint Planning
• Daily Stand-up
• Sprint Review
• und Retrospective (das wird immer vergessen)

Meetings Flex

Flexible Meetings mit einer kontinuierlichen Aufgabe:

Backlog Refinement

Und so gehts:

Sprint Ablauf

Das Team definiert Tasks, um die User Story umzusetzen.

• Sprint Planning
• Bearbeitung der ausgewählten Tickets
• Daily Stand-Up
• (Zwischendurch Backlog Refinement)
• Review Meeting
• Retrospective
• nächste Iteration...

Scrum in a nutshell. Source: http://metaspatial.net/wiki/Sprint (2019-02-27)

Product-Owner

...beschreiben Anforderungen in User-Stories.

Backlog Refinement

Sprint Planning I

Der Product Owner stellt neue User Stories aus dem Product Backlog vor.

• Das Team fragt, bis alles klar ist
• Das Team schätzt Aufwand/Risiko/Tomate
• Das Team wählt Aufgaben für den nächsten Sprint

Das Team schätzt Aufwand/Risiko/Tomate

...erstellen konkrete Arbeitspakete (Tasks) aus den User Stories, die am Ende jedes Sprints zu einem funktionierenden Produkt führen.

Pause

Sprint Planning II

Das Team legt Tasks an, um die User Story umzusetzen.

• Team klärt Details mit Product Owner
• Team committed sich zu den gewählten Tasks
• Der Sprint wird offiziell gestartet!

Im Sprint...

...arbeitet das Team Tickets ab (typisch sind 2 oder 4 Wochen)

Daily

Das Team berät sich täglich im Daily zu den Arbeiten und identifiziert Blocker.

15 Minuten. Der Scrum Master moderiert.

Scrum Master & Product Owner

...beseitigen Blocker und halten das Management
aus
auf dem Laufenden.

Review-Meeting

Das Team präsentiert am Ende des Sprints dem Product Owner, Anwendern und Stakeholdern das Ergebnis. (Im Idealfall) eine neue, funktionierende Version des Produkts.

Ziel ist immer laufenden Code zu zeigen, keinen Foliensatz!

Iteration

Dieser Prozess wird wiederholt, bis das Ziel erreicht ist.

• oder ein Zeitpunkt ist erreicht
• oder das Budget ist ausgeschöpft

Das Ergebnis

Das Ergebnis ist immer ein funktionierendes Produkt, dessen Qualität sich aus der Funktion von Budget, Zeit und Funktionsumfang zusammensetzt.

Source: https://en.wikipedia.org/wiki/Project_management_triangle (2019-03-11)

Scrum in a nutshell. Source: http://metaspatial.net/wiki/Sprint (2019-02-27)

Caveat

• Management muss agil unterstützen!
• Teams sollten multidisziplinär arbeiten!
• Teams müss selbstverantwortlich arbeiten (dürfen)!
• AnwenderInnen müssen mitmachen (dürfen)!

Umsetzung

• Jeder Jeck ist anders
• Scrum ist eine Methodik und muss mit Leben gefüllt werden
• Es wird ein Scrum Handbuch erstellt (pro Projekt / Firma / Team)
• Das Scrum Handbuch unterliegt selbst ständiger Verbesserung

...im folgenden zwei Beispiele:

Scrum Handbuch (Allgemein)

• Besprechungen sind pünktlich (Start & Ende)
• Termine immer als Einladung mit Link
• Code geht ins Respository
• Kein Code ohne Review
• Automatisiertes Linting
• Automatisierte Tests
• Doku aus dem Code
• Pair Programming first
• ...

Scrum Handbuch (spezifisch)

• Product Owner: (Name)
• Team: (Liste mit Namen
• Architekt: (Name)
• Stakeholder: (Liste mit Namen/Organisationen)
• Sprintlänge: (Anzahl Tage)
• Sprintwechsel am: (Wochentag)
• Backlog Refinement am: (Wochentage)
• Daily um: (Uhrzeit)
• ...