La pasada semana presentamos a los alumnos de segundo del ciclo de Desarrollo de Aplicaciones Multimedia de la Universidad Europea el proyecto integrador para del curso 2014-15.
Se trata de un app para dispositivos móviles llamada “QIZit”; un app educativa bilingüe y se desarrollará para móviles y tabletas Android que incluirá elementos de ludificación.
Para este proyecto integrador nos hemos involucrado los profesores de los módulos de Acceso a Datos, Desarrollo de Interfaces y Programación Multimedia y Dispositivos móviles.
Junto a la presentación del proyecto, hicimos una presentación del framework de metodología ágil Scrum que será utilizado para el proyecto integrador; este framework se utiliza en las empresas de desarrollo de software para gestionar el desarrollo de productos, los equipos se organizarán por sí mismos fomentándose la colaboración de todos los miembros del equipo, así como a una comunicación diaria cara a cara de todos los miembros. La clave en las metodologías ágiles es la adaptación al cambio y encontrar soluciones a los nuevos problemas que puedan surgir según las necesidades del cliente o los cambios imprevistos que pueden no haber sido especificados en la planificación original.
Además en este proyecto se utilizarán principios de la programación extrema como son:
- Desarrollo iterativo e incremental
- Desarrollo guiado por pruebas (TDD) y pruebas unitarias
- Programación en parejas (Pair Programming)
- Integración del equipo de programación con el cliente
- Refactorización del código
- Simplicidad en el código
- Propiedad del código compartida en un repositorio (Github)
El desarrollo del proyecto se ha define sobre la idea de Sprints; un Sprint es un periodo de tiempo específico entre dos y cuatro semanas en el que el trabajo debe estar terminado y listo para la revisión. Al final de cada Sprint se hace una exposición de los objetivos conseguidos en el Sprint Retrospective.
En este proyecto se presentaron los componentes de los equipos; en estos grupos se repartieron cuatro responsabilidades que irán rotando en los sucesivos sprints:
- Coordinador del equipo
- Responsable del repositorio GitHub
- Responsable de la documentación del proyecto
Responsable de las pruebas de integración.
A su vez explicamos los roles de Scrum en clase:
- Product Owner (PO): Es el profesor que define los “ítems” que contendrá el Product Backlog y su orden.
- Scrum Master (SM): Es el profesor que supervisa y facilita que se aplique correctamente Scrum. No es un jefe de proyecto.
- Development Team (DT): Los equipos de alumnos, que se encargan de estimar el esfuerzo de los ítems del Sprint Backlog. Toman todas las decisiones dentro del Sprint.
- Scrum Team (ST): conjunto del PO, DT y SM. Se autoorganizan y son autosuficientes para realizar el Product Backlog
Ese mismo día se realizó la reunión del sprint planning; esta contenía dos partes principales:
Primero se hizo una selección de requisitos: El Product Owner (PO) y el Scrum Master (SM), presentaron a los Development Team (DT) la lista de requisitos priorizada del producto o proyecto en el backlog, un documento que se utilizará para todo el proyecto y que contiene las descripciones genéricas de todos los requisitos, funcionalidades deseables etc. Este es abierto y solo puede ser modificado por el PO.
Cada DT preguntó al PO las dudas que les surgieron y se seleccionaron los requisitos más prioritarios para completar en el primer sprint en forma de user stories (historias de usuario); un user story es una representación de un requisito de software escrito en el lenguaje común del usuario; estas permitan de forma rápida administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales, se suelen escribir en un post it con una estructura “Como (rol) quiero (algo) para (beneficio)”
- Cómo diseñador quiero realizar un análisis gráfico y funcional del diseño para crear la mejor experiencia de usuario.
- Cómo diseñador quiero realizar una maqueta de la aplicación para tener una visión global de la app
- Como desarrollador quiero un repositorio en GitHUB compartido con los integrantes del equipo para trabajar en equipo con garantías.
- Cómo programador quiero analizar los requisitos de hardware y software del app para implementarlos
- Como desarrollador quiero realizar la Creación de Virtual Devices y conexión de dispositivos físicos para comenzar con la implementación.
A continuación se realizó la planificación del primer sprint. Los DT elaboraron la lista de tareas del primer sprint necesarias para desarrollar los requisitos a los que se han comprometido.
La estimación de esfuerzo la realizaron de manera conjunta mediante planning poker; Es una técnica muy sencilla, eficaz y sobre todo divertida en la que todo el DT opina para estimar el esfuerzo de desarrollar cada una de las historias de usuario de un sprint. Lo normal es numerar las cartas con una serie de Fibonacci (0, 1, 1, 2, 3, 5, 8, 13, …), más la carta interrogante que equivale a “ni idea” y la carta infinito que equivale a “esto es demasiado grande”. Esto es así porque cuanto más grande es el número asignado mayor es la probabilidad de equivocarse en la estimación.
A continuación los TD pusieron las historias en el panel kanban y se autoasignaron las tareas.¡Es hora de ponerse manos a la obra! El tablero (kanban) ya tiene sus primeras user stories “in progress” e incluso algún “done” correspondientes al primer sprint!
Todos los alumnos están muy motivados con el proyecto, la información está fluyendo y están surgiendo ideas muy originales. Además recientemente realizaron una visita a Coritel dónde pudieron ver de primera mano como un equipo de desarrollo real utiliza Scrum para gestionar los proyectos.
