Experiencia Educativa en el aula: “Ávila en tapas”. (Capítulo 3: Desarrollo)
Este artículo forma parte de una serie de artículos sobre cómo se ha desarrollado el proyecto “Ávila en tapas” en el ciclo formativo de Desarrollo de Aplicaciones Multimedia del IES Alonso de Madrigal. En esta web “Ávila en tapas” puedes acceder al contenido del producto final.
En este capítulo voy a contar como gestionamos las tareas desde el punto de vista de la implementación, del código y los recursos relacionados.
Capítulos:
- “Ávila en tapas”. Capítulo 1: Kickoff
- “Ávila en tapas”. Capítulo 2: Metodología
- “Ávila en tapas”. Capítulo 3: Desarrollo
- “Ávila en tapas”: Capítulo 4: Evaluación y Calificación
Herramientas
Estamos digitalizando una propuesta, vamos a transformar una idea en un producto. Para ello vamos a desarrollar una aplicación y esto implica programar.
Las herramientas que seleccionamos para trabajar son las propias que se usarían en cualquier empresa de desarrollo de software. Estas herramientas fueron:
- MarvelApp (link al prototipo): usamos esta aplicación web para desarrollar el prototipo de la aplicación. Este prototipo inicial sirve para conocer las funcionalidades básicas que va a tener la aplicación. Seguramente en cada uno de los sprints cambiemos cosas del prototipo inicial, pero ese es uno de los objetivos, enfrentarnos al cambio constante, descubrir problemas lo antes posible, crear nuevas oportunidades…
- Controlador de versiones de código: Git. No se puede desarrollar un producto en equipo sin un controlador de versiones. Un controlador de versiones nos permite tener el control del código. Cada uno de los alumnos trabajará en una funcionalidad distinta y luego hay que fusionarlo en el mismo proyecto, es aquí donde un control de versiones nos facilita el trabajo. Nosotros usamos GitHub. Además, hay que recordar que en el módulo de primero “Entornos de desarrollo” (DAM o DAW) se ven los controladores de versiones de código.
- Gestión de tareas: Github(issues). Github además de ser un controlador de versiones de código, tiene funcionalidades completas para gestionar un proyecto. Como vimos en el anterior post, usamos el gestor de “issues” de GitHub como “Backlog” donde estarán todas las tareas a implementar. Veremos el flujo completo en el siguiente punto.
- Aplicación de diseño gráfico: Gimp. Esta herramienta la usamos para retocar imágenes e iconos.
- Recursos gráficos. Casi todos los iconos han sido cogidos de Freepik y StorySet. Se pueden usar recursos siempre que se hagan mención a ellos. Nosotros añadimos estamos menciones en la propia aplicación.
Flujo de desarrollo de una tarea
El flujo de una tarea era muy sencillo, podíamos resumirlo en:
- Asignación de ticket.
- Creación de una rama de desarrollo.
- Implementación de la funcionalidad (con o sin Pair Programmin).
- Creación de Pull Request para añadir la funcionalidad recién implementada al proyecto.
Vamos a describir cada uno de los pasos.
Tarea, ticket o Issue
Un alumno tiene asignada una tarea a implementar. A partir de ahora la llamaremos ticket. El cómo ha surgido esta tarea, la estimación, etc. se explica en el anterior post.
Este ticket se encuentra definido en el backlog.
En este ticket podemos ver la siguiente información:
- Alumno asignado.
- Estimación. En este caso se ha estimado con 3pt. La estimación mide el esfuerzo que supone al alumno desarrollar el ticket.
- Título del ticket. Título descriptivo sobre lo que hay que implementar.
- Módulos involucrados en este ticket. En este caso sólo implica al módulo de PMDM (Programación Multimedia y Dispositivos Móviles). A modo recordatorio, el proyecto se realizó implicando otros dos módulos más: Acceso a Datos (AAD) y Programación de Procesos y Servicios (PSP). En esta ocasión, el ticket estaba muy relacionado con la interfaz de usuario y por tanto sólo implicaba al módulo PMDM.
- Subtareas implicadas en el ticket. Ayudan al alumno a organizar tareas grandes dividiéndolas en tareas más pequeñas.
En el detalle del ticket el profesor con la ayuda del los alumnos detalla lo que se desea conseguir. Como he dicho antes, subdividir el ticket en subtareas más pequeñas ayuda al alumno a organizarse mejor e ir paso a paso. También se incluye el diseño (si es un ticket que incluye desarrollar una pantalla).
Por último, se informa al alumno sobre el objetivo u objetivos con los que se van a trabajar y los criterios de evaluación que van a indicar si se ha superado o han superados.
Además, Github enlaza el código desarrollado por el alumno (Pull Request, lo veremos más adelante) con el ticket.
Gestión de ramas
Para la gestión de ramas en el controlador de versiones, seguimos la metodología GitFlow. Nuestra estructura de ramas era la siguiente:
- Rama Master: es la rama principal del proyecto. Es la rama de donde salen cada una de las versiones que se publican en el Play Store.
- Rama Develop: es la rama principal de desarrollo. Cuando un alumno quiere implementar una funcionalidad nueva, saca una rama para su feature de esta rama. Cuando termina la funcionalidad, solicita a través de una Pull Request la unión de la funcionalidad que acaba de implementar con la rama develop.
- Ramas ‘features’: cada alumno que vaya a implementar una funcionalidad, saca una rama de develop y crea una nueva para su funcionalidad.
Al finalizar la semana, sacábamos una rama de develop llamada ‘release’ donde sólo se subía la versión y se solicitaba la fusión con Master. Esta rama se fusionaba con Master y posteriormente, se actualizaba develop con la rama principal.
Pull Requests
Cuando el alumno termina la funcionalidad asignada, solicita al resto de compañeros que su funcionalidad sea añadida al proyecto. Esto se hace a través de una ‘Pull Request’. En nuestro proyecto, una pull request debía cumplir los siguientes requisitos:
- Descripción de la Pull Request. En este apartado el alumno detallaba qué funcionalidad había implementado.
- ¿Cómo se ha implementado?. En este apartado el alumno describía como había implementado la funcionalidad, los problemas encontrados y cómo los había resuelto.
- Keywords. El alumno elegía unas palabras claves que identificaban a la funcionalidad implementada.
- Screenshot o Vídeo. El alumno subía capturas de pantalla o un vídeo como evidencia del resultado logrado.
Además, el alumno elegía a dos compañeros como revisores. Estos revisores tenían el objetivo de ver el código y añadir comentarios si detectaban errores en el código o si tenían alguna alternativa de cómo implementar alguna de las funcionalidades existentes en el código.
Una vez los revisores y el autor del código resolvían todas las dudas o las diferencias, los revisores daban el ok al código para su fusión con el resto de la aplicación. Para que un alumno pudiera fusionar su código, necesitaba los dos checks de sus compañeros.
Pair Programming
En alguna ocasión, la funcionalidad era compleja y los alumnos podían optar por implementarla haciendo Pair Programming. Esta técnica consistía en ponerse en un ordenador con su compañero de Squad y entre los dos, intentaban resolver la funcionalidad a implementar. Lo normal es que sólo un alumno tuviera el teclado y se lo fueran intercambiando cada 15 minutos.
Con esta técnica, discutían sobre la forma de implementarlo y entre ambos se enriquecían al intercambiar distintas opiniones de cómo resolver el problema.
Capítulos:
- “Ávila en tapas”. Capítulo 1: Kickoff
- “Ávila en tapas”. Capítulo 2: Metodología
- “Ávila en tapas”. Capítulo 3: Desarrollo
- “Ávila en tapas”: Capítulo 4: Evaluación y Calificación
