Przewodnik po Scrumie | 33. Tablice Scrumban i Kanban w Scrum

Scrum i Kanban to metody pracy zespołowej, które mają wiele podobieństw. Jednak są też różnice, o których chcielibyśmy dzisiaj omówić. Tablice Kanban są również często przyjmowane przez Zespoły Scrumowe. Dzieje się tak, ponieważ są bardzo praktyczne w wizualizacji pracy zespołowej i jej postępów. Łącząc to, co najlepsze z obu metod, pojawiła się technika zwana Scrumban. Jest popularny w projektach łączących rozwój produktu z dostarczaniem usług, gdzie długie Sprinty i stosunkowo sformalizowane spotkania Scrum nie zawsze są odpowiednie.

Tablice Scrumban i Kanban w Scrumie – spis treści:

1. Wstęp
2. Kanban kontra Scrum
3. Tablice Kanban w Scrumie
4. Scrumban
5. Streszczenie

Wstęp

Kanban jest metodą pionierską w Japonii. Powstała w latach 50. XX wieku i była przede wszystkim narzędziem do zarządzania ciągłą produkcją w taki sposób, aby nie tworzyć zapasów i nadwyżek, ale na bieżąco przetwarzać zasoby. Na początku XXI wieku Kanban został dostosowany do potrzeb rozwoju oprogramowania przez Davida J. Andersona.

Kanban kontra Scrum

Ogólny sposób pracy w Kanbanie różni się od Scrum przede wszystkim wprowadzeniem mniej formalnego podejścia. W Kanbanie nie ma aż tak szczegółowych wytycznych dotyczących np. pracy w Sprintach, ról Product Ownera, Scrum Mastera czy Zespołu Deweloperskiego. Jest to możliwe, ponieważ Kanban stawia na ciągłość zadań , takich jak świadczenie określonego typu usługi, które są bardziej powtarzalne i nie wymagają tak złożonego planowania.

Jednak cel i sposoby pracy są podobne. Celem Kanban jest dostarczenie klientowi produktu najwyższej jakości na czas. Wspólne dla obu metod zasady dotyczące sposobów pracy można sformułować w następujący sposób:

1. Praca powinna przebiegać płynnie i bez przestojów – w Scrumie osiąga się to dzięki ciągłej sukcesji Sprintów, natomiast w Kanbanie praca jest ciągła dzięki płynnemu przepływowi zadań. Tworzą kolejkę, z której deweloperzy wybierają (wyciągają) kilka zadań do wykonania.
2. Zespół powinien skupić się tylko na wybranych zadaniach – używając terminologii Kanban, zespół powinien „zredukować pracę w toku”. W Scrumie odpowiednikiem tego są Historie Użytkowników wybrane z Backlogu Produktu do umieszczenia w Backlogu Sprintu
3. Postęp zadań powinien być widoczny dla wszystkich zaangażowanych osób – w Kanbanie wizualizują je tablice, które często pojawiają się również w Zespołach Scrumowych.

Tablice Kanban w Scrumie

Tablica Kanban to szeroko stosowane narzędzie do wizualizacji pracy zespołowej. Jest to tabela z kilkoma kolumnami. W każdym z nich znajdują się zadania o określonym statusie. Kategoryzacja zadań opiera się na prostej zasadzie: w jednej z kolumn umieszczana jest karta z opisem zadania – lub jej wirtualnym odpowiednikiem. Minimalna wersja tablic Kanban zawiera trzy kolumny:

• Do zrobienia
• W trakcie
• Ukończone – do ostatniej kolumny przechodzą zadania spełniające definicję ukończenia, o której pisaliśmy tutaj.

Poniżej przykład tablicy kanban z systemu do zarządzania projektami typu „wszystko w jednym” – Firmbee.com

Zazwyczaj jest więcej kolumn. Jeśli jest więcej zadań do wykonania, zwykle między kolumnami „do ukończenia ” i „w toku” znajduje się dodatkowa kolumna zatytułowana „wybrane do wykonania” . Podczas gdy kolumna „do zrobienia” służy jako Backlog Produktu, o którym pisaliśmy tutaj, kolumna „wybrane do realizacji” służy jako Backlog Sprintu, który szczegółowo opisujemy w tym artykule.

Drugim powszechnym dodatkiem jest kolumna „w trakcie sprawdzania” lub „do zatwierdzenia”. Zwykle umieszcza się go między kolumnami zawierającymi zadania „w toku” i „zakończone”. Zawiera zadania wykonane przez Zespół Deweloperski, który czeka na akceptację Właściciela Produktu. Zadaniem Właściciela Produktu jest sprawdzenie ich zgodności z kryteriami akceptacji i uzyskanie ostatecznej akceptacji Klienta. W tej sytuacji do ostatniej kolumny przenoszone są tylko ostatecznie zaakceptowane zadania.

