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).
Categories:
Daily Scrum,
Organizacja zespołu,
SCRUM,
Sprint Backlog