Spikes

Ziel

Die Agile Extension zum BABOK Guide setzt dem Spike diesen Zweck: eine Untersuchungs-, Entwurfs-, Explorations-, Ermittlungs- oder Prototyping-Tätigkeit zeitlich zu begrenzen, um den Aufwand zu verstehen, den die Lieferung eines Backlog-Items oder einer Initiative fordert. Den Auslöser nennt der Guide: ein Item oder eine Initiative, die sich nicht schätzen lässt.

Sein Ergebnis ist Wissen: eine Schätzung, die möglich geworden ist, eine Antwort zur Machbarkeit, ein Entwurfsentscheid, zwei anhand konkreter Ergebnisse verglichene Ansätze. Die Agile Extension schliesst das lieferbare Inkrement aus dem aus, was ein Spike hervorbringt. Der Code, der während eines Spikes geschrieben wird, beantwortet die gestellte Frage und hört dort auf.

Diese Grenze verortet ihn gegenüber den beiden Sitzungen, die die Iteration einrahmen: Die Retrospektive prüft die Arbeitsweise des Teams, während der Spike ein unfertiges Arbeitselement prüft. Das Iterations-Review zeigt Stakeholdern ein fertiggestelltes Inkrement; ein Spike bringt keines hervor, und seine Antwort wird zwischen dem Team und dem Product Owner verwertet, im Backlog Refinement oder in der Planung.

Tabelle 7.0.1 der Agile Extension führt den Spike unter den Techniken des Anforderungsmanagements und stellt ihn auf die Seite der internen Teams, ohne Eintrag für Stakeholder ausserhalb des Teams. Das Ergebnis erklärt diese Einordnung: eine technische oder organisatorische Antwort für jene, welche die Arbeit leisten werden.

Einsatz

Wann einsetzen

• Item, das die relative Schätzung nicht klärt: Die Streuung der Meinungen geht auf eine Unbekannte zurück, die kein Gespräch auflöst.
• Schnittstelle, Bibliothek oder Plattform, die noch nie integriert wurde: Ein technischer Prototyp beantwortet in Stunden, was ein Gespräch offen lässt.
• User Story, die zu gross ist, um auf Anhieb zerlegt zu werden: Ein funktionaler Spike lokalisiert das Risiko und die Stellen, an denen sich die Story schneiden lässt.
• Organisatorisches Risiko, bevor eine Initiative eingegangen wird: Ein explorativer Spike misst die Auswirkung auf Prozesse, Rollen und Compliance.
• Mehrere konkurrierende Ansätze oder Werkzeuge: Sie an konkreten Ergebnissen zu vergleichen kostet weniger als eine aus dem Gedächtnis verteidigte Wahl.
• Team, das sich bildet: Die Agile Extension zählt zu ihren Stärken das gegenseitige und technische Wissen, das ein früher Spike entstehen lässt.

Wann nicht einsetzen

• Frage, die ein Anruf klären würde: den Architekten oder den Lieferanten fragen, danach schätzen.
• Ergebnis, das für die Produktion bestimmt ist: Der Ausgang ist bekannt, es handelt sich um ein gewöhnliches Backlog-Item, das geplant und geliefert wird.
• Rückgriff in jeder Iteration: das Backlog Refinement korrigieren.

Beschreibung

Die beiden Elemente

Die Agile Extension gibt der Technik zwei Elemente: das Ziel und den Typ. Das Ziel ist ein definiertes Ergebnis, das sagt, wann die Untersuchung beendet ist, und der Praktiker der Business Analyse setzt die Dauer des Spikes (time-box im Text des Guides) innerhalb einer Iteration. Ein Ziel wird als Frage geschrieben, deren Antwort sich prüfen lässt: "Deckt die Bibliothek X das Format Y bei unseren Volumen ab?" schliesst, "die Integrationsoptionen prüfen" schliesst nie.

Einen Spike durchführen

Der Spike kommt als eigenes Item ins Backlog, mit sichtbarem Ziel und sichtbarer Dauer, und er wird wie alles andere in eine Iteration eingeplant. Eine oder zwei Personen führen ihn durch. Mike Cohn beziffert den Spike selbst in Stunden (4, 40 oder 400 je nach Tragweite) und behält ihn extremer Ungewissheit vor. Eine gewöhnliche Schwierigkeit beim Schätzen löst sich, indem das Item verfeinert wird.

Die Dauer läuft ab, ob die Frage geklärt ist oder nicht. Ein Spike, der "keine Antwort in sechzehn Stunden" liefert, hat ein Ergebnis erbracht: Das Item ist riskanter, als das Team annahm, und der Entscheid über das Weitermachen liegt beim Product Owner. Die Antwort wird im Refinement oder in der Planung berichtet, das Item wird neu geschätzt, danach wird der Spike geschlossen.

