Historias de usuario lo mejor para entregar valor a nuestros clientes

Que es una historia de usuario ?

1. Tarjeta
2. Conversacion
3. Confirmación

Estos tres componentes son una trinidad inseparable. Elimine cualquiera de ellos, y el valor se pierde de inmediato . Examinemos estos componentes para entender por qué.

La tarjeta

La tarjeta es la primera representación física de la historia del usuario. Como dije anteriormente, la tarjeta suele ser su índice promedio. Su pequeño tamaño es intencional. Estamos evitando la tentación de documentar exhaustivamente el requisito . Una definición de historia típica será solo una oración:

"Como gerente de laboratorio, debería poder filtrar una lista de reactivos para poder localizar fácilmente los que necesito usar".

También te puede interesar: La tarjeta no es una historia de usuario

Notarás este mismo patrón en muchas historias de usuarios. Este patrón es tan frecuente que ha heredado su propio nombre, "Role-Goal-Motivation". Hablaremos sobre los roles en un artículo posterior. Por ahora me gustaría centrarme en el objetivo y la motivación.

El objetivo es "lo que tengo que hacer". La motivación es "por qué tengo que hacerlo". El porqué representa el VALOR que brindará esta historia en particular. Siempre trato de asegurarme de que nuestras historias estén representadas de esta manera para que no nos olvidemos de la parte del valor .

De hecho, evitar el olvido es el valor principal proporcionado por la tarjeta. No estamos tratando de documentar todo. Solo estamos creando lo que Jeffries llama "una ficha". Incluso podría referirse a él como un kanban del mundo delgado. Su propósito principal es recordarnos que tengamos esas conversaciones .

La conversación

La conversación es donde ocurre la captura de valor real . Es en las conversaciones cara a cara regulares entre los clientes y los desarrolladores que cada participante adquiere una comprensión común de lo que se trata un requisito particular.

Estas conversaciones tienen lugar varias veces en el transcurso del desarrollo. Inicialmente ocurrirán cuando se defina la historia y se cree la tarjeta. Volverán a ocurrir cuando llegue el momento de estimar y programar la historia para su implementación. Deben ocurrir con frecuencia en el transcurso de la iteración en la que se implementa una historia determinada. Ocurrirán una vez más cuando la historia se "complete" y las nuevas capacidades del software se demuestren por primera vez.

Cada una de estas conversaciones resulta en el intercambio de "pensamientos, opiniones y sentimientos" con respecto al valor que debe agregarse. Estas conversaciones son el corazón de cómo mitigamos los problemas con las especificaciones de los requisitos de software.

Debido a que nuestras conversaciones nunca son inamovibles, ya que no existe un proceso de control de cambios, podemos responder de manera eficiente y efectiva a nuestra comprensión cambiante de la mejor manera de entregar valor . Debido a que no intentamos documentar exhaustivamente nuestra comprensión del valor requerido, podemos permitir que nuestra comprensión evolucione a lo largo del diseño y la implementación del software . Debido a que estas conversaciones ocurren continuamente en lugar de por adelantado, no hay demoras entre la elaboración de los detalles y la implementación de esos detalles .

Nuestro problema de cambio de contexto ha sido eliminado.

La confirmación

Las conversaciones en sí mismas, sin embargo, no son suficientes. ¿Cómo sabemos cuándo hemos terminado? El último componente crucial de la historia es la confirmación o "prueba de aceptación".

Las pruebas de aceptación son pruebas automatizadas que documentan de manera maleable nuestra mejor comprensión actual de cómo se entregará el valor para una historia dada. Deben ser entendibles tanto por el cliente como por el desarrollador. El aumento en la disponibilidad de herramientas de desarrollo impulsado por el comportamiento , como Cucumber,  proporciona un medio excelente para crear pruebas de aceptación.

Debido a que estas pruebas son maleables, se pueden cambiar fácilmente a medida que ocurren conversaciones adicionales sobre la historia y a medida que el software evoluciona. Debido a que son automatizados y ejecutables, podemos decir fácilmente en cualquier momento dado si el software cumple con nuestra mejor comprensión actual de lo que requiere una historia dada.

No hay riesgo de que el software y los "requisitos" se desincronicen siempre y cuando estas pruebas se ejecuten de manera regular . Si es posible, esto debería suceder cada vez que se confirme un nuevo código en el repositorio de origen.

Resumen

El desarrollo de software se trata principalmente de entregar valor a nuestros clientes . Dado que ese es el caso, deberíamos estar utilizando las mejores herramientas disponibles para garantizar que estamos entregando continuamente el valor que nuestros clientes esperan. Espero que a través de este artículo haya podido arrojar algo de luz sobre por qué las historias de los usuarios son una excelente herramienta para lograr la entrega de valor.

Fuente:  https://dzone.com/articles/use-stories-deliver?edition=513292&utm_source=Weekly%20Digest&utm_medium=email&utm_campaign=Weekly%20Digest%202019-08-07