¿Cuál es el número preferido de tareas para asignar?

No importa, te equivocarás de todos modos. Solo los individuos mismos saben lo que es mejor para ellos, por lo que creo que es un poco presuntuoso pensar que puedes hacerlo mejor.

Así que la respuesta es: no .

Asignar tareas es malo para el desarrollo de software, ya que obstaculiza la creatividad y genera estrés negativo, entre otras cosas. Considere darle la vuelta y hacer que el equipo seleccione las tareas. Eso lo convierte en un compromiso personal que tiene muchas más posibilidades de éxito. También crea un poco de presión saludable porque se han encargado de completar las tareas, en lugar de que alguien más lo haga por ellos.

También libera tiempo para que lo dediques a cosas realmente importantes, como priorizar el trabajo y eliminar impedimentos para el equipo.

Esencialmente, esto va de "empujar" a "jalar".

Trabajar en múltiples tareas al mismo tiempo siempre paga por la calidad. Asignar una tarea a la vez y esperar a que se complete antes de asignar otra tarea tampoco es una opción correcta. A veces, se quedará atascado en un problema o trabajará durante mucho tiempo en la misma tarea y lo agotará.

Mi sugerencia es asignar múltiples tareas y decirle las prioridades por adelantado. Deje que el desarrollador tenga la libertad de elegir entre tareas, siempre y cuando entregue con la calidad esperada.

Actualmente soy el maestro de scrum en un pequeño equipo que trabaja con Agile SCRUM y anteriormente he sido líder en equipos más grandes.

Creo que es mejor dejar que las personas elijan sus propias tareas, dejar que las personas se asignen tareas a sí mismas, lo que supongo que es más o menos análogo a asignar tareas a las personas y dejar que las dejen y elijan otra cosa. El progreso de una tarea: si alguien necesita ayuda, ha elegido una tarea que no puede completar, etc., se puede verificar en una reunión rápida todas las mañanas donde todos le dicen a todo el equipo cómo les está yendo. Permitir que las personas elijan sus propias tareas les permite estar expuestos a partes del sistema que de otro modo no verían, y les permite tomar decisiones sensatas sobre su propio trabajo y continuar con él sin tener que preguntarle "qué sigue" cada vez.

Creo que tener una tarea asignada y esperar completarla antes de poder hacer cualquier otra cosa proviene de un enfoque más en cascada. La idea ahí es que hemos identificado estas tareas y estas son las tareas que tenemos que hacer y tienen que hacerse en este orden porque eso es lo que planeamos. El problema con eso es que cuando realmente llegas a escribir código, a menudo (generalmente) resulta que el plan no cubre todo y necesitas tareas adicionales, o no tantas tareas, o tareas diferentes, o las mismas tareas en un orden diferente.

En resumen: creo que lo mejor es ser flexible con la gente. Pero esa es solo mi opinión :)

Consideró tener una lista de tareas en algún lugar donde las personas puedan inscribirse y luego trabajar en ellas cuando tengan tiempo.

Si en general muy poco progreso para una persona? Cancele la asignación de uno o más elementos y vuelva a colocarlos en la lista.

Los rastreadores de errores modernos también pueden manejar tareas, lo que brinda una gran visibilidad sobre cómo van las cosas para que otros las vean. Desea uno que esté integrado con su sistema de control de versiones para que pueda simplemente poner un marcador en el mensaje de confirmación, que el administrador de tareas recoge automáticamente.

Tengo un tablero con todas las tareas en orden de prioridad. Las reglas son:

• Si no tiene una tarea, saque la tarjeta superior y asígnela.
• Si alguien más en los equipos sabe más sobre el problema, consúltelo, pero haga el trabajo usted mismo.
• Si te encuentras con un bloqueador, tráemelo y pasa a otra tarea.
• Si siente que está tardando demasiado o atascado, obtenga una consulta mía o de otro programador. Si eso no funciona, lo tratamos como un bloqueador (tráemelo).
• Solo deberías estar trabajando en una tarea.
• Puede omitir tarjetas solo si es usted quien más sabe sobre el problema.
• Puede emparejar el programa según sea necesario.

Todas las tareas se reducen a no más de 1 o 2 días de trabajo.

Esto solo funciona en un grupo que quiere la propiedad del grupo y no tiene diferentes roles altamente especializados (es decir, desarrollador flash, dba, programadores de controladores de dispositivos integrados, etc.).

Mi opinión sobre este tema es: Depende.
Depende del desarrollador. Por ejemplo, hay desarrolladores a los que les gusta la libertad del segundo método junto con la presión adicional que este método ejerce sobre el desarrollador. Ejerce una presión adicional sobre el desarrollador, porque no es responsable de completar una tarea a tiempo, sino varias. Soy tan desarrollador, la presión del tiempo más la libertad de lograr los objetivos en el orden que me gusta realmente me hace productivo.
Sin embargo, hay otros desarrolladores que no pueden hacer frente a esa presión y se vuelven improductivos.

Lo que quiero decir: no hay una respuesta definitiva, depende completamente de sus desarrolladores y es posible que deba cambiar su método para cada desarrollador individual.

Depende en gran medida de sus codificadores. Algunos necesitan que se les asignen tareas, otros solo son productivos cuando realmente eligen sus tareas.

También depende de las tareas: ten en cuenta que en algún momento deberás asignar algunas tareas que nadie querrá hacer, pero que aún deben realizarse.

Una cosa que debe hacer es tener una lista razonablemente completa de tareas. Brinde cierta flexibilidad a los miembros de su equipo, en el sentido de que se les debe permitir dividir, cuando lo consideren necesario, algunas tareas en subtareas más pequeñas y pequeñas. Esto les dará una mayor sensación de poder opinar sobre lo que van a codificar.

En esta lista, asegúrese de que quede claro a quién se le asigna qué tarea y qué tareas dependen de otras tareas. Si se necesita una tarea para completar otras tareas, debe quedar claro para todos a quién ayudar o regañar (dependiendo de si la persona asignada está trabajando o no).

En la medida de lo posible, desea que sus programadores se comprometan con sus propias tareas (serán más productivos) y que se ayuden entre sí (trabajarán mejor en equipo).

Así que comience por permitirles elegir un par de elementos de mayor prioridad de su lista; cosas que quieren hacer, déjeles claro cómo se relacionan las tareas con el trabajo de los demás y anímelos a comunicarse mientras trabajan en cosas que dependen del trabajo de los demás. (Evite sobrecargar su horario de trabajo con reuniones grupales: estarán bien discutiendo cosas alrededor de un café o en los escritorios de los demás cuando sea necesario).

Un punto a tener en cuenta al hacerlo es preocuparse por los miembros más tímidos de su equipo; pueden estar interesados ​​en trabajar en esta o aquella tarea, pero se avergüenzan porque alguien más con una boca más grande quiere encargarse de eso. Identifíquelos rápidamente y fuerce un poco las probabilidades dejándolos periódicamente elegir sus tareas primero.

Su equipo también incluirá algunos miembros a los que se les deben asignar tareas. Para estos, proceda un poco como con los miembros tímidos (con frecuencia serán los mismos, en mi experiencia). El truco aquí es saber que, si bien la mayoría de las personas temen tomar decisiones de la nada, por lo general les gustará tener que elegir una opción entre varias opciones. lo que difiere de una persona a otra es el umbral. Para algunos es multitud de opciones; para otros es tan pequeño como uno solo. Por lo tanto, trate de calcular un número con el que se sientan cómodos. Luego, en un primer paso, pregunte cuál de entre esta, esta y aquella tarea preferirían hacer; y en un segundo, si hay otra tarea en la que no habías pensado que les gustaría aún más. Esto inhibirá su miedo y hará que elijan sus tareas sin darse cuenta.

Otro punto a tener en cuenta es que necesitas ser firme de vez en cuando. Al final del día, usted es el jefe y si nadie se ofrece como voluntario para una tarea en particular, deberá asignarla directamente. Por supuesto, hay formas educadas de hacerlo, que estoy seguro de que ya conoces.

De la misma manera, sea flexible. Algunas tareas parecerán nunca realizarse, porque quienquiera que se ofreció como voluntario rápidamente lo encuentra aburrido o difícil o lo que sea, y comienza a concentrarse en otra cosa. Supervise esto y (suavemente) elimine estas tareas de ellos si es necesario. Los miembros de su equipo apreciarán si usted reasigna sus tareas, en lugar de perder la cara en público ("lo siento, no pude asistir").

El enfoque que tomé cuando dirigía un equipo (6 personas, proyecto de 18 meses), que funcionó bien y los miembros del equipo parecían contentos con él (podría haberlo hecho con mejores herramientas/automatización, pero no teníamos el presupuesto para comprar lápices, por no hablar de un sistema de gestión de tareas), era comenzar identificando todas las tareas y subtareas que debían realizarse para una iteración y asignar una estimación aproximada de la dificultad con todo el equipo. Luego recuperaría esa lista, la refinaría si fuera necesario, priorizaría tareas y asignaría miembros del equipo a tareas específicas.

Luego, a cada miembro del equipo se le enviaría su lista de tareas detallada completa, priorizada y con estimaciones de tiempo, entregables para esa tarea, etc., además de una descripción general más breve de las tareas en las que estaban trabajando los otros miembros del equipo. Todos tuvieron la oportunidad de comunicarse conmigo si sentían que era necesario modificar los plazos, o si los entregables no eran lo suficientemente claros, etc.

Cada noche, los miembros del equipo me enviaban un correo electrónico con las subtareas en las que habían trabajado y el avance de esa tarea. Esto me permitió ver qué tan bien estaban nuestras estimaciones de tiempo y estar al tanto de lo que la gente estaba haciendo. Si alguien pasaba mucho tiempo en algo con una prioridad más baja, mientras que las tareas de mayor prioridad no se estaban haciendo, entonces tendría una discusión con ellos sobre por qué sentían que necesitaban trabajar primero, y ver si había era una forma de hacer malabarismos con las tareas para garantizar que las dependencias se terminaran antes de que se necesitaran.

Esto funcionó particularmente bien porque los miembros del equipo sabían todo lo que se esperaba de ellos para una iteración determinada, lo que les ayudó a tomar mejores decisiones de diseño/implementación para sus módulos (teníamos un diseño general, pero los detalles se dejaron en manos de los miembros del equipo que estaban implementando una función en particular) y permitió que los miembros del equipo colaboraran fácilmente ya que sabían exactamente quién estaba trabajando en qué función. Brindé orientación en términos de enumerar prioridades y dependencias, pero dejé que los miembros del equipo decidieran en qué orden querían trabajar en las tareas.