Dlaczego używamy punktów historii zamiast osobodni przy szacowaniu historii użytkowników?


132

W metodologiach zwinnych (np. SCRUM) złożoność / wysiłek wymagany w przypadku opowieści użytkowników są mierzone w punktach opowieści. Punkty historii są używane do obliczania liczby historii użytkowników, które zespół może pobrać podczas iteracji.

Jaka jest zaleta wprowadzenia abstrakcyjnej koncepcji (punktów fabularnych), w której możemy po prostu użyć konkretnego pomiaru, na przykład szacowanej liczby osobodni? Możemy również obliczyć prędkość, oszacować zasięg iteracji itp., Używając szacowanych osobodni.

Natomiast punkty historii są trudniejsze w użyciu (ponieważ koncepcja jest abstrakcyjna), a także trudniejsze do wyjaśnienia interesariuszom. Jaką korzyść oferuje?


16
dlaczego zakładacie, że dzień ludzki jest bardziej konkretny niż punkt fabularny, nie jest.
Ryathal

4
Czy łatwiej jest wytłumaczyć, że oszacowanie 5 osobodni oznacza, że ​​wypełnienie zajmie 1 miesiąc, ponieważ twoja prędkość wynosi 0,25 osobodni / dzień kalendarzowy?
Patrick,

3
@Izkata jest to prawdą tylko wtedy, gdy prędkość zawsze wynosi dokładnie 1
Patrick

4
@Patrick Podczas korzystania osobodni (patrz roboczogodzin Wikipedia), nie ma pojęcia prędkości. To jest sprawność / zwinność.
Izkata,

3
Interesujące jest to, że gdy tylko prędkość się ustabilizuje, punkty historii zwykle identyfikowane są z określoną liczbą godzin lub dni. Np. 1 punkt opowieści = 1 dzień. Jeśli myślę, że zajmie to 2 dni, oszacuję 2 punkty historii.
Giorgio

Odpowiedzi:


126

Myślę, że jedną z głównych zalet jest to, że ludzie i programiści faktycznie źle oceniają czas. Pomyśl też o naturze rozwoju - nie jest to żaden liniowy postęp od początku do końca. Często „pisze 90% kodu w 10 minut, a następnie odrywa włosy z debugowania przez 17 godzin”. Trudno to oszacować w sensie taktowania zegara.

Ale użycie abstrakcji odwraca uwagę od faktycznego czasu w godzinach lub dniach i zamiast tego kładzie nacisk na opisanie względnego kosztu i złożoności zadania w porównaniu do innych zadań. Ludzie / deweloperzy są w tym lepsi. A potem, gdy zaczniesz nucić te szacunki punktowe i pewne rzeczywiste postępy, możesz zacząć patrzeć na czas bardziej empirycznie.

Podejrzewam, że istnieje również efekt obserwatora, który występuje w przypadku oszacowań czasu, który nie miałby miejsca w przypadku oszacowań punktowych. Na przykład bodziec do oszacowania worka z piaskiem i dostarczenia sposobu „przed terminem” zostanie wyciszony w sposób pośredni w systemie punktowym.


28
+1 za skupienie się na złożoności , a nie na czasie. Przełożenie na godziny surowe będzie łatwe, gdy będziesz mieć wystarczająco dużo sprintu za pasem. Odkryłem, że zmienność między historiami z czasem się zaciera.
Kristo,

14
Tak naprawdę punkty złożoności mogą być bardziej zrozumiałym terminem niż punkty fabularne, a każde zadanie o zbyt wielu punktach złożoności jest zbyt złożone i prawdopodobnie wiąże się ze zbyt dużym ryzykiem i niewiadomymi, aby poradzić sobie z nimi za jednym razem. Złożoność ma koszt wykładniczy, a biedny drań, który utknie w tym zadaniu, wykopie dziurę tak głęboko, że nie zobaczy go ponownie przez tygodnie lub miesiące. Lepiej uczyń prostszym zadaniem najpierw zrozumienie złożonego zadania i podzielenie go na mniejsze zadania o mniej ryzykownej i lepiej zrozumianej złożoności.
Supr

4
Czas i koszty są skutkami, przyczyną jest złożoność, a nie można zrozumieć czasu bez zrozumienia złożoności.
Supr

8
Punkty historii = Punkty złożoności - 2 sylaby. :-D
Kristo

