Jak określić cel sprintu?
Posted on 1 lutego 2017 / Posted by Rafał Markowicz
*/?>

Jak określić cel sprintu?

Pracując jako Agile Coach z zespołami Scrumowymi w różnych organizacjach stosunkowo często obserwuję w czasie planowania iteracji, że określenie jakiż to cel sprintu uda się osiągnąć poprzez realizację wybranych na ten sprint wymagań bywa wyzwaniem. Przy czym problem nie jest natury lingwistycznej, ale dużo głębszej: to, co stanowi prognozę zespołu na dany sprint (ang. forecast) nijak nie daje się opisać skończoną ilością słów, a często i zdań.

Czy cel sprintu jest niezbędny?

Jedną z wartości Scrum jest skupienie (ang. focus). Dzięki skupieniu się na tym, co da się zrobić, ale też skupieniu na konkretnym celu, zespół jest w stanie organizować swoją pracę w iteracji, efektywnie radzi sobie z utrudnieniami i poszukuje najlepszych rozwiązań. Sprzyja temu określenie mocnego celu sprintu: zrozumiałego dla wszystkich, dającego się dobrze określić, realnie osiągalnego i przede wszystkim wartego osiągnięcia.

Cel sprintu ma wszakże jeszcze inne funkcje, mniej oczywiste. Przede wszystkim pozwala zespołowi dokonywać świadomych wyborów w każdej sytuacji, gdzie nie jest oczywiste, które rozwiązanie lub droga będzie najlepsza. Jest to trudne zwłaszcza jeśli porównujemy coś, co wydaje się mieć taką samą ilość zalet i wad. Jasny cel, do którego realizacji dąży zespół, pozwala wybrać takie rozwiązania, które sprzyjają osiągnięciu tego celu. Czasami wymaga to zrobienia szybkiego eksperymentu, aby potwierdzić, czy warto iść jedną, czy drugą drogą. Zamiast grzęznąć w analizach i dyskusjach, zespół świadomie spróbuje pójść dwiema drogami i po krótkim, ściśle określonym czasie oceni, jak daleko dotarł każdą z nich. To ułatwi wybór i stanowi dobry przykład korzystania z empiryzmu.

Inna funkcja celu sprintu ujawnia się, gdy złożoność i nieprzewidywalność technologii, wymagań lub otoczenia spowoduje, że prace w sprincie pójdą wolniej, niż zespół zakładał w czasie planowania iteracji. Można wtedy w kontekście celu sprintu zastanowić się z czego da się zrezygnować, lub jak ograniczyć zakres prac, aby cel nadal był osiągalny.

Cel sprintu przydaje się także, gdy ze względu na wyjątkowe okoliczności Product Owner musi negocjować z zespołem zmianę zakresu prac w sprincie. Zdarza się to na przykład w przypadku jakiejś awarii lub pilnej zmiany nie mogącej czekać na kolejny sprint – powodów ku temu może być wiele. O ile Scrum zakłada niezmienność wymagań w trakcie iteracji, nie wymusza to rezygnacji z pragmatyzmu – i tu pojawia się znów nasz cel sprintu. Mając go, możemy podjąć decyzję, z czego w iteracji zrezygnować, by wciąż osiągalny był ten cel, ale też by uzyskać czas niezbędny na poradzenie sobie z nieplanowanymi działaniami.

Kłopotliwy cel

Określenie celu sprintu jest proste, jeśli backlog produktu uporządkowany został tak, że kolejne wymagania opisują następujące po sobie etapy rozwoju produktu – na przykład od jego prostej, minimalistycznej wersji, przez wersje coraz bogatsze funkcjonalnie, do wszystko-mającego ideału, którego zapewne nigdy nie uda się zrealizować.

Dużo gorzej jest, gdy na szczycie backlogu produktu tkwią wymagania mało ze sobą powiązane, a w ekstremalnym przypadku opisujące zupełnie różne potrzeby biznesowe. W takim przypadku jednego celu działań w sprincie nie ma w ogóle. I zaczynają się dziać dziwne rzeczy.

„Składak”

Typowy pomysł zespołu i Product Ownera w takim przypadku to cel „składkowy”. Z listy wymagań, które będą realizowane w sprincie wybierane są te, które stanowią „cel sprintu” (cudzysłów nieprzypadkowy). Motywacja do osiągania takiego „celu” nie bywa duża, bo w sumie nie jest on ani zrozumiały, ani przesadnie atrakcyjny. Ot, zróbmy co do nas należy, żeby zrealizować taką czy inną arbitralnie wyznaczoną listę wymagań.

