Las historias de usuario son...
Y ahí suelen empezar los divagues. Es dificil escribir buenas historias de usuario, sin perder la esencia y el sentido del para qué las escribimos. Y para quienes recién empiezan, es un tema importante que puede resultar complejo. Veamos si podemos dar el puntapié inicial para pensar historias de usuario.
Así que vamos de nuevo.
Las historias de usuario se usan para capturar la esencia del valor de negocio de un sistema, y están escritas en un lenguaje cotidiano. Por ejemplo:
Como enfermera necesito cambiar mi ubicación predeterminada, para visualizar mis datos preferidos cuando ingreso en la aplicación de Enfermería.
Y de ahí podemos desprender el formato básico de una historia de usuario:
Como [rol] quiero [característica] para [valor de negocio]
La enfermera es el usuario que utilizará la aplicación de Enfermería. Ella necesita poder configurar su ubicación predeterminada para no tener que perder tiempo en seleccionar una ubicación cada vez que ingresa a la aplicación. El valor de negocio aquí es que no perderá tiempo en hacer esto y en cambio podrá trabajar más rápido sin odiar al software por no ser amigable :)
Dependiendo qué tanto lleven escribiendo historias de usuario, pueden que todavía no hayan descubierto un factor clave: los usuarios se meten en el medio. No saben lo que quieren, e igualmente te lo van a pedir. Y lo vas a odiar. No los ignores. Sin importar cómo se presenten, debemos abordarlos con la mente abierta para encontrar la necesidad real. Si piden un botón o algún campo para ingresar un número, debemos determinar porqué lo necesitan. Si sólo lo quieren porque "queda bonito" o por algún valor insignificante que a) deberá retocarse el resto del sistema, o b) lleva mucho tiempo hacerlo, probablemente debamos ver si realmente lo necesita (a largo plazo van a quejarse por cuánto tiempo llevamos desarrollando el cambio, y ahí vamos a responderle con un "vos querías ese botón", y nadie va a estar muy contento).
Debemos averiguar lo que el usuario quiere, que propósito sirve, y si le va a servir para el resto de las personas que usan el software. No escribimos código para los casos frontera, escribimos software que funcione en los casos frontera.
El modelo INVEST
El modelo INVEST es la clave para pensar y escribir buenas historias de usuario. Las historias deben ser Independientes, Negociables, Valiosas, Estimables, Pequeñas y Testeables.
- Independiente - una historia debería ser independiente de otras (lo más posible). Las dependencias entre las historias hace que sea más dificil planificar, priorizar y estimar. A menudo, se puede reducir las dependencias haciendo una combinación de historias, o partiendo historias de forma diferente.
- Negociable - una historia de usuario es negociable. La "tarjeta" de la historia es tan sólo una descripción corta que no incluye detalles. Los detalles se trabajan durante la etapa de "Conversación". Una tarjeta con demasiados detalles limita la conversación con el cliente.
- Valiosa - cada historia tiene que tener valor para el cliente (para el usuario o para el comprador). Una forma muy buena de generar historias valiosas es hacer que el cliente las escriba. Una vez que el cliente se de cuenta que la historia no es un contrato y es negociable, van a sentirse mucho más cómodos para escribir historias.
- Estimable - los desarrolladores necesitan poder estimar una historia de usuario para permitir que se pueda priorizar y planificar la historia. Los problemas que pueden impedirle a los desarrolladores estimar una historia son: falta de conocimiento del dominio (en cuyo caso se necesita más Negociación / Conversación); o si la historia es muy grande (en cuyo caso se necesita descomponer la historia en historias más pequeñas).
- Pequeña - una buena historia debe ser pequeña en esfuerzo, generalmente representando no más de 2-3 personas/semana de trabajo. Una historia que es más grande va a tener más errores asociados a la estimación y alcance.
- Testeable - una historia necesita poder probarse para que ocurra la etapa de "Confirmación". Recordemos que desarrollamos aquello que no podemos probar. Si no podemos probarlo, nunca vamos a saber si lo terminamos. Un ejemplo de historia no testeable sería: "el software tiene que ser facil de usar".
