Historias de Usuario: dos aproximaciones distintas (I)

¿Qué pasa si a alguien que usa Scrum le preguntamos la diferencia entre PBI y User Story? Según mi experiencia, hay quien preguntará qué es un PBI, afirmando que en su equipo usan User Stories. Y si rascamos un poco más podemos preguntar algo así como… ¿y cómo creáis vuestras User Stories?, a lo que fácilmente alguien nos responderá: -¡Muy sencillo! Hacemos una para la parte visual, otra para la capa de servicio y otra para el acceso a base de datos. -. Y algo así evidencia 2 cosas a simple vista, como un buen bofetón en cada mejilla: no hay Product Owner en ese equipo Scrum y nadie sabe lo que es una User Story y la potencia que nos ofrece.

En este primer artículo hablaré sobre qué es una historia de usuario y cómo nos ayuda a hacer mejor software. No voy a hablar sobre INVEST, las tres C ni nada similar, que ya hay mucha gente que ha escrito sobre el tema y mucho mejor que yo. Aquí voy a hablar de algo mucho más sencillo, de la esencia y los megapoderes de las historias de usuario. En el siguiente, plantearé dos formas distintas de escribirlas (flujo completo vs incremento funcional de cada parte), cada cual con sus ventajas y sus inconvenientes.

¿Qué es un PBI y qué una User Story?

PBI viene de Product Backlog Item, y nos indica, simplemente, que es trabajo que está aún sin hacer. Es algo que nos indica la funcionalidad o incremento de producto que está aún por satisfacer. Sin embargo, una User Story es un molde que nos permite escribir ese trabajo que está sin hacer desde el punto de vista del usuario final del producto, es decir, de quien está en disposición de pagar o no por él. Pero, además de eso, nos ofrece una cantidad enorme de información que no siempre somos capaces de ver.

Las historias de usuario pueden tener distintas estructuras en su composición, siendo la más usada la siguiente:

Como <rol o persona>
Quiero <funcionalidad>
Porque <necesidad actual>

Estas tres partes son esenciales, tanto porque nos indican cuál es el siguiente incremento de producto o funcionalidad a desarrollar (Quiero), quién espero que consuma el producto (Rol o persona) y cuál es la necesidad que vamos a satisfacer (Por qué). 

¿Por qué usar User Stories?

Existen muchas formas para especificar cómo debe ser un producto. En este caso, tenemos a nuestra disposición una que nos ayuda a definir qué y nos aporta mucha información contextual: por qué.

Esencia

Desde este prisma, conseguimos identificar nuestro target o público objetivo, una necesidad que tiene y describir cómo la va a satisfacer nuestro producto. Por tanto, estamos poniendo en el centro de la concepción de producto a nuestros potenciales consumidores, aquellos que estarán dispuestos a pagar por comprar o consumir nuestro producto. Y sí, me refiero a esos que, por norma general, son los que nos dan de comer.

Ahora es cuando visualizamos el software que desarrollamos cada día, lo vemos funcionar, nos imaginamos a nuestros clientes usándolo… y claro, seguro que están diciendo… ¡cómo me gusta este nuevo acceso a base de datos! ¡Shut up and take my money!

Contexto

A través de las historias de usuario, además de describir qué cosa nueva va a ofrecer nuestro producto, obtenemos muchísimo contexto, que queda representado en la persona a quien se dirige esta nueva funcionalidad y en la necesidad que vamos a cubrir. Al fin y al cabo, el ser humano se mueve por necesidades, que muchas veces son cambiantes, pero al fin y al cabo, necesidades. No es lo mismo adquirir un producto porque me aburro y necesito realizar una compra compulsiva que adquirir ese mismo producto porque es una herramienta de trabajo. De la misma forma, el proceso de compra en ambos casos tampoco será igual. Así mismo, no es lo mismo que la compra la realice una persona que apenas tiene tiempo para hacerlo que otra que no tiene nada mejor que hacer.

Los detalles

Pero claro, en todo esto nos falta algo: ¿dónde van el resto de detalles acerca de la funcionalidad? ¿Cómo puedo validar que una funcionalidad cumple las expectativas de quien me la ha pedido? Bien, para todo esto existe lo que se llama criterios de aceptación. En este grupo introducimos todas las reglas de negocio que afecten a la funcionalidad a desarrollar, así como cualquier otra cuestión que sea susceptible de ser revisada.

Para escribir estos criterios de aceptación, siempre animo a los Product Owners a que se vean revisando esa funcionalidad y escriban qué están verificando.

¿Qué no es una User Story?

Podría resumir este punto con la siguiente frase: no es una User Story cualquier cosa que escriba un técnico (palabra de técnico). Las personas que tenemos perfil técnico estamos habituadas a dividir los problemas grandes en problemas más pequeños de una manera determinada, atendiendo a una serie de patrones arquitectónicos, no funcionales, y supone un grandísimo esfuerzo evitarlo. Lo que sí podemos es identificar cierta literatura sospechosa:

  • Contiene lenguaje técnico.
  • Entiende de capas arquitectónicas.
  • Forma parte de una serie: Funcionalidad Parte 1, Funcionalidad Parte 2…

¿Cómo escribimos User Stories?

Esto es lo que voy a tratar en los siguientes artículos. Vamos a explorar dos posibilidades distintas, una de ellas representada por el modelo que nos propone Jeff Patton con su User Story Mapping y la otra por cubrir un flujo completo de la aplicación, iterando sobre las zonas sensibles.

Anuncios

Acerca de juanmagomez

Acerca de mí tengo un teléfono, mi portátil, el ipad y esas cosas.

Publicado el agosto 12, 2013 en Agile, Desarrollo de Software, Scrum. Añade a favoritos el enlace permanente. 2 comentarios.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: