Velocity - 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:

Wprowadzenie
Velocity rzeczywista i planowana
Trudno艣ci i zagro偶enia zwi膮zane z Velocity
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 in scrum - speed of the development team

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偶:

Autor: Karolina Berecka
Karolina, jako project menad偶erka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przep艂ywu pracy i optymalizacji proces贸w. Jej umiej臋tno艣ci organizacyjne i zdolno艣膰 do pracy pod presj膮 czasu sprawiaj膮, 偶e jest najlepsz膮 osob膮 do zamieniania skomplikowanych projekt贸w w rzeczywisto艣膰.

Zobacz wszystkie posty

凯发k8旗舰厅

Przerwa konserwacyjna

Scrum Guide | 34. Pr臋dko艣膰 Zespo艂u Deweloperskiego