1.Crear la Vision del Proyecto

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.

2.Identificar al Scrum Master y Stakeholder

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.

3.Formar equipos Scrum

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.

4.Desarrollar epicas

É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.

5.Crear el Backlog Priorizado del Producto

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 QUE SE PRIORIZARAN PARA ESTE SPRINT

De la priorizacion utilizando el theme scoring, nos da como resultado las hitorias de usurio numero 11, 12 y 13. Estas historias tienen mayor prioridad, por tanto, son las que desarrollaremos en este tercer sprint.

lLINK-PRIORIZACION DEL PRODUCT BACKLOG

6.Realizar la planificacion de Lanzamiento

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

7.Crear 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.

¿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

LINK-CONTROL DE CAMBIO

8.Estimar 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. 

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

9.Comprometer Historias de Usuario

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

10.Identificar Tareas

El equipo Scrum identifica las tareas que se realizaran en este tercer 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.

11.Estimar Tareas

ESTIMACIÓN DE TAREAS

BURNDOWN CHART

LINK-RESULTADO DE LA ESTIMACION

12.Crear el Sprint Backlog

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

Ítem	Historia de usuario	Estimación	Prioridad	Tarea
11	Como empleado quiero registrar la asistencia de un miembro al gimnasio mediante el código para tener un control de la asistencia de los clientes / miembros mediante el sistema	2	3,8	Crear el módulo de asistencia
				Crear la interfaz del control de asistencia.
				Agregar tabla asistencia en la base de datos.
				Creación de consultas para identificar miembros /clientes por DNI (código)
				Crear opciones de menú: agregar asistencia, asistencia.
				Agregar en la interfaz de usuario la opción de agregar un miembro ya registrado
12	Como empleado quiero registrar una membresía en función al número de meses, asignándoles un precio respectivo; con la finalidad de fijar los precios de acuerdo a la temporada alta o baja en el gimnasio.	5	4,1	Crear módulo de membresía
				Crear interfaz de registro de membresía.
				Establecer las clases y métodos necesarios para registrar y asignar membresía a un miembro.
				Crear opciones de menú: agregar membresía, membresía.
				Agregar tabla membresía a la base de datos.
13	Como administrador quiero editar y/o eliminar una membresía ya registrada para actualizar los precios según la demanda o temporada en el gimnasio.	3	3,8	Creación de un update para actualizar una membresía
				Creación de un update para modificar los precios
				Creación de una consulta para filtrar membresías
				Establecer las clases y métodos para la edición y/o eliminación de las membresías además de las sentencias sql respectivas.

13.Crear Entregables

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.

ENTREGABLES (SOFTWARE)

14.Realizar Daily Standup

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 DE INCONVENIENTES N°1
LINK DE INCONVENIENTES N°2
LINK DE INCONVENIENTES N° 3
LINK DE INCONVENIENTES N° 4

15.Refinar el Backlog Priorizado del Producto

LINK-REFINAAR EL BACKLOG PRIORIZADO

16.Demostrar y Validar el Sprint

DEMOSTRAR Y VALIDAR EL SPRINT

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

Criterios de aceptación de HU11:
 "Como empleado quiero registrar la asistencia de un miembro al gimnasio mediante el código (DNI) para tener un control de la asistencia de miembros mediante el sistema."

- CA01: En caso se desee autocompletar los datos del cliente cuando se ingresa el DNI del miembro/cliente se muestra automaticamente los datos de los mismos.

Estado: Validado

- CA02: En caso se desee registrar la asistencia de un miembro (cliente) en el gimnasio cuando se entre al módulo de asistencia se deberá mostrar la hora y fecha que coincida con la hora y fecha de la computadora por defecto, se registrará la hora del sistema al dar click en registrar.

Estado: Validado.

- CA03: El usuario del sistema podrá registrar la asistencia del miembro/cliente del gimnasio cuando se despliegue en el menú la opción de registro de asistencia, deberá tener libre acceso para cualquier usuario (activo), opción de registrar asistencia por un usuario.

Estado: Validado


Criterios de aceptación de HU12:
 "Como empleado quiero registrar una membresía en función al número de meses asignándoles un precio respectivo con la finalidad de fijar los precios de acuerdo a la temporada alta o baja en el gimnasio"

- CA01: La membresía será clasificada en función al número de meses cuando se registra una membresía se mostrará un combobox indicando la cantidad de meses, así mismo se ingresará un nombre a la misma, la membresía registrada estará en función al número de meses seleccionado.

Estado: Validado

- CA02: En función de la temporada una membresía puede variar su precio de acuerdo al intervalo de tiempo cuando se registra una membresía se le deberá registrar un intevalo de tiempo que permita manejar el precio con el miembro/cliente, la membresía estará en función a un intervalo de tiempo en caso se requiera un precio especial.

Estado: Validado.

