¿Qué son las historias de usuario? (II)

En el post anterior vimos una introducción a las historias de usuario.  En este segundo y último post sobre historias de usuario, veremos cómo definirlas.

Para definir historias de usuario, el proceso general es la entrevista con aquellas personas que tienen claras las funcionalidades de la aplicación.

El problema principal es como estructuramos las ideas generales en ideas simples que funcionen como piezas de un lego (mejor dicho, como un mecano, dado que muchas veces las piezas sólo pueden comunicarse con otro grupo de piezas compatibles).

Para ello hay varias técnicas llamadas talleres de escritura de historias de usuario, entre ellas las siguientes:

– Se hace una lluvia de ideas para entrar en contacto. Posteriormente se categorizan las ideas y se realiza una entrevista por categoría.

– Se realiza la entrevista orientada a la aplicación. Es decir, se le pide al experto o dueño del producto que visualice el producto tal y como se lo imagina.  Empezamos por la primera pantalla, trazamos un flujo entre las diferentes pantallas y escribimos las historias de usuario por pantallas.

De hecho la metodología para organizar las historias de usuario es muy diversa y se debe tener en cuenta el estilo de comunicación de los expertos y el tipo de proyecto para poder detectar aquellas ideas clave del producto.

Sea cual sea el enfoque para concretar el tema a abordar, siempre llegaremos a la entrevista.  Algunos autores destacan las siguientes normas en cuento a la entrevista:

– Las preguntas que se deben hacer deben ser abiertas, no preguntas cuya respuesta sea un sí o no.

– Las preguntas deben ser abiertas, pero focalizadas, e independientes del contexto (muchas veces no debemos entrar en esta fase en aspectos tecnológicos, sino funcionales).

– Desde el punto de vista de diseñadores del sistema, debemos parar las siguientes actitudes de los expertos del domino:

Expertos que preguntan demasiado y se responden a ellos mismos con “se podría” mezclando capas de abstracción funcional y tecnológica. Es mejor que se involucren en el proyecto y no pregunten tanto.  Se les puede involucrar en el diseño o en el comportamiento del sistema.

Profundizar en ideas complejas o niveles de abstracción más altos que deberían ser fruto de ideas más simples y no se han profundizado.

– Se recomiendan entrevistas cortas de 20 minutos focalizadas a un tema concreto e intentar solucionar el tema en esos 20 minutos.

Al final, en un taller de escritura, deberían salir tantas historias como sean posibles.

Una vez tenemos las historias, entonces analizamos lo siguientes:

– Historias épicas: aquellas que son complejas e involucran otras historias.  Las historias épicas se deberían descomponer en historias simples.

– Historias concatenadas: son aquellas que tienen dependencias.  Si podemos, las deberíamos re-escribir en otras que fueran simples.

– Historias simples: son aquellas que cumplen las reglas INVEST que vimos en el anterior post.

Todos estos pasos los fueron los que seguimos en el grupo para definir las diferentes historias de usuario que tiene la aplicación que implementa un tratamiento contra el dolor infantil para niños.  Nos salieron alrededor de 40 historias de usuario para el primer piloto que saldrá en junio.

En el siguiente post explicaremos las diferentes tecnologías que se usan para implementar una aplicación para Smartphone de escritorio, y explicaremos cuál de ellas hemos elegido nosotros.

Hasta pronto.

Equipo técnico de la Unitat per a l’Estudi i Tractament del Dolor – Algos

Universitat Rovira i Virgili, Tarragona