¿Cuál es la mejor manera de escalar y dividir un equipo ágil que crea una aplicación web?

Recientemente me uní a una empresa en la que estoy trabajando como scrum master en un proyecto de desarrollo ágil que crea una aplicación web.

El equipo está a punto de ser el tamaño máximo para un equipo ágil (esperando 9 la próxima semana). Hemos hablado de dividir potencialmente al equipo en dos equipos, no tanto para acortar las posiciones (que no son excesivas en este momento) sino para evitar que las personas se aburran por completo en las sesiones de planificación de sprint (que de nuevo no son excesivamente largas).

Hay dos capas muy distintas para el proyecto: desarrollo técnico de backend alto (como seriamente complejo) y diseño / construcción / integración de UI. Parece que cuando los chicos del backend están hablando técnico, los chicos de la interfaz de usuario se desconectan y viceversa. Parece ser la forma lógica de dividir al equipo aunque solo sea para ser más eficiente en el tiempo, pero tengo una reserva masiva en cuanto a que todo lo que realmente podría estar haciendo es reducir la colaboración y el intercambio de conocimientos. Los dos equipos simplemente no tendrán una buena idea sobre lo que el resto del equipo está construyendo.

¿Alguien tiene alguna experiencia en tratar con algo como esto?

Es lamentable que a los chicos de la interfaz de usuario no les importen los detalles del complejo trabajo de backend. Esto suena más como un tema de discusión para una retrospectiva. Dividir al equipo a lo largo de la disciplina sentaría un precedente peligroso, qué tan pronto sería antes de que la gente de Requisitos comience a dividirse y no se preocupe por lo que están haciendo los chicos de la IU y pedir su propio equipo.

Siempre he estado a favor de los cortes verticales para mis equipos. UI debería escuchar lo que la gente técnica tiene que decir, ya que son las mismas personas que podrían ayudar a facilitar su trabajo (Oh, ese widget va a hacer que hagas esto, y si usáramos este widget en su lugar).

Personalmente, me centraría en el tema de la separación de los tipos de la interfaz de usuario primero, luego, una vez que se haya resuelto esa disfunción, discutiría cómo dividir mejor los equipos. No estoy tratando de difamar a los chicos de la interfaz de usuario, tal vez la gente técnica también podría hacer más para hacer que sus discusiones sean más fáciles de relacionar para los chicos de la interfaz de usuario.

Como han dicho otros, se debe permitir que el equipo se autoorganice para determinar la nueva estructura. Las experiencias pasadas me han enseñado que la autoorganización solo puede funcionar cuando todos están preocupados por el equipo, en lugar de su propia disciplina o intereses.

¡Salud!

De hecho, es una buena idea dividir las partes independientes del equipo en nuevos equipos. En un proyecto más grande, es casi imposible que los desarrolladores estén familiarizados con todo el proyecto, por lo que la división aún está presente formal o informal.

Cada uno de los nuevos equipos debe tener un líder de equipo / gerente técnico, que tenga un conocimiento sólido sobre el alcance de su equipo y que también esté familiarizado con el trabajo de otros equipos.

Después de eso, cada equipo puede tener reuniones scrum separadas, y los líderes de los otros equipos pueden estar presentes. De esta manera, reducirá el número de personas "aburridas", pero los equipos sabrán en qué están trabajando los demás y podrán colaborar con éxito.

La colaboración se vuelve más importante si los ámbitos de los equipos se cruzan o si un equipo depende del otro. Pero, de nuevo, no es necesario que todo el equipo esté presente: el líder del equipo puede coordinar la colaboración.

Un aspecto clave de Scrum es la autoorganización .

Le sugiero que discuta la pregunta con el equipo y deje que la resuelvan.

Todas sus preocupaciones están bien fundadas, pero recuerde que, como Scrum Master, su trabajo es entrenar y facilitar. Pregúnteles cómo resolverán estos problemas. Serán los dueños de las soluciones y harán que funcione.

Yo agregaría: en general, los equipos interfuncionales son el camino a seguir.

Al dividir los equipos, siempre trato de tener en cuenta el hecho de que un equipo debe ser capaz de ofrecer valor al cliente. En su caso, sería tener desarrolladores de backend y frontend en el equipo.

1. ¿Qué tan lejos está el front-end del backend? Como era de esperar, dividir es un buen consejo solo si la distancia es demasiado grande.

   • Si el backend habla sobre el esquema de la base de datos, esto no está demasiado lejos . Tanto el front-end como el backend deben escuchar las discusiones sobre el esquema de la base de datos.

   • Si el backend habla de fragmentación, cachés de memoria, latencia de disco, etc., entonces esto está demasiado lejos (donde el backend se enfoca en la simpatía mecánica y la optimización, mientras que el front-end se enfoca en la estética humana).

2. ¿Existe una interfaz de programación estable y sin ambigüedades entre el front-end y el back-end?

   • Por estable y sin ambigüedades, significa que los usuarios de esa interfaz de programación (los desarrolladores front-end) no se verán empantanados con los cambios, y no necesitarán leer paredes de texto para aprender a usarlo correctamente.

   • El equipo de backend debe proporcionar una buena API y una implementación simulada desde el principio, y solo después de eso comenzará el desarrollo real.

   • Esto no quiere decir que la API deba establecerse en piedra. Esto es solo una mitigación de la consecuencia de dividir un equipo en dos.

3. ¿Por qué tantos artículos ágiles recomiendan tener rodajas verticales? Aquí hay información de fondo:

   • La mayoría de los artículos ágiles en realidad recomiendan evitar el trabajo de back-end, desde una perspectiva de costos.

   • Además, no olvide que una fracción de los artículos ágiles tenía el sesgo implícito hacia las empresas de nueva creación.

   • Y no olvide la dura realidad del marketing: la mayoría de los clientes solo pagan por los front-end.

   • El trabajo de back-end tiende a ser costoso y tuvo una rentabilidad lenta. A menos que una empresa ya esté establecida a largo plazo y esté generando una ganancia decente, es mejor "externalizar" el backend al apegarse a la tecnología comercial y las bibliotecas de código abierto.

   • La mayoría de los artículos ágiles también recomiendan implementar el front-end para que pueda sobrevivir a un cambio de back-end. Este consejo va de la mano con el anterior: si la tecnología estándar no cumple con todos los requisitos, pruebe con otro.

4. Prácticas que pueden mitigar las malas consecuencias de dividir un equipo

   • Back-end estable
   • API estable
   • Baja tasa de defectos back-end
     • Motivo: para evitar la frustración.
     • Cómo: pruebas unitarias
     • No significa: rendimiento u optimización; solo necesita ser funcionalmente correcto.
   • Integración continua
   • Transparencia en la comunicación, el progreso y la toma de decisiones.
   • Fomentar debates informales entre los dos equipos.
   • Anime a los miembros del equipo (aquellos que no se alejan) a asistir a las reuniones del otro equipo.
   • Establecer reuniones conjuntas ocasionales y retrospectivas conjuntas.
   • Otras actividades de trabajo en equipo.

Como otros, definitivamente sugeriría ir con cortes verticales. A veces se les conoce como "Equipos destacados". Recomendaría leer sobre los pros / contras en el sitio Scaled Agile Framework: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

Al principio, cuando se divide, el propietario del producto y el maestro SDF pueden manejar el Backlog de lanzamiento para ambos equipos, así como los backlogs individuales para cada equipo de características. Sin embargo, a medida que crezca, es probable que necesite implementar una acumulación de características del producto que luego se alimenta a varios equipos ágiles. Una vez que escale a ese nivel, es probable que necesite un equipo separado que administre la acumulación de funciones y luego las transfiera a los equipos individuales para su implementación. En esa estructura, puede tener algo como esto:

1. Equipo ágil 1: SM, PO, equipo multifuncional. Tiene una cartera propia de equipo para sus historias.
2. Equipo ágil 2: SM, PO, equipo multifuncional. Tiene una cartera propia de equipo para sus historias.
3. Equipo de gestión del programa: Gerente de producto, Gerentes de lanzamiento, Arquitectos empresariales. Tiene una cartera de programas propia de épicas y características de nivel superior que se organizarán, analizarán y luego se transmitirán a los equipos.

El sitio web de SAFe tiene muchas cosas interesantes para organizar equipos más grandes, y algunas pueden ser útiles para usted a medida que avanza a una escala más grande de equipos de equipos.