Auto-Prescription
Merci Mauko pour ta contribution à cette conversation à propos du standard. La distinction que tu fais entre descriptif et génératif, complexe et simple, invite à considérer comment on peut parfois "altérer" un standard récemment acquis.
Par ex. une équipe met en place une démarche inspirée de Scrum. Chaque jour à une heure fixe, l'équipe se réunit afin de faire le point rapidement sur ce qui empêche chacun d'avancer.
Après un temps, le daily meeting traîne en longueur, (beaucoup de sujets, suscitant des longues mises au point) 🥱
Ou bien, lorsque le Scrum Master n'est pas présent ce jour là, la réunion n'a pas lieu 🕳
Ou bien la réunion se transforme en rapport d'activité quotitien au PO ou au SM 🧐
Autre exemple : une équipe se forme à TDD, à la suite de quoi les développeurs essaient de suivre le cycle Test-Code-Refactor :
- Ecris d'abord un test qui ne passe pas
- Ecris le code le plus simple qui fasse passer ce test
- Remanie le code sans en changer le comportement
Après un certain temps, l'étape de refactoring est négligée pendant plusieurs cycles, jusqu'à devenir importante au point de créer un ticket de refactoring 🧻
Ou bien le code écrit à l'étape 2 implémente bien plus que ce qui suffirait à passer le test 🔥
Ou bien l'étape de test reprend place après l'étape de code ("comment tester une méthode privée ?") 🔄
Ces exemples d'altération d'une pratique ne sont nullement une fatalité. D'autres équipes, sur la base des mêmes sources d'informations, des mêmes formations, pourraient très bien persister dans leur pratique et bien sûr l'améliorer. Cela ne tient pas à la nature de la pratique elle-même, mais à la manière dont elle est acquise et intégrée par l'équipe, qui se l'approprie ou non, dans son contexte.
Un standard imposé de l'extérieur (par une autorité ou une tradition quelconques) sera d'autant plus facilement altéré (voire défiguré) qu'il est a) mal compris par ceux qui l'imposent, b) vécu comme un carcan par ceux qui le "reçoivent". L'amélioration continue ne marche pas à coup de décrets.
Le standard, c'est l'état de l'art de l'équipe, c'est à dire l'ensemble des pratiques qu'elle se donne comme la meilleure façon de résoudre un problème étant donnés ses objectifs et contraintes.
Il inclut des règles simples ou complexes, précises, ou génériques. Aucune de ces "heuristiques" ne garantit de résultat dans l'absolu : elles sont seulement reconnues et éprouvées par l'équipe qui les a intégrées, dans le contexte où elle se trouve.
-
simple, tacite, quasi universel : indenter le code 🗺
-
complexe, souvent vrai, incomplet : écrire des TUs au fur et à mesure afin d'éviter des problèmes une fois en production 🧯
Le standard constitue t'il une prescription ? Pour une personne qui rejoint l'équipe, sans doute. Pour l'équipe elle-même, certainement pas. C'est tout l'objet du standard que d'être constitué et amélioré par l'équipe elle-même au cours de la réalisation.
Stay Tuned !