Chez Toyota, chaque employé sur la chaîne de montage a le pouvoir d’arrêter la chaîne de montage.  S’il trouve un problème, il n’a qu’à tirer sur une corde pour arrêter la production.  Imaginez, un simple employé a le pouvoir d’arrêter une chaîne de montage qui produit des millions de dollars à l’heure.  Et que fait l’employé qui a arrêté la production?  Il identifie le problème et le règle avec l’aide de ses co-équipiers.  Des fois, ils devront remonter la chaîne.  Par exemple, si un coffre à gants ne s’insère pas comme du monde, on va voir qui a fabriqué le coffre à gants.  Peut-être que ce sera le moule du coffre à gants qui est défectueux.  Ou peut-être l’outil utilisé pour fabriquer le moule.  Chez Toyota, on règle les problèmes en remontant à la source.  Chez Toyota, on a fait le calcul qu’un problème réglé une fois à la source est beaucoup moins couteux que tout les problèmes rencontrés en aval.

Comment implanter ce concept lean en développement logiciel?  À mon avis, on peut faire la même chose avec l’intégration continue.  À chaque fois que votre build est cassé (build break), vous vivez un arrêt de production.  Que faire?  Identifier la source du build break.  Qu’est-ce qui est à l’origine de votre build break?  Qui a provoqué le build break?  Aller voir cette personne et regarder avec elle ce qui s’est passé.  L’important, c’est de réparer votre build tout de suite.  Ne le reportez pas à plus tard.  S’il est cassé, cela indique un problème à quelque part.  Attardez-vous à la source du problème dès maintenant au lieu d’attendre que le problème survienne chez le client.

De plus, adopter une attitude positive face au build.  C’est normal de casser le build après tout.  Tout le monde va le faire puisque tout le monde change le code.  L’important, c’est que le build attrape vos bogues avant que le client le fasse.  Le but du « Stop the line », c’est d’impliquer tout les membres de l’équipe dans la qualité du logiciel.  Pourquoi une équipe de tests dans le département « Assurance-Qualité » devrait assurer la qualité du logiciel?  Le QA, c’est l’affaire de tous.  Entre vous et moi, c’est beaucoup moins couteux réparer un problème dans vos bureaux au lieu de supporter 15 clients qui ont tous découvert le problème en même temps.

Et vous, quand réparez-vous votre bogue lorsqu’un problème est trouvé?  À la source?  Attendez-vous que le produit soi chez le client pour réparer vos bogues?  Laissez-moi deviner, vous n’avez pas le temps de réparer vos bogues.  Est-ce que vous mettez vos bogues sur une liste?  Si oui, est-ce que vous consultez cette fameuse liste des fois?  Avant que le produit soit envoyé au client?  Combien de fois regardez-vous cette liste?  Une fois par itération?  Et qui regarde cette liste?  Tous les développeurs.  Quelques zélés dans l’équipe.