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).


Leave a Reply