-
Notifications
You must be signed in to change notification settings - Fork 0
Proceso de desarrollo a seguir
Para la selección de metodología, tras un breve debate, se llegó a la conclusión de que el mejor enfoque sería un enfoque ágil centrado en la iteración, debido a que inicialmente no están claros todos los aspectos y alcance del proyecto. Por este motivo, se decidió elegir SCRUM, pero modificándolo a las necesidades del proyecto y el equipo.
En SCRUM, los roles son definidos en 3 categorías: Product Owner, Scrum Master y Developer. Como método de aprendizaje, se ha elegido un sistema rotativo de roles, estos están agrupados por las historias de usuario, y se ha tomado como criterio para poder dividir estas el tiempo necesario para poder realizarlas dando lugar a un reparto equitativo.
Equipo | Scrum Master | Product Owner | Desarrolladores | Historias De Usuario |
---|---|---|---|---|
Equipo 1 | Sr.Blanco | Sr.Marrón | Sr.Naranja Sr.Azul | HU-008 HU-009 HU-013 HU-015 HU-016 |
Equipo 2 | Sr.Marrón | Sr.Naranja | Sr.Blanco Sr.Azul | HU-001 HU-002 HU-014 HU-017 |
Equipo 3 | Sr.Naranja | Sr.Azul | Sr.Marrón Sr.Blanco | HU-010 HU-011 HU-012 HU-004 HU-005 HU-006 |
Equipo 4 | Sr.Azul | Sr.Blanco | Sr.Naranja Sr.Marrón | HU-003 HU-007 |
En la reunión inicial, se llegó a la conclusión de que deberá adaptarse la periodicidad de los diversos hitos de SCRUM con la periodicidad semanal de clases y laboratorios, por lo que, para aprovecharse al máximo los laboratorios, se unirán los 3 principales eventos de SCRUM en el laboratorio de GPS de cada Viernes a las 17:00.
En nuestra adaptación de SCRUM, iniciaremos la clase haciendo la revisión del sprint, seguidamente pasaremos a hacer la retrospectiva para corregir problemas hallados y, una vez solucionados, corregidos y mejorados dichos problemas o procesos, pasaremos a hacer la planificación de la siguiente semana. En caso de no haber conseguido terminar a tiempo de hacer todo el proceso, se convocará una reunión del equipo, lo más pronto posible. Ese mismo día o al día siguiente. Sobre la revisión diaria, se ha optado por no hacerla.
Empezaremos haciendo una revisión general del estado actual del proyecto, comentando lo que cada persona ha sido capaz o no de hacer y de incidencias, problemas surgidos durante la semana.
Durante la retrospectiva, se buscarán soluciones a los problemas planteados durante la revisión del sprint, permitiendo así la iteración sobre el proceso y su consiguiente mejora.
Una vez teniendo las ideas más claras sobre cómo funcionar para la próxima semana, se hará una planificación del siguiente sprint teniendo en cuenta las nuevas consideraciones. En este punto se pedirá la colaboración del Product Owner para alinear los objetivos del equipo con los del dueño del producto.
En este caso, no se harán reuniones diarias para mantener actualizado al equipo del proceso de cada individuo ya que los sprints son de corta duración y debido a los distintos horarios de los miembros del equipo, no hay una periodicidad diaria común que permita hacer dichas reuniones con comodidad.