El teu equip està pagant deute tècnic a cada esprint?

L'esprint review es converteix en un déjà vu. L'equip es va comprometre a cinc històries, en va tancar tres, i dues van quedar "gairebé acabades". Ningú va fallar. Ningú es va escaquejar. Simplement, les coses van trigar més del previst.

Quan això passa una vegada, és una estimació optimista. Quan passa tres esprints seguits, hi ha alguna cosa a sota.

Aquesta cosa, en la majoria dels casos, té un nom: deute tècnic. No el deute obvi —el que tothom assenyala i ningú no arregla—, sinó el invisible. La que es manifesta com a lentitud, com a imprevistos, com a hores que desapareixen sense que ningú sàpiga exactament on van anar.

Per què el deute tècnic no apareix al teu backlog

La majoria d'equips no rastregen el deute tècnic de manera explícita. No hi ha un tiquet que digui “perdre quatre hores entenent un mòdul que ningú va documentar”. Ni un que digui “refer la meitat de la feina perquè una dependència desactualitzada genera conflictes”.

Aquestes hores es dilueixen dins dels tiquets de producte. Una història estimada en cinc punts n'acaba costant vuit, i ningú investiga per què. L'equip assumeix que va estimar malament. El product owner assumeix que lequip és més lent del que hauria.

Segons l' informe State of DevOps de DORA , els equips d'alt rendiment dediquen menys del 15% del temps a treball no planificat. Els equips amb deute tècnic alt poden superar el 40%. Aquesta diferència no apareix a cap gràfic de velocitat. Però explica per què el roadmap s'endarrereix esprint rere esprint.

El primer problema del deute tècnic al delivery no és que existeixi. És que ningú no la mesura.

Els senyals que indiquen que estàs pagant interessos

No necessites una auditoria de codi per detectar que el deute tècnic està afectant el delivery. Hi ha senyals que qualsevol producte owner, engineering manager o CTO pot identificar observant el dia a dia de l'equip.

La velocitat de l'esprint baixa sense raó aparent. L'equip no ha canviat, el scope és semblant, les tecnologies són les mateixes. Però cada esprint lliura menys. La corba de velocitat baixa de manera gradual, no abrupta.

És com una aixeta que degota: no ho notes fins que veus la factura de l'aigua.

Les estimacions fallen sistemàticament cap amunt. Tot triga més del previst. No un 10% més –un 50% o un 100% més. I no pas perquè l'equip estimi malament, sinó perquè cada tiquet arrossega un cost ocult que no es veu fins que algú obre el codi.

Els bugs apareixen a zones que ningú va tocar. Canvies el mòdul de pagaments i es trenca la notificació de correus electrònics. Això indica acoblament ocult: mòduls que depenen entre si de formes que ningú no va documentar ni va preveure. És una de les formes més costoses de deute tècnic perquè converteix cada canvi en una loteria.

L'equip dedica temps a “investigar” abans de poder treballar. Si abans de desenvolupar una feature l'equip necessita dos dies per entendre el codi existent, llegir commits antics i parlar amb la persona que va escriure aquest mòdul fa tres anys estàs pagant interessos. Aquest temps d'arqueologia no és desenvolupament: és el peatge del deute.

Els pull requests s'engrandeixen sense que el scope creixi. Una història de dos punts genera un PR de 800 línies perquè, per implementar el canvi, es va haver de moure, reanomenar i corregir codi al voltant. El volum del PR no reflecteix la complexitat de la feature, sinó la complexitat del deute.

Com mesurar l'impacte real al delivery

Detectar els senyals és el primer pas. Però per actuar, necessites quantificar. No cal un sistema sofisticat. Només cal mesurar unes poques coses durant tres o quatre esprints consecutius.

Ràtio de treball planificat vs. no planificat

De tota la feina que fa el teu equip en un esprint, quant estava al pla i quant va aparèixer sobre la marxa? Bugs urgents, correccions necessàries per avançar, investigacions imprevistes, ajustaments per dependències trencades.

Tot això és feina no planificada.

Si el treball no planificat supera el 25-30% de l'esprint de forma sostinguda, el deute tècnic probablement és darrere. Mesurar això és senzill: en tancar cada esprint, classifica els tiquets completats com a "planificats" o "emergents". A tres esprints tens una tendència.

Temps de cicle per tipus d'història

El cycle time –el temps des que algú comença a treballar en un tiquet fins que està en producció– és un dels indicadors més reveladors. Però el número absolut diu poc. El que importa és comparar-ho.

Si les històries en mòduls nous (codi net, sense legacy) tenen un cycle time de dos dies, i les històries en mòduls antics triguen sis dies de mitjana, la diferència és deute tècnic pur. No és que un mòdul sigui més complex conceptualment: és que el codi ho fa tot més lent.

Eines com Jira, Linear o Shortcut ja rastregen el cycle time. Només cal segmentar per àrea del producte. Si el teu equip treballa amb Django com a backend, per exemple, pots comparar el cycle time dels mòduls legacy davant dels més recents.

Factor d'expansió dels tiquets

Mesura la diferència entre l'estimació original i l'esforç real. Si un tiquet estimat en 3 punts n'acaba costant 8, el factor d'expansió és 2.6x. Fes la mitjana per esprint i per àrea del codi.

Un factor d'expansió superior a 1.5x de forma consistent indica que les estimacions no estan malament: indica que hi ha feina oculta que no es pot preveure fins que obris el codi. Aquest treball ocult és deute tècnic manifestant-se.

Taxa de reobertura de tiquets

