Ludzie od tysięcy lat tworzą mosty i inne budzące podziw budowle. Inżynieria budowlana wyewoluowała niemal do perfekcji. Mimo to ciągle zdarzają się wypadki, terminy i budżety są przekraczane. Jak więc skuteczne planowanie i zarządzanie czasem wygląda w przedsiębiorstwach IT, gdzie rzeczywistość zmienia się najszybciej? Co to jest Scrum i jak możesz wykorzystać go w swoim życiu?

Scrum to zbiór prostych (lecz nie łatwych) reguł, których celem jest efektywna realizacja planów. Bardzo często wykorzystywany jest w firmach IT, w których sytuacja zmienia się bardzo dynamicznie i trudno jest podejmować długoterminowe decyzje.

Postanowiłem poruszyć ten temat, ponieważ sam od dwóch lat pracuję w Scrumie i jestem pod wrażeniem tego, jak prosty framework pozwala pracować szybciej i krócej, a przede wszystkim efektywnej. Skuteczne planowanie i zarządzanie czasem w Scrumie to sama przyjemność.

Metodologia wodospadu

Kiedyś popularnym podejściem do wytwarzania oprogramowania była metodologia Waterfall. Składa się z kilku dużych etapów. Kolejny etap nie może rozpocząć się, zanim nie zakończy się poprzedni. Oto etapy Waterfalla:

  • Requirements – zebranie wymagań produktu. Innymi słowy, jest to dobre zdefiniowanie celu.
  • Design – stworzenie projektów.
  • Implementation – to proces realizacji planów.
  • Verification – zweryfikowanie, czy to, co zrobiliśmy, jest tym, czego oczekiwaliśmy.
  • Maintenance – proces utrzymania wyniku naszej pracy.

Problem powyższego podejścia polega na tym, że nie pozwala ono dostosować założeń do często zmieniającej się rzeczywistości. Wyobraź sobie firmę, która podjęła się projektu mającego trwać przez dwa lata. Głównym źródłem przychodu miało być wyświetlanie reklam w darmowym oprogramowaniu. Przez pierwsze pół roku zbierano wymagania, tworzono dokumentację, projekty i makiety. Przez kolejny rok realizowano założony plan.

Na samym końcu, w procesie weryfikacji, okazało się, że firma już po kilku miesiącach od rozpoczęcia projektu, całkowicie zmieniła swoją strategię. Postanowiła zmienić podejście do osiągania przychodów poprzez sprzedaż oprogramowania bez reklam. Osiągnęliśmy więc to, co planowaliśmy, jednak nie to, co jest nam potrzebne.

Twardo trzymaliśmy się zasady, że nie rozpoczynamy kolejnego etapu bez zakończenia poprzedniego. Etap Verification nastąpił więc dopiero po półtora roku, gdy projekt jest niemal skończony, a firma poniosła wysoki koszt wdrożenia reklam, które nie są już potrzebne.

Skuteczne planowanie i zarządzanie czasem

Często w naszym prywatnym życiu sytuacja zmienia się bardzo dynamicznie. Planujemy, że załatwimy coś w poniedziałek, ale okazuje się, że musimy to odłożyć na kolejny tydzień. Dobra organizacja pracy własnej powinna charakteryzować się łatwością dostosowania do rzeczywistości. Jak więc wygląda planowanie i zarządzanie czasem, z uwzględnieniem dużej elastyczności?

Odpowiedzią jest właśnie Scrum. Głównym założeniem tej metodologii jest dostosowywanie planu do rzeczywistości, z którą mamy do czynienia. Ludzie mają niestety tendencję do tego, aby naciągać swoją rzeczywistość do planu, którego kurczowo chcą się trzymać. Takie podejście oczywiście nie może dawać dobrych efektów.

Scrum to sposób na efektywne zarządzanie projektami jak np. praca zaliczeniowa, organizacja wakacji, remont mieszkania, stworzenie oprogramowania, napisanie książki, prowadzenie bloga. Nie ma znaczenia czy jest to działka IT, czy nie, czy to duży projekt w firmie, czy też coś bardziej osobistego. Jeśli masz cel, to Scrum pomoże Ci go osiągnąć.

