KAIP vertinti užduočių atlikimo laiką?

Paskutiniame straipsnyje išvardinau mano manymu svarbiausias priežastis „KODĖL sunku vertinti užduočių atlikimo laiką?“. Šiame straipsnyje pasidalinsiu ką aš stengiausi daryti, kad šias priežastis pašalinti.

Užduoties dydis reikalingas tik planavimui, ne įsipareigojimui

Pirmiausia, stengiausi įveikti žmonių baimę. Drąsiausi žmonės yra tada, kai jie yra ne vieni. Tad užduočių vertinimas visos komandos kartu, pavyzdžiui, panaudojant planavimo pokerio žaidimą, labai padėjo. Be to, prieš klausdamas užduoties dydžio paaiškindavau, jog įvertinimų mums reikia tiesiog suvokimui kiek ir kokio dydžio darbų turime. Jokiu būdu pagal šiuos įvertinimus nebus nustatomi griežti atlikimo terminai ar matuojami kokie „geri” darbuotojai kurie jas atlieka. Be abejo, kaip produkto šeimininkas, pagal šiuos įvertinimus galiu planuotis darbus ir produkto paleidimus, tačiau suprantu, jog čia yra tiesiog planas, ir jis gali keistis į abi puses (taip taip, ir pailgėti, bet ir sutrumpėti 🙂 ).

Teisingas klausimas

Gavus žmonių pasitikėjimą, reikia užduoti teisingą klausimą. Čia mums padeda istorijų taškai (story points). Istorijų taškai yra tiesiog dydis (ne laikas), kuris leidžia užduoti klausimą: „kokio dydžio yra ši užduotis palyginant su kitomis, jau įvykdytomis?”. Jei kažkokiai jau įvykdytai užduočiai tarkim priskiriam 3 tai ši užduotis bus didesnė, mažesnė, kiek kartų? Jei jau esame važiavę iki Elektrėnų, tai galime nesunkiai pasakyti, jog iki Kauno yra du kartus toliau. Pasirodo žmonėms daug greičiau ir patogiau vertinti reliatyviai. O vertinimų kokybė nuo to tikrai nenukenčia.

Kai vertiname, aš pabrėžiu, jog dydį komanda vertintų galvodami, jog jie dirbs tik prie šitos užduoties ir niekas jiems netrukdys. Taip komandai žymiai paprasčiau vertinti ir nereikia įsivedinėti mistinių koeficientų. Aišku man, produkto šeimininkui, reikia žinoti ir planuotis, kada užduodis iš tikrųjų bus padaryta. Kad tą padaryti, man reikia įvertinti, jog kažkas gali susirgti ar išeiti atostogų. Jog gali būti kokie nors planuoti mokymai ar įmonės renginys. Jog gali tekti duoti komandai kažkokią neplanuotą užduotį (ko be abejo vengiame, bet tai neišvengiamai kartais nutinka). Bet tai yra mano kaip produkto šeimininko atsakomybė. Užduočių įvertinimų dydžiai nuo to juk nesikeičia.

Nuolatinis mokymasis

Be abejo, net ir pasinaudojus mano patarimais pirmieji vertinimai bus sunkūs, gan ilgi ir netgi ne visai tikslūs. Tačiau čia padeda sprinto retrospektyvų susirinkimas. Per jį aptariame kokio dydžio iš tikrųjų pasirodė užduotys, jas sugrupuojame pagal dydį, kad kitą kartą vertindami jau turėtume daugiau etalonų su kuo palyginti. Praktika rodo, kad pasitikint komandos vertinimais, atvirai apie juos šnekant, komandos labai greitai išmoksta vertinti atsakingai, greitai, ir, iš tikrųjų, labai tiksliai. Daug tiksliau nei vertindami vieni projektų vadovai ar/ir vyresniųjų specialistų komanda.

Pabandykit, gal kuris patarimas padės. O jei jau padėjo, arba ne, arba turite kitų patarimų ir patirčių, dalinkitės komentaruose.

