icon-search

Scrum vs Kanban – krótki przewodnik po metodykach zwinnych.

Karolina Rut 29.11.2018

Jednym z kluczowych elementów przy pracy nad tworzeniem lub rozwojem oprogramowania jest wybór odpowiedniej metodyki działania. Niemalże na każdej stronie związanej z software developmentem pojawiają się takie sformułowania jak „jesteśmy agile”, „działamy zwinnie”, „pracujemy w metodyce Kanban”, „jesteśmy Scrum masterami”. O ile jednak nie stanowi problemu określenie różnic między tradycyjnymi a zwinnymi metodami zarządzania projektami informatycznymi, o tyle zrozumienie specyfiki i rozbieżności między metodyką Scrum i Kanban może dla wielu stanowić kłopot. Mając jednak świadomość, jak duży wpływ na sukces projektu ma odpowiednie zrozumienie mechanizmów jego prowadzenia, postanowiliśmy stworzyć krótki przewodnik po tych dwóch popularnych metodykach.

Czym różni się Kanban od Scruma? Co te metodyki łączy? I wreszcie – którą metodykę wybrać decydując się na pracę nad rozwojem oprogramowania? Tego dowiedzie się z tego artykułu.

Zrozumienie mechanizmów to podstawa

By zrozumieć różnice między dwoma metodykami zwinnymi oczywistym jest, że najpierw trzeba poznać specyfikę każdej z nich. By jednak samo opisywanie metodyk nie zajęło głównej części tego artykułu (materiałów charakteryzujących każdą metodykę jest w internecie mnóstwo – polecam szczególnie Scrum Guide  oraz Kanban Guide) postaram się podsumować każdą z nich w dosłownie kilku punktach.

Scrum – keypoints

  1.   Podziel zasoby organizacji na małe, cross-funkcjonalne, samoorganizujące się zespoły.
  2.   Podziel całość pracy na małej wielkości, konkretne zadania, nadając im odpowiedni priorytet i szacując potrzebny nakład pracy
  3.   Podziel czas przeznaczony na dany projekt na konkretnej wielkości iteracje (z reguły od 2-4 tygodni)
  4.   Po każdej iteracji omów i zoptymalizuj priorytety i czas poświęcany na konkretne taski.
  5.   Zoptymalizuj cały proces organizując spotkanie retrospektywne po zakończonym projekcie.  

Jeżeli mielibyśmy zmieścić opis tej metodyki w jednym zdaniu zapewne brzmiałoby ono: Zamiast dedykować duże zadanie zbudowania dużego produktu dużej grupie ludzi, postaw na małe zespoły, pracujące w krótkich iteracjach dostarczające małe części produktu końcowego.

Kanban – keypoints

  1. Zwizualizuj przepływ pracy – podziel główne zadania na mniejsze taski, każdy task zapisz na oddzielnej kartce i umieść je na tablicy i użyj kolumn z odpowiednimi nazwami by określić w na którym etapie prac jest konkretny task
  2.   Przypisz konkretny limit pracy in progress (work in progress (WIP)) – ile konkretnie zadań może być wykonywanych jednocześnie
  3.   Określ czas realizacji (średni czas ukończenia jednego zadania, czasem nazwany “czasem cyklu”). Zoptymalizuj cały proces tak by czas jego realizacji był jak najkrótszy i jak najbardziej przewidywalny.

Screen Shot 2018-11-29 at 12.12.00

Relacja między metodyką Scrum i Kanban

Przede wszystkim te dwie metodyki łączy cel. Jest nim oczywiście dowiezienie produktu końcowego w możliwie najbardziej efektywny sposób przy jednoczesnym ciągłym udoskonalaniu procesu developmentu. Trudno jest jednak określić, które z tych narzędzi jest jednoznacznie lepsze od drugiego. W zależności od okoliczności każde z nich ma swoje zalety i wady. Z całą pewnością na dużym poziomie ogólności metodyką, która posiada więcej zasad i reguł jest Scrum. Oczywiście, co do zasady metodyki zwinne posiadają mniej norm niż tradycyjne sposoby zarządzania projektami, jednakże relatywnie Kanban jest metodyką bardziej adaptacyjną i swobodną. Scrum bowiem daje nam pewne ograniczenia (jak np. używanie ściśle określonych w czasie timeboxów, dzielenie pracy na iteracje, tworzenie zespołów cross-funkcyjnych). W przypadku Kanban sytuacja jest dużo prostsza – metodyka nakazuje jedynie przedstawianie w sposób wizualny przebiegu prac i określenie limitów Work in Progress.  W Scrumie także z góry określone są pewne role – Product Ownera (określa wizję produktu i priorytety), Zespół (implementuje elementy produktu) i Scrum Mastera (stara się usunąć wszelkie przeszkody w implementacji, czuwa na efektywnym realizowaniem procesu). Kanban dla odmiany nie narzuca żadnej z tych ról.

