Spike

Spike

Copyright ┬ę Shutterstock / Alexander Supertramp

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

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.
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

Kostenloser SEO-Check der OSG


Weitere Inhalte