User Stories – Entendiéndolas para poder usarlas lo mejor posible

Este es el primer post de una serie que voy a escribir sobre User Stories (Historias de Usuario) con la intención de entender bien qué son (y qué no), por qué usarlas, cómo usarlas, cuándo trabajar en ellas y por último como podemos practicar para ser mejores escribiéndolas.

Elegí este tema como primer serie de mi blog ya que creo que muchos equipos que empiezan a trabajar con frameworks de desarrollo de software ágil (más conocido como Agile ☺ ) utilizan User Stories como elementos de su Backlog (o por lo menos así les llaman) sin antes entender bien qué son y por qué se utilizan. Supongo que el hecho de que las User Stories estén tan ampliamente usadas en los equipos ágiles hace que por facilidad o incluso falta de tiempo un equipo adopte esta práctica sin cuestionarse mucho el por qué. Pero bueno, no estoy acá para juzgar a los equipos, así que mejor me concentro en intentar ayudar con este post.

Un equipo que no entienda qué son las User Stories y por qué las utilizan, sino que las utilicen  (como dicen acá en España) “a salto de mata”, está teniendo en su backlog una especie de “deuda técnica”1 que en forma de intereses va pagando con no poder rendir al máximo de sus capacidades. En estos casos poniendo el foco de mejora del equipo en mejorar las User Stories seguramente ayudaría mucho a conseguir un mejor desarrollo ágil.

En los siguientes posts de esta serie voy a intentar cubrir los siguientes puntos.

 

¿Por qué User Stories?

Además de entender qué son, también es muy importante entender por qué las User Stories son así y por qué utilizarlas. Qué objetivo estamos buscando al usarlas y cómo se adaptan bien a un desarrollo ágil.

Para esto podemos ver cómo una User Story se enfoca en el quién, qué y para qué de una funcionalidad/requerimiento, dejando el cómo para el equipo. También ver cómo esta práctica favorece la colaboración, evitando que se asuman cosas incorrectamente y se adapta muy bien a un desarrollo ágil donde se necesita profundizar en los requerimientos solo lo justo y necesario en cada momento.

¿Qué son?

Intentando profundizar en los conceptos de “promesa de futura conversación”, Card Conversation Confirmation, INVEST, etc. Podemos entender bien qué son las User Stories y cuáles son sus características, para a partir de ahí poder tener un ojo mas critico y poder entender el por qué (o por qué no) utilizarlas, el cómo, en que momentos y hasta que nivel de detalle trabajar en ellas.

¿Cómo escribir User Stories?

Ahora sí ya estamos listos para empezar a escribir buenas User Stories! Así que hablemos un poco de cómo escribirlas y refinarlas.

Para esto podemos primero entender bien como escribir las dos C’s que se escriben (Card y Confirmation) y como usar la otra C (Conversation) para ir refinando. Después aprender técnicas para crearlas y para dividirlas.

¿Cuándo se escriben?

Lo último que creo que necesitamos entender es cómo es el proceso de escribir las User Stories a lo largo de un desarrollo ágil. ¿Cómo y cuándo obtener la primer gran lista de User Stories? ¿Hasta qué nivel de detalle conviene llegar y para cuantas Stories del backlog? ¿En qué momentos conviene trabajar en el refinamiento?

¡A practicar!

Practicar, practicar y practicar. Esa es la clave para mejorar y ser bueno en cualquier cosa que queramos hacer. ¡Y las User Stories no son la excepción!

Dentro del desarrollo de software las Katas son una práctica bastante expandida y para las User Stories también se puede aplicar para practicar cómo escribirlas y cómo dividirlas. Esto nos ayuda a poder inspeccionar y adaptar nuestra forma de escribirlas para mejorarlas continuamente.

 

Links a los siguientes posts de la serie:

  1. Por qué las User Stories en un contexto ágil
  2. Qué son las User Stories
  3. ¿Cómo escribir User Stories?
* Por costumbre no traduzco los nombres de artefactos y elementos como User Stories, Product Backlog, etc. Espero que no sea una molestia para el lector. Si es algo que te molesta contámelo!
1 La definición de deuda técnica no aplica en este contexto pero la utilizo como analogía para explicar la idea de que hay algo ahí que se podría hacer mejor  
Anuncios

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