Jaki jest cel planowania pokera w sprincie?

Nasz analityk biznesowy i kierownicy projektu mówią nam o wymaganiach klienta dotyczących historii. Przy każdym planowaniu Sprint, my (programiści) prosimy o grę w pokera planistycznego.

Poprosili nas wszystkich o rozważenie „złożoności”, a nie „wysiłku”. Jesteśmy naprawdę zdezorientowani i marnujemy czas na nasze spotkania. Jeden z programistów podniósł pytanie: „Co naprawdę powinniśmy rozważyć? Czy chodzi o zmianę kodu / DDL, którą musimy zrobić w tym wymaganiu (oszacowanie czasu), czy chodzi o to, czy zrozumieliśmy to wymaganie?

Ale co tak naprawdę rozumieją (analityk biznesowy i kierownicy projektu), rozumiejąc wymóg i podnosząc kartę?

Dodatkowo organizujemy spotkania dla poszczególnych zespołów scrumowych, gdzie każdy programista podaje szacunkowy czas na dane zadanie dla każdego zespołu scrumowego. O czym tak naprawdę rozmawiają w Planning Poker?

Czy ktoś może to wyjaśnić na przykładzie? Spróbuj rozróżnić, o czym tak naprawdę mówią, gdy mówią „złożoność” i „wysiłek”.

Zastanów się nad punktem widzenia kierownika projektu

Prosząc o złożoność, chcą liczby, którą mogą porównać z następnym sprintem, aby znaleźć twoją prędkość jako zespół. Być może próbują go wykorzystać, aby zsumować Twój wynik z szacunkami z innych zespołów, aby uzyskać ogólne oszacowanie, kiedy wszystkie historie zostaną ukończone.

Kierownik projektu szuka oszacowania, kiedy projekt zostanie ukończony, lub jeśli są elastyczne po drugiej stronie trójkąta czas-funkcja-koszt, jakie inne odchylenia można wyciągnąć, aby dopasować je do pozostałego czasu. To nie jest nierozsądne. Decyzje biznesowe będą musiały być podejmowane na podstawie tych szacunków. Problem polega na tym, że naprawdę trudno jest to oszacować dla oprogramowania. Planowanie pokera jest jednym ze sposobów na rozwiązanie tego problemu. Zamiast postrzegać to jako zwykłe zsumowanie liczby punktów opowieści, pomyśl raczej o bardziej złożonej funkcji szacowania tak dobrze, jak to możliwe, wykonując pracę, mierząc, ile czasu to zajęło, iterując, a następnie ekstrapolując.

Dyskusja jest ważniejsza niż liczba

Uważam, że najważniejszą częścią spotkań wskazujących na historię są nadchodzące dyskusje. Jeśli ktoś w zespole nie ma pewności, co do liczby, sugeruje, że nie do końca rozumie historię i trzeba więcej dyskutować. Z Manifestu Zwinnego „Współpraca z klientem przy negocjowaniu umowy”. Zamiast tylko określać umowę napisaną jako historia użytkownika i mówić, że zespół zawiódł, jeśli nie zrobi dokładnie tego, czego chcesz, zawsze lepiej jest rozmawiać o tym, czego naprawdę chce klient, dopóki go nie zrozumiesz.

Złożoność a wysiłek

Aby odpowiedzieć na twoje konkretne pytanie dotyczące złożoności a wysiłku, wydaje się, że każdy ma inne zdanie na ten temat. Mountain Goat , którzy tworzą karty do gry w pokera z kozami i których właściciel Mike Cohn jest duży w świecie Agile / Scrum, mówią, że powinien to być wysiłek, a nie złożoność.

Zwykle nie jest to miara czasu (patrz przykład poniżej dla licznika), ponieważ ludzie źle oceniają czas, a inne czynniki wpływają na liczbę, którą podają: np. Nacisk na utrzymanie niskiej liczby, abyś mógł dopasować więcej funkcji nacisk, aby dać wyższą liczbę, aby dać sobie trochę miejsca, jeśli napotkasz problem. Tworzenie oprogramowania jest trudne. Kiedy budujesz swój 100. dom, możesz oszacować, jak długo to zajmie, ponieważ wcześniej zbudowałeś 99 domów. Jeśli oprogramowanie, które budujesz, jest takie samo, jak poprzednie programy, które zbudowałeś, możesz je kopiować i wklejać, każdy projekt oprogramowania jest inny, a więc będą miały problemy, których nie przewidziałeś na początku.

