Kanban czy Scrum: która metodyka Agile jest Ci bliższa?

Podsumowanie: Kanban to model zarządzania projektami wykorzystujący wizualną reprezentację zadań do zarządzania przepływami pracy, natomiast Scrum to model zarządzania projektami, który pomaga zespołom strukturyzować swoją pracę i zarządzać nią za pomocą zestawu wartości, zasad i praktyk.

Agile jest zbiorem zasad i ideałów, które wyznaczają przyświecający nam główny cel. DevOps jest sposobem automatyzacji i integracji procesów zachodzących na styku zespołów programistycznych i operacyjnych. Jeśli chodzi o wdrażanie Agile i DevOps, kanban i scrum zapewniają różne sposoby, aby to zrobić.

Nietrudno wskazać różnice między praktykami Scrum i Kanban, jednak są to różnice wyłącznie powierzchowne. Praktyka wynikająca z poszczególnych metodyk jest różna, jednak leżące u ich podstaw zasady w dużej mierze są takie same. Zarówno jedne, jak i drugie ramy postępowania ułatwiają tworzenie lepszych produktów (i usług) przy mniejszej liczbie problemów.

Kontynuując przerwany wątek.

Agile to ustrukturyzowane i iteracyjne podejście do zarządzania projektami i rozwoju produktu. Uwzględnia ono zmienność procesu rozwoju produktu i zapewnia zespołom samodzielnie organizującym swoją pracę metodologię umożliwiającą reagowanie na zmianę bez wypadania z rytmu. Obecnie metodyka Agile nie zapewnia przewagi konkurencyjnej. Jest standardem. Nikt już nie może sobie pozwolić na opracowywanie produktu w firmowym zaciszu przez wiele lat ani nawet przez kilka miesięcy. Dlatego właściwe wdrożenie tego podejścia jest ważniejsze niż kiedykolwiek wcześniej.

Kanban polega głównie na wizualizacji pracy, ograniczeniu prac w toku oraz maksymalizacji wydajności (lub przepływu). Zespoły Kanban koncentrują się na skróceniu czasu, jaki upływa od rozpoczęcia do ukończenia projektu (lub historyjki użytkownika). Wykorzystują w tym celu tablicę Kanban i stale doskonalą swój przepływ pracy.

ZespołyScrum zobowiązują się do dostarczenia nadającego się do wdrożenia fragmentu zadania, w określonych odstępach czasu zwanych sprintami. Ich celem jest utworzenie pętli uczenia się, które pozwalają szybko gromadzić i uwzględniać informacje zwrotne od klientów. Członkowie zespołów Scrum przyjmują konkretne role, tworzą specjalne artefakty i organizują regularne wydarzenia, które pozwalają kontynuować prace. Najlepszy opis metodyki Scrum można znaleźć w przewodniku The Scrum Guide.

Niezależnie od tego, który model zarządzania projektami będzie dla Ciebie najlepszy, mamy szablony Jira, które pomogą Ci szybko przystąpić do pracy. Zapoznaj się z naszym szablonem Scrum lub szablonem tablic Kanban — obydwa są bezpłatne.

Zespół korzystający z metodyki Scrum zobowiązuje się dostarczać wartościowy przyrost prac pod koniec każdego sprintu. Metodyka Scrum bazuje za podejściu empirycznym, koncentrując się na niewielkich przyrostach prac, które ułatwiają wyciąganie wniosków z informacji od klientów i dają lepszą podstawę do podejmowania kolejnych działań. A tak to wygląda w szczegółach:

Tempo pracy w metodyce Scrum jest wysokie, ponieważ opiera się na trwających od dwóch do czterech tygodni sprintach z jasno określonymi datami rozpoczęcia i zakończenia. Wąskie ramy czasowe wymuszają podział złożonych zadań na mniejsze historyjki i ułatwiają zespołom szybkie uczenie się. Kluczowe pytanie brzmi: czy Twój zespół jest w stanie dostarczać działający kod tak szybko?

Sprinty są przeplatane spotkaniami dotyczącymi planowania sprintu i przeglądu sprintu oraz retrospektywami, a dodatkowo odbywają się codzienne spotkania Scrum (nazywane stand-upami). Te wydarzenia Scrum są krótkie i odbywają się regularnie.

W metodyce Scrum występują trzy jasno określone role.

• Product owner dba o interes klienta, zarządza backlogiem produktu i pomaga w ustalaniu priorytetu prac realizowanych przez zespół programistyczny.
• Scrum master pomaga zespołowi trzymać się zasad obowiązujących w metodyce Scrum.
• Zespół programistyczny wybiera prace do zrealizowania, dostarcza przyrosty i odpowiada zbiorowo za swoją pracę.

Kto zarządza zespołem Scrum? Otóż nikt. Zespoły Scrum samodzielnie organizują swoją pracę i pomimo odmiennych obowiązków, wszyscy mają równy status. Zespół jednoczy się wokół celu, którym jest dostarczenie korzyści klientom.

Wskaźniki Scrum to informacje, z których zespoły scrum mogą korzystać, aby poprawić wydajność i efektywność. Mogą pomagać w podejmowaniu decyzji i zwiększać wydajność zespołów podczas planowania i realizacji. Podczas fazy planowania sprintu zespoły mogą korzystać z takich wskaźników, jak cele sprintu, prędkość zespołu, potencjał wykonawczy zespołu czy rodzaj zadania. Podczas stand-upów, warto przedstawić postępy w realizacji celów sprintu, przeanalizować wykres spalania sprintu, przyjrzeć się rozkładowi pracy itd.

Zespoły starają się określić, jaką część zadania są w stanie wykonać w czasie trwania sprintu. Zobowiązują się dostarczyć ją przed zakończeniem sprintu. Jednak zespoły Scrum mogą na podstawie uzyskiwanych opinie klientów zamieniać i modyfikować sprint, tak aby dostarczyć jak największą wartość dla klienta. W trakcie retrospektywy sprintu zespoły Scrum powinny omówić kwestię ograniczenia liczby zmian w przyszłości, ponieważ stanowią one zagrożenie dla potencjalnie gotowych do udostępnienia etapów. Jeśli zespół często zmienia zakres w trakcie sprintu, może to oznaczać, że nie w pełni zdawał sobie sprawę, jakiego zadania się podejmuje. Może to również oznaczać, że pracę zespołu zakłócają zadania związane z obsługą lub takie, których nie da się zaplanować.

Więcej informacji na temat metodyk Scrum zawiera artykuł Czym jest Scrum?

Kanban ułatwia wizualizację pracy, ograniczenie prac w toku (WIP) i szybkie przenoszenie prac z etapu „W toku” do etapu „Gotowe”.

Kanban to doskonałe rozwiązanie dla zespołów, które obsługują wiele przychodzących wniosków o różnym priorytecie i różnej wielkości. Podczas gdy procesy Scrum wymagają dużej kontroli nad zakresem, Kanban pozwala działać z większą swobodą. Aby ułatwić podjęcie decyzji, przyjrzyjmy się tym samym pięciu aspektom tej metodyki.

Struktura w metodyce Kanban opiera się na ciągłym przepływie pracy, dzięki czemu zespoły są w stanie sprawnie działać i dostosowywać się do zmieniających się priorytetów. Jednostki pracy, reprezentowane przez karty, są uporządkowane na tablicy Kanban, gdzie przechodzą od jednego etapu przepływu pracy (kolumny) do kolejnego. Typowe etapy przepływu pracy to: Do wykonania, W toku, W trakcie przeglądu, Zablokowane i Gotowe. Ale to trochę nudne.

W metodyce Kanban najlepsze jest, że można tworzyć kolumny niestandardowe dostosowane do sposobu pracy zespołu. Mój zespół zajmuje się dostarczaniem treści, dlatego nasze kolumny (w uproszczeniu) to kolejno Backlog, Priorytetowe, Gotowy konspekt, Pisanie, Projektowanie, Przegląd techniczny i Wydane. Dzięki naszej tablicy dowiedzieliśmy się, że wydajemy około jednej jednostki treści tygodniowo, i zidentyfikowaliśmy nasze wąskie gardła (na etapie Przeglądu technicznego).

W przypadku metodyki Kanban wydawanie aktualizacji ma miejsce, gdy tylko są one gotowe. Nie ma regularnego harmonogramu ani wstępnie zdefiniowanych terminów.

Teoretycznie Kanban nie zakłada ustalonego czasu na wykonanie zadania. Jeśli zadanie zostanie ukończone wcześniej (lub później), można je wydać bez konieczności oczekiwania na kamień milowy wydania, taki jak przegląd sprintu.

Tablica Kanban jest własnością całego zespołu. Niektóre zespoły angażują Agile coacha, jednak w przeciwieństwie do metodyki Scrum nie ma jednego „Kanban mastera”, który czuwałby nad płynną realizacją całego procesu. Współpraca nad zadaniami znajdującymi się na tablicy oraz dostarczanie ich wyników stanowią zbiorową odpowiedzialność całego zespołu.