Wadą „składkowego celu sprintu” jest też to, że pojawia się pokusa jego osiągnięcia w sposób niekoniecznie wspierający empiryzm. Często bowiem jest tak, że taki „cel” nie obejmuje wszystkich wymagań z prognozy na sprint, ale tylko kilka z nich, czasami dosłownie dwa lub trzy z dziesięciu. Można zatem osiągnąć taki „cel” bez realizacji dużej części (lub nawet większości) wymagań składających się na prognozę. Zdarzyło mi się zetknąć z procesową obsługą takiego „składkowego celu sprintu” przez podział wymagań w prognozie na te „gwarantowane” – stanowiące „cel”, i te „opcjonalne”, których… no właśnie, nie trzeba zrealizować? Dziwna sytuacja, jeśli o tym na trzeźwo pomyśleć.

A celem niechaj będzie…

Innym pomysłem jest wskazanie jednego wymagania, które musi być zrealizowane „na pewno”. Jeśli towarzyszy temu sekwencyjna realizacja elementów backlogu, czyli Work in Progress limit = 1, wtedy pół biedy: można powiedzieć, że wskazując dziesiąte od góry wymaganie jako „cel” deklarujemy jednocześnie, że i te dziewięć nad nim zrealizujemy. Przypomina to „składaka” opisanego wcześniej, choć ma niewątpliwą przewagę nad nim: „cel” jest konkretny a reguły jego osiągnięcia jasne.

Problem z takim „celem” jest taki, że ciężko w jego kontekście decydować, co z zakresu usunąć albo jak zakres prac ograniczyć, jeśli zajdzie taka potrzeba. Pojawia się pokusa, by zrezygnować z realizacji jednego lub kilku wymagań o wyższej niż „cel” wartości, a wtedy można będzie ten „cel” osiągnąć mimo dołożenia nieplanowanej pracy w sprincie. Inny problem pojawia się, gdy „celem” nie jest ostatnie z wymagań stanowiących prognozę na sprint. Podobnie jak w „składaku” można zadać sobie pytanie czy to oznacza, że wymagania poniżej „celu” nie muszą być zrealizowane mimo, iż weszły w prognozę na sprint?

Jeszcze gorzej jest jeśli zespół nie limituje WiP do wartości jeden, tylko pracuje nad wieloma wymaganiami jednocześnie. Wtedy może szybko „osiągnąć cel sprintu” realizując najpierw to wymaganie, które wskazał jako „cel”, a potem… potem się zobaczy, co jeszcze się uda zrobić. Efekt niewiele będzie miał wspólnego ze zwinnym rozwojem produktu.

Cel: cały sprint!

Więc skoro już musi to być „składak”, to może niech celem będzie zrobienie wszystkiego, co stanowi prognozę na sprint? Jeśliby dobrze się zastanowić, ma to spory sens, ponieważ nie powstają wtedy domniemania, że coś może nie zostać zrealizowane. Nie ma też możliwości pójścia na skróty, by taki cel osiągnąć (tu już cudzysłowu brak, bo też zrobienie wszystkiego, co zaplanowano w sprincie, wydaje mi się bardzo sensownym celem).

Oczywiście taki cel wciąż jest „składakiem” z wieloma jego wadami: mało motywuje, nie daje też dużo elastyczności, gdyby trzeba było zmienić zakres w czasie trwania sprintu.

A może problemem nie jest cel?

W istocie tym, co przyczynia się do kłopotów z nazwaniem celu sprintu jest kształt backlogu, w którym na górze mamy wymagania słabo lub wcale nieskorelowane ze sobą. Może to świadczyć o tym, że próbujemy zaspokajać potrzeby wielu różnych użytkowników lub linii biznesowych równocześnie. Szeroką ławą idziemy w wielu kierunkach na raz. O ile bywa to niezbędne w skrajnych przypadkach, Product Owner powinien tego unikać. Nie dość, że komplikuje to planowanie, utrudni pracę z backlogiem i zmniejszy przejrzystość tego backlogu, to jeszcze stępia lub całkowicie rozmywa cele, do których zmierza development.

