Tous les bateaux tous les chapeaux

J'ai assisté la semaine dernière, lors du XP Day, à un atelier sur la théorie des contraintes.

L'atelier Mon processus s'étrangle était animé par Pascal van Cauwenberghe.

Ca commence par une simulation avec 7 volontaires qui vont construire des bateaux et des chapeaux en papier. Chacun joue une rôle particulier : client, analyste, concepteur, plieur, testeur... L'objectif est d'identifier le goulet d'étranglement du processus. La présentation est basée sur la théorie des contraintes.

Le goulet a été facile à identifier et nous avons essayé les techniques pour exploiter la contrainte.

Quand on est passé à un vrai problème de développement de logiciel soumis par un participant, il a été beaucoup plus difficile de trouver le goulet d'étranglement. Pas très étonnant, le processus suivi était déjà partiellement agile.

Pascal parle de l'atelier dans son blog et montre les photos des groupes. Il est belge et le français n'est pas sa langue natale, alors on excusera son utilisation de goulot au lieu de goulet[1].

Dans les entreprises que je visite, celles qui ne sont pas encore agiles et m'appellent pour le devenir, des goulets assez évidents se situent au niveau des documents de spécification. L'équipe de développement attend la spec pour travailler. L'analyste qui rédige cette spec constitue le goulet d'étranglement. C'est une tendance dans les processus basés sur des documents et avec des personnes qui jouent des rôles à périmètre strict : ceux qui produisent les documents ne vont pas à la même vitesse que ceux qui les attendent.

Notes

[1] je dis ça d'autant plus que je le sais depuis peu

Commentaires

1. Le vendredi 18 mai 2007, 21:03 par Pascal Van Cauwenberghe

Merci pour le billet sur la session.

J'avais recherché goulet vs goulot auparavant. J'ai retrouvé les deux termes "goulet d'étranglement" et "goulot d'étranglement" dans le dictionnaire. Cependant, le mot goulot qui réfère à la bouteille, me semble plus proche du mot anglais "Bottleneck".

En fait j'ai toujours dit goulot jusqu'à une présentation récente où un participant m'a dit avec assurance qu'il fallait dire goulet.
Il y a toujours un goulet/goulot, même dans les équipes agiles. Cependant, il sera beaucoup moins clair parce que toute l'équipe sait faire (presque) toutes les taches.

Je regarde souvent la situation d'un peu plus haut, ou l'équipe de developpement (agile) est vue comme un ensemble dans le processus complet. Au debut d'une transformation agile, l'équipe de developpement est le goulet. Après quelques iterations le client devient le goulet. Oui c'est ce que je constate aussi dans l'application de Scrum, notamment lorsque le Product Owner n'est pas à plein temps.
2. Le lundi 28 mai 2007, 21:01 par bbing

Vous indiquez que vous avez visiter, les goulot (ou goulet) étaient dans la rédaction des spécifications. Cependant, si on utilise des lot de travail important, il est plus difficile d'identifier les goulots. La taille des lots cache les véritable goulots. En réduisant la taille des lots (en réduisant la taille des itérations), on augmente l'efficacité du système et surtout, on fait clairement ressortir les véritables contraintes du système. Un gros lot (sans jeu de mots), donne l'illusion d'un manque de travail en aval et en amont du lot, donnant l'impression que le goulot se déplace...

Quand on réduit la taille des lots de travail (réduire la taille des itérations), un goulot peut facilement être identifié: une pile de travail à faire et une attente des intervenants suivants.