TÉCNICA UTILIZADA: LANCHA RÁPIDA (SPEED BOAT)

La lancha rapida (del ingles : Speed Boat) es una técnica que se puede utilizar para llevar a cabo la reunión de retrospectiva del sprint. Los miembros juegan el papel de la tripulación de la lancha. La lancha debe llegar a una isla: simbólicamente la visión del proyecto. 

Los asistentes utilizan notas adhesivas para llevar un registro de motores y anclas. Los motores ayudan a llegar a la isla, mientras que las anclas son cosas que están obstaculizando ola llegada. Este ejercicio tiene un bloque de tiempo asignado de unos cuantos minutos. Una vez que se documentan todos los elementos, se reúne la información, se discute y se prioriza por medio de un proceso de votación. Se reconocen los motores y se planifican las acciones de mitigación para las anclas dependiendo de la prioridad.

Por ello la estructura de la reunión consto de las siguientes etapas:

1.Presentación de los participantes de la reunión.

2.Cada uno de los participantes dictara las fortalezas y debilidades encontradas.

3.Discutimos sobre las debilidades (como solucionamos las debilidades).

A continuacion veremos en detalle cada una de las etapas.

PRIMERA ETAPA

Presentación de los participantes de la reunión.

-Stakeholder: Juan Rojas.

-Product Owner: Alvaro Condorchua

-Scrum Master: Julio Perez

-Equipo Scrum: David Trujillo, Rodolfo Ticona, Jhonatan Egocheaga, Paola Concepción, Yenuri Cordova.

SEGUNDA ETAPA

Cada uno de los participantes dictara las fortalezas y debilidades encontradas.

Fortalezas

Debilidades

·  Un equipo con las habilidades suficientes que pudieron afrontar lo que se realizó a pesar de los contratiempos ·  Somos un grupo de jóvenes con conocimiento de scrum y ganas de poner en practica nuestros conocimientos en casos reales ·  Obtener un nuevo panorama en cuanto al manejo de proyectos, proyectos agiles, una nueva visión de estos, y un mayor conocimiento en cuanto al SCRUM ·      Poder optimizar los procesos de un negocio nuevo para el eequipo.

·    Por temas de estudio y trabajo el trabajo en equipo era mucho más difícil, y nos tomaba mucho más tiempo coordinar y realizar las tareas ·      Mala gestión de nuestros tiempos que dificulto en algunos casos la comunicación con el equipo ·      Poca comunicación que he tenido con el equipo SCRUM Al momento de solventar sus dudas. ·      Poca organización entre el product owner y el equipo scrum.

TERCERA ETAPA

Discutimos sobre las debilidades (como solucionamos las debilidades).

Plantear los días disponibles de los integrantes del equipo para así poder planificar que días se realizaran las reuniones y estar todo. Además de que cada uno debe poner compromiso y dedicación

En proyectos futuros, pues afrontar lo mencionado anteriormente tomar un enfoque un poquito más sociable, y entablar mejores relaciones con los miembros del proyecto.

Utilizar técnicas y programas para poder controlar de la mejor manera nuestros tiempo tanto personales como del equipo.

EVIDENCIA DE LOS ENTREGABLES

Esta reunión se realizara con el objetivo de mejorar continuamente el producto que estamos desarrollando, el equipo analiza como fue su desempeño en el trayecto de la iteracion y evalúa si el producto demostrado en el segundo sprint era lo que el cliente esperaba o no.

PREPARAMOS EL ESCENARIO

Visualizamos el nivel de satisfacción con los resultados del sprint, la coordinación y el estado de animo, donde debatiremos la variaciones sorprendentes y los ánimos extremos.

Estos son los resultados de la dinámica que se realizo, dando como resultado un nivel insatisfactorio con respecto al cuarto sprint, como equipo vimos los riesgos que se vio en este sprint y estamos dispuestos a superar cada contratiempo y nos comprometimos a mejorar el producto.

TÉCNICA DEL BARCO DE VELA

Esta es una técnica para reflexionar sobre oportunidades, riesgos y problemas que ha habido en el sprint. En esta dinámica dibujaremos un barco en la pizarra, que va hacia una tierra prometida, donde esta es la visión de lo que el el equipo quiere llegar a ser y que es lo que quieren llegar a conseguir a nivel de procesos, desarrollo y como equipo.

Estos son los resultados de la dinámica, donde vemos el barco con nuestras fortalezas y debilidades reflejadas por el equipo y la tierra prometida reflejando los objetivos y amenazas.

NUESTRAS ACTIVIDADES

En esta dinámica se escriben las tareas que ejecutaremos durante el próximo sprint, quien lo desarrollara y cuando perecedera a realizarlo, comprometiéndose a que cada tarea sea realizada y cumplida en la fecha que se acordó. En esta ocasión las actividades para el próximo sprint no existen ya que hemos culminado con el proyecto.

CERRAMOS LA RETROSPECTIVA

El objetivo es que el equipo salga motivado para enfrentar los desafíos de este sprint, para ello utilizaremos la dinámica de "MAS & DELTA". Consiste en que cada participante de un aspecto de la retrospectiva que le gusto y una que cambiaría.

