Spike Solutions (Spikes)

Bild: Wikimedia Commons / Rainer Flassig - CC BY-SA 2.0

Stellen wir uns folgende Situation vor: ein Product Owner (oder ein Mensch in vergleichbarer Rolle) kommt zu seinem Team. Er stellt ihm die neueste User Story vor, die auch von allen sofort verstanden wird. Als es dazu kommt eine Aufwandsschätzung abzugeben sind die Entwickler aber ratlos - die Umsetzung müsste in einer Technologie oder in einem System erfolgen mit denen sie noch nie gearbeitet haben. Ohne diese Erfahrungswerte können sie den Aufwand nur raten.

Im klassischen Projektmanagement würde man versuchen dieses Problem zu lösen inden man einem team-externen Experten die Aufwandsschätzung überlässt, z.B. einem Architekten, Lead Developer oder Business Analysten. In einem agilen Vorgehen wäre das aber keine gute Lösung, schliesslich soll die Aufwandsschätzung hier nach Möglichkeit von den Mitgliedern des umsetzenden Teams selbst kommen.¹ Wie versetzt man die also in die Lage das zu tun?

Eine Lösung dafür kommt aus dem Extreme Programming, dem Framework dem wir auch die User Story verdanken, und nennt sich Spike Solution (oft abgekürzt zu Spike). Sie besteht in Abgrenzung zur Perfect Solution oder Possible Solution, bei denen zumindest grundlegend klar ist wie gross der Aufwand ist und die direkt neue Funtionen erzeugen sollen.² Die Spike Solution soll das nicht, ihr Ziel ist es lediglich, die Entwickler mit der Technik vertraut zu machen.

But what if you haven't done anything like this story before? What if it's the beginning of the project and you haven't done anything at all? The answer is simple: do some experimenting. We call such an experiment a "Spike Solution" to remind us that the idea is just to drive through the entire problem in one blow, not to craft the perfect solution first time out. You need to know how long it will take you to do something.

Ron Jeffries and Chet Hendrickson, Extreme Programming Installed, S.55

Was Ron Jeffries und Chet Hendrickson, zwei der drei Erfinder von Extreme Programming, hier sagen streicht die entscheidenden Punkte heraus: wenn die Erfahrungswerte für eine Aufwandsschätzung zu gering sind können diese dadurch hergestellt werden, dass so lange Experimente mit der Anwendung durchgeführt werden bis die Vertrautheit gross genug für eine Schätzung ist. Um möglichst schnell an diesen Punkt zu kommen sollten diese Experimente, bzw. Spikes, möglichst klein sein.

In dem Buch aus dem sein Zitat stammt nennen die beiden auch Beispiele dafür. Eines besteht darin einem System einfache Rechenoperationen hinzuzufügen, ein anderes in der Änderung der Formatierung einer Zahl. Derartige Experimente sind in wkurzer Zeit abschliessbar, geben dem der sie durchführt aber trotzdem ein Gefühl davon wie aufwändig die Arbeit in diesem System ist. Falls das noch nicht reicht kann ein zweites oder drittes folgen, bis ein Grundverständnis da ist.

Wichtig ist dabei, dass der im Rahmen der Spikes erzeugte Code im Anschluss nicht weiterverwendet wird und stattdessen gelöscht werden kann. Nur so kann sichergestellt werden, dass nicht versehentlich etwas beschädigt wird und dass das Experiment dort stattfinden kann wo die Unklarheit am grössten ist. Den bereits erzeugten Code irgendwie weiterverwenden zu wollen ist zwar ein verständlicher Reflex, allerdings ist davon aus den genannten Gründen abzuraten.

Soviel zu den Warum und Wie einer Spike Solution, es bleibt aber noch eine Frage - warum eigentlich der Name? Er leitet sich ab von einem einfachen Stech-Werkzeug mit dem Löcher gebohrt werden können. In Analogie dazu ist es durch den Spike möglich in die "Black Box" des unbekannten Systems Löcher zu bohren, wodurch Licht in das Innere fällt, das dadurch sichtbar und begreifbar wird.