FAQ

W odpowiedzi na serię pytań dotyczących gry Featureban zapoczątkowanych przez Igora Szwedzińskiego (dzięki!) postanowiliśmy rozszerzyć materiały ułatwiające prowadzenie gry o sekcję pytań i odpowiedzi (FAQ). Jeśli macie kolejne prosimy o komentarz. Obiecujemy dodawać je do poniższej listy.

1. Jak długo trwa iteracja? ile rzutów monetą zazwyczaj robisz w ramach jednej iteracji?

Ostateczna odpowiedź zależy od szczęścia każdego z zespołów i stosunku wyrzucanych orłów i reszek. Z praktyki można wybrać jedno z dwóch podejść:

  • ustalony „time-box”, tak by potem móc pokazać zespołom ile były w stanie w każdej iteracji dostarczyć w ciągu np. 15-20 minut
  • obserwować plansze i kończyć iteracje po dostarczeniu konkretnej ilości zadań. Wtedy możemy pokazać różnicę w czasie ukończenia tej samej ilości zadań przez wpływ limitu WIP na czas realizacji (lead time).
2. Jak zapewnić wystarczająco dużo zadań do kolumny “Do zrobienia”? Na początku gry? Dorabiać w trakcie? Jeżeli w trakcie, to kiedy?

Przy 4-osobowych grupach na planszę dobrze jest stworzyć po minimum 3 zadania na osobę. Nie będzie ich za dużo tzn. jeśli użyjesz małych karteczek post-it i planszy w formacie A3 to powinno się zmieścić i zapewnić każdemu możliwość ruchu do max. 3 dnia (rundy).

Od 3-ciej rundy mozna uzupełniać kolumnę “Do zrobienia” na koniec „daily”, co ma odzwierciedlać praktykę „replenishmentu” w Kanbanie. Zespół powinien nauczyć sięwięc  obserwować kolumnę “Do zrobienia” i pamiętać o jej uzupełnianiu zanim zadania wyczerpią się.

3. Kiedy wprowadzić zmianę zasad gry (automatyzacja testów)?

Jest to szczególnie przydatne, jeśli widzisz, że ilość orłów jest mała i zadania bardzo wolno osiągają skrajną prawą kolumnę tablicy Kanban.

4. Nie rozumiem slajdu z drugiej iteracji na którym historyjka “silniki impulsowe” jest zaznaczona czerwoną obwódką i znakiem zapytania. Jak to czytać?

Jest to slajd sugerujący następujące pytanie: które z zadań w zapełnionej kolumnie powinno przejść dalej jako pierwsze? Oznacza to odejście od prostego systemu FIFO na rzecz priorytetyzacji zadań wg największej wartość biznesowej, flow i/lub klienta. (Kanban core practice, lub CP 3 na kolejnym slajdzie. Patrz także pytanie nr 6)

5. Co oznacza “inne mechanizmy” w odniesieniu do analizy limitów WIP?

Jak dotąd wprowadziliśmy w grze tylko jeden, najprostszy typ limitu, tj. limit zadań w kolumnie tablicy. Pytania zadawane grupom zwykle dotyczą tego, czy można wprowadzić oprócz/zamiast tego inne limity: limit zadań na osobę, na tablicę; a także: jak limitami sterować przepływem (różne wartości dla różnych kolumn).

Często pada także pytanie czy poza limitem WIP nie wprowadzić innych mechanizmów, takich jak kolejkowanie FIFO, lub inne priorytety zadań w kolumnie, itp.

6. Nie rozumiem slajdu “odniesienia do metody kanban”. Nie wiem co i kiedy mam z tym zrobić. Nie rozumiem elementów oznaczeń: zielony fistaszek, znak zapytania i krzyżyk. Jak to czytać?

