¿Cómo se debe distribuir la habilidad a través de los equipos?

Después de leer esto, Vi que parece haber un gran desacuerdo sobre la forma en que los equipos ágiles deberían estructurarse dentro de un grupo de desarrolladores con diferentes capacidades (es decir, casi todos los equipos). ¿Deberían los mejores desarrolladores formar parte de sus propios equipos y recibir el trabajo de mayor prioridad? Esto garantizará que se realicen las tareas más importantes. Al mismo tiempo, se queda con los equipos "menos que perfectos" en otros lugares acumulando deuda técnica, incluso si solo se trata de tareas de baja prioridad. Por otro lado, los equipos distribuidos de manera uniforme podrían tener la ventaja de mejorar un poco a sus desarrolladores rezagados, pero tienen el potencial de desmotivar a sus bateadores más pesados. Además, si combina un montón de buenos patrones de diseño con un montón de antipatrones terribles, realmente puede terminar con algo que también podría ser un montón de antipatrones.

Hay algunos riesgos conocidos con A-Teams, pero si la dinámica es correcta, creo que sí, pondría a mi gente más fuerte en los proyectos más importantes junto con los desarrolladores junior con el mayor potencial. Para sus proyectos de menor prioridad, necesita un buen líder de equipo si es posible para evitar que se alejen de los rieles. La deuda técnica va a suceder pase lo que pase. No toda la deuda técnica es igual; En primer lugar, el costo / responsabilidad de la deuda técnica es proporcional al valor comercial del proyecto, por lo que si bien sus proyectos de menor prioridad pueden tener más verrugas, el costo de esos probablemente aún sea mucho menor que los problemas significativos en sus proyectos de alta prioridad ser.

Recuerdo cuando estaba en la universidad uno de nuestros profesores contándonos una anécdota sobre las estructuras de los equipos (eché un vistazo al artículo del que estaba hablando ahora pero parece que no puedo encontrarlo).

Básicamente, la historia fue la siguiente:

Un grupo de programadores se dividió en grupos según la habilidad, con los peores programadores x agrupados, los siguientes x agrupados, etc., y los mejores agrupados.

A todos se les asignó la misma tarea y se les asignó un marco de tiempo establecido para completarla.

Al final del período de tiempo, los organizadores analizaron las soluciones para las tareas y, para su sorpresa, descubrieron que la solución con el mejor rendimiento provenía del equipo formado por personas promedio. En contraste, el equipo formado por los programadores A * hizo una de las peores soluciones porque pasaban todo su tiempo discutiendo cuál era la mejor solución .

Si necesita un equipo que haga las cosas, consiga un grupo de hombres promedio y un hombre dominante que pueda liderar, fue la conclusión del estudio (si no recuerdo mal), de lo contrario, los miembros más dominantes pasarán más tiempo peleando que peleando. cosas hechas!

Es posible que la gran mayoría de los desarrolladores inexpertos no puedan crear diseños robustos y elegantes por sí mismos, pero pueden reconocerlo y comprenderlo cuando lo ven. Si no pueden, entonces generalmente carecen de la aptitud o la preparación para haber sido contratados en primer lugar.

También hay algunos desarrolladores más experimentados que son capaces de comprender diseños de software muy complejos, pero carecen de la discreción para saber cuándo algo más simple sería mejor.

En mi experiencia, generalmente solo tienes problemas permanentes con equipos mixtos si contienen miembros no preparados, miembros innecesariamente complejos o ambos. De lo contrario, si su equipo tiene problemas, generalmente se pueden solucionar con una mejor comunicación o asignando roles apropiados.

Agrupar a las mejores personas en un solo equipo puede parecer una excelente solución a corto plazo, pero es un fracaso a largo plazo y tiene costos adicionales. Por ejemplo, mi empresa prefiere cuando las personas aprenden de sus colegas más calificados en lugar de pagar por capacitaciones. Si separa a las mejores personas, no podrán transferir conocimientos a personas menos calificadas. A corto plazo, sus mejores equipos pueden desempeñarse bien, pero debido a la falta de transferencias de conocimiento, el número de personas calificadas no aumentará. Es mucho mejor tener un equipo con menos rendimiento al principio y aumentar el rendimiento en todos los equipos a medida que las personas se vuelven más hábiles.

Además, ¿qué sucede si las personas calificadas deciden irse? ¿Quién tomará sus proyectos?

Otro punto es que el equipo debe estar compuesto por personas con diferentes conjuntos de habilidades. Siempre tendrá tareas fáciles (y tareas aburridas) que son demasiado caras para que las realicen los desarrolladores más experimentados.

Los que no pueden enseñar, hacen ...

Creo que hay más factores a considerar.

Obtendrá el mayor valor al distribuir aquellos que puedan enseñar como líderes de equipo. Pueden enseñar a los otros miembros del equipo y ayudar a elevar la calidad de su trabajo.

No todos los programadores senior harán buenas pistas. Esa capacidad de comunicar información es una habilidad en sí misma. Esta habilidad no es algo que se desarrolla a través de la experiencia de programación. Se desarrolla a través de la enseñanza y la explicación.

Asignar un equipo 'A' tiene dos problemas importantes. Primero es la compatibilidad. Tener equipos que se llevan bien y trabajan bien juntos es mucho más importante que su "habilidad". Ahora esto puede ser dos programadores de habilidades "altas", dos programadores de habilidades "bajas" o una combinación. El hecho de que puedan trabajar bien juntos significa que serán más productivos.

El segundo tema trata del crecimiento. Dos programadores de habilidades "bajas" no aprenderán mucho unos de otros, además de los malos hábitos. Del mismo modo, dos programadores "altamente" calificados no aprenderán mucho el uno del otro. Sin embargo, mezclar los niveles de habilidad "bajo" y alto "ayudará a mejorar las habilidades de la habilidad" baja ". También mejorarán las habilidades de los expertos" altos ". ¿Cómo? Al tratar de enseñar un tema, encontrará rápidamente sus puntos débiles en eso. no considero una habilidad "dominada" hasta que pueda enseñársela a otra persona.

Desde el otro lado de la moneda, creo que tiene sentido mantener equipos que puedan "mantenerse al día" entre sí. Sus programadores de tipo A-Team no quieren esperar a que los tipos B-Team hagan sus partes. Sus tipos de B-Team pueden estar intimados por el flujo de trabajo de estilo A-Team.