Osnovna prednost upotrebe Story Point-a kod procjenjivanja posla

Klikova: 14356

Ako su story point-i procjena potrebnog vremena (napora) da se nešto uradi, zašto procjenu ne radimo direktno u satima ili danima? Zašto će nam uopšte poeni?

Postoji više dobrih razloga da procjenjujemo Product backlog stavke u story point-ima, ali je već jedan dovoljno ubjedljiv da opravda njihovu upotrebu.

Vezaću se za Kralja Henrija I koji je vladao Engleskom u periodu između 1100. i 1135. godine. Prije njegove vladavine, jedan „jard“ je bila jedinica mjere koja je predstavljala udaljenost između nosa osobe i palca ispružene ruke. Zamislite samo probleme zbog činjenice da je ta udaljenost različita kod svake osobe. 

Kralj Henri je u konačnici uveo pravilo da je „jard“ udaljenost između njegovog nosa i palca njegove ispružene ruke. Ovo je bilo zgodno za sve jer je tada usvojena standardna jedinica mjere za dužinu. Osim toga, kraljev jard i vaš i moj jard su poprilično slične dužine.

Story point-i su jako slični. Poput engleskih jardi, oni dozvoljavaju članovima tima različitih sposobnosti i vještina da komuniciraju i dogovore procjenu posla. Kao primjer, zamislite da vi i ja odlučimo da trčimo zajedno. Ja volim trčati ali sam jako spor. Vi ste, s druge strane, vrlo brz trkač. Pokažete mi na stazu i kažete, "Hajdemo odtrčati ovu stazu. Trebaće nam 30 minuta."

Meni je ta staza poznata, ali obzirom da sam dosta sporiji trkač, znam da mi je potrebno 60 minuta da pretrčim tu stazu. Kažem vam da ću trčati sa vama ali da će nam trebati 60 minuta.

I tako počne rasprava. "30." "60." "30." "60."

Na taj način nećemo nigdje stići. Možda ćemo napraviti kompromis i reći da nam je potrebno 45 minuta, što je vjerovatno najgora stvar koju bi mogli napraviti. Imali bi procjenu koja nije dobra ni za koga.

Pa umjesto kompromisa od 45 minuta, nastavljamo raspravu. "30." "60." "30." "60."

Naposljetku mi kažete, "Majk, to je staza od 5 milja. Ja je mogu pretrčati za 30 minuta."

A ja vam kažem, "Slažem se: to jeste staza od 5 milja. Meni je za nju potrebno 60 minuta."

Problem je što smo obadvoje u pravu. Vi je zaista možete pretrčati za 30 minuta, a meni je zaista potrebno 60. Kada pokušavamo dati vremensku procjenu za ovu stazu, nalazimo da to ne možemo uraditi jer radimo (trčimo) različitim brzinama. 

Ali, ako koristimo apstraktniju jedinicu mjere — u ovom slučaju, milje — možemo se složiti. I vi i ja se slažemo da je staza duga 5 milja. Samo se razlikujemo u tome koliko će svakome od nas trebati da je pretrčimo. 

Story point-i služe u istu svrhu. Oni dozvoljavaju pojedincima različitih sposobnosti i brzine rada da nađu zajedničku riječ. Umjesto brzog i sporog trkača, zamislite dva programera različita po produktivnosti. 

Kao u slučaju trkača, ova dva programera se mogu složiti da je neki user story 5 poena. "Brži" programer možda razmišlja da je u pitanju jednostavna funkcionalnost za koju mu treba samo jedan dan. "Sporiji" programer možda razmišlja da će mu trebati dva dana posla. Ali obadvoje se slažu da to procjenjuju sa 5 poena, jer je broj poena koji se dodjeljuje prvom user story-ju poprilično proizvoljan. 

Ono što je bitno je da se, jednom kad se dogovore da je prva korisnička priča (user story) 5 poena, naša dva programera mogu lakše složiti u sljedećim procjenama. Ako brzi programer misli da mu za novu korisničku priču trebaju dva dana (dvostruko više vremena u odnosu na korisničku priču koju je procijenio sa 5 poena), on će procijeniti novu korisničku priču sa 10 poena. Tako će i drugi programer, ako ona misli da će joj za taj posao trebati četiri dana (dvostruko više vremena u odnosu na korisničku priču koju je procijenila sa 5 poena).

Tako da, poput udaljenosti od nosa do palca ispružene ruke Kralja Henrija, upotreba story point-a omogućava koncenzus između pojedinaca koji posao rade različitom brzinom.

About the author
Mike Cohn
Author: Mike CohnWebsite: http://www.mountaingoatsoftware.com/
Agile Software Practitioner, Coach, Author and Owner at Mountain Goat Software
About:
Mike Cohn is one of the contributors to the invention of the Scrum framework. He is one of the founders of the Scrum Alliance and owner of Mountain Goat Software, a company that provides training on Scrum and Agile software development techniques.He began his career in the early 1980s as a Programmer in APL and BASIC before moving on to C++ and Java and running development groups. Cohn ran his first Scrum project in 1995 and has been a vocal proponent of Scrum ever since. Cohn is the author of Agile Estimating and Planning, User Stories Applied for Agile Software Development and Succeeding with Agile: Software Development using Scrum, as well as books on Java and C++ programming[4] and articles for Better Software, IEEE Computer, Software Test and Quality Engineering, Agile Times, Cutter IT Journal, and the C++ Users' Journal. He is also the editor of the Addison-Wesley Mike Cohn Signature Series of books. In 2012, Cohn was named #1 in The Top 20 Most Influential Agile People.

Social Comments