Estymata estymacie nier\u00f3wna<\/h2>\n\n\n\n
Estymowanie pracy w godzinach sprowadza lub sprowadza\u0142o si\u0119 zwykle do tego, \u017ce zesp\u00f3\u0142 dostaje zadanie\/wymaganie\/historyjk\u0119 w zestawie z pytaniem \u201ena kiedy?\u201d. Nast\u0119pnie deweloperzy zastanawiaj\u0105 si\u0119, ile czasu zajmie im dana funkcjonalno\u015b\u0107 (lub jej cz\u0119\u015b\u0107). Rozk\u0142adaj\u0105 j\u0105 na cz\u0119\u015bci pierwsze i bior\u0105c pod uwag\u0119 z\u0142o\u017cono\u015b\u0107 systemu, swoj\u0105 wiedz\u0119 lub jej brak, testy, nieprzewidziane sytuacje, przerwy na kaw\u0119, pr\u0105dy morskie, sytuacj\u0119 polityczno-gospodarcz\u0105 na Bliskim Wschodzie, migracje \u0142ososia oraz prawdopodobie\u0144stwo opad\u00f3w deszczu w Birmie, a na koniec, dodaj\u0105c 30% bufor, podaj\u0105 \u201ena oko\u201d, \u017ce zajmie to im X godzin.<\/p>\n\n\n\n
Znacie prawo Hofstadtera<\/strong>?<\/p>\n\n\n\n Wszystko zawsze zajmuje d\u0142u\u017cej ni\u017c planujesz, nawet je\u015bli we\u017amiesz pod uwag\u0119 prawo Hofstadtera.<\/p>\n<\/blockquote>\n\n\n\n Rezultaty zwykle s\u0105 do przewidzenia \u2013 z reszt\u0105, nie jest to nic niezwyk\u0142ego i coraz cz\u0119\u015bciej traktowane jest to jako co\u015b naturalnego.<\/p>\n\n\n\n Czemu wi\u0119c mog\u0105 s\u0142u\u017cy\u0107 estymaty czasowe? A czemu nie powinny s\u0142u\u017cy\u0107? Jak ich u\u017cywa\u0107?<\/strong> Jak to bywa \u2013 teoria jest prosta, a praktyka trudna.<\/p>\n\n\n\n Pami\u0119tajmy zawsze po co tak naprawd\u0119 estymujemy w Scrum. Przede wszystkim robimy to, \u017ceby wiedzie\u0107, ile mo\u017cemy \u201ew\u0142o\u017cy\u0107\u201d do Sprintu \u2013 na podstawie dost\u0119pno\u015bci cz\u0142onk\u00f3w zespo\u0142u i czasu, jaki potrzebuj\u0105 na wykonanie zadania.<\/p>\n\n\n\n Tak wi\u0119c, praktyka z jak\u0105 si\u0119 spotka\u0142em jest taka, \u017ce historyjki u\u017cytkownika dzieli si\u0119 na sub-taski deweloperskie, b\u0119d\u0105ce \u201echecklist\u0105\u201d tworzon\u0105 przez deweloper\u00f3w dla deweloper\u00f3w. Deweloperzy po podzieleniu takiej historyjki nadaj\u0105 ka\u017cdemu podzadaniu jak\u0105\u015b wycen\u0119 w godzinach. Suma czasu, jaki zostanie po\u015bwi\u0119cony na sub-taski, jest przypisana do ca\u0142ej User Story. St\u0105d wiemy, \u017ce skoro zesp\u00f3\u0142 ma do po\u015bwi\u0119cenia X godzin czasu w Sprincie, to do Sprintu zmie\u015bcimy User Stories, kt\u00f3re mog\u0105 \u0142\u0105cznie trwa\u0107\u2026 oko\u0142o 75%*X godzin, bo tyle w praktyce jeste\u015bmy w stanie pracowa\u0107 efektywnie ka\u017cdego dnia.<\/p>\n\n\n\n Zalet\u0105 godzin jest to, \u017ce godziny s\u0105 znane. Mo\u017cna na ich podstawie wyceni\u0107 (mniej wi\u0119cej), ile zmie\u015bcimy do Sprintu. W mojej ocenie jest to metoda idealna dla pocz\u0105tkuj\u0105cych zespo\u0142\u00f3w<\/strong> lub takich, w kt\u00f3rych nast\u0105pi\u0142y znacz\u0105ce zmiany kadrowe.<\/p>\n\n\n\n Na pocz\u0105tku pracy, czy to w nowym zespole, czy takim, kt\u00f3ry mocno si\u0119 zmieni\u0142, ci\u0119\u017cko si\u0119 opiera\u0107 na Story Points, czy jakiejkolwiek innej relatywnej jednostce miary. Spowodowane jest to tym, \u017ce nie mamy danych historycznych, na podstawie kt\u00f3rych mogliby\u015bmy oszacowa\u0107 nasz\u0105 pr\u0119dko\u015b\u0107.<\/p>\n\n\n\n (Dla os\u00f3b, kt\u00f3re dopiero zaczynaj\u0105 swoj\u0105 d\u0142ug\u0105 i [prawdopodobnie] wyboist\u0105 drog\u0119 z estymatami \u2013 sens ostatniego zdania powinni\u015bcie zrozumie\u0107 po zapoznaniu si\u0119 z nast\u0119pnym rozdzia\u0142em.)<\/p>\n\n\n\n Takie podej\u015bcie do estymat nie jest jednak wolne od wad, poniewa\u017c:<\/strong><\/p>\n\n\n\n No i nie ukrywajmy \u2013 estymowanie w czasie zosta\u0142o przeniesione z poprzednich, kaskadowych modeli, dlatego lepiej si\u0119 sprawdza w nich, ni\u017c w modelach zwinnych. Gdy przekraczamy czas w modelu kaskadowym \u2013 trudno. Wiadomo, \u017ce nie ma si\u0119 z czego cieszy\u0107, ale s\u0105 jeszcze tzw. zakresy tolerancji, kt\u00f3rych zadaniem jest mitygacja takiego ryzyka. W Scrum nie ma tolerancji czasowej \u2013 Sprinty s\u0105 sta\u0142ej d\u0142ugo\u015bci, wi\u0119c nie mo\u017cemy przed\u0142u\u017cy\u0107 iteracji o 2 dni, bo \u201ejeszcze co\u015b trzeba dotestowa\u0107\u201d. Powoduje to cz\u0119sto, \u017ce niedostarczenie funkcjonalno\u015bci na koniec Sprintu odbierane jest przez niekt\u00f3rych jako wina braku planu i zarz\u0105dzania.<\/p>\n\n\n\n Chyba najpopularniejsz\u0105 metod\u0105 wyceny tzw. \u201ehistoryjek\u201d w zwinnym podej\u015bciu s\u0105 Story Points. Opieraj\u0105 si\u0119 na por\u00f3wnywaniu na podstawie z\u0142o\u017cono\u015bci i pracoch\u0142onno\u015bci (w odr\u00f3\u017cnieniu od wyceny godzinowej, gdzie wycenia si\u0119 tylko czas trwania pracy) \u201ehistoryjek\u201d do tzw. \u201ehistoryjki referencyjnej” (maj\u0105cej przewa\u017cnie warto\u015b\u0107 5 lub 8 Story Point\u00f3w). <\/p>\n\n\n\n Zesp\u00f3\u0142 wsp\u00f3lnie zwykle na sesjach Planning Pokera<\/strong> wycenia wymagania, por\u00f3wnuj\u0105c \u201ewielko\u015b\u0107\u201d historyjki do historyjki referencyjnej w skali zmodyfikowanego ci\u0105gu Fibonacciego, zwykle przybieraj\u0105cego warto\u015bci 0, \u00bd, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? i \u2615 (znak zapytania oznacza niezrozumienie historyjki, kubek \u2013 pro\u015bb\u0119 o przerw\u0119).<\/p>\n\n\n\n Sama gra polega na tym, \u017ce po kr\u00f3tkim om\u00f3wieniu przedmiotu wyceny, ka\u017cdy z cz\u0142onk\u00f3w zespo\u0142u samodzielnie wybiera kart\u0119 z talii. Po dokonaniu wyboru przez wszystkich cz\u0142onk\u00f3w zespo\u0142u, jednocze\u015bnie odkrywa si\u0119 karty. Wtedy, je\u015bli nie ma jednomy\u015blno\u015bci co do wyceny osoby, kt\u00f3re poda\u0142y najni\u017csze i najwy\u017csze warto\u015bci \u201ebroni\u0105” swojej wyceny przed reszt\u0105 zespo\u0142u deweloperskiego. Nast\u0119pnie nadchodzi druga tura g\u0142osowania\u2026 i tak a\u017c do osi\u0105gni\u0119cia konsensusu lub rozegrania ustalonej liczby \u201epartii”.<\/p>\n\n\n\n Zalet\u0105 Planning Pokera jest to, \u017ce je\u015bli kt\u00f3ra\u015b z os\u00f3b w zespole widzi proste rozwi\u0105zanie problemu, kt\u00f3rego nie widzi nikt inny \u2013 najprawdopodobniej da ni\u017csz\u0105 wycen\u0119, wi\u0119c b\u0119dzie musia\u0142a si\u0119 wypowiedzie\u0107 na dany temat (czasami taka metoda \u201eprzymusu” jest jedyn\u0105 opcj\u0105, by przekona\u0107 nie\u015bmia\u0142\u0105 osob\u0119 do podzielenia si\u0119 pomys\u0142em na implementacj\u0119 z reszt\u0105 zespo\u0142u) lub w drug\u0105 stron\u0119 \u2013 kto\u015b mo\u017ce zauwa\u017cy\u0107 ogromn\u0105 przeszkod\u0119 na drodze implementacji. Sam niejednokrotnie by\u0142em \u015bwiadkiem sytuacji rodem z filmu \u201eDwunastu Gniewnych Ludzi”.<\/p>\n\n\n\n Podstawowym zadaniem Story Points jest u\u0142atwienie zespo\u0142owi oszacowania zakresu Sprintu.<\/p>\n\n\n\n Znaj\u0105c nasze Velocity (pr\u0119dko\u015b\u0107 wyra\u017con\u0105 liczb\u0105 SP realizowanych per Sprint), jeste\u015bmy w stanie z grubsza oszacowa\u0107, ile Sprint\u00f3w zajmie wytworzenie wystarczaj\u0105cej ilo\u015bci funkcjonalno\u015bci na release lub ile mniej wi\u0119cej funkcjonalno\u015bci dostarczymy na dat\u0119 release.<\/p>\n\n\n\n Do zalet Story Point\u00f3w nale\u017c\u0105:<\/p>\n\n\n\n Jak wszystko, tak\u017ce i Story Pointy maj\u0105 swoje wady. Ich problemem jest nadal, niestety:<\/p>\n\n\n\n Kolejn\u0105, popularn\u0105 metod\u0105 estymowania wielko\u015bci zada\u0144 jest T-shirt Size. S\u0142owo \u201ewielko\u015b\u0107” nie jest tutaj przypadkowe, gdy\u017c opiera si\u0119 na por\u00f3wnywaniu do siebie zada\u0144 pod k\u0105tem w\u0142a\u015bnie rozmiaru. W odr\u00f3\u017cnieniu od Story Points, skupia si\u0119 to na nadawaniu historyjkom rozmiar\u00f3w koszulek, zazwyczaj XS, S, M, L, XL.<\/p>\n\n\n\n Na pocz\u0105tek wybieramy historyjk\u0119, kt\u00f3ra jest typow\u0105, codzienn\u0105 prac\u0105 dewelopersk\u0105 i nadajemy jej wielko\u015b\u0107 M. Reszta odbywa si\u0119 przez por\u00f3wnanie \u2013 np. mniejsza b\u0119dzie mia\u0142a rozmiar S, du\u017co wi\u0119kszy rozmiar XL.<\/p>\n\n\n\n Dalsza cz\u0119\u015b\u0107 mo\u017ce si\u0119 r\u00f3\u017cni\u0107 w zale\u017cno\u015bci od zespo\u0142u. Zwykle polega to na przypisaniu warto\u015bci liczbowej rozmiarowi koszulki, np. S=100, M=200, L=400 itd. i na tej podstawie szacuje si\u0119, ile pracy mo\u017cemy zabra\u0107 do Sprintu (r\u00f3wnie\u017c bazuj\u0105c na warto\u015bciach historycznych).<\/p>\n\n\n\n Oczywi\u015bcie da si\u0119 tak\u017ce robi\u0107 estymaty \u201er\u0119kami” architekta rozwi\u0105zania. Dla niekt\u00f3rych mo\u017ce to by\u0107 dobre rozwi\u0105zanie, jednak, je\u015bli chcemy z niego skorzysta\u0107, musimy by\u0107 \u015bwiadomi z jakich zalet wyceny za pomoc\u0105 innych technik rezygnujemy.<\/p>\n\n\n\n Tematem, kt\u00f3ry wraca jak bumerang w \u015bwiecie zwinnego software developmentu, jest ruch, kt\u00f3ry sam siebie nazywa \u201e#NoEstimates\u201d, moim zdaniem niepotrzebnie wprowadzaj\u0105c w b\u0142\u0105d i budz\u0105c kontrowersje \u2013 no, ale \u201ereklama d\u017awigni\u0105 handlu”.<\/p>\n\n\n\n Wydaje mi si\u0119, \u017ce na polskiej scenie Agile nadal panuje zbyt ma\u0142o zrozumienia dotycz\u0105ce tego ruchu. Jest to temat na zupe\u0142nie inny artyku\u0142<\/a>, jednak postaram si\u0119 przedstawi\u0107 jego esencj\u0119.<\/p>\n\n\n\n Sama filozofia #NoEstimates opiera si\u0119 na tym, \u017ce nale\u017cy w ko\u0144cu zaakceptowa\u0107 fakt, \u017ce estymaty s\u0105 niedok\u0142adne i nie b\u0119d\u0105 ju\u017c dok\u0142adniejsze. W zwi\u0105zku z tym, zamiast skupia\u0107 si\u0119 na dok\u0142adnym estymowaniu, nale\u017cy ograniczy\u0107 czas \u201emarnowany” na estymowanie. Ale jak? Tutaj ju\u017c pe\u0142nej zgody nie ma.<\/p>\n\n\n\n Ale o tym wi\u0119cej w nast\u0119pnym artykule.<\/a> \u017beby podsyci\u0107 Wasz apetyt zostawi\u0119 tutaj tego tweeta od Rona Jeffriesa<\/a>, jednego z tw\u00f3rc\u00f3w Extreme Programming:<\/p>\n\n\n\n I am not sure I invented story points but if I did I\u2019m sorry now. ?<\/p>\n\n\n\n \u2014 Ron Jeffries (@RonJeffries)<\/p>\n\n\n\n 21 grudnia 2017<\/p>\n<\/blockquote>\n\n\n\n Nie wiem, czy Story Pointy pozwoli\u0142yby mi si\u0119 lepiej dogada\u0107 z mam\u0105 \u2013 w ko\u0144cu nie interesowa\u0142 jej wynik Sprintu (meczu), tylko to, \u017ceby sko\u0144czy\u0142 si\u0119 na czas. <\/span><\/span><\/p>\n\n\n\n Mam nadziej\u0119, \u017ce troch\u0119 Wam si\u0119 rozja\u015bni\u0142o. Je\u015bli nie \u2013 ciesz\u0119 si\u0119 jeszcze bardziej. Nie ma nic lepszego ni\u017c konstruktywna dyskusja, do kt\u00f3rej zach\u0119cam w komentarzach. <\/span><\/span><\/p>\n\n\n\n [1] Conte, S.D., Dunsmore, D.E. and Shen, V.Y. Software Engineering Metrics and Models<\/em>, cytuj\u0119 za: Dina S. Ahmed Is your project\u2019s best estimation method Agile or conventional? <\/em>[dost\u0119p 20.02.2019]<\/p>\n\n\n\n ***<\/p>\n\n\n\n Artyku\u0142 zostal opublikowany po raz piewszy 07.10.2019<\/p>\n\n\n\n <\/p>\n\n\n\n
Czas, czas, czas, czas, czas, czas\u2026 Czas wci\u0105\u017c goni nas<\/h2>\n\n\n\n
Jak szacowa\u0107 pr\u0119dko\u015b\u0107 w nowym lub zmienionym zespole?<\/h2>\n\n\n\n
Wady podej\u015bcia<\/h3>\n\n\n\n
\n
Story Points \u2013 za 3 punkty!<\/h2>\n\n\n\n
![\"Story](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/10\/complexity-vs-effort-1.png\")
<\/a><\/a>Zalety i wady Story Point\u00f3w<\/h2>\n\n\n\n
\n
\n
T-shirt Sizes \u2013 czy nie za obcis\u0142a\u2026?<\/h2>\n\n\n\n
Estimates or No Estimates \u2013 that is the question<\/h2>\n\n\n\n
\n
Podsumowanie<\/h2>\n\n\n\n
\u0179r\u00f3d\u0142a<\/h3>\n\n\n\n