[SONIDO] Bienvenidos nuevamente. Ahora vamos a ver los diferentes roles de la metodología SCRUM. Como esta metodología está diseñada para apoyar equipos, existen una serie de roles que ayudan al equipo, no solamente ser más productivo, sino además a aprovechar la metodología de una mejor manera. Incluso crea una serie de puentes de comunicación entre el equipo y personas interesadas en el producto. Estos roles son, Stakeholders, clientes, el equipo, el SCRUM MASTER y el Product Owner. El primero de los roles es el Stakeholder. Un Stakeholder es una persona que tiene interés en el éxito del proyecto aunque no hace parte del grupo de producción. Un primer ejemplo de Stakeholder puede ser el representante del Publisher. El Publisher es una empresa que ayuda al estudio a promocionar y vender el juego y en muchas ocasiones lo financia, por eso el publisher quiere tener un ojo sobre el equipo de producción y saber en qué va el juego, si está atrasado o si va bien. Un segundo ejemplo de Stakeholder puede ser el grupo de mercadeo, ellos están interesados en cuáles podrían ser los puntos claves de venta del juego o por ejemplo cuándo vamos a tener una versión que podemos mostrar en revistas o en eventos especializados, cuándo vamos a abrir el juego en beta para que la gente lo pruebe o simplemente cuándo va a estar listo el juego para que lo podamos vender. Un tercer grupo de Stakeholders puede ser los CEO o líderes del estudio, ellos no trabajan directamente en el juego pero sí son un grupo de personas que pueden ayudar al equipo a administrar sus recursos, ya sea de tiempo, ya sea de dinero o incluso ayudar a solucionar problemas que por alguna razón el equipo directamente no puede solucionar. Otro de los roles son los clientes los cuales son las personas que van a disfrutar del producto final y en nuestro caso son los jugadores. Los Stakeholders y en específico el Product Owner, que es un rol que veremos más adelante, son las personas que tienen en mente las expectativas que los jugadores tienen de nuestro producto y se aseguran que esas expectativas se cumplan a través de la producción y en el producto final. Esta comunicación entre el cliente, Stakeholders y equipo es muy importante porque les ayuda a organizar sus prioridades sabiendo qué tienen que crear y en qué orden deben crearlo y eso se ve reflejado en el Product Backlog. El siguiente rol es el equipo, el cuál está compuesto de un grupo de expertos que saben como hacer el producto, en nuestro caso estamos hablando de programadores, artistas, diseñadores, compositores, etcétera. Este grupo autorganizado de personas deciden al principio de cada Sprint a qué se va a comprometer y al final de éste, entrega un producto que muestra el resultado de su trabajo. El siguiente rol es el del SCRUM MASTER. Usualmente este rol se confunde con el de un productor o un organizador pero no es ninguno de los dos. El SCRUM MASTER es el encargado de enseñar la metodología al equipo y lo hace a través de asesorías o de evitar cualqueir obstáculo que obstruya en su producción. Por eso el SCRUM MASTER tiene una serie de responsabilidades: primero, tiene la capacidad de llamar la atención con respecto a problemas que ocurran durante la producción. Usualmente el equipo es bastante autónomo y puede solucionar los problemas por sí mismo pero es importante que el SCRUM MASTER llame la atención de aquellos problemas ya sea al grupo mismo o a personas externas que puedan ayudar en la solución. Su segunda responsabilidad es la de monitorear la producción. El SCRUM MASTER se encarga de informar al equipo qué tan cerca está de cumplir sus objetivos. Una tercera responsabilidad es la de faciltiar la planeación y revisión del proceso, el SCRUM MASTER crea una serie de reuniones en donde el grupo antes del Sprint planea lo que va a hacer y cuando termina el Sprint hace una revisión de cómo estuvo el proceso para mejorarlo. Una cuarta responsabilidad es la de crear un ambiente de mejoramiento continuo, el SCRUM MASTER detecta elementos en donde el grupo puede mejorar su producción o incluso prevee problemas que puedan presentarse a futuro. Una quinta y última responsabilidad es la de ser un canal de comunicación entre los Stakeholders y el equipo, usualmente a través del Product Backlog. [SONIDO] Nuestro último rol es el Product Owner. Es la persona que tiene la visión de cómo va a ser el juego, por lo mismo tiene una serie de responsabilidades. La primera, es comunicar esa visión al resto del equipo de modo que todo el mundo esté en la misma página. La segunda, es ser el dueño del Product Backlog, él es el que define en qué orden van a estar todas las características del juego y a qué se le va a hacer prioridad para desarrollarlas. La tercera responsabilidad es que ya que él conoce como va a ser el producto, es el que define cuáles van a ser las entregas durante el proceso. La cuarta responsabilidad es procurar un retorno de inversión. El Product Owner conoce no solamente su producto, sino el mercado en el que se mueve, de modo que puede pronosticar qué se va a vender, ya sea en este aumento o en una proyección de dos o tres años. Y la quinta y última responsabilidad es conocer cuáles son las expectativas del jugador. De ese modo él puede decidir qué es lo que se va a producir y en qué orden durante el desarrollo del producto.