sábado, 25 de junio de 2016

¿Cómo funciona la toma de requisitos ágil?

La pregunta se podría reformular preguntado por como funciona el flujo de refinamiento de las historias de usuario para que al equipo de desarrollo le lleguen las especificaciones con la información más reciente e incorporando todos los cambios acaecidos.

Nos basamos en una pila de producto con historias de usuario que son las utilizadas en los métodos ágiles para la especificación de requisitos, ta como describe Mike Cohn en 2004, son una descripción breve de una funcionalidad de software tal y como la percibe el usuario. Describen lo que el cliente o el usuario quiere que se implemente y se escriben con una o dos frases utilizando el lenguaje común del usuario. La primera pila de producto la podemos obtener mediante un User Story Mapping.

Las historias de usuario forman parte de la fórmula de captura de funcionalidades definida en 2001 por Ron Jeffries de las tres C's (Card - Conversation - Confirmation):
Cuadro con la técnica de las 3 C's
Cada historia de usuario debe ser limitada, esta debería poderse memorizar fácilmente y escribir sobre una tarjeta o post-it (card), ya que son una promesa de una conversación posterior. Poco antes de ser implementadas, en la reunión de refinamiento o en la de planificación de sprint, estas van acompañadas junto con los criterios de aceptación asociados de conversaciones entre el equipo de desarrollo y el Propietario del Producto. Como los cambios son bienvenidos en Agilidad, no vale la pena profundizar antes, ya que en el momento de la implementación estas pueden haber cambiado desde que fueron escritas. Los criterios de aceptación, a veces transformados en escenarios de pruebas por el equipo de desarrollo, permiten al Propietario del Producto o usuario de negocio confirmar que el equipo ha entendido y recogido correctamente los requisitos.

Esta forma ágil de administrar los requisitos de los usuario evita la necesidad de elaborar gran cantidad de documentos formales, requiere que negocio lidere el rumbo del proyecto en todo su recorrido y a la vez no requiera mucho tiempo de dedicación por sprint.

No hay comentarios:

Publicar un comentario