Corriger des bugs Vs Résoudre des Problèmes : de l’Agile au Lean

equipe-baby-foot

(Article publié initialement en anglais sur InfoQ.com – Traduction par Florence Préault)

On peut définir le Lean de plusieurs façons mais la définition la plus motivante est celle proposée par le fondateur du Lean Enterprise Institute : John Shooke dans son livre Managing to Learn : « Le Lean management consiste à développer des produits en développant les employés ». Il y explique que le Lean consiste à développer les gens par la résolution de problème : travailler de façon à rendre les problèmes (et les opportunités d’apprentissage) visibles en utilisant une approche scientifique pour les résoudre, au fur et à mesure qu’ils apparaissent.

Quand je travaillais avec des équipes agiles de développement logiciel, je confondais bugs et problèmes : je pensais que le process Agile était Lean car il faisait émerger les bugs. Depuis, avec le recul, j’ai compris qu’une équipe agile qui produit des bugs n’a rien à voir avec un système Lean qui produit des opportunités d’apprentissage : c’était juste une équipe avec des problèmes de qualité comme j’en ai vu souvent.

Ma compréhension des bugs et des problèmes a évolué, le but de cet article est de vous donner des pistes pour mieux comprendre les problèmes qui causent des bugs afin d’améliorer la performance, en l’illustrant avec des exemples concrets. (note : je ne sous-entend en aucun cas que toutes les équipes agiles souffrent de ce même problème) …


Qu’est-ce qu’un bug?

En matière de développement logiciel, le terme de « bug » désigne beaucoup de choses : il peut s’agir d’une erreur système (NullPointerException, un code erreur 404 http, un écran bleu, …), un problème fonctionnel (si je clique sur B, le système devrait faire Z, or il fait Y), un problème de performance, de configuration, etc.

Un bug n’est pas un problème au sens “Lean” du terme tant qu’il n’est pas exprimé comme tel (cf paragraphe suivant). J’en ai vu (et même produit) un certain nombre et 95 % des bugs en question ne ressemblaient pas à des problèmes. A l’exception peut-être des bugs de performance.

Qu’est-ce qu’un problème ?

La définition standard dans le Toyota Way Field book, de Jeffrey Liker décrit les quatre points nécessaires à la définition d’un problème :

1- La performance actuelle

2- La performance souhaitée (standard ou objectif)

3- L’importance du problème telle que définie par la différence entre la perf actuelle et la perf cible

4- L’étendue et les caractéristiques du problème.

Comme l’explique Bené Brown dans son exposé sur la vulnérabilité TED talk about vulnerability : « Ce que l’on ne sait pas mesurer n’existe pas ». Plus concrètement, si vous ne pouvez pas expliquer un problème par un écart de performance, c’est probablement que vous n’y avez pas réfléchi suffisamment.

Avant de commencer à travailler sur un problème, il faut impérativement l’exprimer clairement, prendre le temps de le comprendre (l’expert Lean Michael Ballé dit qu’il faut même « l’apprécier ») et résister à la tentation de proposer une solution. Comme l’expliquait Einstein : « Si j’avais 1 heure pour résoudre un problème, je passerais les 55 premières minutes à réfléchir au problème et 5 mn à réfléchir à la solution ». Personne ne prétend que c’est facile !

Dans un contexte de développement logiciel agile, les indicateurs de performance peuvent prendre la forme d’un diagramme (coûts et retards), nombre d’anomalies, temps de réponse (qualité), note du client sur les User Stories livrées (note sur 10 de satisfaction client) et le nombre de user stories (ou story points) livrées par sprint (productivité).

Avec ce type d’indicateurs, voici des exemples de problèmes :

. Qualité : la cible en termes de temps de réponse pour une page donnée est de 500 ms or nous avons mesuré 1500 ms avec 5000 utilisateurs en simultanée.

. Qualité : le nombre d’anomalies qu’il reste à la fin du sprint (2 au lieu de zéro).

. Coûts/ retard : nous tablions sur 3 jours pour finaliser cette user story, il nous en a fallu 8.

. Productivité : l’équipe a livré 5 user stories à la fin du sprint au lieu des 7 prévues

. Satisfaction client : Nous voulons une note de 8/10 pour chaque user story, or, nous en avons eu 2 en deçà lors du dernier sprint (respectivement 6,5 et 7).

Comment extraire des problèmes d’anomalies ?

Les anomalies ou bugs sont les symptômes de soucis d’ordre plus général et il est indispensable de comprendre la corrélation entre ces symptômes et les problèmes existants. On pourrait donc considérer que le travail des équipes qui font de l’amélioration continue au quotidien est de repérer et extraire les problèmes de la pile de bugs. Cela nécessite de faire une analyse et de transformer le matériau brut en opportunités d’apprentissage.

