Category: Articles

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Sprawne tworzenie oprogramowania jest ważne, ale na niewiele się zdaje, jeśli to co produkuje zespół nie odpowiada najpilniejszym potrzebom odbiorców. Wysiłek zespołu jest też marnowany, jeśli pomiędzy przygotowaniem kolejnych ulepszeń, a oddaniem ich w ręce Klientów mija zbyt dużo czasu lub zespół nie ma sposobu zebrania od nich informacji zwrotnej.

Dzisiaj przyjrzymy się jak Scrum pomaga rozwiązać ten problem za pomocą Przeglądów Sprintu oraz jak w zaangażowaniu Klienta pomagają Radiatory Informacji.

Przegląd Sprintu

Przegląd Sprintu (Sprint Review) lub potocznie Demo jest po to, żeby:

1. zaprezentować odbiorcom nowe funkcje i cechy systemu, żeby wiedzieli, że istnieją i umieli ich użyć,
2. na gorąco zebrać informację zwrotną o przydatności i jakości naszego produktu, żeby w następnym sprincie móc dostarczyć kolejną porcję najważniejszych ulepszeń,
3. (przy okazji) formalnie potwierdzić, które historyjki zostały zakończone (zgodnie z ich treścią, kryteriami akceptacji i definicją ukończenia), a które muszą wrócić do backlogu.

Oznacza to w szczególności, że w każdym przeglądzie powinni brać udział końcowi odbiorcy (wszyscy, jeśli się da lub chociaż ich reprezentatywni przedstawiciele). Jeśli z jakiegoś powodu nie da się takich ściągnąć, to ich interesy reprezentuje Właściciel Produktu. Szczególnie ważne jest wtedy zadbanie o inne okazje do zebrania feedbacku.

Jak widać z powyższej listy najważniesza podczas prezentacji wyników naszej pracy jest empatia wobec potrzeb odbiorców! Oznacza to w szczególności, że powinniśmy:

1. koncentrować się na tym, co zostało dostarczone, a nie jakie prace zostały wykonane,
2. formułować naszą opowieść w języku zrozumiałym dla użytkowników (z pominięciem szczegółowego opisu rozwiązań technicznych),
3. dać uczestnikom spotkania okazję wypowiedzieć się na temat nowych funkcji lub wręcz samodzielnie je wypróbować.

Czy Przegląd Sprintu to nowa nazwa UAT (User Acceptance Testing)?

Nie! Warto pamiętać, że Przegląd Sprintu to nie jest sesja UAT. Nie chcemy dopuścić do sytuacji, w której zespół świadomie oddaje niedokończone (w szczególności nie wystarczająco przetestowane) historyjki, w nadziei, że Klient i PO nie natrafią na widoczne braki lub oczekuje, że właśnie wyłapywanie błędów jest celem Przeglądu. Oficjalna akceptacja historyjek przez PO powinna być formalnością, bo wszystkie wątpliwości powinny być wcześniej omówione, a kluczowe założenia zapisane w kryteriach akceptacji. Zespół oddając historyjkę sam powinien zadbać o to, że spełnia ona wszystkie te kryteria oraz wszystkie standardy zapisane w Definition of Done.

Co dzieje się z historyjkami, których nie zdążyliśmy zakończyć?

Historyjki, które nie są gotowe (zgodnie z kryteriami akceptacji i definicją ukończenia) wracają do backlogu i są repriotytetyzowane. Być może wpadną do następnego Sprintu, być może zostaną odłożone na później, a być może w ogóle stracą aktualność. Jeśli zostaną wzięte do kolejnego Sprintu to w oszacowaniu można uwzględnić już wykonane prace cząstkowe. Jednak jeśli historyjka zostanie odłożona na później to warto konserwatywnie pozostawić oszacownie takie jak było – nie domknięte pół-produkty mają tendencję do szybkiej dezaktualizacji i wcale nie jest pewne czy za kilka sprintów dalej będą pomagać w dostarczeniu tej historyjki.

Czy możemy od czasu do czasu przymknąć oko i przepchnąć prawie-gotowe historyjki?

Możemy… Ale jedynie na własną szkodę! Jeśli pozwolimy na rozluźnienie dyscypliny to bardzo szybko dostaniemy “to co zwykle” opakowane w nową terminologię, a nie prawdziwy Scrum. Podniesienie przejrzystości całego procesu jest kluczowym elementem Scrum i jeśli zaczniemy rozmywać granice akceptowalności to cała konstrukcja rozleci się jak domek z kart. Może wydawać Ci się, że to zbyt ostre sformułowanie; lecz take nie jest. Otwartość, uczciwość i (samo)dyscyplina są niezbędnymi wartościami dla zespołów Scrum, bez których trudno sobie wyobrazić jego prawidłowe działanie!

Radiatory Informacji

Dodatkową pomocą we wzbudzeniu w naszych odbiorcach zainteresowania pracą zespołu służą, znane nam już, radiatory informacji. Jeśli każdy zainteresowany może w każdej chwili popatrzyć na tablicę i zobaczyć, jakie historyjki są obecnie realizowane oraz ile zadań pozostało do ich zakończenia, to będzie spokojniejszy i bardziej zadowolony z całego procesu. Działa to szczególnie dobrze, jeśli przed zastosowaniem Scrum prace developerskie były mało przejrzyste, a data zakończenia poszczególnych projektów nieprzewidywalna.

Jeśli przejrzystość wobec osób z otoczenia zespołu jest dla nas szczególnie ważna możemy pójść krok dalej i przygotować specjalną tablicę dla zewnętrznych obserwatorów, na której można znaleźć cel bieżącego sprintu, daty kluczowych spotkań (z Przeglądem Sprintu na czele), kontakt do Właściciela Produktu i Scrum Mastera i ew. inne informacje pomagające zainteresowanym zorientować się w sytuacji bez przeszkadzania zespołowi w pracy.

Zadowolenie Klientów i efekt IKEA

Naszym celem jako dostawców rozwiązań jest z definicji zadowolenie Klientów. Głównym źródłem satysfakcji są po prostu nowe funkcje i ulepszenia dostarczane przez zespół, szczególnie, że dzięki regularnemu zbieraniu informacji zwortnej są to funkcje i ulepszenia, którz są dla użytkowników najbardziej wartościowe.

Nie do pominięcia jest jednak psychologiczny efekt dania odbiorcom poczucia zaangażowania w tworzenie systemu. W ekonomii podobny mechanizm znany jest jako efekt IKEA. Mówi on, że jako ludzie wyżej cenimy to, w co włożymy własny wysiłek. Dlatego meble z IKEI, która sami składamy, mogą być dla nas bardziej wartościowe niż takie same meble dostarczone w całości lub zmontowane przez dostawcę. Tak samo system, w którego tworzenie jak najwcześniej wciągnęliśmy naszych Klientów jest przez nich wyżej ceniony niż identyczny system, który zostanie im dostarczony przez odizolowany zespół.

Pytania do Was:

1. Czy w Waszych Przeglądach Sprintu biorą udział użytkownicy końcowi?
2. Czy informacja zwrotna, którą od nich dostajecie pomaga Wam ulepszyć Wasz produkt?
3. Z jakich innych źródeł informacji zwrotnej korzystacie?

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Wczoraj rozmawialiśmy o tym, w czym mogą pomóc codzienne standup’y. Dzisiaj przyjrzymy się dwóm pozostałym narzędziom wspomagającym organizację pracy podczas sprintu: Tablicy Scrum i Wykresowi Wypalania (burndown).

Tablica Scrum – zawsze wiemy na czym stoimy i jaki jest następny krok

Standupy działają najlepiej, gdy odbywają się w bezpośrednim sąsiedztwie tablicy, na której stale widoczny jest aktualny plan (Backlog Sprintu) na przykład w formie listy zadań z podziałem na zadania do wykonania, w robocie i zakończone. Na tablicy można też wizualizować inne ważne informacje: tematy do omówienia na retrospekcję, poziom subiektywnego zadowolenia wszystkich członków zespołu (poszukaj pod hasłem happiness metric) lub wyróżnione innym kolorem bieżące zlecenia utrzymaniowe, z którymi nie można poczekać do następnego sprintu.

