¿Qué proceso ágil promueve que el equipo asigne tareas a desarrolladores individuales en lugar de que los individuos se asignen tareas a sí mismos?

Usted pregunta:

1. ¿Existe un proceso que promueva que el grupo asigne tareas a desarrolladores individuales? Las tareas deben asignarse como parte de una decisión grupal y como parte de lo que viene a continuación.

Lo que debe hacer es explicarle al equipo (aquellos que realizan la recolección) cuál es su objetivo. Esto puede alentarlos a dividir la tarea como usted espera.

Una vez que se den cuenta del beneficio de su mejora , la mayoría lo aceptará.

Entonces preguntas:

2. ¿Cómo puedo lidiar con las ocurrencias cuando en realidad las personas se desplazan y reciben tareas de recursos externos de esta manera pirateando la decisión grupal de quién está haciendo qué? Me pregunto si lo que he descrito es una tontería. ¿Qué proceso ágil desalienta a los desarrolladores a elegir tareas por sí mismos?

Si bien Agile promueve la eficiencia, espera promover la ineficiencia a corto plazo para la eficiencia a largo plazo.

Una vez que (re)defina "eficiencia", debería fluir con su implementación de Agile.

No puedes evitar que la gente rompa las reglas, a menos que quieras convertirte en policía, y tienes la autoridad para castigar a la gente. (Incluso entonces, probablemente no desee ese tipo de cultura). Pero puede alentarlos a seguir sus reglas y explicarles los beneficios de ello.

Tenga en cuenta que "romper las reglas" de vez en cuando no es el fin del mundo ; a veces es mejor ignorar las infracciones menores en lugar de hacer un gran problema y distraer a todos.

Una buena idea puede ser mantener un registro de cuándo su implementación "salvó el día". Por ejemplo: dado que x e y conocían el código, cuando x se fue de vacaciones, no necesitábamos un traspaso prolongado.

Recordarles a las personas cuán grandioso es su sistema, con pruebas, les ayuda a entenderlo, alentándolos a seguirlo.

No estoy al tanto de un proceso que desaliente explícitamente a los desarrolladores a elegir sus tareas. En cambio, la mayoría de los marcos ágiles fomentan el uso de equipos autoorganizados .

Un aspecto de la autoorganización es que el equipo decidirá cómo se distribuyen las tareas entre los miembros del equipo.

Sin duda, sería legítimo que un equipo intentara un proceso de asignación de tareas aleatorio o pseudoaleatorio. Tal vez podrían ejecutarlo como un experimento: decidir cómo medirán el éxito, probar el enfoque durante un período de tiempo (por ejemplo, 4 semanas) y luego evaluar cómo resultó el enfoque al final.

Sin embargo, no sería apropiado en un equipo autoorganizado que una persona decidiera el enfoque para la asignación de tareas y lo impusiera en el equipo. El equipo debe discutir enfoques alternativos y llegar a un consenso sobre el enfoque que quieren probar.

¿Cómo puedo lidiar con las ocurrencias cuando en realidad las personas se desplazan y reciben tareas de recursos externos de esta manera pirateando la decisión grupal de quién está haciendo qué? Me pregunto si lo que he descrito es una tontería. ¿Qué proceso ágil desalienta a los desarrolladores a elegir tareas por sí mismos?

Si el equipo decide el enfoque que utilizará, es mucho menos probable que trate de evitarlo. Este es el valor de los equipos autoorganizados: los equipos aceptan el enfoque elegido y, por lo tanto, es más probable que lo ejecuten bien.

Agile se trata de equipos autoorganizados. El equipo es el que puede descubrir la mejor manera de hacer el trabajo y, por lo general, terminas con algún tipo de sistema de extracción. La gente toma trabajo, no se le asigna trabajo.

Si el equipo decidió que es una buena idea alentar a todos a realizar tareas con las que no están familiarizados, entonces eso es una cosa. Si desea una práctica que los desaliente a realizar tareas con las que están familiarizados, entonces eso es otra cosa. El primer enfoque es Agile, el segundo... lo dudo .

No creo que haya ningún proceso Agile que haga lo que pides, y eso es porque realmente no tiene sentido a menos que tu contexto sea particular. Con eso quiero decir que el trabajo es más o menos de la misma área de especialización, los miembros de su equipo tienen roles dentro de esa área de especialización, pero no solo tienen la misma experiencia. Algunos son más hábiles, otros son menos. Hacer lo que sugiere podría funcionar en esa situación, pero no puede funcionar en todas las situaciones. Y la razón es que, inevitablemente, tendrás especialización dentro del equipo.

La forma en que formulaste la pregunta me hace pensar que crees que la especialización es un problema. No es mientras el equipo tenga todos los roles dentro del equipo para hacer su trabajo, entonces eso no es problema . Los equipos entregan software en Agile, no los individuos.

La especialización se convierte en un problema cuando la empresa tiene silos de especialistas que se comparten entre equipos y proyectos. De hecho, tiene un problema porque es una dependencia externa y el equipo en realidad carece de algunos roles para hacer su trabajo correctamente por su cuenta.

Es bueno compartir conocimientos, es bueno tener sesiones de programación en pareja, es bueno que las personas tengan una visión general y compartan la responsabilidad sobre los resultados, pero asignarles tareas con las que no están familiarizados no es necesariamente la forma de hacerlo. Los empuja fuera de su zona de confort y esa es una manera de aprender cosas, pero si los empuja demasiado lejos, terminará causando mucha frustración e incluso rotación de empleados. Como dije, esto funciona en ciertos contextos, no en todos. Los animo a pensar en el último proyecto en el que probaron esto y considerar las habilidades de las personas y la naturaleza del trabajo, y estoy seguro de que descubrirán que no hubo demasiada variación, solo diferentes niveles de experiencia y visión. del panorama general.

Para darle otro ejemplo, considere que tiene un diseñador en su equipo y un desarrollador back-end de Java. ¿Obligaría al desarrollador de back-end a realizar una tarea de diseño solo porque desea evitar la especialización? ¿O peor? ¿Le daría al diseñador una tarea de back-end? No tiene sentido.

De hecho, hay un problema: cuando se trabaja en tareas prioritarias. Digamos que el diseñador está ocupado, pero el desarrollador de back-end acaba de terminar un trabajo y puede elegir la siguiente tarea de la lista de prioridades. La siguiente tarea en orden de prioridades es una tarea de diseño. ¡UPS! Ahora el desarrollador tiene que mirar a su alrededor para ver qué otro trabajo de back-end hay. La segunda tarea es el trabajo de back-end, por lo que la retoman. Pero esa era la segunda prioridad, no la primera. Eso es un problema, ¿verdad? Pero no soluciona este problema empujando la tarea de diseño en la garganta del desarrollador de back-end.

Si está preocupado por la forma en que se realiza el trabajo o ha identificado algún riesgo con los programadores que eligen solo ciertos tipos de tareas, plantee el problema al equipo y déjelos encontrar una manera de solucionarlo. No imponga una cierta forma de trabajar, puede haber otras/mejores formas de solucionarlo, no necesariamente como usted sugiere .

En términos generales, debe preocuparse por lo que el equipo se compromete a hacer a continuación, y no precisamente por quién de los miembros del equipo lo hace realmente.