Share on Facebook Tweet it

Kilka słów o story points

Story points to jedna z miar, którą można przyjąć do estymacji iteracji. Niektórzy upierają się, że szacunki w story points, które mają na celu m. in. wyznaczenie szybkości zespołu(„velocity”), są nieoptymalne ponieważ:

  1. równie dobrze można użyć „idealnych godzin”.
  2. „velocity” wyznaczone na podstawie story points jest zmienne i nie można na jego podstawie niczego wnioskować.
  3. estymatę w story points można łatwo naciągnąć.

Chciałbym w tym wpisie ustosunkować się do tych trzech argumentów.

Ad.1. Na pierwszy rzut oka idealne godziny, zwane też godzinami softwarowymi, inżynierskimi lub godzinami netto nadają się do estymacji user story. Każde wymaganie można oszacować takimi godzinami, które to z kolei godziny można przeliczyć na godziny brutto i mieć wyobrażenie ile czasu zajmie wykonanie danej funkcjonalności.

Zastanówmy się jednak nad naturą problemów, które estymujemy. Pamiętajmy, że proces wytwarzania oprogramowania jest  procesem kreatywnym , w którym mamy do czynienia z rozwiązywaniem problemów, bardzo często napotykanych po raz pierwszy. Sumując idealne godziny bierzemy pod uwagę problemy, które z góry przewidujemy. Na resztę przeznaczamy bufor. Problem polega na tym, że im większa jest niewiadoma, z którą się zmagamy, tym większy bufor powinniśmy przewidzieć. W pewnym momencie bufor, może stać się bardzo znaczną częścią sumy godzin przeznaczonej na przewidziane zadania a nawet ją przewyższyć. Wynika z tego, że o ile estymacja w idealnych godzinach nadaje się do szacowania dobrze opracowanych zadań, tak do user story, które dopiero mają zostać przeanalizowane i podzielone na zadania – niekoniecznie.

Za pomocą story points dokonujemy oszacowania porównawczego. Porównując dane user story ze zrealizowanymi już user story bazujemy na naszym doświadczeniu, natomiast porównując kilka niewykonanych jeszcze user story zakładamy, że ilość niewiadomych w tych user story jest proporcjonalna do jej wielkości oraz że niewiadome rozkładają się w naszych problemach równomiernie, co mimo sporych lokalnych rozbieżności, wydaje się być na dłuższą metę sensownym założeniem.

Ad. 2. Velocity wyznaczone na podstawie story points, pokazuje prędkość z jaką zespół realizuje funkcjonalności. Niektórzy sceptycy, szczególnie w początkowej fazie wdrażania agile narzekają na to, że użyteczność velocity jest znikoma ponieważ rozrzut zrealizowanych user story w sprincie jest zbyt duży. Nie zgadzam się osobiście z tym spojrzeniem. Velocity powinno traktować się jako prędkość średnią a nie prędkość chwilową. Na podstawie ostatnich 5 a nawet 3 iteracji otrzymujemy użyteczną wielkość, na podstawie której, możemy oszacować ile iteracji pozostało do zakończenia projektu.

Ad.3. Czasami spotykam się z opinią, że story points są bezużyteczne, ponieważ łatwo można nimi manipulować. W pewnym stopniu się z tym zgadzam. Wydaje mi się jednak, że godzinami idealnymi można manipulować łatwiej, ponieważ można przyjmować ostrożną taktykę przyjmując bardzo duży bufor. Taktyka ta nie sprawdza się już odnośnie story points, gdzie zamiast szacowania wielkości w godzinach, porównujemy do siebie. Story points pozwalają nam na chwilę więc zdjąć kapelusz dewelopera i zdystansować się do danego user story.

Na koniec chciałem jeszcze zaproponować rygorystyczne rozliczanie story points, tzn. jeśli na koniec sprintu dane user story jest zrealizowane w 90% zapisujemy, uwaga – 0 story points!  Takie podejście, pomimo zwiększania w krótkim terminie zmienność velocity, w długim terminie wymusza na zespole oddawanie funkcjonalności zgodnie z „definition of done”, przyczyniając się do poprawy jakości tworzonego systemu.

 

Tags: , ,

Profile photo of liber

About liber

Jestem zdeklarowanym zwolennikiem zwinnych praktyk. Większość mojego doświadczenia z agile stanowi praca z zespołami scrumowymi zarówno jako Scrum Master jak i jako Scrum Coach. Nie stronie jednak od innych podejść. Ostatnio, na przykład, miałem przyjemność bycia członkiem zespołu kanbanowego. Po klikuletniej pracy w londyńskim City obecnie związany jestem z firmą Espeo Software.

Comments are closed.