Gestio del deute tecnic

El concepte de deute tècnic no és gens nou, ha existit durant molt de temps amb altres noms (p.e. cost de la no-qualitat). L'interessant d'aquest nom és que, segons la meva experiència, capta molt millor l'atenció dels directors, caps i altres rols no tècnics que prenen decissions sobre els projectes de software.

 

El concepte consisteix en les eventuals conseqüències d'usar arquitectures i dissenys deficients (decisions tècnicament incorrectes) o de seguir pràctiques dolentes de desenvolupament de software ("treballar malament"), usualment materialitzades en el treball pendent que pot quedar "submergit" en un moment donat, però que s'haurà de realitzar (pagar) per poder acabar el projecte. El fi del projecte no significa liquidar el deute, doncs el manteniment de qualsevol producte amb deute tècnic s'encarirà notablement, a més de deixar una mala imatge de l'equip o de l'empresa que va fer el projecte.

 

Per una banda, les conseqüències més típiques de tenir un projecte amb deute tècnic són:

  • Endarreriments amb els lliuraments (la planificació es deixa de complir en quant emergeix el deute tècnic)
  • Productes amb qualitat dolenta per l'usuari (visible) i per aquells que l'han de mantenir (invisible).
  • Major cost de manteniment i cost total de la propietat (TCO).
  • Desmoralització de l'equip i excesiva rotació del personal.


Per altra banda, els motius més freqüents del deute tècnic poden ser:

  • Una mala planificació o pressions per avançar en el projecte sense escoltar els criteris tècnics.
  • Manca de metodologia i de comunicació a l'equip (o entre equips).
  • Males pràctiques com el "hardcoding" o els components altament acoblats.
  • Manca de proves unitàries i de proves automàtiques de regressió.
  • Manca de documentació i proves automàtiques de regressió.
  • Molts altres.


També cal tenir en compte que el deute tècnic pot tenir altres característiques:

  • Conscient: p.e. no fer proves unitàries per arribar a fer una demo interna a temps (però es faran immediatament desprès)
  • Inconscient: p.e. no fer proves unitàries perque endarrereix el projecte (fins que apareguin més errors que probablement seran més cars de solucionar).
  • De curt termini: p.e. no documentar per arribar a una fita urgent (reunió amb un altre equip) però que es liquidarà en breu.
  • De llarg termini: p.e. desenvolupar una capa de persistència per Oracle 11g només perquè no s'espera usar una altra BD en producció.

El tema dóna per molt i és millor no eternitzar-se. Podeu consultar una 

presentació molt bona del Steve McConell.

 

Espero poder presentar sobre aquest tema a la Barcelona Developers Conference 2013. Si el tema us sembla interessant, voteu-me si us plau! :-)

Write a comment

Comments: 0