Tagged with: , ,
Posted in Agile, Komanda, Scrum, Užduočių vertinimas
6 comments on “KAIP vertinti užduočių atlikimo laiką?
  1. Agnius101 says:

    Nepaimėtas vienas svarbus planavimo aspektas: planavimo metu komanda išsiaiškina ar ji vienodai suvokia užduotį. Tai yra komandai ir projektui naudingiau, nei tiesiog suplanuoti užduotis vien dėl to kad jas suplanuoti.

  2. Visiškai teisingai Agniau. Ir yra dar daugiau naudų planavimo yra kurių neminėjau, pvz. sistemos architektūros kūrimas, aiškus sprinto ar projekto planas ir pan. Reikės apie naudas kažkada parašyti atskirą straipsniuką, dėkui už idėją!

  3. Simonas Razminas says:

    O tai visgi Story Point yra uzduoties dydis ar santykinis dydis, m? 🙂 Ir dar idomu klausimas: kai pelgiates jei komandoje turite ir senior ir junior nariu? Ar teko buti tokioje situacijoje?

  4. Patys istorijų taškai yra dydis. Tiesiog jis nustatomas reliatyviai lyginant su kitais. O senior ir junior tikrai turim. Bet ar Schumacher’is važius iš Vilniaus į Kauną, ar aš, ar ką tik išsilaikęs vairuotojo pažymėjimą žmogus, visiems reikia įveikti ~100km. Taigi užduoties dydis yra vienodas kas jį bevertintų. O jau per kiek laiko šio dydžio užduotį tikrai priklausys kas vairuos, kas bus šturmanas, kokiu automobiliu važiuosim, kokios oro sąlygos (aplinka) ir t.t. Tuo ir žavūs istorijų taškai. Dydis visada tas pats ir gan lengvai įvertinamas, o laiką reikia mokėti pasiskaičiuoti.

  5. Simonas Razminas says:

    Ar jusu praktikoje junior ir senior programuotojai vertina vienodu kiekiu story points? Ar buv kokiu nors issukiu? Man yra teke susidurti, kai pasiekti panasaus ivertinimo yra rimtas issukis. Ar teko kada susidurti su tokia problema? Taip pat tenka susidurti su tuo, kad pakankamai sudetinga atrinkti vartotoju istorijas palyginimui.

  6. Sveikas Simonai,

    Buvo ir skirtingu vertinimu, buvo ir iššūkių juos sulyginti. Nors nepasakyčiau kad jie buvo labai jau tokie sunkus. Planavimo pokeris leidžia gan greitai pasiekti kompromisą, o tada per retrospektyvas jau diskusija vyksta ar vertinimas buvo daugiau mažiau į tą pusę. Jei nelabai (į bet kurią pusę), bandome suprasti kodėl, ir į ką reikia atkreipti kitą kartą vertinant užduotis (pvz. neužsispirti seniorams dėl kažko, ar juniorams būti mažesniais optimistais, ir pabandyti pagalvoti apie daugiau galimų sudėtingesnių užduoties vietų ir pan.).

    O vartotojų istorijų palyginimui mes nerenkame. VISOS jau padarytos istorijos yra naudojamos kaip etalonas. Taigi jei baigiame istoriją 5 taškų, dedame ją į 5 taškų “krūvelę” ir kitą kartą vertindamas jau turi po kelias skirtingų dydžių istorijas. Mano nuomone prisirišti prie kokios nors vienos istorijos kaip etalono, gan rizikinga.

    O kaip tau sekėsi pačiam. sakai turėjot iššūkių, tai kaip juos sprendėt?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Artimiausi mokymai
Data Mokymai - Lektorius
2017 m. gegužės 18-19 d. Certified Scrum Master (CSM) - Alexey Krivitsky
2017 m. gegužės 23-24 d. Certified Scrum Product Owner (CSPO) - Lasse Ziegler
2017 m. gegužės 17 d. Reikalavimų valdymas Agile projektuose - Vaidas Adomauskas
2017 m. gegužės 18 d. Agile projektų valdymo pagrindai - Vaidas Adomauskas
2017 m. gegužės 18-19 d. ICAgile sertifikuotas profesionalas (ICP) - Vaidas Adomauskas
2017 m. kovo 27-29 d. PMI-ACP sertifikavimosi pasiruošimo programa - Karolis Mickevičius-Mėgelaitis
Visi mokymai
Archives
Categories
Kontaktai

Viešos mokymų klasės:
E-paštas: mokymai (at) agilecoach.lt
Mob. tel.: 8 600 38860

Konsultacijos ir mokymai įmonėms:
E-paštas: vaidas (at) agilecoach.lt
Mob. tel.: 8 600 38860