Agile Estymacja w Scrumie? Punkty historii i Planning Poker

Table of Contents hide

7.1 Karta pokerowa i sekwencja Fibonacciego

7.2 Cechy szacowania związane z ciągiem Fibonacciego

7.3 Specjalne liczby w kartach pokerowych

11 Artykuły w technikach Scrum

W procesie rozwoju oprogramowania zespół często zadaje pytanie:

Jak oszacować czas pracy, aby był bardziej dokładny?

Dla właściciela projektu lub produktu jest to bardzo ważna informacja do pomiaru zasobów projektu i harmonogramów, ale w praktyce spowodowało to wiele problemów.

Wielu deweloperów zawsze czuje, że PM używa terminu, aby popychać w tę i z powrotem. Nie obchodzi ich, czy funkcja może być ukończona w dobrej jakości.

„Najpierw zrób to, potem szukaj lepszego” krąży w branży oprogramowania od dłuższego czasu.

Wielu PM-ów zawsze czuje, że deweloperzy mają tendencję do „przesadzania”, gdy szacują swoją pracę. Wydaje się, że wszyscy używają typowej metody szacowania pracy: „Osądź trzy razy więcej niż rzeczywisty czas jako bufor”

W rzeczywistości godziny pracy nie mogą być oszacowane jako „absolutnie dokładne”, ale istnieją pewne sposoby na oszacowanie „relatywnie obiektywnie”. Z powodu złożoności godzin pracy i wymagań często występuje pozytywna korelacja. Dlatego ten artykuł najpierw wyjaśni powszechne problemy w odpowiedzi na złożoność wymagań, zaproponuje proponowane rozwiązanie i wyjaśni cel wielu projektów w rozwiązaniu.

Problemy

Kopalnia dewelopera

„To bardzo proste. Nie powinno to zająć zbyt dużo czasu, aby to zrobić?”
PM powiedział do ciebie dzisiaj: „Muszę to oddać przed jutrem. „Zrób to zanim zaczniesz szukać jakości”
PM powiedział do ciebie pojutrze: „Dlaczego jakość programu jest tak zła?”
Kiedy to zostało opóźnione, inni koledzy: „Jak to możliwe, że potrzebujesz tyle czasu? To ma gotowy kod do odniesienia. To ma dobrą podstawę do użycia. Dlaczego mnie nie zapytałeś?”
Inni koledzy: „Potrzebuję tylko jednego dnia, dlaczego spędziłeś tyle dni?”
„To jest zdrowy rozsądek! Jeśli nie wspominamy o wymaganiu, powinieneś wiedzieć, co robić.”

Kopalnia PM/PO

„Dlaczego to takie proste? Dlaczego to trwa tak długo?”
„Dlaczego widzisz, że odwiedzasz Facebooka, ale nie masz czasu, aby to zrobić?”
„Dlaczego jakość rzeczy, które są robione, jest tak zła?”
„Dlaczego zrobił to ostatnim razem, ile dni musisz na to poświęcić?”
Ponieważ specyfikacje lub wymagania nie są jasno napisane, deweloper jest opisywany jako zmiana wymagań.

Wynik

Wrogość ról: jednostka popytu i jednostka rozwoju nie dostarczają już produktu, który może przynieść korzyści użytkownikowi, ale atakują się nawzajem w swoich celach, aby uniknąć ponoszenia dodatkowych odpowiedzialności. Dlatego sytuacja, w której jednostka popytu i jednostka rozwoju wcale nie są jednym zespołem.
Odpowiedzialność: Zespół myśli, że „nie jestem winny, więc opóźnienie nie jest moją odpowiedzialnością”, zamiast priorytetować potrzeby użytkowników.
Zamrożenie wymagań: Deweloperzy są zmuszani do zmiany swoich wymagań z powodu presji terminów, w przeciwnym razie będą opóźnieni, a odpowiedzialność zostanie przypisana deweloperowi. W konsekwencji albo będą zmuszeni do pracy w nadgodzinach, aby wyprodukować coś, co ukrywa wiele błędów, albo do stworzenia jakiejś funkcji, która nie spełnia potrzeb użytkowników; a obie sytuacje zmniejszą satysfakcję użytkowników.
Niska jakość: Status PM-a jest często wyższy niż deweloperów. Dlatego, aby dotrzymać terminu umowy lub uniknąć kar, zespół będzie proszony o „Zrobienie najpierw, potem szukanie lepszego”, ale w końcu często jest to „najpierw, nie ma czasu na szukanie dobrego.” Akumulacja długu technicznego rośnie, a wynikiem jest rzeczywisty model łańcucha odpowiedzialności, który ma największą odpowiedzialność i koszty na samym końcu łańcucha. Dlatego zespół jest jak stos, deweloperzy nie mogą utrzymać się jeden po drugim, co jest jednym z czynników, dlaczego inżynierowie w firmach projektowych często mają wysokie wskaźniki rotacji.
Zwiększenie wagi kodu: Aby zoptymalizować wydajność, zawsze używa się pozycji najbardziej zaznajomionej osoby do oszacowania godzin pracy, więc osoba, która jest najbardziej zaznajomiona z modułem i procesem, zawsze będzie zainteresowana odpowiednimi wymaganiami. W końcu tylko te osoby mogą utrzymać swój własny kod, to jak pudełko Pandory, nigdy nie wiesz, które krowy i duchy wyjdą po otwarciu. Ponieważ czarna skrzynka jest często brudna, ale firma nie miała pojęcia, jak rozwiązać ten problem. Również masz nadzieję, że nie odejdzie, w przeciwnym razie część kodu nie będzie zrozumiała.

Rozwiązania

Proponowane tutaj rozwiązanie to powszechny sposób szacowania złożoności wymagań w Scrumie, ale nawet jeśli nie jest to zespół Scrum, zaleca się, aby czytelnicy mogli zidentyfikować najlepszy sposób szacowania swojego zespołu na podstawie zasad i celów projektowych.

Pamiętaj, że bez srebrnej kuli, najlepsze praktyki innych niekoniecznie odnoszą się do twojego zespołu, więc najpierw zrozum, jaki problem obecnie doświadcza twój zespół, a następnie dowiedz się, co jest dla ciebie odpowiednie, aby rozwiązać problem na podstawie praktyki innych, o ile nie prowadzi to do nowych problemów lub ryzyko kosztów nowego problemu jest akceptowalne.

Jednostką używaną tutaj do oszacowania złożoności wymagań jest punkt historii (jednostka relatywna), a nie godziny pracy (jednostki absolutne).

Jednostką używaną do oszacowania złożoności wymagań tutaj jest punkt historii (jednostka relatywna), a nie czas pracy (jednostka absolutna). Istnieje kilka powodów, aby to zrobić:

1. Porównania nie różnią się w zależności od osoby: złożoność wymagań często nie różni się w zależności od osoby, a czas potrzebny na praktykę będzie różny w zależności od osoby.

2. „Relatywne” jest łatwiejsze do oceny niż „Absolutne”: Jeśli spojrzysz na godziny pracy, będziesz musiał oszacować liczbę absolutną, a w procesie szacowania będziesz musiał pomyśleć o szczegółach wdrożenia. Aby użyć punktu historii do oszacowania złożoności, wystarczy porównać rozmiar z innymi wymaganiami.

Na przykład trudno jest jasno powiedzieć, że „Wieża ma kilka metrów wysokości”, ale łatwiej jest wskazać, że „Ta wieża jest około 2 razy wyższa niż ten budynek.”

3. Presja na oszacowanie punktu historii dla opowieści użytkownika jest mniejsza niż oszacowanie czasu pracy: skup się na samym wymaganiu, nie martwiąc się o własne zasoby i zasoby projektu, po prostu oceń złożoność wymagania. W trakcie procesu szacowania członkowie zespołu są mniej zestresowani i traktują część rozwoju oprogramowania jak grę.

Chociaż złożoność wymagań często jest pozytywnie związana z godzinami pracy, z powodu różnych warunków wdrożenia, nadal możliwe jest posiadanie funkcji z wysokim punktem historii, a zapotrzebowanie na godziny pracy jest niższe niż punkt historii. Ale w Scrumie możesz użyć iteracyjnego sprintu, aby ocenić, jaką złożoność każdy zespół sprintowy może strawić. Dla PO/PM, zamiast szacować nieudany przebieg czasowy, lepiej jest oszacować dokładniejszy i obiektywny przebieg czasowy, aby mogli zrozumieć za pierwszym razem, jak daleko są od oczekiwanego przebiegu czasowego projektu. Jeśli zasoby są ograniczone, jak priorytetyzować wymagania lub szukać innego wsparcia.

Następnie wyjaśnij różne aspekty rozwiązania.

Kiedy

Przeprowadź ocenę przed podjęciem decyzji, kto ma to zrobić: Korzyścią z tego jest zminimalizowanie osobistych czynników dewelopera. Ponieważ nie wiesz, kto to zrobi, nie ma potrzeby przeszacowywania, aby dodać bufor z powodu zadania lub terminu.

Kto

Tylko osoby, które wykonują zadania, oceniają razem: dwa kluczowe punkty:

Tylko osoby, które wykonują zadania, mogą być oszacowane. Czas lub złożoność oszacowana przez jednostkę wymagań nie jest obiektywna, ponieważ nie są to rzeczywiste osoby wykonujące pracę, a także nie mają wpływu na oszacowanie zespołu deweloperskiego na podstawie oceny wydajności pracy. To również ułatwia unikanie oceny złożoności wymagań z perspektywy terminu.
Osoby, które wykonują zadania, oceniają razem. Ponieważ nie wiesz, kto to zrobi, liczby, które każda osoba oszacuje razem, łatwo osiągną konsensus po dyskusji i ponownym oszacowaniu. Każdy ma udział, będą mieli poczucie uczestnictwa, a ponieważ każdy ma udział, wynik oszacowania jest decydowany przez wszystkich, więc kto to zrobi w przyszłości, nie będzie narzekał.

Co

Użyj Planning Poker do oszacowania punktu historii.

Karta pokerowa i sekwencja Fibonacciego

TheSeria Fischerama interesującą cechę, a każda liczba jest sumą dwóch pierwszych liczb. Z drugiej strony, im większa różnica między liczbą a następną, tym większa różnica.

Jak pokazano powyżej, różnica między 8 a 13 wynosi 5, a różnica między 13 a 20 wynosi 7. Jednak jak to się ma do szacowania złożoności popytu? Nie jesteśmy na lekcji matematyki.

Cechy szacowania związane z ciągiem Fibonacciego

Szacunki mają również cechę, że im większe, tym dokładniejsze, im większy popyt lub zadanie jest podzielone na drobniejsze szczegóły, tym częściej szacuje się, że jest bardziej dokładne. Tak jakby duży nieregularny kawałek kamienia został umieszczony w kubku, w środku będzie więcej luk, co jest częścią, która jest niezgodna lub zmarnowana. Jeśli zainstalujesz kamień o drobniejszym rozmiarze i tej samej nieregularności, luka będzie stosunkowo mała, a dostosowanie będzie łatwe, a można ją wypełnić wygodniej.

Nawet jeśli różnica w poprzednich liczbach jest stosunkowo mała, nie ma to znaczenia, ponieważ liczba jest mała, co oznacza, że ruch jest elastyczny, a ryzyko jest niskie. Jeśli oszacowanie czasu jest niedokładne z powodu pewnych czynników, zadanie małej liczby z przodu to około 20 minut nadgodzin. Zamiast pracować w nadgodzinach przez 2 lub 5 dni.

Ponieważ duża luka cyfrowa jest duża (stosunek różnicy dwóch wartości przednich i tylnych serii Fermiego jest bliski 1,618), można uniknąć szacowania „czy ta złożoność to 20 czy 21”. „Jeśli chcesz 13, chcesz 20, chcesz 40.

Taka luka może uwydatnić różnicę w szacunkach tego samego wymagania, ponieważ prawie wszystkie z nich są gorsze o więcej niż 1,5 razy. Ten stosunek jest dość łatwy do oceny przez ludzi w odniesieniu do rozmiaru, a zatem może zmniejszyć wiele niuansów i niepotrzebnych kosztów procesu ponownego szacowania.

Specjalne liczby w kartach pokerowych

Dodatkowo na powyższym obrazku można zobaczyć kilka specjalnych liczb, którymi są 0, nieskończoność i znak zapytania.

0 może oznaczać, że to wymaganie w ogóle nie musi być realizowane, lub zostało już zrealizowane.
Nieskończoność oznacza, że popyt jest jasny, ale ten, który przekracza maksymalną liczbę, wskazuje, że popyt musi być podzielony na wiele mniejszych wymagań.
Znak zapytania wskazuje, że popyt nie jest jasny i potrzebuje wyjaśnienia lub doprecyzowania przez PO/PM.

Jak

1. Najpierw zdefiniuj jednostkę złożoności 1, na przykład funkcję kompleksowego zapytania pojedynczej tabeli. Ponieważ nasz proces szacowania opiera się na względnym rozmiarze, najpierw definiujemy jednostkę porównawczą, a po oszacowaniu przez zespół istnieje podstawa do porównania.

2. Prowadzący głośno przedstawia wymagania (takie jak karta historii użytkownika), aby upewnić się, że wszyscy rozumieją wymagania, a każda osoba przedstawia swoje własne oszacowanie złożoności. Powód używania planowania pokera polega na tym, że liczby, które oceniasz, mogą być przedstawione jednocześnie, zamiast obracać liczbami, które oceniłeś. Łatwo jest wywrócić liczby i spowodować, że wyniki osób za nimi będą wpływane przez wcześniejsze liczby.

3. Jeśli w zespole są różne oszacowania, dwa są szacowane jako najmniejsze i największe, a oni ocenią, dlaczego są skomplikowane lub proste. W powyższym przykładzie, w procesie szacowania, jeśli jedna osoba oszacuje, że punkt historii to 13, większość ludzi oszacuje 20, a inna osoba oszacuje 40. 13 i 40 są prawie 3 razy gorsze, więc zasadniczo musi być jakaś ważna informacja, która nie została zsynchronizowana.

Na przykład osoby, które oszacowały 13, myślą, że to wymaganie jest prawie takie samo jak wymaganie w przeszłości, a to wymaganie nie jest tak skomplikowane, jak się wydaje. Osoba, która oszacowała 40, może czuć się stosunkowo skomplikowana, ponieważ nie jest wystarczająco zaznajomiona z tym wymaganiem lub procesem.

4. Minimalne i maksymalne liczby powody oceny są zakończone i przeprowadza się dalsze głosowanie. Jeśli nadal są różne liczby głosów, a zdecydowana większość ludzi ma konsensus, a nie ma konsensusu, że oszacowana złożoność jest tylko jeden poziom od konsensusu złożoności, możesz zapytać członków, którzy oszacowali różne liczby, czy mogą zaakceptować liczby, które oceniłeś.

5. Jeśli liczba nadal ma lukę powyżej poziomu, lub jeśli nie można uzyskać konsensusu, powtórz kroki od 3 do 5, aż osiągniesz konsensus.

Ponownie, tylko ci, którzy faktycznie wykonują zadania lub realizują wymagania, mogą uczestniczyć w procesie głosowania, a PO/PM nie mogą ingerować.

Dlaczego

Istnieje kilka zalet tego sposobu szacowania:

Osoba, która współpracuje, decyduje o rozsądnym i obiektywnym wyniku szacowania, ma poczucie uczestnictwa i nie ma zastrzeżeń.
Wynik decyzji to konsensus między PO a zespołem, co zmniejszy występowanie sytuacji odwetu w przyszłości.
Każdy może zrozumieć wymaganie. W przyszłości każdy może działać jako osoba realizująca wymaganie. Gdy potrzebne jest wsparcie, ludzie mogą również pomagać lub wspierać się nawzajem.
Zanim to zrobisz, możesz wyjaśnić część wymagania, która nie jest jasna, oraz część, która budzi wątpliwości.
Zanim to zrobisz, możesz znaleźć najlepszy i najefektywniejszy sposób pracy w zespole.
O ile cały zespół nie jest osobą nieodpowiedzialną, ta liczba odzwierciedla fakt, że oszacowanie jest dzielone przez zespół, a PO może zrozumieć lukę między popytem a oceną.
Porównując względny rozmiar złożoności między wymaganiami, przyszły PO będzie mógł obiecać, ile pracy można zrealizować w iteracji, a także będzie istniała podstawa do porównania.

Wnioski

Dzięki powyższemu procesowi szacowania taka decyzja jest otwarta, przejrzysta, obiektywna i konsensualna. Dla dwóch ról:

Dla PO/PM:

Nie martw się o przeszacowanie zadania przez niektórych członków jako bufor.
Zrozumienie podstawowych trudności związanych z realizacją wymagań lub zadań w procesie oceny.
Zrozum, czy są jakiekolwiek części wymagania, które muszą być jasno określone lub źle zrozumiane.

Dla zespołu:

Osoby, które już nie wykonują zadań, otrzymują nierozsądny limit czasowy zgodnie z terminem.
Wymiana wiedzy między programistami przed rozpoczęciem pracy nad zadaniem. Niezależnie od tego, czy oszacowana liczba wzrasta, czy maleje, popyt jest bardziej jasny, a oszacowanie bardziej obiektywne.
Ponieważ nadal nie wiesz, kto zgłasza to zadanie, proces szacowania może być osiągnięty obiektywnie i z konsensusem zespołu, wiesz, kto jest zaznajomiony z tym zadaniem przez ten proces. Kiedy faktycznie to robisz, możesz programować w parach lub wiedzieć, kogo poprosić o pomoc.

Rozwiązanie zaproponowane w tym artykule jest rozwiązaniem powszechnym. Skupienie nie jest na formie, ale na celu projektowym każdego ogniwa w procesie szacowania zwinnym, aby rozwiązać, jaki rodzaj problemu.

Artykuły w technikach Scrum

Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文