¿Cómo administra los recursos con un enfoque ágil con PMI?

En un caso con personas limitadas como 5, debe pasar por un proceso iterativo.

Si ponderas, distribuyes y asignas las historias a desarrollar de manera que todos estén bien orquestados y vas en un sprint de 2 semanas y normalmente sigues los siguientes "pasos"

Carrera #1

Historia #N

  • Diseño
  • Código
  • Prueba de unidad

Después de las pruebas unitarias, uno de sus recursos terminó la última historia de Sprint mientras que otros no y por alguna razón quedan 1 o 2 días. ¿Qué se supone que debe hacer este recurso inactivo?

En los enfoques tradicionales, como todo es secuencial, casi todos terminan en la fecha específica o más tarde de lo planeado. También en el tradicional, corre el riesgo de volver a trabajar y volver a planificar, pero cómo administrar ese recurso inactivo en un sprint. ¿Cómo rastreas o haces con esos excelentes creadores de historias que terminaron antes de tiempo?

Fwiw, a la mayoría de las personas no les gusta que las llamen recursos :)
No asignas trabajo en procesos ágiles; utiliza una cola de extracción. También apunta al flujo, no a una alta utilización. Las prácticas que estás describiendo no son realmente "ágiles".
@Erik ¡Edité mi pregunta para aquellos que son sensibles a las palabras literalmente! ;)
@ToddA.Jacobs, Gracias por tu comentario. Efectivamente, tal vez estoy mezclando conceptos porque estoy migrando gradualmente para comprender el enfoque ágil. Necesito estudiar más. El equipo para el que trabajo se está moviendo rápido y adaptándose a Agile. Realmente aprecio tu comentario.
@ToddA.Jacobs, digamos que si los miembros del equipo están terminando sus tareas y no se requieren más tareas, ¿volverán a esa cola de extracción? (por no decir empujarlos a la cola) disponible para el próximo sprint o proyecto?

Respuestas (3)

En términos generales, siempre hay algo que la gente puede hacer. Pueden ayudar a un colega con sus tareas, aprender un nuevo truco, escribir documentación, limpiar código, hablar con otro equipo, preparar una presentación sobre algún tema útil, invitar a la gente a tomar un café, hablar con el propietario de un producto o una parte interesada sobre los objetivos. , obtener información sobre algún producto existente, limpiar la oficina o hacer cualquier otra de las cosas que están en la lista "Realmente deberíamos arreglar eso cuando tengamos tiempo" que tiene cada equipo.

Uno de los objetivos clave de ser un equipo autoorganizado es que las personas a las que les quede algo de tiempo encuentren algo productivo para ellos mismos. Si no ve que eso suceda, es posible que desee indicarles algo que se pueda hacer, pero déjelos elegir algo para que puedan aprender a ser proactivos con respecto a estas cosas.

Gracias por tu respuesta. Entiendo que el enfoque ágil difiere del PM tradicional en que debe promover equipos colaborativos y autoorganizados. Y como ToddA. Jacobs dice que no se trata de optimización. Pero lo que estoy tratando de entender es si las personas disponibles no podrán comenzar el próximo sprint hasta que todos los "designados" para el proyecto estén disponibles, ¿verdad?
Si está ejecutando un sprint basado en scrum, entonces el sprint tiene una duración fija. No importa qué, termina en un día determinado y el siguiente comienza a la mañana siguiente, y conoces estas fechas cuando comienzas el sprint. Incluso si todos terminan dos días antes, el sprint no termina hasta dentro de dos días más, por lo que la gente tendrá que buscar más trabajo por hacer.
+1 para una lista sólida de sugerencias. Además, no se olvide de otros equipos: ¿puede ayudar a capacitar a soporte de primera línea, ventas, marketing u operaciones en algunas características nuevas?

La respuesta de @Erik es perfecta cuando la situación es que todo el equipo ha terminado los objetivos del sprint antes de tiempo.

Si solo algunos de los miembros del equipo terminaron antes de tiempo, su principal prioridad debería ser ayudar a otros miembros del equipo a terminar su trabajo de sprint. Usted quiere que los miembros del equipo piensen primero en el equipo, no solo en sus logros individuales.

Habiendo dicho eso, con frecuencia observo a los desarrolladores decir que están "terminados" cuando en realidad solo tienen el código completo. ¿Existen pruebas automatizadas? ¿Está hecha la documentación? ¿Ha actualizado alguna guía de usuario relevante? ¿Ventas y marketing tienen lo que necesitan para la nueva característica? Estas cosas pueden estar fuera de su "definición de hecho", pero siguen siendo importantes y mejorarán la calidad de la entrega de su equipo.

Durante el proceso de sprint, el objetivo de Sprint es el objetivo del equipo. En mi caso, comenzamos cada historia usando la siguiente secuencia:

  1. El desarrollador y el propietario de QA y Prod (o BA) tienen una reunión rápida para asegurarse de que están en sintonía con la historia/criterios de aceptación. (Nos ahorra muchos retrabajos)
  2. El desarrollador comienza a codificar. Una persona de control de calidad comienza a escribir casos de prueba (automatizados y manuales) al mismo tiempo. Se mantienen en bucle durante el sprint.

  3. Si terminan una historia, pasan juntos a una historia diferente.

  4. Si alguien tiene tiempo de inactividad, siempre hay muchas actividades como revisión de código, revisión de scripts de prueba, optimizaciones de procesos de compilación, documentación de actualización, etc.

  5. Si todavía hay tiempo libre, buscamos nuevas historias O trabajamos en parejas (programación en pareja)

Espero que esto ayude.

Por supuesto. Muy interesante. Muchas gracias por tu respuesta.
¿Cómo administra los recursos con un enfoque ágil con PMI?
RespuestasAquíPolítica de privacidad1y, 0v