Des incidents en production, c’est fréquent (si, si…) et il faut savoir assurer leur gestion. Imaginons ensemble cette situation totalement fictive…Nous sommes quelques jours avant Noël, le service de paiement est tombé sur notre plateforme e-commerce de jouets. Il n’est plus possible de valider son panier, nous perdons à la minute des dizaines de paniers.
L’effervescence commence, tout le monde veut savoir ce qui se passe !
Comme fréquemment dans notre entreprise, l’équipe de paiement est composée de membres qui sont aujourd’hui en présentiel et en télétravail. Des discussions dans les bureaux vont commencer, mais tout le monde ne pourra pas y participer.
Comment s’y prendre pour gérer au mieux la gestion des incidents de production ?
Ce qui se passe lors d’un incident…
Lorsqu’un problème survient, la panique s’empare souvent de l’équipe :
- Les stakeholders veulent comprendre ce qui se passe.
- Les développeurs doivent trouver la source du problème.
- Et les interactions vont se multiplier. Vous me direz, et alors, <troll> c’est bien de communiquer non ? </troll >
La communication est un élément important, sauf si elle vient entraver l’efficacité de l’équipe.
Vous connaissez la loi de Brooks de Frédéric Brooks ? C’est une prédiction sur le nombre d’interactions possibles dans un projet. Cette loi dit :
« Ajouter des personnes à un projet en retard accroît son retard »
Cet énoncé peut sembler contre intuitif, mais il est basé sur le postulat que la plupart des tâches ne sont pas parallélisables. Observons son impact sur l’équipe lorsqu’un incident arrive en production.
Représentation des 15 interactions en présence de 6 individus
Parlons en premier d’une tâche simple et pourtant très vite complexe, la communication au sein d’un groupe.
- Soit N le nombre d’individus à interagir, alors on a la formule N * (N-1) / 2.
- Par exemple, pour 6 personnes, il existe 6 * (6-1) / 2, soit 15 interactions possibles.
Il faut aussi considérer la création possible de sous-groupes de discussions entre les 6 personnes. Dès lors, il devient difficile d’échanger efficacement.
De plus, lorsqu’un incident arrive, tout le monde veut être tenu au courant ! Plus le nombre de questions augmente, et plus l’équipe devra prendre de temps pour y répondre.
Pour résumer, l’équipe se retrouve avec deux tâches lors d’un incident:
- Résoudre le problème
- Communiquer sur la situation
Comme énoncé plus haut, il est difficile de partitionner les deux. Je vous propose ici une méthode pour réduire le nombre de messages et garder un meilleur focus sur la résolution de l’incident.
La méthode pour faciliter la gestion des incidents
Pour réduire le nombre de message, basons nous sur un des principes du manifeste agile
“La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.”
L’équipe se concentre sur deux solutions pour rester simple:
- La centralisation des échanges sur un canal commun (Teams, Slack ou dans une salle de réunion)
- La mise en place d’une personne référente pour communiquer sur le problème, qu’on appellera ici “le commander”
L’idée est d’éviter qu’une première personne pose une question sur le problème et son statut, puis que la question revienne avec une deuxième personne, une troisième…
L’information est centralisée pour gagner du temps et éviter que les mêmes questions reviennent.
De cette manière, le nombre d’interactions passe de 15 à 2 :
- Celle entre les personnes en charge de l’incident,
- et le canal de discussion.
L’information passe plus vite, et les développeurs sont concentrés sur l’essentiel, résoudre le souci.
Il reste 2 étapes à décrire : l’application de la méthode et le suivi d’indicateurs.
La mise en place du commander
Le Scrum master va donc inviter tout le monde à échanger au même endroit. Les questions seront centralisées et plus simples à répondre. Une personne pourra se pencher sur la résolution du problème seule ou à plusieurs.
Les communications passeront à un endroit prévu pour (une salle de réunion, un canal slack, un teams…).
Le commander désigné sera chargé de tenir informé tous les stakeholders impliqués et de répondre aux questions.
La discussion commence avec un rappel de l’incident en cours et des informations déjà connues, et le commander vient apporter les nouvelles informations sur le canal de communication choisi au fur et à mesure.
Facile, non ?
L’introspection
Le problème de paiement est résolu, les utilisateurs peuvent valider leur panier et procéder à leur paiement. Il va rester une étape tout aussi importante, l’introspection.
Le manifeste agile dit :
“À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.”
Dans cette optique, l’équipe va organiser une rétrospective sur l’incident. Vous pouvez utiliser un format classique comme la rétrospective A3. Cette partie n’est pas le cœur de mon propos, je ne m’y attarde donc pas.
Les indicateurs, pour une gestion des incidents à long terme
L’équipe va aussi choisir des indicateurs pour évaluer au fil du temps la gestion d’incidents. Parmi mes favoris, je vous suggère de regarder les indicateurs DORA qui sont appropriés à cette problématique. On y retrouve le Change Failure Rate et Lead Time to Change ou encore le Mean Time to Recovery.
Le Change Failure rate est un pourcentage basé sur :
“le nombre de déploiement avec échec / le nombre total de déploiement”
L’objectif avec la rétrospective est de réduire le nombre d’incident en production, et donc baisser le taux de Change Failure rate.
https://waydev.co/change-failure-rate/
Une fois la méthode comprise et validée, ce sera à l’équipe de se l’approprier. Le scrum master sera présent pour aider à mettre en place et à suivre les indicateurs.
Elouen
Si vous voulez en apprendre un peu plus sur le rôle de Scrum master, je vous invite à lire la série d’article de Matthieu.
KōKan organise toutes l’année des formations au rôle de Scrum Master (préparation de la certification PSM A).
Publié le 19 décembre 2023
