Agile Inception
Cuando nos enfrentamos a una idea de negocio o proyecto, tendemos a pedir un fecha de entrega con dos o tres requisitos a medio definir; es ahí cuando debemos proponer un Agile Inception, que no es nada mas que dos sesiones en la que participan los stakeholders o interesados del proyecto para dar foco a la iniciativa. La primera de ellas es el Impact mapping y la segunda un User story map.
Un agile inception garantiza que todo lo que se hace en el proyecto tiene un objetivo claro y genera un impacto positivo.
Impact mapping
La primera de ellas es el Impact mapping, en esta sesión de no mas de 4 horas, el equipo de interesados debe definir en orden estricto:
- ¿Para qué es el proyecto? Esta definición debe ser especifica (corta y clara de lo que se quiere), medible (saber cuando va a terminar el proyecto), alcanzable, relevante (importancia) y temporal (Tiempo aproximado para hacer la entrega). (Meta tipo SMART).
- ¿A quiénes va a impactar?. Hay dos tipos de personas; a las que se va a impactar y las que van a impactar sobre el proyecto(las que actúan).
- ¿Cuáles son los impactos del proyecto? Relación de impactos positivos y negativos (Riesgos). Aquí se deben definir aquellos impactos negativos o riesgos, con el fin de determinar planes de mitigación sobre los mismos.
- ¿Qué se va a hacer en el proyecto? (Construcción del product backlog). La respuesta de esta pregunta listará los «qué» del proyecto.
User story map
La segunda sesión corresponde al vision story map o user story map, que es una sesión en la cual se estructura el backlog en dos dimensiones, la primera de ellas tiene cada una de las funcionalidades esperadas y la segunda el release en el cual será entregada.
La forma de llevar esta sesión se da en 3 pasos:
- Desglosar: A partir de los «qué» identificados en el impact mapping, listamos todas las funcionalidades definidas. (product backlog). Cada una de las funcionalidades se deben desglosar en historias de usuario.
- Priorizar: Mi recomendación para este proceso es el método MoSCoW (Entérate mas ) en el cual se puede definir la importancia de cada una de las historias de usuario así: M (Must) que tiene que estar, S (Should) que debería estar, C (Could) que podría estar y W (WON’T) que queda descartado por el momento; con esta técnica el equipo de trabajo podrá determinar en conjunto las prioridades de cada una de las funcionalidades solicitadas.
- Definir versiones: Con base en la priorización, se determinará el MVP (Mínimo producto viable) que estará conformado por una o mas de las funcionalidades definidas por el equipo como MUST, seguida a esta las SHOULD y COULD con las cuales se conformaran los release iniciando en el release 1.
Ejemplo práctico.
Aquí les dejo un ejemplo práctico del resultado de las dos sesiones explicadas anteriormente, que es lo que se conoce en el mundo ágil como un release plan.
Este ejemplo lo he tomado del blog winnipeg.
Conclusiones
En nuestro día a día de gestión de proyectos, nos piden agilidad para definir, implementar y poner en producción mil proyectos, pero como se dice en el argot popular «mi urgencia es tu urgencia», si lo quieres rápido y completo, necesito que me digas que quieres, como lo quieres y para cuando. La verdad que los que menos saben que quieren son las personas que nos piden hacer un proyecto, y si de desarrollo de software se trata, el caso se repite con mayor frecuencia; sin embargo nuestra responsabilidad es entender y dejar escrito en alguna parte lo que nuestro usuario Sponsor nos está pidiendo; para ello el release plan con sus dos sesiones Impact mapping y user story map son claves a la hora de determinar esos alcances que siempre nos dan dolores de cabeza por no dejarlos claros desde un inicio.
Estamos en un mundo cambiante y los negocios tienen que reinventarse todos los días para no perder participación en los mercados, por lo cual también debemos ser flexibles a la hora de tener que realizar cambios sobre nuestra planeación inicial, pero todo debe quedar escrito, con el fin de tener trazabilidad de los trabajos realizados y construir un wiki de lecciones aprendidas.