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.
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ę, wybierz plan abonamentowy albo kup dostęp do artykułu/dokumentu.
Zaloguj się
