Szacowanie w projektach IT – część 3

Szacowanie w projektach IT – część 3

Ten wpis jest kontynuacją części 1części 2.

Oszacowanie projektu o stałym zakresie dla klienta wewnętrznego

Projekty o stałym z góry znanym zakresie to projekty prowadzone metodykami kaskadowymi typu Waterfall.  Warto pamiętać, że zakres w tego projektach tylko z nazwy jest stały, bo jakkolwiek dokładna nie byłaby analiza, to zmiana zakresu jest nieunikniona. W tym podejściu biznes przygotowuje opasły dokument z wymaganiami biznesowymi, które są następnie transformowane w specyfikację funkcjonalną i szacowane przez zespół jako całość. Sposób oszacowania jest tu podobny jak w przypadku ofert/kontraktów fixed-price dla klienta zewnętrznego, czyli pracochłonność oczekiwana i czasochłonność pesymistyczna, jednak marginesy bezpieczeństwa są niższe, bo nie ma kar umownych za opóźnienia. Ryzyka komunikuje do odbiorcy projektu wewnątrz organizacji, ale nie zawsze uwzględnia się je w wycenie. Ryzyko zwiększonego budżetu i opóźnień w takich projektach w praktyce ponosi więc odbiorca (w przeciwieństwie do kontraktów fixed-price pomiędzy osobnymi podmiotami, gdzie część ryzyka przerzucona jest na dostawcę). Jeśli biznes chce się zabezpieczyć przed przekroczeniami budżetu i czasu, to może stworzyć coś w rodzaju uproszczonego kontraktu pomiędzy biznesem a działem IT, jednak powoduje to dodatkowe narzuty, nie zabezpiecza w pełni interesów odbiorcy projektu i ostatecznie za opóźnienia płaci i tak ta sama firma co wykonuje projekt.

W projektach dla klienta wewnętrznego metodyki Waterfall coraz częściej zastępowane są metodykami Agile.

Planowanie iteracji i wydania w projektach prowadzonych metodyką Scrum

Storypointy

Scrum podczas planowania iteracji do oszacowania pracochłonności zadań i user stories często używa się jednostek storypoint.

Skala oszacowania jest dyskretna i dopuszczalne są tylko określone wartości, najczęściej używany ciąg tych wartości to: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 oparty na ciągu Fibonacciego. Jednostka storypoint jest miarą względną (relatywną). Wdrożenie takiej miary wymaga kalibracji skali w pierwszej iteracji na przykład w ten sposób:

  1. zespół definiuje 2 przykładowe zadania, jedno bardzo małe, które można wykonać w bardzo krótkim czasie i jedno duże, ale takie, które ciągle da się wykonać w ciągu jednej iteracji,
  2. małe zadanie dostaje wartość z dołu skali, np. 0,5 lub 1 storypoint,
  3. duże zadanie dostaje wartość z góry skali, np. 13 lub 20 storypoint.

Po kalibracji można już wykorzystać skalę i przejść do właściwego oszacowania zadań. Każdemu szacowanemu zadaniu przydziela się wartość poprzez  porównanie pracochłonności tego zadania do dwóch punktów referencyjnych określonych podczas kalibracji oraz wybranie takiej wartości z dyskretnej skali, która znajduje się najbliżej naszego oszacowania.

Wprowadzenie jednostek storypoint i skali dyskretnej ma na celu:

  1. odseparowanie tych estymat od bezwględnych miar pracochłonności w dniach roboczych, które mogłyby być interpretowane jako precyzyjne estymaty pracochłonności lub jako czas trwania tych zadań,
  2. skala dyskretna oparta o ciąg oparty o ciąg Fibonacciego pokazuje, że estymacje są mało precyzyjne i nie można się do nich zbytnio przywiązywać,
  3. poprzez niedeklarowanie konkretnych dat zespół uzyskuje swobodę podczas realizacji zadań w iteracji bez obaw, że będzie codziennie odpytywany o postęp czy daty zakończenia. Jedyna data, co do której zespół się zobowiązuje, to data końca iteracji i dotyczy wszystkich zadań w iteracji.

Planowanie iteracji – sprint planning

Scrum zakłada przyrostowe dostarczanie oprogramowania w regularnych cyklach zwanych iteracjami. Każda iteracja rozpoczyna się spotkaniem Sprint planning podczas którego zespół oszacowuje pracochłonność i planuje zakres prac na daną iterację.

Rezultatem spotkania Sprint planning są:

  1. cel sprintu,
  2. estymaty poszczególnych zadań,
  3. lista zadań, którą zespół zobowiązuje się dostarczyć w danej iteracji (Sprint backlog).

Oszacowanie pracochłonności poszczególnych zadań w storypoint ciężko zaklasyfikować jako optymistyczne czy pesymistyczne, bo jest to miara względna. Z kolei lista zadań w iteracji jest oszacowaniem pesymistycznym. Pracując w modelu iteracyjnym zespół zobowiązuje się na dostarczenie wszystkich zadań na koniec iteracji, nie planuje się dostarczenia części funkcjonalności w trakcie iteracji nawet, jeśli zostanie ona wcześniej skończona. Skoro zobowiązanie zespołu dotyczy dostarczenia całego zaplanowanego zakresu na koniec iteracji jako całość, to można potraktować je jako oszacowanie czasochłonności zadań, gdzie ta czasochłonność równa się długości iteracji.

