Scrum i Kanban – okiem programisty. Przykłady, porady

Programuję od 11 lat, a większość czasu spędziłem pisząc w Javie, z kilkoma epizodami w JavaScripcie (+React), Kotlinie, a także w Groovym. Przez całe studia uczono mnie, że Waterfall to najlepsza z możliwych metodologii pracy (wiadomo, uczelnie są zawsze “trochę” w tyle). W pierwszym roku pracy spotkałem się z koncepcją metodologii Agile i do chwili obecnej uważam, że w projektach developerskich nie ma nic lepszego. Która jednak z dwóch najpopularniejszych odmian jest lepsza?

Co to jest ten Scrum i czy przyda się programiście?

Scrum to odmiana Agile, która opisana jest na stronie scrumguides.org. Z głównych składowych znanych programistom mamy Sprinty, Planningi, Review, Backlog, Tablica oraz Daily Standupy.  

Proces w metodologii Scrum zaczyna się od Backlogu, to tutaj pojawiają się nowe zadania definiowane przez Product Ownera po dyskusji (bądź nie) z zespołem developerskim. Backlog może być uaktualniany albo między Sprintami, albo na bieżąco. Sprint to zadany okres czasu, w którym zespół developerski zakłada, że uda się dostarczyć zadania lub zadanie ze Sprint Backlogu. 

Czym jest Sprint Backlog?

To zadania z głównego Backlogu, na których realizację zdecydował się zespół. Czasami ustala on tzw. Sprint Goal, czyli cel główny Sprintu, łączący jego ostateczny sukces lub porażkę z jego ukończeniem.

Kiedy Sprint Backlog zostaje zatwierdzony i Sprint startuje, nowe zadania nie mogą (lub raczej nie powinny) być dodawane do Sprint Backlogu. Warto zaznaczyć, że w metodologii Scrum zespół pracuje jedynie nad zadaniami w ramach Sprint Backlogu.

Kiedy zaczynamy Sprint?

Sprint zaczynamy, gdy wszystkie zadania zdefiniowane w Sprint Backlogu trafiają na tablicę. Tablica to graficzna wizualizacja statusu zadań w postaci tabelki. Statusy zadań są nagłówkami kolumn, a zadania, w postaci karteczek przekładane są od “ToDo” po lewej stronie do “Done” po prawej stronie.

Członkowie zespołu wybierają zadania, nad którymi chcą pracować, po ich rozpoczęciu zmieniają status zadania na Tablicy na “In Progress” (bądź jakikolwiek inny przez nich ustalony) i omawiają postępy na Daily Standupie. Jak sama nazwa wskazuje Daily Standup to krótkie, codziennie spotkanie mające na celu omówienie statusu zadań przez członków zespołu.

Zobacz też

PM Krytykuj prywatnie, chwal publicznie. O radykalnej szczerości

Gdy zadanie jest blokowane przez jakiś czynnik zewnętrzny i dalsza praca nad nim jest w danym momencie niemożliwa, jego status zmieniany jest na “ToDo”, bądź “Blocked”, a praca nad nim przerywana. Jednocześnie w Scrumie nie ma limitu jednocześnie rozpoczętych zadań. Miarą sukcesu bądź porażki jest liczba wykonanych zadań w czasie trwania całego Sprintu, a nie w poszczególnych jego etapach.

Po zakończeniu Sprintu (po upływie zadanego czasu, niekoniecznie wykonaniu wszystkich zadań), następuje Sprint Retrospective, czyli tzw. retrospektywa, która wykonywana po każdym Sprincie (bądź jeśli zespół ustali rzadziej), pozwala na ocenę pozytywnych i negatywnych aspektów odbytego Sprintu i ewentualne wprowadzenie zmian.

Kanban – co to jest i z czym to się je?

Oryginalnie metoda Kanban powstała w Japonii, jako usprawnienie procesu sterowania produkcją. W programowaniu zaadoptowany został w celu eliminacji procesów na rzecz wydajności. Jak to działa? Koncepcja jest bardzo podobna do Scruma, tak samo mamy tu Backlog, Zadania i ich statusy ale na tym podobieństwa się kończą. 