Najlepszym narzędziem jest tu najczęściej zwykła tablica korkowa (białe zostawmy do rysowania podczas spotkań i dyskusji), z żółtymi karteczkami reprezentującymi zadania. Ma ona tą zaletę, że jest zawsze widoczna i łatwa do aktualizacji. Poza tym jest też łatwa do modyfikacji, jeśli zespół zechce np. wypróbować inny sposób śledzenia postępów. Stanowi też świetny radiator informacji, wokół którego rozgrywa się praca zespołu. Tablica stymuluje też interakcję z osobami poza zespołem, których uwage przyciągnęło coś co na niej zobaczyły.

Oczywiście istnieje szereg narzędzi elektronicznych pozwalających zarządzać Tablicą Scrum. Kilka popularnych rozwiązań to:

1. rozbudowany Green Hopper (będący nakładką na system Jira),
2. minimalistyczne Trello,
3. nastawione na płynność przepływu pracy Kanbanery.

Jeśli jednak zdecydujemy się na elektroniczną wersję tablicy to musimy się liczyć z mniejszą widocznością informacji w niej zawartych. Warto zastanowić się wtedy nad zniwelowaniem tej słabości np. poprzez wyświetlanie tablicy na centralnie umieszczonym ekranie, tak jak to robi np. warszawska firma TouK:

Burndown i diagnoza sytuacji

Po aktualizacji planu (np. podczas standupu) możemy podsumować ile pracy pozostało do wykonania i porównać tą liczbę z czasem pozostałym do zakończenia sprintu. Pozostałą pracę można mierzyć za pomocą sumy godzinowych oszacowań pozostałych zadań, samej liczby zadań (jeśli mamy ich dużo i wszystkie są mniej więcej podobnych rozmiarów) lub w dowolny inny, odpowiedni do sytuacji, sposób. Dystans pozostały do pokonania możemy zwizualizować za pomocą wykresu burndown, który pozwala nam na pierwszy rzut oka ocenić sytuację w sprincie:

Kształt burndown’u pozwala nam też zdiagnozować ograniczenia, nawet jeśli wyrabiamy się w sprincie:

Jeśli nasze postępy są wyraźnie wolniejsze niż zakładane, możemy natychmiast poinformować Właściciela Produktu i uzgodnić z nim, które zadania w sprincie mają najwyższy priorytet, a które będą musiały zostać odłożone na później.

Jeśli wykres ma kształt urwiska (większość zadań domykana jest dopiero pod koniec sprintu) to może to świadczyć o kilku możliwych problemach. Najczęściej występują dwa:

1. Być może dzielimy pracę na zbyt długie zadania (w sprincie zadania rzadko powinny przekraczać jeden dzień). Akceptując wielodniowe, indywidualne prace tracimy możliwość śledzenia prawdziwej sytuacji i jeśli któreś z długich zadań się przeciągnie to dowiemy się o tym dopiero pod koniec sprintu – zbyt późno by cokolwiek poradzić.
2. Być może zespół bierze (lub co gorsza: dostaje) do wykonania zbyt wiele pracy i pod koniec sprintu heroicznym wysiłkiem nadgania zaległości (co prowadzi do natychmiastowej zapaści jakości i szybkiego wypalenia zespołu).

Jeśli wykres przez część sprintu rośnie zamiast maleć to być może to świadczyć o tym, że:

1. W trakcie przypominaliśmy sobie o dodatkowych zadaniach niezbędnych do realizacji wybranych historyjek. Powinniśmy popracować nad bardziej precyzyjnym planowaniem.
2. Często natrafiamy na nieprzewidziane problemy techniczne. Powinniśmy rozważyć zastosowaniem eksperymentów technicznych, które pozwolą nam zbadać teren przed przyjęciem do realizacji “produkcyjnej” historyjki.
3. W trakcie sprintu na zespół spada dużo dodatkowych zleceń, nie związanych z realizowanymi historyjkami (lub co gorsza PO nakazuje realizację dodatkowych historyjek). Musimy zadbać o lepszą ochroną zespołu, by dać mu swobodę sprawnej realizacji wybranych historyjek.

Pytania do Was:

1. Czy utrzymujecie aktualny plan w widocznym, łatwo dostępnym miejscu, które zachęca do codziennej jego aktualizacji?
   
2. Czy śledzicie prace pozostałe do wykonania w trakcie sprintu?
3. Czy Wasze burndown’y mają często podobny kształt? Czy w ruchu karteczek na Waszej tablicy możecie dostrzec powtarzalne wzorce?
4. Co możecie wyczytać z typowego burndown’u i obserwacji tablicy, na temat Waszych przyzwyczajeń i metod organizacji pracy?

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Dzisiaj i jutro odpowiemy na dwa ważne pytania:

1. Jak utrzymać stały rytm pracy aby uniknąć wypalenia i dodać szczyptę samodyscypliny?
2. Jak monitorować postępy wewnątrz sprintu i aktualizować plan w oparciu o bieżącą sytuację?

W Scrum służą do tego:

1. codzienne spotkania potocznie zwane standup‘ami,
2. umieszczona w widocznym miejscu, przejrzysta i łatwa w aktualizacji tablica,
3. oraz wizualnie ilustrujący postępy wykres wypalania (burndown).

Dzisiaj skoncentrujemy się na standup’ach:

Codzienny Scrum (potocznie standup) to spotkanie zespołu, na którym każdy członek zespołu dzieli się z pozostałymi informacją o tym:

1. Co zrobiłem od ostatniego spotkania?
2. Co zrobię przed następnym spotkaniem?
3. Czego potrzebuję, żeby wykonać zadanie?

Zwróć uwagę na formę dokonaną w pierwszych dwóch pytaniach. Możemy w ten sposób wykrywać i rozwiązywać problemy, zanim poważnie zagrożą realizacji celu sprintu. Jeśli często zdarza nam się słyszeć “Wczoraj pracowałem nad X. Dzisiaj dalej będę pracował nad X. Nic nie potrzebuję.” to standup nie spełnia swojego zadania i wymaga naprawy! (W tym konkretnym przypadku może np. pomóc rozbijanie zadań na mniejsze.)

Ostatnie pytanie dotyka zarówno pozytywnych jak i negatywnych aspektów pracy. Jest to jednocześnie okazja do wskazania czegoś, co mnie blokuje i zastanowienia się w gronie zespołu czy jest coś, co mogłoby pomóc wykonać zadanie szybciej i/lub lepiej.

Standup nie jest jedynie okazją do wymiany informacji w gronie zespołu, a tym bardziej nie jest sposobem na raportowanie postępów do kierownika (odwiedzającego standup lub kryjącego się skórze Scrum Mastera). Jak wyraźnie pokazuje Kasia Terlecka (znana w Polsce jako świetny Agile Coach):

Celem standup’u jest planowanie!

Niezależnie od tego czy stosujemy wymienione wyżej pytania czy korzystamy z innych form musimy przede wszystkim dowiedzieć się: Czy jesteśmy na dobrej drodze do realizacji celu sprintu? oraz Jakie są następne kroki w jego kierunku? i Czy powinniśmy uzupełnić lub zmienić plan (czyli Backlog Sprintu)?

Dodatkową zaletą codziennych standup’ów jest dostarczanie pewnej dozy samo-dyscypliny wynikającej z dobrowolnego zobowiązania się danej osoby do wykonania określonych zadań. Dużo trudniej marnować czas (wmawiając sobie, że potem bez problemu nadrobimy zaległości) jeśli już następnego dnia trzeba będzie przyznać się przed całym zespołem do braku postępów. Ważne tylko, żeby nie pójść z tą zasadą za daleko i stworzyć środowisko, w którym nikt nie będzie się bał przyznać do naturalnie występujących problemów w obawie przed mniej lub bardziej namacalną karą.

Tyle korzyści! To musi trwać bardzo długo, prawda?

