Modèles Mentaux
[TDD, Test]
Le conflit (cf posts précédents) entre Clara et Jérémie à propos des tests constitue un évènement. Les évènements s’inscrivent dans des trames, lesquelles suivent plus ou moins fidèlement la voie des processus et de la culture de l’entreprise.
Dans cette entreprise en particulier, à propos du développement, les modèles mentaux suivant ont cours :
1) Développer c’est Écrire du Code
Savoir programmer c’est transformer des idées qui sont communiquées via des expressions de besoin en code exécutable par un ordinateur. Si on est talentueux·se, intelligent·e et passionné·e, on livrera plus vite que les autres un programme dont le comportement sera correct c’est à dire conforme aux attentes et aux besoins. Et en plus le code produit sera lisible et facile à faire évoluer. Pour devenir excellent·e, il faut consacrer une partie de son temps personnel à se former afin de connaître toujours plus de recettes applicables dans leur contexte (et ainsi améliorer son employabilité).
2) Tester c’est Vérifier
Sur un diagramme de Gantt, on verra un rectangle “Développement” qui s’étend de T0 à T+5 (mois), suivi par un rectangle “Tests” sur la période de T+5 à T+6. Le diagramme ne décrit pas ce qui se passe si les tests révèlent un produit inutilisable, ni si cela peut remettre en question l’ensemble du planning. Ce que nous dit le diagramme, c’est que la phase de vérification trouvera des problèmes tellement négligeables que leur somme ne mérite même pas une zone rectangulaire sur le calendrier.
C’est dans ce sens qu’on utilise le terme “Assurance Qualité” pour désigner l’activité de test :
s’assurer que la qualité est là,
et non dans le sens des assureurs, c’est à dire :
assurer la qualité, c’est à dire la garantir en payant lorsqu’elle n’est pas là
3) Penseurs et Exécutants
Lorsque qu’un projet de développement livre très en retard un résultat particulièrement médiocre, on examine d’abord l’exécution avant d’examiner le plan. Il s’avère qu’Alex est trop junior pour bien coder, c’est pourquoi le planning n’a pas tenu. La PO “ne sait pas de quoi elle parle”, et c’est pour cela que le produit ne fonctionne pas.
Dans une organisation qui sépare les “doers” et les “thinkers”, il est plus simple de blâmer, quitte à traverser les turbulences qui suivront, que de travailler ensemble, département et niveaux de managements confondus, à revoir un plan voire à repenser le modèle de développement.
Le clash entre Clara et Jérémie se produit d’abord parce que Clara ne trouve pas sa place dans le modèle courant. Sa “valeur ajoutée” c’est de trouver des problèmes dans un produit, et non de vérifier du code qui n’a pas de tests.
Jérémie assigne à Clara la vérification du code. Le problème qu’il feint d’ignorer c’est qu’il faudrait 50 personnes et non une seule pour vérifier ce code en totalité.
Xavier, le CTO, vient de réaliser la nature du conflit, et réfléchit à la façon de changer le modèle.
Stay Tuned!