Spike

Was ist ein Spike?

Im Kontext der Agile Softwareentwicklung ist ein Spike definiert als eine Geschichte oder Aufgabe, die darauf abzielt, eine Frage zu beantworten oder Informationen zu sammeln, anstatt ein lieferbares Produkt zu produzieren. Seinen Ursprung hat der Begriff Spike im Extreme Programming (XP) und repräsentiert Aktivitäten wie Forschung, Design, Exploration und Prototyping. Der Zweck eines Spikes besteht darin, das notwendige Wissen zu erwerben, um das Risiko eines technischen Ansatzes zu verringern, eine Anforderung besser zu verstehen oder die Zuverlässigkeit einer Schätzung für die Softwareentwicklung zu erhöhen.

Ein Spike kann als eine Art von User Story angesehen, die beispielsweise bei der Softwareentwicklung nach der Scrum-Methode verwendet wird, um eine Frage zu beantworten, Informationen zu sammeln, eine spezifische Grundlagenforschung durchzuführen, Projektrisiken zu adressieren oder eine große User Story aufzuteilen. Grundsätzlich werden Spikes zur Behebung von Unsicherheiten verwendet, indem spezifische Informationen gesammelt werden, um eine funktionale oder technische Anforderung zu verstehen. Zum Beispiel, wenn das Team ein spezifisches technisches Problem lösen muss oder nicht genug Informationen hat, um die User Story zu schätzen.

Technische und funktionelle Spikes

Spikes werden in technische und funktionelle Spikes unterschieden:

Funktionale Spikes

Diese Spikes werden verwendet, um das allgemeine Lösungsverhalten zu analysieren und zu bestimmen. Wenn beispielsweise eine erhebliche Unsicherheit darüber besteht, wie ein Benutzer mit dem System interagieren könnte. Funktionale Spikes werden oft durch ein gewisses Maß an Prototyping evaluiert, sei es durch Benutzerschnittstellenmodelle, Hardware-Prototypen, Page Flows oder andere Techniken, die geeignet sind, Rückmeldungen vom Kunden oder von Stakeholdern zu erhalten.

Technische Spikes

Sie werden verwendet, um verschiedene Ansätze für eine Lösung innerhalb eines Projektes zu erforschen. Beispielsweise können technische Spikes verwendet werden, um eine Build-versus-Buy-Entscheidung zu treffen, die potenzielle Leistung oder Lastauswirkung einer neuen User Story zu bewerten oder, um bestimmte Implementierungstechnologien zu evaluieren, die auf eine Lösung angewendet werden können. Technische Spikes werden eingesetzt, wenn das Team ein selbstbewussteres Verständnis für einen gewünschten Ansatz entwickeln muss.

Timing und Handhabung von Spikes

Ein Spike sollte während der Sprint-Planung als In-Sprint-Aufgabe geschätzt werden. Da Spikes Ungewissheit in einer oder mehreren potenziellen Geschichten darstellen, kann es riskant sein, sowohl die Spikes, als auch die daraus resultierenden Storys in derselben Iteration zu planen. Wenn die Ungewissheit jedoch klein ist und eine schnelle Lösung wahrscheinlich gefunden wird, kann es sehr effizient sein, beides in der gleichen Iteration abzuarbeiten. Dies kann ein funktionierendes Stück Software, ein Arbeitsablauf oder eine Dokumentation sein. Prototypen, Proof of Concepts (PoC) und Wireframes fallen in die Klassifizierung von Spikes.

Spikes werden wie User Storys behandelt. Ziel ist die Informationsgewinnung und nicht ein direkter Nutzwert. Ein Unterschied zwischen einem Spike und einer typischen User Story ist, dass sie nicht geschätzt, sondern zeitlich begrenzt werden. Statt einer Schätzung verpflichtet sich das Team, eine bestimmte Menge Zeit für die Durchführung der notwendigen Forschung zu investieren. Nach dem Ablauf der Zeit-Box wird die Original-Geschichte basierend auf den Informationen, die während der Zeit gesammelt und erarbeitet wurden, neu gestaltet, gepflegt, aufgeteilt oder neu geschrieben.

Wenn das Team schätzt, dass ein Spike vier Stunden benötigt, dann sollten nur vier Stunden für Forschung oder Entwicklung aufgewendet werden. Die Zeitbox des Spikes muss lang genug sein, um die im Spike gestellte Frage zu beantworten. Nach der Aufnahme in den Sprint sollte die Teamarbeit, die für die Spike-Zeitbox benötigt wird, effektiv genutzt werden.

Anwendungsrichtlinien für Spikes

Spikes sollten schätzbar, nachweisbar und akzeptabel sein. Spikes sollten immer die Ausnahme und nicht die Regel sein. Sie sollten sparsam verwendet werden, da sie keinen direkten Wert liefern. Wie andere Storys werden Spikes in das Team-Backlog aufgenommen, geschätzt und so bemessen, dass sie in eine Iteration passen. Sie sollten dem Projektstau hinzugefügt und priorisiert werden. Das Team sollte nur die notwendigen Daten entwickeln oder sammeln, um die Geschichte zu identifizieren und zu bestimmen. Am Ende des Sprints müssen die Ergebnisse demonstriert werden.

Der Output eines Spike ist sowohl für das Team als auch für alle anderen Beteiligten nachweisbar. Dadurch werden die Forschungs- und Architekturbemühungen sichtbar gemacht. Dies trägt dazu bei, kollektive Verantwortung für die Entscheidungsfindung aufzubauen. Der Product Owner akzeptiert in den meisten Fällen Spikes, die demonstriert wurden und die Akzeptanzkriterien erfüllen. Doch, wie bei allen anderen Storys kann das Resultat der Demo sein, dass die Ergebnisse der Spikes entweder akzeptiert oder abgelehnt werden. Und, ein Spike erzeugt fast immer eine neue Story.

Tipp

Entwicklerteams müssen ein praktikables Werkzeug an der Hand haben, um mit dem, was sie nicht wissen, umgehen zu können. Wenn jedoch jede Story einen Spike braucht, ist das ein Hinweis auf ein grundlegendes Problem im Team oder im Projekt. Ein Spike ist ein ernst zu nehmendes Werkzeug für Teams, um Wissen zu gewinnen und zu bestimmen, wie ein Risiko gemindert werden kann. Spikes können genutzt werden, um zu validieren, dass ein technischer Ansatz möglich ist, oder zu entscheiden, wie eine User Story zu schätzen ist.

Sie haben noch Fragen?

Kontaktieren Sie uns