UN RAPPEL A L'ORDREIl y a quelques semaines, notre équipe projet a eu la chance de recevoir la visite d'un coach Lean, pionner de l'eXtreme Programming en France. Nous avons eu la chance de travailler ensemble une journée sur nos pratiques de développement.
J'ai attaqué la journée plein d'enthousiasme et je l'ai terminé avec le moral dans les chaussettes. J'avais honte des problèmes qu'il nous a fait voir ... Ceci dit, il était bénéfique de prendre conscience de nos obstacles et d'être remis sur la bonne voie. En tout cas, je n'oublierai pas le rappel à l'ordre suivant:
Le Lean, c'est
- visualiser la production pour révéler les problèmes;
- réagir immédiatement;
- puis résoudre les problèmes un à un;
- pour améliorer les pratiques.
Ce billet est consacré au premier point:
VISUALISER LA PRODUCTION POUR RÉVÉLER LES PROBLÈMES
Prendre conscience d'un problème est la première étape de sa résolution. Voir un problème est une manière efficace d'en prendre conscience. L'afficher pour que tous le voient est une manière de s'engager dans sa résolution. Reste à organiser la production pour que les problèmes se voient.
C'est ici que les choses se compliquent pour le développement logiciel. En effet, il s'agit d'un métier dont la production ne se voit pas de manière évidente. C'est aussi ce qui rend le défi plus amusant en nous obligeant à devenir créatifs.
Voici quelques exemples de pratiques déployées par notre équipe pour visualiser la production pour révéler les problèmes.
PROBLÈME: RETARDS
L'équipe affiche ses burndown chart. Cela lui permet de voir une mesure de sa production. Si la courbe tracée est au dessus de la droite descendante à 45°, cela révèle un problème: la production est en retard par rapport à la planification.
PROBLÈME: PRODUIT NON OPÉRATIONNEL
L'équipe a connecté un iBuddy au poste d'intégration continue. Dès que l'outil d'intégration continue détecte une modification dans le dépôt de code et lance un build, l'iBuddy agite les ailes et sa tête change plusieurs fois de couleur. Cette chorégraphie, répétée plusieurs fois par jour, permet de visualiser le flux continu des contributions dans le dépôt de code. Tant que le build est réussi, la tête de l'iBuddy reste verte. Sa tête devient rouge pour révéler un problème: le build est en échec et donc le produit n'est plus opérationnel!
PROBLÈME: STOCKS, GOULETS D'ÉTRANGEMENT ET REWORK
L'équipe pilote la production en utilisant des Kanbans. Cela lui permet de voir la production en cours. Les kanbans révèlent plusieurs problèmes: la discontinuité du flux avec l'apparition de stocks et de goulets d'étranglement et le rework avec les produits défectueux collectés dans le bac rouge.
PROBLÈME: FLUX DISCONTINU
L'équipe utilise un sémaphore d'intégration pour mener l'intégration continue du produit. Chaque fois qu'un développeur se synchronise et délivre ses modifications dans le dépôt de code, il place un unique marqueur (une peluche, alias Guizmo) sur son écran. Cela permet de voir le flux continu de production qui enrichit le produit. Cette pratique révèle également deux problèmes: un sémaphore qui ne circule pas dans l'équipe signale un flux discontinu et un sémaphore bloqué sur un poste révèle une intégration douloureuse.
PROBLÈME: NON QUALITÉ
Quotidiennement, l'équipe affiche la quantité de non-qualité automatiquement détectée dans le produit. Cela permet de visualiser l'évolution de la qualité de la production. Cela permet aussi de révéler lorsque le produit n'a plus la qualité attendue.
Ces quelques exemples de pratiques permettant de visualiser la production pour révéler les problèmes. Elles sont adaptées à la nature particulière de notre projet et de notre équipe: logiciel critique et grosse équipe auto-organisée. L'étape d'après est de réagir immédiatement lorsqu'un problème est révélé. Cela sera l'objet d'un billet à venir.
A bientôt!
VISUALISER LA PRODUCTION POUR RÉVÉLER LES PROBLÈMES
Prendre conscience d'un problème est la première étape de sa résolution. Voir un problème est une manière efficace d'en prendre conscience. L'afficher pour que tous le voient est une manière de s'engager dans sa résolution. Reste à organiser la production pour que les problèmes se voient.
C'est ici que les choses se compliquent pour le développement logiciel. En effet, il s'agit d'un métier dont la production ne se voit pas de manière évidente. C'est aussi ce qui rend le défi plus amusant en nous obligeant à devenir créatifs.
Voici quelques exemples de pratiques déployées par notre équipe pour visualiser la production pour révéler les problèmes.
PROBLÈME: RETARDS
L'équipe affiche ses burndown chart. Cela lui permet de voir une mesure de sa production. Si la courbe tracée est au dessus de la droite descendante à 45°, cela révèle un problème: la production est en retard par rapport à la planification.PROBLÈME: PRODUIT NON OPÉRATIONNEL
L'équipe a connecté un iBuddy au poste d'intégration continue. Dès que l'outil d'intégration continue détecte une modification dans le dépôt de code et lance un build, l'iBuddy agite les ailes et sa tête change plusieurs fois de couleur. Cette chorégraphie, répétée plusieurs fois par jour, permet de visualiser le flux continu des contributions dans le dépôt de code. Tant que le build est réussi, la tête de l'iBuddy reste verte. Sa tête devient rouge pour révéler un problème: le build est en échec et donc le produit n'est plus opérationnel!PROBLÈME: STOCKS, GOULETS D'ÉTRANGEMENT ET REWORK
L'équipe pilote la production en utilisant des Kanbans. Cela lui permet de voir la production en cours. Les kanbans révèlent plusieurs problèmes: la discontinuité du flux avec l'apparition de stocks et de goulets d'étranglement et le rework avec les produits défectueux collectés dans le bac rouge.PROBLÈME: FLUX DISCONTINU
L'équipe utilise un sémaphore d'intégration pour mener l'intégration continue du produit. Chaque fois qu'un développeur se synchronise et délivre ses modifications dans le dépôt de code, il place un unique marqueur (une peluche, alias Guizmo) sur son écran. Cela permet de voir le flux continu de production qui enrichit le produit. Cette pratique révèle également deux problèmes: un sémaphore qui ne circule pas dans l'équipe signale un flux discontinu et un sémaphore bloqué sur un poste révèle une intégration douloureuse.PROBLÈME: NON QUALITÉ
Quotidiennement, l'équipe affiche la quantité de non-qualité automatiquement détectée dans le produit. Cela permet de visualiser l'évolution de la qualité de la production. Cela permet aussi de révéler lorsque le produit n'a plus la qualité attendue.Ces quelques exemples de pratiques permettant de visualiser la production pour révéler les problèmes. Elles sont adaptées à la nature particulière de notre projet et de notre équipe: logiciel critique et grosse équipe auto-organisée. L'étape d'après est de réagir immédiatement lorsqu'un problème est révélé. Cela sera l'objet d'un billet à venir.
A bientôt!
Bonjour Emmanuel,
RépondreSupprimerD'abord un grand merci pour ton blog ;)
J'aurais bien aimé avoir des infos sur ces problèmes qu'il vous a fait voir..
Peut etre pour un prochain billet.
BTW, une coquille?
>Si la courbe tracée est en dessous ...
C'est plutot au dessus dans ce cas non?
David
Bonjour Emmanuel,
RépondreSupprimerSympa comme suite de ticket.
Je me répète mais, cela est vraiment gentil de partager tes expérimentations avec les autres.
Pour aider le lecteur que je suis, je m'interroge sur :
Qui est ton client ?
- Un industriel et un certificateur.
Que désire ton client ?
- En mode produit : que tu développes un logiciel critique à tel endroit ..., sans ...,
- En mode projet : que tu sois dans les temps, avec un niveau d'exigence sur ...
Qu'est ce qui est important pour lui ?
Quels sont les objectifs que vous avez définis avec lui, sans lui (indicateur de résultat et de processus)
L'idée vu que tu partages ton expérience et je t'en remercie serait d'avoir une meilleure vision de ton client, des ces exigences, ...
Sinon, comme tu le dis très bien, un des moyens de voir certain problème est de voir la production et pourquoi pas de s'aider d'un d'outil comme l'affichage visuel.
Cependant, selon le niveau de maturité des équipes, il faut faire attention au « chemin de la moindre résistance » d'ou le "go and see/genchi genbutsu" vers le terrain/gemba pour se rendre compte/analyser/.. et déclencher une démarche de résolution. (PDCA)
---
J'ai attaqué la journée plein d'enthousiasme et je l'ai terminé avec le moral dans les chaussettes.
---
Esprit kaizen, il a donc bien travaillé ce sensei :)
Amicalement,
Christophe
> David a dit:
RépondreSupprimer> "J'aurais bien aimé avoir des infos sur ces problèmes qu'il vous a fait voir.."
Par exemple:
[1] Certains de nos outils ne servaient plus à révéler les problèmes. Par exemple, les Kanbans étaient devenus des "task boards": ils ne servaient plus qu'à piloter la production en flux-tendu.
[2] L'équipe consacre de l'énergie à résoudre des problèmes dont la résolution n'a pas (ou peu) d'impact sur le client (final ou interne) alors qu'elle néglige certains vrais problèmes.
[3] La résolution des problèmes n'est pas (encore) une démarche systématique et structurée.
> Christophe a dit:
RépondreSupprimer> Qui est ton client ?
> - Un industriel et un certificateur.
Les 2, en effet.
> Que désire ton client ?
> - En mode produit : que tu développes un logiciel critique à tel endroit ..., sans ...,
> - En mode projet : que tu sois dans les temps, avec un niveau d'exigence sur ...
Les 2, en effet.
> Qu'est ce qui est important pour lui ?
Que le produit soit opérationnel et disponible au moment où il en aura besoin.
Que le produit soit fiable.
Que le produit ait l'autorisation d'être mis en production.
> Quels sont les objectifs que vous avez définis avec lui, sans lui (indicateur de résultat et de processus)
[1] A des dates convenues, le produit doit être conforme à des besoins exprimés (besoins opérationnels et de fiabilité).
[2] Le processus de développement doit être conforme aux exigences normatives. A une date convenue, le produit doit être autorisé à entrer en production.