Si se pregunta a 100 jefes de proyecto cuál es el mayor reto que encuentran en su trabajo, 76 responderán hablando de los obstáculos que encuentran a la hora de comunicarse con el equipo. Gestionar la comunicación implica implicar a las partes interesadas, y también mantener la sinergia de los implicados. Una buena comunicación puede marcar la diferencia entre el éxito o el fracaso de un proyecto.
En los métodos predictivos correspondía al director del proyecto identificar cuáles serían los hitos del proyecto y qué eventos debería realizar el equipo a lo largo del mismo para garantizar un buen desarrollo del equipo. Los métodos ágiles arrojan más luz sobre esta interacción -el propio manifiesto ágil refuerza la idea de individuos e interacciones más que de procesos y herramientas- y por poner en su base 5 grandes eventos, que forman los pilares de la interacción en scrum, son:
Planificación de sprints
Reunión diaria de pie
Revisión de Sprint
Sprint Retrospectiva
Retrospectiva del proyecto
Sprint Planning es el primero de los eventos de scrum, y también se utiliza en otras metodologías ágiles, su función principal es ayudar al equipo a entender el trabajo a realizar, su esfuerzo, y más que eso: una estimación más asertiva de las tareas a realizar
La planificación comienza con la elección por parte del equipo de las historias en las que les gustaría trabajar en ese periodo de tiempo, siguiendo el orden de priorización previamente definido por el PO en el proceso de priorización del Backlog. Las historias ya han sido estimadas, de modo que intentamos trabajar siempre con la misma cantidad de esfuerzo. Es responsabilidad del PO definir junto con el equipo el periodo del sprint, con el fin de cumplir el calendario de entrega. Al seleccionar las historias, el equipo también debe mirar si existe algún tipo de dependencia entre ellas, u otros requisitos que pospongan su ejecución.
Una vez elegidas las historias en las que trabajar, el equipo empieza a comprender qué tareas deben realizarse para ejecutar cada historia. Es habitual que en un equipo de desarrollo el equipo intente comprender los requisitos funcionales (qué debe hacer el sistema), los requisitos no funcionales (cómo debe ser el sistema: seguro, fácil de usar) y las reglas de negocio (por ejemplo, desplegar los martes, autorizar el uso sólo tras la identificación federal del usuario), para entender qué tareas deben realizarse en su ejecución. Dentro de la ingeniería de software se habla mucho de requisitos funcionales y no funcionales, dejando fuera las reglas de negocio, sucede que en el día a día nos damos cuenta que no considerar las reglas de negocio puede significar un obstáculo importante para el proyecto, y muchas veces resulta en retrabajo.
Una vez identificadas las tareas, el equipo comienza a estimar las tareas a realizar, para ello el equipo puede volver a utilizar puntos de estimación, con técnicas como la planificación de póquer, o puede utilizar el Tiempo Ideal, que no es más que el tiempo ideal para realizar una tarea si no hubiera interrupción de ningún tipo.
El último proceso de este ritual es la creación del Sprint propiamente dicho, esto significa identificar cuándo se realizará cada entrega, qué roles se deben desempeñar durante el sprint, en qué historias se trabajará e identificar las áreas que debe abordar el equipo del proyecto. También es interesante que el equipo tenga un objetivo claro establecido para ese sprint, y que en la medida de lo posible el sprint sea capaz de entregar un Producto Mínimo Viable, para garantizar que el valor del proyecto se empieza a realizar ya en las primeras entregas.
Comments