Sytuacja kobiet w IT w 2024 roku
8.08.20205 min
Mateusz Szreder

Mateusz SzrederTeam leader .NET

Kanban - czy to dobra alternatywa dla scruma?

Sprawdź, kiedy kanban może okazać się lepszym wyborem niż scrum.

Kanban - czy to dobra alternatywa dla scruma?

Kanban jako proces organizacji dostarczania swój początek miał nie w IT, ale w fabryce Toyota. Jego założeniem było maksymalizacja efektywności przy zminimalizowaniu ilości towaru na stanie części, w myśl zasad procesów Just in Time. To stamtąd myśl przewodnia kanbana przeszła do barów szybkiej obsługi, restauracji oraz IT.  Ten artykuł pokaże jego główne założenia oraz wskazówki, kiedy warto się zdecydować na porzucenie Scruma na rzecz Kanbana w Twoim projekcie.

Różnica między Scrumem a Kanbanem

Scrum w swoich rygorystycznych zasadach zakłada model dostarczania w postaci zamkniętych sprintów, których zawartość nie powinna się znacząco zmieniać w jego trakcie. Takie podejście wymaga dużej dyscypliny organizacyjnej oraz regularnego wykonywania rytuałów Scruma typu grooming, planning, retrospektywa. 

Każdy sprint tworzy zamknięty koszyk wypełniony zadaniami – Stories, a jego pojemność zależy od wielkości zwanej team velocity, czyli ilości story pointów, które zespół może dostarczyć w czasie jednego sprintu. Pozwala to na planowanie długoterminowe projektu na podstawie historycznego velocity zespołu. 

Kanban z kolei jest czymś w rodzaju strumienia zadań. Zadania napływają w kolejności ustalonej przez product ownera, a zespół wykonuje je w tej kolejności. 

Kanban jako strumień nie zakłada zamkniętych sprintów – elementy mogą być dodawane i zabierane przez PO z listy zadań TODO, dopóki nikt nie rozpoczął nad nimi pracy. Sama lista może być przebudowywana w sposób ciągły wg priorytetów PO. Długoterminowe planowanie odbywa się poprzez analizę historycznego tempa dostarczania, o czym dokładniej przeczytasz w kolejnych punktach.

Kiedy przejście na kanbana jest uzasadnione

Jako kierownik zespołu, team leader lub project manager możesz rozważyć przejście na kanbana, jeśli problemy poniżej wydają Ci się zadziwiająco znajome i bliskie:

  • scope sprintu zmienia się często po jego rozpoczęciu,
  • zadania często wypadają ze sprintu,
  • product owner nie przygotowuje należycie storiesów na planningi,
  • product owner jest ciężko dostępny i ma problem z wygospodarowaniem czasu na grooming lub planning,
  • produckt owner zgłasza częste taski ad-hock,
  • pojawiają się przypadki prób przepchnięcia nowych funkcjonalności jako Błędy w celu obejścia ograniczenia ‘zamknięty sprint’,
  • produckt owner nie przygotowuje planów długoterminowych raczej zleca rzeczy zorientowane na aktualne potrzeby biznesowe.


W takiej sytuacji można zmienić product ownera - ale to nic nie zmieni, ponieważ najwyraźniej organizacja Twojego klienta działa właśnie w taki sposób. Dlatego też hołdując podstawowym zasadom Agile – możesz podjąć decyzję o dostosowaniu procesu wytwarzania oprogramowania do tego, jak pracuje Twój klient – nie tracąc przy tym kontroli nad projektem i wybrać Kanban.

Zasady 

Zasada 1: Kanban-board odzwierciedleniem procesu

Podstawową rzeczą w kanbanie jest tzw. Kanban-board, czyli po prostu tablica z kilkoma kolumnami, przez którą przepływać będą taski w miarę wykonywania pracy. Dlatego aby poprawnie śledzić postęp każdego zadania wymagane jest, żeby kolumny odzwierciedlały kroki/fazy wykonywanych czynności.

Zasada 2: Ograniczenia

Ciągły przypływ zadań może być przytłaczający, a ponieważ miarą wydajności jest przepustowość tablicy kanban (o tym przeczytasz w kolejnym punkcie), to kluczową decyzją jest ograniczenie ilości zadań w danej kolumnie (przykładowo: jeden developer może mieć maksymalnie 2 zadania przypisane będące w stanie IN PROGRESS)

