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. W sumie stanowi Backlog Sprintu, który podlega codziennej inspekcji i adaptacji w miarę, jak ujawnia się to, o czym Zespół nie wiedział w trakcie 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).

Developerzy mogą 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ń (ang. task), jakie należy wykonać w Sprincie (na wszelki wypadek przypominam: praktyka taka nie jest częścią Scruma i jest w nim opcjonalna). Część tych zadań związana będzie z pracą nad elementami Backlogu Produktu podjętymi do realizacji, część z implementacją usprawnień, a pozostałe będą służyć wywiązaniu się z dowolnych innych obowiązków, jakie spoczywają na Developerach w tym Zespole. Można potraktować każde z takich zadań jako niewielki spike, określając jego timebox.

Z pozoru wydaje się to niczym innym jak wezwaniem do typowego 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:

• timeboxy chronią Developerów przed ciągnięciem w nieskończoność prac, które prowadzą donikąd,
• kłopot z ukończeniem zadania przed końcem timeboxu sygnalizuje potencjalne problemy i konieczność adaptacji planów dalszego działania,
• krótkie timeboxy stymulują Developerów do częstego sprawdzania postępu prac.

Całkiem często pojawiają się dodatkowe korzyści, choć to zależy od specyfiki konkretnego Zespołu.

Pierwszy: Developerzy mogą zacząć dekomponować pracę w ten sposób, by każde zadanie dawało realny postęp w Sprincie i by żadne z nich nie trwało dłużej niż jeden dzień. To pozwala na skuteczniejsze przeprowadzanie Daily Scrumów, bo większość prac udaje się kończyć w czasie pomiędzy kolejnymi spotkaniami.

I drugi: zadania w formie spike’ów wskazują cel, jaki Developerzy spodziewają się osiągnąć przed końcem timeboxu, zamiast konkretnych czynności, jakie muszą zostać wykonane. Nie dość, że tworzenie takich zadań jest prostsze i szybsze (bo nie trzeba przewidywać, jak w detalach przebiegał będzie development), to są one bardziej skupione na uzyskiwaniu postępu 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 pojawiają się pytania, na które (już w Sprincie) poszukać trzeba odpowiedzi. Developerzy mogą dokonać oceny ryzyka, jakie się z tym wiąże i dla kwestii, które są krytyczne, zdefiniować kilka spike’ów, a następnie zrealizować je na początku iteracji. Pozwoli to uzyskać w określonym (krótkim) czasie niezbędnych odpowiedzi i potwierdzić (albo obalić) poczynione założenia.

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.

Oczywiście wymaga to dojrzałości w stosowaniu spike’ów, bo zdarza się, że praktyka ta jest nadużywana. Developerzy w niektórych Zespołach potrafią poświęcić mnóstwo czasu w każdym Sprincie na wyjaśnianie wszelkich niejasności (nawet tych mało istotnych), w efekcie czego za późno zabierają się za faktyczną pracę nad osiągnięciem Celu Sprintu i development odbywa się w trybie chaotycznej walki z czasem.

Planując taki spike (lub całą ich serię) należy zawsze dokonać oceny opłacalności 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 i samych Developerów. 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 słowa: output i outcome. Z faktu, że zbudowaliśmy jakiś produkt (czyli że istnieje output procesu) wcale nie wynika, że ten produkt nada się do tego, do czego miał służyć (czyli że uzyskamy oczekiwany outcome). Z faktu, że ludzie uzyskali określone velocity (które jest miarą outputu) 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 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ć, czym 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ć Deweloperzy są zajęci, nie wynika z tego dużo wartości (wspomnianego outcome’u).

Degradacja poziomu praktyk

Zespoły mogą zachłysnąć się spike’ami i zacząć ich nadużywać, co ma zwykle dwie formy:

1. Developerzy poprzedzają realizację każdego (lub większości) elementu Backlogu Produktu budową prototypowego rozwiązania,
2. Developerzy w ramach pielęgnacji Backlogu Produktu za pomocą spike’ów szukają odpowiedzi na wszystkie pytania i próbują wyeliminować potencjalne problemy.

Nadużywanie prototypowania powoduje, że rozwój produktu staje się powolny i kosztowny. Skutkuje to jednak nie tylko marnotrawstwem (bo wszystko robione jest dwukrotnie), ale może spowodować obniżenie poziomu stosowanych praktyk developerskich. W jaki sposób?

Developerzy zaczynają funkcjonować w dwóch trybach: spike’owania i rzeczywistego budowania produktu. Ten pierwszy tryb najczęściej nie wymaga przestrzegania Definicji Ukończenia i dopuszcza budowanie rozwiązań na kolanie. Ten drugi polega wtedy na powtórzeniu czynności już wcześniej wykonanych, ale tym razem z dbałością o jakość.

Może dojść do osmozy sposobu działania z etapu prototypowania na następującą po nim faktyczną realizację elementów Backlogu Produktu. Takie równanie do najniższego wspólnego mianownika w stosowaniu praktyk technicznych i narzędzi developerskich może doprowadzić do tego, że w końcu i w trybie rzeczywistego budowania produktu Developerzy wytwarzać będą umieć wyłącznie wybrakowane buble.

Utrata zwinności w działaniu

Jeszcze groźniejsze jest przyzwyczajenie Developerów do realizacji tylko takich zmian w produkcie, o których wszystko „wiadomo na pewno”. W ramach pielęgnacji Backlogu Produktu realizują dużą liczbę spike’ów, aby uzyskać w wyniku tego możliwość „dobrego zaplanowania Sprintów”. Czasami (rzadko) faktycznie udaje się to osiągnąć, ale nawet wtedy jest nieopłacalne.

Developerzy przyzwyczajeni do realizowania wyłącznie takich zmian w produkcie, do których są dobrze przygotowani, zatracają zdolność radzenia sobie z rozwiązywaniem niespodziewanych problemów. A te mogą wystąpić niezależnie od ilości przygotowań i intensywności spike’owania, jakie poprzedziło development. W skrajnym przypadku Zespół Scrum dochodzi do punktu, w którym używa Sprintów wyłącznie po to, by zrealizować poczynione wcześniej plany, a i to pod warunkiem, że jest pewien ich powodzenia. To nie ma wiele wspólnego ze Scrumem i empiryczną kontrolą procesu.

Kluczowe do zwinnego działania jest wykształcenie w największym możliwym stopniu zdolności szybkiego reagowania na zmianę, również w trakcie developmentu. W ten sposób np. rozwiązania techniczne czy architektura są tworzone w taki sposób, by dało się łatwo i szybko w sposób bezpieczny dokonywać nawet dużych zmian, jeśli pojawi się taka konieczność. Zespół, który uzależni się od spike’ów, nie będzie w stanie tego zrobić, bo systemowo kreuje rozwiązania „dobrze przemyślane”, czyli skomplikowane i trudne do zmiany.

Zadanie domowe dla Scrum Masterów

Każdy Zespół Scrum, nawet taki bardzo dojrzały, może podjąć błędne decyzje, które ostatecznie popchną go w złą stronę. Coś, co wydaje się dobrym narzędziem, niewprawnie użyte zacznie szkodzić. Spike jest taką właśnie praktyką, która może potencjalnie doprowadzić do pojawienia się i rozrośnięcia fazy analizy, która jest czymś typowym dla klasycznych metod projektowych, ale nie powinna występować w Scrumie.

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

• Sprawdź, czy każdy spike ma określony czas trwania i jasny cel, dla którego jest podejmowany, a jeśli trzeba, pomóż w takim ich definiowaniu.
• Jeśli timeboxy poszczególnych spike’ów są długie (dni albo tygodnie zamiast godzin) lub jeśli spike potrafi trwać przez kilka Sprintów, omów z Zespołem, czym właściwie jest spike.
• Sprawdź, czy ludzie rozumieją, że w Scrumie nie chodzi o „uzyskanie wysokiego velocity”, „wykonanie dużej ilości pracy”, ani nawet „dowożenie dużej ilości zmian w produkcie”, 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 w usprawnieniu działania Zespołu.
• 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 rozwiązania).
• Upewnij się, że Zespół (nie tylko Developerzy w nim) rozumie, co jest celem pielęgnacji Backlogu Produktu (podpowiadam: nie jest nim zaplanowanie, w jaki sposób zrealizować zmiany w produkcie) i jak spike może być użyty do jego osiągnięcia.
• Jeśli pielęgnacja Backlogu Produktu ma często formę spike’ów, sprawdź, czy nie jest to emanacją dążenia do uzyskania pewności odnośnie do sposobu realizacji zmian w produkcie, 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.