Cómo estructurar un equipo de desarrollo de software

Dado un equipo de desarrollo de software 15 veces más fuerte que trabaja en proyectos individuales y proyectos pequeños, medianos y grandes; ¿Cuál es la mejor manera de estructurar este equipo y cuál es la mejor metodología de desarrollo de software?

Antecedentes:
Anteriormente el departamento estaba compuesto por:

  • CTO
    • Equipo de desarrollo de soporte (1 líder, 2 desarrolladores de soporte)
    • 4x Desarrolladores

El departamento creció a 10x desarrolladores, por lo que se tomó la decisión de separarse en 2x equipos de desarrollo de 5x desarrolladores cada uno así:

  • CTO
    • Equipo 1 (1x líder/gerente, 4x desarrolladores)
    • Equipo 2 (1x líder/gerente, 4x desarrolladores)

El departamento utiliza Scrum, teniendo cada equipo su propio ciclo de sprint (sincronizado).

Ahora que el departamento es mucho más grande, es necesario realizar una nueva reestructuración. Se han identificado algunos problemas:

  • Los equipos fijos son problemáticos debido a los silos de conocimiento de los desarrolladores individuales
  • Promover a los desarrolladores a roles de líder/administrador/gerencia de línea resulta en la pérdida de recursos esenciales para desarrolladores

También tenemos una PMO que consta de 3 PM y 2 BA. Este equipo está separado del desarrollo (no está en una clasificación más alta o más baja, sino a un lado) y cae bajo el departamento de operaciones (COO).

Usar Scrum tiene sus problemas:

  • Ningún equipo de soporte dedicado significa que el mantenimiento debe recaer en un equipo Scrum. Esto no funciona tan bien. (Un equipo KanBan podría ser más apropiado para soporte).
  • La empresa asume el trabajo personalizado de muchos clientes, lo que da como resultado fechas de lanzamiento mixtas, que en su mayoría no se ajustan al plan de lanzamiento de sprint.

Mis pensamientos

  • Creo que una metodología más receptiva funcionaría mejor (pero no soy un experto aquí, soy un desarrollador / líder), y por proyecto en lugar de por equipo.
  • Creo que los equipos de desarrollo deben ser más fluidos, construir por proyecto en lugar de desarrolladores Nx fijos por equipo. La gestión de línea se convierte en un problema aquí. El liderazgo técnico y la gestión de línea se convierten en un problema aquí debido a la falta de recursos/tiempo adecuados.
flem, ¿Qué estás tratando de lograr? ¿Qué se supone que deben hacer los equipos? Hay muchas formas de estructurar equipos, con estructuras diferentes que son buenas para una cosa y otras estructuras buenas para alcanzar otras metas.
Los objetivos principales son: desarrollo rápido, alta calidad, para muchos proyectos. Algunos proyectos requieren solo un desarrollador, mientras que otros (menos) requieren 4 o 5. Un proyecto promedio requeriría de 2 a 3 desarrolladores.
Dado que es un desarrollador/líder, ¿tiene influencia en su CTO (es decir, esta pregunta tiene valor práctico)? ¿Alguien más puede hacerse cargo de la mayor parte de las tareas administrativas que se imponen a los líderes para que puedan concentrarse en sus equipos? La falta de mantenimiento dedicado en su departamento es una gran desventaja... También puede probar equipos más pequeños (da flexibilidad entre los equipos, mantiene la buena moral dentro de ellos).
@DeerHunter Sí, esta es una pregunta práctica. Las tareas administrativas son una gran parte del problema. Los líderes son desarrolladores de tiempo completo, scrum master y gerentes de línea. Esto termina con clientes potenciales que trabajan demasiadas horas.
Tal vez necesite un grupo de asistentes administrativos para eliminar las tareas rutinarias de los clientes potenciales... Contratar a un asistente es mucho más económico que sobrecargar a un líder capacitado para que lo lleve al asilo.
¿Cuáles son los objetivos comerciales? Claro, es bueno tener un equipo que hace las cosas más rápido, más barato y mejor. Pero, ¿por qué está el equipo allí? ¿Por qué ha crecido? La estructura debe optimizarse para que coincida con los objetivos de la organización.
@MarkPhillips Es realmente tan simple como: las ventas están vendiendo más, los desarrolladores tienen que construir más. Tenemos una plataforma central. Antes del crecimiento, la mayoría de los clientes recibirían 80-90% de plataforma, 10-20% a medida. Ha habido un cambio ahora y las cifras son más como 10-20% de plataforma a 80-90% a medida. Entonces, para un desarrollo más personalizado, necesitamos un equipo más grande. Pero un equipo grande no tiene sentido si no es efectivo.
Flem, ¿vendes desarrollo personalizado o un producto definido? ¿Por qué ha ocurrido el cambio en el desglose? Comprender este tipo de variables realmente puede marcar la diferencia para obtener la estructura correcta. Comparta otra información sobre la empresa y el contexto en el que opera el equipo de desarrollo.
Tenemos un equipo de ventas que se enfoca en vender un producto listo para usar y un equipo de ventas que vende el mismo producto listo para usar pero con características personalizadas. Las características a medida solían representar el 10-20 % (hace 2 años), pero ahora tienden a representar el 80-90 %. Hay varias razones para este cambio, una es que los clientes pagan más por algo único, otra es que poder construir lo que un cliente quiere significa que los clientes son más fáciles de encontrar; podemos ser más selectivos. El foco está ahora en el 80-90% del trabajo a medida. Normalmente tenemos de 3 a 8 proyectos en progreso en un momento dado. El backlog entrante es largo.

Respuestas (3)

¿Ha considerado un sistema de escuadrón? El siempre excelente Henrik Kniberg tiene un artículo que puede resultarle útil sobre cómo se utiliza este sistema en Spotify.

