O co Kanban? - Code Sprinters

O co Kanban?

Czy często zdarza się wam słyszeć od znajomych, że pracują zgodnie z „metodologią Agile”? A jak często dopytując o szczegóły dowiadujecie się, że rozmówca stawia znak równości między Scrumem i Agile? O ile takie pomieszanie pojęć mogło być zrozumiałe kilkanaście czy dziesięć lat temu, dziś zaskakuje. Choć może nie powinno: wiele korporacji wytwarzających oprogramowanie – i niemal wszystkie nowe organizacje – mówią, że są Agile, a echo powtarza za nimi „mamy Scruma, mamy Scruma…”.

Agile to podejście do rozwiązywania problemów, ruch propagujący to podejście i metody (nie „metodologie”) podpowiadające, jak działać w sposób zwinny. Podobnie jest z metodami wywodzącymi się z podejścia Lean. Żadna z nich nie daje gotowej recepty, a jedynie ramy postępowania, które trzeba w świadomy sposób wypełnić kontekstem własnej organizacji. Scrum, Kanban, DSDM czy XP nie muszą być użyte, by organizacja stała się zwinna (lub choćby zwinniejsza). Mogą stanowić inspirację do stworzenia własnego, opartego na empiryzmie podejścia, być może efektywniejszego niż którakolwiek z wymienionych metod.

Scrum dobry na wszystko?

Najpopularniejszą z metod zwinnych jest Scrum, który poprawnie wdrożony daje efekt „wow”, gdy zespoły zaczynają efektywnie dostarczać działające i wartościowe (!) rozwiązania problemów biznesowych. Oczywiście nie każdej firmie i nie każdemu zespołowi się to udaje, ale dzieje się to na tyle często, że Scrum urasta do rangi złotego środka, rozwiązania wszystkich problemów. Cytując jednego ze znanych mi managerów, można nagle zrobić „więcej, lepiej, szybciej, taniej”. Być może, bo wielu firmom się to nie udaje, choć bynajmniej nie z winy samej metody.

Scrum doskonale sprawdza się w rozwoju produktów: empiryzm jest wbudowany w zdarzenia metody, która wspiera poszukiwanie najlepszych rozwiązań i sposobów ich realizacji. Jeśli organizacja lub zespół rozwija oprogramowanie (lub bardziej ogólnie: produkt), Scrum jest dobrym wyborem.

Często jednak zespoły nie rozwijają produktu, ale zajmują się realizowaniem zleceń (zadań technicznych, rozwiązywaniem błędów, ale też zatrudnianiem ludzi, obsługą prawną etc.). Najczęściej nie jest wtedy możliwe negocjowanie zakresu prac, bo te wynikają albo z umów, albo z regulacji prawnych, albo procesów organizacji. Empiryzm wciąż jest konieczny, ale na pierwszy plan wysuwa się optymalizacja przepływu zleceń przez system ich realizacji.

Kanban bywa lepszym rozwiązaniem

Być może wyszarpuję właśnie dywan spod nóg osób przekonanych, że aby być Agile, trzeba stosować Scruma. Nie trzeba. Jeśli nie rozwijamy produktu, a zależy nam na byciu zwinnym – zaprzyjaźnijmy się z Kanbanem mającym korzenie w podejściu Lean. Metoda ta skupia się na wyeliminowaniu marnotrawstwa i skupieniu się na tym, co przynosi wartość (klientom, firmie etc.). Kanban pozwoli nam na optymalizację obsługi zleceń, więc idealnie nadaje się do prac utrzymaniowych i realizacji zadań innych niż tworzenie nowych rozwiązań i produktów.

Aby zacząć pracę w metodzie Kanban nie jest konieczne zdefiniowanie nowych ról ani zdarzeń (spotkań). Założeniem metody jest ewolucyjne usprawnianie, więc pierwszym krokiem nie jest zmiana procesów, ale wizualizacja ich bieżącego stanu. Ma ona formę tablicy z kolumnami reprezentującymi poszczególne etapy, przez które przechodzą zlecenia. Reguły obsługi zleceń muszą być jasne – i spójne z wizualizacją na tablicy. W ten sposób realizowany jest w Kanbanie postulat przejrzystości niezbędny do empirycznego kontrolowania procesów.

W Kanbanie konieczne jest zarządzanie przepływem tak, by czas realizacji zlecenia był możliwie jak najkrótszy. Po co? Im krócej coś robimy, tym mniejsza szansa, że wymagania zmienią się w trakcie, poza tym to „przymusza” do skupienia się na małej ilości problemów na raz i wyeliminowania tego, co zbędne (mało wartościowe). W Scrumie cel ten realizowany jest poprzez ograniczoną (i stałą) długość Sprintu.

Kanban jest systemem pracy „pull”, czyli takim, do którego zadania są pobierane dopiero wtedy, kiedy istnieje możliwość ich zrealizowania. Oczywiście można sobie wyobrazić, że będziemy rozpoczynać kolejne zadania i robić równolegle wiele z nich, natomiast to automatycznie powoduje wydłużenie czasów realizacji. Ograniczenie ilości pracy w toku zabezpiecza przed zapchaniem procesu.

W Scrumie planowanie odbywa się w sposób skwantowany, na początku każdego Sprintu. W Kanbanie zlecenia mogą być pobierane do procesu w sposób ciągły, oczywiście w granicach rozsądku i tylko wtedy, gdy zdefiniowane limity pracy w toku na to pozwalają.