Podobnie jak w przypadku szacunków czasowych zawierających ukryte naciski, tak i wysiłek ma również problemy. Jeśli młodszy programista oceni wysoką złożoność, może poczuć, że naraża się na atak, ponieważ nie jest wystarczająco dobry od innych, którzy oceniliby go niżej. Jest to szkodliwe nie tylko dla twoich szacunków, ale dla ludzi w zespole.

Planowane liczby pokerowe nie są „liczbą dni” ani inną miarą czasu, są względną miarą umożliwiającą porównanie dwóch historii użytkowników. Pierwszą rzeczą, którą musisz zrobić w nowym zespole, jest ustalenie linii bazowej. Wybierz jedną historię użytkownika, która znajduje się w środku zakresu złożoności i uzgodnij jako zespół liczbę w środku zakresu, którą chcesz mu przypisać. Teraz wszystkie inne historie użytkowników mogą być ponumerowane w stosunku do tego. Odkryłem, że to znacznie ułatwia.

Powody, dla których nie możesz podać szacunku

Kiedy menedżerowie projektu pytają o termin realizacji projektu, muszą zrozumieć złożoność zadanego pytania. Programiści nie są pracownikami fabrycznymi, których wydajność można zmierzyć, mnożąc szybkość pisania przez czas pracy. Wymyślają odpowiedzi na problemy i to jest trudne. Grając w pokera planistycznego, najpierw identyfikujesz, kto w zespole czuje, że nie może odpowiedzieć na pytanie, jaki numer przypisać, a następnie wykopujesz, dlaczego nie mogą odpowiedzieć na to pytanie. Myślę, że istnieją co najmniej cztery powody:

1. Historia jest za duża. Podziel go na mniejsze, bardziej szczegółowe historie użytkowników. Pamiętaj, że każda historia użytkownika powinna zapewniać użytkownikowi jedną wartość; input - process - output = wartość.
2. Nie rozumieją wystarczająco dobrze dziedziny problemów, aby móc powiedzieć, ile czasu to zajmie, a nawet poprawnie zadać wszystkie pytania. Idź porozmawiać z ludźmi, którzy wiedzą więcej na temat domeny interesariuszy / programowania tego rodzaju aplikacji, bez względu na to, czego wcześniej nie widziałeś. Jeśli nie jest to możliwe lub nie prowadzi cię do końca, możesz użyć kolca do projektowania. Idź i prototypuj rozwiązanie, ale tylko przez ograniczony i określony czas. Określ, jak długo potrwa faza prototypowania, nie za długo, a następnie spotkaj się ponownie, aby podzielić się swoim nowym zrozumieniem.
3. Twoi interesariusze nie są wystarczająco konkretni. „Zbuduj mi chmurę” to niedopuszczalna historia użytkownika. „Zbuduj mi system, w którym mogę rozkręcać maszyny wirtualne na żądanie” jest lepszy, ponieważ jest dalej rozbity, ale wciąż nie jest na poziomie, na którym możesz podać dokładne oszacowanie, ile czasu zajmie ci to, ponieważ będzie sto ukrytych założenia zawarte w tym oświadczeniu, że interesariusz ma, że ​​nie dowiesz się, dopóki mu czegoś nie pokażesz.
4. Wreszcie, nawet jeśli potrafisz podać szacunek, prawdopodobnie będzie to pierwszy raz źle. Szacowanie jest trudnym problemem, a najlepszym sposobem na rozwiązanie trudnych problemów jest użycie metody naukowej. Zbieraj dane o tym, jakie liczby szacuje każdy członek zespołu, a następnie zbieraj dane o tym, ile czasu to naprawdę zajęło lub jak „skomplikowane” było naprawdę, chociaż jest to trudniejsze, a następnie porównaj je w czasie. W końcu poczujesz, kto przecenia, a kto nie docenia, a następnie powinieneś podzielić się tym z zespołem. Ludzie mogą sobie nawzajem pomóc w lepszym oszacowaniu. Liczby te można również wprowadzić z powrotem do narzędzia śledzącego, aby lepiej przewidzieć, jak długo potrwają historie.

Wniosek

Uważam, że tak naprawdę powinna istnieć dyskusja, ale jeśli naprawdę musisz podać komuś numer, spróbuj po prostu uczynić go niezależnym od tego, który członek zespołu nad nim pracuje i w jakiej kolejności są opracowywane historie. Chodzi o to, aby uzyskać dostęp do dziennika wstecznego, który ma zarówno priorytety, więc pracujesz nad nimi we właściwej kolejności i wielkości, aby Kierownik Projektu mógł z grubsza zobaczyć, ile więcej możesz zmieścić przed upływem terminu. Powinieneś być w stanie zatrzymać się na końcu każdej iteracji i wysłać wszystkie ukończone funkcje, które zostały uruchomione.

Ostrzeżenie

Możesz oszacować czas na wykonanie zadań w zespole tak długo, jak chcesz, pod warunkiem, że zachowujesz liczby dla siebie. Gdy pozwolisz, aby jakikolwiek numer uciekł z zespołu i był widoczny dla innych osób, zrobią rzeczy z tym numerem, którego nie zamierzałeś. Spróbują wykorzystać to jako liczbę dni do wykonania zadań. Postarają się utrzymać cię na poziomie względnej złożoności i zapytają, dlaczego zajęło ci więcej czasu, aby ukończyć historię jednego użytkownika niż drugą z taką samą liczbą punktów. Dodają do siebie twoje liczby i porównają je z liczbami innych zespołów i zapytają, dlaczego ten drugi zespół „wykonuje więcej pracy”, gdy ukończą więcej punktów historii w określonym czasie. Możesz'

Na bok

Planszowy zestaw liczb w pokerze jest zwykle rozmieszczony tak, że luki między liczbami stają się coraz większe. Uważam, że ma to na celu zniechęcenie ludzi do sporu o to, czy historia użytkownika to 16 czy 17, jeśli jest większa niż 13, po prostu zrób z niej 20.

Przykład

Znam przynajmniej jedną drużynę, która używa liczb 1, 2, 3 i 4 do planowania pokera. Wbrew konwencji i w przeciwieństwie do powyższej dyskusji, określają je jako dni programowania (w rzeczywistości dni programowania w parach, czyli o ile dni zajęłoby dwóch programistów pracujących razem na tym samym komputerze, aby ukończyć historię użytkownika). Jeśli zespół uważa, że ​​ukończenie historii użytkownika potrwa dłużej niż 4 dni, nie jest to wskazane, a właściciel produktu jest proszony o współpracę z zespołem w celu dalszego opracowania historii lub dokładniejszego sprecyzowania, aby mogła zostać uwzględnionym w tym zakresie na przyszłym spotkaniu planistycznym. Ale jest to zaawansowana zwinność i prawdopodobnie powinny być używane tylko przez osoby, które mają już doświadczenie w stosowaniu innych technik.

Myślę, że odpowiedzi Franka i Encaity w dużej mierze to obejmują, ale jest kilka dodatkowych rzeczy do rozważenia:

Po co korzystać z punktów historii

Celem oszacowania za pomocą punktów fabularnych jest zapewnienie względnej złożoności opracowywania funkcji dla Twojej aplikacji. Prostym sposobem na przemyślenie tego jest wzięcie historii, którą masz w nadchodzącym sprincie, np. Zmiana adresu URL. Wiesz, że jest to proste pod względem złożoności i ma jasno określone kryteria akceptacji, więc cały zespół zgadza się, że nawet przy testowaniu jest to 1 (przy użyciu skali Fibo).

