Je suis surpris que tout le monde pense que c'est une si bonne chose. Les auteurs de Peopleware (qui, IMO, est encore l’un des rares ouvrages précieux sur la gestion de projets logiciels qui méritent d’être lus) méritent vraiment l’ opposition . Presque toute la partie IV du livre est consacrée à cette question.
L' équipe logicielle est une unité fonctionnelle extrêmement importante. Les équipes ont besoin de jell pour devenir vraiment productives. Il faut du temps ( beaucoup de temps) pour que les membres de l'équipe gagnent le respect de chacun, apprennent les habitudes et les bizarreries de chacun, ainsi que leurs forces et leurs faiblesses.
Personnellement, par expérience personnelle, je peux dire qu’après une année de travail avec certaines personnes, j’ai appris à rire de certaines choses qui me raillaient jadis, mes estimations en tant que chef d’équipe sont bien meilleures, et il n’est pas trop difficile de Faites distribuer le travail de manière à rendre tout le monde heureux. Ce n'était pas comme ça au début.
Maintenant, vous pourriez dire: "Oh, mais nous ne séparons pas toute l'équipe, nous ne faisons que déplacer quelques personnes." Mais considérez (a) à quel point leurs remplaçants seront aveuglément improductifs au début, et (b) combien de fois vous vous retrouverez, vous ou une autre équipe, à dire, sans même penser, "J'ai vraiment aimé X" ou "Cela aurait toujours plus facile avec Y " , offensant subtilement et inconsciemment les nouveaux membres et créant des schismes au sein de l’équipe existante, semant même le mécontentement des" anciens "membres.
Les gens ne le font pas exprès , bien sûr, mais cela se produit presque à chaque fois. Les gens le font sans réfléchir. Et s’ils s’y obligent, ils finissent par se concentrer davantage sur la question et sont frustrés par le silence forcé. Les équipes et même les sous-équipes vont développer des synergies qui se perdent lorsque vous vissez la structure. Les auteurs de Peopleware appellent cela une forme de "teamicide".
Cela étant dit, même si la rotation des membres de l'équipe est une pratique horrible, la rotation des équipes elles - mêmes est parfaitement satisfaisante. Bien que les sociétés de logiciels bien gérées devraient avoir une certaine notion de propriété du produit, il n’est pas aussi dérangeant pour une équipe de la transférer dans un projet différent, à condition que l’équipe ait réellement la possibilité de terminer l’ancien projet ou du moins de l’apporter. un niveau dont ils sont contents.
En ayant des relais d' équipe au lieu de relais de développeur , vous obtenez les mêmes avantages que ceux attendus des développeurs en rotation (documentation, "pollinisation croisée", etc.) sans les effets secondaires désagréables sur chaque équipe. Pour ceux qui ne comprennent pas vraiment la gestion, cela peut sembler moins productif, mais soyez assuré que la perte de productivité résultant de la scission de l'équipe est totalement inférieure à la perte de productivité résultant du déplacement de cette équipe vers un projet différent.
PS Dans votre note de bas de page, vous indiquez que le responsable technique peut être la seule personne à ne pas faire l'objet d'une rotation. C'est à peu près garanti de gâcher les deux équipes. Le responsable technique est un leader et non un manager. Il doit gagner le respect de l'équipe et ne doit pas simplement être autorisé par des niveaux de gestion supérieurs. Confier toute une équipe à la direction d'un nouveau responsable avec lequel ils n'ont jamais travaillé et qui risque fort d'avoir des idées différentes sur l'architecture, la convivialité, l'organisation du code, l'estimation, etc. pour le leader essayant de construire une crédibilité et très improductif pour les membres de l'équipe qui commencent à perdre de la cohésion en l'absence de leur ancien leader. Parfois, les entreprises ontfaire cela, c’est-à-dire si le prospect quitte ou obtient une promotion, mais le faire par choix semble insensé.