Velocity

Velocity
Polecane artykuły
Estymacja czasu trwania zadań Planowanie sprintu Backlog sprintu Kamień milowy Zarządzanie czasem Zasada SMART Backlog produktu Sprint Szacowanie czasu trwania zadań

Velocity reprezentuje ilość pracy wykonanej w każdym sprincie, wyrażona w Story Points. Planowana velocity zostaje oszacowana przez Zespół Scrumowy na początku każdego Sprintu, a User stories zostały przypisane do Sprintu, tak aby suma Story Points mieściła się w ramach zdolności określonej przez oszacowanie velocity. Rzeczywista prędkość została obliczona na końcu Sprintu, podsumowując Story Points dla wszystkich User Stories, zaakceptowanych przez Product Ownera. Planowaną velocity należy oszacować biorąc pod uwagę rzeczywistą prędkość poprzednich Sprintów przy umowie braku żadnych zmian w zespole programistycznym w ciągu projektu [Mahnic V., Zabkar N. 2012, s. 2].

TL;DR

Velocity to miara ilości pracy wykonanej w każdym Sprint sprincie, wyrażona w Story Points. Jest obliczana na podstawie oszacowanej prędkości i rzeczywistej prędkości z poprzednich Sprintów. Velocity jest używane do alokacji zasobów, koordynacji działań i komunikacji w zespole. Planowanie oparte na velocity zakłada, że zespół będzie wykonywał podobną ilość pracy w kolejnych Sprintach. Etapy velocity-driven planningu obejmują ustalenie średniej velocity, wybór liczby zadań z backlogu i oszacowanie pracy.

Istota Velocity

Velocity mierzy jak szybko zespół wykonuje pracę przypisaną w danym czasie (zazwyczaj sprint lub iteracja). Z biegiem czasu zespoły osiągają lepsze wyniki, prędkość rośnie, a następnie normalizuje się w kierunku stałej szybkości. Z powodu tego trendu jednym ze sposobów mierzenia dojrzałości zespołu jest mierzenie zmienności prędkości od jednego sprintu do następnego [ScrumHub 2014].

Podstawowa Velocity (100%) ustalana jest dla zespołu podczas pierwszego sprintu. Product Owner przedstawia priorytetyzowany backlog na spotkaniu planowania sprintu. Szacuje się to za pomocą Planning poker i Story Pointów. Zespół wybiera, co można osiągnąć podczas sprintu, a Product Owner określa dokładnie, co jest "Gotowe" na końcu Sprintu. Suma oryginalnych szacunków dla zatwierdzonych tasków to wyjściowa velocity.

Velocity definiuje się jako: V = Σ oryginalnych oszacowań wszystkich przyjętych prac (tasków) [Sutherland J., Downey S. 2012, s. 2].

Dokładne śledzenie nieplanowanej pracy jest niezbędne do wykrywania i usuwania marnotrawstwa w zespole. Sprint może być uznany za skuteczny, jeśli przynajmniej 80% pierwotnego zobowiązania zostało zatwierdzone przez Product Ownera, a łączna praca nieplanowana pozostaje na poziomie 20% lub mniej pierwotnego zobowiązania [Sutherland J., Downey S. 2012, s. 6].

Uzasadnienie wykorzystania Velocity

• Pierwszym przykładem decyzji opartej na szacunkach jest alokacja zasobów. Pieniędzy i ludzie w większości mają ograniczenia lub ustaloną kwotę, zwykle jest zbyt wiele wartościowych rzeczy do zrobienia.

Ludzie muszą podejmować decyzje robienia jednej czy innej czynności. W podjęciu takiej decyzji warto wiedzieć, ile wysiłku (i kosztu) każda z nich będzie dotyczyła.

• Innym przykładem jest pomoc w koordynacji. Pierwszy zespół chce zaimplementować nową funkcję na swojej stronie internetowej, ale nie może tego zrobić, dopóki drugi zespół nie zbuduje nowego servisu, aby dać im kluczowe dane.

Jeśli drugi zespół szacuje, że zostaną wykonane za dwa miesiące, a zespół perwszy szacuje, że zbudowanie tej funkcji zajmie im miesiąc, to pierwszy zespół wie, że nie warto zaczynać dzisiaj i oni mogą spędzić co najmniej miesiąc pracując nad inną funkcją, która może zostać wydana wcześniej.

Przy każdym zapytaniu o oszacowanie, musimy zawsze wyjaśnić, jaką decyzję podaje to oszacowanie. Jeśli nie możemy go znaleźć, lub decyzja nie jest zbyt znacząca, jest to sygnał, że oszacowanie jest marnotrawstwem. Powinniśmy również wyjaśnić pożądaną precyzję i dokładność.

• Wiele zespołów uważa, że oszacowanie stanowi przydatną funkcję wymuszenia, aby członkowie zespołu mogli ze sobą komunikować.

Spotkania szacunkowe mogą pomóc w lepszym zrozumieniu różnych sposobów implementacji nadchodzących User Stories, przyszłych kierunków architektury i problemów bazie kodu. W takim przypadku wszelkie wartości szacunkowe mogą być nieistotne [Fowler M. 2013, s 6-7].

Velocity-driven planning

Velocity-driven planning opiera się na założeniu, że ilość pracy, którą zespół może wykonać w nadchodzącym sprintcie jest w przybliżeniu równa tej, co zostala zrobiona w poprzednich sprintach. Zakłada to, rzeczy takie jak stały rozmiar zespołu, praca zespołu jest podobną pracą od sprintu do sprintu, sprinty stałych długości.

Etapy velocity-driven planning sprintu są następujące:

1. Ustalenie historycznej średniej velocity zespołu.
2. Wybór liczby pozycji backlogu produktu równą tej velocity. Niektóre zespoły tam się zatrzymują. Inne obejmują dodatkowy krok:
3. Zidentyfikowanie zadań związanych z wybranymi User Stories i sprawdzenie, czy jest to odpowiednią ilością pracy. Niektóre zespoły pójdą jeszcze dalej i dokonują:
4. Oszacowanie zadań i sprawdzenie, czy suma prac jest zgodna z przeszłymi sprintami [Cohn M. 2014].

Bibliografia

• Cohn M., (2014) Velocity-Driven Sprint Planning
• Fowler M., (2013) Twebook perspectives estimation, ThoughtWorks
• Mahnic V., Zabkar N., (2012) Measuring Progress of Scrum-based Software Projects, University of Ljubljana
• ScrumHub, (2014) Implementing Scrum Guide, Axosoft
• Sutherland J., Downey S., (2012) Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft

Autor: Serhiienko Maiia