Planning Poker i wordy developers [zamknięte]

10

Mój zespół składa się z 4 programistów; wszyscy doświadczeni i wykwalifikowani. Jednym z nich jest pracowity, dobrze przemyślany facet, który nalega na określenie technicznego rozwiązania naszych historii, zanim podamy nasze szacunki w Planning Poker. Odmawia oszacowania, jeśli nie ma wstępnego pojęcia o uzgodnionym rozwiązaniu technicznym (co brzmi rozsądnie, prawda?).

Problem polega na tym, że nasze sesje szacunkowe trwają wiecznie! Z własnego doświadczenia, jak radzisz sobie z tego rodzaju osobowością, grając w pokera planistycznego?

Pomario
źródło

Odpowiedzi:

13

Wygląda na to, że podoba mu się formalne definiowanie rzeczy, więc dobrym pomysłem byłby licznik czasu, ponieważ planowanie pokera jest zdefiniowane jako czas, w którym ludzie mogą mówić.

On też ma błędne wyobrażenie o szacowaniu, wszyscy oceniają na podstawie historii, a nie implementacji , dlatego otrzymujesz taką wariancję. Na przykład niektórzy ludzie mogą nie wiedzieć o frameworku lub gotowym rozwiązaniu i zacząć pisać od zera.

StuperUser
źródło
1
Timer to świetny pomysł. Przypomina mówcom zwięzłość i zmusza ich do destylacji tego, co próbują powiedzieć do bardzo podstawowego punktu.
Shane Wealti
Pomaga również, jeśli wstępne prace nad historiami zostaną wypchnięte wcześnie, wtedy wstępne przygotowania techniczne można wykonać „offline” od samego spotkania. Poker nie jest miejscem, w którym można znaleźć rozwiązania, marnujesz cały dział. Innym pomysłem byłoby dodanie „zaprojektuj to” jako opowieść, która zawiera wczesny timebox „implementuj to”. W następnej rundzie uzyskamy rzeczywiste szacunki dotyczące wdrożenia.
Patrick Hughes,
2
Timer jest nie tylko dobrym pomysłem, ale uważam, że jest zalecany (być może ktoś z Agile Planning and Estimation to potwierdzi). Rozumiem, że podobnie jak większość zajęć, planowanie sesji pokerowych ma być chronione czasowo, aby zapobiec sytuacjom takim jak pytanie.
Thomas Owens
1
For example some people may be ignorant of a framework or off the shelf solution and start writing things from scratch- Stąd dyskusja. Wtedy wszyscy wiedzą o tym i szacunki są lepsze.
Izkata,
3

Twój członek zespołu ma osobowość analityka. Analitycy potrzebują wielu informacji, aby podjąć decyzję. Pomysł z timerem jest najlepszy, ale pamiętaj, że da sobie radę z niczego, co da. Współpracuj z nim, aby wyjaśnić, że jest to tylko wczesna ocena oparta na problemach, a NIE rozwiązanie. Jeśli chce zadawać pytania, poproś go, aby rozwiązał problem, a nie rozwiązanie. Być może będziesz musiał go odciąć lub zirytować na jakiś czas, gdy będzie szukał rozwiązań.

Upewnij się, że trzymasz innych w zespole na tych samych zasadach, aby nie czuł się wyróżniony. Analitycy są powszechną osobowością w programowaniu, więc bardzo dobrze możesz spotkać innych takich jak on.

Bill Leeper
źródło
2
+1, jestem analitykiem i walczę z tym problemem. Zauważyłem, że jestem o wiele bardziej dokładny i kompletny i mam mniej błędów niż moi rówieśnicy, ale łatwo jestem zestresowany i nieskuteczny w sytuacjach, w których informacje nie są doskonałe. Codziennie staram się radzić sobie z nieznanym w mniej stresujący sposób.
wałek klonowy
2

Wygląda na to, że Twój kolega nie rozumie różnicy między szacunkiem a zaangażowaniem lub nie został mu o tym poinformowany podczas szkolenia. A ponieważ próbowałeś powiązać problem z jego osobowością, możliwe, że cały zespół jeszcze go nie rozumie. (Ale nie martw się! Większość naszej branży tego nie rozumie. Zwinność jest trudna!)

Kiedy mówimy, że rozmiar opowieści wynosi X punktów, mamy na myśli rozkład prawdopodobieństwa. Jeśli nasze szacunki są prawidłowe, opowieść powinna trwać dłużej 50% czasu (a pozostałe 50% zajmie mniej czasu). Jeśli twój kolega uważa, że ​​po upływie X jednostek czasu zostanie poproszony o pokazanie historii lub inaczej, co zmieni jego podejście do szacowania.

