Metodología de desarrollo utilizada en Los Estudios de Videojuegos y Materiales Audiovisuales

Metodología de desarrollo utilizada en Los Estudios de Videojuegos y Materiales Audiovisuales (EVIMA)

Actualmente ha habido un auge en el desarrollo de software a nivel mundial y Cuba ha querido alistarse en esta gran industria para no quedar detrás, puesto que constituye un ingreso monetario muy importante para el desarrollo de la sociedad cubana.

En el año 2010, se creó un grupo de desarrollo nombrado inicialmente ¨Casa Productora de Videojuegos (CPV) ¨ ubicada en el Palacio Central de Computación y Electrónica perteneciente a Joven Club, con un grupo pequeño de egresados de la Universidad de Ciencias Informáticas (UCI) y la CUJAE, actualmente este pequeño grupo de desarrollo se nombra después de un arduo trabajo de todos sus integrantes debido a que fueron los primeros en el país que comenzaron a desarrollar este tipo de software, ¨Estudios de Videojuegos y Materiales Audiovisuales (EVIMA) ¨. Encargándose no sólo del aprendizaje de sus trabajadores sino también de lo que cada uno aporte a la sociedad con su trabajo, con la producción de software a través de los proyectos productivos creados en el grupo de desarrollo.

Para obtener un software con Calidad es necesario planificar de manera ordenada su proceso de desarrollo, cumpliendo metódicamente con un conjunto de actividades en el ciclo de vida para la creación del mismo.

En el Palacio Central de Computación existen 4 grupos de desarrollo de software. Específicamente, uno de ellos es; EVIMA, donde se realizan proyectos encargados al desarrollo de Videojuegos (VJ). En este artículo se hará una pequeña descripción y la metodología de desarrollo de software que utilizan para un mejor desempeño de su trabajo.

Varios de los proyectos pertenecientes a este grupo han logrado desarrollar la versión final de muchos de sus productos; sin embargo, se detectaron deficiencias como: en ocasiones el conocimiento no está accesible o no está disponible cuando es requerido, no se mantiene bajo control el proceso de confección de un Video–Juego, ni se toman medidas preventivas para combatir las causas de los defectos en las diferentes fases del ciclo de vida del producto, lo cual afecta notablemente el control de la calidad de los productos que se desarrollan. Otra de las insuficiencias detectadas en el grupo, es que fueron escasas la planificación y las acciones sistemáticas en el desarrollo de los productos, lo que incidió en el aseguramiento de la calidad de los mismos; de ahí que en muchos casos no se lograra satisfacer al cliente al menor costo posible. Por lo antes mencionado, podemos arribar a la conclusión de que EVIMA no tiene definida una estrategia que viabilice la Gestión del Conocimiento y la Calidad de sus productos, siendo una necesidad importante para la misma asegurar la Calidad de cada uno de ellos, lo cual resulta una tarea bastante difícil para cada integrante de los proyectos.

Todo grupo para llevar a cabo un buen proceso de desarrollo debe hacer uso de buenas prácticas, por lo que a consecuencia de lo anteriormente descrito, para el proceso de desarrollo de software de EVIMA se escogió la metodología ágil SCRUM por las características que la contempla, las del grupo de desarrollo y porque es un modelo de referencia que define un conjunto de prácticas y roles, que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.

Estos son los principales requisitos que se deben llevar a cabo cuando es utilizada esta metodología ágil:

• La cultura de la empresa está basada en trabajo en equipo, delegación, creatividad y mejora continua.

• El compromiso del cliente sigue la dirección de los resultados del proyecto, gestión del ROI y disponibilidad para poder colaborar.

• El compromiso de la Dirección de la organización es para resolver problemas endémicos y realizar cambios organizativos, formando equipos autos gestionados y multidisciplinares y fomentando una cultura de gestión basada en la colaboración y en la facilitación llevada a cabo por líderes al servicio del equipo.

• Debe existir compromiso conjunto y colaboración de los miembros del equipo.

• La relación entre el proveedor y el cliente está basada en ganar-ganar, colaboración y transparencia.

• Tiene que haber facilidad para realizar cambios en el proyecto.

• El tamaño de cada equipo debe estar entre 5 y 9 personas (con técnicas específicas de planificación y coordinación cuando varios equipos trabajan en el mismo proyecto).

• El equipo ha de estar trabajando en un mismo espacio común para maximizar la comunicación.

• Tiene que existir dedicación del equipo a tiempo completo.

• Es de vital importancia la Estabilidad de los miembros del equipo.

Cada metodología tiene su roles, y los principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director o Jefe de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.

Sus procesos se realizan a través de Sprint, que no es más que el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los avances logrados, y el resultado obtenido es un producto potencialmente entregable al cliente. Asimismo, se recomienda no agregar objetivos al sprint o sprint Backlog a menos que la falta de estos objetivos amenace al éxito del proyecto. La constancia permite la concentración y mejora la productividad del equipo de trabajo.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

Las características más marcadas que se logran notar en Scrum serían: gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por último equipo motivado. Cada uno de estos puntos mencionados hace que el Scrum sea utilizado de manera regular en un conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles que es lo que desea EVIMA en sus proyectos.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Estas características permiten un mejor funcionamiento en el proceso de desarrollo de software en EVIMA, y a continuación se hará mención de cómo son distribuidos los roles, las reuniones y los beneficios por lo que ha sido escogida esta metodología de desarrollo para nuestro grupo, ya que es fácil adaptarle a las necesidades del equipo y cliente.

El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

Esta metodología es facilitada por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido y hace que las reglas se cumplan.

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).

Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Los Stakeholders (Clientes, Proveedores, Vendedores, etc) se refieren a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.

Y los Administradores (Managers) son los que establecen el ambiente para el desarrollo del producto.

El proceso de esta metodología es mediante reuniones que son efectuadas en el grupo, hay varios tipos:

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama daily standup o Stand-up meeting. El Scrum tiene unas guías específicas:

• La reunión comienza puntualmente a su hora.

• Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden hablar.

• La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.

• La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:

• ¿Qué has hecho desde ayer?

• ¿Qué es lo que harás hasta la reunión de mañana?

• ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

Scrum de Scrum se realizan cada día normalmente después del "Daily Scrum":

• Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.

• Asiste una persona asignada por cada equipo.

La agenda será la misma que la del Daily Scrum, añadiendo además las siguientes cuatro preguntas:

• ¿Qué ha hecho tu equipo desde nuestra última reunión?

• ¿Qué hará tu equipo antes que nos volvamos a reunir?

• ¿Hay algo que demora o estorba a tu equipo?

• ¿Estás a punto de poner algo en el camino del otro equipo?

• Al inicio de cada ciclo de Sprint (cada 15 o 30 días), se lleva a cabo una reunión de planificación del Sprint. Se pretende:

• Seleccionar qué trabajo se hará.

• Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que llevará hacer el trabajo.

• Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint.

• Realizarse esta planificación en ocho horas como tiempo límite.

Al final del ciclo Sprint se hacen dos reuniones más: la reunión de revisión del Sprint y la retrospectiva del Sprint.

Reunión de Revisión del Sprint (Sprint Review Meeting)

• Revisar el trabajo que fue completado y no completado

• Presentar el trabajo completado a los interesados (alias "demo")

• El trabajo incompleto no puede ser demostrado

• Cuatro horas como límite

Retrospectiva del Sprint (Sprint Retrospective)

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.

Esto genera una cierta cantidad de artefactos que son importantes mantener archivados durante el proceso de desarrollo del software y que será de gran utilidad en pequeños grupos donde su recurso humano fluctué constantemente.

Product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requisitos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI). Es el qué va a ser construido. Es abierto y solo puede ser modificado por el product owner. Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal (KEV) y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menor tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.

El Sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas pero ninguna tarea con una duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.

La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

Ahora nos toca decir que usar SCRUM como metodología de desarrollo nos da un gran grupo de beneficios que no podemos dejar de mencionar en este artículo:

• Flexibilidad a cambios. Gran capacidad de reacción ante los cambiantes requerimientos generados por las necesidades del cliente o la evolución del mercado. El marco de trabajo está diseñado para adecuarse a las nuevas exigencias que implican proyectos complejos.

• Reducción del Time to Market. El cliente puede empezar a utilizar las características más importantes del proyecto antes de que esté completamente terminado.

• Mayor calidad del software. El trabajo metódico y la necesidad de obtener una versión de trabajo funcional después de cada iteración, ayuda a la obtención de un software de alta calidad.

• Mayor productividad. Se logra, entre otras razones, debido a la eliminación de la burocracia y la motivación del equipo proporcionado por el hecho de que pueden estructurarse de manera autónoma.

• Maximiza el retorno de la inversión (ROI). Creación de software solamente con las prestaciones que contribuyen a un mayor valor de negocio gracias a la priorización por retorno de inversión.

• Predicciones de tiempos. A través de este marco de trabajo se conoce la velocidad media del equipo por sprint, con lo que es posible estimar de manera fácil cuando se podrá hacer uso de una determinada funcionalidad que todavía está en el Backlog.

Reducción de riesgos. El hecho de llevar a cabo las funcionalidades de mayor valor en primer lugar y de saber la velocidad a la que el equipo avanza en el proyecto, permite despejar riesgos efectivamente de manera anticipada.

Por todo lo ante mencionado pudimos apreciar que Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

Por lo que las metodologías ágiles presentan un enfoque diametralmente opuesto a las metodologías predictivas, ofreciendo un enfoque más adecuado para determinados proyectos como el desarrollo de software. No obstante, es importante no caer en el extremo y dar por malo todo aquello que sea de un bando u otro.

Aunque optemos por el uso de metodologías ágiles, resulta interesante conocer las herramientas y técnicas predictivas dado que es posible que podamos incorporar alguna de ellas exitosamente (y viceversa). La convergencia entre ambos modelos puede dar lugar a una gestión eficiente y eficaz.

Autor:

Hissel Lamanier Regueiferos