"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 ...
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.
Bonjour Emmanuel,
RépondreSupprimerMerci pour ces très beaux retours d’expériences.
Je n’ai jamais réussi dans mes équipes / projets à avoir ce niveau d’exigence, moi je dis bravo !
Quelques questions si tu veux bien en rapport avec cette courbe et le titre du poste qui est « VOIR LES PROBLEMES »:
• Qui est ton client ?
• A qui donc s’adresse cette courbe ?
• Ce qui amène la question suivante : si ton produit ne possède pas par exemple de : « classes qui ne respectent pas les standards de codage » en quoi cela est un problème pour ton client ?
• Quel seuil est acceptable pour toi, ton équipe, ton client ?
• Qui fixe ce seuil ?
• Ton produit est-il « livrable » si le seuil acceptable est dépassé ?
• Y a-t-il des indicateurs plus importants que d’autres (subjectivement / objectivement) ?
• Ou sont réellement les problèmes au niveau de ta courbe ?
• Comment l’EQUIPE sait qu’il y a un VRAI problème ?
• C’est un problème ou un souci ?
• Quelle contre-mesure est en place pour résoudre ton problème ?
J’aime beaucoup (en temps qu’amateur des chiffres) cette notion de rajouter des exigences à cette courbe.
SI je devais (ce qui suit n’est que fiction) suivre cette indicateur, je le décomposerais en N indicateurs avec une ligne verte sur chacun pour indiquer le seuil acceptable.
SI je devais suivre ces indicateurs (si bien sûr mon client me le demandais) alors je détecterais de ce fait les écarts de performances sur chaque indicateur et lancerais pourquoi pas un cycle PDCA pour résoudre/améliorer cela.
Par exemple, sur un projet ou la notion d’itération serait présente (ce n’est pas toujours le cas), à chaque itération si cela m’est demandé par mon client, car c’est avec lui que je défini les indicateurs à suivre, je lui montrerais :
• Les indicateurs sur la qualité externe du produit : User Story implémentée, vélocité, …
• Les indicateurs sur la qualité interne du produit (si nous avons convenu que cela était important pour lui) : Couverture des tests unitaires, convention de codage [78% (80% est le seuil acceptable)], …
La question serait ensuite : pouvons nous montrer / intégrer une User Story si la qualité externe est respectée mais pas la qualité interne. Certain client nous dirons NON d’autres OUI.
S’ils disent NON, je ferais évoluer pourquoi pas mes indicateurs pour avoir une vue orientée User Story (valeur d'un point de vu client) pour voir toutes les U.C qui s'écartent des performances attendues
Si au final nous avons un écart de performance , c.a.d qu’une User Story risque d'être rejetée par mon client alors là en effet l’équipe à un VRAI problème :)
Christophe.
PS: J'aime beaucoup cette citation, "Loin des yeux, loin du cœur".
Bonjour Christophe,
RépondreSupprimer> • Qui est ton client ?
Nous en avons 2: 1 industriel et un certificateur. Nous développons un logiciel critique.
> • A qui donc s’adresse cette courbe ?
Le client certificateur car il souhaite vérifier que nous tenons les critères de qualité que nous avons imposé sur le produit pour tenir les objectifs de sûreté de fonctionnement.
> • Ce qui amène la question suivante : si ton produit ne possède pas par exemple de : « classes qui ne respectent pas les standards de codage » en quoi cela est un problème pour ton client ?
Car le client certificateur veut s'assurer que le logiciel puisse être modifié par une nouvelle génération de développeurs dans 10 ans. La norme de développement que nous devons respecter exige que le logiciel soit conforme à des standards afin de faciliter le transfert de compétance.
> • Quel seuil est acceptable pour toi, ton équipe, ton client ?
> • Qui fixe ce seuil ?
Nous n'avons pas encore des seuils pour toutes ces métriques, sauf pour la couverture structurelle (100%).
> • Ton produit est-il « livrable » si le seuil acceptable est dépassé ?
Le client industriel acceptera la livraison et l'utilisera. Mais pour une mise en production réelle il faut l'accord du client certificateur. Il ne donnera pas son accord s'il n'est pas rassuré par la sûreté de fonctionnement du produit.
> • Y a-t-il des indicateurs plus importants que d’autres (subjectivement / objectivement) ?
Oui, en effet, comme la couverture structurelle.
> • Ou sont réellement les problèmes au niveau de ta courbe ?
Ils sont mélangés quels que soient leur gravité. Nous avons en plus des courbes d'historique par métrique. Cependant, il n'est pas pragmatique d'analyser 10 courbes tous les matins - d'où cette courbe de synthèse qui sert à lever des alertes.
> • Comment l’EQUIPE sait qu’il y a un VRAI problème ?
Si elle est flemmarde, elle attend que le ScrumMaster boive son café en analysant les courbe en arrivant le matin.
> • C’est un problème ou un souci ?
Pas de qualité = pas de mise en prodution car il s'agit le logiciel critique.
> • Quelle contre-mesure est en place pour résoudre ton problème ?
On lance des actions correctives lors des stand-ups après analyse des courbes de qualité. Mais, en effer, il n'y a pas de contremesure qui empèche la non-qualité de s'introdure dans le produit à priori.
Merci pour tes remarques et tes conseils.
A++
ManU
---
> Merci pour tes remarques et tes conseils.
RépondreSupprimerPas vraiment de conseil, juste « en situation, dans ce contexte là voilà MAY BE ce que je ferais »
Ensuite si je permets de te demander si c’est un problème ou souci, c’était juste pour insister sur le fait que de temps en temps (chez moi c'est le cas et donc peut être ailleurs ?) nous mettons en place des activités, des processus, … afin d’améliorer / résoudre des situations mais qui d’un point de vue client n’apporte pas de VALEUR (les fameux MUDA I ou II que tu dois connaitre).
D’où cette question « Comment l’EQUIPE sait qu’il y a un VRAI problème ? »
Je vais m'arrêter là, en tout cas merci d’avoir répondu à mes questions et de me donner la possibilité de mieux comprendre ton travail et tes expérimentations.
Christophe
Je pense qu'en effet nous résolvons certains problèmes qui n'en sont pas pour notre client final.
RépondreSupprimerUn exemple que nous avait donné Régis Médina était le temps de build trop long.
Souvent, nous voyons certains douter: est-ce qu'on ne va pas trop loin?
Je pense qu'une partie de la solution est dans le rythme durable. Un projet de développement (chez nous en tout cas) est une LONGUE aventure. Pour la mener à bout sans s'épuiser et sans dépenser une fortune, il est pertinent d'adopter cette attitude d'élimination systématique des gaspillages.
De tels gaspillages ne sont pas forcément un problème pour le client. Par contre, il le sont pour celui qui avance l'argent du développement.
Bonjour,
RépondreSupprimerJe suis a la recherche de conseil pour le choix d'une méthode de gestion d'équipe/de projet.
Voici un peu le point sur la situation actuelle: nous sommes < 5 developpeurs et on se partage une grosse farde avec tous les "dossiers" des programmes a écrire.
Il n'y a pas de communication ni d'entrain, celui qui travaille le plus vite se recupere le plus de dossier. Celui qui a le plus de compétence récupère aussi les problemes (basique) que les autre ne savent pas corriger...(d'ailleurs des fois ils ne font même pas semblant de chercher a les corriger...)
le chef de projet ne suit pas vraiment la chose : il se contente de demander si les développements avancent (il y a plus de 200 programmes / sous programmes...). Le projet a deja commencé en retard , les dossiers sont succincts / incomplets.
On nous balance les dossiers comme si on donnait du grain a des poules.
Le gros probleme c'est qu'au dessus (aux réunions ou les programmeurs ne sont pas invités) ils disent que ca va.... et de toute facon eux ils ont pondu des dossiers apres le reste c'est de la faute des programmeurs qui ne vont pas assez vite.
J' essaye depuis peu la méthode pomodoro qui ne force un peu a (re-)travailler, mais si j'améliore mon travail en terme de rapidité je recupere celui des autres et de nouveau le rythme (et le moral) baisse.
Avez vous qq conseils a me donner
Alfred Dupont
Bonjour,
Je suis a la recherche de conseil pour le choix d'une méthode de gestion d'équipe/de projet.
Voici un peu le point sur la situation actuelle: nous sommes < 5 developpeurs et on se partage une grosse farde avec tous les "dossiers" des programmes a écrire.
Il n'y a pas de communication ni d'entrain, celui qui travaille le plus vite se recupere le plus de dossier. Celui qui a le plus de compétence récupère aussi les problemes (basique) que les autre ne savent pas corriger...(d'ailleurs des fois ils ne font même pas semblant de chercher a les corriger...)
le chef de projet ne suit pas vraiment la chose : il se contente de demander si les développements avancent (il y a plus de 200 programmes / sous programmes...). Le projet a deja commencé en retard , les dossiers sont succincts / incomplets.
On nous balance les dossiers comme si on donnait du grain a des poules.
Le gros probleme c'est qu'au dessus (aux réunions ou les programmeurs ne sont pas invités) ils disent que ca va.... et de toute facon eux ils ont pondu des dossiers apres le reste c'est de la faute des programmeurs qui ne vont pas assez vite.
J' essaye depuis peu la méthode pomodoro qui ne force un peu a (re-)travailler, mais si j'améliore mon travail en terme de rapidité je recupere celui des autres et de nouveau le rythme (et le moral) baisse.
Avez vous qq conseils a me donner
Alfred Dupont
fox_xtcsld@trashmail.net
Merci
Merci