W ramach kontynuacji cyklu o przekłamaniach, nadinterpretacjach i mitach, którymi obrósł Scrum, pora pochylić się nad tym, co nawymyślano na temat monitorowania postępów prac w Sprincie, Backlogu Sprintu oraz Definicji Ukończenia i Przyrostu.
Zachęcam też do sięgnięcia do trzech wcześniejszych artykułów. Można je czytać w dowolnym porządku, ale zachęcam do lektury po kolei: część pierwsza, część druga i część trzecia.
Mit 31: należy sporządzać wykres spalania pracy w Sprincie
Dawno temu wykresy spalania Backlogu Produktu oraz Backlogu Sprintu były popularne i wedle niektórych interpretacji ówczesnych zapisów Scrum Guide nawet obowiązkowe w Scrumie. Do dziś nie brakuje osób, które o tej obowiązkowości są przekonane.
Scrum faktycznie wymaga monitorowania postępu prac nad osiąganiem Celu Produktu oraz – w trakcie iteracji – Celu Sprintu. Nie jest określony sposób, w jaki Zespół ma to robić, więc może posłużyć się dowolnymi narzędziami lub praktykami, które uznaja za właściwe. Wykresy spalania nie są obowiązkowe, a ja dodam, że nie są też przesadnie użyteczne (napisałem kiedyś cały artykuł na ten temat).
Mit 32: należy mierzyć prędkość osiąganą przez Zespół
Prędkość, czyli velocity, to suma oszacowań elementów Backlogu Produktu, które zostały w pełni ukończone w rozważanym przedziale czasowym, np. w Sprincie
Czy velocity może być obowiązkową miarą? Nie, choćby z tego powodu, że aby ją wyliczyć, niezbędne jest szacowanie elementów Backlogu Produktu i to w formie wycen numerycznych, aby dało się je sumować. A, jak pisałem w pierwszej części cyklu, komentując mit numer 6, Scrum nie wymaga szacowania jako takiego.
Wyliczenie prędkości nijak zresztą nie pomoże Zespołowi w monitorowaniu postępu prac w Sprincie i lepszym kontrolowaniu procesu developerskiego. W praktyce może (ale nie musi) przydać się do sporządzania prognoz dat realizacji elementów Backlogu Produktu i bywa używane w trakcie Planowania Sprintu, ale nie ma żadnego obowiązku posługiwania się nim, o czym pisałem części drugiej, omawiając mit 18.
Mit 33: Zespół musi posługiwać się tablicą scrumową
Wiele Zespołów sięga po tablice w różnej formie, na których w mniej lub bardziej udany sposób wizualizuje to, co dzieje się w Sprincie. Najczęściej takie tablice wizualizują zarówno Backlog Sprintu, jak i np. wykresy różnych miar, nieszczęsny wykres spalania, listę utrudnień, nad których usunięciem pracuje Zespół itd.
Jest to na tyle powszechne, że w wielu organizacjach panuje wiara w obowiązkowość takich wizualizacji. Tymczasem Scrum niczego podobnego nie wymaga. Istnieje obowiązek zapewnienia przejrzystości, ale w jaki sposób postulat ten w praktyce będzie spełniany, decyduje sam Zespół.
Mit 34: Backlog Sprintu ma mieć formę tablicy kanbanowej
O ile pomysł połączenia Scruma z Kanbanem jest naprawdę rozsądny, o tyle w Scrumie nie jest wymagane posługiwanie się tablicami kanbanowymi ani w sumie żadnymi innymi, o czym już pisałem powyżej.
Wspomniany Backlog Sprintu może mieć formę dowolną, jaką uznają za właściwą Developerzy – w definicji Scruma brak nawet wskazówek, jak mógłby wyglądać. Ważne, by składały się na niego trzy niezbędne rzeczy: Cel Sprintu, prognoza tego, co zostanie zrealizowane przed końcem iteracji oraz odpowiedź na pytanie, jak Developerzy zamierzają te dwie rzeczy osiągnąć.
Mit 35: Backlog Sprintu to zbiór elementów z Backlogu Produktu
Backlogu Sprintu zawiera prognozę zmian w produkcie, jakie Developerzy oceniają za możliwe do zrealizowania w trakcie Sprintu. Prognozę tę stanowią elementy Backlogu Produktu podjęte do realizacji. To prowadzi do błędnego wniosku, że Backlog Sprintu jest niczym innym, jak podzbiorem elementów Backlogu Produktu.
Co gorsza, twórcy narzędzi elektronicznych poszli torem takiej logiki i Backlog Sprintu jest w nich standardowo (albo wyłącznie) prezentowany jako lista elementów Backlogu Produktu, nie pozwalając łatwo (lub w ogóle) dodać do niego nic więcej.
A przecież Backlog Sprintu składa się z trzech rzeczy: wspomnianej prognozy, Celu Sprintu oraz planu jego osiągnięcia (i zarazem realizacji prognozy). Do tego pojawiają się w Backlogu Sprintu wszelkie inne rzeczy, jakie Developerzy planują zrobić w Sprincie, w tym działania opisujące implementację usprawnień uzgodnionych w trakcie Retrospekcji Sprintu poprzedniego.
Mit 36: Backlog Sprintu to górna część Backlogu Produktu
Wspomniałem już o narzędziach elektronicznych, które kiepsko prezentują Backlog Sprintu. Niektóre z nich wyświetlają oba Backlogi jeden nad drugim, rozdzielone separatorem, przez co wydaje się, że jest to tak naprawdę jedna lista elementów, podzielona na różne segmenty. Planowanie Sprintu polega na przenoszeniu elementów z jednej części listy do drugiej.
Skutki negatywne można łatwo przewidzieć. Część ludzi przestaje rozróżniać Backlogi, inni zaczynają być przekonani, że Backlog Sprintu to po prostu „górna część listy” elementów Backlogu Produktu. Zaczynają się przepychanki między Developerami i Product Ownerem o to, co można, a czego nie można dodać do takiej listy w trakcie Sprintu. Do tego narzędzie często wymusza workflow elementów taki, który być może ma sens dla Backlogu Produktu, ale pasuje jak pięść do nosa do Backlogu Sprintu.
Mit 37: Backlog Sprintu jest jeden i istnieje ciągle
Ten mit jest kolejną pochodną użycia narzędzi elektronicznych do zarządzania Backlogami w Scrumie. Ponieważ Zespoły widzą Backlog Sprintu zawsze w tym samym miejscu i dodają do niego rzeczy co Sprint w taki sam sposób, dość powszechne jest przekonanie, że ten sam Backlog Sprintu istnieje stale.
Oczywiście w Scrumie Backlog Sprintu powstaje na nowo w trakcie Planowania Sprintu i istnieje do momentu jego zakończenia, więc to nieporozumienie. Nie warto byłoby o nim wspominać, gdyby nie fakt, że współgra z kolejnym mitem o Scrumie, o którym piszę poniżej, a który prowadzi do realizowania rzeczy ciągiem przez dwa lub więcej Sprintów. Bo skoro Backlog Sprintu zawiera coś, nad czym prace już się rozpoczęły, po co go opróżniać? Dołóżmy kilka nowych i kontynuujmy development…
Mit 38: nieukończone rzeczy „przechodzą” na kolejny Sprint
Zdarza się, że Developerzy zaczną nad czymś pracę, ale nie uda się jej skończyć, nim minie zaplanowany czas Sprintu. Co wtedy z nimi zrobić? Zdecydowanie zbyt często słyszę, że muszą one pozostać w Backlogu Sprintu i być kontynuowane w kolejnej iteracji. Zupełnie tak, jakby to była jedyna opcja.
Tymczasem takiej opcji w ogóle nie ma. Każdy Sprint jest planowany na początku poprzez podjęcie do niego elementów z Backlogu Produktu. Nie może więc być tak, że nagle, jeszcze nim zacznie się kolejny Sprint, już wiadomo, co – przynajmniej częściowo – będzie w nim robione. A już na pewno nie wiadomo zawczasu, jaki będzie przyszły Cel Sprintu.
Dlatego, jeśli nie uda się czegoś skończyć, opisujące to coś elementy wracają do Backlogu Produktu. I bynajmniej nie zawsze na górę – Product Owner musi zdecydować o ich pozycji. Może umieścić elementy na odległej pozycji, a może w ogóle usunąć je z Backlogu.
Przy okazji: skoro Backlog Produktu opisuje to, co jest do zrobienia, takie powracające na listę elementy powinny zostać stosownie opisane, żeby nie wprowadzać w błąd. Inaczej mówiąc, trzeba je przedefiniować tak, by było jasne, co pozostało do wykonania. A jeśli Zespół stosuje oszacowania, należy ustalić wycenę, jaką ten element ma teraz.
Mit 39: Przyrostem jest to, co zmieniło się w produkcie
Przyrost obejmuje wszystko to, co zmieniło się w produkcie w wyniku prac wykonanych przez Developerów. Inaczej mówiąc, Przyrostem jest owa delta (zmiana), czyli to, o co przyrósł produkt. To bardzo zgrabne wyjaśnienie nazwy tego artefaktu, czyż nie?
Oczywiście to bzdura, bo choć faktycznie w przeszłości w Scrum Guide funkcjonował termin Przyrost produktu (ang. product Increment), od dawna już mowa jest po prostu o Przyroście (ang. Increment) i dzieje się tak nie bez przyczyny.
Ta nazwa odnosi się bowiem nie tyle do przyrastania produktu jako takiego, ile do spodziewanego przyrostu wartości produktu, który powinien nastąpić po wytworzeniu jego nowej wersji. Oraz do tego, że produkt powstaje w procesie nie tylko iteracyjnym, ale inkrementalnie. Przyrostem jest więc cały produkt, a nie tylko to, co się w nim ostatnio pojawiło lub zmieniło.
Poza tym, na logikę, jeśli Przyrostem byłoby tylko to, co do produktu dodano lub co w nim zmieniono, to jaki Przyrost powstaje, jeśli development polega na usunięciu czegoś z produktu? Wychodziłoby na to, że Przyrostem jest to, czego w produkcie już nie ma…
Mit 40: Przyrost, tylko jeden, powstaje na koniec Sprintu
Kolejnym nieporozumieniem jest przekonanie, że praca w Sprincie ma zakończyć się wytworzeniem jednego Przyrostu. Nie całego ich szeregu, z którego każdy kolejny Przyrost obejmuje w sobie poprzednie, ale dokładnie jednego. Najlepiej na styk tuż przed Przeglądem Sprintu. Albo może trochę wcześniej, żeby testerzy (eh…) zdążyli wykonać testy, bo wiadomo, że „testerzy to nie Developerzy”.
To wszystko bzdury. Testerzy są Developerami, bo ich praca jest potrzebna do wytworzenia zmian w produkcie. Co więcej, taki sztywny podział obowiązków i wąska specjalizacja Developerów w Zespole jest mało korzystna i stanowi przykład niskiego poziomu wszechstronności.
Nie dość na tym: empiryczny proces, którym posługiwać powinien się Zespół Scrum, w swej naturze ma iteracyjne i przyrostowe budowanie produktu. Dlatego nie dość, że Scrum nie wymaga, by powstał w Sprincie tylko jeden Przyrost, to jeszcze taki sposób organizacji pracy przez Developerów jest najmniej pożądany. Choćby dlatego, że Zespół, który potrafi sekwencyjnie wytworzyć wiele Przyrostów, każdy kolejny nieco bardziej wartościowy od poprzedniego, ma większe szanse na wykreowanie wartości dla interesariuszy.
Mit 41: Przyrost powstaje dopiero po zrealizowaniu w pełni elementu Backlogu
Jest w Scrum Guide zapis o tym, że w momencie, gdy prace nad jakimś elementem Backlogu Produktu zostają ukończone w myśl warunków zawartych w Definicji Ukończenia, powstaje Przyrost. I to prawda: powstaje wtedy nowa wersja produktu, który nadaje się do użycia, a więc Przyrost.
Nieprawdą jest natomiast, że tylko w takim przypadku powstają kolejne Przyrosty. Przyrostem jest każda nowa wartościowa i nadająca się do użycia wersja produktu, która przybliża Zespół do osiągnięcia w pierwszej kolejności Celu Sprintu, a w dalszym rzędzie Celu Produktu.
Oznacza to, że w trakcie pracy nad elementem Backlogu Produktu, jeśli ma to sens i będzie wartościowe, może powstać wiele kolejnych Przyrostów. Nikt przecież nie mówi, że praca nad elementami Backlogu ma się odbywać ciągiem i nie może być iteracyjna ani inkrementalna – ba, nawet wypadałoby, by taka była w Scrumie. W ten sposób łatwiej też mierzyć postęp prac, bo można sprawdzić, co już zostało zrobione i w jaki sposób działa, a nie tylko mówić „idzie nam nieźle, bo prace przebiegają zgodnie z planem”.
Co więcej, Przyrost powstanie również na skutek naprawienia przez Developerów błędu w produkcie czy dokonania jakiejś zmiany czysto technicznej. Jeśli dzięki temu produkt staje się bardziej wartościowy i są to prace niezbędne, dlaczego nie miałby to być Przyrost?
Mit 42: kilka Przyrostów jednego produktu może powstać równocześnie
Wiele produktów jest na tyle złożonych, że pracuje nad nimi więcej niż jeden Zespół – nie będę tu zaczynał dyskusji, czy to ma sens, tak po prostu się dzieje. Oczywiście implikacją tego jest posługiwanie się wspólnym Backlogiem Produktu oraz wspólną Definicją Ukończenia.
Ponieważ każdy z takich Zespołów pracuje w swoich Sprintach odbywających się równolegle, w tym samym momencie może powstać kilka różnych nowych wersji produktu, z których każda zawiera to, czym zajmował się dany Zespół. Jeśli taka nowa wersja produktu spełnienia warunki zawarte w Definicji Ukończenia, Developerzy zapewne ogłoszą, że wytworzyli Przyrost.
Ze Scrumem będzie to miało bardzo umiarkowane związki, bo przecież użytkownicy produktu nie mogą korzystać z wielu różnych jego wersji naraz, tylko z jednej, która zawiera wszystko, co wytworzyły poszczególne Zespoły.
Jeśli więc istnieje kilka równoległych wersji tego samego produktu, a mimo to Developerzy twierdzą, że każda z nich jest Przyrostem, to ich Definicja Ukończenia jest niekompletna. Brakuje w niej zapisów o konieczności zintegrowania produktu w jedną spójną wersję i potwierdzenia, że spełnia ona wszystkie warunki zawarte w Definicji Ukończenia.
Gdy niezbędne zapisy do Definicji zostaną dodane, jasne stanie się, że development wciąż trwa, bo integracja produktu w całość nie została jeszcze przeprowadzona. A zatem żaden Przyrost na razie nie powstał.
Oczywiście niewykluczone, że Zespoły te zajmują się w istocie różnym produktami, które zostały „zsypane” do jednego Backlogu Produktu, np. dlatego, że mają wszystkie tego samego Product Ownera. Wtedy pilne staje się posprzątanie bałaganu, czyli ich jednoznaczne rozdzielenie, stworzenie osobnych Backlogów Produktów itd.
Trzeba też dla każdego z takich produktów ustalić właściwą dla nich Definicję Ukończenia. A wtedy jak najbardziej w tym samym momencie różne Zespoły będą mogły wytworzyć Przyrosty, bo już nie będą pracować nad jednym, ale wieloma osobnymi produktami.
Ciąg dalszy
W kolejnej części cyklu zajmuję się zdarzeniami kończącymi Sprint, czyli Przeglądem i następującą po nim Retrospekcją – zapraszam do lektury tego artykułu.