RESOUDRE LES PROBLEMES

C'est bien bien sympa de voir les problèmes. Ceci dit, l'objectif reste de les résoudre!

Alors, ces problèmes identifiés et exposés à la vue de tous, sont-ils traités?

1. PETIT RAPPEL

Rappelez-vous: l'équipe prend conscience que pour apprendre, progresser et gagner en efficacité, elle doit résoudre systématiquement les problèmes qu'elle rencontre.
Alors,

• on développe la détection systématique des problèmes;
• on affiche les problèmes pour les rendre visibles;
• on résout les problèmes de manière structurée.

Cette attitude et cette démarche sont décrit dans un précédant billet.

2. EST-CE PRATIQUÉ?

Afin de s'assurer que ces beaux principes sont devenus des pratiques, nous affichons un indicateur révélant le nombre de problèmes résolus (le bas des barres) et le nombre de problèmes non-résolus (le haut des barres). Cet indicateur est actualisé à chaque itération (voir photo ci-dessus).

3. EST-CE EFFICACE?

C'est bien joli de mettre en place de nouvelles pratiques - encore faut-il qu'il y ait un retour sur investissement ... Et là, il faut reconnaître qu'il est difficile de mesurer l'impact de la résolution systématique des problèmes.

Difficile n'est pas impossible: les burndown-chart et la courbe de non-qualité révèlent les gains en productivité et en qualité de cette démarche.
Notamment, la courbe de non-qualité révèle de sévères réductions de la non-qualité correspondant à des chantiers mis en place suite à un problème levé. Ensuite, les paliers qui suivent une chute de cette courbe montrent que l'action corrective "coup de poing" s'est efficacement transformée en pratique continue.
Puisque le burndown-chart ne souffre pas d'une augmentation ou d'une stagnation du "restant à faire", c'est que la résolution du problème a contribué positivement au développement.

4. EFFET SECONDAIRE

Nous avons remarqué un autre effet secondaire bénéfique de cette démarche. Il s'agit d'une très forte augmentation de la standardisation.
En effet, la résolution d'un problème résulte généralement en:

• une contre mesure automatisée (scriptée dans le build, dans le commit, ...);
• une contre mesure manuelle décrite par une petite procédure textuelle;
• l'amélioration d'une procédure existante.

Ainsi, nous avons constaté que notre wiki s'est enrichi de beaucoup de petites procédures pragmatiques. Il s'agit de l'officialisation des meilleures manières de faire à ce moment pour ce projet. Cela constitue un standard léger et évolutif, partagé par les équipiers.

Je pensais que la standardisation étaient une démarche formelle, lourde et ralentissant l'évolution. Je suis désormais convaincu du contraire.

VOIR LES PROBLEMES

"Loin des yeux, loin du cœur". Un problème qui n'est pas visible n'est pas traité.

Sur les conseils de Régis Médina et après avoir assisté à sa conférence présentée à l'Agile Tour à Valence, nous cherchons depuis quelques itérations à rendre nos problèmes visibles pour ne pas les laisser trainer. Pour cela, nous avons mis en place 2 pratiques.

1. VOIR LES DÉFAUTS DU PROCESSUS

La première, déjà évoquée à l'occasion d'un billet sur la résolution systématique des problèmes consiste à afficher sur un tableau dédié les problèmes rencontrés par l'équipe (voir photo).

2. VOIR LES DÉFAUTS DU PRODUIT

La deuxième consiste à identifier, mesurer et afficher quotidiennement et automatiquement la non-qualité du produit. Il s'agit de la somme de tout ce qui est à corriger pour atteindre le niveau de qualité que nous recherchons pour notre produit (et nous sommes TRÈS exigeants).
Ainsi, nous sommons

• le nombre de warnings de compilation du code et des tests,
  
• le nombre d'opérations qui dépassent un seuil de complexité,
  
• le nombre de classes non couvertes à 100% par des tests automatisés,
  
• le nombre de classes qui ne respectent pas les standards de codage ...

L'historique de cette métrique enrichie une courbe qui est affichée quotidiennement à l'endroit le l'open space où il y a le plus de passage, juste à côté des burndown charts.

Depuis que nous avons décidé de rendre visibles ces problèmes, nous nous sommes mis de manière disciplinée et continue à réduire cette non-qualité, comme le révèle la courbe affichée.

Dès que la courbe se stabilise à un niveau acceptable de non-qualité (correspondant à un minimum de travail en cours) nous enrichissons cet indicateur d'une nouvelle classe de défauts. Vous verrez un tel saut commenté à la main sur la courbe affichée. Ainsi, nous relevons notre niveau d'exigence de manière maitrisée.

Nous ne nous intéressons pas à la valeur de la métrique mais plutôt à la pente de la courbe. En effet, elle révèle très clairement si l'équipe s'améliore ou se relâche.

Il est très intéressant d'afficher cette courbe de non-qualité à côté des burndown charts. En effet, on constate souvent que l'amélioration de la productivité (visible sur un burndown chart) se fait au détriment de la qualité (visible sur la courbe de non-qualité). L'affichage quotidien et côte à côte de ces 2 courbes permet de visualiser que nous ne jouons pas aux vases communicants. Mieux, nous arrivons même à corréler que travailler mieux permet de travailler plus vite!

Enfin, nous avons aussi valorisé cette mesure de la non-qualité du produit. A chaque catégorie de défaut identifié nous avons associé une valeur: il s'agit du temps théorique requis pour corriger un défaut de cette catégorie. Ainsi, nous mesurons le temps estimé nécessaire pour obtenir un produit de la qualité recherchée.

Avec la mesure quotidienne et combinée du restant à faire et de la non-qualité du produit, nous avons des outils objectifs, pertinents et complémentaires pour piloter notre développement.