IT eSky.pl

RSS

Scrum vs. System Kanban

Stała długość sprintu w Scrumie i związany z tym cykl spotkań często postrzegany jest przez zespoły jako narzut procesowy, spowalniający lub ograniczający możliwości zespołu. Zdarzało mi się słyszeć sugestię, że przejście do Systemu Kanban pozwoli zrobić więcej w tym samym czasie, bo nie będzie trzeba przerywać pracy tylko po to, by podsumować kończący się sprint i zaplanować kolejny. Zdarzało mi się też dostawać zapytanie, czy aby rozsądne jest restrykcyjne podejście do granic sprintu, skoro powoduje, że często nie można zacząć realizacji żadnego nowego wymagania, bo zostało za mało czasu na jego skończenie w sprincie.

Którą metodę wybrać?

Zawsze odpowiadam, że Scrum nastawiony jest na maksymalizację empiryzmu procesu, podczas gdy System Kanban skupiony jest przede wszystkim na optymalizacji przepływu wymagań przez proces developmentu. Scrum jest dobrym wyborem, gdy szukamy najlepszego rozwiązania problemów biznesowych i końcowy rezultat jest mało precyzyjnie określony. System Kanban może być efektywniejszy wtedy, gdy dość dobrze znamy cele i metodę, jaką chcemy je osiągnąć i chcemy to zrobić jak najszybciej. W szczególności System Kanban idealnie nadaje się do realizacji ściśle zdefiniowanych wymagań, na które mamy mały lub ograniczony wpływ, na przykład do prac utrzymaniowych i rozwiązywania błędów.

Zapewnianie empiryzmu

Podejście empiryczne, o którym piszę, to rozwój produktu i procesu jego wytwarzania w taki sposób, by najczęściej jak to możliwe dokonywać oceny tego, jakie skutki przyniosły poczynione zmiany i decyzje. W istocie każdy sprint w Scrumie jest eksperymentem: realizujemy wymagania będące zapisem hipotezy o sensowności i opłacalności konkretnego rozwiązania (zmiany, nowej funkcjonalności etc.) a następnie dokonujemy oceny tego, co udało się osiągnąć i planujemy kolejny sprint-eksperyment. W Systemie Kanban podobny efekt można uzyskać na wiele sposobów, na przykład oceniając rozwiązanie dla każdego wymagania zaraz po jego zrealizowaniu.

Jeśli zechcemy zachować empiryzm procesu na tym samym poziomie, wtedy Scrum i System Kanban będzie równie kosztowny i powolny, ponieważ to, co Scrum formalizuje jako zdarzenia opisane w metodzie, w Systemie Kanban trzeba zorganizować w adekwatnej (choć nieopisanej metodą) formie. Co więcej, System Kanban wymagał będzie większej dojrzałości od organizacji i zespołów developerskich, ponieważ nie wymusza kadencyjności działań, przez co empiryzm zależy mocniej od determinacji i konsekwencji zaangażowanych osób.

Mit: stała długość sprintu ogranicza produktywność

Wróćmy zatem do problemu niemożności zaczęcia prac nad wymaganiem tuż przed końcem sprintu. System Kanban pozornie jest odpowiedzią na to „ograniczenie” Scruma, bo pozwala planować w systemie ciągłym i realizować zadania dowolnie długo. Ta swoboda jest jednak pozorna i wynika najczęściej z niezrozumienia tego, jak System Kanban działa.  O ile w Scrumie planując sprint szacuje się, co jest możliwe do osiągnięcia przed jego końcem (i wiadomo dokładnie, ile czasu na to przeznaczamy), o tyle w Systemie Kanban zadania są „wciągane” do procesu przez cały czas, ale tylko do momentu wysycenia się możliwości zespołu do ich realizowania. Jeśli wprowadzone zostaną realistyczne limity wymagań, nad którymi zespół pracuje jednocześnie, efektywność okaże się taka sama, jak w Scrumie. Inaczej mówiąc, w tym samym czasie wcale nie uda się zrobić więcej.

A co począć, jeśli krótki sprint uniemożliwia zrealizowanie „naprawdę dużych wymagań”? System Kanban pozwala, przynajmniej teoretycznie, na realizację dowolnie rozbudowanych wymagań przez nieograniczony czas. Należy jednak pamiętać, że taki proces wytwarzania oprogramowania charakteryzował się będzie niskim empiryzmem lub w ogóle przestanie być empiryczny. Co więcej, skoro System Kanban opiera się na idei limitowania ilości pracy wykonywanej przez zespół równolegle, długotrwała realizacja jednego wymagania ograniczy produktywność zespołu (o ile przyjęte limity będą przestrzegane). Aby usprawnić przepływ wymagań przez proces developmentu zespół i tak zacznie dzielić je na mniejsze elementy dające się szybciej realizować.

