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!
