Manejo de dependencias de múltiples equipos

La dependencia entre equipos es un problema conocido en proyectos a gran escala. Estamos ejecutando un proyecto con cuatro equipos que comparten la misma plataforma, y ​​la solución se reduce a comunicarse... mucho.

Acciones específicas a tener en cuenta sobre cómo gestionar estas dependencias:

• Evite la dependencia cruzada tanto como sea posible; es obvio, pero a veces se necesita a alguien con un par de ojos nuevos para revisar la forma en que se construye la plataforma para proponer un poco de desacoplamiento
• cuando el desacoplamiento no sea posible, intente tener interfaces claras entre aplicaciones (tecnologías, como parece en sus casos); De esta manera, una implementación será válida para todas las aplicaciones siempre que se adhieran a esta interfaz común
• Durante el plan de sprint, evalúe qué tareas dependen de más de una historia de usuario ; una historia que depende de esta tarea es priorizar, asegúrese de que las otras historias lo conozcan (si usa un software para rastrear historias y tareas, una forma simple es usar enlaces entre ellas)
• Una vez que una tarea que afectará a más de una historia se convierte en prioridad en el backlog, asegúrese de que se considere el aspecto más amplio de la solución propuesta , para evitar situaciones en las que la tarea entregada solo se ajuste a una historia pero no a todas.
• Una vez que se complete la tarea, asegúrese de que los otros equipos estén al tanto . Ejecutar un scrum de scrums es una forma de hacer esto, pero hay muchos... todo dependerá de la estructura de su equipo. Usamos, por ejemplo, un tablero de Confluence que muestra los últimos cambios 'centrales' creados

¡Todo lo mejor!

Scrum of Scrums (SoS) es un enfoque de escalado ligero

A diferencia de algunos de los otros enfoques de escalado, en Scrum of Scrums no necesita recursos dedicados para la coordinación.

Sitios de Mike Cohn que siguen experiencias usando Scrum of Scrums :

• De esta forma, hemos trabajado en proyectos con más de 500 personas y hemos asesorado en proyectos con más de 1.000.
• cada equipo identifica a una persona que asiste a la reunión Scrum de Scrums para coordinar el trabajo de múltiples equipos Scrum
• En muchas organizaciones, tener una reunión de Scrum de Scrums dos o tres veces por semana es suficiente.

He usado Scrum of Scrums para coordinar entre 4 equipos. En nuestro caso, nos reuníamos dos veces por semana y teníamos más de una persona (Arquitecto, Product Owner, Scrum Master) representando a cada equipo. Algunas de estas personas manejaron múltiples proyectos.

La agenda de nuestra reunión de SoS generalmente constaba de dos elementos principales:

• Dependencias entre equipos: donde un equipo está construyendo, digamos un componente, que será utilizado por otro equipo.
• Conflicto de recursos: Teníamos algunos recursos compartidos. Negociamos las prioridades y qué % de tiempo del recurso compartido estará disponible para cada equipo.