Nie prawda. Jak sama nazwa wskazuje spotkanie to odbywa się na stojąco, co naturalnie zniechęca do zbytniego przedłużania dyskusji i utrudnia korzystanie z przeszkadzaczy w postaci komputera, tabletu lub telefonu. Jeśli mimo to minie 15 minut to bezceremonialnie kończymy standup. Następnego dnia się uda szybciej!

Pytania do Was:

1. Czy spotykacie się codziennie by omówić postępy i ustalić następne kroki?
2. Czy czujecie, że Wasze standup’y przynoszą Wam oczekiwane wartości? Jakie?
3. Jak moglibyście usprawnić przebieg Waszych standup’ów?

Ćwiczenie dla Was:

1. Jako Scrum Master daj się porwać tuż przed zaplanowanym czasem standup’u. Czy zespół sam przeprowadzi spotkanie?
2. Wypróbuj grę standupową opisaną w innym artykule Kasi Terleckiej.

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Pamiętasz drużynę A? W każdym odcinku nasi bohaterowie odnoszą sukces dzięki twórczemu połączeniu unikalnych talentów całego zespołu. Hannibal ustala ogólną strategię, Murdock pilotuje samoloty i śmigłowce by drużyna dotarła do swojego celu, Buźka swoim czarem zyskuje niezbędną pomoc od napotkanych osób a B.A. Baracus dostarcza siłę uderzeniową za pomocą własnych mięśni oraz broni improwizowanej z aktualnie dostępnych materiałów.

Dobre zespoły Scrum działają podobnie.

Tak jak pisaliśmy już pierwszego dnia, najważniejszym czynnikiem podnoszacym efektywność zespołu jest motywacja. Aby stworzyć środowisko jej sprzyjające oraz usunąć przeszkody spowalniające zmotywowany zespół Scrum mówi, że powinien on być samoorganizujący oraz interdyscyplinarny, a wszyscy członkowie takiego zespołu powinni być współodpowiedzialni za osiągane wyniki.

Nie zawsze jest jednak jasne, jak te zasady powinny przekładać się na codzienną praktykę. Dlatego dzisiaj przyjrzymy się kilku dodatkowym zasadom i konkretnym metodom pomagającym zbliżyć zespół do hiperproduktywności.

Dojrzałe, wysoce efektywne zespoły pracują razem bardziej niż równolegle. Nie oznacza to, że wszystko zawsze robione jest jedną wielką grupą, ale takie zespoły na pewno kładą większy nacisk na maksymalne wykorzystanie synergii między talentami poszczególnych członków, niż na podział pracy zgodny z ich specjalizacjami.

Cały zespół jest “właścicielem” całego rozwiązania (collective code ownership) – nikt nie powinien mieć wyłączności na wprowadzanie zmian w danym module, nie ma też miejsca na to, żeby członek zespołu całkowicie ignorował jeden z obszarów prac tylko dlatego, że “to nie moja działka“.

Dobrym zwyczajem wspierającym wspólną własność rozwiązania jest regularny przegląd tworzonego kodu (code review) przez innego członka zespołu. Odbywa się to nie w atmosferze kontroli pracy autora danego fragmentu, co raczej w intencji zapewnienia wysokiej jakości i czytelności kodu oraz rozpowszechniania wiedzy o systemie.

Jeszcze lepsze efekty niż code review może przynieść praca w parach (pair programming), która polega na tym, że dane zadanie wykonują dwie osoby pracujące jednocześnie przy jednym komputerze. Jest to dość trudna technika, lecz jeśli przyjmie się w zespole, pozwala znacznie zacieśnić współpracę, podnieść jakość produkowanego kodu, a także błyskawicznie rozpowszechnić w całym zespole najlepsze praktyki techniczne i wiedzę o tworzonym systemie. Naiwnie patrząc programowanie w parach podwaja pracochłonność bieżacych zadań, lecz ta inwestycja często zwraca się z nawiązką poprzez zmniejszenie liczby błędów do naprawienia później i ułatwienie naprawianie tych błędów, które mimo wszystko wystąpią.

Kolejną zaawansowaną techniką jest swarming, czyli równoczesna praca wielu członków zespołu nad jednym problemem. Swarming przydaje się przy usuwaniu wąskich gardeł w procesie. Przypuśćmy, że w zespole mamy dwóch testerów, którzy testują każdą nową funkcjonalność. Jeśli gotowe do testowania funkcjonalności nawarstwiają się i ta dwójka nie nadąża z ich przepychaniem można podjąć decyzję o chwilowym zatrzymaniu dalszego programowania i skupieniu się całego zespołu nad testowaniem oczekujących funkcji. Przy okazji warto popracować nad zautomatyzowaniem części testów lub innymi sposobami na ułatwienie dalszej pracy testerów. Po odblokowaniu zatoru zespół może spokojnie powrócić do dalszych prac bez obaw, że ich wysiłki są marnowane przez blokadę w innej części procesu wytwórczego.

Swarming może być też wykorzystany jako ćwiczenie pozwalające ulepszyć sposób współpracy zespołu. W takim przypadku możemy na jeden lub dwa sprinty założyć, że cały zespół pracuje nad jedną historyjką, aż zostanie ona w 100% zakończona i dopiero wtedy zabiera się za następną. Taka organizacja pracy rzadko jest dobrym pomysłem na stałe, ale stosowana chwilowo może pomóc przebić się przez bariery ograniczające efektywność zespołu.

Na jakość współpracy mogą mieć wpływ nawet pozornie drobne szczegóły organizacji pracy, takie jak np. moment przypisywania zadań do osób. Jak pisaliśmy wcześniej, lepiej gdy dzieje się to just-in-time, czyli wtedy gdy zespół jest gotowy rozpocząć pracę nad tym zadaniem, a nie np. przy planowaniu sprintu.

Oprócz tego ważne jest, żeby rozpisać pracę w sprincie na odpowiednio małe zadania. Zadania te nie powinny być prawie nigdy dłuższe niż jeden dzień. Dzięki temu na każdym standupie można od razu wykryć ew. problemy i opóźnienia. Zbyt długie zadania są wylęgarnią nieudanych sprintów. Jeśli zespół regularnie dzieli pracę na wielodniowe zadania to traci wgląd w postępy i ogranicza możliwość wzajemnej pomocy oraz stałego doskonalenia.

Jak wyglądają idealni członkowie interdyscyplinarnego zespołu?

Interdyscyplinarność nie oznacza pełnej wymienialności. Wręcz przeciwnie – właściwa różnorodność zespołu bardzo dobrze wpływa na jego skuteczność.  Z drugiej strony wąskie specjalizacje połączone z przyzwoleniem na zamykanie się specjalistów w swoim obszarze to prosta droga do niskiej efektywności.

Idealny członek zespołu Scrum ma profil kompetencji w kształcie litery T, czyli jest generalizującym specjalistą: jest bardzo dobry w swojej głównej dziedzinie, ale posiada też i stale doskonali umiejętności z kilku okolicznych obszarów. Programista świetnie koduje skomplikowane algorytmy, ale umie też odnaleźć się w bazie danych, przeprowadzić testy różnych typów a nawet, o zgrozo, napisać kawałek dokumentacji.

W ten sposób kompetencje całego zespołu powinny układać się podobnie jak puzle pokrywające cały zakres niezbędnych umiejętności – z główną cześcią własnego obrazka, ale też wypustkami pozwalającymi zaangażować się w inne rodzaje pracy.

Pytania do Was:

1. Jak moglibyście wzmocnić współpracę Waszego zespołu?

Ćwiczenie dla Was:

1. Stwórzcie w swoim zespole macierz kompetencji, która pozwoli Wam lepiej zrozumieć Wasze indywidualne i grupowe możliwości.
2. Narysujcie wspólnie koło pomocy, które pomoże Wam wspierać się nawzajem. Opis ćwiczenia znajdziecie w skądinąd świetnej (wolnodostępnej) książce Doktryna Jakości Andrzeja Blikle, na stronie 230.

