Velocity: Różnice pomiędzy wersjami
m (Dodanie TL;DR) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 13 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''Velocity''' reprezentuje ilość pracy wykonanej w każdym [[Sprint|sprincie]], wyrażona w Story Points. | '''Velocity''' reprezentuje ilość pracy wykonanej w każdym [[Sprint|sprincie]], wyrażona w Story Points. | ||
Planowana velocity zostaje oszacowana przez [[Zespół projektowy|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. | Planowana velocity zostaje oszacowana przez [[Zespół projektowy|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 owner|Product Ownera]]. | Rzeczywista prędkość została obliczona na końcu Sprintu, podsumowując Story Points dla wszystkich User Stories, zaakceptowanych przez [[Product owner|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 | 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. | ||
==TL;DR== | ==TL;DR== | ||
| Linia 25: | Linia 8: | ||
==Istota Velocity== | ==Istota Velocity== | ||
Velocity mierzy jak szybko [[zespół]] wykonuje pracę przypisaną w danym czasie (zazwyczaj sprint lub [[iteracja]]). | 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 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]. | 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. | 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. | 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. | 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]. | 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 [[Zespół projektowy|zespole]]. Sprint może być uznany za skuteczny, jeśli przynajmniej 80% pierwotnego [[zobowiązania]] zostało zatwierdzone przez | Dokładne śledzenie nieplanowanej pracy jest niezbędne do wykrywania i usuwania marnotrawstwa w [[Zespół projektowy|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]. | Product Ownera, a łączna [[praca]] nieplanowana pozostaje na poziomie 20% lub mniej pierwotnego zobowiązania [Sutherland J., Downey S. 2012, s. 6]. | ||
<google>n</google> | |||
==Uzasadnienie wykorzystania Velocity== | ==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. | * 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. | 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 | * 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 serwisu, aby dać im kluczowe [[dane]]. | ||
Jeśli drugi zespół szacuje, że zostaną wykonane za dwa miesiące, a zespół | Jeśli drugi zespół szacuje, że zostaną wykonane za dwa miesiące, a zespół pierwszy 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. | 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ść]]. | 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ć'''. | * 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]. | 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== | ||
Velocity-driven planning opiera się na założeniu, że ilość pracy, którą zespół może wykonać w nadchodzącym | Velocity-driven planning opiera się na założeniu, że ilość pracy, którą zespół może wykonać w nadchodzącym sprincie jest w przybliżeniu równa tej, co została 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. | 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: | Etapy velocity-driven planning sprintu są następujące: | ||
| Linia 59: | Linia 43: | ||
# 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ą: | # 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ą: | ||
# Oszacowanie zadań i sprawdzenie, czy suma prac jest zgodna z przeszłymi sprintami [Cohn M. 2014]. | # Oszacowanie zadań i sprawdzenie, czy suma prac jest zgodna z przeszłymi sprintami [Cohn M. 2014]. | ||
{{infobox5|list1={{i5link|a=[[Estymacja czasu trwania zadań]]}} — {{i5link|a=[[Planowanie sprintu]]}} — {{i5link|a=[[Backlog sprintu]]}} — {{i5link|a=[[Kamień milowy]]}} — {{i5link|a=[[Zarządzanie czasem]]}} — {{i5link|a=[[Zasada SMART]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[Sprint]]}} — {{i5link|a=[[Szacowanie czasu trwania zadań]]}} — {{i5link|a=[[Bony podarunkowe]]}} }} | |||
==Bibliografia== | ==Bibliografia== | ||
* Cohn M. | <noautolinks> | ||
* Fowler M. | * Cohn M. (2014), ''[https://www.mountaingoatsoftware.com/blog/velocity-driven-sprint-planning Velocity-Driven Sprint Planning]'' | ||
* Fowler M. (2013), ''[https://info.thoughtworks.com/rs/thoughtworks2/images/twebook-perspectives-estimation_1.pdf Twebook perspectives estimation]'', ThoughtWorks | |||
* ScrumHub | * ScrumHub (2014), ''Implementing Scrum Guide'', Axosoft | ||
* Sutherland J., Downey S. | * Sutherland J., Downey S. (2012), ''[https://www.agilealliance.org/wp-content/uploads/2016/01/ScrumMetricsAgile2012.pdf Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft]'' | ||
</noautolinks> | |||
{{a|Serhiienko Maiia}} | {{a|Serhiienko Maiia}} | ||
[[Kategoria:Harmonogramowanie]] | |||
{{#metamaster:description|Velocity to wskaźnik pracy w każdym Sprint sprincie, wyrażony w Story Points. Oszacowywany przez Zespół Scrumowy i uwzględnia zdolność. Rzeczywista prędkość jest obliczana na końcu Sprintu, uwzględniając zaakceptowane Story Points. Planowana velocity powinna uwzględniać prędkość poprzednich Sprintów.}} | |||
Aktualna wersja na dzień 19:36, 18 sty 2024
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.
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 serwisu, aby dać im kluczowe dane.
Jeśli drugi zespół szacuje, że zostaną wykonane za dwa miesiące, a zespół pierwszy 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 sprincie jest w przybliżeniu równa tej, co została 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:
- Ustalenie historycznej średniej velocity zespołu.
- Wybór liczby pozycji backlogu produktu równą tej velocity. Niektóre zespoły tam się zatrzymują. Inne obejmują dodatkowy krok:
- 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ą:
- Oszacowanie zadań i sprawdzenie, czy suma prac jest zgodna z przeszłymi sprintami [Cohn M. 2014].
| Velocity — artykuły polecane |
| Estymacja czasu trwania zadań — Planowanie sprintu — Backlog sprintu — Kamień milowy — Zarządzanie czasem — Zasada SMART — Backlog produktu — Sprint — Szacowanie czasu trwania zadań — Bony podarunkowe |
Bibliografia
- Cohn M. (2014), Velocity-Driven Sprint Planning
- Fowler M. (2013), Twebook perspectives estimation, ThoughtWorks
- 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
