[SONIDO] Bienvenidos nuevamente a clase, ya hemos hablado de cómo un juego se desglosa en sus características y detalles para ser transformados en ítems en el product backlog, y luego desglosados en tareas en el spring backlog. Ahora veremos una forma de representar esos ítems y tareas, que trae varios beneficios al grupo y al proyecto. Esta forma de representación es conocida como historias de usuario. Las historias de usuario, son frases cortas que representan los requerimientos del juego desde el punto de vista del jugador, no del desarrollador, es decir, sirven para expresar mejor el valor que las características del software o herramienta, tiene para sus usuarios finales. También son útiles para procurar el diálogo entre los miembros del equipo ya que las historias son un marcador para la conversación que hay que tener con respecto a los detalles de los ítems o características descritos en ellas. La estructura que siguen las historias de usuario es la siguiente: COMO, usuario, QUIERO objetivo, PARA razón. El rol de usuario se refiere al cliente final de la historia. El jugador o algún miembro del equipo que se beneficia de alguna mejora en la producción. El objetivo de la historia es una función o característica del juego, de la herramienta o del pipeline de producción, y la razón describe el beneficio que esta historia dará al usuario cuando se cumpla el objetivo. Esta parte puede ser omitida si el beneficio es obvio. Por ejemplo, como jugador quiero tener en mi interfaz una vista de radar para poder ver dónde están todos los jugadores. Otro ejemplo puede ser como animador quiero ver y controlar la forma y la velocidad en que se fusionan dos animaciones. Uno forma de agregar detalles importantes a una historia es complementarla con condiciones de satisfacción. Una condición de satisfacción es una frase que describe una acción y su resultado. Esto ayuda al equipo a entender el objetivo final de cada historia de usuario, y evita que entreguen una característica equivocada o malinterpretada al final del sprint. Estas condiciones de satisfacción debes de ser comprobables, es decir que sean fáciles de demostrar o probar. Por ejemplo, si tenemos la siguiente historia, como jugador quiero tener el control de la fuerza con que pateo el balón, las posibles condiciones de satisfacción pueden ser, al presionar el botón de pateo y soltarlo inmediatamente el balón sale con un mínimo de fuerza. Y también al presionar el botón de pateo y soltarlo después de un segundo el balón sale con el máximo de fuerza. Aquí claramente se describe de qué modo esta historia es verificable. Las características mas importantes para crear una buena historia se reúnen en el acrónimo invest en ingles, dichas características son: uno, que sea independiente, debe procurarse en la medida de lo posible que las historias sean independientes de otras historias en el orden en que se implementan, dos, que sea negociable, las historias deben permitir espacio para su discusión y los detalles deben ser definidos por el equipo en el momento de su adición a un sprint. tres, que sea valiosa, la historia debe expresar claramente el valor que la característica trae a la experiencia del jugador o usuario final, cuarto, que sea estimable, debe ser posible estimar el tiempo que va a tomar desarrollar una historia, a menos de que sea muy grande o el equipo no tenga el suficiente conocimiento para estimarla. En ese caso o se desglosa en historias más pequeñas o se crea un prototipo para resolver esa incógnita respectivamente, quinto, que sea pequeña, en la planeación del sprint las historias del product backlog deben ser subdivididas en historias que puedan trabajarse durante ese sprint. Y seis, que sea comprobable, las historias deben de escribirse de modo que sean verificables al final del sprint, las condiciones de satisfacción ayudan a ese propósito. Hay proyectos sobre todo en videojuegos en donde los usuarios finales se pueden dividir en diferente tipos, esto se conoce como roles de usuario y puede ser entre otros diferentes modos de juego o diferentes dificultades. En estos casos es muy útil identificar esos roles y utilizarlos cuando ayudan a entender mejor el valor que una historia representa para ese caso específico. Por ejemplo, en un juego de fútbol donde existen los modos de defensa y atacante pueden haber dos historias así, como atacante quiero hacer pases dependiendo de hacia qué dirección esta mirando mi jugador, y otra que diga, como defensa quiero que cuando yo cambie de jugador, controle al personaje que esté más cerca al contrario que tiene la pelota. En este caso los roles de usuario ayudan a contextualizar mejor el requerimiento de las historias. Cuando un proyecto está basado en la construcción progresiva de ítems de un product backlog, es importante que el equipo concrete internamente la definición o definiciones de lo que terminado significa para ellos y los stakeholders del proyecto. Una forma de hacerlo es usando las condiciones de satisfacción aclarando qué características va a tener esa historia al terminarse. Otra forma de hacerlo es creando diferentes niveles de terminado que representen diferentes calidades o fases de un proyecto o elemento. Por ejemplo, se podría tener diferentes niveles de terminado, a nivel prototipo, a nivel producción, a nivel lanzamiento, cada uno con estándares distintos de calidad. Lo importante es que estos niveles y sus características sean claros para todas las partes. Ahora bien, después de lo que hemos visto podemos identificar dos ventanas centrales en usar las historias de usuario. La primera es que requieren que el equipo dialogue cara a cara sobre su significado antes de incluirlas en el sprint backlog, de ese modo no solo de dialoga sobre lo que significa y el resultado esperado en la historia, si no que se expone cualquier duda o complicación que alguien pueda identificar en la misma. La segunda ventaja está en el hecho de que ya que las historias están creadas de modo que se entienda su valor al jugador o al usuario, hace que esta sea comprensible para personas que no estén familiarizadas con dicha historia, ya sean otros integrantes en el equipo, el mismo product owner, o los stakeholders.