5
Czy ktoś kiedykolwiek rozważał nazywanie punktów historii „kosztami rzucania”? => nerd
Aaron Gibralter

59

Jeśli używasz liczb Fibonacciego (lub czegoś podobnego), ogranicza to liczbę opcji podczas szacowania historii. Współpracowałem z grupą, która używała tylko niskich liczb: 1, 2, 3, 5, 8 i 13. Mieliśmy referencyjną historię, która była 5. To pozwoliło nam łatwo podejmować szybkie decyzje dotyczące złożoności historii podczas planowania pokera . Innym skutkiem ubocznym było to, że wszystko, co oceniono na 13, prawdopodobnie nie miało wystarczających informacji i wymagało dalszego podziału. Poważnie wątpię, czy byłoby tak łatwo i prosto, gdybyśmy wykorzystali godziny surowe.

Właściciel produktu mówi w języku interesariuszy i powinien być w stanie tłumaczyć między punktami fabularnymi a roboczogodzinami (lub innymi jednostkami) w razie potrzeby. Podczas mojej pracy jako PO miałem twarde dane, że 1 punkt historii = 4 roboczogodziny, ale oczywiście każda drużyna jest inna.

Edytować:

Wiedząc, że 1 punkt = 4 godziny, teoretycznie możesz zmienić swoją talię Planning Poker na 4, 8, 12, 20, 32 i 52. Ale z tymi liczbami trudniej sobie poradzić. Myślę, że mentalnie abstrahowałbym wartości z powrotem do czegoś prostego, np. „Mniej niż dzień”, „więcej niż tydzień” itp. A jeśli to zrobię, równie dobrze mogę pozostać przy jednostce abstrakcyjnej bez punktów fabularnych.


Używamy tej samej metody, a nasza talia planowania ma wyższe liczby, ale zdefiniowaliśmy liczbę 20, co oznacza, że ​​należy ją rozbić lub zdefiniować lepiej. Dla nas 13 jest naszym największym zadaniem i zwykle są to zadania, które kończą się nawet tydzień.
Bill Leeper

„Innym efektem ubocznym było to, że wszystko, co oceniono na 13, prawdopodobnie nie miało wystarczających informacji i wymagało dalszego podziału”. I zakładam, że jeśli zostanie podzielony dalej, zostanie podzielony na równoważne części Fibonacciego?
Joe Z.

@JoeZeng, tak, ci często stawali się 8 + 5 lub 5 + 5 + 3. Jest to jednak pomiar abstrakcyjny, więc jeśli nowe historie są wystarczająco blisko, nie martwiłem się zbytnio. Zespół normalnie mógł wchłonąć 13, stając się dwoma 8 lub 3 5, ale trzy 8 oznaczały, że musiałem przeprowadzić wyjaśniającą rozmowę z interesariuszami. Idealnie, oszacowaliśmy wystarczająco wcześnie, że nie wpłynie to na bieżący sprint.
Kristo,

1
Niekoniecznie. Przyjęliśmy założenia, że ​​opowieści mają 5 punktów, a bardziej szczegółowa, podzielona suma zawiera się w przedziale 15 punktów. Zdarza się.
prochy999

24

Ma to umożliwić lepsze oszacowanie w czasie, bez konieczności dostosowywania oszacowań przez estymatory.

Bardziej niż wszyscy zaangażowani w oszacowanie konieczności myślenia w stylu „OK .. wygląda jak 2 osobodni .. ale w ostatnim sprincie nie doceniliśmy wszystkiego, więc może to naprawdę 2,5 osobodni. Lub 3?”, Kontynuują tak samo jak zawsze. „5 punktów historii!”

Następnie dostosowujesz swoje oszacowanie, ile punktów historii można pokonać w sprincie, na podstawie rzeczywistych wyników osiągniętych w poprzednich sprintach. „Wcześniej robiliśmy 90-110 punktów historii na sprint!”

Powiedziałbym, że kryje się za tym teoria, że ​​programiści lepiej oceniają względną złożoność różnych zadań deweloperskich niż szacunki absolutne . Zwłaszcza jeśli wiele osób ocenia zadanie, które może wykonać jedna z nich (i nie wszyscy pracują z taką samą prędkością jak wszyscy inni).

