KPIs per equips de desenvolupament de programari – Arragonán – Dani Latorre

Com a part de la meva feina en l’últim any, he intentat empènyer la cultura de millora contínua en els diferents equips amb els que he anat treballant . Tant en qüestions d’eines i habilitats tècniques, com en les de comunicació i coordinació, amb certes restriccions i dependències que cauen fora del nostre marge d’influència.

Partim de el supòsit que com millors siguin les pràctiques de l’equip , millor capacitat de lliurament tindrà. Això es tradueix en una major adaptabilitat als canvis, una millor mantenibilitat del programari amb el pas el temps i possiblement una major motivació de l’equip amb el seu treball.

A més de les típiques sensacions subjectives d’efecte de millora, havíem de pensar en indicadors que ens permetessin anar observant realment. En algun moment, també es començaria a voler tenir visibilitat des de fora dels equips, així que tocava donar-li una volta i ordenar idees.

Vaig estar preparant una presentació per explicar internament com estàvem treballant, cap a on creia que havíem de anar a través d’una millora contínua, els diferents KPIs que podríem observar i les necessitats que es cobririen amb una bona capacitat de lliurament.

Diapositiva d'una presentació amb la visió de la qual cosa, com a equip hauríem cobrir: adaptabilitat respecte a negoci, lliurar aviat, evitar retreball, una bona UX i evitar errors en la mesura possible

“Digues-me com em fas i et diré com em comporto “

Desconec l’origen, però amb aquestes coses sempre em acord d’aquesta dita. Cal anar amb compte amb quins indicadors (que no objectius) anem a mesurar. a més, haurem de fer servir diversos per compensar el foment de comportaments estranys que falsegen aquestes mètriques.

Amb l’ús normal de les eines, només acordant algunes convencions, es pot facilitar l’explotació de dades posterior per extreure mètriques. Els orígens de dades per als indicadors són:

  • El codi
  • El repositori i servidor d’automatització
  • Les eines de gestió
  • el mateix producte

Indicadors de el codi

Les eines d’anàlisi estàtic de codi ens donen nombres sobre deute tècnica que existeix. No hem de perdre de vista aquests indicadors i dedicar temps a analitzar i fer neteja específica de tant en tant. Unes vegades es resolen amb solucions simples i altres amaguen problemes de disseny que no resulten tan evidents.

La cobertura de test és un dels indicadors més habituals, el més interessant en aquest cas és veure què NO està cobert . I com se sol comentar, cal anar amb compte perquè és un indicador fàcil de falsejar si es busca com a objectiu.

En un moment donat, a més, es podria utilitzar mutation testing (comprovar que es trenca algun test a l’modificar codi de producció) per tenir un indicador de la qualitat dels tests unitaris.

indicadors de l’repositori i servidor d’automatització

Hi ha força indicadors interessants que es poden treure dels repositoris i servidors d’automatització, tot i que majoritàriament són dependents de les convencions d’ús.

No obstant això, un indicador sempre vàlid i que penso que hauria d’observar-és la freqüència d’integració.

la integració contínua és una pràctica (que no eina) tan popular com mal interpretada, ja que fins que no s’uneix la feina que ha fet o està fent una persona amb la branca principal de desenvolupament i es completa una build, no l’estem realitzant.

Fins que no ha acabat correctame nt la construcció d’un artefacte de programari, no sabem si tot està correcte. A més freqüència, feedback més d’hora i menor incertesa.

En cas d’usar branques, també és interessant veure la durada de vida de les branques. A més temps, més risc de conflictes o altres problemes a l’integrar.

I si s’utilitzen pull / merge requests, també hi ha un grapat d’indicadors que en un moment donat puguin treure’ns olors relacionats amb la capacitat de lliurament : quantitat de comentaris, temps que queden obertes, quantitat de rebutjos …

Indicadors de les eines de gestió

les eines de gestió, a més de servir com a radiador d’informació per saber la situació actual de la construcció de l’producte i ajudar a coordinar la feina, són una bona font d’informació d’indicadors de el procés de treball.

Per observar la capacitat de tot l’equip en conjunt de fer vertical slicing és molt útil conèixer el temps de cicle. A menor temps de cicle, més gran és la nostra capacitat de lliurament. És el temps que es triga des que es comença a treballar en alguna cosa que aporti valor (per exemple, una història d’usuari) fins que passa a estar fet.

És habitual que en algun punt de les eines de gestió es poden observar els diferents desplegaments que s’han realitzat, on puguem obtenir la freqüència de desplegament. Evidentment a major freqüència, millor.

Encara que el nostre temps de cicle fos curt i la freqüència de desplegament alta, seria possible que el nostre producte fora fràgil a causa de bugs. Per això l’indicador de bugs detectats i resolts per versió / desplegament és una altra mètrica a tenir sempre en compte.

Depenent de el moment i escenari en què es trobi un producte, també em sembla molt interessant l’indicador de l’ lead time, el temps que passa des que es demana alguna cosa nova fins que està desplegat en producció. Que vindria a ser conseqüència dels 3 anteriors indicadors i de la mida de la pila de producte.

Com suposo que hi hagi qui pugui fer-lo fora a faltar, ometo intencionadament els indicadors a l’respecte de les estimacions, tipus story points per iteració. Al meu entendre, tenen un component molt subjectiu i variable per a ser utilitzat com a indicador de canvi en la capacitat de lliurament d’un equip.

Indicadors de el propi producte

A més d’un altre tipus de instrumentació molt més minuciosa que necessiten els membres de l’equip de gestió de producte o disseny, l’equip de desenvolupament hauria de poder observar el nombre i percentatge d’ús per funcionalitat, que a la fi defineix l’èxit o no de la feina de tots.

el més interessant d’aquest indicador és que combinat amb altres mètriques pot ajudar a prendre decisions sobre l’evolució del producte. Com per exemple, aquest escenari:

  1. Vam detectar problemes molt greus de rendiment en una part del producte.
  2. Observem que el percentatge d’ús de la funcionalitat afectada per aquests problemes és residual.
  3. Vam decidir no resoldre-ho de moment, però el reflectim a la pila de el producte com una cosa poc prioritari.
  4. Configurem un avís per detectar cert augment en el percentatge d’ús d’aquesta funcionalitat .

Un altre indicador important és el crash rate del producte, quantes vegades es detecta una fallada o error per quantitat d’ús, que ens permet saber el que esta que és un producte. I barrejat amb l’indicador de nombres d’ús per funcionalitat, ens permet detectar els punts problemàtics.

Depenent de l’context de l’producte i de l’negoci, possiblement puguem treure també altres indicadors rellevants d’operacions i suport que siguin conseqüència de l’ ús del producte.

Mesurar sense perdre el focus

Aquests són molts KPIs diferents. És interessant observar-los perquè ens poden servir per detectar olors sobre problemes i oportunitats de millora, però són massa per intentar millorar tot alhora.

Per evitar diluir-nos i no acabar millorant en res, hauríem triar i enfocar-nos en un parell d’aquests indicadors cada vegada, depenent de la situació de cada equip.

I encara que sigui temptador fer-ho, evitaria fer servir alegrement aquests indicadors per marcar objectius, així com per avaluar a equips diferents.

No oblidem que el propòsit de mesurar aquests indicadors és observar l’evolució en el temps d’un equip treballant en un producte i context determinat.

Leave a Comment

L'adreça electrònica no es publicarà. Els camps necessaris estan marcats amb *