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

13

Recientemente me he unido a una empresa en la que trabajo 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 sobre la posibilidad de dividir el equipo en dos equipos, no tanto para acortar los enfrentamientos (que no son excesivos en este momento) sino para evitar que las personas se aburran por completo en las sesiones de planificación de sprint (que tampoco son demasiado largas).

El proyecto tiene dos capas muy distintas: alto desarrollo técnico de backend (como seriamente complejo), y diseño / construcción / integración de UI. Parece que cuando los muchachos del backend están hablando técnico, los de la UI se alejan, y viceversa. Parece ser la forma lógica de dividir el equipo aunque solo sea para que sea más eficiente en el tiempo, pero tengo una reserva masiva en la 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 de lo que está construyendo el resto del equipo.

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

    
pregunta Ani Møller 14.08.2013 - 05:18

6 respuestas

8

Es desafortunado que a los usuarios de UI no les importe el detalle 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 los miembros de los Requisitos comiencen a separarse de la zona y no se preocupen por lo que hacen los jugadores de UI y pidan su propio equipo?

Siempre he estado a favor de los cortes verticales para mis equipos. La interfaz de usuario debería escuchar lo que la gente técnica tiene que decir, ya que son las mismas personas que podrían ayudar a hacer su trabajo más fácil (Oh, ese widget va a hacer que hagas esto, ¿y si en su lugar usamos este widget?) / p>

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

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 realmente cuando todos están preocupados por el equipo, en lugar de su propia disciplina o intereses.

¡Salud!

    
respondido por el Abstract Class 16.08.2013 - 04:32
7

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 sigue siendo 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 separadas de scrum, 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 intersecan o si un equipo depende de otro. Pero nuevamente, no es necesario que todo el equipo esté presente, el líder del equipo puede coordinar la colaboración.

    
respondido por el superM 14.08.2013 - 09:34
5

Un aspecto clave de Scrum es auto-organizado .

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

Sus preocupaciones están bien fundamentadas, pero recuerde que como Scrum Master, su trabajo es entrenar y facilitar. Así que pregúntales cómo resolverán estos problemas. Ellos serán los dueños de las soluciones y harán que funcione.

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

    
respondido por el andy256 14.08.2013 - 13:14
4

Al dividir equipos, siempre trato de tener en cuenta el hecho de que un equipo necesita poder entregar valor al cliente. En su caso, sería tener tanto desarrolladores backend como frontend en el equipo.

    
respondido por el user99561 14.08.2013 - 10:27
3
  1. ¿Qué tan lejos está el extremo frontal del backend? Como era de esperar, la división es un buen consejo solo si la distancia es demasiado grande.

    • Si el backend habla sobre el esquema de la base de datos, no es 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 del disco, etc., esto es un poco demasiado lejos (donde el backend se centra en la simpatía mecánica y la optimización, mientras que el front-end se centra en la estética humana) .

  2. ¿Existe una interfaz de programación estable e inequívoca entre el front-end y el backend?

    • Por estable e inequívoco, significa que los usuarios de esa interfaz de programación (los desarrolladores front-end) no se atascarán con los cambios, y no necesitarán leer las paredes de texto para aprender a usar 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 se debe establecer 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 cortes verticales? Aquí hay alguna 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 inicio.

    • 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 un pago lento. A menos que una empresa ya esté establecida para el largo plazo y esté generando una ganancia decente, es mejor "tercerizar" el backend adhiriéndose a la tecnología ya 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 interruptor 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-ends estable
    • API estable
    • back-end de baja tasa de defectos
      • Razón: para evitar la frustración
      • Cómo: pruebas unitarias
      • No significa: rendimiento u optimización; solo tiene que ser funcionalmente correcto.
    • Integración continua
    • Transparencia en la comunicación, el progreso y la toma de decisiones
    • Aliente las discusiones informales entre los dos equipos
    • Aliente a los miembros del equipo (aquellos que no se separan) a asistir a las reuniones del otro equipo.
    • Organizar reuniones conjuntas ocasionales y retrospectivas conjuntas
    • Otras actividades de formación de equipos
respondido por el rwong 16.08.2013 - 08:03
0

Como otros, definitivamente sugeriría ir con cortes verticales. Estos a veces se conocen como "Equipos de características". Recomendaría leer los pros / contras en el sitio Scaled Agile Framework: enlace

Al principio, cuando se divide, su Propietario del producto y SDF Master pueden ser capaces de manejar el Registro de liberación para ambos equipos, así como los retrasos individuales para cada equipo de funciones. Sin embargo, a medida que crezca, es probable que tenga que implementar un registro de características del producto que luego se alimenta a varios equipos ágiles que liberan trabajos pendientes. Una vez que alcance el nivel, es probable que necesite un equipo separado que administre el registro de funciones y luego las lleve a los equipos individuales para su implementación. En esa estructura, puedes tener algo como esto:

  1. Equipo ágil 1: SM, PO, equipo multifuncional. Tiene un atraso propio del equipo para sus historias.
  2. Equipo ágil 2: SM, PO, equipo multifuncional. Tiene un atraso propio del equipo para sus historias.
  3. Equipo de administración de programas: Gerente de productos, gerentes de versiones, arquitectos empresariales. Tiene un programa de trabajo acumulado de epopeyas de mayor nivel y características que se organizarán, analizarán y luego se incluirán en los equipos.

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

    
respondido por el Jay S 17.08.2013 - 15:30