Podstawową zasadą jednak przy wyborze narzędzi zarządzania jest nieograniczanie się tylko i wyłącznie do jednej metodyki. Wiele zespołów pracujących w Kanbanie organizuje codzienne standupy, które są praktyką przypisywaną Scrumowi, niektóre teamy Scrumowe z kolei oganiczają WIP inspirując się Kanbanem. Najważniejsze jest dostosowanie wybranych elementów do specyfiki projektu. Chcesz nadać rolę Product Ownera zarządzając projektem w metodyce Kaban? Nie ma problemu, pamiętaj tylko by ta zmiana nie wpływała na elementy konstytutywne metodyki.

Organizacja czasu w projekcie

Scrum oparty jest o iteracje, które mają ściśle określone ograniczenia czasowe. Oczywiście istnieje możliwość wyboru długości iteracji, jednak założeniem tej metodyki jest utrzymanie konkretnie wskazanego zakresu czasowego. Każdą iterację można podzielić na trzy fazy:

  1.  Początek iteracji – tworzony jest plan iteracji, na podstawie priorytetów określonych przez product ownera i wcześniej stworzonych estymacji czasowych przypisanych do konkretnych tasków, zespół wybiera odpowiednią ilość elementów z backloga.
  2. Faza właściwa iteracji – zespół skupia się na ukończeniu wcześniej wybranych tasków. Zakres iteracji jest ściśle określony.
  3. Koniec iteracji – przetestowany i gotowy kod jest przedstawiany, dokonywany jest tzw. release. Następnie organizowane jest spotkanie retrospektywne podczas którego omawiane są możliwe drogi usprawnienia procesu.

W Kanbanie ściśle określone iteracje nie są narzucone. Z większą dowolnością można dokonać planowania, czy releasu. Można swobodniej zdecydować, czy będą one dokonywane w regularnych odstępach (co drugi poniedziałek), lub „na żądanie” – w momencie kiedy coś o większym znaczeniu jest do pokazania.

Metody ograniczania Work in Progress (WIP)

W metodyce Scrum sprint backlog zawiera jedynie te zadania, które mają być zrealizowane podczas obecnej iteracji (zwanej sprintem). W wizualnej formie przedstawia się to za pomocą tzw. tablicy Scrumowej. Czym jednak taka tablica różni się od tablicy Kanbanowej? Prześledźmy taki przykład:

Screen Shot 2018-11-29 at 12.12.08

W jednym i drugim przypadku śledzimy realizację określonej ilości zadań. Zadania te podzielone są pomiędzy konkretne etapy realizacji. W tym przypadku jest to To do, In Progress i Done ale może to być równie dobrze Integracja, Testowanie, Release. Ważne by etapów w procesie było jak najmniej i by śledzenie poruszania się tasków między procesami było stosunkowo proste.

Jaka jest więc różnica? Kiedy skupimy się na kolumnie In Progress zobaczymy, że w przypadku tablicy Kanbanowej ilość zadań które są jednocześnie w trakcie realizacji jest ograniczona do dwóch. Na tablicy Scrumowej takiego ograniczenia nie widzimy. W tym momencie pojawia się więc pytanie – czy w przypadku metodyki Scrum WiP nie jest w żaden sposób ograniczona? Odpowiedź oczywiście brzmi nie.

W przypadku Scrum, tak jak to zostało wspomniane, jest określona ilość tasków, która może zostać wykonana w trakcie konkretnej iteracji. W naszym przykładzie są to 4 zadania. Nie więcej więc niż 4 zadania na tablicy Scrumowej będą mogły być wykonywane jednocześnie.

Zarówno Scrum jak i Kanban ograniczają więc WIP – po prostu drogi do osiągnięcia tego celu są inne.

Dokonywanie zmian w iteracji

Załóżmy, że nasza tablica kanbanowa w obecnej iteracji wygląda następująco:

Screen Shot 2018-11-29 at 12.12.15