Scrum opiszę z punktu widzenia grupy, gdzie ważna jest umiejętność pracy w zespole. Myślę, że z łatwością odniesiesz poszczególne etapy do sytuacji, gdzie zespół składa się z jednej osoby – Ciebie.


Scrum process

Krok 1. Tworzymy historyjki

Wszystko zaczyna się od określenia celu. Przykład? Zrobienie danego projektu na zaliczenie, remont pokoju lub zrobienie strony internetowej dla klienta. Aby osiągnąć cel, potrzebujemy mieć listę wymagań, którą zbieramy w postaci tzw. historyjek. Mają one postać Jako X, chcę mieć Y, aby Z. Kilka przykładów poniżej.

  • Remont pokoju dziecka
    • Jako dziecko, chcę mieć biurko, aby móc przy nim odrabiać lekcje.
    • Jako dziecko, chcę mieć ulubiony kolor ścian, aby czuć się lepiej w pokoju.
    • Jako rodzic, chcę wstawić porządne drzwi, aby nie słyszeć hałasów dziecka.
  • Strona internetowa
    • Jako użytkownik, chcę mieć pasek menu, aby łatwo poruszać się po stronie.
    • Jako użytkownik, chcę mieć formularz kontaktowy, aby skontaktować się z firmą.
    • Jako właściciel strony, chcę mierzyć ilość unikalnych wejść na stronę, aby wiedzieć, jak jest popularna.

Cel jest jeden – strona WWW albo remont pokoju. Naszym zadaniem jest rozbić go na mniejsze i konkretniejsze zadania, które będziemy wykonywać. Celem formułki Jako X, chcę Y, aby Z. jest jasne określenie – co robimy, dla kogo i dlaczego.

Tworzymy tyle historyjek ile potrzeba, aby opisać cały nasz projekt. Ich zbiór (dokument tekstowy na komputerze, w notatniku czy na osobnych karteczkach) nazywamy Backlogiem produktu.

Krok 2. Wyznaczamy priorytety

Wszystkie historyjki muszą być uporządkowane od najważniejszej do najmniej ważnej. Nie ma stwierdzeń, że Wszystko jest tak samo ważne.. Zmuś siebie lub klienta do określenia priorytetów. Powód jest prosty – zawsze pracujemy nad jednym zadaniem, które w danej chwili jest najważniejsze. Gdy je zakończymy, to drugie w kolejności stanie się najważniejsze, a więc to nad nim będziemy pracować.

Priorytety ustala właściciel produktu, którego nazywamy Product Ownerem. Jest to osoba odpowiedzialna biznesowo za projekt, a więc nie interesuje się techniczną realizacją, a jedynie osiąganymi efektami i kierunkiem, w którym zmierza projekt. W jednoosobowym Scrumie wszystkie role będziesz spełniał tylko Ty.

Krok 3. Planujemy Sprint

W Scrumie praca podzielona jest na iteracje i Sprinty. Jedna iteracja powinna dostarczyć większą i konkretną wartość, np. stworzenie strony głównej lub zmontowanie mebli do pokoju. Iteracje składają się ze Sprintów, czyli ram czasowych, w których pracujemy. Sprint powinien trwać od jednego tygodnia do miesiąca.

Przed rozpoczęciem Sprintu cały zespół spotyka się na tzw. Sprint Planningu. Celem spotkania jest:

  • ponowne ustalenie priorytetów w Backlogu lub upewnienie się, że priorytety nie zmieniły się,
  • wycena zadań – jeśli potrzeba,
  • ustalenie zakresu prac na najbliższy Sprint.

Wyceniamy zadania

Jeśli priorytety są jasne, zaczynamy przeglądać historyjki, zaczynając od najważniejszej. Dla każdej z nich chcemy określić pracochłonność. Co to jest? To ilość pracy, którą trzeba wykonać i nie przekłada się jej bezpośrednio na czas. Wycena poszczególnych historyjek polega na przypisaniu im odpowiedniej ilości punktów, zwanych Story Points. Są to po prostu liczby. Największą pomyłką jest utożsamianie ich z czasem. Liczby, które ja stosuję w pracy, to: 1, 3, 5, 8, 13, 20, 40, …, ∞. W praktyce, jeśli zadanie ma więcej niż 13 punktów, należy rozbić je na kilka mniejszych zadań.

Aby zacząć wycenę, musisz ustalić swoje zadanie referencyjne i przypisać mu przykładową liczbę, np. 8. Przy stronie WWW takim zadaniem może być ilość pracy, jaką należy wykonać, aby stworzyć formularz (w całości – z walidacją danych, projektem graficznym itd.). W przypadku remontu zadaniem referencyjnym może być skręcenie biurka. Jeśli mamy to ustalone, możemy dla każdej historyjki zadać sobie pytanie, Czy realizacja tego zajmie mi więcej, czy mniej pracy, niż zadanie referencyjne?. Jeśli mniej lub więcej, to o ile? W ten sposób, do historyjek przypisujemy odpowiednie liczby. Przykłady poniżej.

  • Jako użytkownik, chcę mieć pasek menu, aby odnaleźć się na stronie. – przypisuję 5 punktów, ponieważ wydaje mi się, że to zadanie jest łatwiejsze niż moje zadanie referencyjne (dla przypomnienia był to formularz, któremu przypisałem 8 punktów).
  • Jako użytkownik chcę mieć formularz do kontaktu, aby skontaktować się z firmą. – przypisuję 8 punktów, ponieważ to zadanie pokrywa się pracochłonnością z moim zadaniem referencyjnym.
  • Jako właściciel strony, chcę mieć statystyki unikalnych wejść, aby znać popularność strony. – przypisuję 3 punkty.
  • Jako użytkownik chcę widzieć stronę główną, aby zapoznać się z główną ofertą firmy. – 40 punktów, zbyt wysoka wycena! Tę historyjkę muszę rozbić na kilka mniejszych, np. (Jako użytkownik, chcę widzieć pasek menu, aby…, Jako użytkownik, chcę zobaczyć główną treść oferty, aby…, Jako użytkownik, chcę zobaczyć przykładowe realizacje, aby…).

Powtórzę, że Story Points nie powinny być odzwierciedleniem tego, ile przewidujesz dni na pracę, ale raczej czy coś jest trudniejsze, czy łatwiejsze od Twojego zadania referencyjnego. To pozwoli całkiem nieźle oszacować względną prędkość, z jaką pracujesz, co przełoży się na skuteczne planowanie i zarządzanie czasem.

Planning Poker – wycena wielu osób

Nie wspomniałem, że każde zadanie jest wyceniane przez cały zespół, czyli osoby, które będą je realizować. W Scrumie nie przypisujemy zadań do ludzi, ale do zespołu. Nie ma więc znaczenia, czy osoba X je zrobi, czy tylko zacznie, a dokończy osoba Y. Interesuje nas jedynie wykonanie zadania, ale nie sposób jego realizacji.

Aby mieć taką elastyczność, zespół musi być zgodny co do wyceny. Przeważnie więc wygląda to tak, że omawiając wycenę, każdy ma karteczki ze Story Pointami i sam wybiera jedną, która według niego najbardziej pasuje do zadania. Gdy wszyscy są gotowi, w jednym momencie pokazują swoją wycenę. Osoby o skrajnych punktacjach dyskutują o tym, dlaczego wybrały taką liczbę, a nie inną.

Dzięki temu uwzględniamy fakt, iż w zespole mogą być osoby mniej doświadczone, albo świeże. Wymieniamy również informacje – ktoś mógł przy swojej wycenie zapomnieć o czymś, co będzie pracochłonne i dać zbyt małą wycenę. Ktoś inny mógł z kolei sądzić, że trzeba zrobić więcej, niż faktycznie potrzeba i przeszacować wycenę.