Was einen Spike scheitern lässt

Zu lange Dauer oder zu grosses Item

Die Agile Extension nennt diese Grenze: Eine zu weite Dauer oder ein zu umfangreiches Item nimmt dem Spike klare Ziele und ein klares Ergebnis. Zwei Wochen Untersuchung zu "der Migration" liefern einen Bericht, den niemand in eine Schätzung überführt. Lässt sich die Frage nicht in einem prüfbaren Satz stellen, ist das Item noch zu gross und wird vor jedem Spike zerlegt.

Das Wort für ein Folgegespräch

Der Guide hält fest, dass der Begriff zu Unrecht für Folgegespräche verwendet wird. "Dazu machen wir einen Spike" wird zu der Formel, die einen Entscheid von einer Iteration in die nächste schiebt. Ein Spike hat ein geschriebenes Ziel, eine Dauer und eine Person, die ihn durchführt; was diese drei Merkmale nicht hat, ist eine Aufgabe, eine Frage oder eine Vertagung.

Der Prototyp, der in die Produktion geht

Kent Beck, der die spike solution benannt hat, beschreibt sie als ein minimales Programm, das gebaut wird, um eine Entwurfsfrage zu beantworten, und danach verworfen wird. Der Code eines Spikes wird schnell geschrieben, ohne Tests und ohne Fehlerbehandlung, weil die gestellte Frage sie nicht verlangt. Unter dem Druck eines Termins so ausgeliefert, wird er zu einer technischen Schuld, deren Ursprung nach zwei Iterationen vergessen ist. Die Antwort des Spikes wird behalten; sein Code wird weggeworfen.

Der Spike in jeder Iteration

Häufiger Rückgriff zeigt laut Agile Extension ein Backlog Refinement an, das den Bedürfnissen des Teams nicht gerecht wird. Die Items kommen in die Planung, ohne dass jemand untersucht hat, was sie voraussetzen. Die Korrektur betrifft das Refinement: Die Zahl der erlaubten Spikes zu deckeln lässt die Ursache bestehen und schwächt die Schätzungen.

KI-Überlegungen

Ein Sprachmodell kürzt den dokumentarischen Teil eines technischen Spikes ab: Es erfasst die Bibliotheken, die ein Format verarbeiten, fasst eine Spezifikation von mehreren hundert Seiten um die gestellte Frage herum zusammen, erzeugt in wenigen Minuten das Gerüst des wegwerfbaren Prototyps. Es hilft auch beim Schreiben des Ziels: Eine Formulierung vorzulegen und zu fragen, woran man erkennen würde, dass sie erreicht ist, bringt die Ziele zum Vorschein, die nicht schliessen.

Ein Spike ist dazu da, einen Beleg auf dem technischen Stack des Teams zu erzeugen, mit dessen Versionen, dessen Volumen und dessen Daten; ein Modell beschreibt eine Bibliothek so, wie sie in seinen Trainingsdaten stand, und es erfindet Schnittstellenoptionen mit derselben Sicherheit, mit der es reale nennt. Die Antwort zählt, wenn der Code beim Team gelaufen ist. Die Schätzung, die folgt, bleibt jene des Teams, das liefern wird.

Ein Spike greift oft auf das Sensibelste zu, was die Organisation hat: internen Code, Schnittstellenschemata, mitunter Produktionsdaten, die zur Nachstellung eines Falls gezogen wurden. Dieses Material geht nicht an einen externen Dienst, ohne dass die Nutzung gedeckt ist; das Datenschutzgesetz (DSG) gilt für Personendaten, die in einem Testdatensatz liegen, wie überall sonst.

Beispiele

Ein Team eines Zahlungsdienstleisters im Kanton Waadt nimmt den Abgleich der QR-Rechnungs-Zahlungen mit den Buchungen des Kernsystems ins Backlog auf, über eine ISO-20022-Schnittstelle, die es nie integriert hat. Die relative Schätzung kommt nicht weiter: Die vorgeschlagenen Zahlen reichen von 3 bis 13 Punkten. Das Team eröffnet einen technischen Spike. Seine Karte liest sich im Werkzeug so, ergänzt bei der Schliessung.

Die Entwicklerin richtet ein eigenes Repository ein und lässt die bereits lizenzierte Bibliothek über einen Stapel von camt.054-Gutschriftsanzeigen laufen, also über jene ISO-20022-Meldung, mit der eine Bank die Buchungen auf einem Konto anzeigt, gezogen aus der Testumgebung der Hausbank des Unternehmens. Die einfachen Anzeigen laufen ohne Eingriff durch. Teilzahlungen liefern Beträge, die der Abgleich nicht erklärt, und Zahlungen mit SCOR-Referenz kommen ohne Schlüssel heraus, mit dem sich die ursprüngliche Rechnung finden liesse. Sie schreibt für diese beiden Fälle einen Versuchsparser, misst, was er sauber geschrieben verlangen würde, und hört bei der sechzehnten Stunde auf. Ein dritter im Stapel entdeckter Fall, die gruppierten Anzeigen, wurde nicht untersucht: Die Dauer lief ab, bevor die Liste der Fragen erschöpft war.

Die Zeile der Karte, die am meisten trägt, ist die letzte: Das Item verlässt den Vermerk "unbekannt" für 8 Punkte, was der Zweck der Ausgabe war. Die 16 Stunden liefern keine einzige lieferbare Codezeile.

Visualisierungen

Ein Spike wird zuerst über seine eigene Backlog-Karte sichtbar: zwei Spalten, die sich in zwei Schritten füllen, Ziel und Dauer bei der Eröffnung, Antwort und Entscheid bei der Schliessung. Über mehrere Iterationen geführt, zeigt diese Reihe von Karten, wo das Team seine Kapazität an die Untersuchung verliert und ob dieselben Unbekannten wiederkehren.

Der Ablauf wird als zwei parallele Bahnen gezeichnet. Die obere Bahn trägt den gewöhnlichen Fluss, vom Backlog-Item über die Arbeit der Iteration zum lieferbaren Inkrement. Die untere Bahn geht von einem Item aus, das das Team nicht schätzen kann, durchquert einen Kasten fester Breite mit dem Ziel und dem Typ und mündet dann wieder ins Backlog, indem sie eine Schätzung liefert. Kein Pfeil verbindet die untere Bahn mit dem Inkrement.

Aufwand

Werkzeuge

Die Wegwerfumgebung trägt den technischen Spike: ein eigenes Code-Repository, eine Sandbox beim Anbieter der Schnittstelle, ein für den Anlass aufgesetzter Container. Die Trennung vom Repository des Produkts macht es unmöglich, den Code des Prototyps versehentlich auszuliefern.

Das Werkzeug für das Backlog-Management (Jira, Azure DevOps, GitLab und ihre Entsprechungen) nimmt den Spike als vollwertiges Item auf, mit einem eigenen Typ oder einem Etikett. Das Budget in Stunden wird dort eingetragen; die Antwort und das neu geschätzte Item bleiben daran hängen, womit sich sechs Monate später nachvollziehen lässt, warum eine Zahl gewählt wurde.

Die Spezifikation des Anbieters und die Sätze von Beispielmeldungen entscheiden über die Qualität der Antwort, ebenso wie eine Messung an den tatsächlichen Volumen der Organisation. Ein Spike, der auf gelesener Dokumentation beruht, liefert eine Meinung; ein Spike, der auf ausgeführtem Code beruht, liefert eine Tatsache.

Quellen

• IIBA, Agile Extension to the BABOK Guide, §7.16 Spikes: der Zweck der Technik, der Auslöser eines Items, das sich nicht schätzen lässt, der explorative Charakter und der Ausschluss des lieferbaren Inkrements, die zwei Elemente Ziel und Typ, die innerhalb einer Iteration gesetzte Dauer, die drei Typen funktional, technisch und explorativ sowie die dort genannten Stärken und Grenzen, darunter die Fokussierung durch die Dauer, das gegenseitige Wissen zu Beginn der Teambildung, die zu lange Dauer oder das zu grosse Item, der missbräuchliche Gebrauch des Begriffs für Folgegespräche und der zu häufige Rückgriff, der auf ein mangelhaftes Refinement hinweist.
• IIBA, Agile Extension to the BABOK Guide, §7.0, Tabelle 7.0.1 Selecting the Right Technique: der Spike, eingeordnet unter den Techniken des Anforderungsmanagements, auf der Seite der internen Teams.
• Kent Beck mit Cynthia Andres, Extreme Programming Explained: Embrace Change, 2. Auflage, Addison-Wesley, 2004: die Herkunft des Begriffs und die spike solution, ein minimales Programm, das gebaut wird, um eine Entwurfsfrage zu beantworten, und danach verworfen wird.
• Mike Cohn, What Are Agile Spikes? When and Why Do Teams Use Spikes?, Mountain Goat Software: ein Katalog aus der Praxis, nicht normativ; der Spike selbst in Stunden beziffert, die als Beispiel genannte Grössenordnung und die Regel, die ihn extremer Ungewissheit vorbehält.