Une Facture Imaginaire
Poncifs :
👉 Un projet de développement logiciel est une opération affreusement compliquée. Nous simplifions les choses parce qu'il faut bien passer à l'action.
👉 Le problème à résoudre n'a pas fini d'être posé, son exploration n'a peut être même pas commencé, que nous chiffrons déjà des "solutions".
👉 Les acteurs concernés : le Métier, la Technique et le Management ont des objectifs complémentaires mais distincts.
👉 Nos méthodes de développement (que nous appelons "méthodologies" pour leur donner un petit côté scientifique) ne garantissant nullement la cohérence et l'efficacité de l'équipe, nous tablons également sur le leadership, une compétence individuelle difficile à "objectiver".
👉 Notre culture agile est balbutiante et minoritaire : un projet qui s'arrête est toujours perçu, et parfois vécu, comme un échec.
Voilà autant de conditions propices à créer des frictions, voire des barrières de communication.
La dette technique se forme autour des barrières de communication. Elle se manifeste par l'effet résiduel sur le code de toutes les dérives apportées à notre état de l'art.
Impossible de parler de dette technique sans la rapporter à un état de l'art, lui même relatif à nos objectifs, nos contraintes et nos capacités. La DT n'est pas "dans le code".
Le script python non testé, non relu, non documenté qui aide Victor à gérer le contenu de son congélateur ne comporte pas de dette technique en soi. La même stratégie (0 test, 0 revue, 0 doc) apportée au code python de l'ERP que son employeur a choisi d'adapter ménerait à une calamité de dette technique.
Si on considère la DT comme une caractéristique du code, celle présente dans son fichier CONGELO.PY n'est ni plus ni moins importante que celle présente dans les scripts qu'il écrit au travail. Or l'impact est négligeable dans un cas, incalculable dans l'autre.
La dette technique est l'aboutissement dans le code d'une série de dérives et de désalignements dans l'état de l'art d'une équipe, relativement à ses objectifs et ses contraintes. Avec une équipe Métier-Technique-Management parfaitement alignée dans son état de l'art, créer de la dette ou du code legacy est impossible, à moins que cela fasse partie du projet, comme une sorte de défi.
🤔 Vous allez réagir — ou du moins vous pourriez — en disant : "Comment ça l'état de l'art de l'équipe Métier-Technique-Management ? Il y a une équipe de développement, mais que je sache, on ne forme pas d'équipes Métier-Technique-Management"
Et vous auriez raison. On touche là une source majeure de création de dette technique : au lieu de nous organiser pour traduire ensemble des idées, nous déléguons ces traductions par le biais de rôles spécialisés. Après un temps de délégation plus ou moins long, la Technique additionne un montant en euro qu'elle communique à ses deux autres partenaires, comme une facture ou un devis imaginaire.
On doit pouvoir faire mieux que cela.
Stay tuned !