Cyniczna alternatywa: widziałem, że programiści nigdy nie przychodzą na czas. Jeśli coś trwa dłużej, niż przewidywano, przeszedłeś. Ale jeśli coś zajmuje mniej czasu, niż się szacuje, programiści mogą się nim bawić, złocić płytkę lub po prostu zwolnić i uspokoić się, ponieważ przydzielono im wygodne zadanie. Usunięcie rzeczywistych jednostek czasu z oszacowania może ograniczyć te tendencje. Koniec cynicznej alternatywy.


13
To nawet nie takie cyniczne. Jest to zasada „szybka, tania lub dobra”. Mogę dać ci w większości stabilną, przeważnie działającą wersję FizzBuzz, która da ci to, czego ogólnie chcesz w ciągu kilku minut, ale jeśli chcesz interakcji z użytkownikiem, potrwa to dłużej, a jeśli chcesz przetestować regresję, zajmie to dłużej, a jeśli chcesz, aby nie zawiodło się po naciśnięciu MAX_INT, potrwa to dłużej. Powiedz mi, że priorytetem jest prędkość, a zacznę wyrzucać wymagania. Powiedz mi, abym nadał priorytet wszystkim pozostałym, a ja wykorzystam cały czas, jaki otrzymam.
deworde

17

Ludzkie dni lub osobogodziny są, jak mówisz, konkretne. Tak więc, kiedy zadanie jest szacowane na 5 godzin i zajmuje 6, jest to teraz zadanie opóźnione.

Kiedy masz historię, która ma 3 punkty i zajmuje 6 godzin, zajęła 6 godzin, nie jest późno, tylko sześć godzin. Pomiar prędkości jest bardziej zależny od tego, ile punktów wykonasz podczas sprintu, a liczba ta może się zmieniać, ponieważ nie jest konkretna. Nie mierzysz także każdego zadania, ale sumę wszystkich zadań. Kiedy masz godziny na każde zadanie, pojawia się pokusa, aby zmierzyć każde zadanie. Kiedy tak się dzieje, nie masz żadnych korzyści z sprintu za ukończenie z czasem i jest to konsekwencją ukończenia w czasie danego zadania.

Może to być przejście do myślenia w kategoriach punktów. W jednym miejscu pracowałem, zanim wprowadziliśmy zwinne rozmiary używanych koszulek, aby uzyskać pomysł na poziom wysiłku. Punkty są tylko przedłużeniem tego.

Nie oznacza to, że nie ma kontrowersji ani żadnego arbitralnego przypisania do punktów. Mamy członków naszego zespołu, którzy prawie zawsze głosują na najniższą liczbę, i narzekają, gdy myślą, że zadanie to 1, a naszym zdaniem to 3, że cierpimy z powodu inflacji punktowej.


13

Abstrakcja jest w pewnym sensie istotna. Użycie „dnia człowieka” jako pomiaru wiąże się z wieloma pułapkami, w tym:

  1. Jeśli zespół nie zna technologii, której będzie używać, może być naprawdę trudno oszacować w czasie rzeczywistym, ile czasu może zająć zadanie. Są znacznie bardziej prawdopodobne, że będą w stanie podać dobre szacunki względne - np. „Zadanie A zajmie prawdopodobnie dwa razy więcej czasu niż zadanie B”.
  2. Różni ludzie pracują w różnym tempie! Jeśli używasz „dni roboczych”, musisz zmienić szacunkowy czas, gdy zadanie jest przekazywane od jednego programisty do drugiego. Kto określa, ile pracy stanowi „dzień człowieka”?

Jeśli chcesz oszacować osobodni, jest to prosta kalkulacja:

user points in story / average user points per developer per day = estimated man days

Odnośnie do punktu 2: w jaki sposób rozwiązuje to punkt fabuły? Opowiadasz historię jako 4 punkty opowieści. Dajesz go szybszemu programistowi i zajmuje to 4 dni. Dajesz go powolnemu programatorowi i zajmuje to 8 dni. Wydaje mi się, że problem nie został rozwiązany, ale został przeniesiony.
Giorgio

Odnośnie do punktu 1. Pomysł polega na tym, że jeśli zespół zapozna się z technologiami potrzebnymi do projektu, jego prędkość wzrośnie, a względna wielkość opowieści mierzona w punktach opowieści pozostanie taka sama. Ale co jeśli dwie historie użytkowników wymagają innej wiedzy? Np. Masz front-endową historię użytkownika do zrobienia w JavaScript / HTML i back-endową historię użytkownika do zrobienia w Javie. Gdy zespół dowiaduje się więcej o JavaScript, HTML i Javie, dowiaduje się, że część front-end jest o wiele łatwiejsza niż część back-end, a względne oceny historii są znowu błędne.
Giorgio

