Czy projekty agile da się zaplanować?

Cykl: Zwinna Firma
14 stycznia 2015

12

No i dobrnęliśmy do końca naszych konkursowych pytań. Dzisiaj odpowiadam na ostatnie, spośród tych, które przysłaliście. Od razu mówię, że wpis jest trochę długi, ale chciałem dobrze przygotować grunt pod odpowiedź. 🙂

Tak jak obiecałem, wszystkie pytania razem z autorami zostaną zebrane i wydane przez Wydawnictwo Helion w formie bezpłatnego eBooka, którego Wam niebawem udostępnię. No to… GO!

***

Chciałbym zapytać o faktyczną rolę Product Backlogu, jego pielęgnowanie i oszacowywanie zadań.

Co w sytuacji, w której środowisko pracy jest bardzo zmienne i nagle okazuje się, że wstępne szacunki nie przystają do wcześniejszych ustaleń? Szacowanie i wyznaczanie na podstawie ogólnej wiedzy jakichkolwiek długoterminowych założeń opiera się na założeniach, które mogą się mieć nijak do niepewności i zmienności jaka towarzyszy produkcji oprogramowania?

Szacunki te mają spory wpływ na planowanie najbliższego Sprintu. Czy Product Owner powinien zadbać o to, aby Zespół Deweloperski rozumiał w 100% wymagania biznesowe i wspólnie mogli jak najlepiej oszacować wysiłki długoterminowe – dotyczące Product Backlogu? Nawet kosztem kilku godzin pracy w ramach każdego sprintu? Czy może jednak źle o tym myślę i rejestr produktu jest obietnicą dla innych interesariuszy, ale tylko tymczasową, z natury zmienną? A może w takim środowisku Scrum nie będzie najlepszym wyborem i sugerowałbyś inne rozwiązania?

Maciej M.

Maćku! Na początku jedna bardzo ważna uwaga. Agile powstał właśnie po to, żeby radzić sobie ze zmiennym środowiskiem pracy i, w trakcie trwania projektu, może zdarzyć się właśnie tak, że jak napisałeś: „wstępne szacunki nie przystają do wcześniejszych ustaleń”. Tworzenie oprogramowania ze swej natury jest procesem twórczym i bardziej przypomina powstawanie dzieła sztuki niż hamburgera w McDonaldzie. Na etapie startu projektu mamy tylko konkretne cele, które chcemy zrealizować. Wymagania, podobnie jak szczegóły malowanego obrazu, rozwijane są w kolejnych odsłonach (iteracjach), po których dostarczane są kawałki działających części (inkrementy). Wymagania w projektach IT przypominają trochę szkice artysty, które stopniowo odsłaniają się w kolejnych krokach implementacji. Przez cały czas trwania projektu pewne są tylko cele, które chcemy osiągnąć. Reszta jest w ciągłym ruchu i napięciu twórczym. Taki proces jest zgodny z naturą projektów IT, w ramach których tworzymy (sic!) software. Kolejne części powstającej aplikacji prowokują, pobudzają naszą kreatywność, generują kolejne pomysły, uczą. Taki jest agile!

Jak w takim razie zarządzać takimi projektami? Czy projekty agile można w ogóle sensownie zaplanować? Co z szacunkami? Co założeniami długoterminowymi? W Twoim mailu pojawiło się kilka bardzo zasadnych pytań, które „niepokoją” wielu project managerów.

Biorę się za odpowiedzi. 🙂

Tak. Projekty agile’owe da się sensownie zaplanować. Zanim Maćku odpowiem na Twoje pytania, najpierw przedstawię sześć sprawdzonych kroków planowania projektów agile, które na co dzień stosuję u moich klientów. Myślę, że po ich przeczytaniu, przynajmniej część Twoich wątpliwości zostanie rozwiana. 

Krok 1: Ustal, co jest do zrobienia

Zaczynamy trochę jak w projektach kaskadowych – próbujemy zbudować listę funkcjonalności, które powinny pojawić się w naszym projekcie. Różnica polega na tym, że nasza lista nie jest kompletna. Wymagania mogą się zmieniać w trakcie trwania projektu i to jest zupełnie normalne. Chcemy, żeby tak było, bo na tym polega proces tworzenia. I tu mamy pierwsze nieporozumienie. Skoro wymagania są zmienne, jak w takim razie mamy zaplanować projekt? Co z harmonogramem projektu? Na kiedy to wszystko będzie gotowe? Tych i podobnych pytań możemy spodziewać się od naszych klientów, których na pewno będzie jeszcze interesowało, ile to wszystko będzie kosztować. I tutaj dochodzimy do bardzo ważnej kwestii. Agile, wcale nie oznacza, że planowanie „długoterminowe” wcale nie istnieje i wszystko zaczyna się i kończy na pojedynczym sprincie. A reszta – to wielka niewiadoma. Tak nie jest.

