{"id":571,"date":"2022-01-26T01:39:34","date_gmt":"2022-01-26T01:39:34","guid":{"rendered":"https:\/\/www.cybermedian.com\/pl\/?p=571"},"modified":"2025-02-18T17:48:37","modified_gmt":"2025-02-18T09:48:37","slug":"agile-estimation-relative-estimates-vs-absolute-estimates","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pl\/agile-estimation-relative-estimates-vs-absolute-estimates\/","title":{"rendered":"Szacowanie Agile: Szacunki wzgl\u0119dne vs Szacunki absolutne"},"content":{"rendered":"

Dok\u0142adno\u015b\u0107 szacowania grupowego vs. indywidualnego<\/span><\/p>\n

Czy zesp\u00f3\u0142 pracuje nad produktem, czy projektem, musimy odpowiedzie\u0107 na pytanie \u201eKiedy sko\u0144czymy?\u201d lub okre\u015bli\u0107, jak wiele mo\u017cemy osi\u0105gn\u0105\u0107 w danym momencie. Tak jak przy tradycyjnym podej\u015bciu do rozwoju, przed rozpocz\u0119ciem projektu musimy oszacowa\u0107 nak\u0142ad pracy.<\/p>\n

Czym jest szacowanie projektu?<\/h3>\n

Szacunek<\/a> to przybli\u017cone obliczenie czego\u015b. Na przyk\u0142ad, oszacowanie koszt\u00f3w projektu to og\u00f3lna koncepcja modelu cenowego projektu. Pomaga ono przedstawi\u0107 \u2013 miejmy nadziej\u0119, bardziej realistyczn\u0105 \u2013 warto\u015b\u0107, gdy klienci lub inni interesariusze projektu prosz\u0105 o ocen\u0119 koszt\u00f3w i czasu wykonania projektu.<\/p>\n

Szacowanie Agile vs. tradycyjne<\/h4>\n

Tradycyjnie przeznaczamy czas na szacowanie projekt\u00f3w programistycznych, podczas gdy w metodach agile<\/a> preferuje si\u0119 przypisywanie punktu historyjek (story point) do elementu backlogu jako miary wzgl\u0119dnego nak\u0142adu pracy. Pozwala to zespo\u0142owi por\u00f3wna\u0107 zrealizowane wcze\u015bniej zadania z obecnym elementem backlogu, kt\u00f3ry ma by\u0107 oszacowany. Punkty historyjek nie wyra\u017caj\u0105 si\u0119 w okre\u015blonym czasie, lecz odzwierciedlaj\u0105 pracoch\u0142onno\u015b\u0107 wymagan\u0105 do rozwi\u0105zania podobnych zada\u0144 na podstawie wcze\u015bniejszych do\u015bwiadcze\u0144.<\/p>\n

Szacowanie agile<\/a> charakteryzuje si\u0119 trzema cechami:<\/p>\n

    \n
  1. Kolektywne szacowanie zespo\u0142u<\/li>\n
  2. Wzgl\u0119dny nak\u0142ad pracy vs. szacowanie w czasie absolutnym<\/li>\n
  3. Szacowanie pr\u0119dko\u015bci zespo\u0142u<\/li>\n<\/ol>\n

    1. Szacowanie kolektywne<\/h3>\n

    Podczas wdra\u017cania Scrum<\/a> zesp\u00f3\u0142 dzieli\u0142 odpowiedzialno\u015b\u0107 i wsp\u00f3lnie zobowi\u0105zywa\u0142 si\u0119 do wykonania pracy w ka\u017cdym Sprincie<\/a>, dlatego przy szacowaniu nak\u0142adu pracy dla zespo\u0142u agile stosowano podej\u015bcie kolektywne. Kolektywne szacunki zazwyczaj wykorzystuj\u0105 Planning poker jako narz\u0119dzie \u2013 zesp\u00f3\u0142 dokonuje wsp\u00f3lnego oszacowania, graj\u0105c w gr\u0119 szacunkow\u0105. Planning poker<\/a> jest uwa\u017cany za jedn\u0105 z najskuteczniejszych i najciekawszych technik szacowania nak\u0142adu pracy w Agile<\/a>. Zestaw kart zawiera liczby podobne do ci\u0105gu Fibonacciego, w tym: 0, 0.5, 1, 2, 3, 5, 8, 20, 40, ?, \u221e; ka\u017cda talia kart ma 4 grupy takich liczb, dedykowane dla 4 os\u00f3b.<\/p>\n

    Dok\u0142adno\u015b\u0107 szacowania grupowego vs. indywidualnego<\/strong><\/h4>\n

    Wed\u0142ug pewnego badania dotycz\u0105cego dok\u0142adno\u015bci szacowania nak\u0142adu pracy \u2013 por\u00f3wnano oszacowania indywidualne i grupowe w eksperymencie na projekcie programistycznym. 20 specjalist\u00f3w IT z tej samej firmy indywidualnie oszacowa\u0142o nak\u0142ad pracy niezb\u0119dny do realizacji tego samego projektu programistycznego. Uczestnicy mieli r\u00f3\u017cne do\u015bwiadczenia i role<\/a>, a projekt programistyczny by\u0142 wcze\u015bniej wdro\u017cony. Nast\u0119pnie utworzono pi\u0119\u0107 grup. Ka\u017cda grupa, dyskutuj\u0105c i \u0142\u0105cz\u0105c wiedz\u0119 swoich cz\u0142onk\u00f3w, ustali\u0142a jedn\u0105 wsp\u00f3ln\u0105 ocen\u0119.<\/p>\n

    Wynik \u2013 Szacunki oparte na dyskusjach grupowych by\u0142y dok\u0142adniejsze od szacunk\u00f3w indywidualnych.<\/p>\n

    Kroki przeprowadzania Planning Poker<\/strong><\/h4>\n
      \n
    1. Ka\u017cdy cz\u0142onek zespo\u0142u otrzymuje zestaw kart: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, ?, \u221e, w sumie 12 kart.<\/li>\n
    2. W\u0142a\u015bciciel produktu<\/a> opisuje dan\u0105 funkcjonalno\u015b\u0107 zespo\u0142owi.<\/li>\n
    3. Cz\u0142onkowie zespo\u0142u<\/a> dyskutuj\u0105 nad funkcjonalno\u015bci\u0105 i, je\u015bli to konieczne, zadaj\u0105 pytania w\u0142a\u015bcicielowi produktu.<\/li>\n
    4. Po zako\u0144czeniu dyskusji ka\u017cdy z cz\u0142onk\u00f3w wybiera jedn\u0105 kart\u0119 pokerow\u0105, kt\u00f3ra reprezentuje jego szacunek. Nast\u0119pnie wszystkie karty s\u0105 ujawniane jednocze\u015bnie.<\/li>\n
    5. Je\u015bli zesp\u00f3\u0142 oceni\u0142 inaczej szacunki, nale\u017cy zapyta\u0107: Czy si\u0119 zgadzamy? Czy mamy r\u00f3\u017cnice? Czy co\u015b zosta\u0142o pomini\u0119te? Ci, kt\u00f3rzy wybrali najwy\u017csz\u0105 lub najni\u017csz\u0105 warto\u015b\u0107, powinni podzieli\u0107 si\u0119 swoimi argumentami z grup\u0105, zanim ka\u017cdy wybierze kolejn\u0105 kart\u0119.<\/li>\n
    6. Po dyskusji mo\u017cna przeprowadzi\u0107 kolejn\u0105 rund\u0119 szacowania, a zesp\u00f3\u0142 powinien doj\u015b\u0107 do porozumienia.<\/li>\n
    7. Nast\u0119pnie wr\u00f3\u0107 do drugiego kroku i rozpocznij szacowanie kolejnego elementu.<\/li>\n<\/ol>\n

      2. Szacowanie wzgl\u0119dnego nak\u0142adu pracy vs. szacowanie w czasie absolutnym<\/h3>\n

      Szacunek nie jest niczym wi\u0119cej jak dobrze uzasadnionym przypuszczeniem. Wykorzystujemy ca\u0142\u0105 dost\u0119pn\u0105 wiedz\u0119 i do\u015bwiadczenie, aby zgadn\u0105\u0107, ile czasu zajmie dana praca. Zamiast patrze\u0107 na ka\u017cdy nowy element pracy osobno, lepiej por\u00f3wna\u0107 go z wcze\u015bniej wykonanymi zadaniami. Dla ludzi \u0142atwiej jest odnosi\u0107 nowe zadanie do podobnych, ju\u017c znanych, ni\u017c pr\u00f3bowa\u0107 oszacowa\u0107 rzeczywisty rozmiar zadania.<\/p>\n

      Na przyk\u0142ad, czy przypomina to naprawd\u0119 ma\u0142y element? A mo\u017ce bardziej odpowiada temu standardowemu przedmiotowi? Czy mo\u017ce jest naprawd\u0119 ogromny, podobnie jak zadanie, kt\u00f3re uko\u0144czyli\u015bmy w zesz\u0142ym miesi\u0105cu? Szacowanie wzgl\u0119dne nie tylko skraca czas przeznaczony na estymacj\u0119, ale r\u00f3wnie\u017c znacznie zwi\u0119ksza dok\u0142adno\u015b\u0107 szacunk\u00f3w.<\/p>\n

      Nasz m\u00f3zg nie radzi sobie z dokonaniem szacunk\u00f3w absolutnych; zawsze por\u00f3wnujemy nowe zadanie do rzeczy, kt\u00f3re ju\u017c znamy.<\/p>\n

      <\/figure>\n

      3. Szacowanie pr\u0119dko\u015bci \u2013 rejestracja i u\u015brednienie szybko\u015bci zespo\u0142u w ka\u017cdym Sprincie<\/h3>\n

      Pr\u0119dko\u015b\u0107 zespo\u0142u, czyli velocity<\/a>, to liczba punkt\u00f3w historyjek<\/a>, kt\u00f3re zesp\u00f3\u0142 Scrumowy<\/a> faktycznie realizuje w Sprincie. Pr\u0119dko\u015b\u0107 zespo\u0142u m\u00f3wi, jak szybko zesp\u00f3\u0142 realizuje zadania. W przypadku nowo szacowanego projektu lub zespo\u0142u (bez odniesienia do wcze\u015bniejszych wynik\u00f3w pr\u0119dko\u015bci) mo\u017cna wykona\u0107 1\u20132 Sprinty<\/a> w celu ustalenia pocz\u0105tkowej pr\u0119dko\u015bci. W trakcie realizacji Sprintu nale\u017cy rejestrowa\u0107 pr\u0119dko\u015b\u0107 ka\u017cdego z nich, z my\u015bl\u0105 o przysz\u0142ych planach.<\/p>\n

      <\/figure>\n

      Szacujemy \u0142\u0105czn\u0105 liczb\u0119 punkt\u00f3w historyjek<\/a> dla backlogu produktu<\/a>, a nast\u0119pnie, znaj\u0105c \u015bredni\u0105 pr\u0119dko\u015b\u0107 poszczeg\u00f3lnych Sprint\u00f3w, mo\u017cemy obliczy\u0107, ile Sprint\u00f3w potrzeba na zako\u0144czenie projektu, co przedstawiono na poni\u017cszym rysunku.<\/p>\n

      <\/figure>\n<\/section>\n
      \n
      \n
      \n<\/div>\n
      \n
      \n