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.

RECRUTE EQUIPIER

Nous cherchons un équipier pour un CDD d'un an. Si vous êtes mobile pour venir sur Valence et que vous souhaitez intégrer un grand projet industriel, cette opportunité pourrait vous intéresser.

Sincèrement, je pense que notre projet est une bonne école du génie logiciel. Nous exigeons un niveau de qualité maximal, convaincus que bien développer le bon produit permet de développer plus vite. Nous pratiquons l'eXtreme-Programming, Scrum, le Lean, la démarche orientée objet et la programmation par contrat.

Si vous êtes tentés par cette aventure enrichissante techniquement et humainement, l'offre est accessible via l'APEC ici. Si vous voulez en savoir plus sur notre équipe, on en parle sur d'autres blogs, tels celui d'Alexandre Boutin.

A bientôt?

THE TOYOTA WAY, JEFFREY K. LIKER

Après avoir lu plusieurs livres sur le Lean appliqué au développement logiciel, tels Lean Software Strategies, Implementing Lean Software Development et Lean Software Development, j'ai eu besoin de pousser plus loin ma compréhension de cette philosophie pour aider à sa pratique sur notre projet.
En insistant que le Lean s'apprenait par la pratique avec un mentor praticien et non dans les livres, Régis Médina m'a tout de même conseillé la lecture de The Toyota Way.

Le Toyota Way est la philosophie de gestion pratiquée par Toyota. Elle est structurée en 4 parties: la philosophie à long terme, le processus, collaborateurs et partenaires et la résolution des problèmes.

Nos années de pratique de l'eXtreme Programming, de Scrum et du Lean Software Development nous ont conduit à mettre l'accent sur l'aspect processus du Lean. Notre pratique s'appuie essentiellement sur les nombreux outils du Lean, tels le flux continu, le kanban, le jidoka, les andon, le heijunka, le management visuel, etc. Le dernier billet de Régis Médina révèle que nous ne représentons pas un cas isolé.

La lecture du Toyota Way nous a permis de comprendre que nous avions - non pas négligé - mais plutôt sous-estimé - les 3 autres facettes: la philosophie à long terme, les collaborateurs et les partenaires et la résolution des problèmes.

En réaction, nous sommes actuellement en train de travailler sur la résolution des problèmes. Sur ce thème, nous travaillons actuellement sur plusieurs axes en parallèle:

1. Rendre visibles les problèmes de l'équipe (voir billet);
   
2. Mettre en place une résolution systématique et structurée des problèmes (voir billet) ;
3. Animer régulièrement des chantiers d'amélioration de type Kaizen (billet à venir!);
4. Avec des praticiens qui enseignent le métier, pratiquer un leadership de terrain (billet à venir!).

A bientôt pour les billets annoncés!

AGILE TOUR 2009 VALENCE - C'EST FINI!

Cette année, pour l'édition 2009 de l'Agile Tour à Valence, nous avons reçu 150 participants représentant un peu plus de 40 organisations. Grâce aux intervenants et aux sponsors, nous avons accueilli plus de monde que l'année dernière autour du thème du développement agile.
Quelques blogueurs parlent de l'évènement, tout comme:

• Emmanuel Hugonnet,
• Alexandre Boutin et
• Florian Villoing.

Les présentations sont consultables en ligne sur le site du CARA.

En assistant à des conférences, on ramène toujours au moins une piste à explorer. Cette année, notre équipe à déjà commencé à mettre en pratique plusieurs idées recoltées à l'Agile Tour Valence:

• Rendre visibles les problèmes de l'équipe. Je consacrerai un billet à ce seul sujet.
• Valoriser la dette technique: de manière automatisée, la partie visible de la dette technique du projet est mesurée, puis estimée en heures de correction.
• Nos pratiques de résolution systématique des problèmes et d'amélioration continue n'ont pas toujours un impact visible sur nos indicateurs d'avancement (burndown et vélocité). Une explication consiste à conclure que ces pratiques sont inefficaces. Une autre explication consiste à supposer que notre panel d'indicateurs est inapproprié pour détecter l'effet de ces améliorations. Nous avons alors complété nos indicateurs de pilotages par 2 métriques révélant l'efficacité de nos pratiques d'amélioration continue. Je consacrerai également un billet à ce seul sujet.

A bientôt pour le détail de nos nouvelles pratiques.

PROGRAMME DE L'AGILE TOUR 2009 VALENCE

Voici en avant première le programme l'étape de Valence de l'Agile Tour 2009.

Cette année, Valence accueillera 14 orateurs qui animeront 12 sessions dans 4 salles. Cela représente 16 heures d'interventions dont 50% d'ateliers.

Cette année, 6 heures de sessions seront consacrées au Lean.

Les sessions sont organisées pour offrir 4 heures de sessions aux participants selon 3 profils type:

• novice en agilité;
  
• manager / décideur / chef de projet;
• développeur praticien.

Pour participer, l'inscription est gratuite et obligatoire. Venez nombreux en vous inscrivant ici.
A très bientôt!

VENEZ A L'AGILE TOUR A VALENCE

Venez nombreux à Valence assister aux conférences et participer aux ateliers de l'Agile Tour 2009.

L'évènement aura lieu le Jeudi 22 Octobre 2009 dans les locaux de l'IUT de Valence, de 13h à 18h.
Comme l'année précédente, l'évènement est gratuit et sera suivi d'un apéritif.

Cet évènement est la deuxième édition de la conférence itinérante sur les méthodes Agiles (eXtremeProgramming, Scrum, Lean ...). En 2008, l'évènement a rassemblé à Valence 120 participants, professionnels, enseignants et étudiants représentant les principaux industriels, sociétés de services en informatique et écoles de la région.

En particulier cette année, si vous êtes intéressés par le Lean, l'eXtreme Programming, le pilotage par les tests (TDD), la contractualisation des forfaits agiles, le management agile ou le CMMi, venez nous rejoindre le Jeudi 22 Octobre après-midi.

Pour faciliter l'organisation, l'inscription est obligatoire en remplissant le formulaire ici. Pour toute question, n'hésitez pas à nous contacter par mail.
A très bientôt!