Gobernanza de Proyectos Ágiles con PMPeople y Asana

Las organizaciones que utilizan PMPeople ejecutan varios proyectos organizados en unidades de negocio, carteras y programas. Según el enfoque de desarrollo de los entregables, algunos proyectos son predictivos, otros son adaptativos y otros son híbridos.

Nuestra recomendación para gestionar la parte ágil de un proyecto es mantener la gestión del proyecto en PMPeople, descomponer el proyecto en paquetes de trabajo, es decir, lanzamientos ágiles. El paquete de trabajo n.° 0 (es decir, el proyecto en sí) puede incluir tareas de PMPeople para las características principales (también conocidas como epopeyas), y los lanzamientos pueden incluir tareas de PMPeople como características que se demostrarán a las partes interesadas (también conocidas como historias de usuario). Para mejorar la colaboración con el equipo de desarrollo, recomendamos utilizar nuestra integración incorporada con Asana.: Los proyectos de Asana se pueden vincular a los paquetes de trabajo de PMPeople, para que los altos directivos no tengan que entrar en Asana.

Veamos cómo se puede hacer esto en la práctica, en un ciclo ágil que comienza con la planificación del proyecto y termina con la primera retrospectiva. Para simplificar, supongamos que el director del proyecto desempeña el papel de coach ágil y propietario del producto. El nombre del proyecto ágil es PR1:

1. El gerente de proyecto facilita la planificación de la liberación: Los miembros del equipo revisan la versión actual del product backlog para decidir qué historias (o epopeyas) son las más valiosas para el nuevo lanzamiento. Durante el debate, se agregan nuevas historias, se anotan aclaraciones, se aparcan algunos elementos, etc., lo que da como resultado una lista de elementos priorizados en el proyecto de Asana para el lanzamiento denominada PR1_REL1. Todos los elementos se comparten con la lista del product backlog PR1_PBL. Los elementos relevantes que se compartirán con los gerentes sénior se pueden compartir en otra lista denominada PR1_EPICS. Los elementos que se aparcan o se etiquetan para un análisis posterior se mueven a la lista PR1_PARKING.
2. El director del proyecto planifica el proyecto: El gerente de proyecto utiliza PMPeople para compartir información relevante sobre el caso de negocios, la carta del proyecto, el registro de partes interesadas, los entregables, los requisitos, los riesgos, el cronograma, los hitos, los costos, etc. El estado del proyecto se establece en ejecución.
3. Los miembros del equipo pueden consultar sus asignaciones al paquete denominado REL1 en PMPeople. Pueden colaborar para elaborar un estatuto del equipo. Pueden registrar un índice de felicidad de forma anónima, enviar comentarios dirigidos al gerente del proyecto, etc.
4. El administrador de proyectos conecta el paquete de trabajo n.° 0 y REL1 a los proyectos de Asana PR1_EPICS y PR1_REL1, respectivamente.
5. El gerente de proyecto explica la funcionalidad esperada para el primer sprint. Los miembros del equipo descomponen las características en tareas técnicas. Pueden usar una lista para el primer backlog del sprint para el primer lanzamiento del proyecto PR1, como proyecto Asana PR1_SPR1.1. Las historias de usuario también se incluyen en esta lista y las tareas técnicas se establecen como subtareas de Asana y se comparten como tarjetas en otro proyecto de Asana para el tablero KANBAN, sección «por hacer».
6. Los miembros del equipo utilizan el tablero KANBAN durante las reuniones diarias. Cuando un miembro del equipo elige una tarea para hacer, todos pueden verificar el nombre del asignado y la fecha de vencimiento. La buena práctica del flujo de una sola pieza se aplica si nadie tiene más de una tarjeta en la sección «en progreso» del tablero KANBAN. Si algunas tareas se ven obstaculizadas, esto se puede anotar adecuadamente en la sección de descripción de la tarea y etiquetar visualmente en el título con un emoji ? en el título de la tarea. Una buena práctica es que los impedimentos se resuelvan antes de la siguiente reunión diaria, siguiendo la regla: «No dos reuniones diarias hablando del mismo impedimento«.
7. Si los miembros del equipo anotan las horas ideales (planificadas frente a pendientes) en las tareas de Asana, el gerente de proyectos puede actualizar fácilmente el gráfico de evolución del sprint. Si las historias de usuario se calculan con puntos de historia, el gerente de proyectos también puede actualizar los gráficos de evolución del lanzamiento.
8. Los miembros del equipo pueden enviar horas y gastos en cualquier momento mediante aplicaciones móviles o web. El gerente de proyecto puede aprobar o rechazar horas y gastos al final de cada semana. Si se necesita controlar los costos, los informes en línea evitan el papeleo y el desperdicio de procesos.
9. Cuando un miembro del equipo completa una tarea, la marca como completada en el tablero KANBAN (o en la lista PR1_SPR1.1) y la mueve a la sección “completada” en KANBAN. Cuando se completan todas las tareas de una historia de usuario, el gerente de proyecto puede marcarla como completada en PR1_REL1. Los datos de las historias y las épicas se pueden sincronizar automáticamente desde Asana a PMPeople.
10. Durante la demostración del sprint, los miembros del equipo solo muestran a las partes interesadas las historias completadas. Si una historia no es aceptable, se marca como incompleta. Las historias incompletas se pueden planificar fácilmente más adelante.
11. En PMPeople, los gerentes de proyectos ágiles suelen planificar las fechas de revisión al final de los sprints. El gerente de proyectos puede registrar la información correcta en el informe de estado para la versión 1 y para todo el proyecto. Las partes interesadas pueden verificar el estado del proyecto en aplicaciones móviles o web.
12. Por último, el director del proyecto puede facilitar la reunión retrospectiva con el equipo si los miembros del equipo han anotado su información del índice de felicidad en PMPeople.