La búsqueda constante de ideas hace que los Product Managers se enfoquen mucho más en el plano estratégico y de negocio que en el plano de especificación técnica, y la figura del "analista" que escribe especificaciones puro y duro tiende a sustituirse/especializarse por/en expertos del negocio.
La velocidad por encima de la mantenibilidad.
Para conseguir la velocidad necesaria, hay que evitar que desarrollo y testing se queden bloqueados o tomen decisiones poco alineadas con el negocio.
La falta de documentación detallada complica tanto el desarrollo como el testing, pero es sobretodo testing quien se ve afectado desde el día 0 en los modelos ágiles. Lo ideal es comenzar el diseño de las pruebas a la vez que desarrollo, y mientras éstos están lidiando con resolver los problemas técnicos de alto nivel o el diseño de clases, el diseño de test cases necesita de requisitos y sentencias precisos.
Los criterios de aceptación
Es por eso que la tradicional fase de revisión de requisitos se produce en el momento de diseño del plan de pruebas, y más concretamente en la definición de los criterios de aceptación. Así el workflow sería:
- Especificación de historias - PM
- Estimación y product Planning - PM+DEV+QA
- Corrección / revisión de alto nivel de las historias - PM
- Establecimiento (en algunos casos revisión) de los criterios de aceptación - QA
- Demo / verificación de los criterios
Con lo que la documentación no se itera más que en la revisión necesaria para hacer la estimación gruesa y posteriormente en los criterios de aceptación.
Si los criterios están claros, y son unívocos, tanto desarrollo como testing podrán trabajar durante todo el sprint y PM podrá trabajar en la siguiente idea.
No hay comentarios:
Publicar un comentario