Wykorzystanie story points do szacowania złożoności projektu informatycznego

Jednym z podstawowych wyzwań w zarządzaniu projektami jest szacowanie pracy, jaką zespół musi wykonać, by zrealizować konkretne zadanie. W metodykach tradycyjnych aspekt ten zazwyczaj określa się w jednostkach czasowych, np. godzinach pracy, przy założeniu dostępności określonych zasobów osobowych. Metody zwinne proponują jednak inne podejście, oparte w większym stopniu na efektywności zespołu projektowego i tzw. historyjkach użytkowników. Stosowaną miarą pracy są tu story points – abstrakcyjne mierniki ilustrujące zakres pracy, jaki należy wykonać, by zrealizować dane zadanie.

CiRZ_5_15.jpg

Konsekwencje podejścia iteracyjnego

Zwinne metody zarządzania projektami, takie jak Scrum, opierają się na podejściu iteracyjno-przyrostowo-adaptacyjnym, zgodnie z którym produkt powstaje w sposób przyrostowy, podczas kolejnych iteracji (zwanych również sprintami), zaś plan projektu ma charakter otwarty i podlega ciągłym zmianom adaptacyjnym. Charakterystyczną cechą Scrum jest to, że wszystkie występujące w nim zdarzenia, łącznie z samym sprintem, mają określone przedziały czasowe, które nie mogą ulegać zmianom. W efekcie projekt nie może się opóźnić, a jedynie tworzona w jego trakcie część produktu może nie spełniać wszystkich wymagań, jakie wstępnie założono. Tego rodzaju „braki” uzupełniane są podczas kolejnej iteracji. Istotną kwestią podczas planowania prac do wykonania jest określenie pracochłonności kolejnych zadań. W Scrum zamiast szacowania w godzinach, dniach czy tygodniach wykorzystuje się dość nietypową miarę – tzw. story points, których wartość powiązana jest nie tylko z czasochłonnością i złożonością zadania, ale także z efektywnością zespołu, który odpowiada za jego wykonanie.

Jak planuje się zwinne projekty?

W Scrum zadania realizowane w czasie kolejnych iteracji planowane są na podstawie rejestru produktu (ang. product backlog), który zawiera pełną listę wymagań, jakie powinien spełniać gotowy produkt. Wymagania znajdujące się w tym rejestrze powinny być uszeregowane w kolejności, jaka odpowiada ich realizacji, przy czym struktura ta może podlegać zmianom wraz z postępem prac zespołu deweloperskiego. Zespół ten podczas planowania każdego kolejnego sprintu wybiera z backlogu produktu część wymagań, jakie będzie w stanie zrealizować podczas trwania pojedynczej iteracji o ściśle określonym przedziale czasowym (np. 2 tygodni) i umieszcza je w rejestrze sprintu (ang. sprint backlog). W rejestrze tym poszczególne wymagania są rozbijane na zadania przeznaczone do realizacji (rysunek 1). W Scrum nie ma osoby odpowiadającej za typowe zarządzanie projektem – to zespół deweloperski decyduje, w jaki sposób przebiegały będą prace nad poszczególnymi zadaniami znajdującymi się w rejestrze sprintu oraz w jakiej kolejności zostaną one wykonane.

Wykorzystałeś swój limit bezpłatnych treści

Pozostałe 78% artykułu dostępne jest dla zalogowanych użytkowników portalu. Zaloguj się, albo wybierz plan abonamentowy.

Wybierz abonament już od 83 zł miesięcznie Pokaż abonament
Dwutygodniowy dostęp bez zobowiązań Wybieram

Abonament już od 83 zł miesięcznie

Dwutygodniowy dostęp bez zobowiązań

Pełen dostęp do wszystkich treści portalu
to koszt 83 zł miesięcznie
przy jednorazowej płatności za rok

WYBIERAM

Dwutygodniowy dostęp do wszystkich treści
portalu za 99 zł netto, które odliczymy od ceny
regularnej przy przedłużeniu abonamentu

WYBIERAM

Pełen dostęp do wszystkich treści portalu
to koszt 990 zł miesięcznie
przy jednorazowej płatności za rok

Dwutygodniowy dostęp do wszystkich treści
portalu za 99 zł netto, które odliczymy od ceny
regularnej przy przedłużeniu abonamentu

WYBIERAM