Las historias de usuario son una herramienta que se originó en la Programación Extrema y se han convertido en la forma de facto en que los equipos ágiles documentan y recogen sus requisitos. Hay mucho escrito sobre historias de usuario (enlace, enlace, enlace), así que sólo voy a hablar de lo que considero importante para escribir buenas historias ya que veo un MONTÓN de historias realmente malas por ahí hoy en día.
Para los que no lo sepan, las historias son un artefacto ligero que nos permite tanto capturar las necesidades del negocio COMO planificar el trabajo. Normalmente se escriben en fichas (sí… pequeñas tarjetas de 3×5 o 4×6) en el lenguaje del negocio o del cliente. Con las historias de usuario, sólo escribimos lo suficiente para capturar las necesidades del usuario y no más. Tendemos a ver las historias no como una especificación completa de los requisitos, sino como marcadores de posición para las conversaciones posteriores entre los desarrolladores y el negocio.
Cuando se utiliza correctamente, la falta de detalle de una historia de usuario nos proporciona una gran utilidad – podemos utilizar el mismo documento para hablar de un requisito de alto nivel, ampliar los detalles de implementación y saltar de nuevo, todo en el transcurso de unas pocas frases. Una vez que hayamos terminado de hablar de los requisitos, podemos considerar el riesgo, identificar las dependencias y crear un plan de proyecto sin tener que dejar nunca la ficha. ¡¡¡Vaya!!! No conozco ningún otro artefacto de requisitos que nos permita tal utilidad.
A lo largo de los años, las personas que realmente tienen éxito con las historias han establecido algunos puntos comunes que se encuentran en todas las historias:
- Rol: ¿quién, o qué, va a utilizar esta característica?
- Característica (o capacidad): ¿qué va a entregar, o añadir, el equipo después de haber terminado su trabajo?
- Valor: ¿por qué el negocio quiere esta característica? Qué impacto tendrá para el negocio?
- Criterios de aceptación: ¿cómo sabremos si esta característica está hecha?
- Estimación: ¿cuánto cree el Equipo que costará esta característica?
IMO, para que una historia se considere completa tiene que tener TODAS las características descritas anteriormente. Me parece que cuando la gente tiene problemas con la definición de todas las características, las historias no son lo que yo llamo maduras, es decir, no han sido pensadas lo suficientemente bien como para ser utilizables por el Equipo. Además de estas características, las historias también deben seguir los criterios de INVEST (este gran artículo de J.B. Rainsberger habla también de INVEST).
Mike Cohn ha escrito un gran libro sobre historias de usuario. Por desgracia, a pesar de todas las bondades del libro, la gente parece haberse centrado en la única basura del libro: la plantilla de historias de usuario. En su libro, Mike ofrece una plantilla que algunos equipos han encontrado útil para escribir historias y, a partir de ahí, esta plantilla ha sido la fuente de tantas historias malas que no voy a darle más tinta (o bits). Lo que me molesta de la plantilla es que hace que la gente deje de pensar mientras rellena mecánicamente el rol, la característica y el valor y omite los criterios de aceptación y la estimación (presumiblemente porque no están en la plantilla). Cuando veo que la gente tiene problemas con las historias, es porque están tratando de encajar su negocio en alguna plantilla que ayudó a algún equipo sin nombre (que probablemente ya no utiliza esta plantilla) hace cinco o seis años y -sorpresa- no se ajusta a donde están ahora.
Hay un proceso de pensamiento que debe ocurrir antes de escribir una sola historia. Los pasos que suelo ver que completan las personas que tienen éxito escribiendo historias se enumeran a continuación. Por favor, tenga en cuenta, mientras que estos pasos son lineales en mi post, uno puede saltar hacia atrás, hacia adelante y saltar alrededor como tiene sentido. El objetivo es haber respondido a estas preguntas en el momento en que haya terminado su exploración de historias de usuario.
- ¿Cuáles son los roles (o usuarios) que utilizarán su sistema?
- ¿Cuáles son sus necesidades? Cómo les ayuda el producto a conseguirlo?
- ¿Qué características (o capacidades) quiere proporcionar a estos roles?
- ¿Por qué estas características son valiosas para el negocio? Qué tipo de resultados empresariales podemos esperar de estas características?
- ¿Cuáles son las prioridades de estas características? ¿Hicimos una promesa de entregar algunas ya?
- ¿Cómo sabrías si estas características están hechas?
Por último, la gente tiene una tendencia a querer escribir un montón de detalles en el frente de la tarjeta de historia. Tengo dos sugerencias para estas personas. En primer lugar, utilizar tarjetas más pequeñas – realmente. Las historias de usuario NO son documentos de especificaciones o requisitos. Son sólo fichas que capturan las necesidades del usuario y recuerdan que tenemos que capturar esos detalles de implementación más tarde. Si tratas de meter más y más en una ficha, puede ser señal de que necesitas especificaciones o algún tipo de documentación de diseño además de las historias de usuario. En segundo lugar, los tipos de detalles que la gente está tratando de escribir son en realidad los criterios de aceptación. Al empujar esos detalles en los casos de prueba, mantenemos la historia en el lenguaje del negocio y mantenemos el enfoque en la característica y el valor que su equipo está proporcionando.