• Lis : 09 : 2013 - Wstępniak
  • Lis : 09 : 2013 - Dziel i zwyciężaj ...bądź scalaj i zwyciężaj
  • Gru : 15 : 2013 - Doomsday is coming
  • Sty : 15 : 2014 - Ramzes umarł, Kryzys żyje
  • Sty : 24 : 2014 - "Dupa" na tablicy
  • Lut : 20 : 2014 - Zarządzanie czasoprzestrzenią
  • Maj : 15 : 2014 - Stosunek przerywany, czyli strzelając z biodra w architekturę

Featured articles

"Zarządzanie czasoprzestrzenią" - czyli kilka porad dotyczących harmonogramu zdarzeń SCRUM'owych Czytaj ...

Doomsday clock - czyli o tym jak mój zespół monitoruje dług techniczny i pokochał zagładę Czytaj...

"Stosunek przerywany, czyli strzelając z biodra w architekturę" - czyli słów kilka o groomingach Czytaj ...



Fizyczne tablice rządzą


Większość z nas, praktyków arkan SCRUMowych, używa SCRUM board’ów jako reprezentacji Sprint Backlogu. Część korzysta z tablicy „analogowej”, powieszonej gdzieś w pokoju, część cyfrowej w postaci jakiegoś toola (np. JIRY). Ja osobiście jestem wielkim zwolennikiem tych pierwszych, ponieważ:
    • Stanowią naturalny punkt „zbiórki” dla zespołu, gdy trzeba przedyskutować plan działania,
    • Są niezastąpione podczas Daily Scrum’a i stanowią idealne tło dyskusji (wszyscy wiedzą, o czym mowa, mogą pokazać na karteczkę z konkretnym zadaniem, mogą wreszcie przejrzeć swoje karteczki, aby przypomnieć sobie nad czym ostatnio pracowali),
    • Wystarczy oderwać oczy od klawiatury, aby zorientować się w postępie prac (zamiast szukać odpowiedniego tab’a w przeglądarce),
    • Są zdecydowanie bardziej „elastyczne” niż jakikolwiek inny system elektroniczny,
    • Jest coś przyjemnego w „ręcznym” przesuwaniu karteczek… poważnie J