Po wymianie zdań należy dokonać ponownie wyceny, w ten sam sposób. Wszyscy więc ponownie pokazują nową wycenę w jednym momencie (aby nie sugerować się punktacją innych). Powtarzamy dyskusję, aż dojdziemy do wspólnej wyceny. Jeśli mamy na pokładzie kogoś mniej doświadczonego, kto zawyża wycenę, to dostosowujemy się do jego wyceny, bo przecież nie wiadomo, czy on nie będzie wykonywał danego zadania.

Krok 4. Rozpoczynamy Sprint

Gdy mamy już wycenione zadania, a historyjki ułożone są wg priorytetów, zastanawiamy się, ile jesteśmy w stanie dowieźć w ciągu Sprintu. Ustalamy przykładowo, że Sprinty trwają 5 dni roboczych. Bierzemy kilka zadań z góry Backloga i zobowiązujemy się, że je zrealizujemy w ciągu tego Sprintu. Podczas pierwszego Planningu bierzemy na oko tyle, ile sądzimy, że zrealizujemy. Podczas kolejnych Planningów sumujemy punkty ze wszystkich zadań, które udało nam się zrobić w 100% podczas poprzedniego Sprintu. W kolejnym Sprincie zobowiązujemy się zrealizować tyle zadań (o najwyższym priorytecie), aby suma ich punktów, nie przekroczyła sumy punktów zadań dowiezionych w poprzednim sprincie.

Wyznaczamy cel Sprintu

Być może zwróciłeś uwagę, że w metodologii Scrum, zespół sam siebie kalibruje. Nie zakładamy, jak szybko pracujemy, ale na bieżąco to mierzymy i dopasowujemy nasz plan.

Lista zadań, które zobowiązujemy się zrealizować w Sprincie, nazywa się Sprint Backlogiem. Nad zadaniami powinniśmy pracować w kolejności od najważniejszego do najmniej ważnego. Zanim zakończymy nasz Sprint Planning, ustalamy cel Sprintu – czyli krótkie podsumowanie, które chcemy osiągnąć w ciągu najbliższego tygodnia (Sprintu). Oczywiście ten cel powinien być bezpośrednio powiązany z zadaniami, do których się zobowiązaliśmy. Po każdym sprincie chcemy mieć jakąś konkretną rzecz, którą będziemy mogli się pochwalić klientowi, np. strona główna (której realizacja składa się z mniejszych historyjek), albo odmalowane ściany w pokoju.

Jeśli nasz projekt składa się z kilku większych pod-projektów (iteracji) to kolejne Sprinty powinny być tak zorganizowane, aby po upływie kilku z nich jeden z pod-projektów był zrealizowany. Przykładowo, jeśli okaże się, że strona główna jest na tyle złożona, że będziemy robić ją kilka tygodni, to naturalne jest, że kolejne Sprinty będą dowozić kolejne kawałki strony głównej, aby na końcu ją zrealizować w pełni. Pamiętając oczywiście o tym, że po każdym sprincie chcemy pochwalić się jakimś konkretem klientowi.

Nie tworzymy więc historyjek, które nie są konkretne, np. Jako deweloper, chcę rozpocząć pracę nad stroną główną, aby… – rozpoczęcie prac nic nie mówi. O wiele lepiej jest zdefiniowanie tego, co uzyskamy w ramach rozpoczęcia, np. Jako deweloper, chcę stworzyć podstawowy szablon strony głównej, aby…. Taki szablon można już komuś pokazać. Rozpoczęcia strony głównej nie ma jak pokazać.

Jedną z żelaznych zasad planowania jest to, że nie wrzucamy do naszego Sprint Backloga zadania, którego nie da się na dzień Planningu zrobić. Może np. brakować ustaleń, grafik, materiałów. Wtedy nie powinniśmy się zobowiązywać do zrobienia takiego zadania. Product Owner (klient) musi dbać o to, aby zadania były w pełni przygotowane do realizacji. Jeśli jednak klient zobowiąże się do dostarczenia brakujących rzeczy w trakcie trwania Sprintu, to wtedy robimy na to zadanie miejsce. Zobowiązujemy się do zrobienia odpowiednio mniejszej ilości zadań w najbliższym Sprincie. Uwzględniamy jednak, że wrzucimy przygotowane przez klienta zadanie, w trakcie Sprintu.

