Supongamos una tarjeta con la siguiente historia de usuario:
Estadísticas en CSV
Como administrador quiero descargar las visitas a las páginas en formato CSV, para poder graficarlas en Excel.
Estimación: 2
¿Qué está mal en esta historia? Parecería tener todo lo necesario: a) un título corto, b) un tamaño (en este caso, 2), y c) una historia bien escrita usando el formato estándar "Como... quiero... para...". Entonces, ¿qué está mal? ¡Nada! Bueno, casi nada. La tarjeta de la historia de usuario es el punto inicial, pero no es suficiente por si misma.
Varios equipos ágiles y de Scrum suelen empezar creyendo que las tarjetas de historia de usuario contienen toda la información que se necesita para crear una pieza de software de alta calidad. No quiero ser grosero, pero... ¡es estúpido! Parecería ser un poquito ambicioso pensar que una única oración puede describir por completo algo que podría llevar días de análisis, diseño, codificación y testing. No, dejenme decirlo de nuevo. Es más que un poquito ambicioso: es imposible. Entonces, les pregunto de nuevo, ¿qué está mal en esa historia?
Y otra vez les voy a responder que no hay nada mal, pero que es el punto inicial. Muchas personas conocen el concepto de INVEST para las historias de usuario, que es un acrónimo que nos guía a crear buenas historias de usuario. ¡Pero eso no es suficiente! Si leen literatura ágil eventualmente van a encontrar la frase "Una historia de usuario es una invitación a una conversación". Y esta conversación es vital para el éxito. Una conversación nos permite más detalles que una única oración. Puede clarificar muchos aspectos de la historia de usuario. Avanzando más, también necesitamos confirmar que la historia de usuario está completa.
Uniendo todo esto, terminamos con las partes de una buena historia de usuario: Tarjeta, Conversación, Confirmación. Los equipos Ágiles y de Scrum necesitan recordar que una tarjeta es el punto de inicio. Lleva a conversaciones en donde se dan más detalles y ocurren negociaciones (la N del modelo INVEST). Todo esto lleva a la confirmación en la forma de tests (la T del modelo INVEST). Una buena tarjeta de historia debería terminar completada (en el anverso, por ejemplo) con los resultados de la conversación(es) y las pruebas de confirmación.
La próxima vez que vean una tarjeta de historia de usuario no se pregunten si deberían tener una conversación. En cambio, asuman que necesitan tener una conversación, y organícenla! Vayan con el Dueño del Producto o el cliente o el usuario y pregúntele sobre la historia. Tomen notas. De hecho, es incluso mejor que en la conversación participe un desarrollador, un tester y una persona del producto. Las llamo conversaciones de 3 cabezas. Esto nos permite acordar lo mismo, de manera de no tener desacuerdos sobre lo que realmente significaba la historia. En especial evita una de mis conversaciones favoritas, que ocurre cuando el tester y el desarrollador discuten sobre lo que significaba un requerimiento después de que el código esté escrito.
Si están usando alguna herramienta de gestión ágil en vez de tarjetas físicas, registren las decisiones de las conversaciones y las pruebas de confirmación en alguno de los campos de la herramienta. Tienen que asegurarse de registrar este información en caso que alguna persona no haya podido participar en las conversación.
Intenten usar el concepto de Tarjeta, Conversación, Confirmación. Estoy seguro que verán mejores resultados.
