Para este proyecto estamos aplicando la metodología de Scrum para que podamos terminarlo de forma ágil y tengamos una mejor retroalimentación y control. Igual la estamos utilizando porque es una metodología flexible y adaptable
Para el control de calidad, el Scrum Master asignaba tareas desde el Monday, las cuales consistían en verificar la ortografía de todos los documentos que se encuentran en la rama dev. Normalmente estas tareas tenían un valor de 2 o 3 puntos, dependiendo la cantidad de documentos que se esperan obtener al final de cada sprint. Es importante destacar que estas tareas, podían ser realizadas en conjunto con algún integrante del equipo, para una correcta corrección de errores.
En cuanto a la calidad del código, se realizaron múltiples pruebas en cada Intent de la skill, usando enunciados diferentes para verificar que se está obteniendo el resultado esperado.
Durante todo el proceso de desarrollo se siguió una serie de normas que especifica Amazon, para que la skill pudiera estar disponible a todos los usuarios con Alexa. Estas normas pueden verificarse desde el siguiente link: https://developer.amazon.com/es-MX/docs/alexa/certify/certify-your-skill.html
A pesar de no contar con algún dispositivo oficial de Alexa, se realizaron pruebas en los dispositivos de cada integrante del equipo y en el emulador que nos provee la consola de Amazon.
Los roles asiganados son los siguientes:
-
Product Owner: Daniel Pliego Vega
- Es el responsable de verificar que se cumplan los requerimientos de los stake holders
- Es el responsable de hacer merge en la rama main y verificar que no haya conflictos en las otras ramas
- Cuando hay un conflicto de merge de 2 ramas él se encarga de resolver el conflicto
- Está en constante comunicación con los stake holders para asegurarse que se están cumpliendo sus exigencias
- Establece las métricas junto con el scrum master
-
Scrum Master: Omar Cauich Pasos
- Es el encargado de hacer el Backlog
- Es el gerente del Monday
- Cuando alguien tiene una duda sobre Scrum, él la resuelve
- Estable las métricas junto con el Product Owner
- Se encarga de que el proyecto no se atrase
- Es el encargado de hacer las reuniones
-
Developmet team:
- Carlos Fernando Sanchez Chuc
- Yajani Anahi Peraza Alcocer
- Emir Bellos Cruz
- Son los desarrolladores
- Son los que llevan a cabo lo planeado
- Diseñan, construyen y prueban los requerimientos
-
Stake holders: Dr. Edgar Cambranes Martínez y Dr. José Luís Lopez Martínez
- Establecen ciertos requerimientos
- Son los que validan la calidad del producto
- Son los que pagan (Con calificación)
Todos los integrantes tienen tareas y roles ya asignados para tener mayor orden en el proceso del proyecto
El backlog es donde se almacenan los requerimientos del proyecto ya antes establecidos con los stakeholders. Nosotros tenemos el backlog y los sprints en Monday.com
Los sprints son el corazón de Scrum, estos son entregables parciales del proyecto. Para nuestros sprints tomamos en cuenta los siguientes puntos:
- Haremos 4 sprints de 2 semanas aproximadamente los cuales no deberan ser de más de 3 semanas
- Llevamos el control de nuestros Sprints y backlog en Monday.com
Cada que empieza un sprint los integrantes del equipo arrastran las tareas desde el backlog hacia el sprint correspondiente
Otro pilar muy importante de Scrum son las constantes reuniones las cuales nosotros hacemos cada 4 días en vez de hacerlas diario como lo establece scrum, esto debido a que consideramos que se nos haría muy complicado hacer reuniones todos los días por las tareas y por qué algunos integrantes del equipo trabajan
Nuestro equipo de trabajo se acerca en un 70% a la metodología Scrum al momento realizar el proyecto. Se podría decir que tomamos las mejores partes de Scrum, para adaptarlas a nuestra manera. Un ejemplo de ello sería las "Daily Scrum", en nuestro caso son reuniones cada 4 o 7 días, según la disponibilidad de los integrantes.
Nuestro "Product Backlog" es realizado por el Scrum Master, el cual prioriza las tareas de acuerdo a su fecha de entrega, ya que algunas dependen de otras actividades y deben ser terminadas en una fecha específica, para agilizar el proceso.
Los Sprints tienen distinta duración, algunos duran 1 o 2 semanas de acuerdo con las características que buscamos implementar. Si alguna tarea no se realiza en el tiempo estimado, se regresa al backlog.
Lo más cercano que tenemos a un Sprint Review, son las exposiciones de avances en clase en donde recibimos comentarios de los profesores para saber si vamos en buen camino.
Nosotros no realizamos un Sprint Retrospective, ya que consideramos que nuestro equipo trabaja bien con el proceso actual.