Gra powstała jednocześnie z książką Mike’s Burrowsa: “Kanban from the Inside”. W tej książce opisane są główne praktyki metody Kanban jako tzw. Core Practices (CP) i dlatego  w skrypcie do gry zawarte są slajdy 27 & 28 zawierające odniesienia co do tego, które z tych praktyk (CP) i w jakim zakresie są realizowane przez system Kanban, jaki zbudowali do tego miejsca w grze gracze. Fistaszki pokazują naturalnie co jest realizowane, krzyżyki – co nie jest, a znaki zapytania prowokują zespół do dyskusji, czy dana praktyka jest wprowadzona, czy też może zostać ulepszona.

7. Czy metryki w iteracji 3 mają być uaktualniane na bieżąco? Mają być widoczne dla całego zespołu? Dyskutowane przez zespół?

W praktyce przydatne jest, by każdy zespół miał „menedżera-skrybę”, który prowadzi informacje o metrykach. W kilku grach działało to tak, że po wystarczającej ilości dni w iteracji 3. braliśmy papierowe formularze, wpisywaliśmy dane z formularza do Excela i wyświetlaliśmy je  do przedyskutowania w grupie.

8. Jak czytać histogram skrzyżowany z wykresem skumulowanego czasu realizacji?

Słupki pokazują przypadki w ile dni udało się dostarczyć zadania, w naszym przykładzie: najkrócej w dwa, a najdłużej jedenaście dni. Nałożenie dwóch wykresów, pokazuje że np. dla czasu cyklu równemu 3 dni istnieje prawdopodobieństwo ukończenia całego projektu (zestawu zadań) rzędu 50 procent. Powstaje pytanie, czy jest realnym podjąć się zobowiązania ukończenia wszystkiego w 3 dni? Jeśli klient oczekuje większej pewności co do terminu dostarczenia, to można z szansą 85% ukończyć zadanie w 5 dni.

9. Dlaczego 68% na slajdzie kluczowych danych jest podejrzane?

68% to wyjątkowo dobry wynik – dobry i jednocześnie podejrzany; na pewno warty zwrócenia uwagi i analizy. W realnych systemach w branży IT, może poza zadaniami Operations z rygorystycznymi SLA, za dobry uznaje się wynik 40%.

10. O co chodzi na slajdzie wydajność przepływu? Jak go czytać?

Wydajność przepływu pokazuje historię życia jednego zadania. Historia ta trwa 6 dni (oś pozioma) i w zależności od wyrzuconej wartości w górnym wierszu jest to albo O (orzeł) albo R (reszka), czyli, że albo nad zadaniem wykonywana była praca (wliczamy taki dzień do wydajności), albo nie. Oznacza to, że jeśli na 6 dni, które zadanie spędza jako praca w toku, tylko 3 dni to aktywna praca, wydajność wynosi 50%. Jest tu jeden trick. Dzień 5 oznacza, że pracownik pracuje nad czymś innym (mimo orła pracuje np. w innym projekcie), czego efektem jest opóźnienie, a nie zablokowanie zadania. Ostatecznie nawet 4 orły dają wydajność przepływu tylko 50%.

11. Jak symulować opcje gry opisane w iteracji 4? Jak to najlepiej ograć w praktyce w trakcie czterech iteracji?
  • Dodatkowa kolumna wymaga modyfikacji planszy, więc lepiej jest to robić jeśli nie używasz drukowanej planszy, ale np. tworzysz ją na Flipcharcie.
  • Zmiany limitów WIP wymagają dłuższych sesji, tak żeby zobaczyć wpływ tych zmian na lead time (czas dostawy), współpracę (wymuszaną przez niski limit WIP), itd. W ostateczności można przedyskutować co i jaki miałoby wpływ.
  • Zastosowanie kostki było pomysłem Jerzego, co Mike w wersji 2 rozwiązał podobnie przez automatyzację, ale moim zdaniem kostka od początku bardzo pomaga, bo nie ryzykujemy bardzo wolnego początku gry, gdy jakiś zespół ma szczęście do reszki.
  • Ostatni punkt, to trochę rozszerzenie prostej mechaniki systemu ssącego (ang. pull system) o pracę z biznesem a więc rolą Product Ownera. To właśnie Product Owner, albo zespół, poprzez pytania o wartość i priorytety powinien sterować priorytetami zadań uwzględniając wartość/ekonomię zadań.
Reklamy