W poprzednim wpisie dotyczącym kanban  pisałem o jego założeniach. Dziś chciałem opisać podstawowy element kanban: tablicę.

Tablica prezentuje:

  • Kto nad czym pracuje
  • Nad czym sam pracujesz
  • Ile zadań jest realizowanych równolegle

Tablica wizualizuje nam stan realizacji zadania.

O zadaniach szerzej już w kolejnym poście. Teraz tylko wspomnę, że  zadania w Kanban to karty, które powinny/mogą zawierać:

  • Nazwa zadania
  • Opis zadania
  • ID z systemów elektronicznych (np..: JIRA)
  • Termin
  • Kto pracuje nad zadaniem
  • Rodzaj zadania

Oczywiście to przykładowe atrybuty karty zadań. Zespół sam powinien określić, jakie parametry są mu potrzebne.

Przykładowa karta kanban może wyglądać następująco:

kanban_karta

Kartę z zadaniem umieszcza się na tablicy.

Tablica w Kanban

Tablica w Kanban to na samym początku biała tablica. W kolejnych etapach tworzenia zasad i reguł pracy zespołu pojawiają się na niej kolumny oraz zadania.

kanban_etapy_przeplywu_prac_sciezki

Proces wytwarzania oprogramowania można porównać do procesu w fabryce. Krok po kroku wykonujemy podobne czynności. Oczywiście działanie krok po kroku nie musi oznaczać kaskadowego wytwarzania oprogramowania. Bardziej patrzę na ten proces jak na działania w fabryce, gdzie na każdym stanowisku montażowym dokładana jest kolejna część.

Typowe etapy na tablicy kanban to:

  • Do zrobienia – wymagania oczekują na podjęcie pracy,
  • Analiza
  • Programowanie
  • Testowanie
  • Zrobione

Oczywiście w nurcie agile podstawowa tablica może mieć kolumny:

  • Rejestr produktu
  • Praca
  • Zrobione

Przepływ na tablicy kanban jest od lewej do prawej. W pierwszej kolumnie są zawsze rzeczy/zadania do zrobienia. Kluczem do kanban jest dokładne doprecyzowanie kiedy praca jest uznana za wykonaną i może być przekazana na kolejny etap. W kanban praca nie jest skończona do puki nie ma wartości dla klienta lub osoby realizującej kolejny etap. Zmiana etapu (kolumny) realizacji zadania powinna podlegać konkretnym zasadom, które określą jakie kryteria muszą być spełnione by zadanie zostało przeniesione do kolejnej kolumny.

Na tablicy można dodawać dodatkowe wiersze. Dodatkowe wiersze to inne działania realizowane przez zespół. Zadania takie to „wrzutki”, pilne zadania i inne czynności, które zespół musi zrobić. Warto określić, że zdania pilne to jedno góra dwa zadania na tydzień. Inaczej zadania pilne zabiorą nam czas jaki mieliśmy na pracę.

Ponadto należy zauważyć, że nie wszystkie zadania będą przechodzić tą samą ścieżką. Być może zadania typu błąd nie będą wracać do analizy. Warto takie zadania wyróżnić kolorem. Zespół powinien określić zasady „obsługujące” tego typu wyjątki.

Kończąc wątek z tablicą należy wspomnieć, że tablicę powinni zaprojektować członkowie zespołu, którzy będą z niej korzystać. Dzięki temu będą respektować zasady pracy.

Tablica a kolejki

Kolejki na tablicy kanban służą do wizualizacji czekającej nas pracy. Kolejka to innymi słowy zadania do wykonania w ramach działania określonego w docelowej kolumnie

Inaczej pisząc kolejki/bufory to kolumny, gdzie umieszcza się pracę, która na poprzednim etapie „aktywnym” została już ukończona i oczekuje na wzięcie jej do następnego etapu „aktywnego” procesu. Praca oczekuje tam na wolne miejsce w następnym kroku procesu (zazwyczaj w tej samej kolejności w jakiej do kolejki wpłynęła – FIFO).

kanban_agile

Na powyższym rysunku utworzyłem kolumnę Waiting. Często ta kolumna ma nazwę Do X gdzie z może być „do programowania” lub „do analizy”. Kolumna ta to wspomniany bufor.

Tablica wspaniale wizualizuje stan projektu.  Zrealizowany przepływ pozwala zobaczyć status prac i ewentualną kumulację prac. Kumulacja prac zazwyczaj objawi się w kolumnie z buforującej. Powstaje w niej kolejka zadań do wykonania. Nadmiar zadań w kolejce jest sygnałem, który zwiastuje problemy w procesie.

Uważam, że dość dobrze jest aby codziennie rano spotkać się przed tablicą (czy to elektroniczną czy to prawdziwą) i porozmawiać o aktualnie realizowanych zadaniach. To dobry czas by sprawdzić kto ma ile zadań w kolejce i gdzie powstają wąskie gardła procesu.  Podobnie jak w SCRUM, Spotkanie powinno być krótkie i trwać maksymalnie 15 minut.

Codzienne spotkania z tablicą ułatwiają komunikację w zespole i sprzyjają rozwiązywaniu problemów związanych z procesem wytwórczym oprogramowania.

A jak wygląda Twoja tablica ?

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close