Krok 5. Dowozimy Sprint

Gdy wiemy już, jaki mamy cel, jakie zadania będziemy robić w Sprincie oraz w jakiej kolejności, możemy rozpocząć pracę. Częścią każdego Sprintu, są dwa rodzaje spotkań: Daily Scrum, Backlog Refinment.

Daily Scrum

Daily Scrum, jak same nazwa wskazuje, to codzienne spotkania, na których zespół się synchronizuje. Wtedy wszyscy spotykają się o ustalonej godzinie, w ustalonym miejscu i każdy odpowiada na trzy pytania:

  • Co zrobiłem?
  • Co będę robił?
  • Czy mam jakieś problemy/blokery?

W przypadku zespołu to konieczne, aby dowiedzieć się co dzieje się u innych i ewentualnie pomóc im. W przypadku jednoosobowego Scrumu takie spotkania raczej są zbędne, chyba że Twój klient każdego dnia chce znać postęp prac.

Backlog Refinment – rewidujemy priorytety

Backlog Refinment, to znacznie rzadsze spotkania. Ich częstotliwość można ustalić samemu, chociaż warto zacząć od jednego tygodniowo. W spotkaniu uczestniczy Product Owner (klient) oraz zespół. Jego celem jest zrewidowanie priorytetów i wycena Backloga. Rozpoczynamy od zadań w aktualnym Sprincie. Sprawdzamy, czy ich priorytet jest nadal taki sam. Jeśli nie, to zmieniamy priorytety, wtedy zespół stara się dopasować do nowej rzeczywistości i robić to, co najważniejsze. Jeśli oznacza, to przerwanie rozpoczętych prac, trzeba dogadać się z Product Ownerem co robić.

Zawsze dopasowujemy plan do rzeczywistości. Nigdy odwrotnie. Czasem naszemu klientowi będzie zależeć na szybkiej realizacji menu strony głównej, po czym kilka dni później stwierdzi, że musi widzieć przede wszystkim stopkę. To jest ok i powinniśmy się starać do tego dopasować. Problem pojawia się wtedy, gdy klient próbuje całkowicie zmienić zadania w Sprincie. Powinniśmy tego unikać, ponieważ to rozwala całkowicie pracę. Zwłaszcza gdy dzieje się to w każdym Sprincie. Ciężko dowozić konkretne cele, gdy ciągle się one zmieniają. Dlatego zakres Sprintu powinien być raczej święty.

Cele, które zmieniają się kilka razy w tygodniu oznaczają jedno – totalny brak organizacji i planowania po stronie Product Ownera. Trzeba planować tak, aby móc przynajmniej przez tydzień pracować w spokoju.

Backlog Refinment – rewidujemy wycenę

Kolejnym zadaniem Refinmentu jest zweryfikowanie wycen. Przecież może się w trakcie okazać, że coś jest znacznie trudniejsze niż sądziliśmy na początku. Wtedy podnosimy wycenę tego zadania. Jeśli coś okaże się prostsze – zmniejszamy ilość punktów. Wycenę weryfikujemy najpierw w zadaniach aktualnego Sprintu, a następnie w Backlogu produktu, zaczynając od najważniejszego.

Pytanie, które często się pojawia na Refinmentach brzmi: Czy zmniejszamy ilość punktów, gdy zrobimy już część danego zadania?. Odpowiedź brzmi: nie. Wycena dotyczy całości zadania, a nie tego ile zostało do końca.

Staramy się zawsze znać wyceny i priorytety na dwa najbliższe Sprinty. Jeśli więc mamy dużo zadań, to nie musimy ich wszystkich wyceniać. Wystarczy tylko tyle, ile jesteśmy w stanie dowieźć przez dwa kolejne Sprinty.

Backlog Refinment – rewidujemy zakres