Następną historią do oszacowania jest agregacja zestawu danych użytkownika i wizualizacja tego w interfejsie użytkownika. Teraz jako programista wiesz od razu, że jest to o wiele bardziej skomplikowane niż zmiana adresu URL. Omawiasz historię i kryteria akceptacji, masz wiele pytań i widzisz kilka potencjalnych rozwiązań. Inni deweloperzy i QA również zgadzają się, że jest to bardzo złożone. Więc wszyscy zgadzacie się, że to 34-punktowa historia. Warto zauważyć, że skala Fibo pozwala również wskazać, ile masz pewności w przybliżeniu - im większe odstępy między liczbami, tym mniejsze zaufanie do oszacowania

W tym momencie twój mistrz Scrum powinien podskoczyć i powiedzieć, że jako pojedyncza historia jest zbyt duża i musi zostać podzielona na mniejsze historie o mniejszej złożoności. Możesz podejść do tego, robiąc tak zwane SPIKES - to tylko trochę czasu, aby coś zbadać. W tym przykładzie ty i inni twórcy zgadzacie się, że macie 4 godziny na omówienie i zbadanie możliwych rozwiązań technicznych.

Krótko mówiąc, dzielisz tę wielką historię na cztery inne, po 5, 8, 8 i 13 punktów. Nie pamiętaj, że w tych szacunkach chodzi o względną złożoność - nie muszą one sumować się z pierwotną oceną, a teraz masz więcej informacji, aby dokonać dokładniejszej oceny.

Następnie zgadzasz się jako zespół, że w tym sprincie będziesz dążyć do ukończenia 13-punktowej historii, jednej 8-punktowej historii oraz 1-punktowej zmiany adresu URL, którą już zidentyfikowałeś. Łącznie 22 punkty. Następnym sprintem otrzymasz 27 punktów, a następnym sprintem 18 punktów. Po 3 sprintach możesz nabrać pewności co do prędkości (prędkość to ilość pracy, jaką Twój zespół może wykonać w jednym sprincie). Aby uzyskać prędkość, weź średnią z poprzednich sprintów. Tak więc w tym przykładzie średnia wynosi (22 + 27 + 18) / 3 = 22,3, więc zaokrągl ją do najbliższej skali Fibo, która wynosi 21.

Teraz do następnego sprintu wystarczy zdobyć 21 punktów.

Nie odrywaj się od poprawnego oszacowania punktu historii - to nie jest ścisła nauka. Wiesz, że zmiana adresu URL jest o wiele mniej skomplikowana niż agregowanie danych, więc po prostu odpowiednio ją oceń.

Plus omawianie tych rzeczy jako zespołu jest dobre. Spójrz wstecz na swoje szacunki podczas przeglądu sprintu i przedyskutuj, czy byłeś z nich zadowolony, czy nie, a następnie wprowadź je do następnej sesji planowania sprintu.

Ocena całego zespołu

Cały zespół musi uzgodnić jedno oszacowanie dla każdej historii. Funkcja nie jest wykonywana, dopóki nie będzie gotowa do produkcji. Samo napisanie kodu wcale nie jest zrobione. Z mojego doświadczenia wynika, że ​​zespoły Scrum były znacznie bardziej efektywne, pracując jako zespół. Weź przykład zespołu, z którym obecnie pracuję. Kiedy dołączyłem, robili wszystkie spotkania sprinterskie i planowali pokera, ale podczas sprintu proces był następujący: 1. Licencjobiorcy / Właściciele Produktów definiują wymagania jako historie z kryteriami akceptacji i testami akceptacyjnymi 2. Wręczają te wymagania deweloperowi, który następnie pisze kod 3. Deweloper połączył kod z gałęzią programistyczną w celu przeprowadzenia kontroli jakości. Test QA, a następnie zaczynają zadawać pytania i testy kończą się niepowodzeniem, więc wraca do programowania.

Czego tu brakuje? Z początku nie ma wystarczająco dużo dyskusji, a każdy członek zespołu widział tylko swoje własne zadanie. Teraz BA / PO, devs i QA spotykają się przed napisaniem jakiegokolwiek kodu, aby szczegółowo omówić wymagania i zadać pytania z góry, a następnie kontynuować dyskusję przez cały sprint. Jest to o wiele bardziej wydajne i prowadzi do lepszej jakości rozwiązań.