Jako Fluid Circle na codzień pomagamy zespołom zwiększać swoją efektywność i jednocześnie czerpać więcej satysfakcji z pracy. Jeśli chciałbyś, żebyśmy pomogli także Twojemu zespołowi zastosować opisane w tym cyklu zasady to chętnie z Tobą porozmawiamy!

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Planowanie Sprintu ma dwa cele:

1. Uzgodnić cel sprintu.
2. Stworzyć plan jego realizacji.

Przyjrzyjmy się bliżej regułom i dobrym praktykom regulującym oba te aspekty:

Uzgodnić cel sprintu

• Ustalenie celu sprintu rozpoczyna się od wyjaśnienia przez Właściciela Produktu aktualnych priorytetów i omówienie ich z zespołem wraz z możliwymi rozwiązaniami.
• Aby planowanie mogło przebiegać sprawnie Backlog Produktu powinien być GOTOWY. Jeśli nie jest, to możemy dopracować wybrane historyjki na bieżąco. Jednak jeśli zdarza się to często to powinniśmy więcej inwestować w Pielęgnację Backlogu (Backlog Grooming).
• Dla każdej historyjki powinniśmy wiedzieć co dokładnie będzie oznaczało jej zrealizowanie. Wnioski z dyskusji na ten temat powinny być zwięźle ujęte w formie Kryteriów Akceptacji, a standardy pracy wspólne dla wszystkich historyjek w Definicji Ukończenia (Definition of Done).
• Niedokończone historyjki z poprzedniego sprintu nie przechodzą automatycznie do następnego, lecz wracają do Backlogu Produktu. Być może nadal są priorytetowe i zostaną ponownie wybranie, ale nie koniecznie.
• Oprócz listy historyjek przyjętych do realizacji warto ustalić pojedynczy cel sprintu, który da zespołowi wizję wartości, wiążącą w spójną całość wszystkie historyjki.
• Wszystkie osoby, które biorą udział w pracach rozwojowych biorą też udział w planowaniu sprintu: od analityków, przez programistów, testerów, administratorów baz danych, projektantów interfejsu użytkownika, dokumentalistów i przedstawicieli wszystkich innych specjalności niezbędnych, żeby wytworzyć gotowy produkt.
• Decyzja o przyjęciu do realizacji wybranych historyjek należy do całego zespołu. Nie do Właściciela Produktu. Nie do Scrum Mastera. Nie do zewnętrznego Project Managera, ani nawet do Prezesa, gdyby ten chciał się pojawić na planowaniu.
• Decyzja ta powinna być zrodzona z konsensusu . Głosowanie narzucające wszystkim wolę większości nie prowadzi do zdrowej współpracy zespołowej.
• Wiele zespołów, które wcześniej pracowały nad wielomiesięcznymi projektami, zmaga się z pytaniem: Jak zmieścić wszystkie niezbędne prace wewnątrz krótkiego sprintu? Rozwiązaniem jest wybieranie mniejszych celów. Czasem lepiej zapytać “Co możemy dostarczyć w sprint?” niż “Jak podzielić naszą pracę na sprinty?“.
• Dostarczanie gotowych funkcjonalności powinno zacząć się od pierwszego sprintu. Architekturę aplikacji i inne wspólne elementy projektu przygotujemy przy okazji dostarczenia – być może bardzo prostej – ale konkretnej wartości.
• Planując prace w sprincie warto uwzględnić ulepszenia zaplanowane na ostatniej retrospekcji.

Stworzyć plan realizacji

• Po wyborze i omówieniu najpilniejszej historyjki (lub kilku) następnym krokiem jest przygotowanie planu jej realizacji.
• Plan powinien uwzględniać wszystkie prace niezbędne do zrealizowania historyjki zgodnie z Kryteriami Akceptacji i Definicją Ukończenia.
• Mimo tego, że staramy się od razu stworzyć kompletny plan, musimy liczyć się z tym, że w trakcie sprintu pojawią się dodatkowe zadania, niezbędne do realizacji wybranych historyjek. Według współtwórcy Scrum Kena Schwabera może to być nawet 40% wszystkich zadań.
• W trakcie planowania podejmowane są decyzje techniczne niezbędne do przyjęcia historyjek do realizacji i rozpoczęcia prac. W razie potrzeby dalsze projektowanie jest zadaniem wewnątrz sprintu.
• Powinniśmy unikać projektowania rozwiązań dla historyjek na kolejne sprinty. Zaburza to bieżący sprint (to dodatkowa praca poza realizacją aktualnie wybranych historyjek) i grozi zmarnowaniem włożonego w projektowanie wysiłku, jeśli zaprojektowana historyjka zostanie potem wyrzucona z backlogu.
• Jeśli podczas planowania brakuje nam wiedzy niezbędnej do przyjęcia historyjki to zamiast całej historyjki możemy rozważyć przeprowadzenie eksperymentu technicznego (spike) pozwalającego rozstrzygnąć wątpliwość.
• Nie przypisujemy zaplanowanych zadań do konkretnych osób, z góry na cały sprint. Każda osoba bierze kolejne zadania zgodnie ze swoimi możliwościami dopiero wtedy, gdy dokończy poprzednie zadania. Zwykle pojedyńcza osoba nie powinna mieć przypisanych do siebie więcej niż dwóch zadań na raz.
• Plan realizacji historyjek, czyli Backlog Sprintu, powinien umożliwiać śledzenie postępów w rytmie dziennym. Dlatego zadania powinny być oszacowane i żadne z nich nie powinny znacznie przekraczać jednego dnia.
• Im prostsze szacowanie pozwoli utrzymać przejrzystość w sprincie tym lepiej. Zamiast szacowania zadań w godzinach możemy ograniczyć się do trzech możliwości: “tyle co nic“, “pół dnia” i “cały dzień” albo rozbijać całą pracę na podobne do siebie kawałki i po prostu śledzić  liczbę pozostałych zadań.

Na koniec ważna reguła:

• Planowanie Sprintu jest ograniczone w czasie (do 4ch godzin dla 2-tygodniowego Sprintu). Nie powinniśmy przedłużać tego spotkania, nawet jeśli nie zdążyliśmy wszystkiego do końca zaplanować. W takiej sytuacji mamy dwie możliwości:  zaplanować kolejne, ograniczone w czasie spotkanie na następny dzień lub rozpocząć pracę i uzupełniać listę zadań na bieżąco.

Pytanie do Was:

Każdy zespół nieco inaczej prowadzi Planowanie Sprintu. Jakie są Wasze doświadczenia? Podzielcie się w komentarzach.

Ten post jest częścią cyklu Pierwsze Dni Scrum.

W rozmowach z osobami zainteresowanymi Scrum’em często przewija się kilka mitów, np.:

1. “W Scrum nie da się planować dłużej niż na sprint.”
2. “Nie możemy zastosować Scrum, bo potrzebujemy przewidywalności jaką daje nam precyzyjny harmonogram.”
3. “Nie stać nas na częstą integrację i testowanie przez cały projekt – wszystko sprawdzimy na końcu.“
4. “Scrum nie nadaje się do projektów fixed-price.“

Dzisiaj zajmiemy się naprostowaniem tych nieporozumień odpowiadając na trzy pytania:

1. Jak zwiększyć przewidywalność i ograniczyć ryzyko w naszych projektach?
2. Co jeśli musimy zobowiązać się do konkretnej daty, zakresu i ceny projektu?
3. Jak dostarczyć więcej wartości mniejszym kosztem?

Jak zwiększyć przewidywalność i ograniczyć ryzyko?

Zacznijmy od innego pytania: Jak bardzo szczegółowy harmonogram projektu z jednym dużym wdrożeniem na końcu pomaga nam zabezpieczyć się przed ryzykiem opóźnienia?

Nie za bardzo!

Harmonogramy tego typu wpadają w pułapkę iluzorycznej precyzji. Dokładne rozpisanie poszczególnych faz nie chroni nas przed opóźnieniami. Większość problemów w projektach informatycznych wykrywana jest podczas integracji i szczegółowego testowania (problemy techniczne) i testów akceptacyjnych z użytkownikami (problemy biznesowe). Czy możemy sobie zatem pozwolić na zostawienie tych prac na sam koniec projektu? Scrum mówi, że nie: chcemy jak najszybciej integrować, testować i pokazywać Klientom kolejne fragmenty projektu, żeby jak najszybciej wykryć problemy i móc je rozwiązać zanim urosną do przytłaczających rozmiarów.

