Me sorprende que todos piensen que esto es algo tan bueno. Los autores de Peopleware (que, en mi opinión, sigue siendo uno de los pocos libros de gestión de proyectos de software que realmente vale la pena leer) no están de acuerdo. Casi toda la Parte IV del libro está dedicada a este mismo tema.
El equipo de software es una unidad funcional increíblemente importante. Los equipos necesitan gelatina para ser realmente productivos. A los miembros del equipo les lleva tiempo ( mucho tiempo) ganarse el respeto de los demás, aprender los hábitos, peculiaridades, fortalezas y debilidades de los demás.
Ciertamente, por experiencia personal, puedo decir que después de un año de trabajar con ciertas personas, he aprendido a reírme de ciertas cosas que solían irritarme, mis estimaciones como líder del equipo son mucho mejores, y no es demasiado difícil. distribuir el trabajo para hacer felices a todos. No fue así al principio.
Ahora puede decir: "Oh, pero no estamos dividiendo a todo el equipo, solo moviendo a algunas personas". Pero considere (a) cuán ciegamente improductivas serán sus reemplazos al principio, y (b) cuántas veces se encontrará a sí mismo u otros equipos diciendo, sin siquiera pensar: "Realmente me gustó X" o "Esto habría tenido ha sido más fácil con Y todavía cerca " , ofendiendo sutil e inconscientemente a los nuevos miembros y creando cismas dentro del equipo existente, incluso sembrando el descontento entre los miembros" viejos ".
La gente no hace esto a propósito , por supuesto, pero sucede casi siempre. La gente lo hace sin pensar. Y si se obligan a no hacerlo, terminan enfocándose aún más en el tema y se sienten frustrados por el silencio forzado. Los equipos e incluso los sub-equipos desarrollarán sinergias que se perderán cuando juegues con la estructura. Los autores de Peopleware lo llaman una forma de "teamicidio".
Dicho esto, aunque rotar a los miembros del equipo es una práctica horrible, rotar a los propios equipos está perfectamente bien. Aunque las compañías de software bien administradas deberían tener algún concepto de propiedad del producto, no es tan perjudicial para un equipo mover todo el equipo a un proyecto diferente, siempre y cuando el equipo realmente termine el proyecto anterior o al menos lo lleve a un nivel con el que están contentos.
Al tener períodos de equipo en lugar de períodos de desarrollador , obtienes los mismos beneficios que esperarías obtener con desarrolladores rotativos (documentación, "polinización cruzada", etc.) sin ninguno de los efectos secundarios desagradables en cada equipo como una unidad. Para aquellos que realmente no entienden la gestión, puede parecer menos productivo, pero pueden estar seguros de que la productividad perdida al dividir el equipo eclipsa totalmente la productividad perdida al trasladar ese equipo a un proyecto diferente.
PD: En su nota al pie de página, menciona que el líder tecnológico podría ser la única persona que no se rotará. Esto está prácticamente garantizado para arruinar a ambos equipos. El líder tecnológico es un líder, no un gerente, él o ella tiene que ganarse el respeto del equipo, y no solo se le otorga autoridad por los niveles más altos de administración. Poner a todo un equipo bajo la dirección de un nuevo líder con el que nunca han trabajado y que es muy probable que tenga ideas diferentes sobre cosas como arquitectura, usabilidad, organización del código, estimación ... bueno, va a ser estresante como el infierno. para el líder que intenta construir credibilidad y muy improductivo para los miembros del equipo que comienzan a perder cohesión en ausencia de su antiguo líder. A veces las empresas tienenhacer esto, es decir, si el líder renuncia o es promovido, pero hacerlo por elección parece una locura.