SPRINT 1

INDICE

1. PRODUCT BACKLOG - LA PILA.

2. Propuesta Inicial Interfaz Usuario.

3. SPRINT REVIEW.

4. SPRINT RETROSPECTIVE.

3. SPRINT REVIEW

• Objetivo del Sprint: realizar prototipo_1 del MVP

  3.1 Sprint Backlog.

  
  

  3.2 Actividades realizadas.

  • Librería GESCAZA (GitHub).
  • Layout Front App (GitLab).
  • CRUD CAZADOR (API Spring).
  • CRUD CAZADOR (Front Angular).
  • Despliegue inicial de la App GESCAZA.
  
  

  3.3 Actividades pendientes.

  1. En desarrolo:

  • CRUD EVENTO CAZA (API Spring).
  • CRUD EVENTO CAZA (Front Angular).
  • Consulta de Eventos de Caza desde Agenda.
  • Autenticación de usuario.
  • Notificación de evento al usuario.
  
  

  3.4 ¿Qué actividades se van a realizar a continuación?

  1. Actividades pendientes del Sprint 1:

  • Pasar incidencias al Sprint 2.

  2. Iniciar actividades del Sprint 2:

  • CRUD Evento Caza (API Spring).
  • CRUD Evento Caza (Front Angular).
  • Consulta Evento Caza Servicio Cadendly.

3.5 Cambios realizados tras finalizar el Sprint.

1. Servidor Web: Netlify.

En principio se iba a utilizar GitHub Pages, pero se descarta porque en nuestro entorno corporativo no está autorizado.

2. SGBD ElephantSQL.

ElephantSQL ofrece de forma gratuita mejores condiciones que Heroku Postgres (20MB de datos y 5 conexiones concurrentes frente a Heroku Postgres que no ofrece almacenamiento y 20 conexiones, en sus versiones gratuitas).

3. ¿Sistema de autenticación?.

Pendiente de decidir con el cliente.

4. Diseño Interfaz de Usuario.

Se ha cambiado la propuesta incial realizada al cliente, porque se considera que con esta versión se ha mejorado la usabilidad y facilidad de uso de la web. No obstante, pendiente de confirmación por el cliente.

3.6. Diagrama de Clases de Diseño.

Libreria

3.7. Demostración funcionamiento App

App GESCAZA.

Subir

4. SPRINT RETROSPECTIVE

4.1 Esquema Burndown.

Las incidencias relacionadas con el CRUD del Cazador se han cerrado después de finalizar el Sprint.

4.2 Problemas encontrados

• Falta de experiencia en general. Se ha notado la falta de experiencia en desarrollo, sobre todo a la hora de realizar el Sprint Backlog, estimando correctamente las incidencias.

• Persistencia en ElephantSQL. Cambia los tipos de los campos id autogenerados automáticamente desde la API.

• Fronted Angular. Comunicación entre componentes. Dificultad de realizar correctamente la comunicación entre componentes. De hecho nos hemos encontrado con el problema de que al editar ó eliminar un objeto de la clase Cazador, el navegador no responde bien.

• Backend Spring. Persistencia de clases de la librería gescaza. Se ha tenido alguna dificultad a la hora de persistir las clases de la librería.

• Tratamiento campos fecha. Debido a la falta de experiencia, se ha tenido dificultad a la hora de tratar con campos de tipo fecha.

4.3 Errores.

• Mala planificación y estimación de las tareas. No se ha realizado correctamente el Sprint Backlog. Al principio no se concretaban las incidencias y se estimaban mal. Por lo que se ha tenido que ir corrigiendo según se iba avanzado en el Sprint.

• Falta de constancia. Ha sido el error más importante, la falta de constancia en el trabajo del proyecto a mermado considerablemente cumplir con el objetivo del Sprint.

• No priorizar bien las tareas. Se ha perdido tiempo en incidencias menos importantes, como por ejemplo, la interfaz de usuario. Dedicándole más tiempo de lo necesario.

• Realizar pocos test. Debido a la premura de tiempo, ya que se iba muy atrasado con el Sprint, se tenían que haber realizado más test.

4.4 ¿Cómo se puede mejorar?

• Daily Scrum. Es fundamental tener una reunión diaria finalar cada jornada de trabajo.

• Constancia de trabajo. La clave del éxito es la constancia. Esto ha sido un problema. Es necesario y muy importante mantener una cadencia de trabajo constante en el proyecto.

• Realizar únicamente las tareas programadas. Centrarse exclusivamente en aquellas incidencias que están programadas y en el orden priorizado.

• Realizar más test de comprobación. Debemos dedicarle más tiempo a la realización de test para dar por finalizado una incidencia.

• Mantener contacto constante con el cliente. Debemos incluir un enlace del cliente con el equipo de desarrollo para solventar aquellas incidencias que surgan así como obtener feedback de cualquier tema que surga.

4.5 Aciertos.

• Empezar por el diseño. Es fundamental tener un buen diseño para que no perdamos tiempo en desarrollar algo que después no funcione correctamente.

• Librería gescaza. A la hora de implementar la librería en el Backend de Spring, nos hemos adaptado a su diseño. Es decir, a la hora de implementarla, no hemos pensando en cómo adaptarla para después utilizarla en la API. Con esto hemos mejorado nuestra experiencia.

• Despliegue inicial de la App en la nube. Ha sido un acierto desplegar esta versión inicial en la nube, así podemos obtener el feedback del cliente y además podemos ir probando los servicios de la nube.

• Ejecutar la API con perfiles distintos (producción y desarrollo). Al configurar la API con estos dos perfiles nos permite de una forma cómoda, trabajar en desarrollo y probar la versión que tengamos en el despliegue.

### 4.6 Incremento - Librería Gescaza. Proyecto GitHub

• Interfaz Usuario. Layout Front

• CRUD CAZADOR.

  CRUD CAZADOR BACKEND

  CRUD CAZADOR FRONTEND

• Ejecutar la API con perfiles distintos (producción y desarrollo). Al configurar la API con estos dos perfiles nos permite de una forma cómoda, trabajar en desarrollo y probar la versión que tengamos en el despliegue.

• Despliegue inicial de la App en la nube.

  Proyecto GitHub

  Despliegue inicial nube

• Actualizar WIKI del proyecto. Se ha añadido en la wiki la documentación del Sprint 1.

Subir

Home