A jak Scrum pomaga planować na wiele sprintów do przodu?

Po pierwsze potrzebujemy oszacowanego (w jednostkach względnych) backlogu. Przed rozpoczęciem prac szacujemy tempo naszego zespołu w oparciu o nasze najlepsze przewidywania. Na tym etapie pewność nadal może być niska. Sytuacja diametralnie zmienia się już po kilku sprintach, w których uda nam się dostarczyć domknięte (zintegrowane, przetestowane, zrefaktorowane, udokumentowane, itd.) funkcjonalności.

Mając przed oczami jedyną realną miarę postępu w postaci dostarczonego oprogramowania możemy znacznie odważniej spojrzeć w przyszłość. Ekstrapolując dalsze postępy na podstawie średniego tempa z poprzednich trzech sprintów lub na oko wydłużając pesymistyczny i optymistyczny wariant możemy odpowiedzieć na pytania: Na kiedy dostarczymy cały backlog? albo Ile dostarczymy do świąt? Odpowiedzią będą przedziały: “prawdopodobnie między … a …” oraz “co najmniej … i raczej nie więcej niż …“.

Co jeśli musimy zobowiązać się do konkretnej daty, zakresu i ceny projektu?

Powyżej zobaczyliśmy jak Scrum pozwala wyraźniej ocenić sytuację w projekcie. Z drugiej strony wiedza ta nadal nie przekłada się na gwarancję i nadal Właściciel Produktu nie może narzucić zespołowi realizacji konkretnego zakresu w kolejnych sprintach (może jedynie dbać o to, żeby na szczycie backlogu były najbardziej wartościowe elementy i monitorować dalsze postępy w ich dostarczaniu). Co więc, jeśli chcemy starać się o kontrakt fixed-everything, czyli z ustaloną ceną, datą dostarczenia i wymaganym zakresem? Czy Scrum uniemożliwia nam realizację takich projektów?

Oczywiście, że umożliwia! Tradycyjny harmonogram również nie gwarantuje powodzenia, a kwestia czy dostawca powinien wziąć na siebie ryzyko związane z takim projektem to decyzja biznesowa całkowicie niezależna od sposobu realizacji projektu. Jedyne co zmienia Scrum to to, że szybciej nastąpi konfrontacja z rzeczywistością, dzięki czemu będziemy mogli szybciej podjąć działania naprawcze.

Jak dostarczyć więcej wartości mniejszym kosztem?

Jak już niejednokrotnie widzieliśmy, iteracyjne i inkrementalne dostarczanie produktu sprint po sprincie pozwala nam szybciej dostarczać wartość Klientom (funkcja dostarczona teraz jest warta więcej niż ta sama funkcja dostarczona za kilka miesięcy) oraz szybciej porzucić ślepe zaułki technologiczne i biznesowe (w efekcie tworząc produkt lepszej jakości i lepiej dopasowany do realnych potrzeb).

Oprócz tego dostajemy jeszcze jedną korzyść: W Scrum najbardziej wartościowe funkcje dostarczane są blisko początku projektu. Oznacza to, że po pewnym czasie kolejne porcje funkcji mają coraz mniejszą wartość.

Daje nam to większą elastyczność w podejmowaniu decyzji o zakończeniu projektu i postawieniu przed zespołem bardziej wartościowych wyzwań. Jeśli projekt zajął nam dłużej niż przewidywaliśmy możemy zrezygnować z przedłużania go bez dużej utraty wartości (to duża różnica, bo projekt waterfall w takiej sytuacji nie byłby w stanie dostarczyć nic!) albo jeśli wszystko idzie zgodnie z planem możemy wspólnie z Klientem zdecydować by wcześniej zakończyć projekt i podzielić się oszczędnościami.

Uzupełniając tą ostatnią możliwość o opcję wymiany niezrealizowanych wymagań (z zachowaniem pracochłonności) w trakcie trwania projektu otrzymyjemy model kontraktu znanego “money for nothing and your change for free“, który jest dla obu stron nie-gorszy niż kontrakt fixed-everything i pozwala skorzystać z zalet zwinności bez utraty (złudnego?) poczucia bezpieczeństwa jakie dają takie kontrakty.

 Pytania dla Was:

1. Jak często dostarczacie projekty zgodnie z uzgodnionymi terminami?
2. Czy regularny rytm dostarczania pozwoliłby Wam zwiększyć zaufanie i satysfakcję Waszych odbiorców do tego stopnia, żeby nie czuli potrzeby wymuszania długoterminowych zobowiązań?
3. Czy jesteście przekonani, że tradycyjne kontrakty wykluczają zwinność?
4. Jak często pod koniec projektu wykrywacie problemy, które wykryte wcześniej kosztowałyby Was dużo mniej?
5. Czy na bieżąco odpowiadacie na pytanie o wartość kolejnych przyrostów i porzucacie projekty, w których jest ona zbyt niska (bez widoku na poprawę)?

Ten post jest częścią cyklu Pierwsze Dni Scrum.

W pewnej firmie korytarzem przechadza się nowy manager. Zagląda przez uchylone drzwi do salki konferencyjnej, a tam? O zgrozo! Developerzy siedzą i grają w karty? Cóż za bezczelność! Jest jednak nowy więc zanim zgłosi przestępców do HR postanawia bliżej zbadać temat. Wchodzi do salki a tam…

Jak działa Planning Poker?

W kontekście Scrum Planning Poker to metoda szybkiego i skutecznego szacowania względnego rozmiaru elementów backlogu przez zespół, który będzie je realizował, używając umownych jednostek znanych punktami (lub pingwinami).

W Planning Poker gra się talią zawierającą karty: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, nieskończoność, ? i kawa.

Rozgrywka przebiega następująco:

Zespół wybiera element backlogu, który sprawia wrażenie najmniejszego i arbitralnie przypisuje mu jednego pingwina, a następnie dla każdego kolejnego elementu backlogu:

1. Właściciel Produktu wyjaśnia znaczenie i kontekst elementu i odpowiada na pytania zespołu.
2. Po chwili zespół przystępuje do szacowania:
   • Każdy członek zespołu szacuje jak ma się omawiany element do wzorcowego, uwzględniając pracę całego zespołu.
   • Gdy gracz zdecyduje jakie jest jego oszacowanie, wykłada odpowiednią kartę tak, by inni nie widzieli jej wartości.
3. Gdy wszyscy już dokonają swojego wyboru karty są odkrywane:
   • Jeśli oszacowanie jest zgodne to zapisujemy wynik i przechodzimy do następnego elementu.
   • Jeśli oszacowania różnią się co najwyżej o jeden przeskok to bierzemy wyższe oszacowanie i przechodzimy do następnego elementu.
   • Jeśli różnica jest większa to osoby, które zagrały najniżej i najwyżej wyjaśniają swoją decyzję.
   • Jeśli wynikiem szacowania jest nieskończoność oznacza to, że historyjka jest za duża do oszacowania.
   • Jeśli ktoś zagra ?, oznacza to, że historyjka wymaga dalszego wyjaśnienia.
   • Jeśli ktoś zagra kawa to znaczy, że czas na przerwę regeneracyjną.
4. Jeśli jest to konieczne to powtarzamy rundę – gracze wykładają zakryte karty uwzględniając wnioski z dyskusji.
5. Rundy szacowania są powtarzan do skutku lub do znudzenia. Jeśli zespół nie będzie w stanie dojść do porozumienia w 3-4 rundy to znaczy, że historyjka wymaga dopracowania (np. przeformułowania, podzielenia lub okrojenia).

Dlaczego Planning Poker?

Zamiast wyliczać najczęściej przytaczane zalety Planning Pokera odeślę Was choćby do fragmentu książki Mike’a Cohn’a “Agile Estimation & Planning” a tutaj skoncentrujemy się na dwóch rzadziej omawianych korzyściach, która mogą mieć większe znaczenie niż wynikowe oszacowanie:

Planning Poker stymuluje dyskusję o tym, co ma być zrobione – liczby, które wychodzą z sesji PP są ważne, ale jeszcze ważniejsze od nich są dyskusje podczas szacownia! W ten sposób masowo odkrywane są ukryte założenia przyjmowane przez uczestników, zarówno co do zakresu jak i sposobu realizacji prac. Wszystkie ustalenia pojawiające się w czasie tych dyskusji powinny zostać zapisane w formie kryteriów akceptacji dla szacowanego elementu, żeby później uniknąć wątpliwości na temat jego realizacji i późniejszego odbioru przez PO.

Planning Poker wspiera formowanie się zespołu – dyskusja wokół szacowania kolejnych fragmentów backlogu konfrontuje zespół z potrzebą dojścia do wspólnego zrozumienia zakresu zadań i sposobu ich realizacji. Scrum Master powinien dbać o to, żeby podczas szacowania zespół występował jako spójna, współodpowiedzialna jednostka. Nieporządane są sytuacje, w których jeden z członków zespołu zrezygnowałby z wyrażenia swojej opinii lub odmówił komuś innemu takiego prawa ze względu np. na “brak kompetencji w danej specjalności”. Faktem jest (i Scrum Master powinien o tym w razie potrzeby przypomnieć), że każdy członek zespołu wnosi istotną wartość do całego procesu. W przeciwnym wypadku nie byłby członkiem tego zespołu!

Może coś prostszego?

Nie zawsze potrzebujemy szacować z tak dużą rozdzielczością, jaką oferuje Planning Poker. Jeśli dodatkowy wysiłek nie przełoży się na możliwość podejmowania lepszych decyzji to może nam wystarczyć prostszy system szacowania, w której każdemu elementowi backlogu przypisujemy jeden z trzech rozmiarów: S, M i L, które można wyskalować np. tak:

• S – możemy zrobić ~10 takich elementów w sprincie,
• M – mniej więcej trzy w sprincie,
• L – wypełnia prawie cały sprint.

Wszystkie większe historyjki oznaczamy jako za duże i przed oszacowaniem okrajamy lub rozbijamy na mniejsze.

Wymaga to większego wysiłku, by nieco znormalizować rozmiar proponowanych historyjek, ale wysiłek ten może z nawiązką zwrócić się poprzez wyższą jakość backlogu, który w ten sposób powstanie. Uproszczona komunikacja podczas szacowania elementów jest zastąpiona dyskusją o ich podziale. Tracimy za to możliwość zgrubnego oszacowania dużych historyjek przed ich rozbiciem.

Idąc dalej możemy zamiast na szacowaniu różnorodnych elementów skoncentrować się na podziale kolejnych ulepszeń w taki sposób, by wszystkie miały podobny rozmiar. Ta metoda nie jest często stosowana, ale na pewno powinna znaleźć się wśród dostępnych narzędzi.

W skrajnym przypadku możemy w ogóle nie przejmować się szacowaniem. Np. twórcy gier komputerowych dysponujący odpowiednio dużym budżetem (np. Valve) często rozwijają produkt, aż uznają, że jest gotowy, nie stosując żadnych metod formalnego obliczania, kiedy to może nastąpić.

Zadanie dla Was:

1. Jak szacujecie rozmiar planowanych prac?
2. Czy w szacowaniu zaangażowane są wszystkie osoby, które będą odpowiedzialne za realizację (czyli cały zespół)?
3. Czy to szacowanie pozwala Wam podejmować lepsze decyzje?
4. Spróbujcie oszacować przykładową porcję wymagań za pomocą prostszej metody, niż zwykle stosujecie.

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Co to jest historyjka użytkownika (user story)?

Historyjki użytkownika to metoda formułowania wymagań często wykorzystywana przez zespoły Scrum. Historyjki mają często formę “Jako <rola>, chcę <funkcja>, żeby <wartość>.”. Jeśli nigdy wcześniej nie słyszałeś o historyjkach znajdziesz niezłe wprowadzenie w serwisie Mountain Goat Software, Mike’a Cohn’a.

Czego można się spodziewać po historyjkach?

Co jakiś czas pomagamy zespołom rozpocząć stosowanie historyjek użytkownika. Najczęściej obserwujemy następujące korzyści:

1. Lepszą komunikację – Historyjki użytkownika przenoszą dyskusję z poziomu technicznego na poziom opowieści z żywymi aktorami, które dużo lepiej wspierają bezpośredni dialog z odbiorcami, niezbędny do dostarczania najbardziej przydatnych rozwiązań.
2. Lepszą selekcję – Częste zadawanie pytań: “Dla kogo to robimy?” “Co on z tego będzie miał?” pozwala odrzucić dużą część zadań a oszczędzony czas zainwestować w szybsze dostarczenie priorytetowych ulepszeń, podniesienie jakości tworzonego kodu i/lub stopniową spłatę długu technicznego.
3. Więcej kreatywności – Inżynierom bardzo łatwo koncentrować się na rozwiązaniach. Jeśli jednak konkretne rozwiązanie zostanie wdrukowane w wymagania na zbyt wczesnym etapie zabieramy sobie możliwość odkrycia czegoś lepszego.
4. Więcej satysfakcji – to często niedoceniana korzyść, a znacznie wpływa na długofalową produktywność zespołu. Regularnie widząc konkretną wartość w rekach użytkowników członkowie zespołu mogą czerpać więcej dumy ze swojej pracy, w porównaniu z mechanicznym odhaczaniem zadań.

Na co warto uważać w kontekście historyjek?

Jak wszystkie inne metody organizacji pracy, także historyjki użytkownika nie są magiczną różdżką rozwiązującą wszelkie problemy. W naszej pracy z zespołami najczęściej przewijają się następujące problemy, które w dużej mierze sprowadzają się do próby opakowania w język historyjek dotychczasowych przyzwyczajeń:

1. Opowieści o wodospadzie – jeśli w naszym backlogu pojawiają się historyjki typu “Jako zespół chcę przygotować koncepcję rozwiązania, żeby móc kontynuować prace” lub “Jako zespół chcę przetestować system, żeby upewnić się, że nie ma w nim błędów.” to Scrum nie przyniesie nam oczekiwanych korzyści. Dzieląc pracę w ten sposób odkładamy na później dostarczenie konkretnego rozwiązania, a co za tym idzie nie skorzystamy z możliwości wcześniejszego odkrycia problemów. Zostawiając testy na koniec będziemy też mniej uwagi poświęcać jakości realizowanych historyjek i w konswekwencji nie będziemy pewni postępów, bo każda “dostarzczona” historyjka może się okazać pełna błędów i wymagać jeszcze dużo pracy.
2. Brak (samo)dyscypliny – w pogoni za źle pojętym poczuciem sukcesu zdarza się, że zespoły, nawet w porozumieniu z Właścicielem Produktu zgadzają się na uznanie za zakończone historyjek, które nie spełniają w uzgodnionych Kryteriów Akceptacji i Definicji Ukończenia. Najczęściej ofiarą są w takim przypadku testy. Podobnie jak w dziedzinie higieny osobistej szkody nie przyjdą natychmiast, ale w środowisku pełnym zarazków, jedynie kwestią czasu jest pojawienie się poważniejszych zakarzeń.
3. Podział według pracy do wykonania, a nie wartości do dostarczenia – dużą pokusą dla istniejących organizacji jest podział prac według komponentów systemu lub specjalistycznych zespołów. Podobnie jak w przypadku opowieści o wodospadzie prowadzi to do opóźnienia dostarczenia gotowych rozwiązań i późniejszego wykrywania problemów. Tak często jak to możliwe chcemy “kroić tort” czyli dostarczać smakowite kąski obejmujące wszystkie warstwy produktu. Pytaniem, jakie powinniśmy sobie zadawać nie jest “Jak podzielić naszą pracę na historyjki?”. Dużo łatwiej skorzystać z silnych stron tej metody pytając “Jak zorganizować naszę pracę, by w najbliższym sprincie dostarczyć największą możliwą wartość?”
4. Dylemat “Czy to historyjka?” – Najwięcej czasu zajmują zawsze dyskusje, w których nie ma jednoznacznych odpowiedzi. Czasem lepiej jest po prostu uciąć taką dyskusję. Ogólna zasada jest taka, że wszystko co ma zrobić zespół z produktem powinno być w Backlogu. Dla każdego elementu Backlogu warto też zadać pytania o odbiorcę i wartość, lecz jeśli mimo to zadanie nie pasuje do formy user story to nie warto na siłę wtłaczać go w ten gorset. Tak jak wspomnieliśmy wczoraj: eksperymenty techniczne, bugi i inne zadania też mogą być częścią backlogu.