Co w sytuacji gdybyśmy chcieli dodać kolejne zadanie (E) do tej tablicy w trwającym właśnie sprincie?

W przypadku tablicy Scrumowej byłoby to niemożliwe. Team ma za zadanie wykonać task A B C i D, zadanie E można jedynie dodać do product backlog. Jeżeli product owner uzna, że dany task ma duże znaczenie dla projektu, zadanie to zostanie dodane do implementacji w kolejnym sprincie.

A jak sprawa wygląda w przypadku metodyki Kanban?

Mając tablicę z ograniczeniem zadań To Do i In Progress (do dwóch w każdej kolumnie) zespół może powiedzieć – oczywiście możemy dodać zadanie E do naszej tablicy i by tego dokonać mamy dwa wyjścia. Albo trzeba poczekać aż zwolni się miejsce i jeden task z In Progress zostanie wykonany, albo należy usunąć jeden z tasków które obecnie są w kolumnie To do. Wszystko to zgodnie z regułą one item out = one item in (WIP limits).

Owe możliwości dokonywania zmian w tablicach wynikają też z konkretnych uprawnień osób zaangażowanych w proces. W przypadku Scrum, product owner nie może dokonywać zmian w tablicy, to zespół decyduje których zadań się podjął w danej iteracji. W przypadku Kanban istnieje większa dowolność w nadawaniu uprawnień poszczególnym członkom teamu, zazwyczaj product owner ma możliwość dokonywania zmian w kolumnach To do czy Backlogu.

Należy też pamiętać że te dwie skrajne sytuacje nie wyczerpują wachlarza możliwości, które są wykorzystywane w zarządzaniu projektami. Zespół Scrum może nadać product ownerowi uprawnienia do zmianu priorytetów w środku sprintu, zaś zespół Kanban ma możliwość ustalenia ściśle określonych iteracji czerpiąc z zasad Scrumowych.

A co pomiędzy iteracjami?

W przypadku metodyki Scrum podczas trwania sprintu tablica zmienia się następująco:

Screen Shot 2018-11-29 at 12.12.29 Screen Shot 2018-11-29 at 12.12.36 Screen Shot 2018-11-29 at 12.12.42

Z założenia na koniec iteracji wszystkie zadania powinny być w kolumnie done (release etc). Nowy start sprintu w tym przypadku oznacza wyciągnięcie z product backlogu kolejnych zadań i umieszczenie ich na tablicy.

Inaczej wygląda sytuacja w przypadku tablic kanbanowych – tutaj nie ma potrzeby dokonywania resetu.

Screen Shot 2018-11-29 at 12.12.48

Dzielenie zadań w Scrum i Kanban

Zarówno Scrum jak i Kanban oparte są na przyrostowym rozwoju, czyli innymi słowy na rozbijaniu dużych zadań na mniejsze partie.

W przypadku zespołu zarządzanego w Scrumie, weźmie on zobowiązanie do wykonania tylko tych zadań, które uważa za możliwe do wykonania w trakcie trwania jednego sprintu (na podstawie definicji ukończenia tasku). Jeżeli zadanie jest zbyt duże by mogło się zmieścić w sprincie, zespół wraz z product ownerem starają się dokonać jego podziału. Jeżeli generalnie większość zadań w danym procesie jest dużych, wpływa to na czas trwania iteracji (i np. określenia, że nie trwa ona 2 tyg tylko 4 tyg).

Kanbanowy zespół z kolei stara się zminimalizować ilość pracy in progres, co także zachęca do podziału zadań na mniejsze partie. Nie ma jednak ściśle określonych zasad dotyczących długości tasków – może więc się zdarzyć, że na tablicy kanbanowej są zadania które zajmują miesiąc i te których wykonanie trwa jeden dzień.

Przedstawione wyżej różnice to oczywiście tak naprawdę tylko wstępne porównanie. W kolejnej części artykułu przedstawimy jakie są różnice między szacowaniem zadań w dwóch metodykach, jak zarządza się backlogiem w każdej z nich i przedstawimy case study prawdziwych projektów informatycznych zarządzanych w Scrumie i Kanbanie.

Komentarze: 0

Notice: Korzystanie z Motyw nieposiadający comments.php uznawane jest za przestarzałe od wersji 3.0.0! Nie istnieje żadna alternatywa. Proszę zawrzeć w motywie szablon comments.php. in /var/www/html/pl/wp-includes/functions.php on line 4597

Dodaj komentarz

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