Adaptación de Scrum

Para la organización y gestión del trabajo del equipo, se adaptó la metodología ágil Scrum [12]. La razón por la cual se decidió adaptar la metodología se debió al contexto en el cual se desarrolló el proyecto. Para ello, se agregaron aspectos que se creían fundamentales, cómo son una instancia en la cual se decide si el trabajo resultante de un sprint se puede considerar como un producto interno, para posteriormente validarlo con potenciales usuarios.

Cabe destacar que en principio el equipo se manejó con Sprints de dos semanas. Luego, por razones descriptas en el capítulo de gestión de proyecto, sección 6.6, se optó cambiar su duración a una semana.

En la Figura 5 se puede visualizar un diagrama con la adaptación de Scrum realizada, incluyendo las ceremonias, roles, artefactos, entre otros.

39 Figura 5: Diagrama de adaptación de Scrum

Una de las razones por la cual no se pudo utilizar Scrum puro consta de que Scrum no tiene una fecha de fin, mientras que así lo demandaba el proyecto por características académicas.

De las ceremonias que propone la metodología ágil Scrum, se utilizaron Sprint Planning, Scrum Meeting, Sprint Review y Sprint Retrospective.

3.4.1. Ceremonias

En la actual sección se describen las ceremonias que se utilizaron durante el proyecto.

Sprint Planning

Antes de comenzar cada Sprint se realizaba una reunión en la cual se presentaba todo el equipo. El objetivo de las reuniones la planificación de las tareas a realizar en el Sprint a comenzar, agregándolas al Sprint Backlog.

Además, de surgir nuevas tareas, se realizaba una instancia de estimación, priorización y se establecía el criterio por el cual se consideraría finalizada antes de agregarlas al Product Backlog. Los detalles de cómo fueron estimadas se detallan en el capítulo de gestión de proyecto, sección 6.3.2.

Luego, los integrantes se autoasignaban las tareas, eligiendo primero las más prioritarias.

40 Scrum Meeting o Daily Meeting

Estas reuniones tomaban lugar día por medio. Su principal objetivo era informar a los demás integrantes del equipo la situación actual del trabajo que se estaba desarrollando, con el fin de mantener actualizado a todo el equipo.

A su vez, cada integrante comunicaba qué trabajo le restaba por realizar y si necesitaba ayuda de otro integrante o de algún experto en el área, por la existencia de alguna complicación.

Según la definición de Scrum, esta ceremonia debería ser u de carácter diario, pero por ser un equipo de desarrollo pequeño, que además realizaba otras actividades académicas y laborales, se decidió disminuir la frecuencia.

Validación de producto interno

Una vez finalizado el Sprint, el resultado obtenido era evaluado para juzgar si podía considerarse como un producto interno. En caso de que lo fuera, se planificaba una ceremonia en conjunto con potenciales usuarios para validarlo.

El equipo decidió agregar esta ceremonia a la metodología gracias al entorno cambiante, de modo de asegurarse en todo momento de no estar dando pasos en falso validando de forma frecuente con potenciales usuarios.

Sprint Review

La actual ceremonia tomo lugar una vez finalizado cada Sprint. En ella, se repasaba el trabajo planificado para el Sprint, y el que realmente se realizó. En el caso de no finalizar todas las tareas planificadas, se buscó identificar la razón por la cual no se cumplió el objetivo. Se analizaron las tareas realizadas para decidir si realmente fueron completadas o si faltaba algún detalle para incluirse en el siguiente Sprint.

41 Sprint Retrospective

Una vez finalizada la Sprint Review, se realizaba una reunión con el fin de discutir acerca del Sprint. Se identificaban las cosas que se realizaron bien, las que se realizaron mal y qué acciones tomar para mejorar el proceso y no repetir errores en posteriores Sprints.

3.4.2. Artefactos

Product Backlog

El Product Backlog es un listado de todas las funcionalidades que se deben desarrollar a lo largo del proyecto. Además, el listado debe estar priorizado y ordenado.

Sprint Backlog

El Sprint Backlog también es una lista como el artefacto anterior, pero en este caso integrada por las historias de usuario del Product Backlog que se van a realizar en el Sprint a comenzar.

Trabajo terminado o Producto interno

El actual artefacto es una adición del equipo de trabajo a la metodología Scrum. Luego de cada Sprint, se obtiene un resultado el cual se considera como un trabajo terminado.

En el caso que las tareas realizadas cumplan el criterio de aceptación establecido a cada una de ellas, el trabajo terminado se puede considerar como un producto interno.

De ser considerado como producto interno, se le realizará la ceremonia de validación de producto interno detallada anteriormente.

3.4.3. Herramientas y tecnologías

Jira

Se utilizó la herramienta web de Jira para llevar a cabo la metodología seleccionada. La herramienta permite tener un Product Backlog y un Sprint Backlog el cual se armaba al principio de cada Sprint.

42 Además, la herramienta presenta un tablero para cada Sprint, en el que figuran diferentes columnas modificables. El equipo decidió utilizar las siguientes columnas:

1. To Do

En la presente columna se encontraban todas las tareas a realizarse.

2. In Progress

Esta columna contenía todas las tareas que se encuentran en progreso de desarrollo.

3. Code Review

Las tareas que componen la presente columna son aquellas que el integrante asignado a ella consideró finalizada y pronta para que los demás integrantes realizaran una evaluación del trabajo, con el fin de pasarla a la última columna.

4. Done

La actual columna refleja el trabajo revisado y aprobado del Sprint en progreso.

En la Figura 6 se puede observar un ejemplo de cómo se utilizó la herramienta mencionada.

Figura 6: Tablero de la herramienta Jira durante el Sprint 16

43 Cabe destacar que la sumatoria de todas las tareas de todas las columnas dan como resultado el Sprint Backlog original.

Whatsapp

Otra herramienta utilizada durante el proyecto fue la de mensajería instantánea Whatsapp.

El uso de esta herramienta se detalla en el capítulo de gestión de proyecto, sección 6.8.

La razón del uso de una herramienta dinámica como es Whatsapp está relacionada con que las metodologías ágiles se enfocan en la comunicación del equipo más que en la documentación.