@Giorgio Re. punkt 2: Twój szybszy programista ma szybkość pracy 1 punkt historii / dzień, a twój wolniejszy programista ma szybkość pracy 0,5 punktu historii / dzień. Jeśli zrobisz to w ciągu kilku godzin, albo twój szybszy programista sam będzie pracował na śmierć, albo twój wolniejszy programista będzie zwolniony. Odpowiedź Billa Leepera bardzo dobrze to potwierdza.
vaughandroid

1
Re. punkt 1: Za moje pieniądze, jeśli mówisz o 2 różnych zestawach technologii i 2 różnych obszarach produktu, masz dwa zespoły.
vaughandroid

Dalsze informacje punkt 2: Historie użytkowników opracowuje zespół , a nie indywidualni programiści. Ważna jest szybkość pracy zespołu. Pamiętaj, że wdrażając historie użytkowników, najpierw powinieneś podzielić je na zadania. Daj szybszemu programistowi więcej zadań!
vaughandroid

6

Jak już wspomniano, punkty fabularne są względną miarą złożoności. Do oszacowania można użyć mocy 2 serii (1,2,4,8,16 ...) lub skali Fibonacciego (1,2,3,5,8,13,20 ...). Jak sugerują programiści, są biegli w mówieniu czegoś takiego:

Funkcja A jest prawie dwa razy trudniejsza niż funkcja B

Ale naprawdę trudno powiedzieć „jak długo” zajmie ta funkcja do wdrożenia. Pozwól temu zrównoważyć prędkość. Więc jeśli coś zostało oszacowane na 5, ale okazało się, że jest 13, wolniejsza prędkość znormalizowałaby to dla iteracji (lub można by to ponownie oszacować).

Jest jeszcze jedna alternatywa, nazywa się ją „dniami idealnymi” (niektóre są podobne do dni roboczych, ale nie jestem pewien, czy to miałeś na myśli) i znam sporo zespołów, które to preferują. Dni idealne należy interpretować jako:

Jeśli to wszystko, co robię po przybyciu do biura i robię tylko niezbędne przerwy, nie mam żadnych przerw i będę miał wszystko, czego potrzebuję do „zaimplementowania historii”, tj. Żadnych działań peryferyjnych, takich jak spotkania, odpowiadanie na maile itp.

Mike Cohn, jeden z wielu dobrze znanych zwinnych ewangelistów, przedstawia następujące porównanie punktów fabularnych i dni idealnych

Punkty opowieści

  • Pomaga w kierowaniu zachowaniami międzyfunkcyjnymi, tj. Zespoły oceniają historie od całkowitej złożoności implementacji od interfejsu użytkownika do bazy danych i odwrotnie.
  • Oszacowania SP nie ulegają rozpadowi, tj. Za kilka miesięcy 5-punktowa historia prawdopodobnie będzie wynosić 5 punktów, ale idealne oszacowanie dnia może się zmienić w zależności od nabytych umiejętności / szybkości programowania danego programisty
  • SP są czystą miarą wielkości, tzn. Tylko odzwierciedlają złożoność wielkości w stosunku do wielkości. Kropka. Bez czasu trwania itp., Wyrzuć to. To jest zadanie prędkości. Ale nie w idealnych dniach. W rzeczywistości przy idealnych dniach istnieje tendencja do mylenia go z dniami kalendarzowymi. Utrzymywanie abstrakcyjności, ponieważ SP walczy z pokusą porównania z rzeczywistością. Po prostu miara wielkości. Bez bzdur.
  • Zazwyczaj jest szybszy niż idealne dni. Może to być trudne w przypadku pierwszych kilku opowiadań, ale gdy już to zrozumiesz, będzie szybciej.
  • Różni programiści mogą inaczej oceniać swój idealny dzień na ukończenie historii. Mógłbym zrobić to samo w 3, a ty w 5. PZ są mniej więcej jednolite na całej planszy. Można powiedzieć, że wyrównują szanse.

Idealne dni

  • Łatwiej wyjaśnić poza zespołem; z oczywistych powodów :)
  • Łatwiej jest to oszacować na początku, jak wspomniano powyżej. Ale kiedy zrozumiesz SP, przychodzi to naturalnie

Teraz wybór należy do zespołu. Jednak, ponieważ większość odpowiedzi tutaj i moje osobiste doświadczenia, wolę punkty historii. Idealne dni tak naprawdę nie mają tak dużej przewagi nad SP (a Mike Cohn opowiada się również za SP wraz z wieloma innymi zwinnymi ewangelistami).


Następny numer Fibonacciego to 21, a nie 20.
Joe Z.

4
21 lub 20 nie ma znaczenia przy szacowaniu. SP zaokrąglają kolejną liczbę Fibonacciego, aby wyeliminować poczucie fałszywej precyzji. Następna liczba w sekwencji to nie 34, ale 40 (podwójnie 20), a następnie 100. Liczby reprezentują „niepewność” w złożoności, a nie precyzji. To tylko przybliżenie.
dr

1
To prawda, właśnie zbierałem gnidy (i żartowałem).
Joe Z.

1
@PhD: „Oszacowania SP nie zanikają, tzn. Za kilka miesięcy 5-punktowa historia prawdopodobnie będzie wynosiła 5 punktów, ale idealny szacunek dnia może się zmienić w zależności od nabytych umiejętności / szybkości programowania danego programisty”: domyślnie zakłada, że ​​zespół jednolicie poprawi swoje umiejętności we wszystkich obszarach projektu. Nie rozumiem, dlaczego tak zawsze powinno być: niektóre części projektu (i wymagane dla nich technologie) mogą okazać się trudniejsze niż inne, co uniemożliwia wstępne oszacowanie względnej złożoności punktów fabularnych.
Giorgio

3

Punkty fabularne pomagają również mierzyć poprawę wydajności zespołu w czasie. Ponadto nie trzeba ponownie szacować wszystkiego, ponieważ poprawia się wydajność.

Weź ten przykład, który używa dni roboczych:

Zespół ocenia różne zadania na osobodni. To działa przez jakiś czas, ale po pewnym czasie widać, że zespół wykonuje wiele zadań szybciej niż pierwotnie sądzono. Zespół dokonuje ponownej oceny zadań. To działa przez jakiś czas, a po pewnym czasie znów widzisz to samo: zespół jest wykonywany szybciej z wieloma zadaniami. Więc ponowne oszacowanie znowu, i ta historia powtarza się znowu, i znowu, i znowu ...

Dlaczego? Ponieważ wydajność twojego zespołu wzrosła. Ale nie wiesz o tym.

Ten sam przykład z punktami fabularnymi:

Zespół ocenia rozmiar historii użytkowników. Po kilku sprintach widać, że zespół może wykonać około 60 punktów historii na sprint. Później widać, że zespół osiągnął ponad 60 punktów historii, może 70. Zespół kontynuuje w ten sposób i wyciąga kolejne historie użytkowników na kolejne sprinty i dostarcza je.

Dlaczego? Ponieważ wydajność wzrosła. I możesz to zmierzyć. Nie musisz ponownie oceniać wszystkiego po zwiększeniu wydajności swojego zespołu.


3
„Dlaczego? Ponieważ wydajność twojego zespołu wzrosła.”: Alternatywne wytłumaczenie jest takie, że po pewnym czasie zespół zaczyna podawać dokładniejsze / realistyczne szacunki czasu (ponieważ spóźnili się z niektórymi zadaniami w poprzednich sprintach, zaczynają poświęcać więcej czasu, gdy szacowanie historii na późniejsze sprinty).
Giorgio

2

Po pierwsze, ludzie są lepsi w szacunkach względnych niż szacunkach bezwzględnych. Babilończycy mapujący i oceniający względną jasność gwiazd to świetny przykład. Nie uzyskali prawidłowych liczb bezwzględnych, ale kolejność była w większości sprecyzowana nawet przy bardzo podobnych natężeniach.

Drugą zaletą jest to, że głównym powodem wykonywania tego ćwiczenia jest prowadzenie rozmowy. Jeśli zaczniesz dyskutować dokładnie w dniach, rozmowa może szybko się wykoleić.

Jak powiedział Napoleon: plan jest bezwartościowy, planowanie jest bezcenne.

Po trzecie, kierownik projektu nie musi edytować wszystkich oszacowań, tylko dlatego, że okazuje się, że oszacowania były pomniejszone np. O 130%.


