Interacciones entre equipos ágiles en una empresa de software

Intentamos usar Kanban en nuestro proyecto de desarrollo. Nuestro equipo es uno de muchos otros equipos de desarrollo ágil en nuestra empresa. Los otros equipos pueden usar Scrum o Kanban o algo más (a veces nada, supongo).

Todos los equipos trabajan en un gran proyecto, pero este gran proyecto se divide en subproyectos y cada equipo trabaja en un subproyecto.

Hay bastante interacción entre los equipos:

  • un equipo puede pedirle a otro equipo que realice una revisión de código de su solicitud de extracción
  • un equipo puede venir a otro equipo para un consejo experto
  • un equipo puede solicitar a otro equipo que corrija un error crítico
  • etc.

Estas interacciones se dividen en dos grupos:

  • trabajo adicional (reducir la velocidad de nuestro equipo y aumentar el cambio de contexto)
  • bloqueadores (por ejemplo, esperar una revisión de código)

Así que estoy pensando en formas de gestionar eficazmente estas interacciones. Siempre tenemos muchas tareas de alta prioridad en nuestro propio proyecto, al igual que los otros equipos, por lo que parece que los gerentes deberían establecer primero una política común sobre estas interacciones.

¿Tiene alguna experiencia con este tipo de gestión de tareas entre equipos? ¿Cómo se puede abordar todo esto?

¿Todos estos equipos trabajan en el mismo producto o hay múltiples productos y algunos casos de interacción entre equipos son simplemente una cuestión de conocimiento y experiencia?
¿Por qué los equipos intentan rastrear el estado interno en busca de externalidades? O tienes un proyecto compartido o no lo tienes. En lugar de centrarse en soluciones específicas del marco, es posible que desee describir el problema político o comercial real que finalmente está tratando de resolver.
Todos los equipos trabajan en un gran proyecto, pero este gran proyecto se divide en subproyectos y cada equipo trabaja en un subproyecto.
¿Quién es responsable de la integración entre flujos de trabajo, características y entregables en su proyecto?

Respuestas (2)

Hay algunas cosas en las que pensar aquí.

En primer lugar, ¿cómo define sus prioridades? Si solo se definen a nivel de equipo individual, entonces es un desafío priorizar las solicitudes de otros equipos.

Idealmente, cuando se comparte el trabajo, debe haber una priorización clara y de alto nivel para que sea fácil para los equipos saber en qué deberían trabajar a continuación.

En segundo lugar, busque empoderar a los equipos para que se auto-organicen. Las ceremonias como el scrum de scrums pueden ser útiles para permitir que los equipos hablen regularmente entre sí.

Finalmente, valdría la pena pensar en formas de reducir las dependencias entre equipos. La capacitación adicional y el intercambio de conocimientos realmente pueden ayudar con esto. También ayuda si tiene una base de código consistente, de modo que sea relativamente fácil para los equipos trabajar en áreas del código en las que normalmente no operan. Esto, combinado con una buena cobertura de prueba de regresión automatizada, puede alentar a los equipos a corregir sus propias problemas en lugar de tener que depender de otros equipos para que lo hagan por ellos.

¿Una "base de código coherente" "animará a los equipos a solucionar sus propios problemas"? ¿En una configuración en la que los equipos se utilizan para pedir a otros equipos que "arreglen errores"? ¿Simplemente van a cambiar el código para ese caso de esquina donde no se ha especificado el comportamiento?
Eso definitivamente es un peligro y destaca por qué los equipos deben hablar juntos con frecuencia. Por ejemplo, espero que alguien que esté a punto de corregir un error en algún código en el que normalmente no trabaja vaya y charle primero con alguien que esté más familiarizado con él. Los capítulos y las comunidades de práctica también deberían ayudar.
He visto una lógica de negocios distribuida entre capas debido a una fea falla de diseño (suposición desafortunada e innecesaria), otros desarrolladores se encuentran con una parte y sienten que está mal, estudian el comportamiento asincrónico y de subprocesos múltiples y cambian el código a peor Y al final, la causa raíz aparece en un único elemento de deuda técnica, lo que desorienta un poco a la audiencia ocasional sobre su gravedad. Hablar no ayudó mucho aquí.
@loomwithacrew, la charla debería haber tenido el efecto de que los desarrolladores desprevenidos se dieran cuenta de la falla de diseño y que deberían proceder con extrema precaución.
@BartvanIngenSchenau realmente, "debería proceder con precaución", ¿no solucionar el problema de diseño?
@loomwithacrew, se podría preferir arreglar la falla de diseño, pero probablemente no sea económicamente factible o supongo que se habría considerado.

(Mi experiencia es con marcos ágiles que funcionan en sprints de tiempo limitado. Algunos de estos puntos no se aplicarán directamente si está siguiendo un marco de proceso continuo como kanban).

La mejor respuesta dependerá de por qué ocurren estas interacciones entre equipos.

Aquí hay algunas posibilidades que puedo imaginar:

  1. Problema con la composición del equipo

Un equipo ágil debe contener todas las habilidades necesarias para hacer su trabajo. ¿Es esto cierto de estos equipos? ¿Si no, porque no? ¿Se puede revisar la composición de los equipos?

  1. Problema con el proyecto -> descomposición del subproyecto

¿Se definieron los subproyectos con miras a convertirlos en proyectos ortogonales e independientes que puedan ser trabajados por equipos independientes con una coordinación mínima? ¿O se dividieron sobre alguna otra base que ahora está causando dificultades y, de ser así, se puede revisar?

  1. Problema con el exceso de compromiso del equipo

¿El equipo A está pidiendo trabajo al equipo B porque necesita ayuda para completar lo que está en su plato dentro del plazo definido? Si es así, los equipos deben mejorar en la planificación de la capacidad: habilidades como el refinamiento y la estimación de la cartera de pedidos.

En una nota ligeramente diferente, ningún equipo debe planificar el trabajo para llenar el 100% de su capacidad teórica. Apuntar a ~70 % deja espacio para que los desarrolladores realicen otro trabajo que surja durante el período de tiempo: ya sea complejidad recién descubierta, correcciones de errores sorpresivas, mantenimiento continuo, capacitación... o solicitudes de otros equipos para compartir su experiencia. .

  1. Preocupación por el silo

Esta es probablemente la mejor razón que se me ocurre, porque tiene una buena intención a pesar de que la implementación está causando problemas. Si el deseo de la organización es que los equipos participen en las revisiones de código de los demás, etc., con el fin de transferir conocimientos, quizás haya formas menos perjudiciales de hacerlo.

Un par de otros pensamientos:

  • Si el equipo A sabe de antemano que necesitará la ayuda del equipo B para completar con éxito un elemento de trabajo en un sprint futuro, es una buena idea informar al equipo B con suficiente anticipación para que pueda incluirse en las discusiones de planificación del equipo B. para su sprint relevante.

Como cuestión práctica, comencé a pegar etiquetas como "equipo_soporte" en cualquiera de esos boletos, para que podamos ver fácilmente y recordar que debemos hacer esa solicitud de soporte con suficiente anticipación para evitar sorprender al equipo b.

  • Parte de la razón para usar timeboxes relativamente cortos para los sprints es que sea más fácil pedirles a las personas que esperen hasta el final del sprint actual. "Respetar la caja de tiempo" normalmente significa "no dejar que las cosas se pasen", pero también significa "no meter más cosas en ella". Educar gradualmente a todos en la organización para que respeten el límite de tiempo en ambos sentidos requiere tiempo y la capacidad de, de hecho, diferir cualquier solicitud hasta el próximo sprint (lo que puede requerir el apoyo de la gerencia y/o de los demás líderes del equipo).

Estos dos puntos funcionan juntos: a medida que el equipo A aprende que el equipo B no va a responder a las solicitudes entrantes en medio de un sprint, el equipo A también aprende cuál es la cadencia del sprint (u otra planificación) del equipo B y aprende a preguntar por adelantado. .

Interacciones entre equipos ágiles en una empresa de software
RespuestasAquíPolítica de privacidad1y, 0v