Planowanie pokera pomaga w tym procesie, ponieważ zmusza zespół do przedyskutowania tej funkcji i uzgodnienia, jako złożona realizacja tej funkcji. W tradycyjnym tworzeniu oprogramowania kierownik projektu był odpowiedzialny za dostarczenie projektu, ale każdy z doświadczeniem w tym podejściu wie, że to nie działa, ponieważ najczęściej ludzie nie biorą odpowiedzialności za swój udział w dostarczeniu aplikacji. W Agile nie powinieneś potrzebować kierowników projektów, ponieważ zespół ponosi odpowiedzialność za dostarczenie aplikacji.

Terminowe oszacowanie zadań

Mój pogląd, że pracowałem z zespołami, które szacują czas na zadania i zespołami, które tylko oceniają punkt fabularny, NIE PODKREŚLAJ CZASÓW! To tylko strata czasu. Nie są tak dokładne, jak punkty historii, ponieważ są specyficzne dla jednostek, a nie zespołu, i każda z nich będzie miała inny pomysł na oszacowanie czasu (sprowadź płomień).

Punkty historii akceptują, że rzeczy, tj. Wymagania, zmieniają się cały czas, więc naprawdę potrzebujesz wskaźnika tego, co zespół może ukończyć w sprincie.

Kiedy już zrozumiesz prędkość, możesz mierzyć swoje rezultaty w czasie, ponieważ wiesz, co możesz zrobić w każdym sprincie, np. Co dwa tygodnie wiesz, jakie funkcje można dostarczyć. Twój mistrz scrum i właściciele produktów powinni odbyć sesje szacunkowe, aby spojrzeć w przyszłość na sprinty, a następnie możesz uzyskać wskaźnik tego, ile pracy wykonasz w ciągu najbliższych kilku miesięcy. Dzięki temu właściciele produktów mogą podejmować decyzje dotyczące priorytetów dotyczące tego, jakie funkcje mają zostać uwzględnione w końcowej aplikacji.

Poprosiłem programistów, aby oszacowali czas na zadania w celu zaplanowania, ale tak naprawdę nie zgadzam się z tym podejściem (w rzeczywistości zdecydowanie nie zgadzam się z tym podejściem), ponieważ nie jest ono dokładne, np. Co to zajmie mi 4 godziny naprawdę: jeden twórca może poświęcić tylko czas na samo zadanie, ktoś inny może dodać czas na zrobienie filiżanek herbaty!

Szacunki czasu są zawsze przekazywane komuś innemu do celów sprawozdawczych, a także przecenia poszczególne elementy dostarczania funkcji w stosunku do wysiłku całego zespołu.

Szacowanie nie jest największym problemem

Nawiasem mówiąc, ustalenie szacunków nie jest największym problemem, który moim zdaniem muszą rozwiązać zespoły. Najważniejszą rzeczą jest wspólna praca nad zespołem w trakcie sprintu, abyś nie oddał wszystkiego do testów ostatniego dnia. Chcesz zobaczyć stałą liczbę funkcji podczas 2-tygodniowego sprintu. Dynamika zespołu, którą wyjaśniłem powyżej, jest w dużej mierze tego częścią. Szacowanie punktu fabuły pomoże ci to zaplanować, ponieważ zobaczysz, które z wielkich historii wymagają podziału na mniejsze, które można regularnie testować.

Wikipedia dość dobrze wyjaśnia planowanie pokera . Pozwól, że podsumuję niektóre z nich, skupiając się na twojej sprawie:

Po co planować pokera?

Przede wszystkim wszyscy powinniście wiedzieć, dlaczego planujesz pokera, a nie „normalne” oszacowanie. Powód jest właściwie bardzo prosty: każdy z nas ma dużo czasu, jeśli chodzi o szacowanie czasu na zadanie. Niemal każde badanie ujawniło, że ludzki mózg po prostu nie jest w stanie oszacować zadania, które zajmuje rozsądnie dużo czasu. (Jest to również powód, dla którego bilety, których szacunki przekraczają 2-3 dni, są prawie bezwartościowe pod względem szacunków).

Dlaczego złożoność zamiast wysiłku?

Jest to zgodne z powyższym. Wysiłek zwykle oznacza czas , a my na tym wysysamy. Złożoność jest natomiast trudna do obiektywnego oszacowania, co w tym przypadku jest dobrą rzeczą. To twoje wnętrzności mówią ci, że ta historia będzie złożona. Dla kogoś innego może to być mniej skomplikowane. Ale nie musisz dokładnie określać, jak bardzo jest złożona. Nie musisz mieć takiej Xzłożoności - w przeciwieństwie do czasowego wysiłku, w którym ostatecznie musisz zgodzić się, że zajmie to Xkilka dni lub kilka innych.

Po co ukrywać karty?

Karty o złożonym charakterze są odtwarzane w ukryciu, a następnie ujawniane jednocześnie. Ma to na celu upewnienie się, że opinie innych osób nie wpłyną na ciebie przed dokonaniem wstępnej oceny. Jeśli wszyscy mają podobne odczucia jelitowe pod względem złożoności, oznacza to, że gotowe. Jeśli występują bardzo różne liczby, wiesz, że jest tam coś do omówienia. W ten sposób możesz bardzo szybko poradzić sobie z historiami, dla których każdy ma takie samo wyobrażenie o wymaganej złożoności / wysiłku.

Dlaczego liczby Fibonacciego?

Liczby na twoich kartach są zwykle liczbami Fibonacciego lub inną sekwencją z dużą ilością luk w liczbach. Ma to zmusić cię do pełnego zaufania swoim przeczuciom. Jeśli musisz wybrać między 8 a 13, to znacznie więcej niż oświadczenie 9 lub 10. Ponadto, jak wspomniano powyżej, duże różnice dotyczą ukrytych problemów, więc powiększając luki, zwiększasz szansę lepiej wykrywaj te problemy.

Dlaczego to w ogóle działa?

Co ciekawe, pierwsze kilka razy, kiedy grasz w pokera planistycznego, nie zadziała. To takie proste. Co w ogóle oznacza „3” lub „5”? Nie ma definicji, co oznacza każda liczba (celowo!) I to od twojego zespołu zależy odkrycie faktycznego znaczenia każdej z tych liczb. Dopiero po zaakceptowaniu oszacowania swoich historii w tych liczbach - i po zrealizowaniu kilku z nich - masz lepszy pomysł, kiedy powinieneś przebić 5, a kiedy jest to 8.

Po połączeniu tego z koncepcją prędkości i mierzenia postępów sprintu za pomocą tych punktów fabularnych masz zupełnie nową skalę wydajności, która jest mniej więcej niezależna od tradycyjnych oszacowań czasu.

Niemniej jednak, dla mnie osobiście, najbardziej korzystnym punktem planowania pokera jest to, że używając liczb fibonacci zamiast oszacowań czasu, masz znacznie łatwiejszy czas na wykrycie niepewności. Przy klasycznych szacunkach czasu nie jesteś zmuszony do podejmowania takich „ekstremalnych” (ze względu na luki liczbowe) decyzji, dlatego szacunki mogą być dość blisko siebie, a zespół może fałszywie wierzyć, że dobrze zrozumiał historię.

Przykład

Prostym przykładem tego, co zwykle się dzieje, jest przedstawienie historii, a następnie osoba A zgłasza sprzeciw. Jest to coś w rodzaju „nie zapominaj, że ta funkcja wpływa na X, a to może oznaczać, że jest droższa niż dotychczas. Głównym problemem jest to, że zawsze przy stole jest ta osoba A. Zawsze jest coś, o co ktoś się martwi. Jeśli prowadzisz otwartą dyskusję z góry, nie masz pojęcia, jak bardzo martwi Cię ta sprawa z X.

Jeśli robisz ukryte szacunki na podstawie czasu, staje się to nieco lepsze. Ale mimo to osoba A z uzasadnionym sprzeciwem może nie być jeszcze wyraźną wartością odstającą w jej ocenie. Z drugiej strony, przy planowaniu pokera osoba A musi zastanowić się więcej nad tym, jaki jest rzeczywisty problem X. W przypadku dwóch różnych problemów nie można właściwie rozróżnić ich znaczenia na podstawie powyższego „wypowiedzianego tekstu sprzeciwu”. Nawet z szacunkami czasu trudno jest stwierdzić, co stanowi większy problem. Nadzieja używając pokera planowania jest to, że skończy się jeden zarzut jest zaledwie 2-3 punktów różnią się od szacunków innych, ale drugi zarzut, który zakończył się 5 lub 8 punktów od mediany może być tylko najważniejszym niepewność twojego planowania sprintu.

