¿Cuántas veces nos asignan proyectos en donde desde un principio se quiere tener una primera versión operativa del producto con muchas funcionalidades (no todas, pero demasiadas)?
Lo más razonable debería ser que, la primera versión operativa tenga el menor número de funcionalidades posibles y necesarias, hasta podríamos decir que la línea a seguir puede ser identificar el caso de uso más representativo que tenga el end-to-end del requerimiento para trabajar sobre él.
Hay que buscar el pragmatismo y la simplicidad aún a costa de tener una versión que tal vez no termine de satisfacer completamente al usuario.
A partir de esa versión, y con el feed-back de nuestro cliente, seguiremos a una próxima iteración para evolucionar el producto, siempre con la simplicidad como referencia.
¿Cuál es la razón de esta estrategia?
Porque es más sencillo llegar así hacia una solución más compleja, gracias al feedback obtenido por los usuarios y por el aprendizaje que se va obteniendo a todos los niveles mientras se desarrolla el producto y también porque en el caso de descubrir que el enfoque no es adecuado se ha desperdiciado menos esfuerzo en tareas que se podían haber evitado.
Indudablemente si nos ponemos a pensar, para el QA es muy importante esta estrategia ya que nos permitirá evolucionar en todo sentido dentro del proyecto, no solo adquiriendo el conocimiento funcional y/o técnico necesario, sino que además, obtendremos una cobertura de prueba alineada a los requisitos del usuario.
Posiblemente tengamos un poco más de trabajo, no lo sé, pero vale la pena, de eso estoy seguro.
Fuente de Inspiración:
http://wp.me/ppBOQ-40B