Como resultado de esta dinámica tenemos la participación de cada miembro y sus respuestas

Se ha procedido a demostrar y validar el Sprint previo verificando los criterios de aceptación por cada Historia de Usuario, en este 4° Sprint se han determinado 3 historias de usuario: HU15, HU17,HU19,HU14.

Criterios de aceptación de HU15:
 "Quiero que se genere un reporte de los miembros mediante búsqueda previa, los atributos ya registrados de los clientes del gimnasio además del tipo de membresía, fecha de vencimiento de esta."

- CA01: Existencia del módulo de reportes de miembros.

Estado: Validado

- CA02: Compagina-ción de los registros.

Estado: Validado.

- CA03: Acceso libre al módulo de reportes de miembros.

Estado: Validado


Criterios de aceptación de HU17:
 "Quiero mediante el módulo de membresías se genere un reporte de membresías vendidas mostrando los detalles del cliente que lo adquirió."

- CA01: Existencia del módulo de reportes de miembros.

Estado: Validado

- CA02:Al momento de hacer la búsqueda previo al reporte, el grafico debe permitir seleccionar  el año de membresías vendidas que se desea ver.

Estado: Validado.

- CA03:Cuando se despliegue en el menú la opción de reporte de membresías, deberá tener acceso restringido al modulo.

Estado: Validado

Criterios de aceptación de HU19:
 "Quiero generar un reporte de ingresos."

- CA01: La membresía puede modificarse según temporada o necesidad del miembro/cliente cuaando se muestran las membresías ya registradas se deberá poder modificar los atributos de la membresía, actualización de la membresía al hacer la consulta.

Estado: Validado

- CA02:Cuando acceda un rol ajeno al administrador se deberá restringir el acceso al empleado..

Estado: Validado.

Criterios de aceptación de HU14:
 "Quiero asignar a un cliente o miembro nuevo o existente una membresía con el respectivo pago."

- CA01:Cuando se asigna una membresía colocando la fecha de inicio, automáticamente se determina la fecha de vencimiento..

Estado: Validado

- CA02:Cuando se oprime el botón pagar se debe permitir generar una boleta en pdf indicando los datos básicos del pago...

Estado: Validado.


- CA03:Cuando se asigna la membresía y el pago deberá poder ser asignado por cualquier rol del sistema.

Estado: Validado.

En este demostraremos las funcionalidades del software en función a los criterios de aceptación con la finalidad de entregar un producto acorde a las prioridades del cliente.

                                          

REVISIÓN DEL SPRINT

Para la validación del Cuarto Sprint, estuvo presente el equipo de desarrollo, el product Owner, El Scrum Master, y el Stakeholder.

Al finalizar el Sprint se dedicó en una reunión de 3 horas.

En líneas generales la reunión de demostración y validación del Sprint se dio de la siguiente manera:

• El equipo demuestra un código de trabajo al Stakeholder
• Solo se mostró las historias 100% completadas.
• Las historias parcialmente completadas son ignoradas ( en este caso no hubo)
• Retroalimentación directa de los stakeholders
• La retroalimentación se incorporó en el Product Backlog.

El resultado de la revisión del Sprint es un Product Backlog revisado que define los ítems del Product Backlog de mayor valor o probables para el siguiente Sprint. El product Backlog también se puede ajustar en general para satisfacer las nuevas oportunidades.

LINK-REFINAR BACKLOG PRIORIZADO DEL PRODUCTO

Consiste en una reunión diaria donde se realiza la ceremonia sobre el de un proyecto. Esta herramienta es perfectamente aplicable a cualquier trabajo en equipo que necesite sincronizarse para conseguir los objetivos del sprint. Esta reunión también permite resolver muchos conflictos y la facilita los tiempos para que el equipo puede participar.
Guías especificas para realizar la reunión:

• La reunión comienza puntualmente a su hora.
• Todos son bienvenidos, pero solo los involucrados en el proyecto pueden hablar.
• La reunión tiene una duración máxima de 15 minutos, de forma independiente del tamaño del equipo.
• La reunión debe realizarse en la misma ubicación.

Durante la reunión, cada miembro del equipo debe contestar tres preguntas y verificar si se están cumpliendo los plazos marcados para el Sprint.

• ¿Que has hecho?
• ¿Que es lo que haré hoy?
• ¿Has tenido algún inconveniente que te haya impedido alcanzar tu objetivo?

EVIDENCIAS DE LAS REUNIONES DIARIAS

IMPEDIMENTOS QUE SE INFORMARON EN LAS REUNIONES DIARIAS
DOCUMENTOS

LINK-LISTA DE INCONVENIENTES 1
LINK-LISTA DE INCONVENIENTES 2
LINK-LISTA DE INCONVENIENTES 3

En el Trello podemos visualizar las tareas que se han ido realizando y las personas responsables de realizar dichas tareas, y el estado en el que se ha ido ejecutando una tarea.

CREANDO ENTREGABLES (SOFTWARE)

SOFTWARE CUMPLIENDO CON LAS HISTORIAS DE USUARIO