Scrum Guide | 34. Prędkość Zespołu Deweloperskiego

Velocity pozwala określić tempo, w jakim Scrum Team realizuje zadania. Można zdefiniować ją jako średnią ilość Story Points wykonanych w jednym Sprincie. Velocity może służyć także do szacowania czasu trwania projektu na podstawie już zrealizowanych postępów w pracy. Ma to jednak sens jedynie w przypadku dojrzałego zespołu, który pracuje w równym i stabilnym tempie

Prędkość Zespołu Deweloperskiego – omówione zagadnienia:

1. Wprowadzenie
2. Velocity rzeczywista i planowana
3. Trudności i zagrożenia związane z Velocity
4. Podsumowanie

Wprowadzenie

Velocity jest opcjonalnym, lecz chętnie używanym sposobem mierzenia tempa pracy Scrum Team. Dzieje się tak, ponieważ trafnie oszacowana pozwala w pewnym stopniu prognozować czas potrzebny na realizację projektu. Jest to jednak miara, która może być stosowana tylko w odniesieniu do danego Zespołu Developerskiego, który będzie wykonywał zadania, które sam „wycenił” używając znanej sobie jednostki, takiej jak na przykład Story Points.

Prędkość Zespołu Developerskiego jest najczęściej przedstawiana w formie Velocity Chart. Na osi X są tutaj oznaczane kolejne Sprinty. Natomiast na osi Y znajdziemy ilość Story Points lub innych, odpowiadających im jednostek, które zostały zrealizowane w danym Sprincie. Dzięki użyciu Velocity Chart, Scrum Team zyskuje wizualizację zmian w tempie swojej pracy. Jeśli linia oznaczona na wykresie się wznosi, oznacza to, że Zespół optymalizuje swą efektywność lub zmniejsza wartość Story Points. Zarówno Scrum Master jak i Product Owner powinni więc uważnie śledzić przebieg linii ukazującej prędkość Zespołu.

Velocity rzeczywista i planowana

Rzeczywista Velocity Zespołu Developerskiego opisuje tempo pracy w ukończonym Sprincie i jest obliczana na koniec każdego z nich. Przyjmuje ona wartość sumy Story Points dla wszystkich zrealizowanych User Stories. Rzeczywista prędkość Zespołu Developerskiego pozwala na planowanie i szacowanie z pewnym prawdopodobieństwem tempa realizacji przyszłych zadań.

Planowana Velocity jest natomiast szacowana na podstawie uśrednionej wartości rzeczywistej Velocity. Wymaga ona przyjęcia założenia o braku zmian w Zespole Developerskim. Jest ważnym wewnętrznym narzędziem Zespołu Developerskiego, który na jej podstawie może ocenić, czy współpraca w Zespole przebiega właściwie i czy tempo pracy zostaje zachowane.

Velocity planowana pozwala także Product Ownerowi na szacowanie czasu realizacji dobrze zdefiniowanych User Stories przewidzianych do wykonania w kolejnych Sprintach. Dzięki temu możliwa jest sprawniejsza pielęgnacja Backlogu Produktu, o której pisaliśmy w tym artykule. Jednak praktyka stosowania planowanej prędkości do szacowania długości trwania projektów nie jest tak prosta.

Trudności i zagrożenia związane z Velocity

Jest jej często przypisywane zbyt wielkie znaczenie, nie biorąc pod uwagę następujących czynników:

• szacowanie większych całości lub całego projektu– o ile Zespół Developerski jest w stanie trafnie oszacować ilość Story Points, którą należy przypisać konkretnemu zadaniu, opisanie w tych jednostkach większych całości przeznaczonych do przyszłej realizacji jest bardzo trudne lub niemożliwe
• zmiany w projekcie– każda zmiana w projekcie oznacza potencjalnie zmianę ilości Story Points niezbędnych do realizacji Celu Produktu. Może też okazać się, że już wykonane zadania będą wymagały modyfikacji lub nawet nie zostaną wykorzystane w finalnej wersji Produktu
• nieprzewidziane wydarzenia– przewidywanie tempa realizacji przyszłych projektów na podstawie tych już zrealizowanych, czyli przekładanie rzeczywistej Velocity na Planowaną, może owocować trafnymi szacunkami. Jednak każdy projekt ma swoją specyfikę i trafne przewidywanie w oparciu o historię jest zwykle niemożliwe.

Podsumowanie

Użycie Velocity jako metryki służącej do oceny skuteczności Zespołu Developerskiego może powodować, że jej wiarygodność się obniża. Może pogarszać się też jakość estymacji, o których pisaliśmy bardziej szczegółowo w tym artykule [link]. Dążąc do uzyskania jak najlepszych wyników w metrykach, Zespół Developerski może bowiem zawyżać pracochłonność zadań, po to, aby zwiększyć prędkość. Jest to szkodliwe, ponieważ sam zespół traci wtedy cenną informację pozwalającą mu dokonywać usprawnień i dokładniej planować swoje zadania.

Szacunkowa prędkość jest użyteczna przede wszystkim jako wewnętrzna miara stosowana przez Zespół Developerski do oceny tempa własnej pracy. Pozwala bowiem określić, ile zadań jest on w stanie zrealizować w czasie jednego Sprintu.

Velocity w rękach Product Ownera staje się użytecznym narzędziem pozwalającym na szacowanie terminu realizacji większych zadań.

Z największymi zagrożeniami wiąże się jednak używanie jej jako metryki służącej do oceny Zespołu Developerskiego. Może to bowiem prowadzić do obniżenia jej wiarygodności, a nawet celowego zawyżania jej wartości w celu poprawy zewnętrznej oceny pracy Scrum Team.

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.