¿Debería un equipo Scrum estar compuesto por ingenieros de diferentes bases de código? ¿O eso es irrelevante?

En primer lugar, el sentido común. Quiero decir que puede obligar a los desarrolladores de C que ven Java por primera vez en sus vidas a codificar Java, al igual que puede hacer que yo escriba su código C. ¿Tiene sentido? Depende de un objetivo. Si el objetivo es enseñarles nuevas tecnologías, perfectamente podría ser un caso. Si el objetivo es hacer el trabajo, no tanto.

Además, la idea detrás del equipo multifuncional no es hacer que los desarrolladores de diferentes roles se intercambien entre sí, sino reunir diferentes roles de proyecto, por ejemplo, desarrolladores, ingenieros de calidad, gerentes/propietarios de productos, gerentes de lanzamiento, etc. en un equipo.

En este caso, mi pregunta sería: ¿qué se gana realmente a largo plazo al tener desarrolladores de diferentes mundos trabajando en un solo equipo? ¿Quieres que cambien a una sola tecnología? ¿O tal vez hablamos de un equipo de 3 donde intercambiar personas cuando alguien se toma un día libre es complicado? ¿O funciona bien como está? Si esto último es cierto, no intente forzar el cambio.

La otra forma es si es una buena idea tenerlos en un equipo. En realidad, diría que es más probable que lo sea a que no lo sea. No es porque quieras que tomen tareas entre ellos de manera aleatoria. Lo que obtiene al reunirlos en un equipo es que realmente mejora la comunicación entre ellos, lo cual es importante especialmente cuando trabajan en una sola pila de software.

Nota: no tiene por qué significar automáticamente que pululan sobre sus tareas o programa de emparejamiento. Todavía pueden ser un equipo. En realidad, una definición de un equipo no es "pueden enjambre" o algo así. La especialización no es mala. Si tiene sentido, permita que las personas se concentren en las tareas que dominan. Todavía puedes llamar para organizarlos en un equipo.

Tenemos una situación muy similar, donde hay 4 proyectos que son todos independientes pero necesitan integrarse sin problemas al final de los proyectos. ¡Y es un poco una pesadilla manejarlo! :-)

La clave aquí es mantener los proyectos/productos separados y preocuparse por las historias de integración por separado. Si la mayoría de sus historias son específicas del producto, parece que hay poco beneficio al combinar a los desarrolladores en un solo 'equipo'. Manténgalos separados y enfocados en sus productos.

Lo siguiente es cómo lidiar con las historias de dependencia entre productos... esto es más desafiante. Lo que hacemos es, para cada historia de productos cruzados, agregar la historia a un proyecto de 'propietario'. Para nosotros, este es el que tiene la mayor inversión en la función, o lógicamente posee la función, no necesariamente el que tiene más trabajo por hacer. Por ejemplo, si la historia es integrar la funcionalidad X del producto A en el producto B para que el cliente del producto B pueda lograr algo, entonces el producto B sería el propietario de la historia porque necesita demostrar esa característica en su producto, aunque la mayor parte de la integración el trabajo podría ser con el producto A. ¿Tiene eso sentido? Una vez que la historia está en un proyecto, debemos rastrearla en otros proyectos para que no se olvide. Para hacer eso, agregamos historias técnicas en los otros proyectos para asegurarnos de que no se pierda.

Para realizar un seguimiento de esto, tenemos una reunión semanal de los líderes del proyecto (similar a un Scrum de Scrums) para discutir el progreso y los impedimentos.

Esto parece funcionar bastante bien.

"Sin embargo, los ingenieros no pueden cruzar bases de código. Sería demasiado, cada base de código tiene su propia arquitectura y propósito".

Cuestionaría la noción de que esto significa que los ingenieros no pueden trabajar como un enjambre o en equipo. He trabajado con equipos de desarrolladores que tienen habilidades muy aisladas, cada uno con conocimiento de un sistema en particular escrito en un idioma en particular, y que todavía trabajan para lograr un solo propósito de manera muy efectiva.

En su mayoría, hacen esto determinando qué necesita el servicio descendente del ascendente; colaborar en las interfaces (interfaz de servicio, aplicación o biblioteca), cambiar la información proporcionada o la información procesada y hablar entre ellos .

Vi que el equipo se había unido cuando uno mostró un trabajo a las partes interesadas y dijo:

"La semana pasada, vio el trabajo de Y en esta aplicación. También le mostré cómo mi servicio guardaría su información. Esta semana me gustaría mostrarle cómo funcionan juntos".

No son las tecnologías o la comprensión de ellas lo que hace un equipo. Es el deseo de asegurar que el trabajo de cada persona contribuya al trabajo de los demás, construyendo un todo mayor.

Sin embargo, esto funcionó porque tenían un problema específico que resolver. No se puede crear un equipo juntando personas con diferentes capacidades y experiencia; en cambio, reúna un equipo que tenga las habilidades adecuadas para el problema que están tratando de resolver y permítales aprender o pedir ayuda si la necesitan.

Si lo haces bien, no es cuestión de ponerlos en el mismo equipo. Son el mismo equipo, en cuanto se lo permites .

Puede haber beneficios sustanciales al tener miembros de todo el equipo trabajando como un equipo. Si puede hacer que trabajen de manera efectiva como equipo, las interfaces entre los niveles de la pila funcionarán mejor.

Algunos proyectos tienen una arquitectura simple y tener un equipo multifuncional puede ser más real. Tendrás y deberías tener personas en el equipo que sean el tipo (o la chica) a quien acudir para preguntas particulares. Tener una copia de seguridad para ellos es bueno, dos o más es el paraíso.

En un proyecto como el suyo no obtendrá tanta funcionalidad cruzada como otros. A lo que debe apuntar es a que los miembros del equipo en ambos lados de las interfaces entre las capas entiendan las interfaces. Para los dos proyectos C, los miembros deben entender el código de cada lado de la interfaz. Asimismo, para la interfaz entre las bases de código C y Java. C y Java son lo suficientemente similares como para que los ingenieros de ambos lados puedan seguir el código.

PROS:

• El equipo tendrá una mejor comprensión de la pila.
• Las capas de pila deberían funcionar mejor juntas.
• Las interfaces entre capas pueden ser más simples.
• Las historias cruzadas no requerirán coordinación adicional.
• La calidad general del producto debería ser mejor.
• Los ingenieros inactivos de una pila pueden ayudar a los ingenieros de otras pilas.
• Las buenas prácticas de desarrollo se pueden compartir entre las pilas.

CONTRAS:

• Los miembros del equipo Scrum dedicarán tiempo a problemas que son (o parecen) irrelevantes para su pila.
• La funcionalidad puede filtrarse en la pila incorrecta.
• Los problemas de seguridad pueden dejarse de lado debido a la confianza entre los equipos de pila.