Bienvenidos nuevamente a clase. Para este punto, ya hemos experimentado lo que es un sprint. Ahora vamos a hablar de las actividades que se realizan luego de que un sprint ha sido terminado y concluiré esta sesión con los posibles casos en que un sprint no se pueda finalizar y qué hacer al respecto. Luego de que un sprint ha terminado, se realiza una revisión del sprint y una retrospectiva del sprint. El primero se enfoca en el objetivo y el trabajo realizado durante el sprint, mientras que el segundo gira al rededor del proceso llevado durante el mismo perÃodo. La revisión del sprint ocurre el último dÃa del sprint. En esta ocasión, equipo y stakeholders se reúnen para jugar el juego y discutir el trabajo logrado. La reunión comienza con un miembro del equipo explicando el objetivo del sprint y los resultados. Si alguno de los Ãtems del product backlog fue eliminado del sprint, aquà se explican y discuten los motivos. Un miembro del equipo juega el juego mientras se demuestra cada objetivo cumplido y cómo éste adhiere valor al juego. Acto seguido, éste es jugado por un cliente, es decir un jugador, de ser posible, alguien externo al estudio que pertenezca a la audiencia objetivo. Durante la revisión, es cuando el product owner acepta o rechaza el resultado del sprint. Si los resultados para una caracterÃstica en particular son rechazados, es el product owner quien decide si esta caracterÃstica vuelve al product backlog o se elimina. Hay que procurar que estas reuniones sean el mejor momento de comunicación entre el equipo y los interesados externos. La idea es que los stakeholders hagan todas las preguntas que tengan sobre el juego y el progreso del proyecto, de modo que la visión de ambos se unifique y asà los stakeholders se aseguren que el proyecto está cumpliendo con sus expectativas. Uno de los stakeholders más importantes es el publisher. Si el proyecto está siendo financiado o apoyado de alguna u otra forma por un publisher, es importante que éste tenga un representante en estas reuniones, el cual debe experimentar el juego, especialmente en los avances del sprint y su retroalimentación debe ser muy tenida en cuenta. Otro grupo de stakeholders que deben incluirse aquÃ, son los directores del estudio, pues este es un momento clave para saber cuál es la situación del equipo y qué tipo de ayuda requiere. Después de esta reunión, tanto SCRUM MASTER como los lÃderes de cada especialización, se reúnen para discutir sus resultados. El siguiente proceso de autoevaluación es la retrospectiva del sprint. El objetivo de ésta reunión es el de mejorar la forma en que el equipo genera valor para el juego. Esto se logra reconociendo prácticas que han sido beneficiosas, abandonando prácticas que hayan resultado perjudiciales e identificando o proponiendo nuevas prácticas para ser intentadas durante el siguiente sprint. Los cambios propuestos en esta reunión no tienen que ser grandes o radicales. Cambios pequeños y eficientes logran un mejormiento significativo a largo plazo. Esta reunión es organizada por el SCRUM MASTER, quien reúne a todo el equipo y procura que la reunión sea de duración fija y relativamente corta. Usualmente, esta es una reunión que solo compete al equipo, pero es decisión del mismo si alguien externo es invitado a asistir, especialmente personas o roles externos con los cuales se interactúa constantemente durante el sprint. En la reunión se ponen a consideración las siguientes preguntas: Primero, ¿qué cosas deberÃamos dejar de hacer? Segundo, ¿qué ha funcionado que deberÃamos seguir haciendo? Y tercero, ¿qué cosas deberÃamos empezar a hacer? Por medio de las preguntas anteriores, se identifican cambios en la forma en que el equipo trabaja y se representan por medio de Ãtems de acción, pequeñas frases que describen una acción especÃfica a tomarse para mejorar el proceso. Usualmente son acciones muy puntuales que deben ejecutarse una vez. El SCRUM MASTER registra estos Ãtems y los coloca en un lugar visible para el equipo. Las acciones que se cumplen durante el sprint van siendo eliminadas y las acciones que queden al final del sprint, se evalúan en la siguiente reunión retrospectiva. Aunque esta es una de las actividades de la metodologÃa que más tiempo toma en asimilarse, su ejecución es de mucha importancia, ya que la continua práctica de esta reunión ayuda al equipo a ser más eficiente en el tiempo. A veces ocurre que un equipo no cumple las metas de un sprint. Esto puede ocurrir por dos razones, principalmente, cuando el objetivo del sprint cambia, o cuando el equipo, simplemente, no alcanza a cumplir las metas por falta de tiempo. Usualmente, el objetivo de un sprint cambia por algún cambio externo al equipo, una solicitud de algún stakeholder o el descubrimiento de alguna falla técnica que está afectando seriamente a los jugadores o a las ganancias del estudio, en el caso de un free to play. En el primer caso, se debe pedir al stakeholder que tenga en consideración los costos de cambiar algo o incluso de cancelar el sprint, antes de pedir algún cambio, si este no da su brazo a torcer o si el requerimiento es realmente urgente y necesario, se llama al product owner y entre los tres evalúan el requerimiento o problema, desarrollan el Ãtem del product backlog correspondiente, reúnen a parte el equipo que puede cumplir esa labor para que hagan una rápida planeación del sprint y concluyen si es posible completarlo en el tiempo que queda. En la segunda posibilidad, cuando un sprint está por fallar debido a falta de tiempo, el equipo debe decidir primero si el objetivo es viable por medio de tiempo extra de trabajo. La siguiente opción es hablar con el product owner y ver la posibilidad de sacar algún Ãtem y sus tareas relacionadas del sprint backlog, preferiblemente, Ãtems de menor relevancia. En el caso de que esto no sea viable, se hace un llamado al reset del sprint, donde todos los Ãtems no completados, regresan al product backlog, el código y las piezas de arte son revertidos y el equipo llama a una nueva planeación del sprint, eso sÃ, el reset de un sprint debe ser la última alternativa y debe ser evitada a toda costa. También puede ocurrir el otro extremo de la situación, cuando un equipo termina sus tareas antes del tiempo del sprint si esto ocurre, usualmente el tiempo se dedica a trabajos de refinamiento. Si el tiempo sobrante es más de un par de dÃas, el equipo y el product owner se ponen de acuerdo en seleccionar algunos Ãtems del product backlog que puedan ser completados en el tiempo extra. Les agradezco su atención y espero verlos en el siguiente video.