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 ?
Les 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équiper 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 ?
.png)
.png)
