Alai

Gdybyśmy wiedzieli, co robimy, nie nazywałoby się to badaniami.

-Albert Einstein

Spikes są rodzajem eksploracji Enabler Story w SAFe. Zdefiniowane początkowo w Extreme Programming (XP), reprezentują działania takie jak badania, projektowanie, dochodzenie, eksploracja i prototypowanie. Ich celem jest zdobycie wiedzy niezbędnej do zredukowania ryzyka podejścia technicznego, lepszego zrozumienia wymagania lub zwiększenia wiarygodności oszacowania historii.

Podobnie jak inne historie, Spikes są szacowane, a następnie demonstrowane na końcu iteracji. Zapewniają one również uzgodniony protokół i przepływ pracy, który Agile Release Trains (ARTs) wykorzystują, aby pomóc w określeniu wykonalności epiki.

Agile i Lean cenią fakty ponad spekulacje. W obliczu pytania, ryzyka lub niepewności zespoły Agile przeprowadzają małe eksperymenty przed przejściem do wdrożenia, zamiast spekulować na temat wyniku lub przeskakiwać do rozwiązania. Zespoły mogą używać kolców w różnych sytuacjach:

• Oszacuj nowe Cechy i Zdolności, aby przeanalizować implikowane zachowanie, zapewniając wgląd w podejście do dzielenia ich na mniejsze, policzalne kawałki
• Przeprowadź analizę wykonalności i inne działania, które pomagają określić wykonalność epopei
• Przeprowadź podstawowe badania, aby zapoznać je z nową technologią lub domeną
• Zyskaj zaufanie do podejścia technicznego lub funkcjonalnego, zmniejszając ryzyko i niepewność

Spikes obejmują tworzenie małego programu, działalności badawczej lub testu, który demonstruje jakiś aspekt nowej funkcjonalności.

Techniczne i funkcjonalne Spikes

Spikes występują głównie w dwóch formach: technicznej i funkcjonalnej.

Spajki funkcjonalne – Służą do analizy ogólnego zachowania rozwiązania i określenia:

• Jak je rozbić
• Jak zorganizować pracę
• Gdzie występuje ryzyko i złożoność
• Jak wykorzystać spostrzeżenia, aby wpłynąć na decyzje wdrożeniowe

Spajki techniczne – Służą do badania różnych podejść w domenie rozwiązania. Na przykład:

• Determinowanie decyzji build-versus-buy
• Ocena potencjalnej wydajności lub wpływu obciążenia nowej historyjki użytkownika
• Ocena konkretnych technicznych podejść wdrożeniowych
• Rozwijanie pewności co do pożądanej ścieżki rozwiązania

Niektóre funkcje i historyjki użytkownika mogą wymagać obu typów kolców. Oto przykład:

„Jako konsument, chcę zobaczyć moje dzienne zużycie energii w histogramie, abym mógł szybko zrozumieć moje przeszłe, bieżące i przewidywane zużycie energii.”

W tym przypadku, zespół może stworzyć oba rodzaje skoków:

• Spike techniczny do badania, jak długo trwa aktualizacja wyświetlacza klienta do bieżącego zużycia, określania wymagań komunikacyjnych, szerokości pasma oraz tego, czy dane mają być przesyłane w trybie push czy pull
• Spike funkcjonalny – Prototyp histogramu w portalu internetowym i uzyskanie informacji zwrotnej od użytkownika na temat rozmiaru prezentacji, stylu i tworzenia wykresów

Wskazówki dotyczące spajków

Ponieważ spajki nie dostarczają bezpośrednio wartości dla użytkownika, używaj ich oszczędnie. Zastosowanie mają następujące wytyczne.

Quantifiable, Demonstrable, and Acceptable

Podobnie jak inne historyjki, Spikes są umieszczane w Backlogu zespołu, szacowane i wymiarowane tak, aby zmieściły się w iteracji. Wyniki spajków różnią się od historii, ponieważ spajki zazwyczaj produkują informacje, a nie działający kod. Powinny one opracowywać tylko niezbędne dane, aby zidentyfikować i zwymiarować historie, które je napędzają w sposób pewny.

Wyniki spajków są możliwe do zademonstrowania, zarówno dla zespołu, jak i dla wszystkich innych interesariuszy, co zapewnia widoczność wysiłków badawczych i architektonicznych, a także pomaga budować zbiorową własność i współodpowiedzialność za podejmowanie decyzji. Właściciel Produktu akceptuje kolce, które zostały zademonstrowane i spełniają jego kryteria akceptacji.

Timing kolców

Ponieważ reprezentują one niepewność w jednej lub więcej potencjalnych historiach, planowanie zarówno kolca, jak i wynikających z niego historii w tej samej iteracji jest czasami ryzykowne. Jednakże, jeśli jest to małe i proste, a szybkie rozwiązanie jest prawdopodobne do znalezienia, wtedy może być całkiem wydajne, aby zrobić obie rzeczy w tej samej iteracji.

Wyjątek, nie reguła

Każda historia użytkownika ma niepewność i ryzyko; taka jest natura rozwoju Agile. Zespół odkrywa właściwe rozwiązanie poprzez dyskusję, współpracę, eksperymenty i negocjacje. Tak więc, w pewnym sensie, każda historyjka użytkownika zawiera działania typu spike, aby zidentyfikować ryzyko techniczne i funkcjonalne. Celem zespołu Agile jest nauczenie się jak radzić sobie z niepewnością w każdej iteracji. Kolce są krytyczne, gdy istnieje wysoka niepewność lub jest wiele niewiadomych.

Learn More

Leffingwell, Dean. Zwinne wymagania programowe: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.

Ostatnia aktualizacja: 10 lutego 2021

.