0

Punkty fabularne odzwierciedlają złożoność problemu, a zatem odzwierciedlają pewność (lub ryzyko) dokładności oszacowania.

Historia z wysokim punktem historii mówi mi, że wiele dzieje się z historią użytkownika, która nie jest konkretna.

Chodzi o to, aby zobaczyć, jaka jest równowaga różnych punktów historii. Jeśli pokazano mi plan iteracji z opowieściami ze wszystkimi wysokimi punktami historii, nie daje mi to pewności, że iteracja zostanie wykonana zgodnie z oczekiwaniami i że musimy spojrzeć na inne historie dla iteracji lub zacząć opowiadać historie.

Podczas komunikowania się z menedżerem lub właścicielem produktu wysokie punkty fabularne oznaczają, że będzie bardzo niewyraźnie, kiedy otrzymają określoną funkcję. Jednym z rozwiązań jest rozbicie historii i, mam nadzieję, będziesz mieć kombinację niskich i wysokich punktów historii do pracy, dzięki czemu będziesz mógł iteracyjnie demonstrować postępy właścicielowi produktu.


0

Ludzkie dni szacują czas potrzebny na zrobienie czegoś. Są one najlepiej stosowane, gdy szacowane elementy są bardzo precyzyjne i mierzalne. Określone, dobrze znane, powtarzalne zadania można oszacować za osobodni.

Na przykład, jeśli sprzedawca może wykonać średnio 20 połączeń z klientami dziennie, możemy obliczyć, ile czasu zajmuje każde połączenie, i na tej podstawie możemy oszacować, ile osobodni zajmie wykonanie 1000 połączeń.

W tym przykładzie można konkretnie myśleć statystycznie o medianie długości połączenia, ponieważ można założyć, że wszystkie połączenia są faktycznie takie same.

Punkty opowieści określają, którą kombinację opowieści można wykonać w iteracji. Służą do łączenia niejednorodnych celów z rozmytymi granicami i do mierzenia, ile można zrobić w ustalonych ramach czasowych. Szacują złożoność kawałków pracy w porównaniu do siebie , aby móc je połączyć.

Na przykład twój zespół opracował 5 opowieści za łączną liczbę 23 punktów w iteracji 1 i 8 opowieści za 20 punktów w iteracji 2. Na tej podstawie możesz oszacować, że w trakcie iteracji dwa Twoje zespoły wykonają kilka opowieści, których łączna suma wynosi około 20 punktów w iteracji 3.

Pamiętaj, że nie musimy określać wielkości jednego punktu, a w szczególności nie ma założenia, że ​​opracowanie każdej historii o tym samym rozmiarze zajmie tyle samo czasu! Pracujemy tylko na sumach i punktach na iterację. Nie wspomniałem nawet o tym, jak długo trwa iteracja.


0

Jeśli podchodzisz do człowieka na ulicy i pytasz „Jak duży był T-rex?” odpowiedzi zmieniałyby się, mimo że większość ludzi wie, co to jest T-rex, jak duży był tego rodzaju, ale nikt tak naprawdę nie ma pewności - ponieważ nie mamy ŻADNEJ skali względnej do linii odniesienia.

To jest zachowanie poznawcze, które próbujesz zrozumieć dzięki prognozowaniu, a wiele metodologii krąży cyklami z „ Mam to! .. mam sekret do dokładnego prognozowania! ”. Kiedy faktycznie robisz prognozę, mówisz głośno: „POZWOLĘ x dni / godzin / punktów na ukończenie tego ” - w pewnym sensie tworzy „szafę czasową”, w której to wydarzenie ma zostać przeprowadzone.

Dla mnie punkty po prostu przesuwają granice, pod koniec dnia, chyba że jesteś w zespole, który chętnie powie: „ * Mamy 3 tygodnie na sprint i ssanie kciuka ... myślę, że powinniśmy strzelać 30 punktów do ukończenia w tym cyklu! Kto jest ze mną! * ”I to tak głęboko, jak się da w modelowaniu prognoz - w porządku! .. realistycznie ustalasz arbitralny budżet i to wszystko. Spoglądasz też z perspektywy czasu na pracę zakończoną poczuciem „świętej badziewie, zrobiliśmy 33 punkty tego sprintu, było całkiem fajnie” i niewiele można na to poradzić. Możesz użyć prędkości, aby ustalić, czy w połowie sprintu dostajesz huk za budżet, pytając głośno: „ Czy osiągnęliśmy już 15 punktów?„ale istnieje niebezpieczeństwo, że używasz prędkości do pomiaru wydajności, a nie pojemności, co z tego, co rozumiem, powoduje Reactive Release Management (punkty fabularne) w głowie.

