Všetci sme sa mýlili, velocity nie je dôležitá.

cover

Rozmachom Agile sa paleta nástrojov a praktík používaných pri vývoji produktov v IT prudko zväčšila. Začiatok poznamenaný Extrémnym programovaním a neskôr Scrum frameworkom, podľa názoru firiem, nedostatočnou adaptáciou korporátnemu prostrediu zvyknutému na väčšiu kontrolu, motivoval Agile mentorov k hľadaniu odpovedí na potreby agilných organizácií.

Najčastejšou potrebou bolo odhadovanie a mať kontrolu nad dodávkou aj v čase, kedy agilné tímy tvrdili, že rozsah sa môže meniť.

Takto sa objavili aj ďalšie koncepty a praktiky ako napr. User stories, Program Increments a v neposlednom rade storypoints.

Storypoints sú asi najčastejšou témou diskusii pri zavádzaní Agile a pri jeho implementácii. Ale to je určite na inú debatu. Viď aj predchádzajúci článok kolegu Martina Lukniča o odhadoch v Agile.

Práve storypointy priniesli možnosť merania výkonnosti agilných tímov. Aspoň si to tak vo firmách vyložili. Bohužiaľ, aj vďaka nedostatočným schopnostiam a znalostiam Scrum Mastrov a Agilných koučov. Pretože treba si priznať vinu. Práve roly, ktoré by mali edukovať  a nastavovať systém, dovolili nesprávnu aplikáciu princípov až v príliš mnohých prípadoch v praxi.

Dnes tak nie je neobvyklé počuť vo firmách ako lietajú porovnávania rýchlosti (velocít) tímov.

Tento tím je lepší lebo má vyššiu velocitu, nemohli by ste dať viac, prečo vám velocita tak kolíše?

Zle, zle, celé zle!

Čo je velocity?

Velocity je metrika, ktorá meria sumu storypoints pre dokončené položky sprintu.

Problémom č.1 je práve zmienka o položkách šprintu. Nielen User stories. V sprinte by ste predsa mali mať aj nejaké opravy chýb, prevádzkové tickety, technologické  stories. Tie predsa tím spracoval tiež. No z nejakého zvláštneho, a pre mňa nepochopiteľného dôvodu, do velocity niektoré organizácie zarátavajú iba User stories. Teda iba biznisové požiadavky. Výhovorka je jednoduchá.

Chyby ani tickety sa vraj nedajú odhadnúť v storypoints. Hmmm, to ale vôbec nie je pravda.

Problém c. 2 je úplne mimo misu. Velocity per človek alebo rola. Rola je zvyčajnejšia. Velocity testerov je X, backendisti Y, Frontend Z, mobilikáči M. Velocity tímu sa ráta súčtom velocit rolí. Opäť to indikuje fundamentálne neporozumenie, ktoré vždy začína nesprávnym porozumením storypointov, ich aplikácie v tíme a dotýka sa aj pravidiel fungovania tímu a samotnej definície kto sme my ako tím.

Takto podporované skupiny ľudí totiž tímom nikdy nebudú. Budú naďalej iba rolami, a teda kapacitami, v tíme.

Ďalším problémom velocity je, že sa aplikuje ako metrika hodnotiaca aktuálny, alebo práve dokončený sprint. Správne je túto hodnotu spočítať v aktuálnom sprinte.

Nesprávne je použiť velocity pre hodnotenie tímu a aktuálneho šprintu.

Velocity je totiž nástrojom produktového vlastníka. Nie tímu. Nie, nepomýlil som sa.

Produktový vlastník môže využiť velocity, a predovšetkým jej minimálnu, maximálnu, a priemer posledných 8 sprintov, pre rozpracovanie ďalších požiadaviek. Iba toľko, koľko tím stihne v ďalšom šprinte podľa velocity dokončiť. Je zbytočne pripravovať viac. Aj tak to nemusia dokončiť. Vaša práca produktového vlastníka tak skončí v zásuvke stola. A kým sa dostane na radu, možno ju opäť bude treba predefinovať, lebo nastane zmena.

Velocita je síce lagging metrika, ale používa sa ako leading metrika. A to je jej tajomstvo, ktoré málokedy je v praxi pochopené.

Velocity je v práci, hoc aj v jednej firme, tak rôznorodo aplikovaná, že veľmi nemá zmysel sa ňou zapodievať na úrovni produktu, programu alebo nebodaj portfólia.

Velocity je nástrojom produktového vlastníka. Je odmerkou koľko ‘vody’ sa má do pomyselnej fľaše sprintu naliať.

Bodka.  Dokonca veľká bodka.

Sám Ron Jefferies, ktorý storypointy vymyslel, skonštatoval, že to bol jeho veľký omyl. Nedocenil čo sa v praxi s idealistickou myšlienkou stane.

I like to say that I may have invented story points, and if I did, I’m sorry now. Let’s explore my current thinking on story points. At least one of us is interested in what I think.“ … „I certainly deplore their misuse; I think using them to predict “when we’ll be done” is at best a weak idea; I think tracking how actuals compare with estimates is at best wasteful; I think comparing teams on quality of estimates or velocity is harmful.“ – Ron Jefferies, Story Points Revisited

Storypointy, a týmpádom aj velocity, sú z pohľadu biznisu a klientov nič nehovoriace magické čísla.

Podstatná je odpoveď na otázku, ktorú sa nás pýtajú aj malé deti. Hlavne počas cesty.

Kedy tam budeme?  Kedy bude ten výsledok hotový a kedy zažijete zážitok z výsledku?

Podstatnejší ako velocity je teda čas dodávky. Kedy bude požiadavka hotová. Dnes jednoducho v biznise vyhráva čas.

Agile je o funkčných produktoch. Nie dosiahnutej a správne odhadnutej velocity.

MetrikyProduct OwnerScrum MasterAgile

Mohlo by Vás zaujímať

Agilne je … keď používame postity

Agilne je … keď používame postity

Pred niekoľkými týždňami som pri vysvetľovaní Agile senior manažmentu zažil zaujímavý moment. Pri ukazovaní prostredia...

Produktový vlastník. Rodič produktu?

Produktový vlastník. Rodič produktu?

Nie tak dávno sme sa stretli s nastavením roly Produktového vlastníka, ktoré odrážalo maximálne možnosti, ktoré...

Používanie AI na odhadovanie?

Používanie AI na odhadovanie?

Milan, účastník nášho trénigu, sa ma tento týždeň spýtal: „Čo si myslíš o používaní AI na odhadovanie...

Novinky

Naše Agiloviny

Nenechajte si ujsť výber toho najlepšieho z Agile, s čím sa stretli naši mentori. Nielen zo sveta produktov, vývoja, tipov a trikov, ale občas aj humoru. Posielame pravidelne, raz za občas :) #QualityOverQuantity

Posielať na

spracovaním osobných údajov

Ďakujeme