Amb quina freqüència es reobre un tiquet que ja estava tancat? Una taxa de reobertura alta –per sobre del 10-15%– suggereix que el codi és fràgil, que els tests són insuficients o que els canvis tenen efectes secundaris inesperats. Tot això és deute tècnic.

Els paranys que dissimulen el problema

El deute tècnic al delivery és especialment perillós perquè els equips i les organitzacions desenvolupen mecanismes inconscients per dissimular-lo.

Reduir el scope en comptes de qüestionar la velocitat. Si l'equip lliura menys, la solució fàcil és planificar menys. L'esprint s'adapta a la velocitat reduïda i el problema desapareix del radar. Però no ha desaparegut: simplement has normalitzat que el teu equip lliuri la meitat del que podria.

Confondre activitat amb progrés. Els desenvolupadors estan ocupats, els PRs es mouen, els dailies reporten avenços. Però el producte gairebé no canvia. Hi ha molt moviment i poc desplaçament. Si midessis quantes línies de codi de l'esprint són funcionalitat nova versus manteniment forçat, el resultat et sorprendria.

Culpar les estimacions. "Estimem malament" és l'explicació per defecte quan alguna cosa triga més del previst. I de vegades és cert. Però si les estimacions fallen sempre a la mateixa adreça ia les mateixes àrees del codi, el problema no és l'estimació.

Normalitzar els bugs com a “part del procés”. Tots els projectes tenen errors. Però si el vostre equip dedica més d'un 15-20% de l'esprint a corregir defectes en codi existent (no bugs de features noves), la base de codi està generant treball de manteniment que competeix amb el desenvolupament de producte.

Què fer quan confirmes el problema

Si després de mesurar durant uns esprints les xifres confirmen el que ja sospitaves, el pas següent no és obrir un tiquet èpic d'"arreglar el deute tècnic". És fer visible el cost.

Tradueix el deute a llenguatge de negoci

Les dades tècniques convencen els desenvolupadors. A la resta de l'organització us cal parlar en un altre idioma.

No diguis “tenim acoblament alt i cobertura baixa”. Digues: "cada feature nova ens costa un 60% més del que deuria perquè el codi base ens frena. En els últims tres mesos, això equival a X setmanes de desenvolupament perdudes, que podrien haver-se dedicat a les funcionalitats que el negoci necessita".

L' informe de Stripe de 2018 va estimar que el deute tècnic costa a la indústria global de programari 85.000 milions de dòlars anuals en productivitat perduda. No necessites xifres tan grans: només cal calcular quantes hores perd el teu equip al mes en treball generat pel deute i multiplicar pel cost/hora.

Crea un mapa de calor del deute

No tot el deute afecta el delivery per igual. Creua dues variables: freqüència de modificació i cost de cada modificació. Els mòduls que es toquen molt i costen molt cada cop que es toquen són la prioritat.

Eines com CodeScene o SonarQube poden generar aquests mapes de forma automatitzada. Però fins i tot sense eines, ho pots fer manualment: pregunta a l'equip quins són els tres fitxers o mòduls que més temen modificar. La resposta sol coincidir amb les zones de més deute.

Reserva capacitat, no la negociïs

La reducció de deute tècnic no hauria de competir amb les features en la priorització del backlog. Hauria de tenir la pròpia capacitat reservada. Un 15-20% de l'esprint destinat exclusivament a millores tècniques és un punt de partida raonable.

Si el deute és sever, potser necessitis més. Però comença per aquí. L'important és que sigui un compromís fix, no una cosa que se sacrifica cada cop que apareix una feature urgent. Perquè sempre hi ha una feature urgent.

Mesura la millora sprint a sprint

Si comences a invertir a reduir deute, necessites demostrar que aquesta inversió produeix resultats. Fes servir les mateixes mètriques que vas utilitzar per diagnosticar: velocitat, cycle time, factor d'expansió, taxa de reobertura. En quatre o cinc esprints hauries de veure moviment.

Si no ho veus, pot ser que estiguis atacant el deute equivocat. Torna al mapa de calor i reajusta les prioritats.

Quan l'equip necessita reforços

Hi ha una situació que es repeteix: l'equip sap exactament on és el deute, sap què hauria de fer, però no té marge. El 100% de la seva capacitat es consumeix a mantenir el producte funcionant i lliurar el mínim del roadmap. No hi ha un 15% per reservar perquè no hi ha un 15% disponible.

En aquests casos, un equip extern especialitzat en refactoring i modernització de sistemes pot assumir la reducció de deute mentre lequip intern segueix enfocat en producte. No és cedir el control: és ampliar la capacitat durant el temps necessari per sortir del forat.

La clau és que lequip extern treballi integrat amb lintern, no en paral·lel. Comparteixen codebase, comparteixen dailies, comparteixen criteri. El deute es redueix sense fragmentar el coneixement.

El deute sempre es paga

Pots ignorar el deute tècnic durant un temps. De vegades durant força temps. Però l'interès compost funciona igual en programari que en finances: com més esperes més surt més car.

La diferència entre un equip que lliura amb consistència i un que sempre va per darrere poques vegades està en el talent. Està a l'estat de la base de codi sobre la qual treballen. Un bon equip amb una base de codi neta rendeix. El mateix equip amb una base de codi endeutada sobreviu.

Mesurar l'impacte del deute al teu delivery no requereix eines cares ni processos complexos. Requereix deixar d'acceptar que “les coses triguen el que triguen” i començar a preguntar per què. Les dades solen ser-hi. Només cal mirar-los.