Scrum vs Kanban w rozwoju oprogramowania

Scrum – metodyka, metodologia czy framework?

Odpowiedź na to pytanie może okazać się niezwykle wymagająca, szczególnie jeśli pracujemy w środowisku międzynarodowym i staramy się tłumaczyć poszczególne słowa na języki ojczyste z języka angielskiego, a które to znaczenia i tłumaczenia mogą okazać się bardzo niejednoznaczne lub wręcz niemożliwe do translacji.

Jeśli jednak uznamy, że to Scrum Guide powinien być naszym przewodnikiem i drogowskazem po zwinnej przygodzie związanej z wytwarzaniem oprogramowania, to wówczas odpowiedź na pytanie, czy Scrum to metodyka, metodologia czy framework, jest bardzo prosta. Słowa „metodyka” i „metodologia” nie pojawiają się tam ani razu, natomiast „framework” w odniesieniu do pojęcia Scruma występuje w tekście aż 9-krotnie!

Możemy zatem bez wchodzenia w skomplikowane i niejednoznaczne definicje stwierdzić, że framework jest najlepszym i najbezpieczniejszym określeniem Scruma.

Scrum vs Agile

Pojęcia Scrum i Agile często są używane w celu określenia tego samego podejścia/pojęcia, a nie powinny. Agile zawiera w sobie całą grupę różnych od siebie podejść (frameworków) zwinnych, np. SAFe, Scrum, LeSS, Nexus, które można dopasować do potrzeb swojej organizacji. Agile to pojęcie ogólne określające zwinne, aktywne podejście do wytwarzania oprogramowania (lub innych projektów). Definiuje zasady, dobre praktyki, które umożliwiają reakcję i zmianę kierunku rozwoju w dowolnym momencie trwania projektu. Dzięki temu tworzy przewagę nad tradycyjnym podejściem, które u podstaw zakłada przestrzeganie harmonogramu i wcześniej ustalonego zakresu oraz kosztu. Z kolei Scrum określa tylko jedną z wielu dostępnych możliwości, podejść zwinnych do zarządzania projektami.

Scrum:

• Jest elastycznym i proaktywnym podejściem do zarządzania projektami.
• Dzieli projekt na niezależne, w pełni samoorganizujące się zespoły.
• Posiada Iteracje (Sprinty).
• Jest oparty na 3 filarach: inspekcja, adaptacja, przejrzystość.
• Dedykowany jest dla organizacji, w których są małe zespoły, proste produkty, bez skomplikowanych powiązań z innymi zespołami.
• Wprowadza: Sprint Planning, Daily Standup, Refinement, Retrospekcję, Sprint Review oraz wyróżnia zakresy odpowiedzialności: Product Owner, Scrum Master, Zespół Developerski.

Zespoły w Scrumie ciągle usprawniają swoje procesy i sposób pracy. Im bardziej doświadczony i zgrany ze sobą zespół, tym jego efektywność jest większa. Przy tworzeniu zespołu należy pamiętać, że musi on zawierać wszystkie kompetencje potrzebne do zdefiniowania wymagań, stworzeniu kodu i przetestowania funkcjonalności.

Scrum Guide 2020

Scrum Guide zawiera w sobie definicje, opis reguł, ról, wydarzeń, artefaktów czy dobrych praktyk podczas zarządzania projektami. Pierwsza wersja dokumentu powstała w 2010 roku, a jej autorami byli Amerykanie: Ken Schwaber i Jeff Sutherland. Ostatnia aktualizacja pojawiła się w 2020 roku i poniżej zostały przedstawione elementy, które zostały zmienione, dodane lub usunięte w odniesieniu do poprzedniej wersji z 2017 roku.

Zmiany w Scrum Guide:

• Przewodnik został skrócony i uproszczony.
  • Autorzy zmienili styl, uprościli język, aby zawartość była bardziej zrozumiała, a użyte słowa były uniwersalne (wcześniej były odwołania głównie do branży IT).
