Ce n'est pas une question de rôle
La dette, ce n'est pas une question de rôles usurpés.
Un projet = des Développeurs (au sens large que Scrum donne à ce mot), leur Manager, ainsi qu'un P.O. vont pendant plusieurs mois, porter leur attention et concentrer leurs efforts sur 4 systèmes d'idées.
🏛 Le 1er est conceptuel et généralement informel. Les idées y changent rapidement, bien qu'elles soient ancrées dans un langage et des processus souvent éloignés de la Technique. C'est le Domaine Métier.
📱 Le 2d est extrêmement formel, rigide et complexe. C'est une arborescence d'interactions possibles entre des machines et des personnes : le Logiciel.
📐 Le 3ème est un système d'idées techniques très formel, étayé par de nombreux supports : code, tests, scripts, schémas, documents etc. et que nous appellerons : la Conception.
📝 Le 4ème est un ensemble nébuleux, une sorte de "manuel" (mais non documenté) de procédés heuristiques, règles, patterns, ou pratiques que l'équipe adopte et adapte en vue d'atteindre son but. Il est fait de réunions et d'intersections avec d'autres manuels : celui des individus qui composent l'équipe, celui de l'entreprise qui les emploie et/ou celle qui les accueille, et celui de l'Industrie en général. C'est l'État de l'Art du projet.
Domaine Métier, Logiciel, Conception, État de l'Art : tout le travail de l'équipe consiste à opérer, en permanence, entre ces 4 systèmes d'idées, des traductions.
La traduction Domaine ↔ Conception ↔ Logiciel rythme l'activité. L'équipe élabore des traductions qu'elle déploie, ce qui produit des résultats qu'elle réinterprète pour ses traductions suivantes.
🎉 Succès ! On a livré la v.1 ! Le DG a pu acheter un produit ! (Il a des remarques)
→ C'est le résultat de centaines de traductions.
Le terme à la mode pour désigner cette activité est "delivery".
🏛 ↔ 📐 ↔📱 = 📦
Lorsque l'équipe fait évoluer son état de l'art, en empruntant et adaptant de nouveaux procédés, ou bien en le délestant de ceux qu'elle juge inutiles, elle modifie, souvent en profondeur, la façon dont elle va opérer son "delivery".
Dans un projet agile, cette modification se décide souvent à la légère : au détour d'une rétro ou d'un planning meeting, voire devant l'écran.
🙀 On n'aurait pas dû arrêter les revues alors qu'on doublait la taille de l'équipe. Regarde l'état du code ! 💩
→ c'est le résultat d'une décision funeste ayant affecté un grand nombre de traductions.
☞ changement dans la conception = le "delivery" avance 🚚
☞ changement dans l'état de l'art = l'équipe modifie ses procédés 📝 🧯 🪜 🗺
Lorsqu'un changement incohérent affecte la conception, les conséquences sont immédiates (merci l'agile!) : bad smells, bugs, adhérences, questions, retours. 🕳 🚧 🚚
Lorsqu'un changement concerne l'état de l'art, les conséquences se feront sentir… plus tard. 🤸 🕳
Faute de conséquences immédiates, au lieu de raisonner, l'équipe fait des rationalisations. 🙃 C'est là que la dette s'installe.
Ce n'est pas une question de rôle.