Definicja
Spike to timeboxowane zadanie badawcze w Agile, którego celem jest zdobycie wiedzy potrzebnej do podjęcia decyzji lub oszacowania przyszłej pracy. Wynik spike'a to wiedza, nie kod.
Typy spike'ów
| Typ | Cel | Przykład |
|---|---|---|
| Technical Spike | Zbadanie rozwiązania technicznego | „Czy API banku obsługuje 3D Secure?" |
| Functional Spike | Zrozumienie wymagań biznesowych | „Jak działa proces reklamacji w dziale X?" |
Spike vs User Story
| Aspekt | Spike | User Story |
|---|---|---|
| Wynik | Wiedza, raport, rekomendacja | Działający kod |
| Estymacja | Timebox (np. 2 dni) | Story Points |
| Definition of Done | Pytanie ma odpowiedź | Funkcja działa |
| Demo | Prezentacja wniosków | Demo funkcjonalności |
Kiedy spike?
- Zespół nie potrafi oszacować story (zbyt duża niepewność)
- Nowa technologia - trzeba zrobić PoC
- Skomplikowana integracja - trzeba zbadać API
- Niejasne wymagania - trzeba porozmawiać z ekspertami
Dlaczego to ważne?
Spike to licencja na eksplorację - pozwala BA/zespołowi zbadać temat bez presji dostarczenia kodu. Chroni przed podejmowaniem decyzji na ślepo.
Co znaczy słowo spike i jak się o nim mówi po polsku?
W naszych materiałach słowo zostaje po angielsku: „spike" (czytane „spajk"), odmieniane z apostrofem, jak w definicji wyżej („wynik spike'a"). Kiedy ktoś szuka polskiego odpowiednika, padają trzy opisy tej samej rzeczy: „krótkie zadanie badawcze" (lekcja o INVEST w kursie Agile i Scrum), „ograniczone czasowo badanie" (minikurs o user stories) i „krótka iteracja badawcza" (wpis o pisaniu user stories). Wszystkie trzy mówią to, co najważniejsze: to badanie i ma z góry ustalony koniec.
Nazwa pochodzi z Extreme Programming, gdzie mówiło się o „spike solution", czyli możliwie najprostszym kawałku kodu, który sprawdza jedno rozwiązanie. Angielskie spike to kolec albo gwóźdź. Obraz jest trafny: wąsko i głęboko w jeden problem.
Dwa znaczenia, które łatwo pomylić z tym hasłem:
- spike testing to odmiana testów wydajnościowych, która sprawdza zachowanie systemu przy nagłych skokach ruchu - opisuje ją hasło o testowaniu wydajnościowym;
- spike na wykresie to po prostu nagły skok wartości, np. zgłoszeń albo ruchu na stronie.
W backlogu spike stoi obok innych typów elementów. Hasło o backlogu produktu wymienia go w jednej tabeli z user story, błędem, długiem technicznym i usprawnieniem, z przykładem „Zbadaj integrację z API banku".
Jak zapisać spike w backlogu, żeby dało się go zamknąć?
Góra hasła podaje Definition of Done spike'a: „Pytanie ma odpowiedź". To działa tylko wtedy, gdy pytanie zapisano tak, że odpowiedź da się rozpoznać. Hasło o Proof of Concept przypisuje analitykowi dokładnie tę robotę: sformułować pytanie i kryteria sukcesu, zanim ktokolwiek zacznie kodować. Przy spike'u wystarczy pięć pól:
| Pole | Co wpisać | Czego unikać |
|---|---|---|
| Pytanie | jedno pytanie, najlepiej z odpowiedzią tak/nie albo wyborem z listy opcji | „zbadać temat X" bez pytania |
| Decyzja, którą odblokuje | którą historyjkę da się po nim oszacować albo podzielić, jaki wybór zapadnie | spike, po którym nic się nie zmieni w backlogu |
| Timebox | limit czasu ustalony przed startem | „aż się wyjaśni" |
| Forma wyniku | notatka, rekomendacja, szkic, lista ryzyk | kod, który ma trafić na produkcję |
| Kto i z kim | kto bada i kogo może pytać | spike bez właściciela |
Przykład z minikursu o user stories, z lekcji o dzieleniu historyjek. Zespół MediFlow nie umie oszacować rezerwacji wizyty, bo nie wie, czy przy wizycie NFZ trzeba sprawdzić uprawnienia pacjenta w e-WUŚ. Spike w tej lekcji ma pytanie („czy do rezerwacji wizyty NFZ potrzebna jest weryfikacja uprawnień"), właściciela (Tomek z IT), krótki limit czasu i jasno nazwaną stawkę: „Wynik decyduje, jak podzielić resztę". Piąte pole, formę wyniku, lekcja podaje zdanie wcześniej: efektem spike'a jest „wiedza, nie funkcja".
Czym spike różni się od PoC, prototypu i MVP?
Wszystkie pięć to sposoby na kupienie wiedzy przed kolejną, większą inwestycją. Różni je pytanie, na które odpowiadają:
| Na jakie pytanie odpowiada | Co jest wynikiem | Hasło | |
|---|---|---|---|
| Spike | czego nie wiemy, żeby oszacować albo zdecydować? | odpowiedź na jedno pytanie | to hasło |
| Proof of Concept | czy to się w ogóle da zrobić? | potwierdzenie albo zaprzeczenie wykonalności | PoC |
| Proof of Value | czy to przynosi mierzalną korzyść? | wynik porównany z punktem wyjścia | PoV |
| Prototyp | jak użytkownik zareaguje na to rozwiązanie? | uwagi użytkowników do uproszczonej wersji | prototyp |
| MVP | czy ktoś tego chce? | reakcja pierwszych użytkowników na działający produkt | MVP |
Najcieńsza jest granica z PoC. Góra hasła wymienia PoC wśród powodów spike'a („Nowa technologia - trzeba zrobić PoC"), więc techniczny spike może przybrać formę PoC. W materiałach Analify to samo API systemu gabinetowego MediFlow pojawia się w obu rolach i dobrze pokazuje różnicę. Lekcja o dzieleniu historyjek w kursie Agile i Scrum stawia pytanie spike'a: czy API „w ogóle pozwala rezerwować z zewnątrz". Hasło o PoC stawia inne pytanie o to samo API: czy pozwala rezerwować sloty w czasie rzeczywistym, i ustala z góry kryterium sukcesu. Pierwsza odpowiedź mówi zespołowi, jak pociąć historyjkę. Druga mówi, czy architektura udźwignie wymaganie.
Kiedy analityk proponuje spike, a kiedy wystarczy rozmowa?
Minikurs o user stories, w lekcji o INVEST, podaje trzy powody, dla których zespół nie umie oszacować historyjki: za mało wiadomo, historyjka jest zbyt niejasna albo po prostu za duża. I dodaje: nieestymowalność to objaw, a „leczy się ją rozmową, doprecyzowaniem albo spike'em". Rozpisane na powody wygląda to tak (przypisanie lekarstw do powodów i rozdzielenie braku wiedzy na dwa przypadki to nasze rozpisanie; lekcja podaje tylko listę powodów i listę lekarstw, a podziału dużej historyjki wśród lekarstw nie wymienia):
- historyjka niejasna - doprecyzowanie, czyli zwykła praca analityka nad treścią i kryteriami akceptacji;
- historyjka za duża - podział, opisany w haśle o epiku;
- brakuje wiedzy, którą ktoś ma - rozmowa z tą osobą: właścicielem procesu, ekspertem, dostawcą;
- brakuje wiedzy, której nikt nie ma - tu dopiero spike, bo odpowiedź trzeba zdobyć: sprawdzić system, przeczytać dokumentację, przejrzeć dane albo przepisy.
Functional spike z tabeli wyżej („Jak działa proces reklamacji w dziale X?") też jest pracą analityka. Góra hasła wymienia wśród powodów spike'a także rozmowę z ekspertami. Nazwa spike ma sens wtedy, gdy zbadanie tematu wymaga więcej niż jednego pytania na spotkaniu i trzeba dla niego zarezerwować czas w sprincie.
Lekcja o dzieleniu historyjek z tego samego minikursu stawia granicę krótko: „Spike to wyjątek, nie domyślny ruch". Sięgasz po niego wtedy, gdy niepewność blokuje estymację. Odkładanie pisania historyjek to inny powód, którego lekcja wprost nie akceptuje. Lekcja o antywzorcach estymacji w kursie Agile i Scrum mówi, kto często musi tę niepewność nazwać: „to często TY musisz pierwszy powiedzieć »tego nie da się jeszcze wycenić, bo nie wiemy X«". Uczciwym wyjściem jest według niej karta „?" na planning pokerze, a po niej powrót historyjki do refinementu albo spike.
Czy spike wycenia się w story pointach?
Góra hasła odpowiada tabelą: spike ma timebox, historyjka ma story pointy. Uzasadnienie jest proste. Punkty opisują rozmiar pracy, której wynik zespół zna: wiadomo, co ma działać, pytanie brzmi, ile to kosztuje. Przy spike'u jest odwrotnie. Koszt jest znany z góry, bo wyznacza go limit czasu, a nieznany jest wynik.
Zespoły, które liczą velocity, muszą jeszcze ustalić, czy czas spike'ów wlicza się do tej liczby. Obie odpowiedzi da się obronić, byle zespół wybrał jedną i trzymał się jej w kolejnych sprintach. Inaczej velocity z kolejnych sprintów przestaje być porównywalna. Szerzej o velocity pisze wpis o estymacji, podlinkowany niżej. Dla analityka ważniejsze jest co innego: spike zajmuje część pojemności sprintu, więc na sprint planningu trzeba go widzieć tak samo jak każdą historyjkę.
Nie każda niepewność potrzebuje spike'a. Czasem wystarczy nazwać ryzyko wprost. Lekcja o antywzorcach estymacji podaje taką formułę przy antywzorcu „bufor na buforze": estymata z dopiskiem, ile urośnie praca, jeśli API nie wspiera filtrowania, czyli „ryzyko nazwane wprost zamiast schowane w liczbie". Użycie tej formuły zamiast spike'a to nasze zastosowanie, lekcja mówi o buforach.
Co jest wynikiem spike'a i co z nim zrobić po zakończeniu?
Góra hasła mówi: wiedza, raport, rekomendacja, a na demo prezentacja wniosków. Zanim spike zamkniesz, sprawdź, czy wynik trafił w cztery miejsca:
- Odpowiedź zapisana przy elemencie backlogu. Tam przeczyta ją każdy, kto później weźmie historyjkę, także gdy osoba, która badała, będzie na urlopie.
- Decyzja o historyjkach. Nowa estymata, podział albo rezygnacja. Hasło o epiku opisuje historyjkę, która dostaje trzynaście punktów przez nieznaną bibliotekę, a po spike'u spada do trójki.
- Wniosek w wymaganiach. Jeśli spike odkrył ograniczenie, staje się ono wymaganiem albo ryzykiem. Hasło o PoC pokazuje to na tym samym API: odkryty limit zapytań wszedł do wymagań jako konieczność kolejkowania żądań.
- Kod wyrzucony. Lekcja o dzieleniu historyjek w kursie Agile i Scrum opisuje spike trzema czasownikami: „zbadać, odpowiedzieć, wyrzucić kod". I kończy zdaniem: „Spike kupuje wiedzę, nie funkcję."
Odpowiedź „nie da się" albo „nie opłaca się" też zamyka spike. Hasło o timeboxingu opisuje podobny, ograniczony czasem research w MediFlow, zakończony decyzją zarządu, żeby nie wchodzić w integrację z zewnętrznym portalem. Z tej wiedzy nie powstała żadna funkcja, a mimo to rozstrzygnęła sprawę.
Jakie błędy popełnia się przy spike'ach?
- Spike bez pytania. Hasło o PoC nazywa ten sam błąd przy PoC: bez pytania to „zabawa technologią". Po timeboxie nikt nie umie powiedzieć, czy spike się udał.
- Timebox przedłużany, bo już prawie wiadomo. Hasło o timeboxingu opisuje tę pomyłkę wprost: sens limitu polega na tym, że wymusza decyzję na podstawie tego, co już wiadomo.
- Kod ze spike'a na produkcji. Pisany był po to, żeby odpowiedzieć na pytanie. Lekcja o dzieleniu historyjek w kursie Agile i Scrum każe go wyrzucić.
- Spike jako sposób na odłożenie analizy. Gdy po serii spike'ów w kolejnych sprintach nadal nie ma historyjek, sprawdź, czy brakująca wiedza nie leży po stronie biznesu. Wtedy potrzebna jest rozmowa z właścicielem procesu (to nasza obserwacja, nie reguła z kursu).
- Brak spike'a tam, gdzie był potrzebny. We wpisie o retrospektywie projektu przy jednej z kotwic zespół zapisuje wniosek: „Nie zbadaliśmy API dostawcy przed estymacją". Działanie przypisane analitykowi: dodać spike badania integracji do checklisty estymacji.
Gdzie iść dalej
- Estymacja i jej granice: story points, planning poker, timeboxing, wpis Estymacja w analizie biznesowej.
- Historyjki, które spike odblokowuje: user story, INVEST, epik, wpis User stories - jak pisać.
- Miejsce spike'a w backlogu: backlog produktu, refinement, Definition of Ready, wpis Prowadzenie backlogu.
- Sposoby sprawdzania pomysłów: Proof of Concept (PoC), Proof of Value, prototyp, MVP; skąd nazwa: Extreme Programming.
- Sprawdź się bez zakładania konta: test z estymacji i priorytetyzacji.
Jeśli chcesz przećwiczyć dzielenie historyjek i estymację na jednym case'ie, załóż darmowe konto: dostajesz pierwszą lekcję każdego kursu, trzy podejścia do testów w miesiącu i plan na 30 dni.