Miary zwinności

Często, podczas szkoleń i warsztatów mówicie, że interesuje Was praktyczna strona zwinności. Pytacie co mierzyć, jak mierzyć, jak często mierzyć, a przede wszystkim – po co to robić? Dziś, w pierwszej części cyklu miary zwinności, w jednym miejscu zbieramy najczęstsze pułapki różnych mierników i wskaźników.

 

“Dziwnie” brzmiące nazwy

Capacity, Velocity, Story Points i tym podobne nazwy brzmią zupełnie obco dla nowych członków Zespołów Deweloperskich. Zresztą nigdy nie ukrywałem tego, że sam na początku swojej zwinnej przygody, miałem z nimi problem. Wspominałem o tym również na naszym blogu.

Jedni zastanawiają się, po co w ogóle mierzyć, jaki to ma sens i co może nam dać. Inni podchodzą do nich z aptekarską precyzją. A przecież chodzi o to, żeby się nie “zajechać”. Również i w tym przypadku powinna działać zasada – wszystko jest dla ludzi. A nawet –  dla zespołów. Podejdźmy więc do tematu empirycznie.

Nie będziemy skupiać się dziś na definicji każdego z przytoczonych powyżej terminów – zrobiliśmy to już jakiś czas temu. Skupimy się za to na praktycznym ich wykorzystaniu, a w szczególności na ich nadinterpretowaniu i nadużywaniu.

 

Capacity

Capacity to pojemność zespołu. Określa ile “mocy przerobowych” mamy do wykorzystania w najbliższym Sprincie.

Jako miara potrzebna jest nam między innymi podczas planowania Sprintu. Jako zespół, musimy przecież wiedzieć, ile mamy dostępnych “osobodni” na realizację planowanych przez nas wymagań. Wam też kłóci się to z agile mindset? No cóż, nie wszystko może być tak piękne i idealne. Jeżeli chcemy korzystać z capacity, to musimy je w jakiś sposób wyliczyć.

Jak to zrobić? Najłatwiej liczbę osób w zespole pomnożyć przez kodeksową ilość godzin. Otrzymujemy wartość, która – nie oszukujmy się – niewiele ma wspólnego z rzeczywistością. Dlaczego? Badania pokazują, że na każde 8 godzin spędzonych w pracy przypada 2 godziny i 53 minuty pracy faktycznej. Oczywiście jest to wartość średnia, niektórzy pewnie osiągają całe cztery godziny.

Ile wynosi więc capacity 5 osobowego zespołu w 2 tygodniowym Sprincie?

A) 400 godzin
B) 144 godziny i 10 minut

Różnica jest drastyczna, prawda? Nie da się ukryć, że capacity przydaje się w nowych zespołach, aby na przykład nie zaplanować 150 godzin testów dla jednego testera w zespole. Doświadczone zespoły jednak “czują” ile potrafią zrealizować w każdym Sprincie bez wspierania się tą metryką.

 

Velocity

Velocity, a więc prędkość zespołu wyrażona w sumie wielkości dostarczonych wymagań. “Wielkość” to nic innego jak miara, w której wycenione są wymagania w Waszych Backlogach. Mogą to być na przykład Story Points, o których za chwilę.

Jaką informację daje nam owa prędkość? Będzie bardzo pomocna przy prognozowaniu ilości pracy, jaką możemy “wziąć na warsztat” w każdym kolejnym Sprincie. Wartości historyczne pokazują zachwiania, które mogą być wynikiem wprowadzanych zmian i usprawnień. Możemy też badać, czy zespoły pracują coraz wydajniej.

Czy jest to miara idealna? Jak każda, tak i ta w dużej części zależy od jakości danych, na których się opieramy. A te, jeśli zespół nie rozumie celu wyceny wymagań lub brakuje mu transparentności w określeniu co jest done, mogą być dalekie od ideału.

Nie ulega jednak wątpliwości, że na czymś nasze prognozy musimy oprzeć. Nie mając jasno, sztywnie określonego zakresu projektu musimy co Sprint podejmować decyzje, ile będziemy realizować. W tym pomoże nam świadomy zespół i Product Owner. Ten ostatni zresztą na velocity właśnie będzie prognozował terminy i szkicował harmonogramy.

 

Story Points

I doszliśmy do mojej ulubionej miary. “Ulubiona”, bowiem właśnie ją najłatwiej jest wypaczyć. A to z kolei prowadzi do poważnych konsekwencji.

Story Points to względna wycena wymagania znajdującego się w Backlogu Produktu, wyrażona w punktach. To, że jest to miara punktowa i względna nie oznacza, że nie da się korzystać z niej źle. Przede wszystkim nie powinny stać za nią pieniądze, ani czas. To jednak wcale nie zwalnia nas z obowiązku rzetelnej wyceny wymagań.

Ale jak tego dokonać, kiedy często nie wiemy co jest przedmiotem wymagania lub jaki jest cel jego realizacji? Moje ulubione pytanie to “Ile to będzie kosztowało?” zadane zespołowi, który widzi wymaganie pierwszy raz na oczy. Jaka to będzie wycena? Obarczona dużą niepewnością, niedokładna i nierzetelna.

W tekście “Szacowanie, czyli Story Points i nie tylko” poruszyliśmy wiele technicznych aspektów szacowania w miarach względnych, bezwzględnych i punktach. Z kolei omawiając “Planning Poker i nie tylko” skupiliśmy się na metodach szacowania. Tutaj chcemy podkreślić, że najważniejszym aspektem wyceny jest znajomość wymagania.

Na naszych wycenach oparte zostanie Planowanie Sprintu, a rezultaty naszej pracy znajdą też odzwierciedlenie w Velocity. Niedokładne albo wręcz błędne wyceny bardzo szybko “wyjdą nam bokiem”.

 

Miary zwinności

Wpis ten jest pierwszą częścią cyklu odpowiadającego na pytanie o miary używane w zwinności. Celowo wybrałem do niego właśnie te dość podstawowe, ale jednocześnie zależne od siebie miary. Chciałem pokazać w ten sposób, że miary w zwinności to system wzajemnie powiązanych ze sobą elementów. Zachwianie jednym z nich powoduje natychmiastowe konsekwencje w innych.

Odpowiedzialność za poszczególne miary leży na Zespole Scrumowym, a nie Deweloperskim. Oznacza to, że wszyscy w tym samym zakresie odpowiedzialni jesteśmy za ich akuratność i prawdziwość.

Poświęćmy więc chwilę czasu na rzetelną wycenę. Jeśli mamy problemy z wymaganiami – udajmy się do Product Ownera. A jeśli nie rozumiemy po co coś mierzymy, to zapytajmy o to osobę, która powinna znać odpowiedzieć na to pytanie, czyli Scrum Mastera.

 

Opublikowaliśmy także drugi tekst z cyklu Miary zwinności. Zapraszamy do czytania.

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: