Elefanten-Carpaccio – So kommt der Elefant in den Kühlschrank

Und so geht Elefanten-Carpaccio

Vorbereitung

Stelle für den Workshop eine Gruppe mit etwa 10 bis 20 Personen zusammen – es können aber gerne auch mehr sein. Plane mindestens zwei Stunden Zeit für diese Agenda-Punkte ein:

• In den ersten 30 Minuten besprecht Ihr die Hintergründe und die Problemstellung.
• In der nächsten halben Stunde erstellt Ihr ein Backlog mit den neuen, vom Umfang kleineren User Storys.
• Die Teilnehmer, die programmieren können, entwickeln in der Sprache ihrer Wahl innerhalb von 40 Minuten einen Prototypen.
• Danach besprecht Ihr noch 20 Minuten die Ergebnisse.

Einige Teilnehmer benötigen einen Laptop für die Entwicklung des Prototypen.

Im Besprechungsraum müssen genügend Steckdosen vorhanden sein.

Zu Recherchezwecken bietet sich auch ein WLAN-Zugang an.

Einführung

Kläre beziehungsweise diskutiere mit der Gruppe folgende Fragen:

• Was zeichnet eine gute Story aus?
  So sollte sie sein:

  • klein
  • vertikal (also den kompletten Prozess abbilden)
  • schätzbar
  • prüfbar
  • für den Anwender nützlich

• Welchen zeitlichen Umfang haben Eure Storys, Tasks und Commits? Welchen Umfang sollten sie haben?

  • Story: ein paar Tage (weniger als ein Sprint)
  • Aufgabe: ein paar Stunden (weniger als ein Arbeitstag)
  • Commit: ein paar Minuten (mehrere Commits pro Stunde)

• Welche Vorteile bietet das Aufteilen von User Storys?

  • Das Team lernt durch häufigere Feedback-Schleifen schneller.
  • Die Stakeholder sind zufriedener.
  • Personen und Teams sind besser synchronisiert.
  • Die Priorisierung fällt leichter.
  • Die Planung ist einfacher.
  • Das Risiko wird reduziert. Die Produkte werden besser.
• Wie verändert sich der Kundennutzen bei einer Entwicklung nach dem Wasserfall-Prinzip, bei der Verwendung von großen User Storys, beim Arbeiten mit kleinen User Storys?
  Warum hat der Graph für kleine Storys am Ende einen höheren Gesamtnutzen?

Aufgabenstellung

Erstellt in 40 Minuten, aufgeteilt in fünf Iterationen zu jeweils acht Minuten, einen einfachen Rechner für den Einzelhandel.

Dieser Rechner akzeptiert drei Eingabewerte: die Stückzahl, den Nettopreis pro Stück und den ISO 3166 ALPHA-2 Ländercode.

Es gilt folgender Zusammenhang:

Der Rechner gibt den Bruttopreis aus, wobei die lokale Umsatzsteuer sowie der Rabatt auf den Gesamtpreis berücksichtigt werden.

Backlog/Roadmap erstellen

Teile die Gruppe in zwei bis drei Teams auf. Jede Gruppe benötigt mindestens einen Programmierer mit einer lauffähigen Entwicklungsumgebung auf seinem Laptop.

Jede Gruppe schreibt nun ein Backlog mit User Storys (dabei sind die Laptops immer noch geschlossen). Jede Story muss in zwei bis sechs Minuten implementierbar sein und jedes Release liefert eine lauffähige Version.

Spielregeln

• Schreibt für die fünf Iterationen die erforderlichen User Storys und plant insgesamt etwa 15 bis 20 Schnitte/Releases ein. Priorisiert die User Storys, indem Ihr eine Storymap bzw. eine Roadmap erstellt.

• Ein Release ist nur dann gültig, wenn die Applikation über eine Benutzeroberfläche und mindestens ein Eingabefeld sowie ein Ausgabefeld verfügt.
• Außerdem muss sich ein Release deutlich von dem vorherigen unterscheiden.
• Es muss mindestens fünf Releases geben, bevor die Rabatte berücksichtigt werden. Denn die Umsatzsteuer ist im echten Leben verpflichtend, der Rabatt nicht.
• Eine Validierung und eine schöne Oberfläche sollen frühestens nach fünf Umsatzsteuer- und fünf Rabatt-Releases einfließen.
• Vermeidet „Goldränder“ und „Feenstaub“. Entwickelt jeweils nur das, was dem Kunden den größten Nutzen bringt.
• Es ist wichtig, das Reduzieren/Aufsplitten der Funktionen zu üben. Wenn Ihr mit nur drei Schnitten bis zum Ende kommt, habt Ihr Eure Zeit verschwendet und den Sinn dieser Übung nicht erfasst.

Produkt entwickeln

Jedes Team entwickelt nun in 40 Minuten den Rechner. Nach jeweils acht Minuten gibt es eine Demo. Die Zeit wird dabei nicht unterbrochen – also haltet Euch nicht zu lange damit auf. Jedes Team zeigt kurz den aktuellen Entwicklungsstand unter Angabe der jeweiligen Release-Nummer.

Besprechung der Ergebnisse

Nach 40 Minuten beendet Ihr die Entwicklung und besprecht die Ergebnisse.

• Wie weit seid Ihr gekommen?
• Wie viele Releases hattet Ihr?
• Funktioniert Euer Rechner? Prüft das anhand einiger Werte.
• Unterscheiden sich die Ergebnisse der Gruppen? Wenn ja, welche Ursachen kann es dafür geben?
• Wie haben sich die Nicht-Informatiker bei der Übung gefühlt?
• Wie haben sich die Informatiker bei der Übung gefühlt?
• Wie beurteilen die Programmierer die Qualität ihres Codes?
• Was haben die Teilnehmer gelernt?
• Was wollen die Teilnehmer in Zukunft anders machen?

Tipps

… für die Gestaltung des Workshops

• Wenn Eure Gruppe sehr groß ist, bildet kleinere Gruppen von etwa 8 Personen für die Frage- und Antwort-Sitzungen und sammelt die Gruppenergebnisse.
• Plant bei großen Gruppen eventuell mehr Zeit ein – auch für Pausen.
• Achtet darauf, dass während der Einführung alle Teilnehmer ihre Laptops geschlossen halten und keine Handys (privat oder geschäftlich) verwendet werden.
• Anonymisiert den Code vor der Bewertung.
• Stellt sicher, dass jeder der Teilnehmer weiß, wie er das Konzept des vertikalen Schneidens in seiner täglichen Arbeit umsetzen kann. Eine kurze Beschreibung oder auch nur ein Foto von einem Elefanten können als Gedächtnisstütze helfen.

… für die Praxis

• Legt fest, welchen Umfang Euer MVP, Euer Minimal Viable Product, haben soll – und weicht nicht von dieser Zielvorgabe ab.
• Versucht, jede Funktionalität so klein wie möglich zu realisieren. Auf diese Weise könnt Ihr nach jedem Sprint ein lauffähiges Produkt liefern.
• Konzentriert Euch auf die ersten beiden Punkte und arbeitet konsequent daran, diese zu erreichen.