Transcription
Vamos ahora a las historias de usuarios. ¿Qué eran las historias de usuarios? Es la representación del requerimiento en una o dos frases. Nunca deben ir solas, siempre deben ir acompañadas de pruebas de aceptación. Yo redacto una historia de usuario y digo: ¿cómo sé que esa historia queda hecha? Eso se llama el "Definition of Done".
"Acelerar esas sean a darle a probar la certificación, la van a montar hoy." ¿Y qué es el "Definition of Done"? Es decir, ¿cómo sabemos que esto está terminado? La definición de terminado. Eso tiene que incluir.
¿Y qué más? Existe algo que se llama "historias de usuario épicas". ¿Qué es algo que le voy a explicar en unas dos "slides" más adelante, vale? Muy bien. De hecho, a la siguiente.
Muy bien, ¡qué rápido! ¿Qué es una épica? Una historia de usuario muy grande. Generalmente no cabe en un "sprint". O bien, una agrupación de historias que están fuertemente relacionadas. Generalmente, una historia de usuario muy grande, una épica, se reconoce porque quizás es el objetivo incluso del "sprint". Vale, como por ejemplo, si ven los vídeos, las personas dicen algo general, ¿no? Esa puede ser una épica. Esa puede ser el "epic".
Y el que era un reporte automático, ¿ok? Este, para seguir ese reporte automático, ¿qué necesitamos hacer? Y hay un montón de procesos intermedios, ¿no? Entonces, eso es una épica.
Y de forma gráfica, de forma gráfica queda un poco así. Está en la mejor jerarquía que encontré para poder representarla. Esta es la iniciativa, que puede ser el proyecto que vamos a utilizar. Y pueden haber épicas. Y dentro de cada épica hay un conjunto de historias. Y dentro de cada historia pueden haber un conjunto de tareas. Vale, eso es la estructura.
Y finalmente, ¿cuál sería un "backlog"? Por ejemplo, ¿cuál sería el "backlog"? Es el conjunto de historias. Vale, finalmente, todas esas historias de usuario va a ser su "backlog". Muy bien.
¿Qué tiene que incluir? Como nosotros, ¿qué modelo utilizamos para redactar la historia del usuario? Que es algo sumamente importante. Este modelo, que solo puedo recordar, que es el INVEST. Que las historias de usuarios tienen que ser independientes. Mientras más independientes, mejor. Porque si depende mucho de que se haga una tarea, contratar, y después de otra tarea, no somos ágiles. No somos ágiles y volvemos a un esquema de diagrama de Gantt. Vale, entonces la historia se tiene que ser lo más independiente posible. Negociable, quiere decir que una persona dice: "Hoy yo quiero esto", pero eventualmente, si el usuario final dice: "En realidad, me dice gustado, también que agregar a un color rosa". Ok, eso es negociable, no hay problema. Evaluables, valorable, estimable, pequeña, muy pequeña, ojalá lo más pequeño posible. Y demostrar. Este modelo les va a servir muchísimo cuando vayan a redactar la historia de usuario.
Muy bien, ¿cómo es la estructura de la historia de usuario? ¿Cómo, cómo se dice? ¿Cómo es la estructura? Es el cómo se escribe, ¿no? Es como ellos. Hoy el rol de la persona, por ejemplo, como administrador, como reportero, como usuario, como cliente, como lo que sea. No, como "role", "I want", "I desire", "I want to do something", "in order to provide some value". Esa es la historia de usuario.
Viajo, le agrega una pequeña frase que me gustó muchísimo de todas las 20 de la vida, que es: "Las historias de usuario son tareas de desarrollo que se expresan como persona, más necesidad, más propósito". Vale, es muy relevante el propósito. Vale, porque ahí es donde podemos entender cuál es el valor real de que eso esté implementado. Porque si tiene muy poco valor, porque le voy a dar una importancia tan grande, a lo mejor tengo que buscar otra tarea que tenga más valor para el cliente.
Y esta es una medida que desarrolla generalmente el "product owner", pero ustedes van a tener que desarrollarla debido a la naturaleza del proyecto que vamos a hacerlo. Vamos a un ejemplo. Algo como sería si voy donde el cliente y tengo que escribir esto en papel. Más o menos así se vería una historia de usuario en este "post". Y el tipo "poster" que es de metodología "agile", que van pegando en distintas partes los "Scrum Masters" generalmente.
Entonces, fíjate la estructura. Vamos, vamos por lo primero, con el lado inverso. Tiene una idea. Es algo importante porque si sabemos, tenemos como referencia, digamos, a esta historia de usuario. Vale, tiene un título. "Préstamo del libro", en este caso. Tiene una descripción. Y fíjate en la estructura: "Como cliente, se acuerdan como el rol, quiero que los socios puedan pedir prestado un libro, indicando su número de socio y la referencia del libro, siempre y cuando no tengan ya tres libros en préstamo en ese momento".
Esta historia me gusta, pero le falta incorporar el valor. ¿Cuál es el valor que le entrega? ¿Cuál es el propósito? Eso le falta a esta historia. No, de aquí tiene una estimación que puede ser una estimación inicial. Y se será en cuenta, no hay horas. ¿Dónde están las horas? Acá. ¿Cuántas horas se demora esto en hacer? Y eso es lo que vamos a realizar hoy. Porque dice 4. Prioridad 300. ¿De dónde sale ese 300? Dependientes de 1 y 2. Eso es importante de declararlo. Se acuerdan que en el módulo INVEST, nosotros vamos a tratar de hacer que no sean dependientes. Hay casos en que no podemos hacerlo, no podemos hacerles tareas que sí van a depender, pero idealmente no tengan dependencia.
Y fíjate en el reverso que tiene, que es muy importante, es las pruebas de aceptación. Es decir, ¿cómo sabemos que esto está realizado? El "Definition of Done". Entonces, mira, te pone una primera, un primer "checklist". El "Definition of Done" es un "checklist" de tareas. Vale, ahí están las tareas asociadas a las historias de usuario. Cuando menciona tarea, es lo mismo que historia. Solo no, una historia de usuario puede contener N tareas. Y eso es lo que vemos acá. Por ejemplo, la primera tarea es: "Introducir un número". O sea, las pruebas de aceptación: "Introducir un número de socio incorrecto y comprobar que se indica error". Eso puede ser una tarea. Puede ser un programa en que realices. Sálvora, cuando le pedimos hacer un programa, ¿qué tal cosa, cierto? Esa es en este caso una situación: "Introducir un socio que ya tiene tres libros en préstamo y comprobar que ese indicador se encuentra y aparecer las condiciones que ocuparíamos". Hay un ciclo, ¿no? Un ciclo que cuente uno, dos, tres. Y afuera, siguiente: "Introducir un libro del que no hay ejemplares y comprobar que se indica un error". Eso tengo que ir a otro ciclo, tengo que ir a buscar que no hay ejemplares dentro de un sistema. No se dan cuenta cómo se van ocupando algunos conceptos. Vale.
Este es un ejemplo de una peluquería. El objetivo es modernizar esto. Lo que me pidieron ellos: "Modernizar nuestra peluquería incorporando el sistema de gestión". Resultado clave: "Ingresos de nuevas citas a un sistema", "Migración del 100% registros de clientes al sistema". Te hablé con el cliente y me dijo: "El primer requerimiento, hoy quiero registros de clientes". Y ahí el "product owner" tiene que ir a decir: "Allí, ¿y quién va a utilizar ese registro de cliente?". Es la primera pregunta que tenemos que responder para redactar la historia. Sabremos quién va a ser el usuario. Ok. ¿Y para qué lo quieres hacer? Y ahí tener otra respuesta para no recurrir al papel y tener mayor rapidez en la búsqueda. Te das cuenta que está el valor, está el valor de lo que quiere.
Entonces, cuando yo voy a donde el cliente y le hago la lista de requerimientos, tengo que hacerle dos preguntas: ¿Quién va a utilizar? Porque siempre va a decir sus necesidades, "Oye, no, yo quiero esto". Ok, ¿quién va a utilizar esto que tú me estás diciendo? Y luego, ¿para qué? ¿Para qué lo quiere dejar implementado? Esas preguntas son claves. Es lo que me dice el cliente. Y luego está la historia de usuario. Luego, yo transformo este requerimiento en una historia de usuario. Y luego hay una parte de cómo probarlo. Esto se hace, se hace general, se hace en el "Sprint Planning", se hace con el equipo de desarrollo. El equipo de desarrollo soy yo. ¿Cómo probamos esto? Y ahí es donde nace la idea, donde: "Mira, con esto, con esto". Y el "product owner" te dice: "Si está bien, con esto porque él tiene la visión del cliente, el cliente quiere esto. Si está bien con eso, ha solucionado para ellos. Perfecto".
Entonces, quiero darles, les voy a dar estas dos primeras tante ejemplo. Estando ejemplo, pero la actividad que van a hacer, a la que se van a reunir en grupitos, y hay una persona que va a redactar la historia. Son las demás van a aportar y van a redactar las historias de usuario. Y por cada vez que redacten una historia de usuario, por ejemplo, "poder dejar pagado el servicio", ustedes van a poner un ejemplo. Vale, "Oye, ¿quién, quién necesita, quién va a utilizar esto y qué valor le aporta esto?". Lo van a hacer como ejemplo. Sí. Y van a entregar un "cómo probarlo". Van a definir un poco cómo probarlo. Así, una vez tengamos tanto la historia de usuario como el "cómo probarlo", nos vamos a reunir nuevamente a mirar cómo fueron sus historias de usuario, cómo las redactaron. Necesito que suelten un poco la mano en redactar.