Jeż

Spike a Scrum, część 1

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 XP i powstała jako odpowiedź na dwa problemy, na które natrafia często zespół developerski:

  • 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, jako jedno lub kilka zadań, 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 nie pozwalający na jego dalsze użycie.

Różne rodzaje spike’ów

W literaturze spotyka się podział na spike techniczny oraz 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 więc 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 i wspiera ich proces decyzyjny – więc każdy jest z natury rzeczy „developerski”. Do idei spike’a „biznesowego” jeszcze się odniosę w dalszej części artykułu.

Cechy jakie ma dobry spike

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 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 podpowiada nam doświadczenie, coś chcemy potwierdzić lub wykluczyć. 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.

Różnica między spike a wymaganiem

W przypadku wymagania wiemy, co chcemy osiągnąć, a szacujemy (prognozujemy) jakiego wysiłku i czasu będzie to wymagać. Jeśli realizacja wymagania zabiera więcej czasu niż wynikało z prognoz, prace często i tak są kontynuowane, aż zostaną ukończone. Wyjątkiem są sytuacje, w których kontynuacja jest nieopłacalna, lub 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 co będzie możliwe do osiągnięcia w określonym czasie. I 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, ile 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. Natomiast krótkie sprinty umożliwiają skuteczne reagowanie na zmienność potrzeb, środowiska czy wykorzystywanej technologii.

Każda iteracja rozpoczyna się od prognozy tego, co będzie możliwe do osiągnięcia 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.

Czy to brzmi znajomo? Zespół podejmuje ograniczone czasowo działania, aby osiągnąć jakiś cel, opierając się na prognozie, że jest to możliwe, a wszystko po to, by uzyskać wiedzę niezbędną do podjęcia decyzji co dalej. Czy to nie spike? Oczywiście, że tak. Można więc powiedzieć, że każdy sprint w Scrumie to spike „biznesowy” (lub może raczej „produktowy”).

Spike developerski w czasie sprintu

W sytuacji, gdy zespół developerski 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 aby:

  • określić, czy element backlogu produktu jest w ogóle wykonalny w kontekście możliwości zespołu i technologii, którą się posługuje,
  • ocenić nakład pracy nad niektórymi z wymagań (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 taki spike ma sens wtedy, gdy zespół nie dysponuje wiedzą pozwalającą na jakiekolwiek 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 służy pozyskaniu 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 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 zespół spróbuje 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, który towarzyszy pracy w sprincie i zazwyczaj nie zabiera więcej, niż 10% czasu, jakim dysponują developerzy. Proces ten ma – między innymi – doprowadzić do tego, by zespół developerski był w stanie zaplanować realizację wymagań, które znajdują się na szczycie backlogu produktu podczas planowania sprintu.

Spike jest dobrym sposobem, by uzyskać wiedzę do tego niezbędną, ale trzeba racjonalnie z niego korzystać. Zespoły potrafią wpaść w pułapkę robienia spike dla każdego wymagania, przez co zamiast na realną pracę, poświęcają sporo czasu na przygotowanie się do niej. 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.

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 zespół na nie poświęci. Jeśli tak, rozsądnym podejściem będzie zdefiniowane tej pracy jako spike, który realizowany będzie w kolejnym sprincie.

Backlog sprintu czy produktu?

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 zespół realizuje w czasie sprintu (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 rozwiązaniem problemu technicznego lub usprawnieniami jest to oczywiste. A jeśli budowany jest prototyp jakiejś funkcjonalności? Wiele zespołów scrumowych 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 tego, czy Definition of Done będzie w czasie prac przestrzegane.

Jeśli prototyp powstaje na potrzeby zespołu developerskiego i niektóre wymogi Definition of Done intencjonalnie zostaną pominięte, wtedy praca nad nim nie powinna być definiowana w backogu 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 Definition of Done i na jego bazie 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 produktu (o ile Definition of Done zostanie rzeczywiście spełnione).

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 lub zrealizowane usprawnienie. Jest nią albo wiedza, która pozwala podejmować decyzje, albo 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 scrumowymi, 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 Definition of Done – oraz „na czysto” – gdy już wiadomo dokładnie, co i jak zrobić. Osobliwie najczęściej towarzyszy temu umieszczanie takich spike’ów „biznesowych” 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 tworzyć dokumentację a potem na jej bazie produkt, budujemy rozwiązanie dwukrotnie.

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ć Definition of Done. 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, co mamy…

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. 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 stanowi zobowiązanie (kontrakt), a nie prognozę itd.

A gdy czasami w tym niezdrowym procesie pojawi się jeszcze niewiadoma biznesowa, do jednego nieporozumienia związanego ze spike developerskim dołącza drugie – w postaci spike’a „biznesowego”…

Ciąg dalszy nastąpi

W kolejnej części artykułu napiszę 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ę podczas kalkulacji velocity.

Dodaj komentarz

%d bloggers like this: