Indice de contenidos
Historia sobre las historias de usuario
El concepto de Historia de Usuario fue introducido por primera vez en los noventa por Ron Jeffries, uno de los primeros desarrolladores en aplicar y practicar eXtreme Programming, Ron definía las historias de usuario con tres conceptos o pilares muy importantes: Card, Conversation y Confirmation. No obstante, fue Mike Cohn quién las hizo populares más adelante con su libro.
Que es una historia de usuario
Una historia de usuario es una narración/storytelling/explicación informal del comportamiento del usuario con el producto o funcionalidad. Su objetivo es centrar una conversación de un modo colaborativo en el usuario del producto. Como decíamos antes, Ron Jeffries definía las historias de usuario con tres pilares fundamentales (o las 3’C): Card, Conversation y Confirmation, ¿Pero qué significa cada una de estas cosas? veámoslo:
Card o tarjeta en una historia de usuario
La historia de usuario comienza con una tarjeta (Card), que no es un documento detallado ni un documento de requisitos sino un símbolo/token/reminder que representa una necesidad. Contiene la información justa y suficiente para identificar y recordar esa necesidad durante las conversaciones.
Conversation o conversación en una historia de usuario
Aquí es donde se despliega el verdadero valor de las historias de usuario. En Scrum por ejemplo, los desarrolladores participan en conversaciones continuas con los Stakeholders, y Product Owner sobre las funcionalidades del producto, a menudo utilizando una pizarra física o digital (no es relevante). Estas conversaciones son cruciales durante etapas o eventos como la Release Planning, Sprint Review, Refinamiento, etc.
Confirmation o confirmación en una historia de usuario
Después de las conversaciones, los desarrolladores implementan una pequeña parte de la funcionalidad, usualmente en uno o dos días, y luego la presentan al cliente para su confirmación. Este ciclo rápido asegura que el desarrollo se alinee estrechamente con las necesidades y expectativas del cliente. Esta parte de la confirmación a menudo suele estar creada previamente como criterios de aceptación de la historia de usuario, utilizando por ejemplo, el concepto o enfoque de BDD (Behavior Driven Development o Desarrollo dirigido por comportamiento), incluso automatizar estos criterios de aceptación utilizando ATDD. De tal manera que se puede ir confirmando las Historias de Usuarios conforme el equipo va terminandolas.
Ejemplo de buenas historias de usuario
Para ello vamos a utilizar un formato muy popular para crear las historias de usuario:
As…
I want…
So that…
Ejemplo 1
Contexto: un visitante de un sitio web
Como visitante del sitio, quiero leer un nuevo artículo en la portada una vez a la semana para estar al día de los últimos acontecimientos.
Ejemplo 2
Contexto: Un sitio web para cursos online
Como Trainer, quiero recibir periódicamente un resumen de ventas con la frecuencia que elijo para saber cómo van mis cursos.
Mike cohn hizo como 200 ejemplos en pdf por si se quiere consultar y ampliar: Ejemplos de historias de usuario
No hay que ligarse para siempre a este formato, se puede utilizar este formato como se puede utilizar otro formato. Lo importante son las 3C’s, no en el formato en si.
Mitos y anti-patrones de historias de usuarios
Todas las historias de usuario deben de tener el formato: como…quiero…para…
Según Ron, el típico formato de: como…quiero…para… no tiene por que ser una historia de usuario, de hecho un Item del Backlog con ese formato, sin los tres elementos fundamentales: Tarjeta, Conversación y Confirmación (3 C’s), no es una historia de usuario. De hecho, entre los tres elementos, los más importantes son: la conversación y la confirmación.
En el Product Backlog en Scrum solo hay historias de usuario
La gestión de un Product Backlog en Scrum no implica que todos los Items (Product Backlog Items) deban de ser una historia de usuario. En el Product Backlog pueden haber Bugs, funcionalidades pequeñas, funcionalidades grandes, tareas no funcionales, mejoras técnicas, experimentos o spikes, etc.
Este típico error suele suceder cuando se piensa que las historias de usuario son requisitos del sistema (técnico y funcional) 🤷
¿Existen las historias técnicas?
La respuesta de un buen Scrum Master es….: ¡Depende! 😜 ¿Y de qué dependen? El propósito del producto, es para dar soluciones a Developers? Si es que si, entonces tiene todo el sentido del mundo, ejemplo: un equipo que desarrolla la nueva versión de Visual Code, Eclipse, IntelliJ, la API de Google Maps, etc.
Las historias de usuario son narrativas y Storytelling sobre el comportamiento del usuario, no son especificaciones técnicas de un producto.
Si existen historias técnicas en el Backlog, es una muestra de una disfunción en la estructura del equipo, así que se puede plantear la siguiente pregunta: ¿Tenemos todas las habilidades necesarias en el equipo? La respuesta a esta pregunta nos puede llevar a crear el equipo de desarrollo perfecto
Si te ha gustado este articulo compártelo y déjanos tu valoración, sería de gran ayuda.
