historias de usuario I

Entes ágiles vivos

Primitivo Cachero (@primicachero)

 

Una historia de usuario es una representación de un requisito escrito en una o dos frases utilizando el lenguaje común del usuario. Esa es la definición de la wikipedia para una historia de usuario. Su origen se remonta a Extreme programming y han ido madurando con el tiempo, gracias a grandes agilistas como Mike Cohn.

Las historias de usuario, se entienden como un contrato. Pero desde mi punto de vista, una historia madura con el tiempo, al igual que un proyecto agile va evolucionando en el cono de incertidumbre con el tiempo, la historia también. Por tanto, ese "contrato" evoluciona y cambia, se adapta a las necesidades del cliente durante la vida agile del proyecto.

A diferencia con las epics o features, las historias de usuario (user stories) deben de ser pequeñas, para poder realizarse en poco tiempo (días o un par de semanas a lo sumo). De esta manera aportarán valor pronto, rápido y concreto al cliente y se adaptarán a sus necesidades de negocio. Porque el propósito de ellas es aportar valor de negocio a lcliente.

Si la historia se va de tiempo, a más de dos semanas, es un indicativo de que no es una historia de usuario, es más, podrán ser  varias incluso, o no tener suficiente conocimiento del problema.

Estamos acostumbrados a leer u oír que una historia debe de ser independiente, negociable, valiosa, estimable, pequeña y comprobable, pero ¿qué es todo eso?

 

Independiente

En agile estamos acostumbrados a trabajar en equipo, pero aplicando el sentido común, tratando de evitar bloqueos, dependencias entre miembros del equipo, para que el trabajo "fluya" a lo largo del sprint correctamente. Con lo cual, si conseguimos historias independientes, tanto entre sí, como independientes de miembros del equipo y de conocimiento explícito de personas, estaremos haciendo historias más robustas. Historias dependientes conducen a priorizar y planificar en función de esas dependencias, no del valor que proporcionan al cliente. Dependencias entre historias pueden hacer más difícil la tarea de estimación. Cuantas veces nos hemos encontrado ante el dilema con el cliente de "No, es que si te hacemos esta historia primero, o al mismo tiempo que esta otra, la estimación de la primera es menor". Ante dependencias, podemos realizar un agrupamiento de ambas historias en una historia más amplia, que se vuelve independiente del resto (siempre que sea viable realizarla en un sprint) o por el contrario tratar de encontrar una forma diferente de dividir las historias para romper la dependencia. Siempre trataremos de realizar estas dos acciones, y como última, la de dos estimaciones en función del orden de resolución de las historias. Pero, esta opción, debería de ser la última a contemplar cuando las anteriores nos han fallado o no hemos podido llegar a solucionar dicho problema de división.

 

En el próximo artículo continuaremos desgranando las historias de usuario negociables, valiosas y estimables. ¡Sigue leyendo!