System punktowy jest prawie zbyt sprytny, aby nie zauważyć, że nadal przypisujesz względny czas do równania, wszystko od uzgodnionych „cykli sprintu” do codziennych pojedynków, w których wprowadzasz ukrytą zasadę dotyczącą czasu trwania + złożoności = „ Max zajmuje zbyt dużo czasu z tym zadaniem „wrodzone jelita czują kod zespołu czerwony moment?

Ludzki mózg nie jest w stanie przewidzieć, ponieważ wiąże się z dużą pamięcią roboczą połączoną z pamięcią długo- / krótkoterminową, więc to tak, jakby poprosić początkującego studenta matematyki o zrobienie ułamków w głowie, a nie na papierze. To dlatego inne branże nigdy nie zgadzają się na prognozę i nieustannie weryfikuje prognozy we względnym czasie (np. geolog nigdy nie przestaje modelować prognoz, dopóki ten metr sześcienny nie zostanie wykopany z ziemi, a następnie „zrobiony”).

Powiedziałbym, że system punktowy działa, jeśli nie prognozujesz . Zgadzasz się na część pracy opartą na algorytmie podziału częściowego, ale to naprawdę twoje najbliższe podejście do prognozowania, jak to możliwe. W rzeczywistości zarządzanie wydaniami szukałoby naturalnych przerw w kolejce „zaległości”, które pasują do motywów (np. W Silverlight my, menedżerowie produktu czekali, aż uzupełnią swoje zaległości i poskładają motywy, które początkowo ustawiliśmy. nigdy nie wiedzieliśmy, co konkretnie robią inżynierowie, po prostu mieliśmy ogólny zarys. Następnie wzięlibyśmy tę część pracy i zbudowaliśmy wokół niej nasze wydarzenie marketingowe (Microsoft Mix)

Kiedy zaczynasz blokować oczekiwania dotyczące prędkości w cyklach sprintu, które opierają się na prędkości + czasie, ponownie powracasz do prognozowania, ale tym razem jesteś w gorszej sytuacji, ponieważ grasz w grę „to zależy” ... Co ważniejsze, zabijają również potencjał wzrostu zespołu / kariery.

Podatek płacony za punkty w funkcji czasu zależy od punktów, w których należy szukać alternatywnych formuł pomiaru, aby śledzić rozwój umiejętności / mentoring onjob lub zachowanie programistów.

Ponieważ nadal będziesz musiał spojrzeć na „medianę programistę” jako idealną osobę do połączenia umiejętności / wysiłku, możesz następnie bazować na innych programistach z tą osobą, aby określić, w jaki sposób godzą się w ciągłym rozwoju w zespole. Zwraca także uwagę na sytuacje, w których „szybcy” programiści niosą większość wody, ale nudzą się lub gorzej, pracują dłużej i nie są nagradzani / nagradzani z powodu konkurencyjnych terminów itp. Awarie nie odkrywają tego w rzeczywistości, są naprawdę tam, aby wykryć nieprzyjemne zapachy w zespole, na przykład, jak w „ta osoba walczy, pomaga

Następnie pojawiają się opowieści o „przeniesieniu”, które nie są podzielone na ten cykl sprintu, ale przechodzą do następnego cyklu sprintu. Który następnie może łatwo wywołać efekt domina, jeśli uwzględnisz czas, ale w momencie, gdy weźmiesz pod uwagę czas względny. Ponownie, po prostu cofnąłeś się do „prognozowania / szacowania na podstawie czasu” i ponownie system punktowy jest po prostu zabłocić wody.

Jeśli przejdziesz do punktów, całkowicie ignorujesz czas i mam na myśli całkowicie, gdy pozwalasz, aby czas wkradł się w grę, grając w pomysł / metodologię.

Podróżując po całym świecie jako ewangelista, widziałem, jak wiele zespołów przeklina swoje ręce na to, co im się podoba, że ​​złamały kod Agile Forecast ... ale zawsze kliknąłem swój język, uśmiechałem się i odchodziłem z myślą „ tak ... prawie to zrobiłeś, ale ta kochanka, którą nazywamy „czasem”… jest po prostu okrutna…


-1

Książka Mike'a Cohna „Zwinne szacowanie i planowanie” opisuje zalety i wady szacowania za pomocą „idealnych dni” lub punktów historii, więc szybka odpowiedź na twoje pytanie jest taka, że ​​nie musisz oceniać za pomocą punktów historii. Jeśli oszacowanie w idealnych dniach jest bardziej naturalne, przejdź do przodu.


1
To niekoniecznie odpowiada na pytanie; zamiast tego zapewnia jedynie odniesienie do książki. Możesz wzmocnić swoją odpowiedź, przedstawiając podsumowanie zalet i wad.

-1

Myślę, że metoda Story Point ma co najmniej dwie ważne zalety w stosunku do metody „Dzień roboczy”: po pierwsze, łatwiej jest oszacować w SP. SP jest względne, a ludzie, podobnie jak my, są lepsi pod względem względnym niż bezwzględne oszacowanie, jak metoda na dzień człowieka.

Po drugie, gdy oszacujesz w SP, otrzymasz „Team SP”, a nie „Individual Manday”. Kiedy zapytasz „Jak długo potrwa to zadanie?”, Starszy programista może dać ci 1 dzień, ale 5 dni dla juniora. To dzień człowieka zależy od tego, kto podejmie się tego zadania. Jeśli właściciel zostanie zmuszony do zmiany (i tak się stanie!), Musisz wszystko zaplanować ponownie. Dzięki SP wciąż jest to ten sam, kto podejmie się tego zadania.


-1

Dziwi mnie, że nikt jeszcze nie wspomniał o prawie Parkinsona .

Praca rozszerza się, aby wypełnić czas dostępny na jej zakończenie.

Zasadniczo, jeśli szacujesz w jakiejkolwiek jednostce czasu dla dużych zadań, programiści zwykle poświęcają czas, który szacują, aby go ukończyć lub przejść. Kiedy oszacujesz w mglistym czasie, takim jak Punkty Story lub Rozmiary Koszula, unikniesz tej pułapki.


1
„Kiedy szacujesz w mglistym czasie, takim jak Punkty Story lub Rozmiary Koszula, unikasz tej pułapki.”: Niezupełnie: jeśli na 2-tygodniowy sprint przydzielono mi dwie historie użytkowników w sumie 10 punktów historii, mogę wziąć całe dwa tygodnie i ustaw prędkość na 5 punktów opowieści na tydzień. Myślę, że wzrost wydajności ma więcej wspólnego z motywacją zespołu i warunkami pracy niż z jednostką używaną do pomiaru złożoności zadań.
Giorgio

Nie chodziło mi o zwiększenie wydajności, a bardziej o to, że jeśli oszacowanie historii wyjdzie na 3 dni. Deweloper ma znacznie większe szanse, że ukończenie go zajmie 3 lub więcej dni, niż popełnił błąd.
Vadim

Czy istnieją dobre dowody na prawo Parkinsona? Strona Wikipedii chyba nie wspomina o żadnej.
bdsl,

-2

Oszacowanie punktu fabuły następuje według serii Fibonacciego 1,2,3,5,8,13,21 ...

Ludzki mózg może łatwo mapować rzeczy na podstawie rozmiarów. Na przykład: Mamy kartę pocztową i przypisujemy jej punkt historii 2, a trzy karty wielkości post oznaczałyby 2 * 3 = 6 punktów opowieści.

Story Point 6 mieści się pomiędzy seriami Fibonacciego 5 i 8, przy czym 5 jest liczbą bliższą, a zatem punktem fabularnym byłoby 5.


1
Nie mapujemy rzeczy na podstawie wielkości, używamy pamięci roboczej, aby traktować je jako „schematy” do pracy. W pewnym sensie nasz mózg ma niewielką ilość pamięci RAM, którą, gdy karmimy małymi, dostrzegalnymi wzorami (Fibonacci, A000079, rozmiary koszulek itp.), Mogą odwołać się do naszych wewnętrznych zdolności poznawczych, aby pomóc w projektowaniu w tym przypadku - odpowiedź. , który jest tak naprawdę modelem „prognozy względnej”.
Scott Barnes
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.