Może się okazać, że skończymy nasze prace znacznie szybciej, niż sądziliśmy. Wtedy na Refinmencie bierzemy zadanie o najwyższym priorytecie z Backloga produktu i wrzucamy do Sprintu, jednocześnie zobowiązując się, że również je zrobimy. Sytuacja odwrotna jest również prawdopodobna. Wiemy wtedy, że czegoś na pewno nie zdążymy zrobić, bo inne prace okazały się bardziej pracochłonne. W takiej sytuacji wyrzucamy zadanie, którego nie damy rady zrobić ze Sprint Backloga do Product Backloga, jednocześnie potwierdzając, że go nie zrobimy w ciągu tego Sprintu.

Krok 6. Kończymy Sprint i wyciągamy wnioski

Minęło więc 5 dni roboczych i czas zakończyć Sprint. Różne metody i techniki zarządzania, uwzględniają odpowiednie wyciąganie wniosków z pracy, którą wykonujemy. Nie inaczej jest w Scrumie. Koniec Sprintu wiąże się z dwoma spotkaniami, które najczęściej następują od razu po sobie: Sprint Review, Sprint Retrospection. Oczywiście uczestniczy w nich cały zespół.

Review – rewidujemy zakończony Sprint

To czas na zaprezentowanie wyników naszej pracy. Pokazujemy klientowi, co udało nam się zrobić, jak to wygląda i działa. Przykładowo prezentujemy stronę główną lub odmalowany pokój dziecku. Mówimy, co zrobiliśmy, a czego się nie udało zrobić. To czas na otrzymanie pochwał lub uwag od klienta. Bardzo często jest tak, że klient, mówiąc nam, że chce koło na stronie głównej, myśli o kwadracie. Bywa także, iż coś w rzeczywistości wygląda inaczej, niż klient to sobie wyobrażał.

Potęga Scrumu tkwi w tym, że często otrzymujemy informację zwrotną. Klient jest więc ciągle informowany, jak coś działa lub wygląda. Jest w stanie korygować swoje plany. Nierzadko zmienia wtedy historyjki, dodaje nowe lub rezygnuje z nieaktualnych. Nasz plan ciągle ewoluuje. Jesteśmy wiec zwinni – patrzymy na rzeczywistość i dostosowujemy się do niej. Kluczowa jest tu transparentność. Nie wolno niczego zatajać ani ukrywać. Klient powinien dokładnie wiedzieć, co naprawdę się dzieje.

Retrospekcja – ulepszamy proces

Scrum słynie z tego, że zespoły są samo-organizujące i samo-ulepszające. Ważnym etapem jest wyciągnięcie wniosków na temat pracy samej w sobie. Retrospekcja dotyczy zarówno wieloosobowego zespołu, jak i pracy w pojedynkę. Każda osoba mówi jedną pozytywną rzecz i jedną negatywną. Rzeczy pozytywne mówimy, aby reszta grupy wiedziała, co podoba się danemu człowiekowi. W ten sposób wzmacniamy pozytywne zachowania w zespole.

Rzeczy negatywne mówimy, aby identyfikować problemy, które wystąpiły podczas pracy (np. coś okazało się znacznie trudniejsze lub zbyt często ktoś nam przeszkadzał). Następnie cały zespół głosuje nad jedną najbardziej bolącą rzeczą. Następnie staramy się wymyślić rozwiązanie tego problemu na najbliższy Sprint. Nie zawsze jest to możliwe, dlatego często rozwiązaniem będzie opracowanie planu rozwiązania. Musimy również wyznaczyć osobę, która będzie odpowiedzialna za realizację ustaleń. Nazywamy ją ambasadorem problemu.

Bardzo często spotkanie następujące po Retrospekcji, to Sprint Planning, który już opisałem. Jak więc widzisz, proces zatacza koło. Mała uwaga – jeśli zrobiłeś tylko część zadania i chcesz je wrzucić do kolejnego Sprintu, to wyceniasz go, myśląc o tym, ile pracy faktycznie zostało do końca. Czyli jeśli coś miało 8 punktów, zrobiłeś trochę, to do kolejnego Sprintu wrzucasz to samo zadanie, np. z wyceną 5 punktów. 3 punkty nam uciekło. Zadania, którego nie zakończyliśmy, nie możemy zsumować pod koniec Sprintu. Dlatego tak ważne, jest dbanie o dobrą granulację i planowanie Sprintu. Więcej na ten temat w dalszej części posta.

Długoterminowe planowanie czasu pracy, a zarządzanie sobą w czasie

Na tym etapie powinieneś wiedzieć jak rozbić projekt na historyjki oraz jak realizować go przy pomocy kolejnych Sprintów. Nie omówiłem jednak bardzo ważnej kwestii – planowanie długoterminowe. Scrum jest metodologią zwinną, w której często zastanawiamy się, czy nasze plany nadal są aktualne i poprawne. Dlatego też mamy tyle spotkań.

Every minute you spend in planning saves 10 minutes in execution.

Brian Tracy

Czas więc nauczyć się szacowania czasu realizacji całego projektu. Potrzeba do tego dwóch czynników:

  • zgrubnej wyceny wszystkich historyjek,
  • informacji o kilku zakończonych Sprintach.

Aby uzyskać pierwszy czynnik, musimy spotkać się całym zespołem i bez wdawania się w szczegóły wycenić wszystkie zadania. Nie chcemy dyskutować o tym tak dokładnie, jak podczas Backlog Refinmentu. Naszym celem jest zgrubna wycena każdego zadania w Story Pointsach. Po tym etapie otrzymamy wycenione poszczególne kawałki naszego projektu. Jak więc przełożyć Story Pointsy na czas realizacji?

Story Points vs Man Days – efektywne planowanie czasu pracy

Story Points dla początkujących wydają się mało sensowne. Czy nie moglibyśmy szacować czasu na wykonanie zadania w dniach lub godzinach (Man Days)? Moglibyśmy, ale pokażę Ci, że abstrakcyjne pojęcie Story Poinstów lepiej wpływa na skuteczne planowanie i zarządzanie czasem.

Ludzie mają spory problem z szacowaniem czasu, który potrzeba na wykonanie danej pracy. Bardzo często coś, co miało trwać 2 dni, trwa 5 i vice versa. Wycena w dniach lub godzinach zawsze będzie obarczona błędem ludzkim. Dlatego też powstały Story Pointsy, które nie przekładają się bezpośrednio na dni pracy. To względna jednostka, która sama dopasowuje się do tempa Twojej pracy. Dlatego nie da się porównać prędkości pracy dwóch zespołów. 8 punktów dla jednego zespołu, może oznaczać 13 dla innego.

Wyobraź więc sobie, że dokonujesz wyceny w dniach. Ilość Twoich dni jest ustalona przez długość Sprintu, np. 5. Jeśli więc wycenisz coś błędnie, to nie masz możliwości uwzględnienia tego w Twojej przyszłej wycenie. Możesz jedynie liczyć, że wyceny kolejnych zadań będą dokładniejsze, ale jak wiesz – czasem będą, a czasem nie będą. Jeśli cały projekt został wyceniony na 100 dni, to spodziewasz się, że zakończysz go za 100 dni. Termin może się zmienić tylko wtedy, gdy zmieni się wycena jakichś zadań.

Co w sytuacji, gdy przez pierwsze Sprinty robiłeś sobie przerwy po 10 minut, a później się rozleniwiłeś i zacząłeś poświęcać 25 minut na kawę kilka razy dziennie? Wycena zadań się nie zmieniła, ale Twoja produktywność się zmieniła, co niesie ogromne ryzyko, że nie dowieziesz projektu w 100 dni. Najgorsze będzie to, że nikt nie będzie o tym wiedział, aż do samego końca! Dlatego, że wszystkie zadania, które wyceniłeś kiedyś na 1 dzień, w Twojej głowie nadal będą tyle Trwać, a przez Twoje przerwy na kawę okaże się, że trwają 2 dni. Sprint po Sprincie będziesz miał coraz większą obsuwę terminu.

Przewaga Story Pointsów

Teraz mamy projekt, który wyceniliśmy na 100 punktów. Kiedy go dowieziemy? Nie wiadomo, ponieważ nie umiemy przełożyć punktów na ilość dni. Możemy wstępnie założyć, że w każdym sprincie średnio zrobimy 10 punktów. Nasz wstępny plan mówi, że projekt zrealizujemy po 10 Sprintach. Po pierwszym Sprincie zrobiłeś zadania, których suma punktów wynosiła 13. Po drugim zakończyłeś 10, a po trzecim 15 (przypominam, że do sumy nie wliczamy zadań, których nie zakończyliśmy w 100%, nawet jeśli zabrakło troszeczkę). Po trzech Sprintach mamy więc:

  • prędkość minimalna: 10,
  • prędkość maksymalna: 15,
  • prędkość średnia: 12.

Teraz możemy oszacować trzy potencjalne terminy zakończenia naszego projektu:

  • najwcześniejszy – 100/15 to 7 tygodni, po zaokrągleniu w górę,
  • najpóźniejszy – 100/10 to 10 tygodni,
  • prawdopodobny – 10/12 to 9 tygodni po zaokrągleniu w górę.

Teraz najlepsza część. Zepsuł się ekspres i poświęcasz codziennie 25 minut na kawę, którą wcześniej robiłeś w 5 minut. Dodatkowo rozleniwiłeś się i Twoja produktywność spadła. W czwartym Sprincie zrobiłeś więc 8 punktów, a w piątym 5. Teraz mamy nowy termin zakończenia projektu (staramy się analizować 5 ostatnich Sprintów):

  • prędkość minimalna: 5,
  • prędkość maksymalna: 15,
  • prędkość średnia: 10.2 czyli 10.
  • Termin najwcześniejszy – 100/15 to 7 tygodni, po zaokrągleniu w górę,
  • najpóźniejszy – 100/5 to 20 tygodni,
  • prawdopodobny – 100/10 to 10 tygodni.

Po każdym Sprincie jesteśmy więc w stanie zmierzyć swoją produktywność oraz rzutować ją na nasz długoterminowy plan. Tym samym na bieżąco widzimy, jak zmienia się nasza sytuacja, dzięki czemu jesteśmy w stanie lepiej planować. Nie ma czegoś takiego jak jeden prawdziwy termin. Bardzo wiele czynników wchodzi w skład czasu realizacji projektu:

  • jak szybko ktoś pracuje,
  • jak dobrze zna projekt,
  • ktoś się rozchorował,
  • ktoś wziął urlop,
  • lepsza wycena zadań,
  • ktoś się rozleniwił.

Story Points uwzględniają wszystkie te wydarzenia. Zarówno na etapie wyceny jak i planowania terminów.

Reasumując

Ten post wyszedł dosyć długi, ale chciałem porządnie opisać metodologię Scrum, która pozwala na skuteczne planowanie i zarządzanie czasem. Metodologia jest bardzo popularna w przedsiębiorstwach IT, gdzie sytuacja zmienia się najbardziej dynamicznie. Co więcej, jednoosobowy Scrum również jest popularnym tematem, ponieważ sposób, w jaki organizujemy swoją pracę, zawiera wszystkie dobre praktyki psychologii produktywności i sukcesu.

Nie bez powodu rozbijamy plan na konkretne kawałki, które chcemy dowozić często. Nie bez powodu regularnie wyciągamy wnioski na temat własnej pracy. Nie bez powodu tak często zastanawiamy się nad priorytetami i wyceną. Zasada jest prosta: plan powinien być dopasowany do rzeczywistości. Nie na odwrót.

Jeśli artykuł był dla Ciebie przydatny i chcesz docenić moją pracę, to poproszę o lajka na FB :).

Nie przegap żadnego posta

Otrzymuj powiadomienie o nowym poście prosto na Twój adres e-mail i uzyskaj dostęp do dodatkowych materiałów – tylko dla czytelników newslettera.

Wczytywanie...

Chętnie poznam Twoją opinię – skomentuj tego posta na portalach społecznościowych. Nie zapomnij mnie otagować, jeśli chcesz mieć pewność, że zobaczę Twój komentarz.

Polub Brieftip