Zasada 3: Wszystko jest zadaniem

Ciągły przypływ zadań oraz ograniczenie ilości zadań IN PROGRESS wymaga konsekwencji i determinacji poprzez traktowanie nawet pozornie pobocznych rzeczy jako istotnych elementów strumienia zadań.

Jeśli do wykonania jakiegoś story wymagane jest najpierw zamówienie jakichś dostępów – powinno być to odzwierciedlone poprzez osobne zadanie. Ukrywanie takich pozornie nieważnych zadań doprowadza do niewidocznych z boardu wąskich gardeł w procesie.

Zasada 4: Zmiany mogą dotyczyć tylko zadań TODO

Podobnie jak w scrumie – tylko tutaj nie na poziomie sprintu, ale na poziomie konkretnych zadań – jeśli rozpoczęto prace nad zadaniem oznacza to, że w momencie, kiedy programista skończył poprzednie zadanie, to kolejnym było te, które w danym momencie jest na szczycie listy.

Zasada 5: Mierzyc i jeszcze raz mierzyć

Nie ma tu zamkniętych sprintów, więc planowanie releasów jest utrudnione. Dlatego należy skrupulatnie mierzyć wartości, które objaśnię w kolejnym punkcie, aby moc kontrolować pozorny chaos wprowadzony przez wielką elastyczność tego procesu.

Transparencja - czyli co mierzymy i skąd wiemy, co i kiedy dostarczymy

Planowanie

W kanbanie nie ma zamkniętych koszyków zadań. Nie ma możliwości tak prostego jak w scrumie określenia: release mamy co 2 miesiące, sprinty mają po 2 tygodnie – średnio dostarczamy 90 story pointów na sprint, więc możemy założyć, że do następnego Releasu wykonamy zadań o następującej sumarycznej ilości SP: 360 (czas między Releasami / czas sprintu * średnie velocity)

W kanbanie mierzymy przepływowość (throughput), czyli ilość story pointów, jaka przepływa przez nasz board w jednostce czasu.  

Osiągnąć to można, mierząc czas upływający od momentu rozpoczęcia pracy nad zadaniem do momentu jego zakończenia.

Dzięki temu mając listę zadań, które biznes chciałby mieć dostarczone w ramach releasu, możemy szacując ich złożoność (Story points), określić, co wejdzie w skład deploymentu, a co nie.

Kontrola procesu

Jak każdy proces, i ten wymaga kontroli i nadzoru, a co lepiej, niż suche fakty, ukazuje słabe punkty? Dlatego pracując w kanbanie warto kontrolować inne niż przepływowość wartości, chociażby po to, aby zidentyfikować wąskie gardła. Zakładając, że board został skonstruowany prawidłowo – tj. kroki na tablicy odpowiadają krokom w procesie wytwarzania – mierzenie czasów przejść pomiędzy stanami pozwoli uzyskać nam dodatkowe cenne informacje.

Time to Work

Średnia długość oczekiwania zadania ze szczytu listy TODO do momentu podjęcia pracy nad nim. Niesiona informacja: jeśli biznes przychodzi do nas z zadaniem ‘na już’, jesteśmy w stanie oszacować, kiedy rozpoczniemy nad nim prace, a sumując tę wartość z przepływnością, jesteśmy w stanie określić, kiedy zadanie może być dostarczone.

Time in progress

Średnia długość w developmencie. 

Niesiona informacja: monitorując w dłuższym okresie czasu tę wielkość, można uzyskać namacalne dowody na temat degradacji kodu oraz wzrostu długu technologicznego, co razem z wynikami narzędzi statycznej analizy kodu typu Ndepend, daje niezastąpiony argument do dyskusji na temat potrzeb refactoringu.

Time in tesing

Średnia długość czasu, jaką zadanie przebywa w fazie testowania. 

Niesiona informacja: pozwala nam to na identyfikację obciążenia testerów. Jeśli czas wzrasta z każdym miesiącem, wynika z tego, że albo należy zainwestować więcej w automatyzacje, co powinno uwolnić czas testerów do testów manualnych lub jest to jasny sygnał, że potrzebny jest dodatkowy tester.

Time in verification

Czas, jaki zadania spędzają w fazie weryfikacji biznesowej. 

Niesiona informacja: identyfikacja wąskiego gardła w procesie po stronie biznesu

<p>Loading...</p>