• Rezygnacja z nakazów lub ich złagodzenie, odejście od przykładowych pytań na Daily Standup, mniej jednoznaczne zwrócenie uwagi na konieczność uwzględnienia pomysłów, usprawnień z Retrospekcji w Backlogu Sprintu.
• Podkreślenie wartości zespołu i wszystkich osób odpowiedzialnych za tworzony produkt.
• Został wprowadzony „Cel Produktu”, aby przypomnieć, do czego zespół został stworzony.
• Dodano zobowiązania:
  • Dla Backlogu Produktu to Cel Produktu.
  • Dla Backlogu Sprintu to Cel Sprintu.
  • Dla Incremetu (Przyrostu) to Definicja Ukończenia (DoD).
• Zamieniono wyrażenie „Samoorganizujący się zespół” na „Samozarządzający się zespół” w celu podkreślenia, że to zespół niezależnie decyduje, kiedy, kto i jak wykona pracę.

Czym jest Scrum?

Odpowiedź na najprostsze pytanie „Czym jest Scrum?” nie będzie w moim odczuciu możliwa bez dosłownego przytoczenia cytatu pochodzącego ze Scrum Guide. Niech ten cytat stanowi początek naszych rozważań.

Scrum to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów. Najprościej rzecz ujmując, Scrum wymaga, aby Scrum Master przyczyniał się do tworzenia środowiska, w którym:  

1. Product Owner porządkuje pracę potrzebną do rozwiązania złożonego problemu, tworząc Product Backlog.

2. Scrum Team przekształca wybraną część tej pracy w wartościowy Increment w trakcie Sprintu.

3. Scrum Team oraz jego interesariusze sprawdzają efekty i dostosowują swoje działania na potrzeby kolejnego Sprintu.

4. Powtórz

Scrum jest prosty

Scrum tak naprawdę opiera się na iteracji – powtarzalności Sprintów i Przyroście (Increment) – systematycznym rozbudowywaniu poprzednich efektów pracy oraz weryfikacji, czy wszystkie poprzednie przyrosty są do siebie dopasowane. „Scrum jest prosty” – napisali twórcy Scruma, Ken Schwaber oraz Jeff Sutherland. Oznacza to, że Scrum postrzegany jako framework może być niekompletny i nie odpowiadać na wszystkie pytania, jakie mogłyby zostać zadane podczas implementacji tego podejścia w organizacji. Jest to jednak działanie celowe – zamiast dawać gotowe odpowiedzi na pytania oraz szczegółowe instrukcje – Scrum stwarza pole do rozwijania wzajemnych relacji i interakcji międzyludzkich.

Zespół Scrumowy

W Scrumie podstawowym elementem jest mały zespół, w skład którego wchodzą Product Owner, Scrum Master i Developerzy. Zespół Scrumowy nie dzieli się na podzespoły i nie obowiązuje w nim hierarchia – każdy z członków zespołu jest w taki sam sposób odpowiedzialny za pracę, jaką wykonuje zespół. Warto w tym momencie zaznaczyć, że mianem „Developera” nie nazywamy tylko i wyłącznie programisty, ale również osoby pełniące inne funkcje  bądź wykonujące inne zawody, których obecność jest niezbędna do ukończenia zaplanowanej pracy,  np. UX designer, Analityk Biznesowy, etc. Wszyscy członkowie zespołu skupieni są na realizacji celu sprintu i odpowiedzialni są za osiągnięcie Celu Produktu.

Zespół Scrumowy nie powinien liczyć więcej niż 10 osób – doświadczenie podpowiada, że tylko wówczas osiągana jest najlepsza zwinność pracy, a także możliwa jest lepsza komunikacja i synergia. Jeśli zespół jest liczniejszy, prawdopodobnie należałoby rozważyć jego podział na dwa mniejsze – z tym samym Backlogiem, Celem Produktu i Product Ownerem.

Trzeba podkreślić, że Zespoły Scrumowe są samozarządzalne, co oznacza, że sam zespół decyduje o tym, kto, kiedy i jak będzie wykonywać określoną pracę. To także Zespół Scrumowy jest odpowiedzialny za stworzony co Sprint użyteczny Increment (Przyrost), czyli najczęściej działającą część aplikacji.

Developerzy

Jak mówi Scrum Guide, developerzy to „osoby w Scrum Teamie zobowiązane do wytworzenia każdego aspektu użytecznego Incrementu w każdym Sprincie”. Warto podkreślić raz jeszcze, że developerzy wbrew sugerującej nazwie to nie tylko programiści, ale każda osoba, której niezbędne umiejętności są koniecznie do ukończenia i zrealizowania Celu Sprintu. Developerzy są odpowiedzialni między innymi za stworzenie Backlogu Sprintu, zapewnienie jakości zgodne z Definition of Ready, a także wzajemne wspieranie się, pomoc i egzekwowanie odpowiedzialności za pracę.

Product Owner

Product Owner jest odpowiedzialny za maksymalizację wartości biznesowej produktu, nad jakim pracuje Zespół Scrumowy. Co jest ważne, Product Owner nie jest i nie może być przełożonym lub managerem zespołu! Jest to członek Zespołu Scrumowego na równorzędnych prawach i obowiązkach wskazanych w Scrum Guide. Do obowiązków Product Ownera należą między innymi ustalanie priorytetów Backlogu, tworzenie nowych elementów (zadań) Backlogu, ich objaśnianie i doprecyzowanie.

Product Owner to jedna osoba – nie grupa lub zespół, który odpowiedzialny będzie za powyższe zadania. Product Owner może i powinien oczywiście brać pod uwagę zdanie interesariuszy, biznesu i innych osób zaangażowanych w projekt, jednak ostatecznie to on podejmuje finalne decyzje. Bardzo ważne jest, aby decyzje podjęte przez Product Ownera respektowane były przez całą organizację.

Scrum Master

Scrum Master to przywódca służebny odpowiedzialny za efektywność pracy Zespołu Scrumowego oraz za to, aby Scrum był stosowany zgodnie z zaleceniami i wskazówkami zawartymi w Scrum Guidzie.

Scrum Master wspiera Zespół Scrumowy między innymi poprzez:

• Naukę jak być samozarządzający i samowystarczalny.
• Usuwanie blokerów i przeszkód, jakie napotyka w swojej pracy Zespół Scrumowy.
• Upewnienie się, że spotkania scrumowe odbywają się, zespół zna ich cel, a także, jeśli to potrzebne, pomaga w ich przebiegu i facylitacji.

Scrum Master pomaga Product Ownerowi między innymi poprzez:

• Znajdowanie sposobów efektywnego zarzadzania Backlogiem.
• Zrozumienie i wprowadzenie empirycznego podejścia do pracy w środowisku zwinnym.
• Współpracę z interesariuszami, w sytuacji gdy zachodzi taka potrzeba lub jest o to poproszony.

Scrum Master wspiera organizację między innymi poprzez:

• Szerzenie wiedzy o Scrumie i upewnianie się, że wszystkie osoby zaangażowane rozumieją ideę iteracyjnego i przyrostowego wytwarzania oprogramowania.
• Usuwanie blokerów, barier i niezrozumienia pomiędzy Zespołem Scrumowym a interesariuszami.
• Szkolenie organizacji i jej członów w procesie wdrożenia i adaptacji Scruma.

Praca Scrum Mastera w zależności od danego projektu, jak również od dojrzałości zespołów i organizacji, może się różnić celami oraz zadaniami, na jakich Scrum Master powinien się skupić. Powyższa lista stworzona na podstawie przykładów zawartych w Scrum Guidzie oczywiście nie wyczerpuje wszystkich zadań i wyzwań, jakie w swojej pracy może napotkać Scrum Master. Zwinne środowisko charakteryzuje się nierzadko dużą zmiennością, zatem Scrum Masterzy powinni być świadomi wyzwań, jakie czekają na nich w pracy z Product Ownerem, zespołem oraz organizacją.  

Wydarzenia w Scrumie

Scrum zawiera w sobie kilka określonych wydarzeń (spotkań), których nazwy na pierwszy rzut oka mogą być enigmatyczne lub wręcz niezrozumiałe dla postronnego obserwatora (Sprint, Sprint Planning, Daily Scrum, Sprint Retrospective). Celem wydarzeń jest stworzenie takiego środowiska pracy, aby było odpowiednio przejrzyste. Spotkania są także możliwością do inspekcji i adaptacji artefaktów Scruma. Pamiętajmy, że rezygnacja z organizacji któregokolwiek z wydarzeń lub przeprowadzenie ich w inny, niż opisany w Scrum Guidzie sposób, wiąże się z utratą wcześniej wspomnianej możliwości inspekcji i adaptacji. Spotkania powinny odbywać się w tym samym miejscu i w tym samym czasie, aby wyeliminować komplikacje i ewentualne zamieszanie. Dobrze zaplanowane spotkanie staje się rutynowe i daje możliwość dobrego przygotowania się do niego wszystkim osobom w nie zaangażowanym.

Sprint

Sprint jest Wydarzeniem Scrumowym, które zawiera w sobie wszystkie inne wydarzenia. Długość Sprintu powinna wynosić maksymalnie 4 tygodnie, a kolejny Sprint rozpoczynany jest zaraz po ukończeniu poprzedniego. Każdy Sprint można uznać za osobny projekt, na którego końcu przedstawia się wyniki prac, jakie udało się wykonać w poprzednim okresie czasu. Cykle, czyli Sprinty, można by przedstawić jako klocki Lego, gdzie każdy kolejny przyczynia się do osiągniecia Celu Produktu, czyli np. zbudowania użytecznej aplikacji internetowej.

Sprint Planning

Sprint Planning jest pierwszym spotkaniem Sprintu, podczas którego cały Zespół Scrumowy ustala i decyduje, co będzie do wykonania w nadchodzącym Sprincie. To Zespół Scrumowy jest odpowiedzialny za przebieg i wartość spotkania, niemniej istnieje możliwość zaproszenia innych osób np. interesariuszy w charakterze doradców lub ekspertów, z których to wiedzy Zespół chciałby skorzystać. Sprint Planning powinien trwać maksymalnie 8 godzin (dla miesięcznych Sprintów), jednak zazwyczaj trwa zdecydowanie krócej.

Daily Scrum

Jest to 15-minutowe spotkanie dla developerów odbywające się codziennie w tym samym miejscu i stałym czasie. W trakcie Daily Scrum developerzy wskazują postęp w realizacji Celu Sprintu, a także tworzą plan na nadchodzący dzień pracy. Codzienne 15-minutowe spotkanie ułatwia komunikację w zespole, ukazuje problemy, z jakimi borykają się developerzy, oraz daje możliwość poruszenia tematów ważnych dla developerów. Daily może przybierać różną formę, byleby tylko spotkanie dotyczyło realizacji Celu Sprintu.

Sprint Review

Sprint Review to maksymalnie czterogodzinne spotkanie, na którym Zespół Scrumowy przedstawia interesariuszom efekty wykonanej podczas ostatniego Sprintu pracy, a także, jeśli to koniecznie, omawiane są przyszłe zmiany. Sprint Review wbrew stereotypowej, krążącej opinii nie powinien być tylko prezentacją, a raczej możliwością dyskusji, oceny i analizy tego, co udało się wykonać, oraz tego, co wykonane powinno być w nadchodzących Sprintach. Modyfikacja Backlogu podczas Sprint Review jest nie tylko dozwolona, lecz powiedziałbym – wysoce zalecana, jeśli tylko w toku rozmów i analiz pojawiła się taka konieczność.

Sprint Retrospective

Retrospektywa jest ostatnim wydarzeniem w Sprincie, a jego celem jest podniesienie jakości, efektywności i organizacja lepszej współpracy Zespołu Developerskiego podczas Sprintu. Retrospektywa Sprintu skupia się na osobach, procesach i interakcjach, na tym, jak przebiegały, a w szczególności na poprawie ich korelacji i funkcjonowania. Nie ma jednego sprawdzonego sposobu na udaną retrospektywę – można używać wirtualnych lub fizycznych tablic z podziałem na to, co poszło dobrze, źle i to, co można poprawić. Najbardziej pożądane zmiany można dodać do Backlogu Sprintu, aby nie umknęły uwadze Członkom Zespołu.

Definition of Ready i Definition of Done

Podczas pracy w zwinnych metodykach możemy się spotkać ze zwrotami „Definition of Ready” (Definicja gotowości) i „Definition of Done” (Definicja ukończenia). Są to bardzo pomocne elementy i dobre praktyki. Jasno określają (mierzą), czy jesteśmy gotowi na uwzględnienie zadania w Backlogu Sprintu (DoR) oraz czy zadanie spełnia wszystkie ustalone i wymagane kryteria potrzebne do stwierdzenia, że dane zadanie jest ukończone (DoD), a dokładniej:

DoR (przykłady):

• Zadanie jest właściwie opisane (posiada cel, zakres, kryteria ukończenia).
• Zadanie jest zrozumiałe dla wszystkich członków zespołu.
• Zadanie jest oszacowane i jest na tyle małe, że zespół jest w stanie ukończyć je w ramach jednej iteracji (np. dwutygodniowego Sprintu).
• Zadanie nie ma otwartych i znanych zależności względem innych zadań.

DoR jest weryfikowane najczęściej podczas Backlog Refinementu, na którym cały zespół wspólnie omawia nowe zadania jako kandydatów na kolejny Sprint (Sprinty). DoR może być stworzone w formie checklisty i dodane do każdego zadania lub może istnieć na platformie czy w przestrzeni Zespołu Developerskiego (np. Confluence) jako punkt odniesienia dla jego członków.

DoD (przykłady):

• Kod został stworzony w oparciu o wytyczne technologiczne i wewnętrzne wytyczne projektu.
• Zostały stworzone testy jednostkowe, wynik testów jednostkowych jest pozytywny.
• Kod został sprawdzony przez inną osobę niż autor (tzw. Code Review).
• Kryteria akceptacji zostały spełnione.
• Funkcjonalność została przetestowana i wyniki testów zostały udokumentowane.
• Nowo stworzona funkcjonalność nie zawiera otwartych błędów.

DoD określa zasady, które należy spełnić, aby ukończyć konkretne zadanie. Punkty z DoD powinny być takie same dla zespołów pracujących nad jednym produktem. Poszczególne zespoły mogą dodatkowo włączyć własne elementy, aby podwyższyć jakość tworzonego oprogramowania.

Backlog Produktu

Jest to zbiór wszystkich zadań, nad którymi zespół lub kilka zespołów pracuje równocześnie. To uporządkowana według priorytetów lista, która określa, co należy wykonać, aby otrzymać produkt. Każde zadanie w Backlogu zawiera listę wymagań klienta (User Story), zadania techniczne, defekty, etc.

Osobą odpowiedzialną za Backlog Produktu jest Product Owner – to właśnie on przekłada wymagania klienta na pojedyncze zadania i określa priorytety. Pozostałe osoby z zespołu również mają dostęp do Backlogu Produktu, mogą wspierać i również opracowywać zadania, niemniej jednak osobą odpowiedzialną i decyzyjną pozostaje Product Owner. Product Backlog może zawierać zadania, które są już gotowe do implementacji, jak również te, które są bardzo ogólne, pomysły czy propozycje usprawnień. Product Backlog nigdy nie jest wersją ostateczną – zadania są na bieżąco tworzone, opracowywane, zamykane itp.

Jeśli nie Scrum, to co?  

Dawno, dawno temu pracodawcy zachęcali do podjęcia pracy w młodym i dynamicznym zespole, podkreślając, jak ważne są dla nich komunikatywność, chęć szybkiego uczenia się, reagowania na zmiany i multitasking. Z biegiem lat i wraz z rozwojem nowych metodyk zarządzania multitasking, rozumiany jako wykonywanie wielu czynności jednocześnie, zyskał negatywne konotacje i dziś często przywodzi na myśl presję czasu, stres i przytłaczającą liczbę zadań. W 2009 roku Uniwersytet Stanforda chciał sprawdzić, czy multitaskerzy rzeczywiście lepiej radzą sobie z wykonywaniem zadań. Wyniki badań wskazywały jednoznaczne: za realizowanie wielu zadań jednocześnie płacimy wysoką cenę: zmniejsza się koncentracja, spada efektywność (według American Psychological Association nawet o 40%), a przeciążenie zadaniami może prowadzić nawet do obniżenia IQ czy trwałych zmian w mózgu. Obecnie świadomość na temat efektywnych metod zarządzania czasem rośnie. Odchodzi się od wielozadaniowości, ale komunikacja, elastyczność i ciągły rozwój nadal pozostają w cenie, stanowiąc fundamenty zwinnych metodyk rozwoju oprogramowania.

Kanban, czyli mindfullness w świecie IT

W świecie, w którym jesteśmy bombardowani wieloma informacjami z różnych źródeł i kanałów komunikacji, z pomocą przychodzą techniki mindfullness. Skupienie na tym, co tu i teraz, praktykuje się także w realizacji projektów IT. Kanban (z języka japońskiego Kàn, „znak” oraz Bǎn, „tablica”), to metodyka zwinna, która tak jak trening uważności pomaga okiełznać chaos i z szumu wyłowić to, co istotne. Zamiast rozpoczynać kolejne zadania i przełączać się między różnymi aktywnościami, zespół najpierw zamyka jedno zadanie, a następnie zaczyna pracę nad kolejnym, tak aby zadań o statusie „w toku” było jak najmniej.

Zasady i praktyki stosowane w Kanbanie

Kanban jako metodyka zwinna dąży do tego, by wyróżnia 4 zasady:

1. Zaczynanie od tego, co aktualnie się robi.
2. Zgoda na dostarczanie zmian przyrostowych.
3. Przestrzeganie procesu, ról i obowiązków.
4. Zachęcanie do przywództwa na wszystkich płaszczyznach.

A także dobre praktyki:

1. Wizualizuj.
2. Ogranicz pracę w toku.
3. Zarządzaj przepływem pracy.
4. Objaśnij zasady procesu.
5. Stosuj pętle informacji zwrotnych.
6. Udoskonalaj.

Potęga wizualizacji w Kanbanie

Kanban, podobnie jak mindfullness, wykorzystuje potencjał wizualizacji. Na tablicy Kanban można przedstawić wszystkie zadania wraz ze statusami prac (zaplanowane, w toku, zrobione) oraz śledzić przepływy pracy. Zyskujemy też bieżący wgląd w zadania, nad którymi aktualnie pracują inni członkowie zespołu. Idea jest prosta: Zamiast rozpoczynać jedno zadanie, przechodzić do następnego, a w międzyczasie rozgryzać kolejne, zespoły kanbanowe skupiają się na domykaniu rozpoczętych prac, tak żeby zadań o statusie „w toku” było możliwie jak najmniej.

Scrum vs Kanban

Chcemy być Agile – która metodyka sprawdzi się na początek? Oba podejścia ułatwiają pracę i są chętnie stosowane przez mniejsze zespoły. Kanban i Scrum zmierzają w tym samym kierunku, ale do osiągnięcia celu wykorzystują inne metody. Scrum skupia się na dostarczaniu ciągle udoskonalanego produktu, Kanban – na minimalizowaniu pracy w toku i doskonaleniu się.

Scrum