J’ai trouvé une manière de faire en classant les anomalies par famille pour comprendre le poids de chacune. La plupart du temps, un bug est la cause d’un problème existant ou est lui-même un problème. Par cette corrélation, on s’assure que l’on prend les problèmes dans le bon ordre, en commençant par celui qui a le plus gros impact sur la performance opérationnelle. Si vous ne savez toujours pas par quoi commencer, le lean nous dit de partir de la qualité !

Exemple 1 : dans un monde agile

J’étais manager d’une équipe de développement agile. Comme souvent, il ne s’agissait pas d’une équipe cross-fonctionnelle mais d’une équipe en silo faisant ses développements par itération, produisant le logiciel côté serveur pour des équipes d’application qui l’utilisaient dans d’autres itérations.

Grâce au Pareto sur les anomalies, nous avons identifié une famille représentant 20 % d’entre elles : ouverts par des équipes d’application et liés à la définition « implicite » de l’API côté serveur du logiciel. Quand les équipes métier ont utilisé ces services applicatifs, il se sont rendus compte qu’il il manquait des paramètres en entrée et des données en sorties, etc… Aussi ces équipes métier ont ouvert des bugs en spécifiant les données en sorties attendues et manquantes. L’équipe qui développe ses services répondait alors : mais c’était implicite que nous ne retournerions pas cette donnée.

Nous avons aussi remarqué que la durée de vie de tels bugs, entre leur création et leur résolution, était d’environ 4 semaines. Le code est livré à l’issue d’une itération d’un mois et l’équipe client l’utilise dans le mois qui suit (dans le meilleur des cas). Ils tombent alors sur le bug généré par le développeur 2 à 3 semaines après qu’il l’ait codé, il doit donc s’y remettre,…

Pour y remédier, nous avons décidé de revoir notre façon de travailler et de mettre les gens ensemble en équipes co-localisées, cross fonctionnelles et interdisciplinaires.

Grâce à cette approche, nous avons réduit de façon très significative (environ 50 %) ces bugs « implicit API ». Plus intéressant encore : la durée de vie de ces types de bugs est tombée à 2 jours. Précisons que certains bugs étaient repérés sans faire l’objet d’un ticket d’incident car les développeurs en pair programming les corrigeaient aussitôt.

Malgré ces progrès, je n’étais pas à l’aise, j’ai compris plus tard pourquoi : d’un point de vue Lean, il y avait deux problèmes :

1-La persistance des anomalies générait du rework et le système de développement produisait des gaspillages : en l’absence de qualité dans le process (“built-in quality”) rien ne garantissait que nous n’allions pas transmettre des problèmes à l’étape suivante. D’autre part, aucune pratique standard n’obligeait l’équipe à s’arrêter à chaque problème pour essayer de le comprendre.

2-Même si ces résultats étaient significatifs et encourageants, il n’y avait aucune corrélation directe avec la performance quotidienne de l’équipe qui permette de prendre des mesures immédiates pour en voir les résultats dès le lendemain. Nous ne regardions que le résultat macro à l’issue de la release de 6 mois. A ce moment-là, on ne pouvait que constater une amélioration de la qualité due à la nouvelle organisation cross-fonctionnelle mais nous n’avions pas les moyens de surveiller et faire évoluer au quotidien.

Ce qui se passe dans un monde plus “Lean”

Deux ans plus tard, dans la même organisation, je suis devenu leader et coach chargé de mettre en œuvre l’Agile dans le cadre d’un grand projet multi-équipes et multi-technologies. L’une des équipes développe une intégration technique complexe avec une technologie dont nous sommes loin d’être des experts. Cette équipe n’a pas réussi à livrer une seule user story au cours des deux derniers sprints et rencontre des problèmes de qualité, avec de nombreux bugs. Lors de la rétrospective sur le dernier des deux sprints, l’équipe décide de passer chaque semaine les bugs en revue (analyse de bacs rouge en langage Lean). Elle commence alors par bâtir un Pareto des problèmes.

Dès lors, elle se fixe comme objectif d’éliminer la cause racine de chaque famille de bug, une par une, en commençant par celles qui ont le plus d’occurrences. Pour favoriser la collaboration sur ce sujet, le Scrum Master décide d’afficher ce pareto près du Scrum Board avec le nombre de bugs et de le mettre à jour quotidiennement. Chaque nouveau bug est répertorié immédiatement lors de la réunion du matin, quand l’équipe présente ses bugs du jour. Cela rend explicite et concrète la notion de qualité quotidienne pour l’équipe. Cela aide aussi à faire l’étape « C » du PDCA : le check. Quand le problème est éradiqué, il ne doit plus y avoir de bug sur cette ligne pour une semaine. Et si cela se reproduit, c’est une nouvelle opportunité d’apprentissage !

