Spike
Als Spike bezeichnet man eine notwendige Maßnahme bei der Methode Scrum. Der Spike wird notwendig, wenn das Team nicht genug Informationen oder Erfahrungen hat, um eine realistische Schätzung eines Projekts vorzunehmen. Schätzungen wiederum sind eine Möglichkeit, den Umfang und die Inhalte eines Scrum Projektes zu planen.
Ein Spike kann auch dann entstehen, wenn dem Team das Verständnis für die Komplexität des Projekts fehlt. Ein Spike kann eine sinnvolle Schätzung zur Folge haben, einen sinnvollen Storyschnitt oder auch zu keiner Lösung führen.
Allgemeine Informationen zum Thema
Ein Spike sollte grundsätzlich die Ausnahme sein, die nur zum Einsatz kommt, wenn das Team sich hinsichtlich der Komplexität nicht einigen kann, die Story als zu komplex angesehen wird bzw. fachlich nicht mehr geschnitten werden kann und wenn bezüglich der groben Umsetzung des Projekts im Team keine Einigkeit erzielt werden kann.
Die wesentlichen Merkmale eines Spikes sind a) die zeitliche Begrenzung, b) dass es sich um eine experimentelle Lösung handelt, die durch alle Layer gehen kann, c) dass er am Schluss immer verworfen und d) dass mit dem Ende eine Dokumentation des Spikes erfolgt[1].
Ablauf des Spikes
Im Laufe des Spikes (oder auch: Design-Spikes) erproben die Mitglieder des Scrum-Teams (das kann auch ein einzelnes Mitglied übernehmen) denkbare Lösungen oder erstellen ein Proof of Concept. Unter einem Proof of Concept wird im Projektmanagement ein Meilenstein verstanden, durch den die grundlegende Durchführbarkeit eines Vorhabens belegt wird. Dabei können sowohl positive als auch negative Machbarkeitsnachweise erbracht werden. Mit dem Proof of Concept (das auch Proof of Principle genannt wird) ist in der Regel die Entwicklung eines Prototyps verbunden, der über die notwendige Kernfunktionalität verfügt[2].
Während der am Spike beteiligte Teil des Teams arbeitet, befassen sich die nicht beteiligten Teammitglieder im Zuge eines Sprints an User Storys bzw. User Cases, die außerhalb des Problemfeldes liegen. Im Zusammenspiel kann der aktuelle Sprint in seiner Dauer flexibel gestaltet, also beispielsweise verkürzt werden, um so zeitnah auf die Ergebnisse, die der Spike gebracht hat, reagieren zu können.
Je nach Voraussetzungen kann der Spike auch größer gefasst werden. Stellt sich zum Beispiel heraus, dass die Software ganz oder teilweise innerhalb der vorliegenden Architektur nicht auf Dauer wartbar ist, kann der Spike für die Identifikation neuer Konzepte genutzt werden. Das Team muss dabei jedoch den Rahmen innerhalb von Scrum nicht verlassen.
Wenngleich Spike häufig bei Scrum verwendet wird, kommt es nicht ursprünglich dorther. Im Zusammenhang mit Extreme Programming (XP) wird Spike auch bei Rape Prototyping oder beim inkrementellen Design verwendet[3].
Wie es zum Spike kommt
Im besten Fall ist die User-Story so aufgebaut, dass eine realistische Schätzung über ein Projekt abgegeben werden kann. Ist die Story zu groß, muss sie verfeinert oder geschnitten werden. Das ist auch dann sinnvoll, wenn innerhalb einer User-Story mehrere weitere Storys verborgen sind. Das Schneiden von User-Storys gelingt am besten mit dem INVEST-Prinzip von Bill Wake oder den sogenannten „Patterns for Splitting User Storys“ von Richard Lawrence.
Damit eine User-Story funktioniert, muss sie nach Bill Wake unabhängig, verhandelbar, schätzbar, testbar, klein und von Wert sein. Die gleichen Eigenschaften müssen beim Schneiden von User-Storys vorhanden sein.
Praktischer ausgerichtet ist das Pattern nach Richard Lawrence, wenngleich die Frage nach dem richtigen Schneidungsmuster unbeantwortet bleibt. Die Ausnahme bildet hier das Herausbrechen von Spikes (Pattern #9). Wenn das Entwicklungsteam an der User-Story scheitert, weil nicht genügend Kenntnisse vorhanden sind bzw. die weiter oben beschriebenen Probleme auftreten, kann ein Spike aus dem Product Backlog herausgebrochen werden, was bedeutet, dass eine Story erstellt wird, die die inhaltliche Analyse des unbekannten Sachverhalts liefert. Im nächsten Sprint wird die eigentliche User-Story betrachtet und auf der Grundlage der gewonnenen Erkenntnisse kann eine bessere Schätzung vorgenommen werden[4].
Bedeutung für das Development
Für die Problemlösung bei der Softwareentwicklung ist Spike mit der Möglichkeit, eine zeitlich begrenzte User-Story zu schaffen, ein sinnvolles und hilfreiches Instrument. Dabei werden wichtige Informationen gesammelt, die das Ziel verfolgen, ein lieferbares Produkt zu entwickeln.
Für das Projektmanagement bedeutet Spike bessere und verlässlichere Einschätzungen der User Storys sowie ein besseres Verständnis für die User-Story an sich. Auch die Anforderungen eines Product Backlog Items werden durch Spikes klarer[5].
Einzelnachweise
- ↑ Scrum Definitionen hs-augsburg.de. Abgerufen am 14.02.2018
- ↑ Proof of Concept de.wikipedia.org. Abgerufen am 14.02.2018
- ↑ Architektur und Scrum Ablauf ramonanger.wordpress.com. Abgerufen am 14.02.2018
- ↑ Requirements Engineering und -Management sophist.de. Abgerufen am 14.02.2018
- ↑ scrum lexikon spike agile-academy.com. Abgerufen am 14.07.2020