Jak mierzyć oszacowania i punkty fabularne w Scrumie?

Question

Weźmy przykład, że mamy 5 pięter A, B i C, D, E.

Importance Name Estimate 
90   B 
70   A 
50   C 
35   E 
10   D 

Historie są uporządkowane według ich ważności (priorytet). Jak oceniasz je? Czy jest on szacowany na podstawie rozmiaru funkcji? Na przykład podałem im wartości szacunkowe:

Importance Name Estimate 
90   B  10 
70   A  12 
50   C  9 
35   E  20 
10   D  11 

Załóżmy, że jest to 2-tygodniowy sprint. Jest to 14-dniowy czas = 5,14x5 = 70 osobodni. Teraz co oznacza wartość 10? Czy to oznacza ilość czasu (godzin lub dni), jaką zespół powinien wydać? A jakie są punkty fabularne? Załóżmy, że jest to pierwszy sprint; jak oszacujesz liczbę sprintów, gdy nie masz prędkości ostatniego sprintu?

Answer 1

Argh! Odpowiada mi za pisanie z pamięci.

Punkt opowiadania związany jest z oszacowaniem kursu, a gdy próbujesz ustalić, ile możesz zrobić dla sprintu, punkt fabuły to jedna jednostka "pracy" potrzebnej do wdrożenia części lub całości funkcji . Jedna z historii może być dniem, godziną lub czymś pośrednim. Myliłem "szacunek" i "punkt fabuły" poniżej, nie wiem o czym myślałem.

To, co pierwotnie napisałem, to "szacunki" i "punkty fabularne". Co miałem zamiar napisać (i edytować poniżej) to "punkty fabularne" i "prędkość".

---

punkty historię i prędkość idzie w parze, i pracują razem, aby spróbować daje poczucie „ile możemy zakończyć w danym okresie czasu.”

Weźmy przykład.

Załóżmy, że chcesz oszacować funkcje w ciągu kilku godzin, więc funkcja, która ma szacunkową wartość 4, zajmie Ci 4 godziny, przez jedną osobę, więc przydzielisz takie oszacowanie wszystkim funkcjom. W związku z tym uznajecie tę funkcję lub jej "historię" za 4 punkty, jeśli chodzi o konkurowanie o zasoby.

Załóżmy również, że masz 4 osoby w projekcie, z których każda działa normalnie 40 godzin tygodniowo, ale z powodu innych rzeczy, które się wokół nich dzieje, takich jak wsparcie, rozmowy z marketingiem, spotkania itp., Każda osoba będzie może pracować tylko w 75% na rzeczywistych funkcjach, pozostałe 25% zostanie wykorzystane na te inne zadania.

Każda osoba ma 30 godzin dostępnych każdego tygodnia, co daje 30 * 4 = 120 godzin łącznie w tym tygodniu, gdy policzymy wszystkie 4 osoby.

Załóżmy też, że próbujesz utworzyć sprint 3 tygodni, co oznacza, że ​​możesz poświęcić 3 * 120 godzin pracy. To jest twoja prędkość, jak szybko się poruszasz, ile "punktów fabularnych" możesz ukończyć.

Jednostka twojej prędkości musi być kompatybilna z jednostką dla twoich punktów opowieści. Nie można mierzyć historii w "ile filiżanek spożyje programista podczas implementacji tego" z "ile godzin mamy do dyspozycji".

Następnie próbujesz znaleźć zestaw funkcji, które razem zajmują blisko, ale nie więcej, 120 punktów, uszeregowanych według ich priorytetów. Byłoby to po prostu sumowanie akumulacyjne od góry i od dołu, aż do osiągnięcia zadania, które przekazuje sumę równą lub równą 120 punktom. Jeśli to przechyliło, nie dołączaj zadania.

Można tak samo łatwo oszacować w dniach lub filiżanek kawy skonsumowanych przez programistę, tak jak liczba jest reprezentatywna dla rodzaju wykonywanej pracy, i może być związana z rzeczywistą pracą, którą wykonasz. (tj. ile masz czasu).

Po każdym sprincie należy również ocenić obciążenie pracą, aby ustalić, czy ten 75% numer jest prawidłowy. Na przykład, jeśli udało Ci się zarządzać tylko połowę tego, co zrobiłeś, sprawdź, czy oszacowania funkcji były nieprawidłowe lub czy oszacowania obciążenia były nieprawidłowe. Weź pod uwagę to, czego się nauczyłeś, przy szacowaniu i planowaniu następujących sprintów.

Należy również pamiętać, że funkcje powinny zostać podzielone, jeśli stają się zbyt duże. Główną przyczyną tego jest to, że większe oszacowania mają wbudowaną dużo więcej niepewności i możesz je złagodzić, dzieląc je na podfunkcje i szacując je. Wielka ogólna funkcja staje się wtedy sumą wszystkich podfunkcji. Może również umożliwić podział funkcji na kilka osób, przypisując różne funkcje podrzędne różnym osobom.

Dobrą zasadą jest, że cechy, które mają szacunkową ponad 1 dni należy prawdopodobnie podzielone. *

Answer 2

Z nowym zespołem lub projektem zawsze zaczynamy od założenia, że ​​punkt opowiadania to jeden "idealny dzień", a każdy programista otrzymuje około 3,5 idealnego dnia w tygodniu, tak jak obliczamy naszą prawdopodobną początkową prędkość.

