Mi empresa adoptó Scrum hace dos años y creo que hemos tenido bastante éxito al usarlo. Actualmente me enfrento a la tarea de tratar de reestructurar parte de nuestra organización de desarrollo y quería obtener alguna información.
Actualmente contamos con 3 equipos de productos que están desarrollando aplicaciones orientadas al cliente basadas en la web. También tenemos un equipo de API que desarrolla una API interna que utilizan los demás equipos. En los próximos 2 o 3 meses, el trabajo atrasado del equipo de API se reducirá cada vez más, ya que el equipo ha entregado la mayoría de las funciones requeridas por los equipos de productos. El trabajo de los equipos de productos continuará más allá de ese punto.
Alguien tendrá que continuar y dar soporte a la API interna. Este trabajo incluiría:
Estamos considerando algunas opciones de cómo reestructurar los equipos para apoyar mejor esto:
Me encantaría escuchar cualquier otra sugerencia que nos falte, y también obtener información basada en la experiencia que alguien podría haber tenido al usar cualquiera de los métodos anteriores (bueno o malo). Mi objetivo es crear una estructura que reduzca las dependencias (y los bloqueos) entre equipos, al mismo tiempo que proporciona cierta supervisión para la API.
Cualquier enlace a lectura adicional que deba hacer sobre este tema también es muy apreciado.
Gracias
No cambiaría el equipo de API en absoluto. Una vez que tenga un grupo de personas que se hayan vuelto efectivos trabajando juntos, generalmente es mejor dejarlos juntos.
En su lugar, considere comenzar a agregar poco a poco trabajo que no sea de API a su cartera de pedidos, comenzando con una combinación baja y aumentando constantemente hasta que se conviertan en un equipo de producto en pleno funcionamiento que también son expertos en API. Esto permite que esa capacidad permanezca completamente ensamblada al mismo tiempo que se usa el equipo en otras capacidades. Puede que le resulte útil para la formación cruzada si alguien quiere "intercambiar puntos" del equipo de API a un equipo de producto, pero esto debería ser opcional y verdaderamente un comportamiento voluntario en ambos lados.
Probablemente elegiría la solución 3, la razón de esto es que necesita establecer una propiedad clara y definida del producto. Esto asegurará que se realice el trabajo necesario (como lo señaló Trevor) y minimizará los escenarios de conflicto innecesarios.
La segunda solución propuesta podría funcionar, sin embargo, depende en gran medida de los equipos involucrados, su motivación y carga de trabajo.
Un aspecto que vale la pena considerar al reestructurar sus grupos de desarrollo es cómo afectará a los miembros de su equipo desde un punto de vista psicológico. Reducir un equipo que está acostumbrado a ser la columna vertebral de los otros equipos puede llevar a una disminución de la motivación. Las personas que se quedan atrás en el grupo central pueden verlo como si usted pensara que no son tan productivos o tan buenos como sus compañeros de trabajo que se pusieron a trabajar en los equipos de nuevos productos.
Recomendaría leer el modelo de dinámica de grupo FIRO y cómo un cambio afectará a los miembros de su equipo.
Si bien es cierto que este no es mi ámbito de especialización, parece que casi has tomado la decisión, ya que las opciones 1 y 3 son básicamente las mismas. Desde una perspectiva externa, dado que hay 3 equipos independientes que dependen de la API, parece que la mejor ruta es dejar un equipo dedicado para trabajar en eso. Esto asegura que cuando se realicen cambios, también se tengan en cuenta los requisitos y preocupaciones de los otros dos equipos.
Absolutamente deberías mantener unido a este equipo; es probable que hayan estado juntos durante algún tiempo y tengan una velocidad establecida. Distribuirlos a los otros equipos seguramente interrumpirá la velocidad existente y posiblemente hará que esos equipos vuelvan al modo de formación. Si el trabajo de la API se está agotando, considere el trabajo de otras características para que fluya a su cartera de pedidos, además del mantenimiento de la API, pero recomendaría mantenerlos juntos, si es posible.
Más allá de eso, corresponde a más y más organizaciones de productos comprender verdaderamente el valor de su API. Trate su API como un producto y asegúrese de que se investiguen todos los esfuerzos para comercializarlo como tal.
Al considerar cambios organizacionales en una organización de software, siempre considere la Ley de Conway: http://swreflections.blogspot.com/2012/10/should-you-care-about-conways-law.html
Sea consciente de los posibles efectos en su API, con el tiempo, si disuelve a esas personas y cambia esencialmente su enfoque. Ahora tienen incentivos para asegurarse de que sus funciones funcionen, pero es muy posible que pierdan de vista el valor de los estándares y la disciplina que construyeron juntos, con el tiempo, como equipo, trabajando en la API con propiedad y orgullo.
andres claro