Coaching Agile

Agile, Scrum et autres pensées
Laurent Carbonnaux

Dette Technique : la poule aux oeufs d'or


From blog.crisp.se
Je viens juste de lire un article d'Henrik Kniberg sur la dette technique datant de Juillet 2013.


Dans les commentaires, George, un internaute rappelle à Henrik les conditions de pression dans lesquelles les développeurs sont au quotidien.
Henrik lui répond que dans le "monde réel" qu'il voit, les compagnies s'engouffrant dans la dette technique vont de moins en moins vite, perdent des développeurs, et finissent par regretter leur manque de discernement qui rend de plus en plus coûteuse la correction des anomalies à posteriori.

Il synthétise en disant que ne pas s'occuper de la qualité du code est un investissement court terme, bien que les compagnies cherchent à vivre longtemps.

C'est sur ce dernier point que je souhaite apporter mon point de vue.
"Les compagnies cherchent à vivre longtemps"
Oui, toutes, les compagnies clientes et les SSII! *

Hors pour que les SSII vivent longtemps, il faut qu'elles aient du travail pour longtemps. Vous voyez où je veux en venir.

Les SSI sont facturées à la journée, à la charge consommée ou  vendue  (au forfait ou en régie peu importe). Le développement des applications est découpé en projet de développement puis en projets de maintenance (Tierce Maintenance Applicative). Quel intérêt pour une SSII de faire que le produit qu'elle fournit soit trop exempt d'anomalies, que la dette ne soit pas trop réduite? De toute façon le client fera appel à elle (ou une autre, juste un échange entre SSII du marché) pour une TMA, et au final repayer pour corriger des bugs non vus avant et pour lesquels ils ont en plus déjà payé de la garantie souvent.

Même chez les clients. J'ai entendu chez un de mes clients, il y a fort longtemps, que le coût des tests automatisés, par exemple, étaient trop élevés pour le projet de développement et que ce n'était pas grave que ça coûte cher pour la maintenance, "ce sera un autre budget pour le département d'à côté". Là aussi problématique lié au découpage budgétaire et du cycle dev+maintenance.

Pour qu'une société vive longtemps, c'est sur la valeur qu'il faut se focaliser, le ratio valeur/coût.
Vérifier que vos équipes ou vos prestataires puissent vous garantir le maintien de l'apport de valeur au même coût et ce sur le long terme.
Et opter pour une vision produit, tout au long de la vie de celui-ci, de façon itérative et essayant sans cesse d'améliorer le coup suivant.
Comment va-elle traiter la dette technique? pas en balayant la poussière sous le tapis.

 Là aussi faut des tripes. SWCC ™

 (*) j'ai vu dans un article aujourd'hui qu'il fallait maintenant appeler les SSII les SSN, Société de Services en Numérique, bon.


2 commentaires:

Guillaume a dit…

Bonjour Laurent !
Un commentaire bien dur ... Ce que je constate est que les SSII proposent à leurs clients des outils de mesure de la qualité (Sonar, CAST) pour démontrer la valeur de leurs développements. Les clients qui s'intéressent à la dette technique sont demandeurs de telles métriques. A l'inverse, les clients qui ne s'intéressent qu'au cout immédiat des solutions ne veulent pas voir l'évolution de cette dette.
Pour ce qui est de l'avenir des SSII, un client préférera toujours payer pour une évolution que pour une correction, donc mieux vaut fournir un code propre en continu !!! Bonne soirée !

Laurent Carbonnaux a dit…

Bonjour Guillaume.
Merci pour ton commentaire.

Tu as raison, Sonar et Cast peuvent servir à détecter de la dette.

Je ne parle pas de valeur des développements, mais de valeur du produit. Même un code propre peut ne servir à rien. 45% des fonctionnalités des logiciels ne servent jamais et 19% rarement (Etude Chaos Report du Standish group). Ce code contribue aussi à la dette.

Quant à ta dernière phrase, je suis en phase avec, et c'est bien de cela dont je parle.
Je ne fait aucunement l’apologie des SSII, bien au contraire, ou alors je me suis mal exprimé. ;-)