Blog

W poprzednich artykułach (część pierwsza i część druga) pisałem o tym, czym jest spike developerski i jak podejść do szacowania związanej z nim pracy. Na koniec kilka praktycznych porad jak używać spike’ów. Mam też zadanie dla czytających ten artykuł Scrum Masterów.

Spike w sprincie

Planowanie sprintu owocuje zdefiniowaniem celu sprintu, sformułowaniem prognozy tego, co uda się zrealizować, oraz pierwszą wersją planu działania (a więc backlogiem sprintu). Ten plan podlega codziennej adaptacji w miarę, jak ujawnia się to, o czym zespół nie wiedział podczas planowania. Innymi słowy każdy sprint planowany jest z większym lub mniejszym prawdopodobieństwem, że nie wszystko uda się zrealizować, dlatego jego długość jest ograniczona – do maksymalnie miesiąca – co pozwala kontrolować ryzyko (ewentualne straty).

Zespół developerski może wykorzystać spike aby mitygować ryzyko w czasie sprintu. Opiszę dwa z kilku rozwiązań, z jakimi się spotkałem – mam nadzieję, że zainspirują czytelników do popatrzenia z innej perspektywy na sposób organizacji pracy w ich zespołach.

Zadanie jako spike

Częstą praktyką jest tworzenie przez developerów zadań („tasków”) dla poszczególnych wymagań realizowanych w sprincie (na wszelki wypadek przypominam: praktyka ta jest opcjonalna w Scrumie). Można potraktować każde z takich zadań jako spike, określając jego timebox.

Z pozoru wydaje się to niczym innym jak wezwaniem do typowego i dobrze znanego szacowania zadań w godzinach, ale podobieństwo jest pozorne. Nie chodzi bowiem o przewidywanie ile czasu zajmie realizacja takich zadań, ale o zdefiniowanie po jakim czasie dokonamy oceny, czy idziemy w dobrą stronę. Takie podejście ma trzy zalety:

• zapewnia stały dopływ empirycznych danych do zespołu (do wykorzystania na przykład w czasie Daily Scruma),
• zapobiega „utonięciu” developerów w realizacji jakiegoś zadania,
• stymuluje dyskusję potrzebną do skutecznej adaptacji backlogu sprintu.

Zespół uczy się w ten sposób całkiem szybko jak dekomponować pracę na takie etapy, które dają realny postęp w sprincie.

Spike jako punkt wyjścia do osiągnięcia celu sprintu

W czasie planowania sprintu podejmowanych jest wiele decyzji opartych na przewidywaniu lub założeniach, a nierzadko z wymaganiami związane są pytania, na które (już w sprincie) poszukać trzeba odpowiedzi. Zespół może dokonać oceny ryzyka, jakie się z tym wiąże i dla kwestii, które okażą się krytyczne, zdefiniować spike (jeden lub kilka), które zrealizowane zostaną na początku iteracji. Celem powinno być uzyskanie w określonym (krótkim) czasie niezbędnych odpowiedzi i potwierdzenie założeń.

Takie podejście pozwala szybko odkryć problem, którego ujawnienie zbyt późno w sprincie uniemożliwiłby skuteczną reakcję ze strony zespołu. Efektem jest zwiększenie szansy na osiągnięcie celu sprintu. O ile, rzecz jasna, praktyka nie przybierze niezdrowej formy, w której wszystkie niewiadome i wątpliwości (nawet mało istotne) developerzy próbują wyjaśnić na początku sprintu, w efekcie czego może braknąć czasu na zrealizowanie samych wymagań.

Planując taki spike (lub całą ich serię) należy zawsze dokonać oceny ryzyka i mieć na względzie ustalony cel sprintu.

Konsekwencje złego użycia spike’ów

Każda praktyka może być użyta w niewłaściwy sposób, dotyczy to również spike’ów. Nie istnieje też jeden dobry, jedynie słuszny sposób, w jaki powinny być stosowane. Wszystko zależy od potrzeb i możliwości zespołów developerskich. Warto jednak wskazać kilka typowych pułapek, w które wpadają one korzystając ze spike’ów.

Pozorna produktywność

W poprzednim artykule pisałem o bezzasadności szacowania spike’ów developerskich w story pointach i uwzględniania pracy nad nimi w kalkulacji velocity. Wróćmy do tego tematu na moment i spójrzmy na niego z nieco innej perspektywy.

W języku angielskim funkcjonują dwa piękne słowa: „output” i „outcome”. Z faktu, że zbudowaliśmy jakiś produkt (jest „output” procesu) wcale nie wynika, że ten produkt nada się do tego, do czego miał służyć (czyli że uzyskamy „outcome”). Z faktu, że ludzie uzyskali określone velocity („output”) nie wynika, że powstało cokolwiek nadającego się do użycia („outcome”).

Jeśli w Scrumie mówimy o uzyskiwaniu wartości, to należy ją rozumieć jako pozyskiwanie owego „outcome’u”. Ktoś, kogo uwiera, że na velocity nie złożyło się wszystko, co zespół robił w sprincie, i traktujący velocity jako wartość samą w sobie, powinien jeszcze raz spróbować zrozumieć jak Scrum działa i dlaczego jest stosowany. Powinien też sięgnąć do podstaw i zrozumieć, co to jest empiryzm (Scrum Masterze, czy twój zespół to rozumie?).

Skutkiem szacowania spike’ów developerskich i dodawanie ich do velocity może być uzyskanie poczucia, że to, co robi zespół, jest wartościowe i sensowne nawet w sytuacji, gdy zajmował się on będzie głównie szlifowaniem rozwiązań od strony technologicznej i prototypowaniem. To jedna z form wykazywania pozornej produktywności, bo choć zespół jest zajęty, nie wynika z tego dużo wartości (wspomnianego „outcomu”).

Utrata zwinności w działaniu

A co dzieje się, gdy nadużywamy spike’ów i robimy ich za dużo? Ma to miejsce najczęściej w dwóch przypadkach, występujących czasami jednocześnie:

1. zespół developerski poprzedza realizację każdego (lub większości) wymagań budową prototypowego rozwiązania,
2. zespół developerski w ramach pielęgnacji backlogu produktu poświęca czas na rozstrzygnięcie wszystkich problemów technicznych.

Nadużywanie prototypowania, poza tym że skutkuje marnotrawstwem (bo wszystko robione jest dwukrotnie), może skutecznie osłabić praktyki developerskie. Zespół zaczyna funkcjonować w dwóch trybach: spike’owania i rzeczywistego budowania produktu. Ten pierwszy tryb najczęściej nie wymaga przestrzegania Definition of Done i dopuszcza budowanie rozwiązań „na szybko”.

Może dojść do osmozy sposobu działania z etapu prototypowania na następującą po nim realizację wymagań. Takie równanie do najniższego wspólnego mianownika w stosowaniu praktyk technicznych i narzędzi developerskich może doprowadzić do tego, że nawet w trybie „produkcyjnym” developerzy wytwarzać będą potrafili wyłącznie wybrakowane buble.

Dużo groźniejsze jest przyzwyczajenie zespołu do realizacji tylko takich wymagań, w których wszystko „wiadomo na pewno”. Dążenie do uzyskania odpowiedzi na wszystkie pytania i rozwiązania wszystkich znanych problemów w ramach pielęgnacji backlogu produktu implikuje dużą ilość pracy developerskiej w formie spike’ów. Celem jest uzyskanie bardziej przewidywalnego przebiegu sprintów i ten pożądany skutek bywa czasami osiągany, co zdawałoby się wskazywać na sensowność takiego działania.

Niestety, taka pielęgnacja jest czasochłonna, a zespół zatraca umiejętność szybkiego rozwiązywania problemów. Sprinty przebiegają bardzo sprawnie tylko wtedy, gdy nie zdarzy się nic niespodziewanego, wymuszającego istotną zmianę przyjętego na początku sposobu postępowania. Te, w których to nastąpi, najczęściej kończą się brakiem ukończenia czegokolwiek.

Kluczowe do zwinnego działania jest wykształcenie w największym możliwym stopniu zdolności szybkiego reagowania na zmianę. Nie sprzyja temu utonięcie w serii spike’ów dających pozorną pewność, że wszystko „wiadomo na pewno”.

Zadanie domowe dla Scrum Masterów

Nie musi od razu ziścić się któryś z czarnych scenariuszy opisanych powyżej – trzeba tylko pamiętać, że ryzyko osunięcia się ku nim będzie rosło z narastaniem „fasadowych” dowodów na to, że zespół działa sensownie. Zespół (tak developerski, jak i cały scrumowy) może bowiem przekroczyć barierę, za którą przestaje dostrzegać, że powoli degraduje jakość produktu, albo że rozrasta mu się faza analizy (której przecież wcale nie miało być w Scrumie).

Jeśli twój zespół korzysta ze spike’ów developerskich, warto by robił to dobrze. Dlatego:

• sprawdź, czy każdy spike ma określony czas trwania i jasny cel, dla którego jest realizowany – pomóż w doprowadzeniu, by tak były definiowane,
• jeśli timeboxy poszczególnych spike’ów są długie (dni albo tygodnie zamiast godzin), lub wręcz jeśli spike potrafi trwać przez kilka sprintów, omów z zespołem koncept spike,
• sprawdź, czy ludzie rozumieją, że w Scrumie nie chodzi o „dostarczenie velocity”, ani o „robienie dużo”, ani nawet „dowożenie”, ale o uzyskanie wartości,
• zapytaj tych, co chcą szacować spike developerski w story pointach (lub w inny sposób normalnie używany dla elementów backlogu produktu) jak pomoże to działać empirycznie lepiej, niż bez tej estymaty,
• zapytaj też, co jest celem takiego szacowania oraz jaką wartość i dla kogo ten cel ma,
• jeśli spike uwzględniany jest w velocity (o ile je liczycie) wspólnie pomyślcie jakie mogą być negatywne efekty takiego postępowania (podpowiadam jeden: pojawi się pokusa, żeby robić spike przed większością trudnych wymagań przy jednoczesnym dążeniu do tego, aby velocity wyglądało ładnie),
• również wspólnie zastanówcie się, czy jest możliwe, że spike użyty zostanie jako łatwiejsza alternatywa dla jakiegoś lepszego (ale trudniejszego i wymagającego więcej wysiłku) rozwiązania (podpowiadam: łatwiej robić prototypy i je potem „dopracowywać” niż bez prototypów budować wartościowe przyrosty produktu),
• upewnij się, że zespół (scrumowy, nie tylko developerski) rozumie, co jest celem pielęgnacji backlogu (podpowiadam: nie jest nim zaplanowanie w jaki sposób zrealizować wymagania) i jak spike może być do tego użyty,
• jeśli pielęgnacja backlogu produktu ma często formę spike’ów sprawdź, czy nie jest to emanacją dążenia do uzyskania pewności jak zrealizować poszczególne wymagania jeszcze nim rozpocznie się planowanie prac nad nimi.

Wiedza, jak jest (w szczególności, jeśli jest źle, lub gdy pojawiają się niekorzystne trendy) daje możliwość dokonania usprawnień. A jeśli zespół nie korzysta ze spike’ów? Warto o nich porozmawiać mimo to, bo znajomość tej praktyki i sposobów jej wykorzystywania, na pewno okaże się przydatna.

Część 1 Część 2