Planowanie w projektach zwinnych odbywa się na kilku poziomach i przypomina trochę obieranie cebuli. Stopniowo, krok po kroku, ściągamy kolejne warstwy. Sporo nieporozumień, związanych z planowaniem projektów agile bierze się stąd, że skupiamy się głównie na środkowych warstwach cebuli: planowanie na poziomie sprintów i codziennych stand-up’ów. Pozostałe elementy się nie liczą. Zostawiamy je organizacji. Tymczasem, wszystkie założenia „długoterminowe” dotyczą tego, co się dzieje poza horyzontem danego sprintu – na poziomie konkretnego wydania. Do tego warto jeszcze dodać, że „długoterminowość” nie jest tutaj rozumiana tak jak w projektach kaskadowych, gdzie oznaczała naprawdę długi horyzont planowania, na przykład dziewięciu i więcej miesięcy. „Długoterminowość” w projektach zwinnych, to perspektywa kilku sprintów – w praktyce najczęściej sprowadza się do jednego, dwóch lub trzech miesięcy.

Agile Release Planning

Co robimy na poszczególnych poziomach planowania?

  • Planowanie wydania. Rozmawiamy o celach biznesowych, które chcemy osiągnąć. Dyskutujemy podstawowe ograniczenia projektu: budżet, harmonogram, zakres. Wybieramy konkretne tematy oraz historyjki, które chcemy zaimplementować. Rozmawiamy o ich priorytetach. Próbujemy także oszacować wielkość pracy, jaką mamy do wykonania. Ile nam to zajmie? Wreszcie, tworzymy plan wydania, do którego później wracamy – aktualizujemy go, odsłaniając kolejne warstwy.
  • Planowanie sprintu. Na tym etapie planujemy mniej. Bo mniejszy też jest horyzont planowania (2-4 tygodnie). Zespół zastanawia się, ile w tym czasie jest w stanie zrobić. Product Owner opowiada o priorytetach, o tym, jakie historyjki powinny znaleźć się w planie sprintu. Zespół zastanawia się, jak podzielić pracę na konkretne zadania.
  • Codzienne planowanie. Mimo, iż jest ono bardzo nieformalne, to jednak ma bardzo duże znaczenie dla koordynacji pracy. Zespół codziennie spotyka się na krótkie, piętnastominutowe spotkania, żeby zsynchronizować swoje zadania. Wszelkie odchylenia od planu są na bieżąco korygowane.

Założenia „długoterminowe”, dotykają planowania na poziomie kolejnych wydań produktu, a nie sprintów. Kiedy uruchamiamy jakąś inicjatywę w firmie, na początku mamy najczęściej tylko listę określonych pomysłów i wizji, z których za chwilę wyłoni się Backlog Produktu. Powstanie jego zarys – szkielet, który stopniowo będziemy wypełniać nowymi elementami. Na co dzień, zwykle dzieje się to w ramach sesji pielęgnacyjnych w sprincie (projekty bieżące) lub w trakcie przygotowywania się do uruchomienia sprintu 1.

Efektem tych prac, jest pierwsza wersja planu naszego projektu, która wyznacza kierunek dalszych prac. Jak pokazuje rysunek poniżej, na samej górze tej układanki są jakieś tematy strategiczne, którymi chcemy się zająć w naszym projekcie. Tematy z kolei grupują epiki – a więc duże historyjki użytkownika, które wymagają dalszej dekompozycji na mniejsze fragmenty pracy. Sam zakres release’u składa się z historyjek użytkownika, które są realizowane w kolejnych sprintach. Może to wyglądać na przykład tak jak przedstawia rysunek poniżej:

User Story Mapping

Przy konstruowaniu planu wydania, nie ma sensu planować wszystkich sprintów od a do z, bo czy to kolejność, czy same wymagania w Backlogu mogą się zmienić. Tak zwane „planowanie do przodu” (np. 2-3 sprintów) ma jednak sens, gdy mamy do czynienia z zależnościami między zespołami lub zewnętrznymi dostawcami, co w dużych organizacjach jest na porządku dziennym.

Podsumowując ten krok, mamy więc listę tematów strategicznych, które tworzą coś na wzór kręgosłupa produktu. Potem powstaje jego szkielet (epiki) oraz historyjki, które go „wypełnieniają”.

Krok 2: Oszacuj wielkość historyjek

