Diagrammes et Modèles 4
— Si je comprends bien, on est pris dans étau.
— Qu'est-ce que tu veux dire ?
— Soit nous testons notre logiciel de bout en bout, et nous allongeons les délais de livraison, soit nous le livrons au plus tôt, mais alors nous devons traiter les incidents en production.
— Si on reprend le diagramme qui modèlise ton système :
- certains changements entraînent des dysfonctionnements
- certains dysfonctionnements seront détectés via des tests, ce qui laisse une chance de les corriger avant la mise en production
- certains dysfonctionnements "échapperont" aux tests, et ne seront identifiés qu'en production
— Dans les deux cas, il faut corriger les problèmes, et ça prend du temps.
— Oui, mais si ton équipe n'effectuait aucun test, ta stratégie se limiterait à attendre que les incidents arrivent. Ce serait terrible !
— Ce qu'il faudrait, c'est tester, mais seulement les parties critiques du logiciel.
— Tu veux dire celles qui doivent absolument fonctionner ?
— Oui.
— Je suis certain que ton équipe fait déjà une telle sélection dans ce qu'elle teste.
— Alors que faire ?
— Jusqu'ici on recherche des dysfonctionnements existants dans le système. On pourrait mettre en place une stratégie visant à les prévenir, plutôt.
— Par exemple ?
— Par exemple, si tu programmes en javascript et que ton code additionne une chaîne de caractères à un nombre, tu viens de créer un dysfonctionnement.
— C'est probable.
— C'est quasi-certain. On pourrait empêcher ce défaut d'arriver en production, et même en environnement de tests. Il existe au moins 3 moyens :
- relire le code, de préférence en équipe
- écrire un tests automatisé qui va échouer sur le résultat attendu
- utiliser un langage comme typescript, qui vérifie le type des termes d'une addition.
— Tout ça c'est bien, mais ça ne se fait pas du jour au lendemain. Ça prend du temps.
— Ça vaut peut être le coup d'essayer : pour l'instant c'est la seule stratégie qui te permet de réduire le nombre de dysfonctionnements : on a une nouvelle relation
CHANGEMENTS → VÉRIFICATIONS -⊖→ DYSFONCTIONNEMENTS
ce qui veut dire que l'on réduit le nombre de dysfonctionnements à la source.
{:width="800px"}
— Note que ça plairait peut être à notre sponsor ce que tu viens de dessiner là.
— Ah oui ?
— Il se plaint que l'équipe ne soit pas capable de corriger les défauts sans en introduire de nouveaux.
— Ce que dit ce diagramme, c'est qu'avec un système assez grand, sans régulateur, l'activité de l'équipe tomberait dans un cercle vicieux :
CHANGEMENTS → DYSFONCTIONNEMENTS → INCIDENTS → CHANGEMENTS.
Pour réguler l'activité et empêcher un effet boule de neige , il faut soit réduire le nombre d'attentes, c.à.d moins de fonctionnalités promises, et/ou moins de clients…
— Hors de question.
— …soit réduire le nombre de dysfonctionnements à la source.
— C'est mieux.
— Et pour ça il vous faut un processus de vérification.
— On en revient toujours là.
— …mieux vaut prévenir que guérir.
Stay Tuned !