Prenons un exemple : l’équipe identifie une régression comme famille de bug ; une modification logicielle a cassé une fonctionnalité existante. Cela se produit généralement sur l’interface utilisateur qu’il est très difficile de tester automatiquement. L’une des causes racine identifiées vient de l’inexpérience des développeurs les plus juniors qui ne comprennent pas toujours l’impact de leur modification sur le code. La contre-mesure est d’introduire une nouvelle étape dans le processus, une revue de code avant le commit sur le référentiel SVN avec un développeur plus senior. Non seulement cette étape de 15 minutes réduit drastiquement les régressions, ce qui est visible quotidiennement sur le nombre de bugs par release (2 releases par jour) mais elle permet aussi d’améliorer les compétences des développeurs junior.

A la fin, tous les problèmes sont résolus et les résultats sont remarquables : les problèmes ont été éliminés un par un grâce aux standards (code review avant commit). Le nombre de bugs quotidien chute et le nombre de user stories livrées – fonctionnelles et sans bug – augmente à chaque itération. En 3 mois, l’équipe qui détenait le triste record de livraison de bugs au sein du projet est devenue un exemple à suivre d’équipe qui livre de la qualité rapidement.

Cette approche, plus Lean que la précédente, a un impact direct sur la performance quotidienne (qualité) et la productivité (nombre de user stories livrées) et l’équipe a mis la barre haute en termes de standards opérationnels.

indicators-agile-team-operae-partners

Exemple d’indicateurs de performance pour équipe agile

Transformer une équipe Agile en une équipe Lean

A partir de ces exemples et de ce que j’ai appris, voici la roadmap que je propose pour transformer une équipe agile en équipe Lean qui apprend :

. Mesurer la performance, la rendre visible et en discuter tous les jours

Ce qui suit sera peut-être difficile à entendre pour certains coaches agiles mais la vérité c’est que si l’on veut améliorer quelque chose, il faut le mesurer. D’autant que l’on n’apprend que si l’on se confronte à la réalité. C’est ainsi que font les géants du web (Google, Amazon, Twitter, Facebook) et d’autres leaders comme Etsy : ils mesurent quasiment tout. Ca n’est pas en comptant simplement les story points qu’ils sont devenus ce qu’ils sont ! Un exemple concret pour une équipe agile : au-delà du burndown chart du sprint, montrer la performance sur la qualité (nombre de bugs encore ouverts, nombre de bugs par release, par famille, etc), satisfaction client (une note sur 10 par user story par exemple) et se demander chaque jour pourquoi l’on n’atteint pas l’objectif sur le burndown chart.

. S’assurer que les problèmes sont exprimés au sens « lean » du terme

Un problème doit être exprimé comme une différence entre la performance constatée et la cible. Le pareto est un outil parfait pour classer des données brutes par familles mais il nécessite une analyse complémentaire pour comprendre comment chaque famille affecte la performance.

De cette manière, vous serez sûr d’avoir correctement formulé le problème et de l’attaquer de la bonne manière, du point de vue de la performance économique.

. Traiter les problèmes un par un quand ils apparaissent

L’une des clés de la résolution de problème en Lean : on ne traite pas plusieurs problèmes à la fois. On en traite un seul pour comprendre son impact sur les indicateurs de performance et pour s’assurer que l’on comprend la relation de cause à effet.

. Faire le check

D’expérience, c’est l’étape que l’on a hélas tendance à oublier. Confronter ses estimations à la réalité. Cela n’a pas fonctionné comme vous l’espériez ? Super ! Que peut-on en apprendre ? C’est dans cet espace précieux entre ce que vous pensiez qu’il allait se passer et ce qui s’est réellement passé que l’apprentissage se produit. Exactement ce qui s’est passé avec la 2e équipe. Comme l’explique Stephen J. Spear dans Chasing the Rabbit, c’est là que votre système organisationnel susurre à votre oreille : « il y a une chose que tu ne sais pas encore mais si tu écoutes attentivement, je vais te le dire ». C’est là que l’équipe développe son expertise sur son propre travail et ses processus et devient à coup sûr une dream team.

De l’Agile au Lean

En tant qu’Agiliste depuis 2004, j’ai évolué vers le Lean au cours des dernières années et cela m’a permis de dépasser les obstacles que l’Agile seule ne me permettait pas de surmonter.

Le Lean m’a permis d’aller au-delà de l’Agile, d’adopter des pratiques d’amélioration continue qui ont un effet direct sur la performance de l’équipe et son engagement. Faire un distinguo clair entre les bugs et les problèmes a été déterminant dans cette amélioration.

 

Advertisements

2 Comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s