Te same problemy, różne objawy

Co ciekawe, w Systemie Kanban problem „nie mogę zacząć kolejnego zadania” objawia się nieco inaczej. O ile w Scrumie czekamy cierpliwie na początek następnego sprintu, o tyle w Systemie Kanban czeka się na zwolnienie limitu (a więc na skończenie jakiegoś innego zadania). Czasem mniej to doskwiera, bo występuje w losowych momentach (a w Scrumie z reguły pod koniec sprintu), natomiast skala problemu w tym samym zespole będzie taka sama niezależnie od metody. Co więcej, Scrum uczyni ten problem dobrze widocznym, podczas gdy w Systemie Kanban można źle zdefiniować limity i długo nie mieć świadomości, że zespół dławi się nadmiarem równoległej pracy.

Warto w takim przypadku zadać sobie pytanie: z czego wynika ta niemożność zaczęcia czegokolwiek późno w czasie sprintu? Rychło okaże się, że wymagania są za duże (więc można je podzielić), że są źle wyestymowane (więc można je jeszcze raz przeszacować), że dałoby się je zrobić gdyby efektywniej działały procedury buildu i integracji (więc można je zoptymalizować) etc. W praktyce naprawdę dojrzały zespół dojdzie do momentu, gdzie „wyciągnięcie” granic sprintu i przejście ze Scruma na System Kanban może odbyć się niezauważalnie, bo jedyną zmianą będzie odejście od planowania per-sprint na rzecz planowania just-in-time.

A wy wolicie Scruma czy System Kanban? Jakiej metody używacie i co zdeterminowało jej wybór?


  • Aleksander Heliński

    Ciekawy artykuł, choć nie zgadzam się z tym, że w Kanbanie czeka
    się na zwolnienie limitu. Z tego co wiem, gdy naruszony zostaje limit, priorytetem
    powinno stać się jego jak najszybsze odblokowanie i ponowne udrożnienie pracy. Zamiast
    czekać, należy się tym właśnie zająć. Z drugiej strony nigdy też nie widziałem zespołu
    Scrumowego, który w ostatni dzień sprintu siedziałby popijając kawkę i czekając
    na następny planning, więc i tu trudno jest powiedzieć o marnowaniu czasu.

    • Rafał Markowicz

      Istotnie – przekroczenie ustalonych limitów w Systemie Kanban zdarza się stosunkowo często i nie musi świadczyć o złym jego wdrożeniu; jeśli fakt przekroczenia limitu jest bardzo krótkotrwały i powoduje skupienie zespołu na zredukowaniu ilości zadań, nad którymi pracuje, wtedy sytuacja jest jak najbardziej zgodna z duchem tej metody.

      Natomiast sytuacja, w której limity są łamane nagminnie i w sposób znaczący, wtedy zespół do momentu wyeliminowania przyczyn takiego stanu rzeczy de facto utknie w miejscu – albo będzie gwałcił podstawowe założenia metody w sposób permanentny, albo limity w istocie zablokują możliwość rozpoczynania kolejnych zadań do czasu udrożnienia kolejek. Do takiej właśnie sytuacji referowałem: zespół, który ma problemy z pracą w sprincie (metoda SCRUM) tak, by nie mieć przestojów, będzie miał problemy z limitami (metoda Kanban System). W obu przypadkach można ignorować ducha metody (w SCRUMie przeciągając zadania przez granice sprintów, w Systemie Kanban łamiąc limity) – ale lepiej poszukać źródła tych problemów. Jak się usunie przyczyny, to nagle okaże się, że jedynie sporadycznie coś nie zostanie w sprincie dokończone lub limity zostaną chwilowo przekroczone.

      I faktycznie, zgadzam się, że w miarę dojrzały zespół (czy to w SCRUM, czy w Systemie Kanban) zawsze znajdzie sobie zajęcie, które będzie wartościowe dla organizacji i/lub biznesu, a będzie wykonywane z duchem przyjętej metody i nie zaburzy sposobu pracy zespołu, ani nie ograniczy jego zwinności.

Zobacz również