Agilne metrike predstavljaju alate za praćenje napretka i ostvarenja ciljeva agilnih projektnih timova.
Kada se pravilno definišu, metrike pružaju dragocen uvid u performanse tima, nivo kvaliteta, efikasnost testiranja, kao i sveukupnu uspešnost, i kako se ona razvija tokom vremena.
Osnovni cilj agilnih metrika je da pomognu timovima da identifikuju oblasti u kojima mogu da se poboljšaju i da donesu odluke zasnovane na podacima, što će voditi ka stvaranju boljih proizvoda kako tim napreduje.
U praksi, kompanije često definišu metrike koje su ili površne i ne odražavaju pravo stanje, ili su samo sirovi brojevi koji imaju tendenciju rasta. Takve metrike mogu delovati lepo na kontrolnim tablama, ali su uglavnom beskorisne za sam tim.
Njihova svrha nije da pomognu timu u bilo kom smislu, već da popune izveštaje za menadžment, što potom vodi ka donošenju strateških odluka. Nažalost, tim često ne razume razloge iza tih odluka.
Pritisnuti da ispune takve pogrešne metrike, timovi često manipulišu svojim procesima kako bi metrike izgledale bolje, dok se stvarni učinak tima ne poboljšava.
Osnovne Metrike
Postoji više načina za klasifikaciju metrika. Najosnovnija podela je na metrike „odozgo prema dole“ i „odozdo prema gore“.
➡ „Odozgo prema dole“ znači da menadžment kreira metrike koje svi treba da ispune, a krajnji cilj je da se rezultati uklope u unapred definisane okvire. Nije bitno da li se tim slaže sa tim metrikama ili ne; ovo su metrike koje se prate.
➡ „Odozdo prema gore“ znači da tim identifikuje oblasti u kojima želi da se poboljša, i na osnovu toga definiše metrike koje će pratiti napredak tima ka svojim ciljevima. Na ovaj način tim može pokazati menadžmentu kako su unapredili svoj rad tokom vremena.
Definicija Dobre Metrike
Šta čini dobru metriku i kako je opisati?
Najvažnija karakteristika je da metrika treba da podstiče promenu ponašanja. To znači da, kada pogledate rezultat metrike, jasno vam je šta tim treba da promeni kako bi se poboljšao.
Metrika takođe treba da bude jednostavna. Ako ne možete da je objasnite u nekoliko rečenica tako da je svi relevantni ljudi razumeju, onda nešto nije u redu.
Dobra metrika se može upoređivati tokom vremena. Snimite rezultate u jednom trenutku, pa ponovo kasnije, i uporedite ih. Ako ne možete da uporedite rezultate, treba razmisliti o promeni metrike.
Na kraju, metrika treba da bude odnos ili procenat, kad god je to moguće, a ne samo čisti broj. Na primer, „10 novih otvorenih defekata tokom sprinta“ ne govori mnogo, osim ako ne znate da li obično imate jedan ili 100.
Evo nekoliko primera metrika koje, po mom mišljenju, ispunjavaju sve gore navedene kriterijume. Posebno su osmišljene za agilne timove. Podeljene su u tri glavne kategorije: performanse, kvalitet i moral.
Kategorije Metrika
Metrike Performansi
Cilj je da se razume koliko je tim uspešan u realizaciji planiranih zadataka tokom sprinta. Metrike treba da pomognu u proceni da li tim preuzima previše obaveza, ili da li je postalo uobičajeno da se zadaci prenose iz sprinta u sprint.
Sa stanovišta agilnog načina rada, tim treba da teži isporuci planiranog sadržaja za koji se obavezao na početku sprinta.
To ne znači da nećemo biti fleksibilni u razmeni zadataka tokom sprinta, ali to treba da budu pregovori koji vode ka razmeni, a ne ka dodavanju. Kapacitet tima se ne povećava samo zato što su dodati novi zadaci u sprint.
Ovom metrikom želimo da pratimo takve slučajeve i podstaknemo sve u timu da zaštite kapacitet koji imaju za sprint.
Ovo povećava pouzdanost i predvidivost tima.
#1. Kapacitet Sprinta u Odnosu na Isporucene Bodove Priče
Pratite istoriju kapaciteta sprinta u odnosu na broj isporučenih bodova priče (SP) tokom različitih sprintova.
- Manja odstupanja od sprinta do sprinta su prihvatljiva. Veliki skokovi u bilo kom smeru ukazuju da nešto nije u redu.
- Ukupan kapacitet sprinta se računa sabiranjem raspoloživih dana svakog člana tima. Na primer, ako tim ima 10 ljudi i svi su dostupni tokom celog sprinta, ukupan kapacitet za sprint je 100.
Proverite kapacitet sprinta u odnosu na završene SP od sprinta do sprinta. Ako se tim (tokom planiranja) obaveže na znatno više SP-ova nego što tim obično može da završi, upozorite tim na ovaj rizik.
Cilj je da ukupan broj planiranih SP-ova bude jednak ili manji od ukupnog broja završenih SP-ova po sprintu.
Možete imati više završenih SP-ova od planiranih ako je tim završio sve planirane zadatke i ima preostali kapacitet da preuzme dodatni zadatak.
- Ako tim više puta isporučuje manje SP-ova od planiranih, treba da preispita svoj proces planiranja i da preuzme manje SP-ova u sledećem sprintu.
Alati kao što su monday.com, Atlassian Jira ili Asana olakšavaju čuvanje i izvlačenje bodova priča za svaki zadatak u sprintovima. Neki od njih mogu i automatski da generišu izveštaje nakon svakog planiranja sprinta.
#2. Burndown Grafikon
Ovo je jedan od pokazatelja koje većina scrum timova ima negde skrivene na kontrolnoj tabli. Razumem zašto bi ovo moglo delovati kao beskorisna metrika. Tim retko obraća pažnju na grafikon, dok menadžeri ističu da zadaci ne napreduju dobro (jer su svi otvoreni tokom celog sprinta).
Želim da istaknem da i tim treba da prati ovaj grafikon radi sopstvenog dobra. Ako su svi zadaci otvoreni tokom celog sprinta, i zatvaraju se samo poslednjeg dana, to stvara neizvesnost u timu i otežava ostvarenje ciljeva sprinta.
- Pregledajte sprint tablu i obratite pažnju na završene zadatke.
- Proverite sa timom zašto su mali zadaci još uvek otvoreni, čak i ako su započeti na početku sprinta.
- Radite sa timom na promeni načina razmišljanja kako zadaci ne bi ostajali otvoreni duže nego što je potrebno.
- Idealan burndown grafikon je obično teorijsko stanje. Međutim, što se više približavamo idealnom stanju, efikasnije upravljamo zadacima.
Alati za agilno upravljanje kao što je Asana mogu automatski generisati burndown grafikon za svaki sprint.
Izvor: asana.com
#3. Završetak Cilja Sprinta
Ova metrika prati procenat ciljeva sprinta koje ste postigli tokom svakog sprinta.
Ciljeve sprinta dokumentujete zasebno, na primer, na Confluence ili Jira stranici, za svaki sprint. Status će biti dodeljen u zavisnosti od toga da li su ciljevi ispunjeni ili ne.
Čak i ako tim nije završio sve zadatke u okviru sprinta, i dalje može da postigne cilj sprinta (npr. nedostaju samo sporedni zadaci).
Cilj je da se u svakom sprintu postigne 100% ciljeva sprinta. Ako to nije slučaj, otkrijte šta sprečava tim da ostvari ciljeve.
- Ako je previše paralelnih tema u svakom sprintu, smanjite njihov broj.
- Ako se tokom sprinta dodaje previše ad hoc zadataka, smanjite ih kako ne bi uticali na prvobitne ciljeve sprinta.
- Ako su ciljevi sprinta preveliki ili previše izazovni, pojednostavite ih. Nema smisla imati velike ciljeve u sprintu, a ne ispuniti ih do kraja.
Metrike Kvaliteta Koda
Ove metrike prate kvalitet koda tokom vremena. Pomažu u održavanju zdravih razvojnih procesa i smanjuju vreme utrošeno na rešavanje problema, kao i vreme čekanja programera tokom razvojnih i testnih aktivnosti.
Izvor: azuredevopslabs.com
#1. Automatizovani Testovi
Programeri treba da kreiraju automatizovane testove za svaku promenu koju naprave.
- Izmerite pokrivenost koda automatizovanim testovima – koristite Azure Pipelines ili SonarCloud za pokretanje testova. Cilj je pokrivenost od 85%. Preko 90% nije efikasno.
- Uverite se da je automatizovano kreiranje testova jedinica deo definicije „završeno“ za nove zadatke.
- Postepeno povećavajte pokrivenost starijeg koda testovima, kao deo zadataka za tehnički dug u zaostatku.
#2. Složenost Koda
Procenite nepotrebne komplikacije koje se pojavljuju u kodu tokom vremena i aktivno ih rešavajte putem zadataka za tehnički dug, ili sprečite da se pojave ako je moguće.
Definišite standarde i smernice za kod kako biste obučili programere da ih se pridržavaju. Uverite se da se poštuju pravila kodiranja kako bi se minimiziralo nepotrebno povećanje složenosti koda. Redovno ažurirajte smernice na osnovu iskustva tima.
Identifikujte „mirise koda“ – indikatore potencijalnih problema u kodu, kao što su duplirani kod, dugačke metode i nekorišćene promenljive.
Stručnjaci treba da obezbede da se standardi koda primenjuju na novokreirani kod.
Koristite alate kao što su Azure DevOps ili SonarCloud kontrolne table i izveštaje kako biste otkrili probleme u kodu.
#3. Ručni Koraci u Implementaciji
Pratite koliko ručnih koraka tim treba da uradi da bi pustio kod u testno ili produkcijsko okruženje.
- Naš cilj je da vremenom postignemo 0 ručnih koraka.
- Kreirajte zadatke za tehnički dug ako je potrebno kako biste doveli implementaciju do automatizovanog sistema. Postepeno smanjujte preostale ručne korake u procesima od sprinta do sprinta.
Metrike Morala
Ove metrike prate kako se tim oseća u vezi sa svojim radom i procesima sa kojima se svakodnevno bavi.
#1. Retrospektivno Ispunjenje Sprinta
Možete pratiti koliko je dogovorenih akcija stvarno završeno u sledećem sprintu.
- Scrum Master će prikupiti rezultate sa retrospektivnog sastanka i uneti ih na timske stranice kako bi pratio dogovorene akcije.
- Tim će zatim pratiti napredak.
- Menadžment projekta može da pregleda da li akcioni zadaci napreduju i šta sprečava tim da ih završi. Zatim treba da izmeni okruženje kako bi tim mogao da napreduje sa dogovorenim akcijama.
Najmanje 33% ili 1 (u zavisnosti od toga šta je više) akcionih zadataka iz prethodnog sprinta biće usvojeno u narednim sprintovima.
Ako je manje od toga, potrebne su promene kako bi se timu omogućilo da primeni poboljšanja koja su dogovorena.
Alati za upravljanje projektima sadrže šablone spremne za korišćenje za retrospektivne aktivnosti sprinta. Evo primera sa monday.com:
Izvor: monday.com
#2. Timska Saradnja
Programiranje u paru.
- Formirajte prirodne parove po zadacima kako biste zajedno radili, delili zapažanja, znanje i uspeh. Kreirajte podzadatke unutar zadataka koje poseduju različiti članovi tima.
Recenzije koda od strane kolega.
- Kolege treba da iniciraju ili preduzmu radnje kako bi pregledali tuđi kod.
Metrike se mogu izdvojiti sa monday.com/Asana/Jira table iz podzadataka.
Najmanje 50% zadataka u sprintu treba da bude podeljeno među članovima tima. Ako je manje, istražite razloge i preduzmite mere gde je to smisleno.
Za dobrovoljne recenzije kolega, pratite zadatke sa namenski definisanim podzadacima. U početku, 20% pregledanog koda je dobar početak. Postepeno, tokom sprintova, treba da podstičete i motivišete tim da radi više kolaborativno i da poveća broj pregleda na 50% po sprintu.
#3. Tehnički Dug u Odnosu na Nove Zadatke sa Funkcionalnošću
Izvor: atlassian.com
Dajući timu priliku da reši sopstvene dugove, povećaćete zadovoljstvo tima svojim radom.
- S druge strane, gomilanje tehničkih dugova bez plana za njihovo progresivno rešavanje će vremenom demotivisati tim. Rešenje će postati nestabilnije, složenije i teže za rešavanje bez suštinskih prepravki.
Tim najbolje zna šta ne funkcioniše dobro u rešenju, čak i ako zainteresovane strane ili krajnji korisnici to ne vide. Takvi zadaci imaju najveći uticaj na sam razvojni tim. Za zainteresovane strane, oni mogu biti nevidljivi. Zbog toga je važno dati timu priliku da radi na zadacima koji će im pomoći da se ne zatrpaju razvojnim aktivnostima.
Cilj je da se prati koliko je tehničkih dugova rešeno tokom vremena i da li zaostatak takvih zadataka raste ili ne.
Tim može da označi zadatke kao „Tehnički dug“ u zaostatku i da im da prioritet, kako bi bili izabrani u sprintovima.
U zavisnosti od stanja projekta i količine tehničkih dugova, možda ćete želeti da osigurate da zaostatak „Tehničkog duga“ ne raste za više od 10% iz sprinta u sprint.
Dajte prioritet zadacima za tehnički dug i uključite ih u sprintove kako biste držali rast zaostataka pod kontrolom, i kako bi timu bilo dozvoljeno da radi na tehničkim dugovima 10-20% vremena svakog sprinta.
Završne Reči
Svaki projekat će na kraju trebati neke metrike, bilo zato što menadžment to želi ili zato što tim odluči da meri sopstveni uspeh.
Najbolje što možete da uradite je da počnete da gradite svoju biblioteku metrika spremnu za korišćenje, što pre to bolje. I dok to radite, vodite računa da pre svega uvek koristite metrike koje menjaju ponašanje.
Zatim obratite pažnju na nezdrave procese koji mogu uništiti vaš sprint.