{"id":402,"date":"2022-01-25T11:11:31","date_gmt":"2022-01-25T11:11:31","guid":{"rendered":"https:\/\/www.cybermedian.com\/pl\/?p=402"},"modified":"2025-02-18T12:34:33","modified_gmt":"2025-02-18T04:34:33","slug":"agile-estimation-in-scrum-story-point-and-planning-poker","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pl\/agile-estimation-in-scrum-story-point-and-planning-poker\/","title":{"rendered":"Agile Estymacja w Scrumie? Punkty historii i Planning Poker"},"content":{"rendered":"
W procesie rozwoju oprogramowania zesp\u00f3\u0142 cz\u0119sto zadaje pytanie:<\/p>\n
\n
Jak oszacowa\u0107 czas pracy, aby by\u0142 bardziej dok\u0142adny?<\/p>\n<\/blockquote>\n
Dla w\u0142a\u015bciciela projektu lub produktu jest to bardzo wa\u017cna informacja do pomiaru zasob\u00f3w projektu i harmonogram\u00f3w, ale w praktyce spowodowa\u0142o to wiele problem\u00f3w.<\/p>\n
Wielu deweloper\u00f3w zawsze czuje, \u017ce PM u\u017cywa terminu, aby popycha\u0107 w t\u0119 i z powrotem. Nie obchodzi ich, czy funkcja mo\u017ce by\u0107 uko\u0144czona w dobrej jako\u015bci.<\/p>\n
\n
\u201eNajpierw zr\u00f3b to, potem szukaj lepszego\u201d kr\u0105\u017cy w bran\u017cy oprogramowania od d\u0142u\u017cszego czasu.<\/p>\n<\/blockquote>\n
Wielu PM-\u00f3w zawsze czuje, \u017ce deweloperzy maj\u0105 tendencj\u0119 do \u201eprzesadzania\u201d, gdy szacuj\u0105 swoj\u0105 prac\u0119. Wydaje si\u0119, \u017ce wszyscy u\u017cywaj\u0105 typowej metody szacowania pracy: \u201eOs\u0105d\u017a trzy razy wi\u0119cej ni\u017c rzeczywisty czas jako bufor\u201d<\/p>\n
W rzeczywisto\u015bci godziny pracy nie mog\u0105 by\u0107 oszacowane jako \u201eabsolutnie dok\u0142adne\u201d, ale istniej\u0105 pewne sposoby na oszacowanie \u201erelatywnie obiektywnie\u201d. Z powodu z\u0142o\u017cono\u015bci godzin pracy i wymaga\u0144 cz\u0119sto wyst\u0119puje pozytywna korelacja. Dlatego ten artyku\u0142 najpierw wyja\u015bni powszechne problemy w odpowiedzi na z\u0142o\u017cono\u015b\u0107 wymaga\u0144, zaproponuje proponowane rozwi\u0105zanie i wyja\u015bni cel wielu projekt\u00f3w w rozwi\u0105zaniu.<\/p>\n<\/figure>\n
Problemy<\/h3>\n
Kopalnia dewelopera<\/strong><\/p>\n
\n
\u201eTo bardzo proste. Nie powinno to zaj\u0105\u0107 zbyt du\u017co czasu, aby to zrobi\u0107?\u201d<\/li>\n
PM powiedzia\u0142 do ciebie dzisiaj: \u201eMusz\u0119 to odda\u0107 przed jutrem. \u201eZr\u00f3b to zanim zaczniesz szuka\u0107 jako\u015bci\u201d<\/li>\n
PM powiedzia\u0142 do ciebie pojutrze: \u201eDlaczego jako\u015b\u0107 programu jest tak z\u0142a?\u201d<\/li>\n
Kiedy to zosta\u0142o op\u00f3\u017anione, inni koledzy: \u201eJak to mo\u017cliwe, \u017ce potrzebujesz tyle czasu? To ma gotowy kod do odniesienia. To ma dobr\u0105 podstaw\u0119 do u\u017cycia. Dlaczego mnie nie zapyta\u0142e\u015b?\u201d<\/li>\n
Inni koledzy: \u201ePotrzebuj\u0119 tylko jednego dnia, dlaczego sp\u0119dzi\u0142e\u015b tyle dni?\u201d<\/li>\n
\u201eTo jest zdrowy rozs\u0105dek! Je\u015bli nie wspominamy o wymaganiu, powiniene\u015b wiedzie\u0107, co robi\u0107.\u201d<\/li>\n<\/ul>\n
Kopalnia PM\/PO<\/h3>\n
\n
\u201eDlaczego to takie proste? Dlaczego to trwa tak d\u0142ugo?\u201d<\/li>\n
\u201eDlaczego widzisz, \u017ce odwiedzasz Facebooka, ale nie masz czasu, aby to zrobi\u0107?\u201d<\/li>\n
\u201eDlaczego jako\u015b\u0107 rzeczy, kt\u00f3re s\u0105 robione, jest tak z\u0142a?\u201d<\/li>\n
\u201eDlaczego zrobi\u0142 to ostatnim razem, ile dni musisz na to po\u015bwi\u0119ci\u0107?\u201d<\/li>\n
Poniewa\u017c specyfikacje lub wymagania nie s\u0105 jasno napisane, deweloper jest opisywany jako zmiana wymaga\u0144.<\/li>\n<\/ul>\n
Wynik<\/h3>\n
\n
Wrogo\u015b\u0107 r\u00f3l: jednostka popytu i jednostka rozwoju nie dostarczaj\u0105 ju\u017c produktu, kt\u00f3ry mo\u017ce przynie\u015b\u0107 korzy\u015bci u\u017cytkownikowi, ale atakuj\u0105 si\u0119 nawzajem w swoich celach, aby unikn\u0105\u0107 ponoszenia dodatkowych odpowiedzialno\u015bci. Dlatego sytuacja, w kt\u00f3rej jednostka popytu i jednostka rozwoju wcale nie s\u0105 jednym zespo\u0142em.<\/li>\n
Odpowiedzialno\u015b\u0107: Zesp\u00f3\u0142 my\u015bli, \u017ce \u201enie jestem winny, wi\u0119c op\u00f3\u017anienie nie jest moj\u0105 odpowiedzialno\u015bci\u0105\u201d, zamiast priorytetowa\u0107 potrzeby u\u017cytkownik\u00f3w.<\/li>\n
Zamro\u017cenie wymaga\u0144: Deweloperzy s\u0105 zmuszani do zmiany swoich wymaga\u0144 z powodu presji termin\u00f3w, w przeciwnym razie b\u0119d\u0105 op\u00f3\u017anieni, a odpowiedzialno\u015b\u0107 zostanie przypisana deweloperowi. W konsekwencji albo b\u0119d\u0105 zmuszeni do pracy w nadgodzinach, aby wyprodukowa\u0107 co\u015b, co ukrywa wiele b\u0142\u0119d\u00f3w, albo do stworzenia jakiej\u015b funkcji, kt\u00f3ra nie spe\u0142nia potrzeb u\u017cytkownik\u00f3w; a obie sytuacje zmniejsz\u0105 satysfakcj\u0119 u\u017cytkownik\u00f3w.<\/li>\n
Niska jako\u015b\u0107: Status PM-a jest cz\u0119sto wy\u017cszy ni\u017c deweloper\u00f3w. Dlatego, aby dotrzyma\u0107 terminu umowy lub unikn\u0105\u0107 kar, zesp\u00f3\u0142 b\u0119dzie proszony o \u201eZrobienie najpierw, potem szukanie lepszego\u201d, ale w ko\u0144cu cz\u0119sto jest to \u201enajpierw, nie ma czasu na szukanie dobrego.\u201d Akumulacja d\u0142ugu technicznego ro\u015bnie, a wynikiem jest rzeczywisty model \u0142a\u0144cucha odpowiedzialno\u015bci, kt\u00f3ry ma najwi\u0119ksz\u0105 odpowiedzialno\u015b\u0107 i koszty na samym ko\u0144cu \u0142a\u0144cucha. Dlatego zesp\u00f3\u0142 jest jak stos, deweloperzy nie mog\u0105 utrzyma\u0107 si\u0119 jeden po drugim, co jest jednym z czynnik\u00f3w, dlaczego in\u017cynierowie w firmach projektowych cz\u0119sto maj\u0105 wysokie wska\u017aniki rotacji.<\/li>\n
Zwi\u0119kszenie wagi kodu: Aby zoptymalizowa\u0107 wydajno\u015b\u0107, zawsze u\u017cywa si\u0119 pozycji najbardziej zaznajomionej osoby do oszacowania godzin pracy, wi\u0119c osoba, kt\u00f3ra jest najbardziej zaznajomiona z modu\u0142em i procesem, zawsze b\u0119dzie zainteresowana odpowiednimi wymaganiami. W ko\u0144cu tylko te osoby mog\u0105 utrzyma\u0107 sw\u00f3j w\u0142asny kod, to jak pude\u0142ko Pandory, nigdy nie wiesz, kt\u00f3re krowy i duchy wyjd\u0105 po otwarciu. Poniewa\u017c czarna skrzynka jest cz\u0119sto brudna, ale firma nie mia\u0142a poj\u0119cia, jak rozwi\u0105za\u0107 ten problem. R\u00f3wnie\u017c masz nadziej\u0119, \u017ce nie odejdzie, w przeciwnym razie cz\u0119\u015b\u0107 kodu nie b\u0119dzie zrozumia\u0142a.<\/li>\n<\/ul>\n
Rozwi\u0105zania<\/h3>\n
Proponowane tutaj rozwi\u0105zanie to powszechny spos\u00f3b szacowania z\u0142o\u017cono\u015bci wymaga\u0144 w Scrumie, ale nawet je\u015bli nie jest to zesp\u00f3\u0142 Scrum, zaleca si\u0119, aby czytelnicy mogli zidentyfikowa\u0107 najlepszy spos\u00f3b szacowania swojego zespo\u0142u na podstawie zasad i cel\u00f3w projektowych.<\/p>\n
Pami\u0119taj, \u017ce bez srebrnej kuli, najlepsze praktyki innych niekoniecznie odnosz\u0105 si\u0119 do twojego zespo\u0142u, wi\u0119c najpierw zrozum, jaki problem obecnie do\u015bwiadcza tw\u00f3j zesp\u00f3\u0142, a nast\u0119pnie dowiedz si\u0119, co jest dla ciebie odpowiednie, aby rozwi\u0105za\u0107 problem na podstawie praktyki innych, o ile nie prowadzi to do nowych problem\u00f3w lub ryzyko koszt\u00f3w nowego problemu jest akceptowalne.<\/p>\n
Jednostk\u0105 u\u017cywan\u0105 tutaj do oszacowania z\u0142o\u017cono\u015bci wymaga\u0144 jest punkt historii (jednostka relatywna), a nie godziny pracy (jednostki absolutne).<\/p>\n
Jednostk\u0105 u\u017cywan\u0105 do oszacowania z\u0142o\u017cono\u015bci wymaga\u0144 tutaj jest punkt historii (jednostka relatywna), a nie czas pracy (jednostka absolutna). Istnieje kilka powod\u00f3w, aby to zrobi\u0107:<\/p>\n
1. Por\u00f3wnania nie r\u00f3\u017cni\u0105 si\u0119 w zale\u017cno\u015bci od osoby: z\u0142o\u017cono\u015b\u0107 wymaga\u0144 cz\u0119sto nie r\u00f3\u017cni si\u0119 w zale\u017cno\u015bci od osoby, a czas potrzebny na praktyk\u0119 b\u0119dzie r\u00f3\u017cny w zale\u017cno\u015bci od osoby.<\/p>\n
2. \u201eRelatywne\u201d jest \u0142atwiejsze do oceny ni\u017c \u201eAbsolutne\u201d: Je\u015bli spojrzysz na godziny pracy, b\u0119dziesz musia\u0142 oszacowa\u0107 liczb\u0119 absolutn\u0105, a w procesie szacowania b\u0119dziesz musia\u0142 pomy\u015ble\u0107 o szczeg\u00f3\u0142ach wdro\u017cenia. Aby u\u017cy\u0107 punktu historii do oszacowania z\u0142o\u017cono\u015bci, wystarczy por\u00f3wna\u0107 rozmiar z innymi wymaganiami.<\/p>\n
Na przyk\u0142ad trudno jest jasno powiedzie\u0107, \u017ce \u201eWie\u017ca ma kilka metr\u00f3w wysoko\u015bci\u201d, ale \u0142atwiej jest wskaza\u0107, \u017ce \u201eTa wie\u017ca jest oko\u0142o 2 razy wy\u017csza ni\u017c ten budynek.\u201d<\/p>\n
3. Presja na oszacowanie punktu historii dla opowie\u015bci u\u017cytkownika jest mniejsza ni\u017c oszacowanie czasu pracy: skup si\u0119 na samym wymaganiu, nie martwi\u0105c si\u0119 o w\u0142asne zasoby i zasoby projektu, po prostu oce\u0144 z\u0142o\u017cono\u015b\u0107 wymagania. W trakcie procesu szacowania cz\u0142onkowie zespo\u0142u s\u0105 mniej zestresowani i traktuj\u0105 cz\u0119\u015b\u0107 rozwoju oprogramowania jak gr\u0119.<\/p>\n
Chocia\u017c z\u0142o\u017cono\u015b\u0107 wymaga\u0144 cz\u0119sto jest pozytywnie zwi\u0105zana z godzinami pracy, z powodu r\u00f3\u017cnych warunk\u00f3w wdro\u017cenia, nadal mo\u017cliwe jest posiadanie funkcji z wysokim punktem historii, a zapotrzebowanie na godziny pracy jest ni\u017csze ni\u017c punkt historii. Ale w Scrumie mo\u017cesz u\u017cy\u0107 iteracyjnego sprintu, aby oceni\u0107, jak\u0105 z\u0142o\u017cono\u015b\u0107 ka\u017cdy zesp\u00f3\u0142 sprintowy mo\u017ce strawi\u0107. Dla PO\/PM, zamiast szacowa\u0107 nieudany przebieg czasowy, lepiej jest oszacowa\u0107 dok\u0142adniejszy i obiektywny przebieg czasowy, aby mogli zrozumie\u0107 za pierwszym razem, jak daleko s\u0105 od oczekiwanego przebiegu czasowego projektu. Je\u015bli zasoby s\u0105 ograniczone, jak priorytetyzowa\u0107 wymagania lub szuka\u0107 innego wsparcia.<\/p>\n
Przeprowad\u017a ocen\u0119 przed podj\u0119ciem decyzji, kto ma to zrobi\u0107: Korzy\u015bci\u0105 z tego jest zminimalizowanie osobistych czynnik\u00f3w dewelopera. Poniewa\u017c nie wiesz, kto to zrobi, nie ma potrzeby przeszacowywania, aby doda\u0107 bufor z powodu zadania lub terminu.<\/p>\n
Kto<\/h3>\n
Tylko osoby, kt\u00f3re wykonuj\u0105 zadania, oceniaj\u0105 razem: dwa kluczowe punkty:<\/p>\n
\n
Tylko osoby, kt\u00f3re wykonuj\u0105 zadania, mog\u0105 by\u0107 oszacowane. Czas lub z\u0142o\u017cono\u015b\u0107 oszacowana przez jednostk\u0119 wymaga\u0144 nie jest obiektywna, poniewa\u017c nie s\u0105 to rzeczywiste osoby wykonuj\u0105ce prac\u0119, a tak\u017ce nie maj\u0105 wp\u0142ywu na oszacowanie zespo\u0142u deweloperskiego na podstawie oceny wydajno\u015bci pracy. To r\u00f3wnie\u017c u\u0142atwia unikanie oceny z\u0142o\u017cono\u015bci wymaga\u0144 z perspektywy terminu.<\/li>\n
Osoby, kt\u00f3re wykonuj\u0105 zadania, oceniaj\u0105 razem. Poniewa\u017c nie wiesz, kto to zrobi, liczby, kt\u00f3re ka\u017cda osoba oszacuje razem, \u0142atwo osi\u0105gn\u0105 konsensus po dyskusji i ponownym oszacowaniu. Ka\u017cdy ma udzia\u0142, b\u0119d\u0105 mieli poczucie uczestnictwa, a poniewa\u017c ka\u017cdy ma udzia\u0142, wynik oszacowania jest decydowany przez wszystkich, wi\u0119c kto to zrobi w przysz\u0142o\u015bci, nie b\u0119dzie narzeka\u0142.<\/li>\n<\/ol>\n
Co<\/h3>\n
U\u017cyj Planning Poker do oszacowania punktu historii.<\/p>\n<\/figure>\n
<\/figure>\n
<\/figure>\n