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

Lista de tareas que el equipo elabora en la reunion de planificacion de la iteracion como plan para completar los objetvos o requisitos seleccionados para la iteracion y que se compromete a ddemostrar al cliente al finalizar la iteracion,m en forma de incremento de producto preparado para ser entregado.

SPRINT BACKLOG

Asi mismo podemos apreciar las historias de usuario contenidos en el sprint backlog con su respectiva estimación y prioridad que indicaron que debían ser contenidos en el tercer sprint

LINK-SPRINT BACKLOG

ESTIMACIÓN DE TAREAS

Esta es la técnica más usada debido a la habitual falta de datos históricos. Como su nombre indica, esta técnica consiste en que una persona que conozca y tenga experiencia en la tarea estime su duración más probable, esperando que la experiencia y conocimiento del experto sustituya la falta de datos.

Esta técnica está muy cerca de la suposición, y la aceptación del cronograma por parte del equipo del proyecto y el sponsor va a depender de la reputación del experto, lo que puede debilitar la posición de director del proyecto a la hora de defender el cronograma.

Una forma de reducir los problemas inherentes a esta técnica es usar un grupo de expertos en lugar de una única persona. Ente caso se puede coger el valor medio del grupo.

BURNDOWN CHART

Un diagrama Burn Down o diagrama de quemado es una representación gráfica del trabajo por hacer en un proyecto en el tiempo. Usualmente el trabajo remanente (o backlog) se muestra en el eje vertical y el tiempo en el eje horizontal. Es decir, el diagrama representa una serie temporal del trabajo pendiente. Este diagrama es útil para predecir cuándo se completará todo el trabajo. Usualmente se usa en el desarrollo ágil del software, especialmente con Scrum.

LINK-RESULTADO DE LA ESTIMACIÓN

El equipo Scrum identifica las tareas que se realizaran en este cuarto sprint donde se realizara la respectiva asignacion a cada mienbro, para que cada uno pueda cumplir con dichas tareas y evaluar su progreso durante el desarrollo de este tercer sprint.

TAREAS IDENTIFICADAS

Lista de tareas que el equipo elabora en la reunion de planificacion de la iteracion como plan para completar los objetvos o requisitos seleccionados para la iteracion y que se compromete a ddemostrar al cliente al finalizar la iteracion,m en forma de incremento de producto preparado para ser entregado.

En  este proceso el equipo Scrum se compromete a entregar al Produt Owner las historias de usuario para un sprint. El resultado de este proceso serian las historias de usuario comprometidas.

HISTORIAS DE USUARIO COMPROMETIDAS

LINK-COMPROMETER HISTORIAS DE USUARIO

El equipo de desarrollo debe poder estimar las historias de usuario. Es un requisito fundamental  para poder planificar de manera responsable las historias que se pueden desarrollar dentro de un sprint.

PLANING POKER

Es una tecnica para calcular una estimacion basada en el consenso, en su mayoria utilizada para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de sotfware. 

LIMK-MÉTODO PLANING POKER

APLICAMOS EL PLANING POKER

En esta reunión estimamos las historias de usuario dando como resultado lo siguiente:

LINK-ESTIMACIÓN DE LAS HISTORIAS DE USUARIO

Una historia de usuario es una representación de un requisito escrito en una o dos frases utilizando el lenguaje común de usuario. Las historias de usuario son utilizadas en las metodologías ágiles para la especificación de requisitos.
Estas historias son una forma rápida de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir mucho tiempo para administrarlos, ademas permiten responder rápidamente a los requisitos cambiantes.

HISTORIAS DE USUARIO DEL CUARTO SPRINT

¿Cómo evaluamos la calidad de las historias de usuario?

Aplicamos una de las técnicas variadas, como es el caso propuesto por Ron Jeffries, el propone la fórmula de las Tres C. La historia de usuario cumple bien su papel cuando atiende 3 características C las cuales son:

• Card (Tarjeta) : Es pequeña, lo suficiente para caber en una tarjeta
• Conversación: consigue promover la comunicación  entre el usuario y el equipo dando un entendimiento común de la funcionalidad que será entregada.
• Confirmación: El comportamiento esperado para confirmar su alcance. También conocido como plan de pruebas, escrito en el reverso de la tarjeta

LINK-HISTORIAS DE USUARIO

CRITERIOS DE ACEPTACIÓN

Los criterios de aceptación brindan claridad al equipo respecto a lo que se espera en una historia de usuario; eliminan la ambigüedad de los requerimientos, ayudando a la alineación de las expectativas. El Product Owner define y comunica los criterios de aceptación al equipo Scrum.

¿Qué técnicas usamos para escribir los criterios de aceptación?

Hemos utilizado dos técnicas, la técnica de comportamiento y la técnica de escenarios:

• Técnica de comportamiento : Se establece una condición, cuando ocurre una acción o evento, sucederá una consecuencia.  Ello fue la estructura que empleamos en la redacción de los criterios de aceptación.
• Técnicas de escenarios: Se propone dos trayectos "el feliz" y uno "alternativo" de la funcionalidad en cuestión y debe describir como el usuario ejecutaría o intentaría ejecutar los diferentes pasos en dichos trayectos. Gracias a ello se eliminó información innecesaria, el usuario procedería y el sistema correspondería.

LINK-CRITERIOS DE ACEPTACIÓN

El objetivo de esta planificación de lanzamiento es determinar las funcionalidades en las que se va a trabajar durante este Sprint. Entregando cierta cantidad de producto con cierta calidad y en cierto intervalo de tiempo.
Este plan se crea con la colaboración de todo el equipo Scrum, donde definirán las funcionalidad en el incremento planeado y como el equipo de desarrollo creara este incremento y la salida de este trabajo es definir el objetivo del sprint.

NUESTRO PLAN DE LANZAMIENTO

CRONOGRAMA DE TRABAJO

PRODUCT BACKLOG PRIORIZADO

Es una lista priorizada de historias de usuario detalladas que sirve para tener una perspectiva de todo lo que se quiere hacer y tener claras las prioridades del cliente. Ayuda a que el equipo sea mas auto disciplinado y respete las prioridades del cliente.

PRIORIZACION DEL PRODUCT BACKLOG (THEME SORING)

El Theme Scoring es una técnica que permite determinar la prioridad de las funcionalidades como una combinación de diferentes criterios, a los que se puede dar diferente importancia. A cada historia de usuario se le asigna un peso de 1 a 5 en cada una de las características. Para ello, por cada característica se elige una historia de usuario de referencia, que tengan un valor medio de 3. A las demás historias de usuario se les asigna el peso en cada característica en comparación con la historia de usuario de referencia. La estimación de una característica por comparación es siempre mucho mas sencilla y rápida que la estimación de una media absoluta.

HISTORIAS DE USUARIO PRIORIZADAS PARA ESTE SPRINT

De la priorizacion anterior del tercer sprint utilizando el theme scoring, tomamos las hitorias de usurio numero 15, 17, 19 y 14 ya que estas historias de usuario son las que quedaron para este cuarto sprint.

LINK-PRIORIZACION DEL PRODUCT BACKLOG

ÉPICAS

Cuando estamos trabajando en un sprint , una posible estrategia de desarrollo la tenemos dividiendo todas o algunas historias de usuario en tareas, ya sea por cuestión de tamaño, por la posibilidad de dividir el trabajo entre diferentes desarrolladores, etc.

Una épica no es mas que un nivel de agrupación por encima de las historias de usuario que permite clasificar las mismas por funcionalidades, módulos, subsistemas, etc. Es decir, se tiene en mente una imagen abstracta de lo que quiere obtener con la épica (que se desarrollara probablemente en varias iteraciones), pero son las historias de usuario, su implementacion en los sprints y el feedback los que terminan de darle finalmente la forma.

DESARROLLO DE ÉPICAS

Para el desarrollo de nuestro producto no clasificamos las historias de usuario, es decir no hay épicas. Trabajamos en base de las mismas historias de usuario.

EL EQUIPO DE DESARROLLO EN SCRUM

Los miembros del equipo de Desarrollo, también conocido como "equipo", son especialistas de área, y responsables de entregar los elementos del Backlog, y de la gestión de sus propios esfuerzos.

Un equipo de desarrollo debe ser multifuncional. Ademas, debe auto-organizarse, ser responsable y capaz de encontrar su propio camino en lugar d recibir ordenes, y al respecto deberá alinearse con el propósito del proyecto y no trabajar "a ciegas".

Durante el sprint una tarea podría asignarse a un solo miembro del equipo, pero todo el equipo de desarrollo sera responsable de esa tarea; ningún individuo es dueño de una tarea.

El equipo de desarrollo entrega el producto paso a paso, de manera incremental, tal y como esta definido en el Backlog del producto. El equipo siempre trabaja enfocado en el producto.

El equipo Scrum esta conformado por:

• David Trujillo Rengifo.
• Jonathan Egocheaga Oscco.
• Paola Concecpcion Reyes.
• Rodolfo Ticona Vilcapaza.

Los criterios que tomamos en cuenta para el equipo Scrum se basan en las habilidades que poseen ya sea de análisis, diseño, desarrollo,etc. para este grupo de personas es importante el trabajo en equipo ya que es organizado, responsable y colaborativo.

DESCRIPCIÓN GENERAL

SCRUM MASTER

El Scrum Master tendría una figura similar a la de un couch/mentor que acompañara al equipo durante todo el desarrollo del proyecto y asegurara que se cumplan las buenas practicas, actuando como un facilitador y solucionador de problemas.
Entre otras funciones, el Scrum Master debe:

• Asesorar y formar a los diferentes miembros para trabajar de forma auto organizada y con responsabilidad de equipo.
• moderar las reuniones.
• Gestionar las dinamicas de grupo en el equipo.
• Encargarse de la configuración, diseño y mejora continua de las practicas de scrum en la organización.

SCRUM MASTER IDENTIFICADO

El Scrum Master es Julio Perez Gomez, ya que nuestros criterios se basan en el buen desempeño como líder, es el que guía al equipo para que trabaje de manera organizada cuidando de que las reuniones prosperen y no tengan interrupciones, también es el encargado de hacer entender al equipo acerca de la metodología Scrum.

STAKEHOLDER IDENTIFICADO

El stakeholder es Juan Rojas ya que es la persona quien hara posible el proyecto y quien tendrá beneficio de la misma. Ademas, participara directamente durante las revisiones del sprint.

OBJETIVO GENERAL DEL PROYECTO

Implementar un sistema de información encaminado al adecuado control y organización de la información de socios del gimnasio "BodyLife", mediante la complementación de una propuesta de desarrollo ágil.

OBJETIVOS ESPECÍFICOS DEL PROYECTO

• Prever los cambios y permitir actualizaciones en el sistema de información.
• Brindar herramientas que permitan definir y controlar el registro de usuarios y socios en el gimnasio
• Controlar  y mantener un historial de la venta de membresías y/o "visitas" de los socios.
• Generar reportes de los ingresos del gimnasio a fin de la mejora en la toma de decisiones.

JUSTIFICACIÓN DEL NEGOCIO

En la actualidad, el gimnasio tiene varios problemas entre ellos:

• Inadecuada gestión de los socios del gimnasio, actualmente se tiene un registro manual de los clientes en el gimnasio por medio de un libro y entrega de carnets para identificar al socio del gimnasio.
• Falta de acceso a la información actualizada del estado de membresia de los socios, que ocasiona que no se pueda generar una respuesta rápida ante la solicitud del estado de actividad o inactividad del socio del gimnasio.
• Falta de seguimiento a la actividad de los socios, generando que el administrador o empleado pueda tomar decisiones en cuanto a beneficios o membresias con precios especiales a fin de fidelizar a los socios.
• Falta de acceso a la información actualizada de los ingresos por concepto de membresia y/o "visitas" al gimnasio de los socios, ello conlleva a no manejar los recursos económicos del gimnasio para la mejor toma de decisiones.
• Inadecuado control de asistencia de los socios al gimnasio así como el tiempo restante para el vencimiento de la membresía, ello genera lentitud y posiblemente falsificación de los carnets por parte de los socios.
• Estos problemas generan que el gimnasio pierda o retrasen potenciales ventas del gimnasio así como la merma en el servicio que como consecuencia ocasionan daños económicos a la misma.
• Los sistemas web son implementados con el fin de mejorar los proceso del negocio del gimnasio y mejorar el servicio a sus socios. Por ello el presente proyecto se realizará en un sistema web con el objetivo de generar valor con la mejora en el manejo de la gestión de usuarios, socios, membresias, registros de pagos para el gimnasio BodyLife.

Mejorar la calidad de vida, salud mediante la filosofía del gimnasio a través de los diferentes servicios que ofrece BoydLife, promover el ejercicio físico en la comunidad.

Ser el gimnasio líder brindando bienestar a nuestros socios y en general a la comunidad, generando valor a nuestra empresa, y a nuestros colaboradores.