Ważnymi wskaźnikami dla zespołów Kanban są czas wdrażania i czas cyklu. Dotyczą one średniej ilości czasu, jaki upływa od rozpoczęcia do ukończenia zadania. O powodzeniu zespołów Kanban świadczy skrócenie czasów cykli.

Kolejnym narzędziem analitycznym stosowanym przez zespoły Kanban do monitorowania liczby jednostek pracy w poszczególnych stanach jest kumulacyjny diagram przepływu (CFD). Diagramy CFD ułatwiają identyfikację konkretnych wąskich gardeł wymagających usunięcia w celu zwiększenia wydajności.

Innym sposobem eliminowania wąskich gardeł są limity prac w toku (WIP). Limit WIP określa maksymalną liczbę kart, które mogą równocześnie znajdować się w jednej kolumnie. Po osiągnięciu limitu WIP w narzędziu takim jak Jira kolumna jest oznaczana, a zespół pracuje wspólnie nad tymi jednostkami, aby przenieść je do kolejnego etapu.

Przepływ pracy w metodyce Kanban może ulec zmianie w dowolnym momencie. Można dodawać do backlogu nowe jednostki pracy, blokować istniejące karty, a nawet je usuwać, w zależności od ustalonych priorytetów. Ponadto w przypadku zmiany potencjału wykonawczego zespołu można odpowiednio dostosować limit WIP, a w efekcie także liczbę jednostek pracy. W Kanban chodzi przede wszystkim o elastyczność.

Więcej informacji na temat metodyki Kanban zawiera artykuł Czym jest Kanban?

Członkowie społeczności Agile uważają, że ta rozmowa nie powinna dotyczyć narzędzi. Często obserwujemy sytuację, w której wybór narzędzia wpływa na wybór ram postępowania, a ramy postępowania decydują o zasadach, które przyjmuje zespół. Uważamy jednak, że kierunek procesu decyzyjnego powinien być odwrotny.

Gdy zespół zaznajomi się z zasadami Scrum i uzna, że te ramy postępowania są dla niego odpowiednie, przyjdzie czas na wybranie narzędzia, które sprawdzi się najlepiej. To samo dotyczy metodyki Kanban. Nie jesteśmy obiektywni, ale biorąc pod uwagę, że jest to narzędzie do tworzenia oprogramowania najczęściej używane przez zespoły Agile, uważamy, że Jira zapewni Ci wszystko, czego potrzebujesz.

Dzięki typom projektów Jira dedykowanym metodykom Scrum i Kanban możesz wdrażać zasady dowolnych ram postępowania. Służymy także pomocą w rozpoczęciu pracy, udostępniając nasze przewodniki dotyczące tego, jak korzystać z metodyki Scrum w Jira i korzystania z metodyki Kanban w Jira.

Metodyki Scrum i Kanban są zgodne z zasadami Agile. Działają w sposób wypróbowany i skuteczny, z którym właściwie trudno się nie zgodzić. Nawiązując do innego znanego powiedzenia, można rzec, że „nikogo nie zwalnia się za wybranie metodyki Scrum”.

Jednak wybór wcale nie musi być tak jednoznaczny. Setki zespołów korzystają z modeli hybrydowych czerpiących zarówno z metodyki Scrum, jak i z Kanban. Chcemy ułatwić zespołom przyjęcie takiej strategii w Jira, dlatego opracowaliśmy projekty zarządzane przez zespół.

Projekty zarządzane przez zespół, jak sama nazwa sugeruje, umożliwiają zespołom wybranie tych funkcji Agile, które mają sens w ich przypadku, niezależnie od tego, czy pochodzą one z metodyki Scrum, Kanban, czy połączenia obu. Zamiast wdrażania konkretnych ram postępowania już pierwszego dnia projekty zarządzane przez zespół pozwalają stopniowo dokładać kolejne zaawansowane funkcje, w miarę jak zespół będzie odkrywał, co sprawdza się (lub nie) w jego przypadku.

Można bez obaw wybrać szablon Scrum lub Kanban projektu zarządzanego przez zespół, wiedząc, że obydwa można dostosować do potrzeb swojego zespołu.

Niezależnie od wybranej opcji, korzystaj z niej przez pewien czas. Weź część prac z backlogu i zrealizuj je aż do etapu ukończenia, a następnie zapytaj członków zespołu, co poszło dobrze, a co nie. Wypróbowując metodykę Scrum i Kanban oraz zadając te pytania, jesteś na dobrej drodze do osiągnięcia pełni sukcesu związanego z wyborem podejścia Agile.