¿Cuál es la mejor manera de dividir el trabajo entre los desarrolladores?

Mi equipo y yo estamos reconstruyendo un sitio que desarrollamos hace unos diez años, y queremos hacerlo en Agile.

Entonces, después de pasar mucho tiempo leyendo (probablemente no lo suficiente), tengo problemas con la pregunta de cómo dividir el trabajo entre los desarrolladores.

Seré más específico y diré que el sitio está dividido en módulos separados que no tienen mucha integración entre sí.

¿Cuál es la forma mejor / más aceptada de dividir el trabajo entre los desarrolladores?

• Dar a cada persona un módulo diferente para trabajar.
• Asigne a todos los desarrolladores al mismo módulo y divida el trabajo por diferentes partes del módulo (UnitTesting, DAL y Mapping, Logics, UI)
• Asigne a todos los desarrolladores al mismo módulo y divida el trabajo por diferentes lógicas (por ejemplo, cada desarrollador está a cargo de una lógica específica (probablemente un método en el BL) y Es UnitTesting, DAL y Mapping and UI ...

¿O tal vez algo completamente diferente?

Mi equipo ha estado tratando de ser "ágil" durante algunos lanzamientos, pero ser parte de una gran corporación no lo ha hecho exactamente fácil. No voy a fingir que tengo la respuesta, pero puedo compartir algunas de mis observaciones.

• División de desarrolladores por módulo:

  • Debe tener cuidado porque si la gente trabaja demasiado aisladamente, su equipo no se beneficia de compartir habilidades y conocimientos.
  • La planificación de reuniones y stand ups diarios puede volverse increíblemente aburrida para todos si las personas se centran demasiado en sus propios módulos y no ven una imagen más grande. Una vez que las personas se aburren, comienzan a pagar y usted pierde gran parte del beneficio que Agile aporta.
  • Puede terminar con algunos componentes escritos muy bien, y otros componentes, bueno ... no tanto. Si las personas trabajan de forma aislada, sus muchachos mayores no podrán entrenar a los jóvenes.

• Todos trabajan en el mismo módulo al mismo tiempo

  • Intentamos eso para una versión, cuando la gerencia decidió que impondrán agilidad a todo el equipo y será completamente a su manera. Es como un choque de trenes absoluto. Tuvimos un equipo de 9 desarrolladores que entregaron en un año lo que normalmente habría hecho un desarrollador. (Podría estar exagerando aquí pero no por mucho).
  • Nadie sintió que había espacio para respirar. Aquellos a quienes no les importaba el software, se sentían como en casa porque, como parte de un paquete más grande, simplemente se diluyen en el grupo. Aquellos de nosotros que teníamos pasión por el software, nos sentimos absolutamente sofocados ya que no había libertad para movernos o ir más allá de los límites acordados por 9 personas.
  • Todas las reuniones fueron para siempre hasta el punto de querer dispararme. Demasiadas personas con una opinión en la misma habitación obligados a trabajar en la misma DLL. El horror.
• En la última versión, hemos decidido probar algo diferente
  • En primer lugar, divida el grupo de desarrollo en equipos más pequeños de 3-4 desarrolladores. Cada equipo trabajó en relativo aislamiento el uno del otro, pero dentro del equipo la gente trabajó mucho más cohesivamente
  • Con este enfoque, los stand ups son rápidos y las reuniones de planificación duran de 1 a 2 horas en comparación con las 4 horas sólidas.
  • Todos se sienten comprometidos porque cada equipo solo discute lo que les importa a los desarrolladores de ese equipo.
  • El líder técnico de cada equipo habla con otros líderes técnicos periódicamente para asegurarse de que el proyecto general esté en camino.
  • En lugar de hacer que las personas sean "propietarias" de un módulo específico, asignamos áreas de especialización a las personas, por lo que cuando comenzamos el proyecto, parecía que las personas tenían su propio módulo, pero después de varios meses, los desarrolladores empezarían a mirar el código de los demás como Las áreas comenzaron a superponerse.
  • Las revisiones de código son esenciales. Esta fue la segunda versión donde teníamos una estricta política de revisión de código y todos en el equipo los amaban. El experto de un área específica siempre está en una revisión de código cuando alguien más modifica ese código.
  • Con las revisiones de código, compartimos un montón de conocimientos y puede ver de manera visible la mejora general de la calidad del código de nuestros equipos. Además, debido a que el código se revisa con tanta frecuencia, cuando las personas entran en el área de especialización de otra persona, es probable que ya hayan visto el código al menos algunas veces.
  • Una gran parte de cada equipo es absorbida en las reuniones de revisión de diseño, por lo que incluso si nunca han visto el código, todos están familiarizados con el flujo general de todos los módulos de los que su equipo es responsable.
  • Lo hemos hecho durante aproximadamente 10 meses y parece que comenzamos con un enfoque de módulo aislado y nos transformamos en que todo el mundo trabaja en todo. Pero al mismo tiempo, nadie siente que están apretados o limitados. Y para asegurarnos de que los muchachos aún tengan sentido de cierta autoridad, los dejamos como expertos en el área, a pesar de que ahora es principalmente una formalidad.

Hemos estado haciendo lo último, y aunque hay mucho espacio para mejoras, en general todo nuestro equipo ha estado muy contento y eso dice mucho, cuando somos parte de una corporación gigante.

Una cosa importante que nos equivocamos las primeras 3 veces que "nos volvimos ágiles" es que cada una de esas personas se les dijo cómo trabajar y se les dijo en qué trabajar. Esa es la forma número uno de hacer que su equipo pierda por completo el interés en el proyecto y luego se encuentre en problemas reales.

En cambio, intente lo contrario. Dígale al equipo que pueden hacer lo que quieran y como gerente / líder (si usted es uno, si su gerente no repite estas palabras), su trabajo es asegurarse de que sean lo más productivos y felices posible. El proceso no es algo malo, pero debe estar allí para ayudar a su equipo cuando se dé cuenta de que necesita uno, y no al revés.

Si algunos de los miembros de su equipo prefieren trabajar de forma aislada, déjenlos (hasta cierto punto). Si prefieren trabajar en parejas, déjelos hacer eso. Asegúrese de dejar que su gente elija su propio trabajo tanto como pueda.

Por último, y esto es muy importante y siempre se pasa por alto. NO OBTENDRÁS ESTE DERECHO (a menos que seas superman, o al menos Batman). Tener reuniones retrospectivas regulares es extremadamente importante. Cuando lanzamos las retrospectivas, el libro las hizo y se sintió como otro proceso más por el que tuvo que pasar. Para eso no es retrospectiva. Es para escuchar a su equipo, identificar las áreas que causan más dolor y arreglarlas para que todos puedan seguir con su trabajo. Aparentemente, a los ingenieros de software en general les gusta comunicar productos y características, y la reunión retrospectiva de mensajes más importante para comunicarse es que es únicamente para su beneficio. Desea identificar y abordar obstáculos, comenzando con los más grandes (o los más fáciles, allí '

Tenga una reunión con el equipo, muéstreles la lista de tareas y pregunte quién quiere hacer qué.

No pienses en módulos. Piensa en elementos funcionales. Describa esos elementos de funcionalidad por historias de usuario (u otra forma) y no olvide describir los criterios de aceptación (probablemente definidos por su aplicación actual y los cambios que espera el negocio). Ponga sus elementos funcionales en la cartera de pedidos. Luego, permita que el negocio priorice qué funcionalidad debe entregarse primero (trabajará de forma incremental e iterativa y la prioridad le dirá qué debe implementarse primero).

Una vez que tenga esto, al menos para parte de su aplicación original, estará listo para el desarrollo. Lo que suceda después depende de su metodología ágil seleccionada. La parte importante es que cada funcionalidad generalmente se puede dividir en múltiples tareas y los miembros del equipo seleccionarán qué tareas quieren hacer, eso se llama autoorganización. Cuando comienzas con agile, la autoorganización puede necesitar ayuda para que alguien se asegure de que las tareas impopulares y populares sean compartidas por igual por el equipo. Una vez que el equipo sea más maduro, los desarrolladores no dudarán en expresar su desacuerdo con la organización actual y esto se manejará automáticamente dentro del equipo.

Pensar en módulos desde el principio no tiene que ser una buena manera. Está reescribiendo la aplicación por alguna razón y tal vez la arquitectura actual de la aplicación basada en la separación incorrecta del módulo es una de las razones ocultas detrás de los problemas visibles. También puede encontrar que algunas funciones de los módulos existentes se redefinirán por completo y se trasladarán a otro lugar.

Aunque estoy de acuerdo con la respuesta de David, sentí que podría sacar provecho de algunos detalles:

• Ágil significa que no toma estas decisiones y las empuja al equipo. No hay un gerente / líder de proyecto como ese. Solo el equipo.
• Los que mejor saben cómo dividir el trabajo son los propios miembros del equipo.
• Discuta su trabajo atrasado y descubra lo que quiere realizar en la próxima iteración / sprint.
• Uso de póquer planificación o métodos similares para tener una idea de la cantidad de trabajo que se va a dividir de todos modos, y sólo entonces comienzan a dividir paquetes de trabajo reales en conjunto .

Básicamente, la conclusión es: nadie aquí en SE puede responder esa pregunta por usted, ni tiene mucho sentido, porque es mucho mejor si encuentra una respuesta como equipo.

El enfoque más simple es a menudo el mejor.

Evitaría dividir las tareas en grupos como testing / log / UI / etc a menos que pueda definir algunas razones muy buenas y claras para hacerlo. Mi razonamiento es que cuando permite que los programadores trabajen fuera de sus áreas habituales de experiencia, puede hacer que las cosas sean más interesantes y desafiantes para ellos, y les permite desarrollarse y crecer dentro de su campo. Si cree que las limitaciones de tiempo requieren que divida el trabajo en función de la experiencia, como mínimo, asegúrese de que cada desarrollador aún tenga que realizar sus propias pruebas unitarias, y utilice la revisión del código y las pruebas de aceptación para resolver los problemas. Escribir sus propias pruebas es muy ágil, y esperar que el tiempo de los probadores esté disponible puede ser muy derrochador.

Cuando me enfrento a este mismo tipo de dilema, he empleado el siguiente enfoque:

• Alcance del proyecto. Dése una idea sobre en qué se está metiendo y desarrolle una lista de características dividiendo el proyecto en una serie de tareas.

• Priorizar características. Decida qué características deben completarse antes y cuáles proporcionarán un valor inmediato a sus clientes. No se preocupe si sus desarrolladores terminan trabajando en los mismos módulos, pero asegúrese de tener un buen proceso y herramientas para administrar las fusiones de código.

• Involucre a su equipo y solicite a sus desarrolladores que lo ayuden a desglosar las características en una lista de tareas más fáciles de administrar. Revise como grupo y ajuste las tareas según sea necesario para que puedan estimarse más fácilmente.

• Pídale a cada desarrollador que elija una tarea para implementar, o un grupo de tareas dependiendo de cómo se ejecutarán sus iteraciones, desde la parte superior de la cola de prioridad, en la que el desarrollador desea trabajar.

• Haga que cada desarrollador trabaje en una sola cosa hasta que se complete antes de pasar a seleccionar el siguiente elemento de la parte superior de la cola de prioridad. Es posible que sienta la tentación de hacer que su personal cambie las tareas ocasionalmente, sin embargo, esto generará un desperdicio en términos del tiempo del desarrollador. Si se encuentra con cuellos de botella de dependencia, deberá ajustar las prioridades de su tarea y minimizar el desperdicio.

• No tenga miedo de que los desarrolladores se ejecuten con iteraciones superpuestas, y administre sus versiones en consecuencia. Esto ayudará a minimizar el tiempo perdido entre lanzamientos esperando que se completen las tareas.

En última instancia, ser ágil se trata de encontrar una solución que funcione bien para su equipo, su empresa y sus clientes. Depende de usted ajustar su proceso al encontrar el equilibrio de prácticas que funcione mejor para usted. La forma de dividir sus tareas será una parte muy importante de un proceso mucho más grande, pero debe ser lo más simple posible para alentar la participación voluntaria y evitar problemas difíciles de resolver que se desarrollen más adelante.

Ninguna discusión organizacional del equipo desarrollador estaría completa sin mencionar el Equipo Quirúrgico del Dr. Fred Brooks .

La fórmula básica es: un equipo quirúrgico por unidad de trabajo

Definiendo un equipo quirúrgico

El concepto del equipo quirúrgico se basa en dos ideas fundamentales:

1. Menos desarrolladores son mejores por unidad de trabajo porque las conversaciones cruzadas matan la productividad.
2. Los desarrolladores de alto rendimiento superan a los desarrolladores de bajo rendimiento (y de acuerdo con Brooks, no existe un desarrollador de rendimiento medio), por lo que es mejor que les dé el trabajo más importante para hacer y limite sus distracciones.

Un equipo quirúrgico está compuesto por 3-10 desarrolladores:

1. Un programador jefe. Un desarrollador de alto rendimiento, que realiza la mayor parte de la programación real.
2. Un copiloto. Otro desarrollador de alto rendimiento, que realiza algo de programación, pero también algunas tareas administrativas, como asistir a reuniones y reunir requisitos.
3. 1 - 8 asistentes. Brooks los describe como desarrolladores responsables de cosas como documentación, limpieza de código, investigación, escritura de herramientas / algoritmos, pruebas, etc. En los años 60, Brooks propuso exactamente 8 roles, pero con herramientas modernas puede necesitar tan solo 1 o 2, y probablemente debería asignarse en función de las necesidades de su proyecto.

Definiendo una Unidad de Trabajo

Entonces, ahora que podemos formar un equipo, ¿qué les asignamos?

• Si el proyecto es muy pequeño , esto es fácil. Usted asigna un equipo quirúrgico a todo el proyecto.
• De lo contrario, deberá comenzar con una persona o equipo que esté a cargo de la arquitectura del proyecto completo . Será su trabajo modularizar el software adecuadamente para que el trabajo se pueda dividir entre sub-equipos adicionales. El equipo de arquitectura también puede realizar otro trabajo, para no extender demasiado a los desarrolladores.

Debería ver emerger tres patrones básicos y aceptables:

1. Exactamente 1 sub-equipo para cada capa (UI, DAL, etc.)
2. Exactamente 1 sub-equipo para cada módulo (Página de inicio, Sitio de soporte, Tienda)
3. Una combinación de los dos (un equipo marco de bajo nivel y un equipo centrado en la interfaz de usuario para cada módulo)

Dependiendo del número de desarrolladores y módulos (y escalas de tiempo), generalmente hago que mis desarrolladores elijan un módulo interesante (para ellos) y un módulo desafiante (preferiblemente algo que no han hecho) y luego el resto lo divido por nivel de habilidad y limitaciones de tiempo Creo que esto les da a mis desarrolladores algo en lo que quieren trabajar y algo para impulsarlos.

Por supuesto, esto no siempre funciona ...

Esto es lo que haría:

Si todos los módulos son pequeños, puede dar a cada uno un módulo para trabajar. De lo contrario, haga esto:

1. Defina el tamaño de cada módulo, la complejidad y las habilidades necesarias para hacerlo.
2. Definir las habilidades de cada miembro del equipo.
3. Defina qué personas trabajan bien juntas y cuáles no con otras.
4. Asigne módulos grandes a equipos de personas que trabajen juntos en función de los requisitos de habilidades del módulo y las habilidades del equipo.
5. Asigne los módulos restantes a las personas que no pueden trabajar bien con otras personas según los requisitos de habilidades del módulo y las habilidades del equipo.

Lo anterior no funcionará si las personas a las que no les gusta trabajar con otros son las más competentes y este es un caso común, así que haga una excepción a 4 y 5 en consecuencia