Mamy wstępną listę funkcjonalności w projekcie, którą teraz trzeba oszacować. Pamiętajmy, że cały czas mówimy o planowaniu wydania, a nie konkretnego sprintu. Do szacowania używamy punktów (ang. story points) lub osobodni. Nie polecam idealnych godzin, które z kolei bardzo dobrze sprawdzają się podczas planowania sprintu. 

Krok 3: Określ długość sprintu

Na początku, kiedy zaczynamy swoją przygodę ze zwinnością, długość sprintu może się zmieniać. Zespół eksperymentuje, uczy się jakie podejście jest najbardziej optymalne do jego pracy. Potem, żeby lepiej planować pracę na poziomie projektu, dobrze jest, gdy długość sprintu jest stała. To też wpływa na podtrzymanie stałego rytmu pracy w projekcie.

Krok 4: Ustal priorytety

Product Owner porządkuje elementy w Product Backlogu. Często wspiera się przy tym radą i pomocą zespołu, którego doświadczenie może się bardzo przydać. Poza tym, jest jeszcze otoczenie projektu (inne projekty, programy, dostawcy), które również przy ustalaniu priorytetów Backlogu mają znaczenie, szczególnie w dużych organizacjach. 

Krok 5: Jaka jest prędkość zespołu?

Żeby dobrze zaplanować projekt, musimy wiedzieć ile jednostek pracy (punkty lub osobodni) zespół średnio „spala” w sprincie. Prędkość zespołu oraz długość sprintu będą nam potrzebne do kolejnego punktu, w którym wreszcie powstanie wstępny plan naszego projektu i harmonogram.

Krok 6: Wybierz historyjki i ustal datę

I tutaj dochodzimy do najważniejszego momentu. Musimy wiedzieć, jakiego typu jest nasz projekt. Czy bardziej zorientowany na datę, czy może na konkretne funkcjonalności. W każdym przypadku podejście do planowania będzie trochę inne. 

Projekty typu „fixed-date”

To jest sytuacja, w której data wydania jest stała. Ale możemy „manipulować” liczbą dostarczanych funkcjonalnościach. Może się na przykład okazać, że po dwóch miesiącach pojawi się jakaś super ważna historyjka, która na bank musi wejść do wydania. Nie ma problemu! Dodajemy nową, zabieramy starą. To oczywiście wpływa na ustalony zakres prac w projekcie.

Agile Fixed-Date Project

Planowanie projektów typu „fixed-date” składa się z trzech kroków:

  1. Ustal liczbę sprintów. Znamy datę wydania. Przyjmijmy, że jest to 30 czerwca. Załóżmy też, że długość naszych sprintów to 1 miesiąc. Bierzemy teraz do ręki kalendarz (oczywiście aktualny) i liczymy. Do zakończenia wydania mamy dokładnie 6 sprintów.
  2. Oszacuj prędkość zespołu i wyraź ją za pomocą skali. Nie interesuje nas wartość punktowa. Chcemy wiedzieć, ile punktów zespół „wypali” w najlepszym i najgorszym wypadku. Powiedzmy, że prędkość pesymistyczna to 15 punktów, a optymistyczna 20.
  3. Oszacuj możliwą liczbę punktów dostarczonych w wydaniu. Pamiętajcie, że cały czas musimy brać pod uwagę ten dobry i zły scenariusz. Zakładając, że zespołowi nie będzie sprzyjał dobry los, mnożymy liczbę sprintów (6) przez prędkość pesymistyczną (15 punktów). W ten sposób dowiemy się, ile punktów łącznie zespół będzie mógł dostarczyć w planowanym wydaniu. Oczywiście są to wartości szacunkowe. Niemniej, na ich podstawie, możemy bezpiecznie przyjąć, że historyjki, których łączna wielkość odpowiada wyliczonym punktom, raczej na pewno zostaną dostarczone w wydaniu XY. Podobną kalkulację stosujemy dla prędkości optymistycznej. W ten sposób wiemy ile dodatkowych funkcjonalności zespół będzie mógł zrealizować, zakładając, że będą mu sprzyjać bóstwa.
Agile Fixed-Date Planning
Planowanie wydania w projektach typu „fixed-date”

Projekty typu „fixed-scope”

Tutaj z kolei, jesteśmy trochę bardziej elastyczni, jeśli chodzi o datę. Ustalamy z klientem listę najważniejszych funkcjonalności, które muszą zostać dostarczone. Jednocześnie akceptujemy pewne ryzyko, związane z datą wydania.

Agile Fixed-Scope Planning

