Tag: Pierwsze Dni Scrum

Witamy po długiej przerwie. Niniejszym wznawiamy cykl “Pierwsze Dni Scrum” i wchodzimy w obszar wykraczający poza uniwersalne reguły Scrum, lecz ważny dla wszystkich zespołów stosujących Scrum w obrębie inżynierii oprogramowania, a mianowicie ZPI – zwinny praktyki inżynierskie. Ale zacznijmy od początku:

Dlaczego szybkie dostarczanie “działającego oprogramowania” nie wystarczy?

Wyobraźmy sobie taką sytuację: nasz Właściciel Produktu ma świetny pomysł na biznes i dokładnie wie jak przekazać swoją wizję zespołowi, zespół dobrze rozumie jak działa Scrum i sprawnie się samoorganizuje pod opieką doświadczonego Scrum Mastera, który tydzień w tydzień rozbija w pył wszelkie przeszkody organizacyjne. Mijają sprinty, przyrosty przyrastają, pierwsi Klienci kupują, PO jest zadowolony, zespół jest zadowolony, management się cieszy. Bajka…

Błogostan trwa kilka miesięcy, lecz stopniowo, jakby nie wiadomo skąd, pojawia się coraz więcej zgrzytów:

• znajdujemy coraz więcej błędów i ich naprawianie zajmuje coraz więcej czasu,
• coraz częściej naprawienie jednego błędu powoduje zepsucie czegoś innego,
• dodanie nawet prostych funkcji zajmuje dużo dłużej niż na początku,
• tempo prac (velocity) maleje mimo ulepszeń organizacyjnych wprowadzanych po retrospekcjach.

PO i management myśli sobie, że zespół przestał się starać, więc próbuje zastosować techniki pseudo-motywacji rodem z call center banku detalicznego, wysyłając sygnał, że zespół nie zasługuje na zaufanie i szacunek i musi być zdalnie sterowany i kontrolowany przez czujnych managerów. Zespół próbuje wyjaśnić, że powodem jest wzrastająca złożoność systemu i że to nie ich wina, ale kierownictwo odbiera to jako wymówki. Motywacja spada, produktywność jeszcze bardziej, Klienci zaczynają oglądać się za konkurencją.

Sytuacja tylko się pogarsza szczególnie, że nikt nie zaadresował prawdziwego problemu, gdyż:

Czy da się utrzymać wysokie tempo prac zaniedbując jakość kodu?

Czy znalazłeś się kiedyś w sytuacji, kiedy konieczność szybkiego dostarczania użytkownikom nowych funkcji zdominowało wszystko inne, w tym jakość wewnętrzną (mierzoną np. liczbą WTF/min podczas code review), a nawet zewnętrzną (liczba błędów i niedociągnięć widocznych dla użytkowników)? Czy szef powiedział Ci kiedyś, że “ma poprawnie działać dla użytkowników, a w środku choćby na zapałki” albo “wystarczy jakość na 80%, byle byśmy szybko dostarczyli nowe funkcje“.

To może być rozsądna strategia biznesowa, zakładając, że decydenci w pełni rozumieją konsekwencje swoich decyzji. Jest to problem, bo świetni biznesmeni i managerowie produktu rzadko są jednocześnie doświadczonymi architektami a doświadczeni architekci rzadko świetnie rozumieją reguły biznesu.

Jak w tej sytuacji optymalnie wykorzystać wiedzą i doświadczenie obu stron?

Dług techniczny

Na ratunek przychodzi pojęcie długu technicznego (ang. technical debt), które pozwala obu stronom popatrzeć na postawiony wyżej problem w ich naturalnym języku. Metafora ta została użyta po raz pierwszy przez Warda Cunninghama w 1992 roku. Ward porównał w ten sposób pośpieszną produkcję kodu do szybkiej ekspansji, finansowanej kredytem. Dzięki niemu możemy szybciej osiągnąć nasze cele, lecz w naszej długoterminowej strategii musimy uwzględnić spłatę zaciągniętego długu i liczyć się z tym, że zbyt długie zwlekanie ze spłatą spowoduje narośnięcie kosztownych odsetek. Jeżeli nie poświęcimy czasu na przywrócenie odpowiedniej jakości kodu, coraz trudniej będzie go utrzymywać i rozwijać.

Takie postawienie sprawy pozwala zrównoważyć obie perspektywy. Z jednej strony inwestowanie w jakość może nie mieć uzasadnienia ekonomicznego i architektom łatwiej to zaakceptować, jeśli za cel postawią sobie optymalizację wartości biznesowych, a nie tylko techniczne aspekty produktu. Z drugiej strony odbiorcy staną się świadomi konsekwencji ścinania zakrętów i chętniej zainwestują w jakość widząc jej bezpośredni wpływ na długofalowe utrzymanie wysokiego tempa rozwoju.

Dlaczego nie zawsze dbamy o jakość kodu?

Bo to trudne.

Dlatego, choć nie mam przed oczami statystyki na ten temat, wiem, że większość zespołów nie dba o jakość kodu z zapałem niezbędnym do utrzymania wysokiego tempa rozwoju.

Aby zwiększyć swoje szanse musimy ukształtować nasze otoczenie w taki sposób, by czynniki wspierające znacznie przeważały nad przeszkodami. Przydatny model opisuje Jurgen Appelo w swojej książce “Jak zmienić świat“. Według modelu ADKAR przeszkodą blokującą udaną zmianę może być między innymi:

• Brak świadomości problemu (Awareness) – brak bolesnego doświadczenia zespołu, Właściciela Produktu i kierownictwa w zakresie długofalowych konsekwencji zaniedbania jakości kodu. Co gorsza może się okazać, że w przeszłości osoby te wykopały się z dołka niskiej jakości za pomocą dużej dawki morderczego wysiłku z domieszką szczęścia i teraz uważają, że heroiczny wysiłek i improwizacja niwelują potrzebę systematyczności i proaktywnego inwestowania w jakość.
• Brak motywacji lub aktywna demotywacja (Desire) – jeśli osoba posiadająca władzę w organizacji explicite stawia inne korzyści ponad jakością trudno wykrzesać w sobie chęć dyskutowania. Odpowiedzialny profesjonalista znajdzie sposób, by pokazać jak wysoka jakość wpłynie na sukces w języku odbiorcy i czym grozi jej zaniedbanie, ale często łatwiej jest po prostu podporządkować się obowiązującym oczekiwaniom i zrzucić odpowiedzialność z własnych barków.
• Brak wiedzy i umiejętności (Knowladge i Ability) – inżynieria złożonych systemów jest po prostu trudna. Nawet doświadczeni specjaliści muszą włożyć dużo wysiłku w stosowanie dobrych praktyk i ciągłe poznawanie nowych. Bez wiedzy i umiejętności dobre chęci nie wystarczą.
• Brak mechanizmów utrwalających (Reinforce) –  wszystkich powyższych przeszkód nie wystarczy zaadresować raz i o nich zapomnieć. Dla długofalowego sukcesu potrzebne są długofalowe mechanizmy wspierające i utrwalające pozytywne aspekty naszych praktyk oraz niewelujące zagrożenia.

Jak się pozbyć długu technicznego i zapobiegać nierozsądnemu jego zaciąganiu?

Chcesz uniknąć przeistoczenia Twojego zespołu w grupę szambonurków? Przy rosnącej złożoności systemu nie jest to łatwe. Na pewno czeka Cię duży wysiłek. Nagrodą za ten wysiłek jest sukces Twojej organizacji i budowanie Twojej reputacji jako wysokiej klasy profesjonalisty.

Aby odwrócić, albo chociaż spowolnić, zaciąganie długu technicznego albo spłacić wcześniej zaciągnięty dług potrzebne są świadome działania. Jest milion różnych podejść, niżej wybraliśmy dla Ciebie najważniejsze:

Pisząc nowy kod możesz:

• automatyzować testy jednostkowe, integracyjne i funkcjonalne oraz uruchamiać je przy każdej zmianie za pomocą serwera Continuous Integration,
• stosować programowanie zorientowane na testy (Test Driven Development),
• programować w parach,
• dbać o (samo)edukację w zakresie technik pomagających utrzymywać wysoką jakość kodu,
• utrzymywać wysoką czytelność kodu (mierzoną chociażby zrozumiałością dla innych członków zespołu) jako jedno z ważnych kryteriów jakości.

Pracując z istniejącym kodem możesz:

• refaktoryzować, aż do usunięcia prawie wszystkich brzydkich zapachów i osiągnięcia czystego kodu, z którego dumny byłby nawet Wujek Bob.
• stosować statyczną analizę kodu (i poprawiać wykryte usterki),
• badać pokrycie kodu przez testy,
• stosować przeglądy kodu.

W ramach kolejnych dni z cyklu porozmawiamy więcej o wybranych technikach i korzyściach, jakie one wnoszą, a tymczasem zostawimy Cię z dwoma pytaniami.

Pytania do Was:

• Jak często rozmowy między “IT” a “biznesem” na temat jakości kodu i innych spraw technicznych udaje się w Twojej organizacji zakończyć porozumieniem uwzględniającym potrzeby wszystkich zainteresowanych?
• Co robisz na co dzień, by zminimalizować narastanie długu technicznego lub sukcesywnie spłacać dług który nagrabiliście sobie wcześniej?

Skontaktuj się z nami, jeśli chcesz podzielić się swoimi doświadczeniami lub chciałbyś skorzystać z naszej pomocy w osiąganiu Twojego sukcesu.

Marcin Zajączkowski i Michał Parkoła

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

Umiejętność wyciągania wniosków z własnych doświadczeń jest podstawą uczenia się i rozwoju. Krótka pętla zbierania danych, planowania ulepszeń i wprowadzania ich w życie jest niezbędnym elementem empirycznego podejścia, jakim jest Scrum.

Tak samo jak co Sprint dostarczamy kolejne ulepszenia w naszym produkcie tak powinniśmy co sprint ulepszać środowisko naszej pracy, stosowane metody i narzędzia oraz wszystkie inne czynniki (na które mamy wpływ), które pozytywnie lub negatywnie wpływają na naszą efektywność.

W Scrum okazją do przejścia tego procesu są Retrospekcje, które odbywają się pod koniec każdego Sprintu.

Szkielet Retrospekcji

Jak piszą boginie retrospekcji Esther Derby i Diana Larsen w książce “Agile Retrospectives“, każde takie wydarzenie powinno w takie czy innej formie zawierać następujące kroki:

1. Ustal uwagę (Set the Stage) – przywołaj cel retrospekcji i podstawowe zasady (zakaz obwiniania jednostek, ulepszanie systemu, …). Ustal ramy czasowe i organizacyjne.
2. Zbierz dane (Gather Data) – zawsze staraj się zebrać i wspólnie przyjąć do wiadomości jak najwięcej faktów na temat przebiegu sprintu. Od liczby i rodzaju napotkanych bugów po nastrój poszczególnych członków zespołu w kolajnych dniach.
3. Zrozum sytuację (Generate Insight) – zadbaj o to, żeby cały zespół wypracował wspólne zrozumienie tego, co oznaczają zebrane fakty i jak można ich użyć by poprawić sytuację.
4. Zaplanuj działanie (Decide What to Do) – na podstawie wspólnego zrozumienia sytuacji zaplanujcie konkretne zmiany, które mogą pomóc Wam skuteczniej i przyjemniej pracować. Plany te powinny być możliwie konkretne, uwzględnione w planie kolejnego sprintu i najlepiej powiązane z pomiarem, który jednoznacznie odpowie na pytanie, czy zmiana przyniosła oczekiwane efekty.
5. Podsumuj retrospekcję (Close the Retrospective) – podziękuj wszystkim za uczestnictwo i powtórz, co zostało zaplanowane.

Powyższe kroki można zrealizować mniej lub bardziej wprost lub wpleść je w różnorodne plany retrospekcji, o jakich można przeczytać lub pomyśleć. Retrospekcje nie muszą (i nie powinny) być zawsze takie same, jednak lekkomyślne pominięcie któregoś z tych elementów może zatrzeć granicę między wartościową retrospekcją a czystą rozrywką lub wręcz destruktywną sesją narzekania.

Pomysły na retrospekcje

Skąd brać pomysły na skuteczne i angażujące retrospekcje? Jak słusznie zauważa Paweł Brodziński, czasem Scrum Master powinien powściągnąć swoje kreatywne zapędy i zaczerpnąć pomysły z samego zespołu. Nawet “obiektywnie lepsza” metoda przegra w konkurencji z podejściem wywiedzionym z naszego realnego środowiska.

Jeśli mimo to szukasz inspiracji, istną kopalnią pomysłów jest wspomniana wyżej książka. Wiele schematów retrospekcji można też znaleźć w internecie. Tutaj przytoczymy zaś trzy:

Mad, sad, glad – zadaj wszystkim razem i każdemu z osobna trzy pytania:

1. Z czego jesteś zadowolony (glad)?
2. Co Cię smuci (sad)?
3. Co Cię wkurza (mad)?

Statek: żagiel i kotwica – wyobraźcie sobie, że Wasz projekt to okręt żeglujący w kierunku nowego lądu:

1. Co jest wiatrem wypełniającym Wasze żagle i pchającym do przodu?
2. Co jest kotwicą, która Was spowalnia?
3. Czy gdzieś przed Wami czai się rafa, która może doprowadzić do katastrofy?

Luźna dyskusja – czasem retrospekcja nie wymaga wydumanego formatu. Może wystarczyć nieformalna rozmowa. Jednak nawet wtedy warto zadbać o to, żeby:

1. podczas sprintu, na bieżąco zbierać tematy do omówienia na retrospekcji (inaczej wiele ważnych zagadnień jest po prostu zapominana),
2. zadbać o to, żeby rozważać problemy w kontekście myślenia systemowego, a nie szukać winnych (w samym zespole lub poza nim),
3. sprowadzać rozmowę do faktów bardziej niż opinii,
4. wyjść z retrospekcji z konkretnymi zadaniami i uwzględnić je w planie następnego sprintu.

Analiza Problemów

Podczas retrospekcji oraz przy innych okazjach przydatne są często dwie popularne techniki analizy problemów, opisane niżej:

5xDlaczego (Five Whys) – gdy zidentyfikujemy problem, zamiast przystępować do jego rozwiązywania, pytamy dlaczego on wystepuje. Gdy znajdziemy przyczynę, pytamy dlaczego ona występuje i tak dalej pięć razy lub do momentu gdy jesteśmy w miarę pewni, że natrafiliśmy na źródłowy problem, a nie tylko na kolejne poziomy jego objawów.

Ość Ishikawy – to diagram w kształcie szkieletu ryby pozwalający rozważyć wiele przyczyn składających się na występowanie danego problemu. Jest przydatny, gdy na nasz problem wpływa wiele różnych czynników jednocześnie. Każdy z nich możemy analizować głębiej, tak jak w metodzie 5xDlaczego, aż do zbudowania wystarczająco pełnego obrazu sytuacji.

Appreciative Inquiry

Częstym błędem popełnianym przez zespoły podczas retrospekcji (a także przez wszelkiej maści coach’ów i konsultantów) jest zbytnie koncentrowanie się na problemach. Często dużo lepsze efekty można osiągnąć koncentrując się na pożądanych efektach oraz silnych stronach zespołu i procesu, które można rozszerzyć i wzmocnić.

Metoda ta jest często lekceważona, bo “przecież my tu mamy konkretne problemy, więc koncentrowanie się na pozytywach to forma mydlenia oczu…“. A jednak okazuje się, że metoda ta, poprawnie przeprowadzona, ma zaskakującą moc. Nigdy nie zamiatamy problemów pod dywan, jednak gdy stosujemy takie doceniające podejście często okazuje się, że zamiast bezpośrednio zmagać się z problemami możemy je zniwelować lub w ogóle obejść dzięki spojrzeniu na sytuację z innej perspektywy.

Duże retrospekcje

Retrospekcje są wartościowe nie tylko dla pojedyńczych zespołów. Jeśli stoisz przed problemem zorganizowania retrospekcji dla większej organizacji skontaktuj się z nami, a w międzyczasie przeczytaj jak duże retrospekcje wyglądają w szwedzkiej firmie Spotify.

Ćwiczenie dla Was:

1. Jeśli do tej pory tego nie robicie, to spróbujcie wpleść w swoje retrospekcje kroki opisane w “Agile Retrospectives”.
2. Jeśli nie zbieracie danych, na podstawie których prowadzicie retrospekcje to zacznijcie to robić.
3. Jeśli Wasze retrospekcje wyglądają zawsze tak samo to spróbujcie zmienić format i wypróbować inne metody – zaproponowane przez sam zespół lub z któregoś ze wspomnianych wyżej źródeł.

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?