Po kilkudziesięciu iteracjach w moim zespole odkryliśmy, że punkty fabularne dotyczą głównie średniookresowego sterowania projektem. Pozwalają właścicielowi produktu rzutować się na 2 lub 3 sprinty z wyprzedzeniem i zasadniczo podejmują decyzje biznesowe i dotyczące zakresu dotyczące wydania na podstawie średniej prędkości.

Odkryliśmy, że punkty fabularne nie są zbyt przydatne na poziomie sprintu, ponieważ żadne 2 sprinty nie są podobne i przewidywanie, ile pracy zostanie wykonane, jest niemożliwe. W związku z tym zdecydowaliśmy, że nie powinniśmy mieć obsesji na punkcie szacowania i po prostu rozważmy planowanie pokera jako pretekst do rozmowy na temat funkcji.

Zgadza się to z stwierdzeniem Mike'a Cohna tutaj .

Na marginesie, odnosi się to do danej drużyny, ale nie ma żadnych zasad dotyczących tego, w jaki sposób punkty historii pomogą ci. Zalecam, aby najpierw zastosować metodologię, ale spróbuj szybko dowiedzieć się, czy i jak są one przydatne. Retrospektywy pomogą ci się nad tym zastanowić.

Podstawowym problemem jest to, że jest zepsuty. Premier chce użyć pokera planistycznego, aby dowiedzieć się o złożoności każdej historii, z zamiarem dokładnego poznania, ile historii można dopasować do sprintu (prędkość zespołu).

W rezultacie jest to „nieoparte na czasie”, które jest „oparte na czasie”. Nic dziwnego, że wszyscy się zdezorientowali.

Istnieją sposoby, aby to zadziałało dla Ciebie. Po pierwsze zapomnij o wysiłku i skup się na złożoności. Zapomnij o tym, jak długo może to potrwać, i skup się na obszarach, na które wpływa każda historia. Jeśli masz historię aktualizującą bazę danych, kod serwera, kod klienta i dokumentację klienta, możesz powiedzieć, że jest to historia 4-punktowa. Jeśli jest to tylko zmiana w DB SQL, to jest to historia 1-punktowa. To daje bardziej zrozumiały sposób na znalezienie względnej złożoności między opowieściami. (Będziesz musiał wymyślić kilka wskaźników, które będą odpowiednie dla twoich okoliczności, np. Wymagania dotyczące zasięgu testu lub złożoność interfejsu użytkownika)

Moim zdaniem ogólnie rzecz biorąc, jest to bezcelowa strata czasu, która po prostu zachęca do planowania sprintu, jak gdyby były to projekty mini wodospadu. Kogo naprawdę obchodzi, ile punktów historii można zmieścić w sprincie? Jeśli na końcu sprintu pozostały historie, po prostu zrób je w następnej. Biorąc to pod uwagę, równie dobrze możesz po prostu zwiększyć zaległości w stosunku do każdej wybitnej historii, którą posiadasz, i stopniowo je z czasem zmniejszać. Dostawa trwa tyle, ile trwa (ale będzie szybsza, jeśli nie będziesz marnować 20% swojego czasu na zaległości i spotkania dotyczące planowania sprintu). Pod koniec projektu nikt nie dba o liczbę dostarczonych punktów fabularnych. Ludzie dbają o dostarczony projekt.

Również wskazywanie historii użytkownika daje firmie przewagę, jeśli coś wymaga ponownych negocjacji. jeśli masz miesiąc na ukończenie pracy, którą uzyskałeś jako 100, możesz mieć kłopoty. daje także szansę na podzielenie epickiej historii na coś mniejszego, który wciąż ma wartość i może zostać ukończony w sprincie.