W tym podejściu strategia postępowania jest odrobinę inna, niż w projektach zorientowanych na datę.  Tym razem, musimy wykonać trochę inny zestaw kroków:

  1. Ustal, co jest do zrobienia. Wspólnie z Product Owner’em próbujemy zbudować listę wszystkich funkcjonalności, które chciałby zobaczyć w najbliższym wydaniu.
  2. Oszacuj wielkość wybranych funkcjonalności. Mamy już listę tematów/ epików, które, choćby nie wiem co, muszą znaleźć się w planowanym wydaniu. Dekomponujemy je na historyjki użytkownika i szacujemy.
  3. Oszacuj prędkość zespołu i wyraź ją za pomocą skali. Do tej pory strategia postępowania jest identyczna, jak przy planowaniu dowolnego wydania. Szacujemy więc, ile jesteśmy w stanie przyjąć „na klatę” w sprincie. Przyjmijmy, podobnie jak w poprzednim przykładzie, że prędkość optymistyczna wynosi 15 punktów, a pesymistyczna 20.
  4. Oszacuj datę wydania. Żeby to zrobić, musimy obliczyć wielkość wszystkich planowanych funkcjonalności. Załóżmy, że wyszło nam 120 punktów. Teraz, tę liczbę dzielimy przez optymistyczną i pesymistyczną wartość prędkości zespołu. W ten sposób, dowiadujemy się, kiedy najwcześniej i najpóźniej skończymy projekt.
Agile Fixed-Scope Planning
Planowanie wydań w projektach typu „fixed-scope”

Wracam do pytania

Po tym wstępie, raz jeszcze wracam do Twojego pytania Maćku:

Co w sytuacji, w której środowisko pracy jest bardzo zmienne i nagle okazuje się, że wstępne szacunki nie przystają do wcześniejszych ustaleń? Szacowanie i wyznaczanie na podstawie ogólnej wiedzy jakichkolwiek długoterminowych założeń opiera się na założeniach, które mogą się mieć nijak do niepewności i zmienności jaka towarzyszy produkcji oprogramowania?

Jak widzisz, zmiana założeń długoterminowych nie jest czymś złym i, w pewnym sensie, na to się godzimy, gdy idziemy ścieżką zwinną. Z drugiej strony, nie jest też tak, że agile niesie ze sobą totalne rozpasanie, jeśli chodzi o prowadzenie projektu. Istnieją bardzo konkretne reguły planowania pracy i każda decyzja, związana ze zmianą założeń „długoterminowych” ma swoje konsekwencje, z którymi trzeba się liczyć. Zmiana zakresu w projektach typu „fixed-date” może skutkować na przykład tym, że nie zrealizujemy pierwotnego planu. W zamian za to, zrealizujemy jednak plan, który bardziej odpowiada bieżącym potrzebom biznesowym. Podobnie jest w projektach typu „fixed-scope”, gdzie zmiana wymagań może skutkować, na przykład zmianą daty „wypuszczenia” produktu na rynek. W zamian za to, zbudujemy jednak produkt, który będzie składał się z najbardziej wartościowych funkcjonalności. Takie podejście zawsze bardzo się opłaca.

I jeszcze druga część Twojego pytania:

Szacunki te mają spory wpływ na planowanie najbliższego Sprintu. Czy Product Owner powinien zadbać o to, aby Zespół Deweloperski rozumiał w 100% wymagania biznesowe i wspólnie mogli jak najlepiej oszacować wysiłki długoterminowe – dotyczące Product Backlogu? Nawet kosztem kilku godzin pracy w ramach każdego sprintu?

Tak. Product Owner powinien zadbać o to, żeby Zespół Deweloperski dobrze rozumiał jego wizję i cele biznesowe, które chce osiągnąć w projekcie. Taka jest między innymi jego rola – czytelne artykułowanie elementów Backlogu oraz zadbanie o to, żeby zespół wiedział, co ma robić. Co do zaangażowania zespołu w formułowanie założeń „długoterminowych”, zespół również powinien w tym uczestniczyć, na przykład poprzez:

  • wspólne (z Product Ownerem) pisanie epików i historyjek (warsztaty)
  • szacowanie pracy (sesje estymacyjne)
  • dyskutowanie o rozwiązaniach technicznych
  • analizę możliwych zależności i kolejności elementów Backlogu Produktu

Nie wyobrażam sobie, żeby prace planistyczne na poziomie projektu odbywały się „za plecami” zespołu.

***

Dzięki za bardzo dobre pytanie. Gdybyś miał jeszcze jakieś wątpliwości, pisz śmiało na adres: me@mariuszchrapko.com  Będę odpowiadał 😉