Une équipe de 5 développeurs, un product owner et un manager, ajustent leur état de l’art : on passe de Trelli à Jora. (Jora permet de requêter les tickets, ce qui permet de produire toutes sortes de rapports intéressants, ce qui améliore la communication du projet).

4 semaines plus tard, elle décide de faire le chemin inverse.

Impact aller :

  • conversion tickets : 0.5j
  • prise en main : 0.5j
  • communication : 0.5j

Impact retour à t + 4 semaines :

  • ressaisie tickets : 0.1j
  • communication : 0.5j

À 4 semaines, le changement Trelli → Jora → Jora → Trelli aura coûté 2j d’effort et rapporté une leçon : l’ergonomie de Jora présente des défauts incontournables et insurmontables.

La même équipe, avec son PO et son Manager, décide de remplacer la stratégie

[Tests Automatisés Unitaires]

par une stratégie de

[Campagne de Tests de Non-Régression Manuels]

4 semaines plus tard, elle décide qu’elle a pris une bonne décision : davantage de stories développées, des développeurs épanouis qui écrivent du code utile.

Impact aller, à t+16j

  • TU automatisés sur le code : 0j * 5 DEV x 4 sprints (zéro!)
  • stories supplémentaires réalisées : 4 x 4 sprints
  • tests de non-rég. manuels : 2j * 1 QA x 4 sprints

20 semaines plus tard, elle décide de revenir à une stratégie de tests automatisés à grain fin, si possible à mesure qu’on écrit ou modifie le code.

Impact aller, à t + 100j

  • interventions sur incidents en production : 1j * 5 DEV x 16 sprints
  • corrections de défauts trouvé en non-rég. : 1.5j x 5 DEV x 16 sprints
  • corrections de défauts insérés lors de corrections de défauts : 0.5 j x DEV x 16 sprints
  • tests de non-régression manuels : 4j * 1 QA x 16 sprints
  • communication de crise : 8j

📖 Leçons apprises :

  • assurer systématiquement la non-régression requiert 1) d’automatiser les vérifications 2) au plus près du code concerné 3) au fur et à mesure qu’on l’écrit
  • les tests manuels sont du “best effort”, i.e à hauteur du temps imparti, ils ne sont donc jamais couvrants
  • le travail d’un testeur est de trouver des problèmes et non de vérifier du code

Impact retour :

  • estimation des efforts de rétro-engineering : 5j
  • ajustements et communication : 2j
  • acquisition des techniques de TU automatisés sur du code existant : 1.5j * 5 DEV x 4 sprints
  • retro-engineering du code des stories pour ajout de TU : 2j * 5 DEV x 4 sprints

🚪 Conclusion 🚪

Tout au long de son activité, l’équipe ajuste son état de l’art.

Certains ajustements sont faciles à annuler : ceux dont l’impact est faible et observable rapidement. 🔎

Certains ajustements sont coûteux voire impossibles à annuler : ceux dont l’impact est important ET observable seulement après un long délai. 🔭

❓ en l’absence de boule de cristal, comment savoir si un ajustement de notre état de l’art impacte négativement le projet ?

🧯🧯🧯 si l’ajustement limite au lieu d’étendre votre stratégie de prévention des défauts, ne le faites pas 🧯🧯🧯

#qa #etatdelart #dettetechnique