Powiem szczerze, że ciężko mi sobie wyobrazić porządny Daily Scrum bez tablicy. No chyba, że z gigantycznym ekranem dotykowym J W sytuacji, gdy macie w zespole kilka osób „zdalnych” możecie utrzymywać jednocześnie tablicę analogową i cyfrową. Te kilka minut dziennie potrzebne na zsynchronizowanie tablic wydaje mi się śmiesznie małą ceną za wszystkie zalety fizycznych tablic, które wymieniłem powyżej (możecie również spróbować takiego toola: http://jimflow.jimdo.com).

Elastyczna tablica, czyli nie bój się kolorów


W dalszej części tego prosta chciałbym poruszyć temat „elastyczności” fizycznych tablic. SCRUM board nie musi wyglądać jak tabelka z kolumnami TODO, In Progress, Done, na której przyczepione są żółte karteczki. Macie cały zestaw wspaniałych narzędzi, które uczynią wasz product backlog bardziej czytelnym i przyjemniejszym w użyciu. Pamiętajcie, że karteczki typu post-it są dostępne w różnych kolorach, kształtach i rozmiarach. Wykorzystajcie to!! Pamiętajcie także, że możecie również skorzystać z wszelkiego rodzaju magnesów z obrazkami, naklejek, wydruków, żetonów z gry, odznak, awatarów, zdjęć, korowych taśm klejących, zakładek do książek, markerów… słowem jakichkolwiek przyborów papierniczych jakie wpadną wam w ręce. Ciekawy przykład: mój zespół potrzebował czegoś by oznaczać zadania  przy realizacji których pojawił się problem/blocker. Mieli do dyspozycji tylko „zwykłe” karteczki typu post-it oraz karteczki przylepne w kształcie serduszka, gwiazdki i księżyca. Żadna z nich nie specjalnie kojarzy się z problemem. Co zrobili? Wzięli serduszka przywiesili je do góry nogami i stwierdzili że od teraz symbolizują one „dupę” J. Na każdej takiej „dupie” pisali w kilku słowach na czym polega problem. Poniżej znajdziecie listę różnych sposobów modyfikacji zwykłej, szarej i nieatrakcyjnej tablicy SCRUMowej w użyteczną, czytelną i „fajną” jej wersję. Pomysły zaczerpnąłem z koncepcji, które stosujemy lub stosowaliśmy w naszym zespole jak i z podpatrzonych wśród innych zespołów.
·         Oznaczanie User Story kolorami – wszystkie zadania związane z jednym User Story zapisujcie na karteczkach w tym samym kolorze. Każde User Story (US) w ramach jednego Sprintu powinno mieć inny kolor. Dzięki temu dużo łatwiej ocenić ile zadań zostało do wykonania w ramach różnych US oraz widać nad jakimi US zespół aktualnie pracuje,
·         Wysokość US na tablicy określa jego priorytet w sprincie – US umieszczone najwyżej na tablicy mają najwyższy priorytet. Zespół (w ramach rozsądku) powinien zacząć pracę „od góry” tablicy i kontynuować „w dół”. Dzięki temu zmniejszy się ryzyko niedostarczenia kluczowych US,
·         Dodatkowe znaczniki na kartkach z zadaniami – stosuj znaczniki aby sygnalizować „specyficzne” statusy związane z zadaniami. Poza wspomnianą wcześniej „dupą” w naszym zespole stosowaliśmy również magnesiki z nadrukami, które używaliśmy do oznaczania następujących statusów: zadanie zblokowane, zadanie nie idzie zgodnie z planem, zadanie idzie bardzo źle, FUBAR. Magnesiki z własnymi „nadrukami” możecie zamówić za parę złotych na allegro,
·         Awatary reprezentujące członków zespołów – zamiast pisać kto wykonuje dane zadanie można przy tym zadaniu umieszczać wydruk awatara reprezentującego konkretnego developera. Awatary możecie zrobić tu, tu, tu lub skorzystać z tej listy,
·         Zasygnalizować maksymalną ilość zadań nad którymi zespół może równolegle pracować – czyli po ludzku WiP limit dla kolumny In progress. Można zrobić to na wiele sposobów: napisać w nagłówku kolumny jaki jest WiP limit, narysować miejsca na karteczki (tylko tam można umieszczać zadania), fizycznie ograniczyć ilość miejsca w kolumnie In progress.
·         Wielkość karteczki z zadaniem odpowiada wielkości zadania – tego jeszcze nie spróbowaliśmy w praktyce ale wydaje się być ciekawą koncepcją J

Zachęcam do eksperymentowania z waszymi Sprint Backlogami. Pamiętajcie tylko, że nadrzędnym celem jest zwiększenie jego czytelności, a nie zrobienie go bardziej zbajerowanym.

Nasz Sprint Backlog





W naszym zespole do realizacji Sprint Backloga używamy białych tablic. Na tablicy z lewej strony wieszamy kartki (formatu A5) reprezentujące User Stories, w kolejności od góry do dołu (na górze są najbardziej priorytetowe US). Obok US umieszczamy zadania. Wszystkie zadania dotyczące jednej US są napisane na kartkach tego samego koloru. Zadania uporządkowane są od prawej do lewej strony, czyli najbliżej kolumny In progres znajdują się te, które najwcześniej będziemy robić. Kartka z zadaniem wygląda następująco:





Dodatkowo, gdy zadanie jest gotowe do review, wpisujemy na niej literkę R, a obok niej osobę która zgłosiła się, aby wykonać Review. Nasz Spritnt Backlog ma tylko 3 kolumny: TODO, In progres i Done. Nie mamy kolumny Review oraz Test (często spotykanej w innych zespołach). Zamiast stanu Test mamy zadania typu Test. Powód jest prosty: testujemy funkcjonalności, a nie poszczególne zadania (typu dodaj kolumnę do bazy danych).



Nasz proces deploymentu


Apokaliptycznych wizji ciąg dalszy. Jak wspomniałem we wstępniaku, proces deploymentu nowych funkcjonalności jest dość skomplikowany. SCRUM’em objeliśmy jedynie fazę developmentu i testów na środowiskach developerskich. Reszta procesu wygląda (w pewnym uproszczeniu) mniej więcej tak:


Dla tych którym nie chce się zagłębiać w powyższy diagram lista co ciekawszych właściwości procesu:
  1. Proces skomplikowany i przejście go trwa bardzo długo (średnio około miesiąca),
  2. Przez proces przepływają nowe wersje komponentów, a nie funkcjonalności (jedna funkcjonalność może wymagać zmiany w kilku komponentach),
  3. Spora część procesu znajduje się poza bezpośrednią kontrolą zespołu,
  4. Po stronie organizacji klienta istnieje trylion różnych zespołów IT, nad którymi nasz klient (sponsor, PO, zespół biznesowy) nie ma bezpośredniej kontroli (znajdują się w innym pionie organizacji).

Problem


Teraz najwyższa pora opisać jak to wyglądało w praktyce. Otóż przez proces przepływała olbrzymia ilość zgłoszeń o deploy komponentów. Część z nich utykała w różnych miejscach procesu, część  w ogóle ginęła w niewyjaśnionych okolicznościach, części nie udało się zainstalować z powodu braku innych komponentów, od których były zależne, wreszcie część jakimś cudem udawało się „przepchnąć” na środowisko produkcyjne. W tym ogólnym galimatiasie co jakiś czas zespół biznesowy ni stąd, ni zowąd rzucał jakąś datą: np. funkcjonalność XYZ ma być gotowa za tydzień bo umówiliśmy się z klientem na testy. Oczywiście funkcjonalność, mimo że gotowa od strony developerskiej, znajdowała się w bliżej nieokreślonym stanie w procesie deploymentu. Jednym słowem KRYZYS. W takich przypadkach zbieraliśmy sztab kryzysowy, zakasaliśmy rękawy i do roboty!! A robota polegała na szaleńczym „przepychaniu” zgłoszeń wszelkimi możliwymi sposobami… co oczywiście przynosiło skutek odwrotny od oczekiwanego i funkcjonalność „przechodziła” przez proces deploymentu jeszcze dłużej. Ramzes umarł, kryzys żyje!!!

Rozwiązanie


Ktoś mógłby powiedzieć, że fundamentalnym problemem jest tutaj „zasięg” SCRUM’a, który nie obejmuje procesu deploymentu. Niestety, mimo że takie podejście pozwoliło by nam rozwiązać większość wymienionych powyżej problemów, w naszym przypadku nie jest możliwe do zastosowania. Przeszkodami są tutaj:
  1. Zespół developerski nie ma kontroli nad sporą częścią procesu, 
  2. Proces trwa bardzo długo, a z powodu opisanego w punkcie 1. zespół developerski nie ma możliwości skrócenia go,
  3. Wydłużenie sprintów tak, aby mogły objąć development + deployment nie wchodzi w grę z powodu dużej dynamiki biznesu klienta (cały czas coś się zmienia, a długie, miesięczne sprinty spowodowałyby nieakceptowalną dla zespołu biznesowego „bezwładność” funkcjonalności).

Debatując nad problemem doszliśmy do wniosku, że w naszej sytuacji najistotniejszą rzeczą, jaką musimy zrobić, jest opanowanie chaosu. Wszyscy muszą mieć wyraźny wgląd w aktualną sytuację, jaka panuje w procesie deploymentu. W świecie Lean Managementu istnieje oczywiście rozwiązanie naszego problemu i nazywa się Visual Management. Dodatkowo aby ułatwić wdrożenie nowego rozwiązania oraz uczynić go atrakcyjniejszym dla zespołu postanowiłem „ubrać go w szaty” zabawy. I tak powstała gra planszowa „Kryzys”. 


Czym jest gra planszowa „Kryzys” ?


Jest to pewna wariacja tablicy Kanbanowej (nie mylić z tablicami często wykorzystywanymi w SCRUM’ie do realizacji Sprint Backlogu), która reprezentuje nasz proces deploymentu. Przez pola przedstawiające poszczególne kroki procesu, wędrują żetony funkcjonalności (a nie tak jak do tej pory komponenty). Jednak w porównaniu do typowej tablicy Kanbanowej posiada ona kilka innych elementów. Są to:

  • Żetony „Kryzysu” (reprezentowane przez bombę atomową) – jeśli widzimy zagrożenie, że dana funkcjonalność może nie „przejść” procesu deploymentu na czas przypinamy do niej żeton „Kryzysu”,
  • Pole z Datami – które reprezentują daty dostarczone przez klienta,
  • Punktację dla graczy biorących udział w grze.

Nasza tablica wygląda mniej więcej tak:


Tura gry „Kryzys” odbywa się codziennie o stałej porze (za wyjątkiem dni planningów) i bierze w niej udział delegacja z zespołów: developerskiego, testerów i IT.

Gorąco zachęcam też do zapoznania się z instrukcją do gry, którą znajdziecie w pliku poniżej:

Instrukcja do gry "Kryzys"


Problemy Wyzwania


Visual Management pomógł nam opanować chaos, a przedstawienie pomysłu jako gry planszowej uczyniło to rozwiązanie atrakcyjnym dla zespołu. Należy jednak pamiętać, że dla developerów zarządzanie procesem deploymentu to zło konieczne, którym najchętniej w ogóle by się nie zajmowali. Dlatego z czasem entuzjazm w zespole osłabł, jako ScrumMaster musiałem (!?) pilnować, aby spotkania kryzysowe odbywały się regularnie, frekwencja również bardzo zmalała. Problemem również okazało się  wyciąganie (a właściwie to wydzieranie) dat i terminów od zespołu biznesowego. Niemniej jednak przedsięwzięcie uważam za bardzo udane… wprowadziliśmy je półtora roku temu i wciąż działa. Pomogło nam też zapobiec wielu poważnym  kryzysom.

Przyszłość

Dlaczego nie zastosowaliśmy Kanbana? Odpowiedź jest prosta: tak jak SCRUM, Kanban jest koncepcją prostą do zrozumienia, lecz trudną do stosowania, szczególnie dla zespołu biznesowego osadzonego w rzeczywistości korpo(racji). Gra „Kryzys” pozwoli na łagodne „wejście” w świat Kanbana… świat w stronę którego zmierzamy (przynajmniej w kwestii deploymentów, ponieważ oczywiście ze SCRUMa nie rezygnujemy). W tym momencie, gdy zaczniemy wprowadzać np. WiP limity, każdy zrozumie dlaczego to robimy. W końcu wielokrotnie podczas gdy w „Kryzys” widział jak ten czy tamten krok procesu korkuje się powodując znaczne utrudnienia dla wszystkich deploymentów.

Wyciągnięte lekcje


  1.  W firmie/projekcie zmiany wprowadza się trudno i mozolnie. Dotyczy to szczególnie projektów, które mają styczność z rzeczywistością korpo(racyjną)
  2. Nie oznacza to, że nie warto próbować. Jeśli nie możesz przeskoczyć problemu to spróbuj go obejść
  3. Zmiany wprowadzaj małymi kroczkami (nie wszystko naraz)
  4.  Zespół zaadaptuje zmiany szybciej, jeśli spróbujesz ją uczynić dla nich … po prostu fajną (fun factor !!!)
  5. „Krzywa nauki” będzie mniej stroma, jeśli upewnisz się, że:
    1. Wszyscy wiedzą, dlaczego wprowadzamy zmianę / nowy element procesu
    2. Zasady są jasne i przejrzyste
  6. Przygotuj się na to, że w wypadku zmian typu „zło konieczne” zapał z czasem osłabnie.
  7. W świecie Agile poza SCRUM’em istnieją też inne frameworki. Większość z nich ma tą ciekawą właściwość, że nie wykluczają się nawzajem, lecz raczej uzupełniają (najczęściej stosowany mix to SCRUM + XP, ale nie jest to jedyna możliwość)