Jakie pisać dobre historyjki?

Pełna odpowiedź na to pytanie wykracza poza zakres niniejszego artykułu. Oprócz oczekiwanych korzyści i ostrzeżeń opisanych powyżej dobrą techniczną wskazówką jest analog SMART-celów w postaci skrótowca INVEST. Więcej o pisaniu dobrych historyjek można też przeczytać w książce “User Stories Applied” Mike’a Cohn’a.

Pytania dla Was:

1. Czy dla każdego zadania zadajecie sobie pytanie komu ma ono służyć i im ma dać?
2. Jak często nieudana próba odpowiedzi na te pytania powoduje, że odrzucacie zadanie?
3. Czy w Waszym zespole obserwujecie spodziewane korzyści z wykorzystania historyjek? Czy obserwujecie któryś z typowych problemów z historyjkami użytkownika? Jak możecie mu zaradzić?
   1. Jeśli tak to jak moglibyście jeszcze wzmocnić ten efekt?
   2. Jeśli nie to jaki jest źródłowy powód? Zadajcie pięć razy pytanie “dlaczego?”.
4. Jak możecie podnieść Wasze (zespołu, PO, Klientów) umiejętności pisania i czytania historyjek użytkownika? Czy pomogłoby Wam zorganizowania wspólnych warsztatów treningowo-roboczych?

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Wczoraj rozmawialiśmy o tym, jak ważną rolę w Scrum pełni Właściciel Produktu i jego główne narzędzie komunikacji, jakim jest Backlog Produktu. Dzisiaj przyjrzymy się temu, jak powinien wyglądać Backlog, żeby dobrze pełnił swą rolę.

Do czego właściwie służy Backlog?

Backlog Produktu jest narzędziem planowania. Planowanie to ma dwa główne cele:

1. pomagać zespołowi jak najszybciej dostarczać największą możliwą wartość,
2. ułatwić organizację pracy i śledzenie jej postępów.

Jakie są cechy dobrego backlogu?

Aby skutecznie realizować wyżej wymienione cele Backlog powinien być:

1. Zrozumiały dla PO, zespołu i odbiorców – tylko wtedy może stymulować i wspierać rozmowy, które są niezbędne do określenia gdzie leży wartość i jak zespół może ją dostarczyć uwzględniając ograniczenia osobowe, techniczne i organizacyjne.
2. Uporządkowany z uwzlędnieniem wartości, pracochłonności i ryzyka, w taki sposób, żeby jego sukcesywne realizowanie przynosiło organizacji największe możliwe korzyści. Nie istnieje jednoznaczny algorytm pozwalający pogodzić wszystkie te czynniki: odpowiednie ich wyważenie powinno wyłaniać się z komunikacji między PO, zespołem i odbiorcami.
3. Żyjący – Backlog powinien ewoluować wraz z wzrastającą wiedzą wszystkich zainteresowanych. Wymagania “na teraz” powinny być GOTOWE (patrz niżej), a dalsze plany mogą być jedynie naszkicowane. Powinniśmy unikać przeinwestowania w szczegółowe rozpisanie backlogu na wiele miesięcy do przodu, bo praca ta zostanie zmarnowana przez nieuniknione zmiany.

Nie tylko historyjki

W zwinnych zespołach elementy backlogu najczęściej mają formę historyjek użytkownika (którymi zajmiemy się jutro). Nie jest to jednak obowiązek. Elementy backlogu mogą mieć też inne formy:

1. Hasłowe określenie tematu historyjki, o ile jest zrozumiałe dla wszystkich zainteresowanych.
2. Bardziej szczegółowy opis funkcjonalności np. w formie pełnych przypadków użytkownika (use case)  lub wręcz siatek poszczególnych widoków. Takie podejście ma swoje wady, ale czasem jest właściwym rozwiązaniem.
3. Defekt odkryty po zakończeniu sprintu (warto zainwestować w jakość wewnątrz sprintu, by było ich jak najmniej).
4. Eksperyment techniczny nie będący realizacją konkretnej funkcjonalności, ale pozwalający odpowiedzieć na ważne pytania i podjąć lepsze decyzje co do dalszego rozwoju produktu.
5. Cel biznesowy bez określenia sposobu jego realizacj. W takim przypadku warto określić:
   • wartość jaka nas interesuje np. łatwość użycia, responsywność lub konwersja,
   • miarę, która pozwoli nam zmierzyć tą wartość np. % wykonania zadania z sukcesem w testach z 20 użytkownikami, czas oczekiwania na otwarcie danej strony lub konwersja (w tym przypadku wartość jest jednocześnie miarą).
   • punkty odniesienia np. w przypadku responsywności: zastępowany system: 1 min, obecna wersja nowego systemu: 30 sek, główny konkurent: 15 sek, nasz cel: 10 sek.

Ta ostatnia metoda zostawia najwięcej swobody zespołowi, co pozwala najskuteczniej wykorzystać pełen zakres kompetencji i kreatywności jego członków, lecz jest też najbardziej wymagająca z punktu widzenia psychologicznego i organizacyjnego.

Co to znaczy, że element backlogu jest GOTOWY?

Elementy backlogu zakończone przez zespół w danym sprincie muszą być zrobione “na gotowo” (czyli spełniać Definicję Ukończenia, ang. Definition of Done). W przeciwnym wypadku Właściciel Produktu nie może ich zaakceptować i nieskończone elementy smutno wracają do Backlogu by być zrepriorytetyzowane (i być może porzucone). Tak samo historyjki przedstawiane przez PO do realizacji powinny być GOTOWE do realizacji.

Co to znaczy gotowe? Dobrze opisuje ten problem Roman Pichler w artykule “The Definition of READY”. Według Romana najważniejsze jest by GOTOWE elementy backlogu były:

1. zrozumiałe i jednoznaczne (clear) – wszyscy zainteresowani muszą rozumieć o co chodzi,
2. testowalne – musi się dać jednoznacznie odpowiedzić na pytanie czy dany element działa poprawnie,
3. realistyczne – muszą być możliwe do zrealizowania przez zespół w jeden sprint, uwzgledniając też przewidywane zaburzenia w pracy (urlopy, święta, wydarzenia firmowe, nagłe ataki zimy, itd.).

To dobre kryteria, jednak zawsze powinny być przez Was uzupełnione i dostosowane do Waszych potrzeb. Wynikająca z tych ustaleń Definition of Ready powinien być zapisany w powszechnie dostępnym miejscu tuż obok Definition of Done, a zespół powinien mieć prawo (i obowiązek) by nie przyjmować do realizacji historyjek, które nie są GOTOWE.

Kiedy w Scrum zajmujemy się Backlogiem?

Z powyższych rozważań wynika, że wytworzenie i utrzymanie dobrego backlogu może być bardzo pracochłonne. Wysiłek ten jednak zwraca się z nawiązką już po kilku sprintach i dlatego warto zarezerwować w procesie odpowiednio dużo czasu na pracę nad backlogiem. W Scrum przyjmuje to formę następujących wydarzeń:

1. Planowanie Wydania – obejmuje wzmożoną pracę PO, który wspólnie z zespołem i w porozumieniu z odbiorcami musi przygotować listę rzeczy do zrobienia wykraczającą tak daleko w przyszłość, jak jest to niezbędne (zwykle kilka sprintów lub kwartał) i doprowadzić najbliższe zadania do stanu GOTOWOŚCI.
2. Planowanie Sprintu – to ostatnia szansa na dopracowanie najpilniejszych historyjek. Obejmuje szczegółowe omówienie ich znaczenia oraz proponowanego rozwiązania oraz przyjęcie danego elementu przez zespół do realizacji.
3. Backlog Grooming (pielęgnacja lub “czesanie” backlogu) – to worek na mniej obciążające prace równomiernie rozprowadzone między pozostałe prace. W ramach pielęgnacji backlogu PO sam ulepsza, przepisuje i zmienia kolejność elementów backlogu, deleguje część tych zadań na zespół oraz potwierdza trafność i aktualność nadchodzących zadań z odbiorcami systemu. Dobrą praktyką jest zarezerwowanie około 10% czasu zespołu na pielęgnację backlogu. Jeśli zespół poświęca na to mniej czasu to backlog będzie zbyt oderwany od realiów ich pracy, a jeśli dużo więcej to zaburzy realizację bieżacych zadań.

Pytania dla Was:

1. Czy macie jedno miejsce, w którym zebrane są wszystkie źródła wymagań dla pracy zespołu?
2. Czy Wasz backlog jest zrozumiały dla wszystkich zainteresowanych?
3. Czy zawsze na szczycie listy znajdują się rzeczy najważniejsze?
4. Czy na bieżąco pielęgnujecie backlog uwzględniając najświeższe informacji?
5. Czy wymagania na szczycie backlogu są GOTOWE?

6. Kiedy Wasz backlog działa najlepiej?
7. Co moglibyście zrobić, żeby częściej działał w ten sposób?

Co dalej?

Jutro przyjrzymy się bliżej historyjkom użytkownika, w czwartek omówimy Planning Poker – popularną metodę wymiany informacji ukrytą pod postacią metody szacowania, a w piątek zajmiemy się długofalowym planowaniem.

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Jeśli zespół jest sercem Scrum a sprinty są rytmem, w jakim ono bije to elementy backlogu są krwią, którą to serce pompuje.

… a za Backlog w pełni odpowiedzialny jest Właściciel Produktu.

Jego rola jest najbardziej odpowiedzialną i zarazam najbardziej niedocenianą rolą w Scrum. Według współtwórcy Scrum Jeffa Sutherlanda, niskiej jakości backlog może łatwo doprowadzić do obcięcia tempa zespołu o połowę. Przyjmijmy oszczędnie, że mamy zespół, który kosztuje firmę coś w okolicach 50 tys. zł miesięcznie. Ile warto zainwestować, żeby upewnić się, że zespół pracuje nad tym, co rzeczywiście ma największe przełożenie na biznes? Ile nas będzie kosztowała walka ze źle podzielonym, niejasnym, nietrafnym backlogiem?  Zgodnie ze znaną zasadą Garbage In, Garbage Out nawet świetny zespół nie wyprodukuje nic wartościowego na bazie słabego backlogu. Dobry backlog to też podstawa pomiaru i adaptacji – musimy dobrze rozumieć co i po co budujemy, żeby móc skutecznie śledzić postępy i właściwie reagować na nowe informacje.

Scrum Guide
Definicja reguł Scrum – Scrum Guide – mówi, że: “Właściciel Produktu (ang. Product Owner) jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego.” oraz “Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny.” Dodaje też: “Aby Właściciel Produktu mógł odnieść sukces, cała organizacja musi respektować jego decyzje.”.

Oznacza to, że PO musi łączyć głęboką wiedzę dziedzinową ze zrozumieniem technologii stosowanej przez zespół, by móc skutecznie wyjaśniać kontekst biznesowy pracy zespołu i zarazić członków zespołu empatią dla odbiorców systemu i entuzjazmem dla rozwiązania ich problemów. Jak podkreśla Scrum Guide musi też posiadać odpowiednią dozę autorytetu wobec innych jednostek w organizacji.

Wszystko to oznacza, że Właścicielem Produktu powinna być najwyżej postawioną osobą, która jest dostępna dla zespołu. W relacji Klient-Dostawca najlepiej, gdyby był nim ktoś po stronie Klienta. Stoi to jednak w sprzeczności z potrzebą zainwestowania dużej ilości czasu i energii w “inżynierię wymagań” przez regularną pielnęgnację formy i treści poszczególnych historyjek.

Dlatego tak ważne jest odpowiednie uformowanie relacji między PO a zespołem w taki sposób, by zespół mógł wesprzeć Właściciela Produktu w porządkowaniu backlogu z zachowaniem pełnej głębi jego biznesowej wizji.

Rola PO według Henrika Kniberga

Henrik Kniberg – znany Agile Coach ze Szwecji, obecnie pracujący w Spotify, nagrał ostatnio bardzo dobry filmik trafnie podsumowujący rolę PO.

Wybrane spostrzeżenia Henrika z jego prezentacji:

1. Głównym zadaniem PO jest określenie “Jaki problem powinniśmy rozwiązać i dla kogo?”.
2. Największym wyzwaniem jest zarządzanie oczekiwaniami odbiorców poprzez umiejętną selekcję pomysłów i życzeń umieszczanych w backlogu.
3. O ile misją PO jest maksymalizacja wartości pracy zespołu to wartość ta nie zawsze ma postać funkcjonalności dostarczanej klientom – często wartością jest wiedza pozwalająca zminimalizować ryzyko:
   • biznesowe (że produkt nie będzie naprawdę przydatny),
   • osobowe (że nasz zespół nie będzie w stanie zbudować produktu),
   • techniczne (że wybrana technologia nie sprosta wyzwaniu),
   • oraz budżetowo/harmonogoramowe (że nie zdążymy zbudować produktu na czas i poniesiemy dodatkowe koszty).

To tylko wybrane spostrzeżenia, cały filmik trwa tylko 15 minut i jest wart obejrzenia w całości:

[youtube http://www.youtube.com/watch?v=502ILHjX9EE]

Lean Startup

Marek Kirejczyk, współzałożyciel firmy Aenima i grupy Agile Warsaw nazwał go zaginionym podręcznikiem Product Ownera. Główną tezą Lean Startup (oraz wcześniejszej metodologii Customer Development, z której czerpie inspirację) jest, że tworząc nowy produkt naszym pierwszym zadaniem powinno być nie tyle zbudowanie jak największej liczby funkcjonalności, co raczej zweryfikowanie założeń biznesowych stojących za pomysłem na produkt.

W kontekście produktów na rynek masowy główne pytanie brzmi: Czy nasz model biznesowy jest powtarzalny i (opłacalnie) skalowalny? W kontekście projektów dla pojedyńczego odbiorcy pytanie sprowadza się do: Czy na pewno rozumiemy prawdziwe potrzeby Klienta?

Lean Startup dostarcza też narzędzi do poszukiwania odpowiedzi na te pytania. Wśród nich wyróżnia pętlę Build-Measure-Learn, czyli znaną pętlę tworzenia gotowego produtku po każdym sprincie rozbudowaną o rygorystyczny pomiar skuteczności produktu w osiąganiu założonych celów (przyciągania uwagi klientów, konwersji, utrzymania, …). Lean Startup nazywa wiedzę zdobytą w ten sposób wiedzą zweryfikowaną (Validated Learning) a wśród stosowanych miar wyróżnia tzw. Actionable Metrics, na podstawie których można podejmować trafne decyzje co do dalszych działań oraz Vanity Metrics, które służą co najwyżej do połechtania ego twórców.

Dowiedz się więcej na stronie ruchu Lean Startup.

Zadanie dla Was:

Dla Właściciela Produktu: Co jest najważniejsze dla naszych Klientów? Wypisz trzy najważniejsze wartości i omów je z zespołem – jak możecie dostarczyć jeszcze więcej tej wartości tym samym, albo mniejszym nakładem pracy?

Dla zespołu: Jak możecie pomóc PO przygotowywać lepszy backlog? Bardziej przejrzysty i zrozumialy? Pozwalający łatwiej śledzić postępy prac? Pozwalający szybciej dostarczyć realną wartość?