Dlaczego określenie „odpowiedniej” wielkości zadania do realizacji, czyli angielski rightsizing, jest tak istotne?

Jedna z odpowiedzi padła w tekście dotyczącym ograniczania poziomu prac w toku (https://www.jsproject.pl/wiedza/blog/flow-management/982-constant-wip-conwip ) w odniesieniu do jednostki ograniczania limitu WIP. Po prostu: żeby mieć podstawę do tego ograniczania, trzeba mieć zadania podobnej wielkości.

Inna odpowiedz związana jest z jednym z podstawowych celów zarządzania pracami i projektami, czyli z przewidywalnością i odpowiedzią na pytania klienta: na kiedy zrobimy dane zadanie oraz: na kiedy zrobimy projekt, czyli zbiór zadań? W dodatku z taką naszą odpowiedzią, która spełnia oczekiwania i wymagania klienta.

Problemy tradycyjnego szacowania

Tradycyjne podejście, mające doprowadzić do odpowiedzi na te pytania, związane jest z dokonaniem oszacowania pracochłonności i/lub czasu trwania zadania, a na tej podstawie także szacowania czasu trwania projektu, czyli udzielenia odpowiedzi: na kiedy zrobimy projekt.

Problem polega na tym, że – po pierwsze - szacowanie jest bardzo pracochłonne, bo jeśli trzeba w dużym projekcie oszacować setki zadań, to ta czynność nie zajmie przysłowiowych 5-ciu minut. Po drugie: szacowanie jest zwykle bardzo subiektywne, a dodatkowo różne zespoły i różni specjaliści mają odmienne podejścia do oszacowania tego samego zadania i/lub elementu pracy. Co oznacza, że tradycyjne szacowanie nie działa „w skali”, tj. przy szacowaniu projektu, składającego się z wielu zadań. Co prowadzi do wniosku, że takie oszacowania projektu nie są wiarygodne, a na dodatek – to był pierwszy problem – są bardzo pracochłonne.

Dlatego też zarówno Kanban, jak i Flow Management odchodzą od szacowania na rzecz innych metod, na przykład prognozowania probabilistycznego lub stosowania do prognozowania Prawa Little’a. Czyli na rzecz budowania przewidywalnego systemu dostarczania, nie stosującego przy tym tradycyjnych oszacowań.

I w tym miejscu pojawia się druga odpowiedź na pytanie dlaczego określenie „odpowiedniej” wielkości zadania do realizacji, czyli angielski rightsizing, jest takie istotne. Algorytmy wykorzystywane w prognozowaniu probabilistycznym działają dobrze, gdy wielkość zadań, które podlegają prognozowaniu jest „odpowiednia”. „Odpowiednia”, czyli mieszcząca się w „rozsądnych” granicach”. Wielkość prognozowanych zadań po prostu nie może różnić się bardzo, choć oczywiście może się różnić. W praktyce więc na poziomie zadań (czyli kart, gdy stosujemy platformę Businessmap (dawniej Kanbanize) powinniśmy dążyć do minimalizacji odchyleń wielkości tych zadań. Nigdy oczywiście nie doprowadzimy do sytuacji, że zadania będą miały taką samą wielkość. Raczej więc chodzi o doprowadzenie – drogą dekompozycji większych prac na zadania, by właśnie na poziomie zadań minimalizować te odchylenia.

Rightsizing - odpowiednia wielkość zadania

Jaka więc może być taka wielkość zadania? Firma Businessmap sugeruje, ale też sama stosuje podejście, że zadanie nie powinno być większe nić circa 5 dni pracy. Oczywiście mogą zdarzyć się zadania większe, jednak nie powinno to zdarzać się zbyt często. Im mniejszy spodziewany czas pracy nad zadaniem, tym lepiej, jednak nie powinno to być mniej niż ½ dnia. Nie ma bowiem praktycznego sensu w definiowaniu zadań zajmujących godzinę, dwie, czy nawet ½ godziny. Inni specjaliści sugerują wielkość zadania w przedziale 1-3 dni.

Vasco Duarte w podejściu #NoEstimates proponuje, by to najmniejsze zadanie (czyli w świecie tworzenia oprogramowania tzw. historyjka) wymagało między 0.5 a 1 osobo-dnia pracy. A jako generalną zasadę proponuje on, by zadanie (historyjka) nie była większa niż circa połowa długości iteracji.

W praktyce podejścia Kanban w zdefiniowanym procesie wytwórczym wyodrębniana jest czasem faza, czyli kanban’owa kolumna, dekompozycja, w której członkowie zespołu dokonują – jak sugeruje sama nazwa, dekompozycji większej pracy na te małe zadania.

Istotną pomocą podczas dekompozycji większych prac na mniejsze jest posługiwanie się przyjętą w organizacji hierarchią prac i „widełkami” wielkości prac na poszczególnych poziomach. Hierarchia taka może obejmować na przykład takie elementy - i związane z nimi orientacyjne, ułatwiające dokonywanie dekompozycji – czasy trwania, jak:

• Projekt: czas trwania kilka miesięcy
• Funkcjonalność (ang. Feature): czas trwania kilka tygodni
• Epik: czas trwania 1-3 tygodnie
• Zadanie: czas trwania poniżej 5 dni.

Prognozowanie większych prac, czyli projektu, funkcjonalności lub epika powinno być oparte o zadania. A zadania powinny być „odpowiedniej”, czyli mniej więcej tej samej wielkości (rightsized).

Vasco Duarte w książce „#NoEstimates” opisuje nieco prostszą hierarchię obejmującą:

• Projekt
• Funkcjonalność (ang. Feature): maksymalnie 2 miesiące
• Zadanie (ang. Story): maksymalnie 1 dzień.

Efektywne i wiarygodne prognozowanie – bez względu na stosowaną metodę – wymaga „odpowiedniej”, czyli mniej więcej tej samej wielkości zadań. Ponadto wymaga ono oczywiście stabilnego systemu pracy, czyli systemu bez większych odchyleń.  A metodą uzyskania takiego stabilnego systemu jest wprowadzenie i przestrzeganie ograniczenia prac w toku (limitów WIP), jak i eliminacja lub przynajmniej znaczne ograniczenie wszelkiego rodzaju blokerów pracy.

Przy spełnieniu powyższych dwóch warunków (mała wielkość zadań oraz ograniczone prace w toku – WIP) te małe zdania w powiązaniu z przyjętą hierarchią prac dostarczają praktyczną metodę śledzenia postępu prac (zarówno na poziomie tych zadań, jak i na wyższych poziomach hierarchii prac). Dostarczają też praktycznych informacji dla zarządzania pracami projektowymi i dla podejmowania decyzji, w szczególności umożliwiających zarządzanie zakresem zwłaszcza w sytuacji trudnych projektów, których termin realizacji jest wymagający, lub – w trakcie realizacji  - może być zagrożony.

Korzyści odpowiedniej wielkości zadania

Ta mała wielkość zadania daje jeszcze jedną olbrzymią korzyść. Jest nią możliwość skupienia uwagi przez decydentów biznesowych (np. przez Właściciela Produktu) na wartości, a nie – jak to bywa w tradycyjnym zarządzaniu pracami i projektami -  na „taniości”, czyli minimalizacji – w gruncie rzeczy pozornej – kosztu prac.

Jeśli więc zespół dokona dekompozycji prac na zadania w opisany powyżej sposób i – oczywiście – będzie się stosował do wprowadzonych limitów prac w toku, to wtedy menedżerowie nie będą wymagali od zespołu szczegółowych oszacowań, gdyż będą mogli udzielać odpowiedzi na pytanie klienta: na kiedy zrobicie projekt lub inną dużą pracę, z pomocą prognozowania na podstawie danych historycznych lub innych metod, nie wymagających szacowania zadań.

Mamy więc kolejną, tym razem podwójną korzyść: zespół nie poświęca czasu na dokonywanie żmudnego i mało wiarygodnego oszacowania, lecz może skupić się na produktywnej pracy. A klienci – dzięki przewidywalności dostarczania, związanej ze stosowaniem wiarygodnej metody udzielania odpowiedzi na pytanie: na kiedy zrobicie projekt lub pojedyncze prace – są zadowoleni, szczęśliwi i – co może najważniejsze w kontekście relacji biznesowych – mają zaufanie do naszych prognoz dostarczenia produktu i/lub usługi, czyli do nas – dostawców.

I tak doszliśmy do – najważniejszej moim zdaniem – odpowiedzi na pytanie: dlaczego określenie „odpowiedniej” wielkości zadania do realizacji jest tak istotne.