Agile, Scrum, Kanban: co to jest i jak działa

Tomasz jest początkującym Scrum Masterem. Tomasz słyszał o wielu frameworkach, ale zakochany jest wyłącznie w Scrumie. Kiedy więc jego przyjaciel Marek – PM, który zarządza projektami Kanban – mówi o braku sprintów i ważności wykonania każdego zadania, brew Tomasza mimowolnie unosi się w górę w zdziwieniu. „Jak można tak pracować?” – w jego oczach czyta się nieme pytanie.

Nie każdy początkujący menedżer wie, jak działają podejścia i frameworki, z którymi jeszcze się nie spotkał. Jednak znajomość artefaktów, zasad i celów, na których opierają się różne metodyki, przydaje się nie tylko w kłótniach z przyjaciółmi PM. Znając te informacje łatwiej jest porozumieć się z wieloma klientami i developerami, którzy są nowi w zespole, a wcześniej pracowali z innym systemem i nie wpadać w panikę z powodu przełączania się na inny format zarządzania projektem, gdy stary nie działa.

Nie zamierzamy narzucać opinii, chwalić jednego podejścia i mówić o wadach drugiego. Jaki jest w takim razie sens tego artykułu? My opowiemy Ci z czym to się je, a Ty sam możesz wyciągnąć wnioski.

Elastyczne metody

Agile to elastyczna, ustrukturyzowana, iteracyjna metoda zarządzania projektami. Właściwie, stąd nazwa – Agile – „zwinny, elastyczny”. W rzeczywistości jest to coś więcej. Nie jest to jedna metodyka, ale cały system metod elastycznych, który obejmuje nie tylko Scrum i Kanban.

Wartości Agile:

• ludzie i interakcje są ważniejsze niż procesy i narzędzia;
• działający produkt jest ważniejszy niż obszerna dokumentacja;
• współpraca z klientem jest ważniejsza niż uzgodnienie warunków kontraktu
• gotowość do zmian jest ważniejsza niż trzymanie się pierwotnego planu.

„Tym samym, nie odrzucając ważności tego, że po prawej stronie, wciąż bardziej liczy się to, co po lewej” – podkreśla Manifest Agile.

Manifest Agile to główny dokument agilistów, powstały w 2001 roku, który opisuje wartości i zasady elastycznego modelu.

Zasady Agile

Elastyczność Agile polega na tym, że należy skupić się na ciągle zmieniających się warunkach. Dlatego też zmiany w wymaganiach są nie tylko mile widziane, ale również zatwierdzane. W końcu zaspokojenie prośby klienta i dostarczenie maksymalnej wartości użytkownikom jest najwyższym priorytetem. Dostarczenie działającego produktu do klienta odbywa się w stosunkowo krótkim czasie – od kilku tygodni do kilku miesięcy.

Motywacja jest tym, na czym opiera się projekt. Dlatego w interesie PM leży motywowanie zespołu i zapewnienie wsparcia właścicielom biznesowym. Najskuteczniej można to robić na spotkaniach, gdzie przekazywanie informacji odbywa się osobiście, w obecności wszystkich i poza korespondencją, aby uniknąć źle przekazanej informacji.

Elastyczność elastycznością, ale bez spójności też daleko nie zajdziesz. Agile sprzyja trwałości. Proces jest podzielony na równe interwały czasowe – iteracje. Klient w tych samych interwałach otrzymuje gotowe do użycia funkcje dla swojego oprogramowania. Użytkownicy wiedzą, że aktualizacje są wypuszczane, powiedzmy, raz w miesiącu.

Ponieważ zespół w Agile jest samoorganizujący się, samodzielnie analizuje swoje działania i koryguje je. Stała dbałość o doskonałość techniczną i jakość architektury przyczynia się do samej elastyczności, która jest tak ważna w Agile.

Zespół samoorganizujący się to zespół, którego członkowie pracują na rzecz wspólnego celu i podejmują decyzje samodzielnie, bez akceptacji kogoś „nad” nimi. Zasady, na których opiera się praca takiego zespołu, przyczyniają się do samorealizacji każdego członka zespołu. Istnieje zaufanie do siebie nawzajem i wiara w słuszność podejmowanych decyzji.

Czy słyszeliście, że „prostota jest najlepszą cechą człowieka”? Cóż, nie tylko człowieka, ale i pracy. Nie robić rzeczy, które nie są zapisane w wymaganiach to sztuka, bo często chce się dodać „coś ekstra”. Trzeba być ostrożnym i w porę się zatrzymać, bo dobre chęci mogą zagrać przeciwko was. Agile nie wita niczego poza wymaganiami, niczego „ponad miarę”. Dlatego nie należy robić rzeczy niepotrzebnych. Po prostu się tego nie robi.

Jak śledzi się postęp projektu w Agile? Poprzez uruchomienie oprogramowania. Ten punkt zawiera w sobie wszystkie poprzednie. Bez udanej realizacji każdego z poprzednich kroków i przestrzegania każdej z zasad, na których opiera się Agile, nie będzie działającego oprogramowania.

Popularne metody Agile

Nie istnieje żadnego wiarygodnego rankingu „Najpopularniejszych metod w zarządzaniu projektami”. Wykresy, które krążą w internecie, trudno uznać za dokładne. Chodzi o to, że wiarygodne dane wymagają przepytania PM-ów ze wszystkich zakątków świata – od Ameryki po Chiny. Trzeba przyznać, że jest to trochę trudne.

Kolejną przeszkodą w tworzeniu dokładnych statystyk jest to, że nie każdy rozumie, pod jakim frameworkiem pracuje, jakkolwiek absurdalnie to brzmi. Ktoś, kto ma zespół 30 programistów, którzy wszyscy są w tym samym zespole, może myśleć, że pracują w Scrumie. Ktoś myśli, że zarządza przez Kanban, przy czym przydziela każdemu członkowi zespołu swoją rolę (spoiler dla początkujących: nie wolno tego nigdy robić w tych frameworkach). Niektórzy pracują bez frameworków w sensie kanonicznym i wcale się tego nie wstydzą.

Scrum i Kanban

Przy tak nieprecyzyjnych danych źródłowych bardzo trudno jest określić, która z metod jest najbardziej popularna. Na podstawie praktyki naszych studentów, mentorów i prelegentów zarządzających projektami, najpopularniejsze „czyste” frameworki to Scrum i Kanban. Hybrydowe (50% jednego i 50% drugiego) i niestandardowe frameworki się nie liczą.

Dlatego porozmawiajmy o tych dwóch „graczach” – Scrum i Kanban. Są oni jak napastnik i obrońca w piłce nożnej, mają różne zasady i schematy gry. Agile jako trener – choć „podzielił się” swoimi wartościami i wiedzą, pozostaje osobną postacią.

Scrum

Być może, gdy słyszymy frazę „elastyczna metoda”, mamy przed oczami obraz chaosu, programistów uciekających przed terminami i kierowników wyrywających sobie włosy z głowy. Scrum, choć jest elastyczny, jest metodą ustrukturyzowaną. Bądźmy jak Scrum i rozpatrzmy wszystko po kolei.

Zespół Scrum: czy można nakarmić wszystkich dwoma pizzami

Kiedyś Jeff Bezos, twórca Amazona, ustanowił zasadę: każdy wewnętrzny zespół musi składać się z tylu pracowników, ilu można nakarmić dwiema pizzami. Faktem jest, że można pracować produktywnie i współpracować ze sobą tylko wtedy, gdy w zespole jest niewielka liczba osób. Powiedzmy, że od pięciu do dziewięciu.

Być może w tamtych czasach ludzie jedli mniej lub pizze mogły być większe, ale istota tej zasady została przyjęta przez Scrum. Liczba osób w zespole nie powinna przekraczać 9. Każda większa liczba to już nie jest zespół Scrumowy.

W takim zespole występują 3 role:

• właściciel produktu, który przede wszystkim występuje jako głos klienta;
• scrum master – mistrz jedi, który koordynuje pracę w zespole i jest swoistym pomostem pomiędzy menedżerem produktu a zespołem developerskim;
• zespół developerski jest samoorganizujący się i cross-funkcjonalny.

Iteracje: dlaczego sprinty, a nie tygodnie pracy

Scrum jest podejściem iteracyjnym. Iteracje nazywane są „sprintami”, a ich czas trwania jest określany na początku projektu i ustalany do końca. Sprinty trwają zwykle od dwóch do czterech tygodni (bardzo rzadko jeden tydzień). Im są krótsze, tym łatwiej jest pracować ze zmianami. Gdy sprint jest 1- lub 2-tygodniowy, łatwiej jest dokonywać edycji backlogu produktu w miarę potrzeb, niż gdy iteracja trwa cztery tygodnie. Miliony poprawek są niezalecane podczas sprintu. Jeśli okaże się, że jakieś zadanie w pracy nie jest tak ważne dla klienta i jest zupełnie nieistotne dla projektu jako całości, to zdecydowanie się je usuwa.

Po co w ogóle te sprinty, skoro są zwykłe ludzkie tygodnie? Żeby dodać kolejne słowo do słownika developerów? Oczywiście, że nie, to jest miernik. W ramach sprintu zespół musi wykonać zaplanowany scope.

Scope – zawartość projektu: co, jak i dla kogo musi być zrobione, aby projekt można było uznać za zrealizowany.

Nie dla wszystkich zespołów odpowiedni będzie termin – tydzień. Powodów może być wiele: ogólny harmonogram projektu, liczba osób w zespole programistów, liczba zadań itp. Dla jednego projektu sprint może trwać dwa tygodnie, ale dla innego optymalne są cztery. Na koniec każdego sprintu zespół prezentuje wyniki klientowi.

Celem metody jest zakończenie sprintu, idealnie zrealizowawszy wszystkie zadania. Najważniejsze jest dostarczenie klientowi działającej wersji produktu w formie demo. Zdarza się, że niektóre z zadań nie są ukończone na czas. Jeśli to zadanie nie jest niezbędne do działania funkcji, to nic nie szkodzi: zostanie przeniesione do następnego sprintu.

Spotkania: strata czasu czy ważna, strategiczna część Scruma?

Spotkanie. Słowo, które sprawia, że serca Scrum Masterów biją szybciej, a developerzy wzdychają. Ci ostatni często są wściekli i nie rozumieją, po co to wszystko, skoro można po prostu pracować przez dodatkową godzinę. Agile, z którego wywodzi się Scrum, mówi, że interakcja twarzą w twarz jest ważniejsza i bardziej produktywna niż interakcja pośrednia. Łatwiej jest się dogadać twarzą w twarz niż w slacku, kiedy wisi 50+ nowych wiadomości i nie pamiętasz, od czego to wszystko się zaczęło.

Sprint planning meeting

Na tym spotkaniu decydują się losy. Nie, nie ludzkości – sprintu. Obecni są Scrum Master, właściciel produktu i zespół developerski. Właściciel produktu mówi im, co chce zobaczyć na koniec sprintu. Developerzy wyjaśniają potrzebne momenty, aby uniknąć miliona pytań, które mogą pojawić się w procesie. Zespół obgaduje nakład pracy. Na podstawie tego wszystkiego określany jest cel sprintu. W ten sposób przebiega pierwsza część spotkania. W drugiej części zespół sporządza backlog sprintu – zadania do realizacji.

Długość spotkania planistycznego zależy od długości sprintu. Na spotkanie planistyczne przeznacza się 2 godziny na każdy tydzień w sprincie. Jeśli ustalimy, że sprinty będą trwały 2 tygodnie, to na planowanie należy przeznaczyć 4 godziny. Jeśli cała kawa jest wypita, plecy bolą od tak długiego siedzenia na spotkaniu, a samo spotkanie trwało ponad 8 godzin, to coś poszło nie tak. Zastanów się: czy to przypadek, czy może tendencja do zaciągania spotkań? W przypadku wzorca, prawdopodobnie Twój Scrum wymaga przeskalowania.

Daily Scrum Meeting

Codzienne spotkanie, które pomaga członkom zespołu zsynchronizować się. Ma służyć synchronizacji, a nie narzekaniu, chwaleniu się czy obwinianiu wszystkich na świecie.

Ponieważ zespół Scrum jest cross-funkcjonalny, wszyscy uczestnicy są ze sobą połączeni. Łatwiej jest dowiedzieć się, kto i jak jest połączony w ciągu 15-20 minut, kto ma iść do kogo i kto oczekuje czego od kogo dzisiaj, niż pingować wszystkich na świecie przez cały dzień.

Pytania, które choć są powtarzane z spotkania na spotkanie, są bardzo pomocne w zrozumieniu obecnej sytuacji dotyczącej postępu:

• Co zostało zrobione?
• Co zaplanowano?
• Czy są jakieś problemy i co może pomóc?

Sprint review meeting

Wszystko, co działo się w sprincie, było właśnie po to. Review jest motorem do dalszego postępu. Zespół developerski jasno pokazuje, co zostało zrobione podczas sprintu. Jeśli nie da się tego pokazać, to jest to wyjaśniane, jak to się mówi, na palcach. Dzieje się tak, gdy wykonano zadania techniczne, których nie da się pokazać, ale bez których nic nie będzie działać, albo będzie działać źle. Powstają wtedy sugestie, opinie, skargi i wizje dalszego rozwoju. Wszystko to jest brane pod uwagę przy tworzeniu kolejnego sprintu.

Czas na review jest przydzielany wprost proporcjonalnie do liczby tygodni w sprincie: jedna godzina dla sprintu jednotygodniowego i trzy godziny dla sprintu trzytygodniowego.

Sprint retrospective meeting

Wspinacz, który osiągnął szczyt góry, spogląda wstecz na pokonaną drogę, wychwytuje pewne spostrzeżenia, chwali siebie za to, co osiągnął. Robi w głowie notatki typu: „Następnym razem powinieneś kupić bardziej niezawodny sprzęt”. W Scrumie nazywa się to retrospective. Zespół zbiera się, aby wyjaśnić:

• Co było dobrze?
• Co było źle?
• Co można ulepszyć?

Retro odbywa się w ostatnim dniu sprintu. Nie ma jasno określonego limitu czasowego. Zazwyczaj to spotkanie trwa 45 minut pomnożone przez liczbę tygodni w sprincie.

Kanban

Jeśli Scrum jest podejściem strukturalnym, to Kanban jest podejściem równowagi. Metoda wizualna, dzięki której bardzo wyraźnie widać, czym należy się zająć w pierwszej kolejności. Tutaj celem jest wykonanie zadania. Zmiany i przesunięcia w planie są przyjmowane bezboleśnie. Nie trzeba nikogo karmić pizzami. W Kanban nie ma limitu osób w zespole ani długości iteracji, nie ma ról zespołowych i obowiązkowych spotkań. Co jest w zamian? Wszystko po kolei.

Role zespołowe: ktoś żyje?

Scrum nie jest Scrumem bez Scrum Mastera i innych ról. Inaczej jest w Kanban. Nie ma ról zespołowych, jest „zespół”. ” I za wszystko co robimy, odpowiadamy razem!” – słyszeliście coś takiego? To jest hasło zespołu Kanban, bo każdy jest odpowiedzialny za cały projekt.

Ze względu na osobliwości Kanbana, które zostaną omówione poniżej, zespół może składać się z kilku pod-zespołów: projektantów, programistów i analityków. Ich praca nie zawsze jest wykonywana równolegle, zwłaszcza we wczesnych fazach rozwoju. Zanim mistrzowie kodu przystąpią do pracy, projektanci muszą już opracować prototyp na podstawie danych, który z kolei musi zostać zebrany przez analityków.

Proces: chaos bez terminów?

W Kanban nie ma sprintów. Wszystkie prace projektowe odbywają się w sposób ciągły. Ważne wydarzenia projektowe – planowanie, releasy – odbywają się wtedy, gdy zespół o tym zdecyduje. Może to być konkretny dzień tygodnia lub „zrób to po tym jak zrobimy tamto”. W ten sposób releasy nie są związane z końcem iteracji. Udało się to zrobić znacznie wcześniej niż zakładano? Świetnie! Zrobiłeś to później? Zdarza się.

Tablica Kanban

Świadkowie okresu przedzdalnego pamiętają jeszcze tablicę Kanban w jej fizycznej formie – tablicy, na której zadania były rozdzielane za pomocą naklejek lub markerów. Obecnie stosuje się głównie wersje elektroniczne.

Ruch zadań na tablicy odbywa się od lewej do prawej: od statusu To Do, gdzie wszystkie zadania są zebrane do realizacji, do Done, gdzie zadania osiągają swoiste zen. Gdy wszystkie zadania przesuną się do kolumny Done, projekt uznaje się za gotowy.

Zadania na tablicy są wizualizowane dzięki kartom, na których zaznaczony jest priorytet. Aby mózg nie parował, a zespół nie pracował nad zadaniami 24 godziny na dobę, zadania w każdym ze statusów są ograniczone ich łączną wagą. Jeśli kolumna „Testowanie” ma limit wagi 3, to łączna waga zadań w tym statusie może wynosić 3.

Statusy Kanban

Dzięki statusom w roboczym czacie możesz dowiedzieć się, kto co robi, a dzięki statusom Kanbana możesz śledzić, co i jak długo trwa na każdym etapie. Statusy są po to, by zapewnić przejrzystość i stworzyć limit dla tych, którzy lubią zanurzyć się w zadaniu i taplać się w nim, nie kończąc żadnego. Liczba kolumn na tablicy zależy od projektu. Są podstawowe i opcjonalne – te dodaje się umownie w zależności od potrzeb i charakterystyki projektu.

Podstawowe:

• To Do 
• In Progress 
• Testing 
• Done 

W zależności od potrzeb, zespół może dodawać także inne kolumny. Na przykład Blocked – gdy zadanie zostało już wykonane, przetestowane, ale ze względu na jakieś błędy nie może zostać przeniesione do kolumny Done jako gotowe i bez błędów.

Co jest lepsze: Agile, Scrum czy Kanban

Agile, Scrum i Kanban łączy idea, że ludzie są kluczowym elementem projektu. Poza relacjami zawsze będą istniały zasady, które dla jednego zespołu są ważne, a dla drugiego zupełnie obojętne. To właśnie odróżnia je od siebie.

W poniższej tabeli porównajmy główne artefakty, które różnią się w Scrum i Kanban. Ich zasady opierają się na Agile, więc nie ma sensu porównywać bazy i dwóch frameworków, które z tej bazy wynikają.

Nie zamierzaliśmy pisać w końcowej części artykułu „…jak rozumiesz, najlepiej pracować według…”.  Twoje osobiste zrozumienie i zdrowy rozsądek najlepiej pomogą w wyborze podejścia lub ram dla Twojego projektu. Pomiędzy wartościami metody zarządzania projektem a Twoimi powinien istnieć mash-up.

Agile, Scrum i Kanban to igły w stosie metod i frameworków. Być może żaden z tych wymienionych w artykule nie sprawdzi się w Twoim projekcie. Nie rozpaczaj: jest wiele innych na każdy gust i kolor PM-a. Prelegenci na kursie Dao PM opowiadają o nich szczegółowo. Praktykujący PM dzielą się praktycznymi przykładami, wrażeniami pracy z tą czy inną metodą, a także pokazują wizualnie, jak interakcja przebiega w prawdziwym życiu.

Bez względu na to, który z frameworków wybierzesz do pracy, pamiętaj, że efekt końcowy jest zawsze ważniejszy od procesu, więc uważnie obserwuj, czy dana praktyka przybliża cię do upragnionej mety.