- CA03: El registro de membresía lo controla el administrador, cuando se registre una membresía nueva con sus atributos, será solo permitido por el administrador; el registro de la membresía por parte del empleado.

Estado: Validado

Criterios de aceptación de HU13:
 "Como administrador quiero editar y/o eliminar una membresía ya registrada con la finalidad de actualizar los precios según la demanda o temporada en el gimnasio"

- 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: Confirmar la edición de membresía mediante un aviso cuando se procede a editar una membresía se deberá avisar antes de hacer los respectivos cambios, ello permitirá la confirmación de edición de la membresía.

Estado: Validado.

- CA03: La edición de la membresía lo realiza solo el administrador, cuando se quiera variar los atributos de una membresía ya existente se deberá realizar con el rol de administrador.

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 Tercer Spint, 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.

17.Retrospectiva del Sprint

A continuación se detallará los detalle de la reunión de retrospectiva del tercer sprint.

¿Quién?
El equipo de desarrollo
El Product Owner
El Scrum Master

¿Cuándo y cuánto?
Después de la revisión del sprint
Duración: 1.5 horas.

Entrada
Información de los equipos acerca del tercer sprint.

Salida
¿Qué salió bien?
Mejoras potenciales
Plan de mejoras.

El grupo creyó conveniente revisar la literatura, por ello se tomó como referencia el libro:

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

• Preparar el escenario
• Coleccionar data.
• Generar aprendizaje
• Determinar que hacer
• Cerrar Retrospectiva

A continuación veremos en detalle cada una de las etapas de la reunión:

1. Preparar el escenario
-Técnica Armar El Escenario:
Para ello se graficó en la pizarra el primer cuadrante del plano cartesiano en la cual en el eje de las abscisas se coloca cerca al origen de coordenadas: "Insatisfecho" y más a la derecha "Muy" Cantidad de veces que coordinamos, y en el eje de las ordenadas cerca al origen "insatisfecho" y más arriba "Muy" Satisfacción del resultado del tercer sprint, ello se puede observar la siguiente dinamica:

Los resultados fueron:

2. Coleccionar data.
-Técnica el Barco de Vela
Para ello se grafica un barco de vela con un ancla en la cual los participantes de el equipo de desarrollo colocarán las fortalezas y debilidades que identificaron en la realización del tercer sprint.

tal como se muestra en la siguiente imagen:

Los resultados fueron:
Fortalezas:
- Comunicación en el equipo de desarrollo ya que hoy en día el equipo se encuentra cursando estudios en la UNTELS y todos pertenecen al mismo ciclo, por ello la comunicación es fluida.
Unión en el equipo, ya que la interacción es constante ya que pertenecemos a la misma universidad.

- Conocimiento del Scrum, los integrantes del equipo nos hemos capacitado en el curso ofrecido por la plataforma Udemy en el curso "Scrum Master + la revolución ágil + liderar equipos Scrum"

Debilidades:

- Poco tiempo de los integrantes, ya que la mayoría de estudiantes del equipo de desarrollo trabaja para autosostenerse.

- Falta de un espacio de coordinación en el equipo, si bien es cierto contamos con la universidad para hacer las coordinación pero no se cuenta de un espacio adecuado para llevar a cabo las reuniones diversas que sugiere el Scrum.

- Equipo saturado de actividades de actividades académicas, ya que cada estudiante lleva 6 cursos en la universidad y sumado con el trabajo; ello hace que tengamos un equipo "Multitarea" lo cual Scrum no recomienda, ya que debemos enfocarnos en el desarrollo del proyecto.

- Falta de empeño en ocasiones, el cansancio y saturación nos hizo desviar en ocasiones lo planificado en el sprint sin embargo al final se cumplió con lo establecido.

- Falta de coordinación en el equipo, ello por consecuencia de falta de un espacio geográfico adecuado para reunirnos.

Oportunidades:

Amenazas:

3. Generar aprendiza y determinar que hacer

 Se usó una dinamica que consistió en formular las siguientes preguntas:

¿Qué?

¿Quién?

¿Cuándo?

Cada integrante del equipo de desarrollo escribió las tareas que se harían del cara al 4° Sprint:

 

  

estos fueron los resultados de la dinamica:

4. Cerrar la retrospectiva

Se usó la técnica "Más y Delta", lo cual permitió que los integrantes del equipo participen opinando o que le gustó de la reunión y que no le gustó de la reunión.

Los resultados son los siguientes:

18.Enviar entregables

EVIDENCIA DE LOS ENTREGABLES

VÍDEO DEL ENTREGABLE

REUNIÓN DE RETROSPECTIVA SEGUNDO SPRINT

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 segundo 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 escribiremos las tareas que ejecutaremos durante el tercer 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ó.

RESULTADOS DE LA DINAMICA

CERRAMOS LA RETROSPECTIVA

El objetivo es que el equipo salga motivado para enfrentar el desafió del próximo 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