Planowanie pokera wprowadza kolejny błąd: zamiast próbować określić X, dopasowujemy go do dyskretnej skali, przy czym najbardziej popularna jest skala Fibonacciego (1, 2, 3, 5, 8 itd.). Mówi, że rozmiar nie jest tak duży, jak to jest. Gdy mówimy, że rozmiar opowieści wynosi 3 punkty, naprawdę mówimy „to X plus minus pewna wariancja, a X jest bliższy 3 niż 2 lub 5.”

Twój zespół może skorzystać ze zrozumienia, jak nieprecyzyjne jest to ćwiczenie i jak szacunek różni się od zaangażowania. Jeśli chcesz / musisz dogłębnie przestudiować te pojęcia, ta książka ma to.

azheglov
źródło
Planując, jeśli uważasz, że historia zajmuje 3 dni i godzinę, powinieneś wykorzystać te 5 dni, a nie zaokrąglać w dół . Deweloper musi zachować dyscyplinę i dokonać oceny w odniesieniu do zadania, a nie dopasować plan zadania do oceny.
StuperUser
10
„Wygląda na to, że twój kolega nie rozumie różnicy między szacunkiem a zaangażowaniem”. Mogę się z tym całkowicie odnieść, ponieważ wielu menedżerów ZAWSZE bierze początkowe szacunki i zamienia je w zobowiązania . Niektórzy z nas, tacy jak ja, tak bardzo denerwują się tym, że podają przybliżone dane szacunkowe, ponieważ menedżerowie nas do nich przylgnęli, a następnie spodziewali się, że będziemy pracować przez długi weekend bez snu, aby zrobić to do końca sprintu.
wałek klonowy
1
@maple_shaft: masz absolutną rację, szacunek / zaangażowanie jest jednym z największych nieporozumień w naszej branży, a to nieporozumienie jest jedną z największych przeszkód. Twoje „zdenerwowanie”, „długie weekendy”, „brak snu” itp. Są wśród jego konsekwencji. Możesz rozwiązać ten problem tylko wtedy, gdy włączysz wszystkich, cały zespół, swojego kierownika itp. Dlatego sprawne przejście jest tak trudne. Podnoszenie talii kart bez zrozumienia tych pojęć jest łatwe.
azheglov
1
@azheglov, czasami przejście Agile jest trudne, ponieważ zarząd myśli , że chce Agile, podczas gdy w rzeczywistości są mikro-zarządzającymi megalomanami ze strasznym kompleksem niższości i silnym pragnieniem, aby NIGDY nie dostosowywać harmonogramów sprintu, gdy zmieniają się wymagania lub nowe informacje. Innymi słowy, tak naprawdę nie chcą Agile, ponieważ prawdziwa Agile jest tak zasadniczo sprzeczna ze wszystkim, co wiedzą.
wałek klonowy
@maple_shaft, ty też masz rację! Nie będę
omawiał
1

Widzę, skąd pochodzi twój zespół, ale najwyraźniej nie do końca zrozumiał koncepcję Agile i Planning Poker. Powinieneś zacząć od upewnienia się, że wszyscy rozumieją koncepcje i uzasadnienie, a następnie powinni zrobić to samodzielnie.

AJC
źródło
1

Dla zespołów, z którymi pracuję, na początku każdej sesji planowania ustawiam na stole 3-minutowy minutnik. Daję znać całemu zespołowi, że jeśli w którymkolwiek momencie czuje, że rozmowa staje się głębokim nurkowaniem lub jest nieistotna, lub w jakikolwiek inny sposób wykracza poza to, co według nich jest potrzebne do oszacowania historii w punktach fabularnych, wtedy każdy w zespole może odwrócić stoper. Gdy piasek się skończy, zespół natychmiast ocenia.

Ta metoda umożliwia każdej osobie w zespole ograniczenie rozmowy, gdy czują, że rozmowa nie jest już przydatna do oceny omawianej historii. Jednocześnie nie przerywa ona natychmiast rozmowy, ale daje wizualne wskazanie, że rozmowa musi się zakończyć w ciągu kilku minut, ponieważ wtedy głosujemy.

Innym narzędziem, którego używam, aby pomóc skupić się na planowaniu, jest upewnienie się, że wszyscy w zespole sprawdzili historie u góry zaległości przynajmniej na kilka dni przed planowaniem. Chodzi o to, że jeśli masz listę pytań natychmiast po przeczytaniu opowiadań, możesz powiadomić właściciela produktu o potencjalnych pytaniach kilka dni wcześniej, aby mogli wyjaśnić historię lub krytyczną akceptację, aby, mam nadzieję, ograniczyć późniejszą dyskusję. Dzięki temu ludzie mogą zacząć myśleć o potencjalnym projekcie historii, zanim zaczną planować (i próbują zaprojektować podczas planowania).

Shawn S.
źródło