Transcription
Hola, yo soy Cris Rúa y hoy les voy a hablar sobre historias de usuario. Las historias de usuario tienen tres elementos supremamente importantes: card o tarjeta, conversación y confirmación.
Esta primera C, representa la tarjetita. Son esos post-it que normalmente vemos por ahí. Error grande, tratamos de meter toda la información necesaria en esta pequeña tarjetica. Por algo es pequeñita, porque esta tarjeta es la que nos va a ayudar a recordar lo que vamos a hablar antes de iniciar el sprint. O sea, que no se pongan a meter todo, más bien téngalo presente porque eso se va a conversar. Hay una recomendación para escribir esta tarjeta y es la siguiente: "Yo como..., quiero..., para...". Yo como persona que usará la funcionalidad, no el que la pidió, el que la va a usar. Quiero, aquí específicamente viene la funcionalidad, o sea, lo que vamos a realizar. Y para: esto para qué sirve, esto que resuelve.
Me voy a saltar a esta última C. Esta última C que significa confirmación, son a los que normalmente llamamos criterios de aceptación. ¿Y esto qué es? Son las cosas que me dicen si una historia de usuario ya quedó lista. Cada uno de estos puntos se tienen que validar antes de entregarse la historia de usuario. Ejemplos: "Yo como persona que usa el cajero electrónico, quiero poder sacar el dinero, para tener acceso a mi dinero desde cualquier parte". Un criterio de aceptación podría ser: "El usuario debe ingresar una clave con un número de cuatro dígitos". Otro criterio puede ser: "Si el usuario se demora más de 10 segundos en ingresar su clave, se le cancelará el proceso y deberá volver a iniciar". Y se deben poner los suficientes para decir que esta funcionalidad está bien hecha. Se recomienda que tampoco sean un montón. Si usted tiene demasiados criterios, piense si posiblemente no será que tienen que sacar dos historias de usuario de ahí. Recuerde que la idea es que las historias de usuario sean pequeñitas y que nos generen recordación de lo que vamos a realizar.
Ahora, la más importante de todas las CCC: la conversación. Todo lo que usted no alcance a aclarar aquí, porque siente que le falta, es lo que se tiene que conversar. Esta es la magia de las historias de usuario. Hay muchos ejercicios que demuestran que por más que usted escriba en un papel, nunca va a alcanzar a aclararse como quisiera, y que un minuto de conversación es más eficiente que pasar una hora tratando de escribir todo lo que yo quiero y enviándoselo al otro por correo. Esta conversación es presencial y aquí tiene que estar nuestro Product Owner, que es la persona que nos va a aclarar todo y nos va a responder cualquier pregunta. La conversación se hace en la planeación, donde está el Product Owner, el equipo, y en medio de la conversación aclaran todo lo que se necesiten.
Ahora, para las personas que están definiendo historias de usuario, que es el Product Owner normalmente, tenemos el modelo INVEST, qué es lo que le ayuda cuando las está definiendo, cómo las divido, cómo las separo, qué tan grande dejo una, cómo hago para dividir una de la otra. Y tenemos que este modelo es que cada historia de usuario debe cumplir con lo siguiente:
Que sea independiente. Independiente es que no necesite de otra para poder funcionar, o al menos no programes dos historias dependientes para el mismo sprint. Si usted a un grupo de personas le dice que tiene que estucar y pintar un apartamento durante el mismo sprint, la persona que pinta tendrá que esperar a la persona que estuca para poder hacer su trabajo. Por lo cual, las historias deben ser lo más independientes posible.
Negociables. No la lleves tan, tan hecha. Mira que por eso la historia de usuario es pequeña. Tú llevas lo que van a conversar y en medio de la conversación podrán salir cosas mejores que hasta el equipo de desarrollo puede ver y que tú no la habías visto. Por lo cual, en medio de la planeación se podrán acordar algunas cosas de más o de menos.
Valiosa. Que una historia de usuario no dependa de otra para generar valor.
Estimable. Que el equipo pueda decir cuál es la dificultad que tiene esa historia de usuario comparada con otras para poder decir con cuántas se pueden comprometer durante el sprint. Eso es estimar.
Pequeña. Una historia de usuario primero debe caber en un sprint y segundo, no debe ser al límite de que una persona se demore todo un sprint haciéndola, porque van a correr el riesgo de que no la termina en ese mismo sprint. Por eso se recomienda ser lo más pequeña posible.
Y testeable. Que una persona pueda decir cuando la historia está lista y que pueda verificarlo.
Estar jugando con esto no es fácil. Por ejemplo, lograr que una historia de usuario sea valiosa y que sea pequeña al mismo tiempo es un juego muy importante. Por eso tenemos el rol del Product Owner, que este es gran parte de su trabajo: crear las historias de usuario, mantenerlas claras, mantener sus criterios de aceptación claros, estar presente para conversarlas. Unas historias de usuario difícilmente serán bien hechas si no tenemos un rol de Product Owner encargado de hacerlas y de hacerlas muy bien hechas.
Esto es crear una historia de Usuario, un poquito resumido. Ve y estudia cada uno de estos temas que te va a servir muchísimo en tu día a día y para estar puliendo y mejorando. Espero que te haya gustado este video y que le sirva en sus equipos para cada vez ir mejorando. Suscríbete aquí abajo y dale click en la campanita, así YouTube te dirá cuando yo monto otro video. Que tengas un lindo día. ¡Chao!