Po przejściu przez etap "planowania pokera" i zrównoważeniu/porównaniu wszystkich swoich opowieści rzeczywisty czas trwania punktu fabularnego jest naprawdę nieznany - wszystko, co naprawdę masz, to całkiem niezły pomysł na względny trwanie i wykorzystaj swój najlepszy osąd, aby wymyślić prawdopodobną prędkość.

Przynajmniej tak to robię!

Jeśli chcesz, aby Twoja historia była mniej więcej równa ideałowi, to sugerowałbym podzielenie twoich artykułów na mniejsze historie, w przeciwnym razie nie będziesz się dobrze bawić w planowanie i śledzenie iteracji .

Answer 3

Pamiętaj, że punkty są tylko ROM (szorstki rząd wielkości) ustalone poprzez zastosowanie „Planning Poker” jako powszechna praktyka. Pierwsze kilka Sprintów rozpoczyna się, gdy zaczynasz identyfikować, co oznaczają punkty dla zespołu, a im dłużej jedziesz, tym dokładniejsza jest drużyna.

Plus należy użyć punktów, które są nieco bardziej oddalone od siebie. Praktyka, którą widziałem i używałem, to używać sekwencji fibonacci, która zapewnia, że ​​nie ma zbyt wielu różnic 1 punktu.

Nie zapominaj także o testerach, gdy wskazuje się historię, którą każdy musi wykonać, aby odważyć się na ważenie, ponieważ czasami proste zadanie programistyczne może spowodować duży wysiłek testowy, a jeśli są to prawdziwe Sprinty, to wszystko ma być wykonane tak, jak to tylko możliwe. być wysyłane (zbudowane, przetestowane i udokumentowane). Tak więc oszacowanie historii jest ustalane przez zespół, a nie przez jednostkę.

Answer 4

Dobre odpowiedzi dookoła.

Jedną z rzeczy, które chciałbym dodać, jest to, że nie jest ważne, co wybierzesz jako bazę dla wartości swoich punktów (godziny, idealne dni, cokolwiek innego). Ważne jest, aby zachować spójność.

Jeśli zachowasz spójność, pozwoli to odkryć "prawdziwą prędkość" twojego zespołu. Na przykład powiedzmy, że miał kilka iteracji:

iteration 1 = 120 points 
iteration 2 = 95 points 
iteration 3 = 115 points 

A teraz zaczynają iteracji 4 i masz następujące w portfelu (klasyfikowane na priorytet):

item 1 = 50 points 
item 2 = 30 points 
item 3 = 30 points 
item 4 = 40 points 

Teraz zakładając swoje punkty szacunków są spójne, możesz być pewien, że zespół zakończy pozycje 1,2 i prawdopodobnie 3, ale zdecydowanie nie 4.

Możesz zastosować to samo, aby uwolnić zaległości, aby poprawić prognozę daty premiery. Umożliwia to zespołom Scrum poprawianie swoich szacunków na bieżąco.

Answer 5

Wartość 10 jest jedynie wartością w stosunku do innych oszacowań, np. jest o połowę trudniejszy niż 20 lub nieco trudniejszy niż 9. Nie ma konkretnego tłumaczenia 1 punktu = x godzin wysiłku jest czymś, co należy wskazać.

Gdzie pracuję, mamy to, co nazywamy "punktami epickimi", co jest trudne w historii jakiegoś wysokiego poziomu, np. zintegrować wyszukiwarkę z nową witryną, która będzie składać się z wielu historii do ukończenia, a następnie szacujemy godziny każdej historii, która powstaje z rozbicia każdego eposu, np. po prostu włóż Szukaj w poszukiwaniu dokumentów wsparcia na stronie. "Punkty epickie" są rozmieszczone w wariancie liczb Fibonacciego (1,2,3,5,8,13,21,28,35), tak że szersze, bardziej niejasne epiki mają jedynie dużą wartość, np. cokolwiek większego niż 8, jest wskaźnikiem, że można go podzielić na łatwiejsze do oszacowania historie. Warto również zauważyć, że tam, gdzie pracuję, pracujemy tylko 5 dni w tygodniu, aw ciągu każdego sprintu tracimy dzień na spotkaniach takich jak demo, spotkanie planowania iteracji, retrospekcja i przegląd, więc jest tylko 9 dni na sprint. Dodanie programowania w parach dla niektórych rzeczy, czasu na naprawianie błędów i innych prac niezwiązanych z projektem, takich jak bilety na wsparcie, i trudno jest powiedzieć, ile godzin będzie spędzać garstka programistów w sprintu.

Pierwsze kilka sprintów to miejsca, w których wartości zaczynają stawać się coraz bardziej konkretne, ponieważ w oparciu o zdobyte doświadczenie, prognozy mogą stać się bardziej przejrzyste pod względem sposobu odgadnięcia wartości.

Answer 6

JB King ma najlepszą odpowiedź, ale nie ma głosów, co oznacza, że ​​propaguje się niepoprawne informacje i przyczynia się do ogólnie niskiej interpretacji scrum. Proszę zobaczyć prawdziwą odpowiedź od jednego z ludzi, którzy zaprojektowali Scrum tutaj:

http://blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

Pamiętaj, chodzi o wysiłek, nie złożoność.

Teraz przeczytać i obejrzeć film tutaj:

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points