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
completadoPresentar el trabajo completado a los interesados
(alias "demo")El trabajo incompleto no puede ser
demostradoCuatro 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