W Kanbanie nie ma pojęcia Sprintu, a zatem zadania dodawane są do Backlogu na bieżąco, zgodnie z ustaleniami z Product Ownerem bądź przedstawicielami Biznesu. Podobnie praca nad zadaniami realizowana jest na bieżąco, a preferowany kierunek przechodzenia zadań na tablicy to z lewej do prawej. Oznacza to, że raz rozpoczęte zadanie powinno być ukończone przed rozpoczęciem prac nad następnym. Pozwala to kontrolować ilość rozpoczętych zadań i usprawnia ich “przepływ” na tablicy. 

W przeciwieństwie do Scruma nie mamy tutaj Sprintów, a co za tym idzie praca odbywa się bardziej “taśmowo”, umożliwiając utylizację wszystkich członków zespołu jednocześnie. Jednocześnie w przypadku Kanbana ważne jest też, aby wszystkie pojawiające się blockery zadań były na bieżąco rozwiązywane i usuwane, gdyż w Kanbanie bardzo źle widziane jest rozpoczynanie kolejnego zadania, nie kończąc poprzedniego. 

Wszystko, o czym za mało mówi się w branży IT.

Prosto na Twoją skrzynkę.

Oświadczam, że zapoznałem/am się z Polityką Prywatności oraz akceptuję jej treść.

Leave this field empty if you’re human:

Kiedy użyć czego?

Moim zdaniem Scrum będzie bardziej użyteczny w zespołach, których praca musi mieć “mierzalny” postęp. W przypadku zespołów developerskich oznacza to projekty, w których wymagane jest demonstrowanie postępów prac poza gronem zespołu. Scrum znajdzie też zastosowanie w zespołach, które dopiero zaczynają ze sobą pracę, bądź występuje w nich duża rotacja. Spotkania, takie jak Sprint Retrospective pozwalają członkom zespołu poznać się lepiej oraz poprawić niedociągnięcia pojawiające się w czasie pracy.

Kanbana użyłbym w zespołach składających się z większej liczby seniorów, którzy nie muszą koordynować pracy tak często i gdzie nie ma dużej różnicy w szybkości pracy członków zespołu. Jest to również dobra metodologia dla mniej licznych zespołów, w których bardziej liczy się efekt końcowy, niż postępy w czasie. Także projekty, w których zadania nie są ze sobą powiązane (devops) skorzystają z dobrodziejstw Kanbana.

Spójrzmy na przykładowy projekt w celu porównania. Klient chce, aby zespół developerski wykonał aplikację do robienia i przechowywania zdjęć. Główne funkcje aplikacji to zrobienie zdjęcia, wysłanie do backendu, na backendzie zapis i ich prezentacja na stronie www.

Gdyby w tym przypadku użyć Scruma łatwo byłoby demonstrować postępy w tworzonej aplikacji, ustalając kolejne ww. etapy jako cele kolejnych Sprintów. Z drugiej strony brak elastyczności w ramach Sprintu prowadzić może do dostarczenia funkcjonalności, która przy zmienności wymagań okazać się może zbędna. 

W przypadku nawet tak prostej zmiany funkcjonalności jak zmiana formatu akceptowanych plików może okazać się, że na implementację trzeba czekać do rozpoczęcia kolejnego Sprintu. Jednak w przypadku zmian w składzie zespołu, dużo łatwiej planować ilość skończonej pracy w jednostce czasu korzystając ze Scruma. Kanban zakłada, że cały zespół ma podobną wydajność i żadne zadanie nie będzie trwało znacznie dłużej niż pozostałe. 

Czy zatem któraś z metodologii jest lepsza?

To zależy od przypadku użycia. Osobiście dużo lepiej pracowało mi się w Kanbanie, z uwagi na minimalną ilość spotkań i tzw. overheadu. Kanban szczególnie dobrze sprawdził się w projektach z krótkim czasem dostarczenia całości funkcjonalności i przy braku monitorowania postępów. 

Z drugiej strony, pracując na projekcie z dość dużą rotacją i możliwość pracy nad zadaniami zarówno mniej, jak i bardziej skomplikowanymi, używałem Scruma, który tutaj okazał się idealny. Pozwalał nowym członkom zespołu na szybsze wdrożenie się w projekt. Większa ilość spotkań pozwala też na większą kontrolę nad zadaniami i projektem ze strony developerów.

Zdjęcie główne artykułu pochodzi z unsplash.com.