Pratiques de Prévention
La dette technique, c'est un rebut, présenté comme un fait accompli. La dette passée nous empêche de faire évoluer rapidement le logiciel. Mais la dette future, nous la paierons plus tard, il y a plus urgent dans le backlog.
Que faire ?
Créer comme certains le recommandent une équipe transverse de désendettement ? Elle travaillerait sur les mauvaises priorités, toujours après la bataille, coûteuse, inessentielle.
Nous pouvons changer de modèle. Nous n'avons pas nécessairement besoin d'adhérer à un système de représentations s'il ne produit pas des changements dans le bon sens, et nous devrions même le questionner.
Si nous fabriquons de la dette spontanément, sans le savoir : nous devrions examiner la façon dont nous travaillons, et y remédier. Toute industrie améliore ses procédés.
Si nous sommes conscients de créer de la dette mais continuons à le faire : d'où nous vient un tel fatalisme ?
De fait nous connaissons des pratiques qui limitent la dette technique. En voici quelques unes :
🏷 Product Owner : rôle définissant les responsabilités et prérogatives liées à la traduction en application, des idées élaborées avec le Métier
🏷 Architecte : rôle définissant les responsabilités et prérogatives liées à la traduction Technique des contraintes et objectifs stratégiques élaborées avec le Métier
🏷 User Story : pattern d'interaction dans lequel le Métier et la Technique partagent une description succincte d'un comportement possible du logiciel du point de vue de ses utilisateurs
🏷 Backlog Grooming : rituel durant lequel le Métier et la Technique raffinent ensemble la traduction d'idées à ajouter prochainement au logiciel en cours de développement
🏷 Ensemble Programming : session d'écriture de code en équipe, dans laquelle l'équipe raffine et traduit une idée de comportement à ajouter au code
🏷 Pair Programming : session d'écriture de code à deux, qui combine les rôles de manière à ce qu'une idée de comportement passe toujours par la compréhension d'un coéquipier avant d'entrer dans le code
🏷 Test Automatisé : pattern de code auto-exécutable décrivant les aspects intéressants du comportement d'un logiciel et les vérifiant à travers une exécution
🏷 Refactoring : action de modifier le code d'un programme afin d'en améliorer la facilité d'évolution, sans modification de son comportement
🏷 Revue de Code : procédé de relecture de code permettant à l'équipe de valider des améliorations faites individuellement sur le code, de consolider ses standards, et de maintenir sa cohésion d'équipe Technique
🏷 Rétrospective : rituel au cours duquel une équipe examine et améliore ses procédés, son organisation, ses patterns de communication ainsi que sa cohésion
Remarquez vous à quel point ces pratiques ont pour sujet la traduction, et non la fabrication ? Stay tuned !