• Jest podejściem iteracyjnym, posiada określone ramy czasowe oraz podział odpowiedzialności.
• Nie wyróżnia ról, ale wyróżnia zakresy odpowiedzialności.
• Rolę facylitatora pełni Scrum Master, który pomaga namierzyć blokery.
• Zespół reaguje na wszelkie zmiany, dobierając zadania z Backlogu Produktu.
• Scrum jest dobrze opisany, a jego założenia są zdefiniowane w Scrum Guide.   

Kanban

• Nie ma ram czasowych, jest nastawiony na pracę ciągłą, przejrzystość i udoskonalanie procesów.
• Nie wyróżnia zakresów odpowiedzialności (nie ma tu Scrum Mastera czy Product Ownera).
• Cały zespół jest odpowiedzialny za rozwiązywanie powstałych problemów. Zespół na bieżąco reaguje na wszelkie zmiany.
• Podejście Kanban dąży do tego, żeby nie było żadnych braków, opóźnień, zapasów, kolejek, bezczynności, zbędnych operacji technologicznych i kontrolnych i przemieszczeń.

Oba podejścia działają motywująco na członków zespołu i są ukierunkowane na poprawę efektywności. Warto pamiętać, że metodykę powinniśmy dobrać odpowiednio do potrzeb projektu i mieć akceptację przez członków zespołu. Scrum czy Kanban wdrażany siłą może przynieść odwrotne skutki do zamierzonych. Dlatego dobrze jest przede wszystkim zadać pytanie „Co chcemy osiągnąć?” czy „Jakie są potrzeby naszego zespołu?”. Warto poświęcić czas na rozpoznanie potrzeb oraz poznanie wyzwań, z jakimi borykają się poszczególni członkowie zespołu w codziennej pracy.

Kiedy wykorzystać Scrum?

Scrum sprawdza się, w zespołach projektowych, które liczą nie więcej niż 10 osób i zajmują się wytwarzaniem produktu lub dostarczają usługi. Ponieważ Scrum zakłada ciągłe udoskonalanie rozwijanego produktu, np. oprogramowania, ta metodyka sprawdzi się, gdy członkowie zespołu szukają sposobu na poprawę jakości dostarczanego rozwiązania, a specyfikacja jest znana i dostarczana przez biznes (Product Owner). Sprawdzi się również w zespołach, którym zależy na ciągłości komunikacji, co ułatwiają spotkania scrumowe.

Kiedy wykorzystać Kanban?

Kanban warto wykorzystać w małych zespołach, które pracują nad projektami cechującymi się sporą dynamiką. Kanban sprawdzi się w sytuacji, gdy zespół potrzebuje dużej elastyczności działania. Jeżeli w twoich projektach zdarzają się przestoje i spadki efektywności, tablice kanbanowe pomogą namierzyć i usunąć blokery oraz usprawnić pracę, w co angażuje się cały zespół.

Kanban – cele

• Zminimalizowanie liczby zadań w toku i domykanie zadań.
• Identyfikowanie i usuwanie blokerów czy tzw. „wąskich gardeł”.
• Szybkie reagowanie na zmiany w dowolnym momencie.
• Lepszy wgląd w przepływ pracy.

Scrum – cele

• Dostarczanie działających funkcjonalności w krótkich czasookresach.
• Ciągłe rozwijanie i ulepszanie produktu.
• Elastyczne reagowanie na zmiany w ramach danego Sprintu.
• Inspekcja i usprawnianie procesów.

Jak mierzyć efektywność? Metryki w Scrumie i Kanbanie

Skąd będziemy wiedzieli, w jaki sposób wykorzystywane podejście przekłada się na efektywność naszej pracy? Czy w ogóle można ją jakoś zmierzyć? Zarówno w Kanbanie, jak i w Scrumie można wykorzystywać metryki, przy czym w przypadku Scruma, jak podkreśla Scrum Guide, nie są one istotą tego podejścia.

Dlaczego warto sprawdzać metryki i prezentować dane w zespole?

