Tout le monde connait le principe de la chaîne humaine, lors d’un déménagement vous l’avez certainement pratiqué, les participants se mettent en ligne d’un point A à un point B et se passent les cartons jusqu’à ce que le camion soit vide. Pour que la chaîne soit efficace, il faut que les participants soient mobiles. Quand ils ont les mains vides, les participants avancent vers le point A jusqu’à récupérer un carton, puis ils avancent vers le point B jusqu’à ce qu’il refourguent leur carton à un collègue. Ce principe est tout à fait applicable à un projet informatique et je le recommande même vivement.

La chaine humaine du projet informatique

Dans une équipe projet, ce principe est très intéressant à répliquer.

Prenons un projet informatique composé d’une partie front-end, une partie API et une partie back-end. Il n’est pas acceptable qu’une partie de l’équipe se tourne les pouces pendant que les autres triment pour tenir les délais de la prochaine release. Ici je caricature mais dans cet esprit, il est légitime de se demander si l’équipe la moins chargée ne peut pas aider celle la plus chargée plutôt que de se consacrer à des tâches de priorité moindre. En appliquant ce principe, une équipe peu chargée, par exemple le back-end, fera un pas vers l’équipe la plus proche techniquement, l’API, pour l’aider à réaliser ses taches les plus prioritaires.

Quoi de plus frustrant qu’une personne faisant partie d’une équipe projet qui explique qu’il n’a rien a faire car il attend que les autres aient livré leur partie et que ce n’est pas de sa responsabilité de les aider. Il est important que chaque membre de l’équipe se sente impliqué de la même façon dans le projet.

J’ai l’occasion sur plusieurs projets de pouvoir appliquer ce principe dès que l’équipe est suffisamment importante et volontaire. Chaque matin, l’équipe fait le point 10 minutes (le fameux standup meeting) sur les taches en cours et l’avancement de la prochaine release (sprint de 3 semaines). On revoit donc ensemble les taches qui sont importantes et ne sont pas affectées, les développeurs les moins chargés se proposent de s’en occuper que ce soit leur spécialité ou non. Jusqu’à présent, toutes les tâches ont été affectées sans aucune obligation et plusieurs développeurs ont aidé sur des parties de code qu’ils ne connaissaient pas et avec le sourire.

Quid de la qualité de code

Il faut dans une telle organisation faire attention à ne pas diluer la responsabilité. Qui est responsable de la qualité et de la maintenabilité du code si tout le monde peut intervenir sur n’importe quelle partie du projet en tant que newbe ne connaissant pas les standards appliqués à ce module, d’autant que les langages utilisés sont souvent différents selon les couches logicielles.

Il faut donc un responsable de cette couche logicielle avec si possible des développeurs spécialisés sur chaque partie permettant des échanges techniques entre développeurs. L’intégration de toute modification sur un module est donc de la responsabilité du manager du module. Celui-ci peut s’appuyer sur d’autres spécialistes du module et déléguer des revues de code, cependant, cela n’enlève rien de sa responsabilité sous peine de diluer la responsabilité et de finir avec un code tout pourri et une dette technique qui finira par coûter très cher.

Avantages

Appliquer le principe de la chaîne humaine a de nombreuses vertus.

1/ Augmentation de la productivité.

Les développeurs ne s’attendent plus, chacun est capable de faire avancer ces sujets sans être dépendant des autres. Les développeurs prennent des engagements de livraison d’une fonctionnalité et non d’un bout de code à intégrer avec d’autres bouts de code, l’intégration fait partie des prérogatives du développeur.

2/ Implication des membres de l’équipe.

Permettre à chacun de choisir avec ses collègues les taches qu’ils réaliseront est très motivant. Aussi réaliser des fonctionnalités de A à Z est beaucoup plus engageant que de modifier une fonction dont on ne connait pas la finalité pour le produit. Cela permet de prendre connaissance de l’ensemble de la chaîne et des implications des différentes couches logicielles entre elles

3/ Partage de connaissance

Développer sur différentes parties du code participe au partage connaissance sur toutes les parties du code. Un oeil neuf sur une partie du code peut-être très bénéfique, le “nouveau” développeur apporte toujours quelques chose à l’équipe qui l’accueil, ne serait-ce que de permettre au développeur expérimenté d’expliquer son code et lui faire réaliser que des patries sont à factoriser ou à ré-écrire pour réduire la dette technique avant qu’elle soient très cher à supprimer.

Aussi, si un ou deux développeurs sont trop isolés, cela permet de réduire le risque dû au faite que peu de personnes sont spécialistes d’une partie et vampirisent la connaissance d’un code complexe.

4/ Intérêt pour chaque développeur.

Enfin, chaque membre de l’équipe verra plus de technologie, de problématiques métier, cela participe à l’ouverture d’esprit et à la formation continue. Aussi, cela facilite la responsabilisation de chacun vis à vis des fonctionnalités à développer et non des fonctions logicielles isolées, cela permet une meilleur qualité de livraison.

Conclusion

Il y a vraiment beaucoup d’avantage à casser les frontières entre les équipes d’un même projet. il faut tout de même faire attention à garder la cohérence de l’équipe et à ce que les développeurs ne changent pas en permanence d’équipe et de technologie, ce qui pourrait avoir l’effet inverse d’une équipe un peu incompétente dans tous les domaines.