Dette technique, capacité et volonté de la réduire

J’ai lu dernièrement un article très intéressant parlant de la dette technique d’une application sur le blog de Claude Aubry :

Ces deux liens donnent une définition plutôt claire de la dette technique et des moyens de la reconnaitre.

Je me permets cependant de compléter ces articles, puisque je suis actuellement dans un cas similaire où j’ai pour mission d’améliorer la qualité et la productivité d’un projet qui supporte une dette technique particulièrement importante.

S’il y a dette technique sur un projet, l’équipe projet ne sera pas à même de la reconnaitre, sinon celle-ci n’aurait pas de dette technique (ou alors minime) à moins d’avoir un éclair de génie et de se dire, « Mais nous avons une grosse dette technique !!! ». Sur le projet que j’encadre actuellement, les développeurs n’ont absolument aucune conscience de la mauvaise qualité des développements et considèrent que les difficultés qu’ils rencontrent sont essentiellement dû à l’environnement particulier de développement (du javascript sur un serveur NetSuite). Le code n’est pas formaté, n’a aucune convention de nommage, ne réutilise pas ces composants, et pire les développeurs font du copier-coller de code à outrance, car ils ne veulent pas casser du code existant de peur d’engendrer des bugs en série. Et bien évidemment, ils ne connaissent pas les tests unitaires et d’intégration. Dans ces conditions, comment voulez-vous que cette équipe soit à même de reconnaitre la dette technique de son projet ?

Capacité à voir la dette technique

Pour reconnaitre la dette technique d’un projet, il est nécessaire de faire appel à une personne extérieure au projet. Cette personne peut être de la même entreprise, mais si tous les projets sont fondés sur les mêmes principes (pas de formatage, pas de convention de nommage, pas de réutilisation de code et pas de tests unitaires), alors il est préférable de faire appel à une personne extérieure, nouvellement embauchée ou intervenant extérieur.

Cette personne devra avoir les capacités techniques et fonctionnelles nécessaires à l’acquisition des bases d’un projet mal ficelé (autant dire de très bonnes compétences) et comprendre ce qui a amené les développeurs à se retrouver dans une telle situation. Compétences et/ou connaissances techniques insuffisantes, pression du business pour avancer toujours plus vite sans réfléchir sur ses actes pour réorganiser le projet au fur et à mesure de son accroissement… Cette personne devra également avoir de gros talents de persuasion et de négociation pour que les développeurs eux-mêmes reconnaissent que quelque chose doit être fait. En effet une personne extérieure au projet et plus spécialement extérieure à l’entreprise aura toujours plus de mal à convaincre, surtout si elle doit faire les preuves de ses capacités.

Mais le plus important n’est pas de reconnaitre cette dette technique, de la faire reconnaitre aux développeurs ou de trouver une solution afin de la réduire.

Volonté à réduire la dette technique

En effet, une fois les premiers acteurs du projet acquis, il va vous falloir convaincre les décideurs, c’est à dire le métier, qu’il y a une grosse dette technique (qu’ils n’ont jamais vu d’ailleurs) que celle-ci est pénalisante pour le projet et que réduire cette dette technique va permettre d’accroitre la productivité par 2 voire 3 fois.

Mais surtout il va falloir leur expliquer que pour combler cette dette technique, vous allez devoir pénaliser la production pendant une période plus ou moins courte (3 mois dans mon cas, mais la dette technique est vraiment très importante) afin de mettre en place un process de développement et/ou une architecture digne de ce nom. Et c’est sur ce dernier point que vous allez rencontrer les plus grosses difficultés.

Rien ne garantit en effet que vous aurez les gains de productivité attendus, qui paraissent tout de même extraordinaire. Le business est bien évidemment dans une phase critique et réduire les développements est inimaginable. Alors vous allez expliquer et négocier, mais si le business a réellement besoin de ces développements, vous pouvez être sur que le planning de votre refactoring va s’allonger dans le temps ou être décalé jusqu’à des temps plus sereins (ce qui d’après mon expérience existe rarement).

Bonne chance pour réussir sur ce dernier point.

PS : La décision de mon example sera prise dans les jours prochains, nous verrons ce qu’en aura décidé le business. (Je crains le pire).

Publicités

Une Réponse to “Dette technique, capacité et volonté de la réduire”

  1. Liens du mois - Juin 2009 | Forum Logiciel Says:

    […] Dette technique, capacité et volonté de la réduire […]


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :