Discussion :

[nault]

Bonjour,

j'aimerais ouvrir un petite discussion autour de la gestion des Technicals debts et excuser moi pour l'anglicisme, je ne connais pas la bonne traduction.

Dans mon contexte, on travaille en agile / scrum. nous avons énormément de de vieux codes assez obscure et pour les nouveaux projets, souvent précipité en production par notre chef de projets.

En gros, la majorité du temps, on doit tourner les coin rond, passer par dessus la création de test unitaire ou fonctionnel etc.

J'ai commencer à documenter ou se situe ces Technicals debts et pour les nouveaux projets, documenter au fur et a mesure ce qui a été laissé de coté.

j'aimerais savoir dans votre expérience de travail, les méthodes que vous utilisé pour gerer ca ; allouez-vous un pourcentage de votre temps a revenir en arriere fixer ca, les documentez vous?

[souviron34]

Pour pouvoir les gérer, encore faudrait-il savoir de quoi on parle...

Tu parles de "de vieux codes assez obscure", mais tu en train d'en créer, vu que tes définitions ne sont pas claires...

Précise donc ta pensée avant de traiter les vieux codes d'obscurs


PS: et bonne année...

[nault]

En fait je parle de 2 scenarios:

- vieux code (legacy code)
- les coins ronds dans le nouveau code

Pour les vieux codes, un tas de 'technical dept, peuvent exister ; non centralisé, non tester, non comenter, coder a la spagetti etc...

Pour les nouveau, souvent un peu mieux codé, mais par empressement a déployé en production; pas de tests unitaires, non documenté, documenté, architecture plus ou moi scalable etc...


dans ces 2 cas, si il y a un bug, si la personne qui à creé ce code s'en vas de l'équipe, si on doit rajouter des feature.... bref un tas de points negatifs vont survenir si on prend pas la peine de revenir en arrière fixer ce qui a été oublié

quand je parle de technical dept, je parle de ca. Et je vx savoir, dans votre expérience de travail, qu'avez vous connu en matiere de gestion de ses dept technique?

[souviron34]

Ben je crois qu'il faut faire preuve de bon sens :

• "tourner les coins ronds" : ne devrait JAMAIS arriver... Au pire, une solution pas optimale... Mais EVITER ou CABLER un problème ne devrait jamais arriver. Dans ce cas, documenter ET dans le code ET dans un document externe, évaluer l'importance, la priorité de correction... Et l'intégrer dès qu'identifé dans le plan de travail.
  
  
• "vieux soft obscur" : d'abord obscur pourquoi ? langage plus utilisé, plus à la mode, ou pas de commentaire ou alog trop complexe ? là encore, évaluer l'importance, la priorité....

L'essentiel de tout, c'est l'évaluation de l'importance (du risque) - risque de crash, de râlage des usagers, etc - et la priorité - cas très peu fréquent, importance critique pour le soft, etc...

C'est cela qui déterminera si il faut s'y atteler dare-dare, ou si c'est un "todo" qui peut attendre 1 an, voire plus...

Si il faut s'y atteler dare-dare, il est inutile - et dangereux - de le séparer en "x heures/mois". Il faut le régler le plus vite possible..


Dans les environnements de production très contrôlés (CMMi, etc), une liste priorisée des bugs/modifs à faire etc est établie (par le CP et les testeurs ou clients), dispo pour tout le monde, et on n'attaque rien des suivants tant que les prioritaires ne sont pas faits...

[nault]

tourner les coins ronds" : ne devrait JAMAIS arriver...

Je suis 100% d'accord avec toi, mais l'expérience ma prouvé le contraire. Le nombre de foi où on se fait demander de passer le moins de temps possible sur une maquette pour démontrer la faisabilité et qu'un bout de ligne, ces cette maquette qui se rend en production...

vieux soft obscur" : d'abord obscur pourquoi ? langage plus utilisé

Dans mon contexte, on accumule du code depuis 1996, les équipes on évoluer et changé maintes et maintes foi. Ces codes on été patché et re-patché. et aucune documentations est fourni pour dire ce qui les utilise... Ça peut bien être utilisé a travers 20 crons job différentes ou 20 codebases php etc...

Ce vieux code, je le qualifie d'obscure pour ça. et de temps a autre, nous avons a y fourrer des fonctionnalités. Je peux vous dire, qu'on y vois bien des dangers et si on avait du temps pour les nettoyer sur le coup sa prendrais du temps mais réduirait considérablement les risques pour le futur

[souviron34]

Ben je te dis alors :

documenter une liste avec :

• endroit exact
• fonctionalité concernée
• "degré" d'obscurité (nombre de lignes impactées, etc)
• criticité (pour la fonctionalité, la fréquence, ..)

Puis trier la liste par ordre de criticité.... Et attaquer à partir de là... (et mettre à jour la liste à chaque fois : nouveau point découvert / point résolu / résolu mais peut mieux faire.)

[nault]

Oui c'est des excellents point.

Je viens de tomber sur un article assez intéressant, une sorte d'analogie qui compare les dette techniques aux dettes monétaires.

Il y a effectivement plusieurs similitudes et même sur la façon de les rembourser héhé...


Maintenant je regarde ça, pour pouvoir vendre l'idée à mon équipe, et surtout au chef de projets, d'ajouter un politique de gestion de ces dettes technique parmi nos standars de base dans mon équipe.

[el_slapper]

Un autre article sur le même sujet

Sujet important. J'aime beaucoup le vocable parce que les chefs sont capables de le comprendre. Et surtout, comprennent les mécanismes de décisions qui peuvent permettre de choisir laquelle repayer, quand, etc.....

J'aime aussi l'article que tu as posté. J'ai tendance à être extrémiste et à vouloir tout payer, là, maintenant, mais ça n'est pas toujours pertinent. Par exemple, si l'appli est en cours de dé-commissionnement, chercher à l'optimiser, c'est un peu vain(exemple extrême, et j'ai vu la question posée).

Il est important de lister tout ce qu'on trouve en dette technique, et surtout avec une estimation à la louche de son cout et de son cout de correction. Nous avions une horreur qui provoquait deux jours de plantages incessants. Chaque mois. Cout estimé de correction : entre 10 et 15 jours. Appli en fin de vie. On serre les dents et on mange les incidents. Par contre, on retient la leçon pour l'appli de remplacement...

[nault]

Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten

J'adore!

Je sais qu'il n'y a sûrement pas q'une seule recette gagnante qui convient à 100% pour toutes les équipes et types d'architectures.

Mais je crois qu'il y a des rôles et responsabilités communs peut importe le contexte. Je m'explique, en tant que développeur et je peux facilement maintenir à jour une liste de dettes technique. Mon chargé de projets, lui peut décider de ce qui va allez dans le backlog de tâches à faire.

Cependant, il reste la mince (pas si mince...) ligne d'argumentation où les rôles peuvent se chevaucher et créer confusion ou désordre. Si le développeur perçoit une dette technique plus importante que le management la perçoit. Est-il dans sa responsabilité de revenir à la charge ou se garde t-il la vielle bonne carte ; je vous avais prévenue...

je continue a cogiter un peu la dessus... j'aimerais trouvé la meilleur façon d’implanter cette philosophie de gestions des dette technique, les nouveaux mécanismes à mettre en place et les rôles et responsabilités de tout les intervenants dans un équipe SCRUM.

[el_slapper]

Il m'est arrivé de passer en douce, des fois. Quand le décideur(qui était la MOA, pas mon manager) décide de se boucher les oreilles en hurlant "La la la la la" pour ne pas entendre qu'il y a de la dette technique, il faut ruser.

Et quand ils me demandent un chiffrage détaillé, et qu'ils commettent l'erreur de ne pas lire le détail, ça permet de passer bien des choses. Nyark nyark nyark.

[souviron34]

Je m'explique, en tant que développeur et je peux facilement maintenir à jour une liste de dettes technique. Mon chargé de projets, lui peut décider de ce qui va allez dans le backlog de tâches à faire.

J'ai déjà du mal avec ta terminologie..

"chargé de projet".. Est-ce un Chef de Projet ? Un Chef d'équipe ? Ton chef direct ?

Ce que je veux dire, c'est que normalement cette liste se bati simultanément du bas en haut, et du haut en bas... Du bas en haut par tes remarques de dev, du haut en bas par les remarques des clients, des testeurs, des architectes, des chefs, voire du marleting.

C'est pour ça que dans les bons projets, on utilise des outils (comme les suites Clear et autres) pour centraliser, avec une origine...

Là, chaque fois que quelque chose est entré, il ne peut etre entré qu'avec une estimation du temps / du poids (quand c'est de bas en haut), ou une demande d'estimation (quand c'est du haut en bas).

Une fois les estimations remplies, là, les utilisateurs tests ou experts, conjointement avec les chefs, établissent la priorité...

Cependant, il reste la mince (pas si mince...) ligne d'argumentation où les rôles peuvent se chevaucher et créer confusion ou désordre. Si le développeur perçoit une dette technique plus importante que le management la perçoit. Est-il dans sa responsabilité de revenir à la charge ou se garde t-il la vielle bonne carte ; je vous avais prévenue...

Cete ligne n'existe plus (ni la pertinence d'un rappel) si tu utilises quelque chose de centralisé...

Partagé par tous, mis à jour par tous suivant les rôles...

Par exemple, on peut centraliser une base qui serait basée sur un "bug report". Ce "bug report" peut éventuellement concerner une nouvelle fonctionalité (origine : usager ou marketing ou CP), un besoin de réécriture ou de retravail (origine : développeur), une vraie erreur (origine : testeurs, usagers, devs). Ils sont introduits avec le statut "New". Ne sont processés que par le CP, qui discutera avec les intervenants d'origine, et éventuellement demandera une évaluation. Là seul lui pourra y ajouter une évaluation (justifiée) et le fera passer au stade "évalué". Il aura, ce faisant, évalué ou demandé l'évaluation de la criticité ou importance. Le "bug report" passe donc en statut "en attente". Il est éventuellement affecté à un développeur (ou une équipe) dans sa file.. etc... Il ne sera marqué "Terminé" que par le testeur final avant livraison.

Enfin c'est ce que moi j'ai vu faire et ferai...

[nault]

Il m'est arrivé de passer en douce, des fois. Quand le décideur(qui était la MOA, pas mon manager) décide de se boucher les oreilles en hurlant "La la la la la"

En effet! mais je crois que ca reste signe d'une mauvaise gestion des dette technique.

"chargé de projet".. Etce un Chef de Projet ? Un Chef d'équipe ? Ton chef direct ?

chargé de projet

C'et pour ça que dans les bons projets, on utilise des outils (comme les suites Clear et autres) pour centraliser, avec une origine...

Dans mon contexte, nous somme sur JIRA.


Quand j'ai parlé de la mince ligne ou le développeur percevrait une plus grande importance que sont chargé de projet pour un dette en particulier, tu as raison quand tu dit :

Une fois les estimations remplies, là, les utilisateurs tests ou experts, conjointement avec les chefs, établissent la priorité...

mais il faudrait tout de même que le développeur puisse faire valoir ses points au hautes instances non technique.

[gangsoleil]

Bonjour,

A mon sens, tu oublies aussi un autre point, ou tout du moins tu n'en parles pas : si un code fonctionne, et ne demande que tres peu de maintenance, il n'y a absolument aucune raison de le toucher, meme s'il est horrible.

[souviron34]

D'autre part :

Quand j'ai parlé de la mince ligne ou le développeur percevrait une plus grande importance que sont chargé de projet pour un dette en particulier, tu as raison quand tu dit :

mais il faudrait tout de même que le développeur puisse faire valoir ses points au hautes instances non technique.

ça ça fait juste partie de la phase "évaluation"... Que ce soit le dev qui ait remonté le pbe ou que ça vienne d'ailleurs, cette phase sert justement à demander l'évaluation de la criticité et du montant de travail grossièrement...

Faire valoir des point à des intances non-techniques, si tu vises au dessus du CP, oublie-ça : non seulement c'est pas ton rôle, mais ils n'en ont rien à cirer. Si tu vises niveau CP, d'une part il devrait avoir la base technique suffisante, et d'autre part c'est dans le dialogue établi lors de l'évaluation que tu mets tes arguments en avant. Si le CP, avec ce que tu lui dis, décide quand même que ce n'est pas prioritaire, eh bien ça ne l'est pas....

[el_slapper]

En effet! mais je crois que ca reste signe d'une mauvaise gestion des dette technique.
(.../...)

Noooooooon, tu crois????? Se voiler la face, ne rien écouter, bombarder les techos d'insultes pour être sur qu'ils n'ont le temps de rien dire, une méthode discutable? Tu est sur? Ils auraient pu ne pas être absolument parfaits?


Gangsoleil a insisté sur le point essentiel : il faut parvenir à chiffrer les "intérêts". Parfois, c'est facile(dans mon premier exemple, 2 jours par mois). Parfois, c'est impossible. Quand ils sont faiblards, personne ne prendra la décision de refaire propre. Ca n'est pas rentable.

Il faut aussi décider si la faillite(i.e. on élimine/désinstalle l'appli, ce qui liquide la dette en même temps) est une solution viable. Toujours dans mon exemple, c'était déjà en cours.

[Luckyluke34]

Je pense que la première façon de gérer la dette technique est déjà de ne pas en créer. Nous sommes tous des professionnels, il est de notre responsabilité de dire "non" (en argumentant) quand on nous demande de faire du travail de mauvaise qualité pour raccourcir les délais si on sait pertinemment que la dette va nous exploser dans les mains d'ici peu. C'est même dans notre intérêt légal puisqu'en cas de pépin, un développeur peut être tenu responsable, sinon de ne pas avoir respecté un engagement de moyens d'effectuer consciencieusement son travail, au moins de ne pas avoir agité le chiffon rouge du moment qu'il connaissait le problème. Cf healthcare.gov et autres fiascos du même acabit.

Pour la dette existante, je suis assez fan de la règle du boy scout : toujours laisser le code dans un meilleur état que celui où on l'a trouvé. Ca demande de la discipline et un peu de pondération pour ne pas se lancer tout le temps dans des reworks hasardeux à durée indéterminée. Et aussi des outils adéquats comme un IDE efficace permettant des retours en arrière faciles ainsi qu'un filet de sécurité de tests automatisés. D'autres techniques sont décrites dans l'excellent Working Effectively With Legacy Code de Michael Feathers.

Un travers bien humain des développeurs est de raisonner en termes de tout ou rien : "ce code est pourri, jamais je n'y toucherai" ou "on va tout refaire from scratch". Pourtant je pense que la résorption d'une dette technique se fait plus efficacement et de façon moins risquée par petits pas et "nettoyage opportuniste" qu'à coups de grosses refontes de pans entiers du système.

[gangsoleil]

Nous sommes tous des professionnels, il est de notre responsabilité de dire "non" (en argumentant) quand on nous demande de faire du travail de mauvaise qualité pour raccourcir les délais si on sait pertinemment que la dette va nous exploser dans les mains d'ici peu. C'est même dans notre intérêt légal puisqu'en cas de pépin, un développeur peut être tenu responsable, sinon de ne pas avoir respecté un engagement de moyens d'effectuer consciencieusement son travail, au moins de ne pas avoir agité le chiffon rouge du moment qu'il connaissait le problème.

Reponse systematique du chef, car c'est le message qu'il recoit de ses chefs (dans plusieurs boites, de la PME au grand groupe) :
"OK, j'ai bien pris en compte tes remarques, mais tu as tout de meme 5 jours pour le faire, car le commercial l'a vendu comme ca, et donc il faut le faire dans les temps."

[rmaker]

Tu prends le cas d'une vieille appli, mais ce n'est même pas la peine d'aller aussi loin. La dette technique dans mon cas de pauvre petit développeur en banque finance... (une histoire de rmaker, aux "éditions de la ss2i dans la joie")

Dans un monde idéal, on écrit les tests, on code, on teste, on refactore. Les tests garantissent que le refactoring ne casse pas une fonctionnalité importante. Et on refactor tellement qu'on n'a plus de dette technique. Si on met cette bonne pratique dès le début du projet, ça passe. C'est facile.

Mais, évidemment, personne ne fait ça. Chez nous, on code, on ne teste pas, et évidemment, on ne refactor pas. Pas le temps. Du coup, des classes bien pensées au début vont prendre des responsabilités en plus, parce que ' la modif c'est là, et point barre' et que c'est plus simple. Quête de la solution la plus rapide rime avec 0 refacto. Le code devient donc des énormes classes qui ont une responsabilité bien trop grosse (elles gèrent les connexions à la base, les requêtes, et une partie du métier par exemple) et des classes de merde autour. Dette technique à fond, et ça va très vite. Mais alors, TRES vite.

Et donc, quelle est notre réponse? Et bien on paie les intérêts de la dette technique à chaque nouvelle itération. Réponse du client? Ce n'est pas grave!

Car au bout d'un moment, le code est tellement pourri que la première modif prend des mois. Donc, on est hors budget sur le projet. Donc, le projet ne sert à rien. Donc, le pauvre chef de projet est déplacé / viré / recasé, et son équipe est dissoute. Comme c'est du presta, ça part bien. Une nouvelle équipe est reformée. Elle a pour but de remplacer l'outil précédent, celui qui est en train de crever de sa dette technique. Et donc, la nouvelle application a du budget, commence à coder proprement, et etc, l'histoire se poursuit...

Voilà... Je sais que je n'ai pas vendu du rêve, et pourtant, c'est vrai.

[ovh]

Tu prends le cas d'une vieille appli, mais ce n'est même pas la peine d'aller aussi loin. La dette technique dans mon cas de pauvre petit développeur en banque finance... (une histoire de rmaker, aux "éditions de la ss2i dans la joie")

Dans un monde idéal, on écrit les tests, on code, on teste, on refactore. Les tests garantissent que le refactoring ne casse pas une fonctionnalité importante. Et on refactor tellement qu'on n'a plus de dette technique. Si on met cette bonne pratique dès le début du projet, ça passe. C'est facile.

Mais, évidemment, personne ne fait ça. Chez nous, on code, on ne teste pas, et évidemment, on ne refactor pas. Pas le temps. Du coup, des classes bien pensées au début vont prendre des responsabilités en plus, parce que ' la modif c'est là, et point barre' et que c'est plus simple. Quête de la solution la plus rapide rime avec 0 refacto. Le code devient donc des énormes classes qui ont une responsabilité bien trop grosse (elles gèrent les connexions à la base, les requêtes, et une partie du métier par exemple) et des classes de merde autour. Dette technique à fond, et ça va très vite. Mais alors, TRES vite.

Et donc, quelle est notre réponse? Et bien on paie les intérêts de la dette technique à chaque nouvelle itération. Réponse du client? Ce n'est pas grave!

Car au bout d'un moment, le code est tellement pourri que la première modif prend des mois. Donc, on est hors budget sur le projet. Donc, le projet ne sert à rien. Donc, le pauvre chef de projet est déplacé / viré / recasé, et son équipe est dissoute. Comme c'est du presta, ça part bien. Une nouvelle équipe est reformée. Elle a pour but de remplacer l'outil précédent, celui qui est en train de crever de sa dette technique. Et donc, la nouvelle application a du budget, commence à coder proprement, et etc, l'histoire se poursuit...

Voilà... Je sais que je n'ai pas vendu du rêve, et pourtant, c'est vrai.

+1000

Voilà enfin un post qui décrit exactement notre métier !

[Luckyluke34]

C'est en effet un excellent résumé de la réalité

Par contre, l'usager que je suis a un peu peur... Pas de tests ? Du coup, il y a une horde de bugs tapis dans le système d'information de ma banque prêts à exploser ? Pire, dans celui de mon hôpital ? De mon centre des impôts ? De l'aéroport du coin ?

Vous avez l'air d'accepter sans sourciller que les applications soient des objets jetables qui moisissent à très court terme, ce qui me parait assez dangereux. Je crois qu'on peut quand même se responsabiliser et agir à notre niveau de développeur :

• L'ajout de tests ou le refactoring n'a pas besoin d'être énorme pour être bénéfique. De petites améliorations peu impactantes sur la charge de travail peuvent apporter un gain de qualité non négligeable et faire boule de neige avec le temps.
  
• En tant qu'expert, on n'a pas à se justifier de produire de la qualité. Elle devrait être intrinsèque à notre façon de travailler et bien souvent ça ne se remarquera même pas de l'extérieur (un peu ce que el_slapper expliquait).
  
• Ne pas hésiter à diffuser la connaissance. Plus les bonnes pratiques de développement seront connues, promues, discutées, enseignées, plus on aura de chances de les considérer comme état de l'art et les adopter en début de projet. Par exemple, aujourd'hui un outil de source control et un serveur d'intégration continue sont généralement considérés comme des minimum syndicaux. C'est le sens du progrès que ces exigences augmentent.
  
• C'est normal que les managers défendent "leurs intérêts" en essayant d'imposer des deadlines courtes. A nous de défendre les nôtres, de négocier. Il ne s'agit pas de dire "non" tout court mais de faire une contre-proposition argumentée. Combien osent le faire au lieu de se résigner et dire "je vais essayer" ?