Recap

Fonctionnement actuel/classique

Classification (criticité)

Les défauts sont classés en fonction du lieux de découverte plutôt que par impact, partant du principe que :

• plus c’est tard plus c’est cher : mobilisation du support, relivraison, astreinte, perte de confiance client/support, …
• un bug avec un impact fort (système de paiement, …) n’est pas si grave s’il est détecté en interne plutôt que par le client

On a donc (exemple) :

• A : Dévelopeur, PO
• B : Démo fin de sprint, QA
• C : Lancement, Démo client, Beta
• D : production

On aura donc 2 objectifs : Introduire moins de bug, mais aussi les détecter plus tôt en visant le 0 bugs de type ‘D’

Traitement : Procéssus en 8 étapes

Version Toyota

Mesure : Défauts / véhicule produit

Adaptation à la tech

Mesure : Plusieurs indicateurs possibles :

• Change failure rate (% de déploiements introduisant un incident) (avantage : c’est une des métrique DORA d’accelerate, on avance sur les 2 tableaux)
• Total Backlog + nouveaux (ce que fait Cyril)

Management visuel : Jira, Gitlab, …
Attention : Il manque souvent le taux d’introduction (on a plutôt des listes)

Standard : Notion, Wiki, …

Formation : Tutorials, Katas, Pair/Mob, Code review

Partie importante de la méthode, à ne pas négliger.

Exemple cité : la personne est formée : on montre, puis pratique assistée, puis pratique seule un flow. Elle ne peut aller sur la chaine de prod que lorsqu’elle sait produire au niveau de qualité attendu (mais pas de vitesse).

Weak point : Faire émerger des points faibles répétés et transverse.

Exemple: problème répété de lenteur sur la DB (n+1 query).
Lorsqu’on détecte un weak point, on provisionne du temps d’analyse et de résolution (ou une task force focalisée sur le problème) pour le traiter de manière définitive

ça a également permis d’ajuster la formation initiale : Académie (site dédié) de formation avec exemple de point d’attention, simulation, MR, …

Environnement de travail : Etre capable de trouver une infos sans demander à personne

Lint, structure de code, Wiki, Portail développeur, … Favoriser l’écrit !

Format : QRQC

Format de réfléxion autour d’un bug.

Attention : L’exemple suivant est précisé comme étant très détaillé, ce serait plutôt le niveau de détail attendu sur un Weak Point.

• Présenter le problème d’un point de vue client
• Trouver la MR qui introduit le problème (REX 3)
• Montre le raisonnement pour avoir une correction immédiate, ex:
  • Ajout d’index sur la DB
  • Nouveau endpoint
  • Se rend compte qu’il y a des n+1 query
  • …
  • Montre les stats
• Se pose la question de “Comment ça a été introduit”, qu’en tirer comme information
  • exemples de code
  • proposition de modification de fond
• Explique ce qui a été essayé, ce qui a marché ou non, …
• Changements recommandés (avec actions prises éventuelles):
  • Comment éviter l’introduction de ce type de bug
  • Comment les détecter plus tôt

Attention : Bien regarder les standards : L’exemple montre aussi beaucoup outils/méthodes, pas seulement des procédures internes (OpenApi, GAnalytics, format Stripe pour les montants, …).

Un format plus simple :

Rituel : Claim Asaichi

Normallement quotidien

Séparé du daily : C’est n’est pas un “ce que j’ai fait / ce que je vais faire” mais un point ou chacun apporte sa connaissance pour résoudre un problème

Les devs vont présenter les QRQC : Solutions appliquées, , l’équipe va réagir, challenger les solutions, identifier des weak points, …

Un REX indique que c’était un point hebdo, un autre en daily.

D’autres personnes que les devs peuvent venir : Autre équipe, CEO, …

Candidat idéal pour un format async/démat ?

Notes/Difficultés

• Mettre l’attention sur les bugs entrants si le stock est important
• Charge de travail : 2-3h par défaut
• Conditions : Deadlines, … peuvent vite devenir les causes racines
  • Ne se focus que sur les solutions techniques et pas organisationnelles (laisser ça à la rétro ?)
  • Utiliser un format simple pour se forcer à être synthétique/précis et ne pas y passer trop de temps
• Travailler équipe par équipe pour bien scaler
• Buy-in du top management important