• Żeby sprawdzić, które zadania zespół ukończył, a których nie.
• Żeby sprawdzić, jak skuteczne było Planowanie Sprintu.
• Żeby poznać „Team Velocity” (najczęściej jest to średnia ukończonych Story Pointów, czyli jednostek wykorzystywanych do oszacowania pracochłonności, z kilku poprzednich Sprintów).
• Żeby kolejne Planowanie Sprintu było lepsze, wiarygodniejsze, bardziej przewidywalne.
• Żeby sprawdzić, czy są jakieś trendy w zespole (np. zwiększenie lub zmniejszenie produktywności).

• Burndown Chart (wykres spalania) – prezentuje ilość zadań dodanych do Sprintu z perspektywy czasu pozostałego do końca Sprintu. System wyznacza dwie linie, pierwsza to „idealna linia”, która z wyprzedzeniem pokazuje wariant perfekcyjny (dzienna ilość zamykanych zadań w Story Points), a druga to rzeczywista linia, która wskazuje, gdzie jesteśmy faktycznie. Wykres pozwala zweryfikować, czy działamy zgodnie z oczekiwaniami, wskazuje, gdzie mamy zaległości i jest mała szansa na ukończenie zadań w Sprincie, jak również  może wskazywać, że mamy pewnego rodzaju zapas.
• Velocity Chart – wizualizuje ilość pracy zaplanowanej vs ukończonej dla zakończonych Sprintów. Ten wykres pomaga znaleźć optymalną ilość Story Points dla zespołu jako punkt odniesienia dla Planowaniu Sprintu.
• Weryfikacja, czy cel Sprintu został osiągnięty.
• Ilość ukończonych Story Pointów na jedną osobę.
• Ilość błędów w Sprincie.
• Ilość zadań dodanych lub usuniętych podczas trwania Sprintu.
• Średni czas potrzebny do ukończenia 1 Story Pointu.

Przykłady metryk w Kanbanie

• Work in Progress (praca w toku) – liczba zadań, które zostały rozpoczęte, ale jeszcze nie są ukończone.
• Lead time – jest to średnia ilość czasu od powstania zgłoszenia do jego zakończenia.
• Cycle time – to średnia ilość czasu pracy nad zadaniem.
• Throughput – ilość zadań ukończonych.
• Flow Diagram – skumulowany wykres, które prezentuje zmiany w czasie z perspektywy statusów zgłoszeń.

Metryki w Scrumie i Kanbanie mogą się różnić od siebie ze względu na inną organizację pracy, niemniej jednak można je wykorzystać dodatkowo. Zebrane dane należy zaprezentować zespołowi i porozmawiać o tym, czy wykresy odzwierciedlają rzeczywistość, a w Scrumie – sytuacje ze Sprintu (lub z kilku ostatnich Sprintów) oraz czy można na ich podstawie wdrożyć nowe pomysły i usprawnienia.

Prezentowanie metryk w zespole nie ma na celu stworzenia presji, że „powinien dostarczać więcej i szybciej”. Celem głównym jest zapewnienie, że zespół wie, gdzie i w jaki sposób korzystać z metryk, jaką wartość uzyskuje poprzez prezentacje danych. Dodatkowo tworzy przestrzeń do dyskusji. Poza wyżej przedstawionymi metrykami warto również pamiętać o roli komunikacji w podejściu Agile, a zatem regularnie rozmawiać z klientem końcowym czy wykonać testy użyteczności. Pozwoli to ocenić jakość produktów, które zespół tworzy, z innej perspektywy.

Podsumowanie  

W czasach, gdy projekty rozwoju oprogramowania charakteryzuje dynamika, Zespół Developerski dysponujący możliwościami, jakie dają Scrum czy Kanban, może pracować efektywniej. Oba podejścia zwinne skupiają się na ciągłym doskonaleniu. Scrum na udoskonalaniu funkcjonalności tak, aby pod koniec każdego Sprintu zespół mógł dostarczyć działający element oprogramowania. Kanban – na rozwijaniu współpracy i ciągłym jej udoskonalaniu. Bez względu na to, który framework wybierzesz dla swojego projektu, możesz być pewien, że przyniesie on długofalowe korzyści dla rozwoju produktu.