Scrumban

Ze względu na ogromną popularność Scrum i Kanban pojawiła się ich hybryda, łącząca to, co najlepsze z obu sposobów pracy. Scrumban najlepiej sprawdza się w organizacjach, które łączą tworzenie Produktów ze świadczeniem usług, często polegających na wdrożeniu Produktu u Klienta. Ze względu na ograniczenie spotkań i komunikacji zespół może być większy.

Scrumban kładzie mniejszy nacisk na metryki powszechnie używane w Scrumie, takie jak wykres spalania. Wykorzystuje jednak w Scrumie filary potrzeby ciągłego doskonalenia procesu pracy i dostosowywania go do warunków i potrzeb klienta.

Jednak podczas pracy w Scrumbanie praca nie jest podzielona na Sprinty. Spotkania Scrum odbywają się co 3, 6 lub 12 miesięcy.

Harmonogramowanie pracy odbywa się zgodnie z zasadą „na żądanie”, czyli tak jak występuje. Historie użytkowników są umieszczane bezpośrednio w pierwszej kolumnie tablicy Kanban zawierającej zadania „do zrobienia”. Tym samym służy jako Backlog Sprintu, o którym szerzej pisaliśmy w tym artykule. Podobnie jak w Backlogu Sprintu, najpilniejsze zadania są umieszczane na górze listy rzeczy do zrobienia. Jednak w przypadku bardziej złożonych projektów Kierownik Projektu może prowadzić osobną listę rzeczy do zrobienia odpowiadającą Backlogowi Produktu, z której wybiera, które zadania umieścić w pierwszej kolumnie.

Podczas przenoszenia zadań z pierwszej do drugiej kolumny obowiązuje zasada „Pociągnij” . Oznacza to, że zadania nie są delegowane na konkretnego Developera. Każda osoba wybiera zadanie z kolejki i wykonuje je samodzielnie.

Liczba zadań umieszczonych w środkowej kolumnie „do wykonania” jest zwykle ograniczona w zależności od wielkości zespołu, tak aby w miarę możliwości każdy zajmował się tylko jednym zadaniem na raz.

Streszczenie

Scrum i Kanban, choć używane do podobnych celów, to różne sposoby pracy. Scrum najlepiej sprawdza się w kreatywnych, innowacyjnych projektach realizowanych przez małe Zespoły Scrumowe. Z kolei Kanban został stworzony do działania w środowisku ciągłym i wolnym od przestojów w celu świadczenia podobnych usług. Scrum często używa tablic Kanban jako metody wizualizacji wykonywanej pracy. Połączenie obu zaowocowało Scrumbanem, który najlepiej sprawdza się jako framework dla organizacji sprzedających swoje produkty i świadczących na ich podstawie usługi klientowi.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube, Pintereście.

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Zobacz wszystkie posty

Przewodnik po Scrumie:

1. Słowniczek podstawowych pojęć, ról i pojęć
2. Co to jest Scrum?
3. Wartości Scrum
4. Jak wdrożyć Scrum w swojej firmie?
5. Zespół Scrumowy - co to jest i jak działa?
6. Kim jest Product Owner?
7. Najczęstsze błędy Product Ownera
8. Kim jest Scrum Master?
9. Charakterystyka dobrego Scrum Mastera
10. Najczęstsze błędy Scrum Mastera
11. Jakie statystyki i metryki powinien śledzić Scrum Master?
12. Współpraca Product Ownera ze Scrum Masterem
13. Zespół Deweloperski w Scrum
14. Najczęstsze błędy programistów
15. Artefakty Scrum
16. Skalowanie Scrum
17. Backlog Sprintu
18. Czym jest Backlog Produktu?
19. Czym są historie użytkowników?
20. Tworzenie najlepszej historii użytkownika z INVEST
21. Najczęstsze błędy User Story
22. Kryteria akceptacji historii użytkownika
23. Szacowanie i punkty fabularne w Scrumie
24. Poker Planowania
25. Drużynowa gra szacowania
26. Definiowanie przyrostu
27. Wydarzenia scrumowe
28. Czym jest Sprint w Scrumie?
29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
30. Co to jest wykres spalania?
31. Jak stworzyć i zinterpretować wykres spalania?
32. Zalety i wady wykresu spalania
33. Tablice Kanban w Scrum i Scrumban
34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
35. Codzienny Scrum
36. Planowanie sprintu
37. Przegląd sprintu
38. Czym jest retrospektywa sprintu?
39. Typowe błędy podczas Retrospektywy Sprintu
40. Pielęgnacja Backlogu Produktu