Brak skupienia na jasnych celach bywa często pochodną braku wizji produktu. To ogranicza zaangażowanie wszystkich uczestników procesu, trudno też ocenić, co warto robić, a co można bez żalu usunąć z backlogu. Brak skupienia (znów nawiązuję tu do wartości Scrum) bardzo utrudni pracę zwinną jeszcze z jednego powodu: ponieważ próbujemy realizować wiele celów na raz, w każdym z nich prace posuwają się do przodu wolno, wydłużać zaczynają się pętle feedbackowe, więc możemy przestać działać empirycznie. Pojawi się wtedy ochota na zrobienie pewnych rzeczy raz a dobrze…

Jak temu zaradzić? Nawet mając wielu użytkowników lub wiele linii biznesowych korzystających z jednego produktu należy mieć wizję rozwoju produktu jako całości. Ta wizja jest realizowana przez serię wydań, które nas do niej zbliżają. Wydania rzecz jasna mogą być robione w sposób ciągły (model Continuous Delivery), wtedy niekoniecznie skupiamy się na wydaniach, ale mówimy raczej o kolejnych etapach rozwoju produktu. Z tych wydań (etapów) wynikają pośrednie cele – już nie jest to wizja, ale konkretne funkcjonalności lub cechy produktu, których pożądamy w danym momencie najbardziej.

A zatem można układać backlog tak, by poszczególne sprinty zbliżały nas do zdefiniowanych celów wydań (etapów). Możemy świadomie dedykować sprinty jakiejś grupie użytkowników, jakiejś linii biznesowej, jakiejś funkcjonalności. Zmusza to Product Ownera do zrozumienia potrzeb różnych grup interesariuszy, pogodzenia ich oraz określenia, które wymagania warto robić najpierw, a których nie warto realizować. Ale kto mówi, że rola Product Ownera jest łatwa? W istocie takie działanie to kluczowy aspekt tej roli. Dzięki temu w sprincie mogą być realizowane związane ze sobą wymagania, opisujące rozwój jakiejś większej funkcjonalności – i nagle będzie dało się cele sprintu zidentyfikować bez kombinowania i zabawy w „składaki”.

Może metoda jest nieodpowiednia?

A co robić, gdy zmiana backlogu jest niemożliwa? Wciąż warto próbować ograniczać skalę problemu dążąc do minimalizacji jednocześnie podejmowanych celów, dzięki czemu może nie jeden, ale dwa biznesowe cele na sprint uda się ustalić (zamiast dziesięciu).

Jeśli permanentnie jesteśmy skazani na „cele-składaki” w jakiejkolwiek ich formie, warto zastanowić się, czy metoda wymagająca w swej istocie skupienia i możliwości określenia jasnych celów jest rzeczywiście dobra dla nas. Może nasz backlog nie opisuje zmian w produkcie, ale jest kolejką zleceń do wykonania w różnych obszarach? Może udajemy, że jednym produktem jest całe ich portfolio, ale pracy w każdym pojedynczym elemencie tego portfolio jest zbyt mało, by zajmował się nimi dedykowany zespół? To tylko dwie możliwości wyjaśnienia przyczyn problemu, jest ich bez wątpienia więcej.

Gdy znajdziemy odpowiedź na pytanie „co zmusza nas do zajmowania się kompletnie różnymi rzeczami w jednym sprincie” być może uznamy, że Scrum to nie jest najlepsza dla nas metoda i lepiej korzystać z Kanbana. Być może okryjemy, że mamy wiele produktów a nie jeden; wtedy rozdzielimy ich backlogi a zespół – zamiast udawać, że pracuje ze wszystkimi na raz – będzie się przełączał między nimi co któryś sprint? Może odkryjemy jeszcze coś innego?

Tagi:
,
*/ ?>

SZKOLENIA ZWIĄZANE Z TEMATYKĄ ARTYKUŁU


O autorze: Rafał Markowicz
Scrum Master z wieloletnim doświadczeniem, w branży IT od 15 lat. Praktyk Agile pracujący z zespołami developerskimi, jednocześnie ekspert w zakresie inżynierii testów i zapewnienia jakości. Pracował jako analityk systemowy i biznesowy, jest doświadczonym developerem, managerem i konsultantem. Prowadzi szkolenia z zakresu Agile, Scrum, Kanban, testowania (nie tylko zwinnego) i zapewnienia jakości. Uczy jak tworzyć i dekomponować wymagania, jak definiować kryteria akceptacyjne i używać ich w procesie rozwoju produktu, jak pracować z wymaganiami funkcjonalnymi i niefunkcjonalnymi (w tym jak prowadzić testy wydajnościowe złożonych systemów).

Inne artykuły tego autora