Historias de Usuario en Scrum

Siguiendo con el post: https://unpocodejava.wordpress.com/2010/01/12/libro-diseno-agil-con-tdd/

Del libro

Una historia de usuario posee similitudes con un caso de uso, salvando ciertas distancias. Por hacer una correspondencia entre historias de usuario y casos de uso, podríamos decir que el título de la historia se corresponde con el del caso de uso tradicional.

Sin embargo, la historia no pretende definir el requisito. Escribir una definición formal incurre en el peligro de la imprecisión y la malinterpretación, mientras que contarlo con ejemplos ilustrativos, transmite la idea sin complicaciones.

En ATDD cada historia de usuario contiene una lista de ejemplos que cuentan lo que el cliente quiere, con total claridad y ninguna ambig¨uedad. El enunciado de una historia es tan sólo una frase en lenguaje humano, de alrededor de cinco palabras, que resume qué es lo que

hay que hacer. Ejemplos de historias podrían ser:

Breves, concretas y algo estimables. Son el resultado de escuchar al cliente y ayudarle a resumir el requisito en una sola frase. Muy importante: Están escritas con el vocabulario del negocio del cliente, no con vocabulario técnico.

Por sí misma una historia aislada es difícil de estimar incluso con este formato.

Lo que las hace estimables y nos hace ser capaces de estimarlas cada vez mejor, es el proceso evolutivo que llamamos ágil. Esto es: a base de iterar, estimar en cada iteración y hacer restrospectiva al final de la misma, vamos refinando la habilidad de escribir historias y estimarlas.

Cada historia provoca una serie de preguntas acerca de los m´ultiples contextos en que se puede dar. Son las que naturalmente hacen los desarrolladores a los analistas de negocio o al cliente.

· ¿Qué hace el sistema si el libro que se quiere a˜nadir al carrito ya está dentro de él?

· ¿Qué sucede si se ha agotado el libro en el almacén?

· ¿Se le indica al usuario que el libro ha sido a˜nadido al carrito de la compra?

Las respuestas a estas preguntas son afirmaciones, ejemplos, los cuales transformamos en tests de aceptación. Por tanto, cada historia de usuario tiene asociados uno o varios tests de aceptación (ejemplos):

Las preguntas surgidas de una historia de usuario pueden incluso dar lugar a otras historias que pasan a engrosar el backlog o lista de requisitos: “Si el libro no está en stock, se enviará un email al usuario cuando llegue”.