El principio básico es el siguiente:

  1. Los equipos verticales de múltiples habilidades (producto, desarrollo, diseño) trabajan en un solo producto o área de desarrollo de producto (por ejemplo, infraestructura, comentarios de los clientes); estos se conocen como escuadrones .
  2. Las agrupaciones horizontales basadas en habilidades (por ejemplo, desarrolladores de PHP, desarrolladores de front-end) atraviesan los escuadrones; estos se conocen como capítulos . Cada uno tiene un líder de capítulo que (generalmente) asume la responsabilidad de la gestión de línea para todos en su capítulo.
  3. Los grupos de interés especial (p. ej., gestión ágil de proyectos, pruebas) son transversales tanto en capítulos como en escuadrones: estos grupos se conocen como gremios y cada uno tiene un líder de gremio.

Existen algunas similitudes con un sistema de gestión matricial , que quizás también desee investigar.

Descargo de responsabilidad : no he usado el sistema de escuadrones, ¡solo creo que podría ser un buen enfoque para ti!

Gracias por el enlace. Esto es muy interesante. Tengo la intención de investigar más a fondo.

TL;RD

TANSTAAFL. Si desea escalar, debe agregar más equipos. Sin embargo, si agrega más equipos, debe administrar la complejidad adicional y la sobrecarga de comunicaciones que conlleva.

Los canales de comunicación directa escalan mal. La fórmula generalmente se expresa como N(N-1)/2 . Si no tiene un modelo de gestión de proyectos que aborde este hecho crítico de la complejidad de las comunicaciones, tendrá muchos problemas para escalar.

Opciones de equipo

Los equipos Scrum son equipos de proyecto . Si bien los buenos equipos a menudo permanecen juntos para trabajar en proyectos posteriores para evitar los gastos generales de formar y normalizar con un nuevo grupo, no es un requisito del marco. Sin embargo, si tiene varios proyectos simultáneos, tiene un problema de capacidad , independientemente de la metodología elegida.

Cambiar de tarea

El cambio de tareas siempre es un problema. Incluso si elige una metodología diferente a Scrum, aún debe empaquetar y priorizar el trabajo de tal manera que cada unidad de trabajo minimice el cambio cognitivo. Eso significa que pedirle a un solo desarrollador que trabaje en diferentes tareas para diferentes proyectos (incluso si las tareas están secuenciadas en lugar de pseudoparalelizadas) será menos óptimo que permitir que el desarrollador trabaje en el proyecto de un cliente a la vez.

Aceptar trabajo basado en la capacidad

El verdadero problema subyacente es que debe priorizar los proyectos de los clientes y escalar sus procesos a medida que necesita más capacidad para más proyectos de clientes. Su organización no debe aceptar más trabajo del que tiene capacidad disponible para acomodar. Dar prioridad a la cartera de proyectos será tarea de la alta gerencia, no de los equipos de proyecto, por lo que este problema no lo afectará directamente.

En cuanto a escalar, un Scrum de Scrums es generalmente la herramienta adecuada para el trabajo si es un taller de Scrum. Si usa una metodología diferente, entonces necesita usar las funciones de escalado de ese marco en su lugar. Sin embargo, el punto es que la comunicación entre equipos se vuelve más difícil y compleja a medida que agrega equipos; eso es casi axiomático.

La mejor manera que conozco para resolver el problema del intercambio de conocimientos en un entorno complejo de Scrum-of-Scrums es asegurar que los Product Owners agreguen capacitación entre equipos e historias educativas a su Product Backlog. Esto brinda oportunidades para la polinización cruzada entre equipos y reduce el efecto de silo, sin destruir la naturaleza de los equipos muy unidos.

Actualmente, la capacidad no es un problema y podemos escalar para admitir más proyectos. El principal problema (creo) es que no tenemos suficiente liderazgo para administrar la mayor capacidad. ¿Deberíamos tener un gerente de tiempo completo "jefe de desarrollo" para todas las funciones de gestión de línea/RRHH, que permita a los líderes del equipo concentrarse en los proyectos?
@flem: los líderes de equipo deben evitar el papeleo, pero no la gestión de sus equipos.
@DeerHunter ¿Es una buena idea que un líder de equipo sea un gerente de línea? Es decir, ¿Scrum master es un gerente de línea?
Por lo general, tratamos de evitar que las personas le informen a alguien de su equipo dónde estoy. Mantiene una distinción entre la gestión de línea y el liderazgo y creo que ayuda a mantener las retrospectivas más honestas.
@flem: parece que (administración de línea para líderes de equipo) está sujeto a otra pregunta.
@Cazador de ciervos. Pregunta derivada planteada aquí .

Vea cómo funciona Menlo Innovations en Ann Arbor, Michigan. Creo que son similares a lo que estás tratando de hacer.

  • Unas 70 personas haciendo trabajos a medida para muchos clientes.
  • Todos se emparejan y los pares cambian semanalmente: se comparte mucho conocimiento
  • Sprints de una semana
  • prácticas de programación extremas
  • Antropología de alta tecnología (algo que inventaron)
  • Los proyectos se forman a partir de pares, por lo que es fácil ampliarlos o reducirlos según sea necesario.

Vea el libro Joy, Inc., que se publicó recientemente. Fue escrito por Richard Sheridan, cofundador de Menlo Innovations, y describe Menlo Way. También hacen recorridos por su tienda y ofrecen clases para aquellos interesados ​​en aprender las técnicas. http://www.menloinnovations.com/

Nunca he trabajado allí, pero conozco a varias personas relacionadas con la empresa y soy fanático de cómo funcionan.

Cómo estructurar un equipo de desarrollo de software
RespuestasAquíPolítica de privacidad1y, 1v