Jako, że zobowiązanie (commitment) jest oszacowaniem bezpiecznym, może się zdarzyć, że pracochłonność zadań będzie mniejsza niż zespół przewidywał i zostanie jeszcze czas w iteracji na dodatkowe prace, w takim wypadku dobiera on kolejne zadania z listy uporządkowanej według bieżących priorytetów (backlog produktu) lub realizuje zadania techniczne, które nie są priorytetyzowane przez product ownera.

Jeśli zadanie jest zbyt ogólne, to zespół może odmówić zaplanowania zadania do iteracji z powodu niespełnionej definicję gotowości zadania do estymacji (definition of ready). Zespół może też zasugerować zaplanowanie na najbliższą iterację jedynie analizy i rozpoczęcia zadania (zadanie typu Spike), ale bez deklarowania konkretnych rezultatów tych prac. W obu przypadkach jest to próba poradzenia sobie z problemem niewystarczającej precyzji oszacowania i braku możliwości zobowiązania się do zakończenia tego zadania w jednej iteracji.

2. Planowanie wydania – release planning

Planowanie releasu (wydania produktu) to planowanie średnioterminowe, którego wynikiem jest określenie zakresu funkcjonalności produktu oraz ram czasowych dla najbliższego wydania produktu. Czasami planuje się od razu więcej niż jedno wydanie, ale poziom dokładności planu kolejnych wydań jest malejący.

W Agile podczas planowania wydań produktu często używa się do szacowania pracochłonności tych samych jednostek co przy planowaniu pojedynczej iteracji, czyli storypointów. Jeśli zadania przewidziane na release nie będą precyzyjnie zdefiniowane lub będą zbyt duże, to zespól albo przydzieli im wartości z górnej części skali lub nie będzie w stanie podać oszacowania. Dlatego też przed planowaniem wydania potrzebna jest wcześniejsza praca analityczna oraz odpowiednie rozbicie wymagań na mniejsze części. Wymagania często rozbijane są do poziomu historyjek (user stories).

Planowanie a Kanban

W przypadku metodyk bez iteracji jak Kanban, zespół nie planuje zadań na określony interwał czasowy, ale realizuje zadania na bieżąco według zmieniających się dynamicznie priorytetów. Metodyka ta skupia się na maksymalizacji przepływu (throughput), czyli szybkości dostarczania skończonych zadań. W tej metodyce nie ma formalnego szacowania zadań przed ich rozpoczęciem. Jeśli klient potrzebuje zgrubnej estymacji zadań to zespół podaje ją z reguły w dniach roboczych. Metodyki Kanban dobrze nadają się do projektów utrzymaniowych, pracy operacyjnej czy projektów z dużą zmiennością priorytetów i wielu zadaniach adhoc.

Planowanie długoterminowe w projektach Agile

Stożek niepewności (cone of uncertainty) pokazuje  właściwość, że we wczesnych etapach projektu niedokładność estymacji jest bardzo duża i maleje wraz z przechodzeniem do kolejnych faz projektu. Choć Agile zauważa potrzebę planowania dla różnych horyzontów czasowych i popularna jest wizualizacja tych perspektyw w formie “cebulki planowania” (ang. planning onion), to jednak sama metodyka skupia się na estymacji krótko- i średnioterminowej, czyli planowaniu iteracji oraz releasa. O wyższych warstwach tej “cebulki” Agile mówi pobieżnie bez wskazania jak wykonywać te estymacje.

Czy odbiorcą będzie klient zewnętrzny czy wewnętrzny, może on potrzebować planów średnio- i długoterminowych (plan taktyczny i strategiczny). Wkładem do tych planów jest zgrubne oszacowanie pracochłonności i czasochłonności projektu. Plany te są z reguły mniejszej dokładności niż plany krótkoterminowe i zawierają głównie punkty milowe określające daty końca etapów projektu, odbiorów, płatności, wypuszczenia produktu na rynek, itp.

Pracochłonność i czasochłonność do planowania budżetu i harmonogramu w planach taktycznych i strategicznych może być podana w roboczodniach czy roboczomiesiącach. Alternatywnie może to być liczba iteracji, którą też można przeliczyć na pieniądze na podstawie średnich kosztów zespołu na iterację. Czasochłonność może być również podana albo w dniach roboczych albo jako liczba iteracji.

W kontraktach fixed-price ryzyko przekroczenia budżetu częściowo przerzucane jest na dostawcę, dlatego oszacowania dostawcy w wycenie są bardziej pesymistyczne i uwzględniają ryzyka. W przypadku projektów Agile, które często oparte są o kontrakty Time&Material, ryzyko przekroczenia budżetu ponosi klient, więc zespół szacując pracochłonność i czasochłonność ma tendencje do podania oszacowania oczekiwanego z małymi marginesami bezpieczeństwa. Warto klientowi przygotować oszacowanie jako zakres z dolną granicą będącą oszacowaniem optymistycznym, a górną pesymistycznym. Dzięki temu klient może zaplanować odpowiednie marginesy w budżecie projektu oraz harmonogramie.

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *