— Qu’est-ce que nous essayons de faire, au juste avec ces diagrammes ?
— Trouver des relations entre des variables à propos de ce que nous observons.
— Et quand on a trouvé ces relations, qu’est-ce qu’on a de plus ?
— On peut identifier des points d’interventions, c’est à dire changer ce que nous faisons de manière à changer ces relations.

— Mouais.
— Ce qu’on a jusqu’ici :

  • ton équipe effectue des changements dans un logiciel
  • une partie de ces changements provoquent des dysfonctionnements
  • ces dysfonctionnements ne sont observables que sous la forme de rapports d’incidents, lorsque le dysfonctionnement fait que le logiciel ne répond pas aux attentes
  • munie de ces rapports d’incident, ton équipe effectue de nouveaux changements

— C’est un peu léger, ta description. L’équipe ne se contente pas d’attendre tranquillement des incidents. On fait des tests, figure-toi.
— Comment est-ce que vous faites vos tests ?
— Eh bien une partie de l’équipe installe le logiciel dans un environnement de tests, et ensuite exécute des scénarios de tests, à la recherche de ce qui pourrait ne pas marcher.
— Et quand elle trouve un dysfonctionnement ?
— Elle produit un rapport d’anomalie à destination des développeurs.
— Je vois. On a donc une nouvelle relation :\

CHANGEMENTS → TESTS —&—|D|→ ANOMALIES
DYSFONCTIONNEMENTS —&—|D|→ ANOMALIES
ATTENTES —&—|D|→ ANOMALIES
ANOMALIES → CHANGEMENTS

système

Lorsque l’équipe change le logiciel, elle procède à des tests. Les tests révèlent des dysfonctionnements, c’est à dire des façons de fonctionner qui ne répondent pas aux attentes. Les dysfonctionnements sont consignés dans des rapports d’anomalies, ce qui permet de changer à nouveau le logiciel.

— C’est ça.
— On a un diagramme un peu plus compliqué, mais qui permet de voir ce que vous faites pour pallier au problème du révélateur.
— Le révélateur ?
— Oui, rappelle toi : le fait que les incidents en production ne nous révèlent les problèmes que très tard, lorsque le dysfonctionnement est déjà en production.
— Exact.
— Avec une démarche de tests systématique, vous pouvez identifier les dysfonctionnements et les supprimer avant le passage en prod.
— Tu as raison. Il faut que nous recrutions plus de testeurs.
— Est-ce que c’est ça qui va améliorer la vitesse à laquelle vous réalisez votre logiciel ?
— Si je suis ton modèle, oui : des défauts trouvés avant la prod, c’est toujours du temps gagné, crois-moi.
— J’ai connu une situation dans laquelle un manager avait fait exactement ce que tu t’apprêtes à faire, pour avoir moins d’incidents : il a recruté des testeurs supplémentaires.
— Et… ?
— Il a eu moins d’incidents. Mais au final le temps de développement a doublé.
— Comment ça ?
— Les testeurs trouvent des problèmes plus efficacement que les utilisateurs en production, figure toi.
— Oui, c’est leur job !
— Tu vois un insecte sortir de dessous une pierre. Tu soulèves la pierre. Qu’est-ce que tu vois ?
— Argh…

Stay Tuned !

publié sur Linked In le 28/06/2023