Spike a Scrum, część 1
Czym jest developerski spike, jaki ma związek z wymaganiami i w jaki sposób użyć go w Scrumie, aby przyniósł korzyści.
Tematem, który powraca do mnie niczym bumerang, jest spike, a dokładnie sposób użycia tej praktyki w Scrumie. Osobliwie dyskusja prawie zawsze dotyczy nie tego, jak realizować spike, ale czy w ogóle umieszczać go w Backlogu Produktu, szacować tak jak pozostałe elementy (na przykład user stories), uwzględniać przy kalkulacji velocity…
Co to jest spike?
Zacznijmy od wyjaśnienia, czym spike jest. Praktyka ta wywodzi się z metody Extreme Programming (w skrócie XP) i powstała jako odpowiedź na dwa problemy, na które natrafiają często Zespoły:
- niedoboru wiedzy niezbędnej do podjęcia decyzji,
- konieczności zredukowania ryzyka poprzez weryfikację kluczowych założeń.
W praktyce spike realizowany jest przez Developerów w ramach ściśle ustalonego przedziału czasowego (timebox). Te działania mogą obejmować, między innymi, niektóre (a czasami wszystkie) z wymienionych poniżej czynności:
- zbudowanie prostego prototypu rozwiązania dla jakiegoś problemu,
- przetestowanie prototypu,
- symulację specyficznych warunków działania dla istniejącego rozwiązania i sprawdzenie skutków,
- przetestowanie stanu (jakości, kompletności, dostępności etc.) wszystkiego, co ma być użyte do wytworzenia rozwiązania,
- ocena możliwości, jakie dają różne technologie i narzędzia developerskie,
- potwierdzenie lub wykluczenie istnienia zależności między różnymi rozwiązaniami budowanymi niezależnie od siebie,
- sprawdzenie, że planowane rozwiązanie nie będzie kolidować z rozwiązaniami już istniejącymi,
- zapoznanie się z architekturą istniejącego rozwiązania lub komponentów, które mają być użyte do jego budowania.
Spike nie służy wytworzeniu docelowych rozwiązań, a jedynie pozyskaniu wiedzy niezbędnej do tego. Tym samym, nawet jeśli powstaje prototyp, jest on zwykle wykonywany w sposób niepozwalający na jego dalsze użycie.
Różne rodzaje spike’ów
W literaturze spotyka się podział na spike techniczny oraz spike funkcjonalny. Ten pierwszy służy przede wszystkim ocenie wpływu technologii na to, co robimy – wykorzystywany jest więc do pozyskania wiedzy niezbędnej do dokonywania wyborów technologicznych i kształtowania architektury. Można powiedzieć, że jest przede wszystkim poszukiwaniem odpowiedzi na pytanie „w jaki sposób budować rozwiązanie?”.
Funkcjonalny spike natomiast wykorzystywany jest do pozyskiwania wiedzy niezbędnej do zaprojektowania rozwiązania, a dokładniej sposobu działania tego rozwiązania. Inaczej mówiąc, ma dostarczyć odpowiedzi na pytanie „jakie rozwiązanie należy zbudować?”.
Czasami natknąć można się na nazywanie spike technicznego developerskim a funkcjonalnego biznesowym – nie ma w tym niczego nagannego, ale takie określenia mogą wprowadzać w błąd. Spike wymaga zawsze pracy Developerów, więc jest z natury rzeczy developerski. Do idei spike’a biznesowego jeszcze się odniosę w dalszej części artykułu.
Cechy dobrego spike’a
Przede wszystkim musi mieć określony czas trwania, timebox. Powinien obejmować raczej kilka godzin niż dni, ponieważ ma służyć rozwiązaniu specyficznego (najczęściej niewielkiego) problemu i wspierać podjęcie jakiejś decyzji. Spike trwający kilka tygodni nie jest więc czymś pożądanym ani efektywnym.
Konieczne jest też określenie celu spike’a. Wraz z timeboxem zabezpiecza to Zespół przed utonięciem w niekończącej się eksploracji, która przez wiele dni jest „o krok od celu”, a która w praktyce nie da realnych wyników. W momencie, gdy czas przydzielony na realizację spike się kończy, Developerzy mogą dokonać sprawdzenia jego efektów. Jeśli cel został osiągnięty to świetnie. Jeśli nie – to również jest istotna informacja. Wiedza pozyskana w czasie realizacji spike’a oraz przyczyny, dla których nie udało się osiągnąć celu, pozwala świadomie zaplanować dalsze działania (być może kolejny spike).
Działanie w ciemno
Specyficznym rodzajem spike’a jest alokacja czasu na eksplorację w ciemno jakiegoś rozwiązania tylko po to, by uzyskać więcej wiedzy. Powinien on być naprawdę krótki, to oczywiste. Natomiast jak ustalić dla niego cel, skoro dopiero pozyskujemy podstawową wiedzę?
Każde działanie, nawet to podejmowane zupełnie po omacku, wynika z jakiejś potrzeby. Nawet wtedy, gdy z pozoru nic nie wiemy, najczęściej potrafimy wskazać obszar największego ryzyka, mamy jakieś podejrzenia, które chcemy sprawdzić, coś próbujemy wykluczyć itd. To pozwala realizować spike tak, by do tego ryzyka (lub podejrzeń) wprost się odniósł.
Jeśli i to jest niemożliwe, celem spike’a w naturalny sposób powinno stać się uzyskanie maksymalnej ilości danych pozwalających na zaplanowanie kolejnego kroku. Skoro spike robimy w kontekście konkretnej potrzeby lub problemu, który ma zostać rozwiązany, celem powinno być ustalenie przynajmniej jednej konkretnej rzeczy z tą potrzebą (problemem) wprost związanej.
Czym różni się spike od wymagania
W przypadku wymagania wiemy, co chcemy osiągnąć, a prognozujemy, jakiego wysiłku i czasu będzie to wymagać. Jeśli realizacja wymagania okazuje się trudniejsza, niż wskazywały prognozy, zazwyczaj development i tak jest kontynuowany. Rzadziej zdarza się, że prace są przerywane, bo ich kontynuacja jest nieopłacalna. Zwykle ma to miejsce wtedy, gdy ujawni się przeszkoda, której nie da się w racjonalny sposób pokonać.
Zupełnie odwrotnie działa to w przypadku spike’a. Definiując go, dokonujemy oszacowania tego, co będzie możliwe do osiągnięcia w określonym czasie. Praca kończy się zgodnie z ustaleniami niezależnie od tego, czy osiągnięty został cel, czy też nie. Inaczej mówiąc, wiadomo z góry, jak długo spike potrwa, ale nie wiadomo na pewno, co przyniesie. Spike jest więc lustrzanym odbiciem wymagania.
Spike w Scrumie
Scrum to metoda (framework) pozwalająca rozwiązywać złożone problemy w warunkach dużej zmienności i nieprzewidywalności. Rozwiązania te budowane są w Sprintach (krótkich iteracjach) przyrostowo: najpierw powstaje najprostsza wersja, która jest następnie rozbudowywana krok po kroku. Ograniczony zakres zmian w każdej iteracji pozwala radzić sobie z nieprzewidywalnością, bo prognozy dotyczą niewielkiego obszaru produktu i są krótkoterminowe. Z drugiej strony krótkie Sprinty umożliwiają skuteczne reagowanie na zmienność potrzeb, środowiska czy wykorzystywanej technologii.
Każda iteracja rozpoczyna się od sporządzenia prognozy tego, co zostanie zrealizowane przed jej zakończeniem. Inaczej mówiąc, stawiana jest hipoteza, że jakiś problem da się rozwiązać i że będzie z tego płynęła wartość. Podobnie jak w przypadku każdego eksperymentu, tak i ten mający formę Sprintu w Scrumie może zakończyć się potwierdzeniem hipotezy, lub jej obaleniem.
Jednym zdaniem: Zespół podejmuje ograniczone czasowo działania, aby osiągnąć jakiś cel, opierając się na prognozie, że przyniosą one empiryczną wiedzę niezbędną do podjęcia decyzji odnośnie do sposobu dalszego rozwoju produktu. Czy to aby nie brzmi znajomo? Zupełnie, jakby każdy Sprint stanowił swoisty rodzaj spike’a? Oczywiście, że tak. Można powiedzieć, że każda iteracja w Scrimie to spike biznesowy (lub może raczej produktowy).
Spike developerski w czasie Sprintu
W sytuacji, gdy Zespół (a przede wszystkim Developerzy w nim) potrzebuje rozpoznać teren przed podjęciem jakiegoś elementu Backlogu Produktu do realizacji w Sprincie, może przeprowadzić spike dostarczający niezbędnej wiedzy.
Kiedy stosować spike?
Najczęściej Zespół używa spike’ów, aby:
- określić, czy element Backlogu Produktu jest w ogóle wykonalny z wykorzystaniem bieżących możliwości Developerów i technologii, którą się posługują,
- ocenić nakład pracy nad niektórymi z elementów Backlogu Produktu (najczęściej z obszaru słabo znanego Developerom),
- wykryć zależności i ewentualne przeszkody w realizacji, które trzeba usunąć przed rozpoczęciem prac.
Oczywiście każdy taki spike ma sens wtedy, gdy nikt w Zespole faktycznie nie dysponuje wiedzą pozwalającą na żadne prognozy. Dzieje się tak na przykład wtedy, gdy rozpoczyna się migracja do nowej technologii lub gdy Developerzy po raz pierwszy stykają się z jakimś komponentem technologicznym, systemem biznesowym etc. Spike pozwala na określenie podstawowych punktów odniesienia, by uzyskać minimum przewidywalności niezbędnej do planowania Sprintów i działania w nich.
Innym scenariuszem, gdy spike może być użyty, to sprawdzenie dwóch równorzędnych, ale wykluczających się koncepcji rozwiązania problemu. Zamiast prowadzić długotrwałe dyskusje i analizy, szybciej można dokonać wyboru jednej z dróg, porównując, która z nich w tym samym czasie (na przykład kilku godzin) pozwala osiągnąć więcej.
Czasami konieczne jest zweryfikowanie zależności albo choćby potwierdzenie, że komponent dostarczony przez inną firmę lub Zespół rzeczywiście działa, nim Developerzy spróbują go użyć w Sprincie. Użyty w tym celu spike nie potrwa długo i ma jak najbardziej sens.
Pielęgnacja Backlogu Produktu
Spike developerski w Scrumie jest jednym z możliwych działań podejmowanych w ramach pielęgnacji Backlogu Produktu. Pielęgnacja to proces doskonalenia elementów Backlogu nie tylko przez Product Ownera (dla którego jest to podstawowym obowiązkiem), ale cały Zespół. W szczególności dzięki pielęgnacji Developerzy poznają elementy Backlogu Produktu na tyle, by móc później zaplanować ich realizację w Sprintach.
Spike pozwala na praktyczną weryfikację różnych założeń i pomysłów na to, jak dokonać zmian w produkcie, ale trzeba racjonalnie z niego korzystać. Zespoły potrafią wpaść w pułapkę robienia spike’ów dla każdego elementu Backlogu Produktu, żeby „wiedzieć na pewno”, w jaki sposób można je zrealizować i ile to potrwa. Poświęcają na to mnóstwo czasu i dyskusyjnym jest, czy to jeszcze pielęgnacja Backlogu Produktu, czy też już nieformalna implementacja poszczególnych jego elementów.
Pamiętać też trzeba, że spike nie ma za zadanie dostarczyć odpowiedzi na wszystkie pytania, ani tym bardziej dostarczyć działającego rozwiązania dla potrzeby biznesowej, a przede wszystkim dostarczyć wiedzy niezbędnej do podjęcia kluczowych decyzji.
Usprawnienia
Zdarza się, że w ramach Retrospekcji Sprintu Zespół zaplanował usprawnienie, które wymaga przetestowania nowego narzędzia, sprawdzenia możliwości użycia jakiegoś rozwiązania, lub przeprowadzenia jakiejkolwiek szeroko rozumianej eksploracji przez Developerów. Prace te mogą (i nawet powinny) wymagać określenia limitów czasu, który Developerzy na nie poświęcą. Jeśli tak, rozsądnym podejściem będzie zdefiniowane tej pracy jako spike i zrealizowanie go w kolejnym Sprincie.
Przy czym uwaga: taki spike nie powinien być traktowany jako rozwój produktu, tylko jako część procesu developerskiego albo wysiłek na rzecz rozwoju Zespołu jako takiego. Inaczej mówiąc, traktowanie go jak „kolejny element Backlogu Produktu” byłoby błędem, bo taki spike nigdy przecież w Backlogu Produktu się nie znajdzie.
Backlog Sprintu czy Produktu?
Ano, właśnie. Naturalnym miejscem, w którym spike developerski może się znaleźć, jest Backlog Sprintu. Backlog ten opisuje pracę związaną z osiągnięciem Celu Sprintu, wytworzeniem produktu, ale też wszystkie inne działania, które Developerzy realizują w czasie iteracji (na przykład wdrożenie usprawnień z Retrospekcji Sprintu poprzedniego).
Spike developerski nie może być definiowany jako element Backlogu Produktu, jeśli jego realizacja nie wpływa na cechy produktu ani nie zmienia jego funkcjonalności. W przypadku spike’a związanego z kwestiami czysto technicznymi lub usprawnieniami jest to oczywiste. A co jeśli budowany jest prototyp jakiejś funkcjonalności? Wiele Zespołów Scrum definiuje w tym celu osobny element w Backlogu Produktu (w porozumieniu z Product Ownerem). Czy tak można? Odpowiedź nie jest jednoznaczna, bo zależy od powodu, dla którego wytwarzane jest prototypowe rozwiązanie, oraz od tego, czy w trakcie prac nad nim stosowana będzie Definicja Ukończenia.
Jeśli prototyp powstaje na potrzeby Developerów i niektóre wymogi Definicji Ukończenia intencjonalnie zostaną pominięte, wtedy praca nad nim nie powinna być definiowana w Backlogu Produktu, a jedynie w Backlogu Sprintu. Jeśli dodatkowo ustalony zostanie timebox na jej wykonanie, powstanie z tego zgrabny spike.
Natomiast jeśli prototyp budowany jest zgodnie z obowiązującą Definicją Ukończenia i na jego podstawie (poprzez dalszy rozwój) może potencjalnie być wytworzone docelowe rozwiązanie, Product Owner powinien umieścić stosowny element w Backlogu Produktu. W rozumieniu Scruma taki prototyp będzie pełnoprawnym Przyrostem, o ile wymogi Definicji Ukończenia zostaną rzeczywiście zaspokojone.
Wartość spike’a developerskiego
Czy zrealizowany spike developerski dostarcza wartość? Można powiedzieć, że tak – ale jest to taki sam rodzaj wartości, jaką daje nam każda inna forma pielęgnacji Backlogu Produktu lub zrealizowane usprawnienie. Jest nią albo wiedza, która pozwala podejmować decyzje, albo nowe możliwości pozwalające na skuteczniejsze działanie. Lub obie te rzeczy na raz.
Spike nie dostarcza natomiast wartości rozumianej jako nowe cechy lub funkcjonalności produktu, nawet jeśli jest z tym produktem ściśle związany.
Spike’owe nieporozumienie
Co jakiś czas stykam się z Zespołami Scrum, które stosują spike jako narzędzie do prototypowania przed niemal każdą zmianą, jaką realizują w produkcie. Każda rzecz robiona jest wtedy dwa razy: na brudno – jako prototyp, najczęściej z pominięciem niektórych wymogów zawartych w Definicji Ukończenia – oraz na czysto – gdy już wiadomo dokładnie, co i jak zrobić. Osobliwie najczęściej towarzyszy temu umieszczanie takich spike’ów w Backlogu Produktu, co – jak pisałem wcześniej – najczęściej jest działaniem niewłaściwym w Scrumie.
W praktyce dochodzi wtedy do odtworzenia fazy analizy znanej z metod predyktywnych i to w wybitnie ciężkiej formie, bo zamiast poprzestać na stworzeniu analiz, dokumentacji i planów, budujemy do tego od razu działające rozwiązanie. Trochę tak, jakby dla oszacowania czasu podróży z Krakowa do Gdańska wybrać się do Trójmiasta i z powrotem, a potem twierdzić, że to ma sens, bo dzięki temu „wiadomo na pewno”, ile zajmie przejechanie tej trasy, gdy już wyjazd do Gdańska oficjalnie nastąpi.
Inspiracją do zastosowania takiego podejścia jest najczęściej potrzeba uzyskania „pełnej przewidywalności” (w prawdziwie złożonym świecie nieosiągalnej). Uczestnicy tej kosztownej zabawy łudzą się, że budowanie byle jak na brudno quasi-prototypów pozwoli wiedzieć na pewno, jak zrobić docelowe rozwiązanie i ile to potrwa.
Skutkiem takiej praktyki jest wypłukanie empiryzmu z procesu, bo prototyp (zrobiony najczęściej byle jak) daje jedynie złudzenie, że „na pewno” da się go doszlifować i spełnić wymogi Definicji Ukończenia. Innym skutkiem jest użycie prototypu zamiast produktu, najczęściej pod presją czasu: skoro mamy już coś działającego i terminy naglą, to może na razie użyjmy tego produktu, jakim dysponujemy…
Takie postępowanie ma często miejsce tam, gdzie Scruma próbuje się używać do szybszego (niż w klasycznych metodach projektowych) realizowania z góry zdefiniowanej listy wymagań, bez intencji poszukiwania wartości i stosowania przy tym empiryzmu. Sprinty mają wtedy służyć zakończeniu kolejnego etapu w projekcie i muszą (sic!) się udać albo misternie poukładany plan się sypie. Niezbędne są oczywiście precyzyjne oszacowania, Planowanie Sprintu kończy się zawarciem kontraktu na dostarczenie kolejnych rzeczy, a nie stworzeniem prognozy wartości, jaką Zespół chce uzyskać itd.
Ciąg dalszy
W kolejnej części cyklu piszę o tym, czy warto przypisywać do spike’a developerskiego oszacowania (na przykład w story pointach), oraz jak (i czy w ogóle) uwzględniać jego realizację przy wyliczaniu velocity.