Proyecto final

El proyecto final de ED consistirá en lo siguiente:

El objetivo

Desarrollar una aplicación que funcione en equipos de dos o más personas, utilizando para ello la filosofía expuesta a lo largo del curso:

  • Empleo de una metodología ágil para el desarrollo del proyecto.
  • Uso de IDE's para optimizar y automatizar tareas rutinarias durante la escritura de código.
  • Utilización de herramientas que automaticen tareas tediosas, como la intalación de librerías, la carga de dependencias, etc.
  • División en capas del proyecto utilizando el patrón MVC.
  • Modelado y diseño arquitectónico empleando UML
  • Diseño arquitectónico de los contenidos mediante diagramas descriptivos de las vistas
  • Desarrollo orientado a pruebas, siempre que sea posible.
  • Uso de las ventajas del control de versiones.
  • Integración continua del proyecto
  • Despliegue continuo del proyecto

Las historias de usuario

Las historias de usuario del proyecto son las siguientes:

Descripción Valor
Existe un Backlog, al que se pueden añadir Historias de usuario. Las historias de usuario contienen la siguiente información:
  • Nombre/ID
  • Descripción
  • Valor de negocio
Se puede añadir una nueva Historia de usuario al Backlog en cualquier momento. Las historias de usuario también se pueden modificar y eliminar
1000
Un usuario puede crear un nuevo Sprint. El nombre de un nuevo Sprint, será la palabra Sprint seguido de un número autoincremental. Al crear un Sprint, éste tiene estado abierto. Un Sprint se puede cerrar, lo que quiere decir que ya no se trabajará más en él. No se puede añadir un nuevo Sprint hasta que el último Sprint esté cerrado. 500
Un Sprint puede tener una descripción, que se puede añadir durante la creación del Sprint. También se puede editar una vez que el Sprint ya ha sido creado. 10
Se puede asignar una Historia de usuario del backlog a un Sprint abierto. Este proceso se puede revertir mientras el Sprint siga abierto. Una vez cerrado, ya no se podrá modificar. Se debe poder consultar el Sprint backlog, para ver las Historias de usuario asignadas al Sprint. 100
Se pueden añadir nuevas tareas a cada Historia de usuario. Una tarea contendrá la siguiente información:
  • Nombre
  • Descripción
  • Lista de pruebas de aceptación
  • Coste estimado
  • Prioridad
Una tarea se puede modificar y eliminar. Se debe poder consultar las tareas asociadas a una Historia de usuario.
100
Se puede ver la evolución de cada Sprint mediante una tabla Kanban. En dicha tabla hay varios estados, como por ejemplo Por hacer, En proceso, Completado y No terminado. En dicha tabla se mostrarán las tareas asociadas a cada Historia de usuario. Inicialmente, las tareas aparecerán en la columno Por hacer, pero se pueden mover por la tabla Kanban. 50
En la tabla Kanban se deben distinguir las tareas de cada Historia de usuario de alguna forma, por ejemplo, mediante un color, una etiqueta, etc. La información mostrada de cada tarea en la tabla Kanban se limitará al nombre, coste y prioridad. Si se desea conocer más detalles sobre la tarea, se puede ver su información mediante algún mecanismo (hacer clic sobre ella, botón específico, etc.). 20
Un Sprint se puede cerrar solamente cuando todas las tareas estén en estado Completado o No terminado. Si hay Historias de usuario no completadas (porque hay tareas no terminadas), se puede crear una nueva Historia de usuario en el Backlog que incluya nuevas tareas no terminadas en el Sprint anterior. 10

Cómo se evaluará

Se prentende valorar la capacidad de cada equipo para abordar la resolución del proyecto utilizando los recursos aprendidos durante el curso, u otros nuevos que adquiera individualmente. Se van a observar los siguientes aspectos:

Planificación del proyecto utilizando Scrum (25%)

Se valorará el uso correcto de Scrum para planificar el proyecto, mediante fotografías de la evolución del mismo, incluyendo:

  • Backlog
  • Asignación de tareas a cada Historia de usuario, indicando coste, pruebas de aceptación, prioridad, etc.
  • Reparto de tareas entre los componentes del equipo
  • Evolución de la tabla kanban para el/los Sprints
  • Uso de un Burndown chart para el/los Sprints

Diseño de cada parte de la aplicación (25%)

Se valorará el diseño de los diferentes elementos de la aplicación mediante diagramas explicativos. Estos diagramas pueden incluir notación UML, diagramas de arquitectura de contenidos (navegación/interacción con el usuario), modelos E/R, y cualquier otro que el alumno considere necesario.

Uso de herramientas para el desarrollo (25%)

Se valorará el uso de las herramientas vistas durante el curso, así como cualquier otra que se desee incluir:

  • Gestión automática de paquetes, ya sea mediante Composer o mediante otra herramienta.
  • Desarrollo orientado a pruebas (TDD). Además de las pruebas, serán necesarias capturas donde se pueda ver las diferentes fases de las pruebas (rojo/verde).
  • Control de versiones, y repositorio centralizado. Es importante que se defina un work-flow y se siga durante el desarrollo del proyecto.

Funcionalidad (25%)

Además de lo anterior, se valorará que el software escrito funcione según se indica en las Historias de usuario.

Tal y como dice el manifiesto ágil

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación detallada
  • Colaboración con el cliente sobre negociación contractual
  • Repuesta ante el cambio sobre seguir un plan

¡OJO! Procesos, herramientas, documentación detallada, y planificación son necesarias, pero lo más importante es un programa que haga cosas.

Recursos de ayuda

Como apoyo para el proyecto, puedes consultar la evolución del proyecto https://github.com/mmatpein/miScrum. Además de esto, puedes encontrar los siguientes recursos:

  • Informacion variada como diagramas, información puntual de intercambio entre programadores, etc. en info que se irán añadiendo conforme el proyecto avance.

  • Taskboard del proyecto en TaskBoard