historias de usuario III

Entes ágiles vivos

Primitivo Cachero (@primicachero)

 

Después de lo aprendido en las dos últimas entradas sobre Historias de usuario:

Te contamos finalmente, los últimos puntos sobre cómo tienen que ser: 

Pequeñas

El tamaño de la historia importa, historias demasiado grandes o demasiado pequeñas no se pueden utilizar en la planificación. Las historias grandes como las épicas son difíciles de trabajar. La determinación final del tamaño se basa en el equipo, sus capacidades y las tecnologías utilizadas para realizarla. Una historia puede ser compuesta o compleja. La historia compuesta comprende varias historias que son visibles.

Sencillas

La historia compleja, a diferencia de compuesta, es muy grande, y no puede fácilmente ser dividida. Si hay mucha incertidumbre genera complejidad. En este caso dichas historias pueden ser divididas en una parte de investigación y otra de desarrollo.

Combinables

A veces las historias son demasiado pequeñas. Cuando el equipo dice que una historia no necesita ser escrita o estimada por ser muy pequeña existe un problema. Puede generar problemas posteriores y no estar documentada. Con lo cual dichas historias pequeñas habrá que combinarlas en historias más grandes para tener  constancia de ellas.

Comprobables

Es importante que el resultado de las pruebas demuestre que la historia fue realizada con éxito. Si la historia no puede ser comprobada, ¿Cómo puede el equipo definir cuando ha terminado la historia?. Historias que no se pueden comprobar atienden a requisitos no funcionales, tales como "El software debe ser fácil de usar". "El usuario no tiene que esperar mucho tiempo para que aparezca su pantalla de acceso".

Debemos de tratar, además, de que dichas pruebas sean automatizadas. Se puede automatizar más de lo que se creé. Cuando se desarrolla un producto incremental, las cosas cambian muy rápidamente, y algo realizado ayer puede dejar de funcionar hoy, lo que se denominan "fallos colaterales". Con esas pruebas automatizadas encontrará dicho fallo lo antes posible.

Hay una muy pequeña parte de las pruebas que no se pueden automatizar, seamos realizas, pero habremos cubierto posiblemente más del 90% de la funcionalidad de modo automático.

 

A modo de conclusión, no siempre realizar todo esto es posible, pero es una meta lean, a tratar de alcanzar, pero ante todo las historias son negociables entre usuario y equipo, y como tal han de escribirse. Deben de ser escritas por el cliente con la ayuda del equipo. En la propia historia se pueden documentar casos de prueba que demuestren su realización correcta. Si son demasiado grandes, divide, tanto historias compuestas como complejas, por el contrario, si son demasiado pequeñas, agrúpalas para que den valor al cliente. Las historias son promesas para hablar, no especificaciones detalladas. Las historias técnicas o de infraestructura, hay que describirlas como necesidades en términos de valor aportados al cliente.

 

Si te interesa todo lo relacionado con esto y las nuevas metodologías Agile, descubre nuestra QUALITY OBJECTS Agile Academy