Łatwo sobie wyobrazić, że usprawnianie procesu, dopasowanie wysokości wspomnianych limitów i określenie zasad pobierania zleceń wymaga poddawania wszystkich tych elementów inspekcji i adaptacji, zupełnie jak w Scrumie. Różnica polega na tym, że Kanban nie proponuje wprost rozwiązania (zdarzenia), które by służyło temu celowi. Nic wszakże nie stoi na przeszkodzie, by cyklicznie przeprowadzać retrospektywy.

Dlaczego czasami Kanban działa lepiej?

Trzymając się zasad i praktyk metody Kanban można ewolucyjnie usprawnić proces tak, by nie pojawiały się wąskie gardła, czas realizacji zleceń był powtarzalnie krótki, a przepustowość całego systemu obsługi względnie stała. Tam, gdzie zasadniczym pytaniem nie jest „co i jak chcemy zrobić?” ale „na kiedy to będzie gotowe?”, Kanban jest lepszym rozwiązaniem niż Scrum.

Scrum nie pozwala łatwo radzić sobie z sytuacją, gdy zlecenia pojawiają się w sposób ciągły i nie ma możliwości negocjowania zakresu wymaganych prac. Wtedy również należy rozważyć skorzystanie z Kanbana.

Jaką metodę wybrać?

Każda z metod ma swoje zalety, ale też ograniczenia. Wybierając pomiędzy Scrumem i Kanbanem należy zrozumieć obie metody i zastanowić się, która lepiej pasować będzie do stanu, który chcemy osiągnąć (a niekoniecznie do stanu, jaki mamy teraz). Jakiego typu problemy będziemy rozwiązywać? Czy zależy nam na czasie realizacji, czy też na inkrementalnym rozwoju produktu i jego częstej walidacji?

Jeszcze bardziej ostrożnym należy być przy podejmowaniu decyzji o zmianie metody. Są organizacje, które rozwijają nowe produkty w Scrumie, po czym uciekają do Kanbana, bo uwiera ich zbyt krótki Sprint. Cóż, Kanban pozwoli ciągnąć prace nad jednym wymaganiem dowolnie długo, ale ciężko wtedy mówić o optymalizacji czasu jego realizacji…

Zróbmy sobie Scrumban

Uważny czytelnik zapewne już doszedł do wniosku, że da się pogodzić obie metody i de facto korzystać z nich jednocześnie tam, gdzie ma to sens. Rzecz jasna nie chodzi tu o wybranie tego, co nam pasuje ze Scruma i Kanbana – robiąc to ryzykujemy, że poniesiemy koszty transformacji nie zyskując nic w zamian. Natomiast można, i często warto, organizować pracę zespołu Scrumowego posiłkując się Kanbanem.

Jak to działa? Planujemy i poddajemy inspekcji produkt i proces tak jak w Scrumie, zespół jest zdefiniowany zgodnie z wymogami tej metody, również rygory czasowe (w szczególności stała długość Sprintu) jest zachowana. Natomiast dodatkowo wizualizujemy proces, ograniczamy ilość pracy w toku (na przykład pracując na raz tylko nad jednym z wymagań zaakceptowanych do Sprintu) i tak dalej. Innymi słowy przetwarzamy Backlog Sprintu korzystając z Kanbana.

Innym wariantem jest zastosowanie Kanbana w szerszym kontekście organizacji, to znaczy nie tylko do rozwiązywania już nazwanych i dobrze zdefiniowanych problemów biznesowych, ale także do całego pre-processingu oczekiwań i pomysłów, które mogą, ale nie muszą się przełożyć na wymagania, oraz do dostarczania lub wdrażania rozwiązań po tym, jak zostaną one przygotowane. Wtedy jednym z etapów w procesie Kanbanowym będzie „wytworzenie rozwiązania”, a etap ten z powodzeniem można realizować Scrumowo.

Warto też mieć cały czas świadomość, że ani Kanban, ani Scrum nie są „metodykami totalnymi” i nie odpowiadają na wszystkie pytania na temat tego jak działać powinna organizacja. Tak długo, jak nie są łamane zasady i wartości obu metod, każda z nich, albo obie jednocześnie, mogą uzupełniać już istniejące procesy i metody pracy. Co więcej, nic nie szkodzi na przeszkodzie, by zacząć ten model twórczo rozwijać i stworzyć własne rozwiązanie (ba! jest to właściwie nieuniknione przy dużej skali organizacji).

Jeśli chcecie dowiedzieć się więcej o Kanbanie, Scrumie lub Agile – zapraszamy na szkolenia.


SZKOLENIA ZWIĄZANE Z TEMATYKĄ ARTYKUŁU


O autorze: Rafał Markowicz
Scrum Master z wieloletnim doświadczeniem, w branży IT od 15 lat. Praktyk Agile pracujący z zespołami developerskimi, jednocześnie ekspert w zakresie inżynierii testów i zapewnienia jakości. Pracował jako analityk systemowy i biznesowy, jest doświadczonym developerem, managerem i konsultantem. Prowadzi szkolenia z zakresu Agile, Scrum, Kanban, testowania (nie tylko zwinnego) i zapewnienia jakości. Uczy jak tworzyć i dekomponować wymagania, jak definiować kryteria akceptacyjne i używać ich w procesie rozwoju produktu, jak pracować z wymaganiami funkcjonalnymi i niefunkcjonalnymi (w tym jak prowadzić testy wydajnościowe złożonych systemów).

Inne artykuły tego autora