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