Alai

Wenn wir wüssten, was wir tun, würden wir es nicht Forschung nennen.

-Albert Einstein

Spikes sind eine Art von Exploration Enabler Story in SAFe. Ursprünglich in Extreme Programming (XP) definiert, repräsentieren sie Aktivitäten wie Forschung, Design, Untersuchung, Exploration und Prototyping. Ihr Zweck ist es, das notwendige Wissen zu erlangen, um das Risiko eines technischen Ansatzes zu reduzieren, eine Anforderung besser zu verstehen oder die Zuverlässigkeit einer Story-Schätzung zu erhöhen.

Wie andere Stories werden Spikes geschätzt und dann am Ende der Iteration demonstriert. Sie bieten auch ein vereinbartes Protokoll und einen Arbeitsablauf, den Agile Release Trains (ARTs) verwenden, um die Durchführbarkeit von Epics zu bestimmen.

Agile und Lean schätzen Fakten gegenüber Spekulationen. Wenn sie mit einer Frage, einem Risiko oder einer Ungewissheit konfrontiert werden, führen Agile Teams kleine Experimente durch, bevor sie zur Implementierung übergehen, anstatt über das Ergebnis zu spekulieren oder eine Lösung zu wählen. Teams können Spikes in einer Vielzahl von Situationen einsetzen:

• Schätzen Sie neue Funktionen und Fähigkeiten, um das implizite Verhalten zu analysieren, und erhalten Sie so Einblicke in den Ansatz für die Aufteilung in kleinere, quantifizierbare Teile
• Durchführen von Machbarkeitsanalysen und anderen Aktivitäten, die helfen, die Durchführbarkeit von Epen zu bestimmen
• Grundlagenforschung betreiben, um sich mit einer neuen Technologie oder Domäne vertraut zu machen
• Vertrauen in einen technischen oder funktionalen Ansatz gewinnen, Verringerung des Risikos und der Unsicherheit

Spikes beinhalten die Erstellung eines kleinen Programms, einer Forschungsaktivität oder eines Tests, der einen Aspekt der neuen Funktionalität demonstriert.

Technische und funktionale Spikes

Spikes gibt es hauptsächlich in zwei Formen: technisch und funktional.

Funktionale Spikes – Sie werden verwendet, um das Gesamtverhalten der Lösung zu analysieren und zu bestimmen:

• Wie man sie aufschlüsseln kann
• Wie man die Arbeit organisieren kann
• Wo Risiken und Komplexität bestehen
• Wie man Erkenntnisse nutzen kann, um Implementierungsentscheidungen zu beeinflussen

Technische Spikes – Sie werden verwendet, um verschiedene Ansätze im Lösungsbereich zu untersuchen. Zum Beispiel:

• Entscheiden Sie sich für eine Build-versus-Buy-Entscheidung
• Evaluieren Sie die potenziellen Leistungs- oder Lastauswirkungen einer neuen User Story
• Evaluieren Sie spezifische technische Implementierungsansätze
• Entwickeln Sie Vertrauen in den gewünschten Lösungspfad

Einige Features und User Stories können beide Arten von Spikes erfordern. Hier ein Beispiel:

„Als Verbraucher möchte ich meinen täglichen Energieverbrauch in einem Histogramm sehen, damit ich meinen vergangenen, aktuellen und voraussichtlichen Energieverbrauch schnell verstehen kann.“

In diesem Fall könnte ein Team beide Arten von Spikes erstellen:

• Ein technischer Spike, um zu untersuchen, wie lange es dauert, eine Kundenanzeige auf den aktuellen Verbrauch zu aktualisieren, um die Kommunikationsanforderungen und die Bandbreite zu ermitteln und um zu entscheiden, ob die Daten gepusht oder gezogen werden sollen
• Ein funktionaler Spike – Prototyp eines Histogramms im Webportal und Einholen von Benutzerfeedback zu Darstellungsgröße, -stil und -diagramm

Richtlinien für Spikes

Da Spikes dem Benutzer keinen direkten Nutzen bringen, sollten Sie sie sparsam einsetzen. Es gelten die folgenden Richtlinien.

Quantifizierbar, nachweisbar und akzeptabel

Wie andere Stories werden Spikes in das Team Backlog aufgenommen, geschätzt und so dimensioniert, dass sie in eine Iteration passen. Spike-Ergebnisse unterscheiden sich von einer Story, da Spikes typischerweise Informationen und keinen funktionierenden Code produzieren. Die Ergebnisse eines Spikes sind sowohl für das Team als auch für alle anderen Stakeholder nachweisbar, was die Forschungs- und Architekturbemühungen sichtbar macht und auch dazu beiträgt, kollektives Eigentum und gemeinsame Verantwortung für die Entscheidungsfindung aufzubauen. Der Product Owner akzeptiert Spikes, die vorgeführt wurden und seine Akzeptanzkriterien erfüllen.

Timing von Spikes

Da sie eine Unsicherheit in einer oder mehreren potenziellen Stories darstellen, ist es manchmal riskant, sowohl den Spike als auch die daraus resultierenden Stories in der gleichen Iteration zu planen. Wenn es sich jedoch um ein kleines und einfaches Problem handelt und eine schnelle Lösung wahrscheinlich ist, kann es recht effizient sein, beides in derselben Iteration zu erledigen.

Die Ausnahme, nicht die Regel

Jede Benutzergeschichte birgt Ungewissheit und Risiken; das liegt in der Natur der agilen Entwicklung. Das Team findet die richtige Lösung durch Diskussion, Zusammenarbeit, Experimentieren und Verhandlung heraus. In gewissem Sinne enthält also jede User Story spike-ähnliche Aktivitäten, um die technischen und funktionalen Risiken zu identifizieren. Das Ziel eines agilen Teams ist es, in jeder Iteration zu lernen, wie man mit der Unsicherheit umgeht. Spikes sind von entscheidender Bedeutung, wenn eine hohe Unsicherheit besteht oder es viele Unbekannte gibt.

Mehr erfahren

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.

Letzte Aktualisierung: 10. Februar 2021