Eventos Belsy

Contenido
Tabla de contenido
1. Perfil.......................................................................................................................................................4
1.1. Introducción....................................................................................................................................4
¿Qué es un software de gestión en la Nube?.......................................................................................4
1.2. Objetivos.........................................................................................................................................6
1.3. Descripción del Problema...............................................................................................................6
1.4. Formulación del Problema..............................................................................................................7
1.5. Alcance............................................................................................................................................7
1.6. Elaborar una tabla Backlog (Lista de deseos).................................................................................8
1.7. Modelo de Dominio........................................................................................................................9
2. Marco Teórico......................................................................................................................................14
2.1. Propósito de SCRUM.....................................................................................................................14
2.2. Visión General de SCRUM.............................................................................................................15
2.4. El Dueño del Producto (Product Owner)......................................................................................16
2.5. El Equipo de Desarrollo (Development Team)..............................................................................16
2.6. El Scrum Master............................................................................................................................17
2.7. Eventos de Scrum..........................................................................................................................17
2.8. El SPRINT.......................................................................................................................................17
2.9. Reunión de Planificación de Sprint (Sprint Planning Meeting).....................................................18
2.10. Objetivo del Sprint (Sprint Goal).................................................................................................18
2.11. Scrum Diario (Daily Scrum).........................................................................................................18
2.12. Revision de Sprint (Sprint Review)..............................................................................................19
2.13. Retrospectiva de Sprint (Sprint Retrospective)..........................................................................20
2.14. Artefactos de Scrum...................................................................................................................21
2.15. Lista de Producto (Product Backlog)...........................................................................................21
2.16. Lista de Pendientes del Sprint (Sprint Backlog).........................................................................22
2.17. Incremento.................................................................................................................................22
2.18. Transparencia de los Artefactos................................................................................................22
2.19. Definición de “Terminado” (Definition of “Done”)....................................................................23
1
2.20. Ventajas y Desventajas..............................................................................................................23
2.21. Valores del trabajo.....................................................................................................................24
2.22. Herramientas de trabajo............................................................................................................25
3. Personas y Roles del Proyecto.............................................................................................................25
4. MODELOS USADOS PARA EL DESARROLLO DE SCRUM.......................................................................25
4.1. Sprint Planning Meeting (Reunion de planeamiento Del Sprint).................................................25
4.2 Pila de Sprint (Sprint Backlog) Sprint 0..........................................................................................27
4.3. Elementos : Pila del sprint............................................................................................................28
4.4. Sprint Review................................................................................................................................29
4.5. Sprint Restrospective....................................................................................................................30
4.7. Ejecución de la iteración...............................................................................................................30
4.8. Lista de casos de uso y Diagrama de casos de uso.......................................................................31
4.9. Diagrama de Clases.......................................................................................................................32
4.10. Paquetes y casos de Uso.............................................................................................................33
4.11. Artefacto.....................................................................................................................................35
5. INCREMENTOS.....................................................................................................................................35
5.1. SPRINT 1........................................................................................................................................35
a) Desarrollo de las fases de SCRUM...................................................................................................35
5.2. Planeación de Iteración................................................................................................................36
5.3. Historia de Usuario.......................................................................................................................38
5.4. Pila del Sprint 1.............................................................................................................................52
5.5. Burndown (Grafica de tareas y Datos de tareas)..........................................................................54
5.6. Grafica de esfuerzo y Datos de esfuerzo......................................................................................56
5.7. Scrum TaskBoard..........................................................................................................................59
5.9. Conclusión.....................................................................................................................................59
6.7. Análisis de la arquitectura.............................................................................................................60
6.7.1. Análisis de casos de uso.............................................................................................................60
GESTIONAR RESERVA...........................................................................................................................60
6.7.2. Diagrama de componentes........................................................................................................62
6.7.3. Diagrama de despliegue............................................................................................................63
2
6.7.4. Diagrama organizado en capas..................................................................................................64
6.8. Mecanismos que posibiliten que el usuario pueda aprender a usar la aplicación.......................65
6.9. Bibliografía....................................................................................................................................66
7. Anexos..............................................................................................................................................67
3
1. Perfil
1.1. Introducción
El uso de la tecnología se ha convertido en una herramienta primordial con mayores

exigencias de calidad y servicio. La mayoría de las empresas cuentan con un Sistema
de Información, que le ayudan a tener buen desempeño en sus funciones, los cuales
son diseñados y adaptados de acuerdo a las necesidades o requerimientos que estas
exijan.
Un sistema de información queda definido como: “conjunto formal de procesos que,
operando sobre una colección de datos estructurada de acuerdo a las necesidades
de la empresa, recopila, elabora y distribuyen selectivamente la información
necesaria para la operación de dicha empresa y para las actividades de dirección y
control correspondientes, apoyando, al menos en parte, los procesos de toma de
decisiones necesarios para desempeñar funciones de negocio de la empresa de
acuerdo con su estrategia”.
Todo sistema de información utiliza como materia prima los datos, los cuales
almacena, procesa y transforma para obtener como resultado final información, la
cual será suministrada a los diferentes usuarios del sistema, existiendo además un
proceso de retroalimentación o “feedback”, en la cual se ha de valorar si la
información obtenida se adecua a lo esperado
La información es uno de los elementos más importantes en nuestros tiempos. Las
empresas que manejan la información de manera adecuada y eficiente, son las que
tienen una gran ventaja sobre aquellas que aún se mantienen con un manejo de la
información en forma manual provocando entropía a la hora de obtener información
de la empresa. Hoy en día se puede observar la importancia que ha adquirido
Gestionar la administración de servicio de eventos para acontecimiento social y el
constante movimiento económico que este genera.
¿Qué es un software de gestión en la Nube?
Tanto la información como el tráfico de datos que generamos con esas aplicaciones

se almacenan en la Nube, de manera que otro usuario puede acceder desde su
dispositivo, ubicado a kilómetros de distancia del usuario original, y trabajar con el
mismo software y datos. Sin ningún tipo de conexión entre ambos equipos.
App móvil
El desarrollo de aplicaciones móviles es el conjunto de procesos y procedimientos
involucrados en la escritura de software para pequeños dispositivos inalámbricos de
cómputo, como teléfonos inteligentes o tabletas.
4
El desarrollo de aplicaciones móviles es similar al desarrollo de aplicaciones web, y
tiene sus raíces en el desarrollo de software más tradicional. Una diferencia
fundamental, sin embargo, es que las aplicaciones (apps) móviles a menudo se
escriben específicamente para aprovechar las características únicas que ofrece un
dispositivo móvil en particular. Por ejemplo, una aplicación para juegos podría
escribirse para aprovechar el acelerómetro del iPhone.
Una forma de asegurar que las aplicaciones muestren un rendimiento óptimo en un

dispositivo determinado es desarrollar la aplicación (app) de forma nativa en ese
dispositivo. Esto significa que, a un nivel muy bajo, el código se escribe
específicamente para el procesador de un dispositivo particular. Cuando una app
necesita ejecutarse en varios sistemas operativos, sin embargo, hay poco –si es
que hay alguno– código que puede ser reutilizado desde el desarrollo inicial. La
aplicación debe ser esencialmente reescrita para cada dispositivo específico.
En el futuro, se espera que la mayoría de los esfuerzos de desarrollo de aplicaciones

móviles se centren en la creación de aplicaciones basadas en navegador que sean
agnósticas del dispositivo. Las aplicaciones basadas en navegador son
simplemente sitios web creados para navegadores móviles. Estos sitios se
construyen para cargar rápidamente a través de una red celular y tienen una
navegación fácil de usar con los dedos..
Alguna de las funciones de este campo son las siguientes: Gestionar la compra de
productos, emisión de facturas, notificación de las fechas de reserva y otros.
5
1.2. Objetivos
1.2.1. Objetivo General
Desarrollar un Sistema de Información para Gestionar Venta de servicio de
evento para acontecimiento social.
1.2.2. Objetivo Especifico

✔ Recopilar información de los diferentes servicios que prestan los eventos
✔ Analizar la información obtenida de cada una de las empresas que prestan
servicios para la elaboración de un sistema genérico que cumpla con los
requisitos de venta de servicio para acontecimiento social.
✔ Establecer requerimientos funcionales para el diseño del sistema de

información ideal para el desarrollo competitivo de la empresa.
✔ Utilizar la metodología de desarrollo de software PUDS y SCRUM
✔ Diseñar e implementar una base de datos mediante la utilización de SGBD

“SQL Server 2008”
✔ Implementar la interfaz del software acorde a los requerimientos del

usuario mediante el lenguaje de programación PHP.
1.3. Descripción del Problema

Los eventos sociales son parte de la vida de la mayoría de la gente, ya que es muy
común asistir de invitados a fiestas de cumpleaños, de bodas, a eventos culturales y
otros tipos de eventos sociales. Cuando hablamos de eventos sociales nos estamos
refiriendo a un suceso importante y programado que puede abarcar cualquier área
social, artística, deportiva y los mismos pueden presentarse como seminarios,
talleres, conferencias, inauguraciones, exposiciones entre otros. El tipo de evento
determinará la finalidad del mismo, aunque generalmente los eventos sociales se
organizan con el principal objetivo de que la gente invitada se relacione entre sí. Son
muchos los tipos de acontecimientos sociales con los que nos podremos encontrar,
pero sin lugar a duda, los más habituales son las fiestas. En este caso debemos
indicar que aunque la mayoría de ellas tienden a realizarse en un ambiente algo más
privado, poseen todas las características para que puedan considerarse como tal,
además, una fiesta no solo es motivo de celebración, sino que también es mucha la
gente que interactúa entre sí, y precisamente por esta razón, las fiestas son
consideradas eventos sociales. De todos modos, es justo que se consideren las
características de la misma a la hora de la organización, ya que no es lo mismo
organizar una fiesta de boda que organizar una fiesta de cumpleaños, pero aun así,
6
los factores que se deben tener en cuenta durante su planeamiento son básicamente
los mismos.
1.4. Formulación del Problema

Se pretende desarrollar un Sistema de Información que se encargará de gestionar y
administrar los servicios que prestan de empresas organizadora de eventos;
Automatizando los datos de la empresa para su mejor organización, el
almacenamiento digital de los productos, la reserva y los pedidos, la impresión de los
datos de registro para el archivado físico, la realización del reporte en cualquier
momento, los movimientos que se han desarrollado.
1.5. Alcance
Hemos logrado detallar en nuestro alcance algunos puntos que se necesita en la
elaboración de nuestro programa, tomando en cuenta lo más primordial, por tanto
nuestro sistema será capaz de realizar lo siguiente:
 Gestionar empresas
Almacenar las distintas empresas y sus diferentes tipos de productos que
ofrecen al cliente, y el precio. Contará con los siguientes atributos:
Imagen, nombre, ciudad
 Gestionar reserva
Almacenar los datos respectos al stock, la cantidad de productos que queda en
el stock, los atributos que tendrá será:
Id, fecha registro, hora registro, monto, tipo de pago
 Gestionar Pedido
Se encarga de almacenar los pedidos, contara con los siguientes atributos:
Id, cliente, fecha registro, hora registro, monto, tipo de pago, estado
 Gestionar servicio
Se encarga de gestionar los servicios que requieren los clientes, contara con
los siguientes atributos:
Id, imagen, código, nombre y descripción
 Gestionar producto
Se encarga de gestionarlos productos de cada una de las empresas, contara
con los siguientes atributos:
Id, imagen, código, descripción, categoría y stock
7
 Gestionar categoría
Se Gestionará los distintos tipos de categorías de los productos que ofertan las
empresas. Contará con los siguientes atributos:
Id, Código, descripción
 Gestionar reporte
Este se encarga de mostrar el reporte de pedido. Cuenta con los siguientes
atributos
Fecha inicio, fecha fin, servicio, cliente, hora inicio, hora fin, tipo de
pago, monto final
 Gestionar reporte de pedido

Se almacenará los distintos pedidos y reservas que realizan los contara con los
siguientes atributos:
Fecha inicio, fecha fin,servicio, tipo de pago, monto inicio, operador, monto
final
1.6. Elaborar una tabla Backlog (Lista de deseos)
Elaborar historial de usuario de Gestionar categoría

Diseñar interfaz de gestionar categoría
Implementar la interfaz de gestionar categoría
Elaborar historial de usuario de Gestionar empresa
Diseñar interfaz de gestionar empresa
Implementar la interfaz de gestionar Empresa
Elaborar historial de usuario de Gestionar notificación
Diseñar interfaz de gestionar Notificación
Implementar la interfaz de gestionar Notificación
Elaborar historial de usuario de Gestionar reserva
Diseñar interfaz de gestionar Reserva
Implementar la interfaz de gestionar Reserva
Elaborar historial de usuario de Gestionar usuario
Diseñar interfaz de gestionar Usuario
Implementar la interfaz de gestionar Usuario
Elaborar historial de usuario de Verificar estado
Diseñar interfaz de Verificar Estado
Implementar la interfaz de Verificar Estado
Elaborar historial de usuario de Gestionar grupo
Diseñar interfaz de gestionar Grupo
Implementar la interfaz de gestionar Grupo
Elaborar historial de usuario de Gestionar producto
Diseñar interfaz de gestionar Producto
8
Implementar la interfaz de gestionar Producto
Elaborar historial de usuario de Gestionar detalle
Diseñar interfaz de Gestionar Detalle
Implementar la interfaz de Gestionar Detalle
Elaborar historial de usuario de Gestionar servicio
Diseñar interfaz de Gestionar Servicio
Implementar la interfaz de Gestionar Servicio
Elaborar historial de usuario de Gestionar carrito
Diseñar interfaz de Gestionar Carrito
Implementar la interfaz de Gestionar Carrito
Elaborar historial de usuario de Generar reporte
Diseñar interfaz de Gestionar Reporte
Implementar la interfaz de Gestionar Reporte
Elaborar historial de usuario de Generar pedido
Diseñar interfaz de Gestionar Pedido
Implementar la interfaz de Gestionar Pedido
1.7. Modelo de Dominio

1.7.1. Identificar Clases y Atributos
 USUARIO
Esta clase registra los datos personales de las personas involucradas en el
sistema.
 CLASE USUARIO
• Id
• Usuario
• Nombre
• Imagen
 GRUPO
Esta clase registra grupos de clientes

CLASE GRUPO
• Id
• Nombre
 NOTIFICACIÓN
Registra las notificaciones enviados al cliente u a la empresa.
 CLASE NOTIFICACIÓN
• Id
• Hora
• Fecha
• Estado
9
• mensaje
 DETALLE-NOTIFICACION-USUARIO
Esta es una clase intermedia que relaciona la tabla usuario y notificación.
 CLASE DETALLE-NOTIFICACIÓN-USUARIO
• Id
 RESERVA
Registra las reservas realizadas por el cliente
 CLASE RESERVA
• Id
• Monto
• Estado
• Fecha
• Hora
• Tipo de pago
 EMPRESA
En esta clase se registra las empresas
CLASE EMPRESA
• Nombre
• Imagen
• ciudad
 ESTADO
Esta clase se almacena el estado de la reserva
CLASE ESTADO
• ID
• Estado-reserva
 CATEGORIA
Esta clase el usuario podrá ver las categorías de productos
CLASE CATEGORIA
• Id
• Código
• Descripción
 PRODUCTO
10
En esta clase se almacena los diferentes productos
 CLASE PRODUCTO
• ID
• Código
• Descripción
 SERVICIOS
Se registra la lista de los servicios que ofrecen las empresas
 CLASE SERVICIO
• Código
• Descripción
• Id
• Imagen
• Nombre
 DETALLE
Esta clase almacena el detalle de las ventas
 CLASE DETALLE
• ID
• Descripción
• cantidad
• total
 CARRITO
La clase carrito se encarga de registrar la cantidad de servicios comprados.
CLASE CARRITO
• ID
• Estado
• Cantidad
• precio
 DETALLE-CARRITO
La clase detalle-carrito es una clase intermedia donde van las compras
realizadas
DETALLE-CARRITO
• ID
• Nombre
 PERMISO
La clase permiso se encarga de realizar los permisos realizados por los
usuarios
CLASE PERMISO
11
• ID
• Descripción
 DETALLE-GRUPO-PERMISO
La clase detalle-grupo-permiso se encarga de detallar los permisos
otorgados
CLASE DETALLE-GRUPO-PERMISO
• ID
• Descripción
1.7.2. Identificar Relaciones
12
1.7.3. Diagrama de Clases
class Modelo de clases
CATEGORIA EMPRESA
NOTIFICACION
- codigo: integer - ciudad: varchar(50) DETALLE-NOTIFICACION
- imagen: varchar(50) - estado: varchar(50) USUARIO
- descripion: varchar(50)
- nombre: varchar(50) - fecha: date
- id: Integer
- hora: time - id: integer
1 *
- id: integer
- mensaje: varchar(50)
DETALLE CARRITO
1
- id: integer
- nombre: varchar(50)
* 1 *
RESERVA ESTADO
PRODUCTO
- estado: integer - estado-reserva: varchar(50)
- categoria: integer
- fecha-registro: date - id: integer
- codigo: Integer * USUARIO
- descripcion: varchar(50) - hora-registro: time 1
- id: integer - id: Integer
- id: int
- monto: Integer - imagen: varchar(50)
- tipo-pago: money - nombre: varchar(50)
* 1 - usuario: varchar(50)
DETALLE *
- cantidad: integer
- descripcion: varchar(50) 1
- id: integer *
CARRITO
- cantidad: integer *
*
- estado: varchar(50)
- id: integer DETALLE-GRUPO-PERMISO
SERVICIO
* - precio: integer
- id: integer
1
- codigo: Integer
- id: integer
- imagen: varchar(50) PERMISO GRUPO
- descripcion: varchar(50) - id: integer 13
- id: integer * * - nombre: varchar(50)
2. Marco Teórico
2.1. Propósito de SCRUM
Scrum es un marco de trabajo para el desarrollo y el mantenimiento de
productos complejos. Esta Guía contiene la definición de Scrum. Esta definición
contiene los roles, eventos y artefactos de Scrum, y las reglas que los
relacionan. Ken Schwaber y Jeff Sutherland desarrollaron Scrum; la Guía de
Scrum está escrita y es proporcionada por ellos. Juntos, respaldan la Guía de
Scrum.
2.2. Visión General de SCRUM

Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro
porque no se basa en el seguimiento de un plan, sino en la adaptación continua
a las circunstancias de la evolución del proyecto.
Scrum es una metodología ágil, y como tal: Es un modo de desarrollo de
carácter adaptable más que predictivo. Orientado a las personas más que a los
procesos. Emplea la estructura de desarrollo ágil: incremental basada en
iteraciones y revisiones.
Scrum es un proceso en el que se aplican de manera regular un conjunto de
buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su
selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final,
priorizadas por el beneficio que aportan al receptor del proyecto. Por ello,
Scrum está especialmente indicado para proyectos en entornos complejos,
donde se necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovación, la competitividad, la
flexibilidad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está
entregando al cliente lo que necesita, cuando las entregas se alargan
demasiado, los costes se disparan o la calidad no es aceptable, cuando se
necesita capacidad de reacción ante la competencia, cuando la moral de los
equipos es baja y la rotación alta, cuando es necesario identificar y solucionar
ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un
proceso especializado en el desarrollo de producto.
2.3. El equipo SCRUM (Scrum Team)

Los Equipos Scrum son autoorganizados y multifuncionales.
14
 Los equipos auto organizados eligen la mejor forma de llevar a cabo su
trabajo y no son dirigidos por personas externas al equipo.
 Los equipos multifuncionales tienen todas las competencias necesarias
para llevar a cabo el trabajo sin depender de otras personas que no son
parte del equipo. El modelo de equipo en Scrum está diseñado para
optimizar la flexibilidad, la creatividad y la productividad.
Los Equipos Scrum entregan productos de forma iterativa e incremental,
maximizando las oportunidades de obtener retroalimentación. Las entregas
incrementales de producto “Terminado” aseguran que siempre estará
disponible una versión potencialmente útil y funcional del producto.
2.4. El Dueño del Producto (Product Owner)

El Dueño de Producto es el responsable de maximizar el valor del producto y
del trabajo del Equipo de Desarrollo. El cómo se lleva a cabo esto podría variar
ampliamente entre distintas organizaciones, Equipos Scrum e individuos.
 Es una única persona, no un comité
 Es la única persona responsable de gestionar la Lista del Producto
(Product Backlog).
 El Dueño de Producto podría representar los deseos de un comité en la
Lista del Producto, pero aquellos que quieran cambiar la prioridad de un
elemento de la Lista deben hacerlo a través del Dueño de Producto.
 El Dueño de Producto podría hacer el trabajo anterior, o delegarlo en el
Equipo de Desarrollo. Sin embargo, en ambos casos el Dueño de
Producto sigue siendo el responsable de dicho trabajo.
Para que el Dueño de Producto pueda hacer bien su trabajo, toda la
organización debe respetar sus decisiones. Las decisiones del Dueño de
Producto se reflejan en el contenido y en la priorización de la Lista del
Producto. No está permitido que nadie pida al Equipo de Desarrollo que
trabaje con base en un conjunto diferente de requerimiento
2.5. El Equipo de Desarrollo (Development Team)

El Equipo de Desarrollo consiste en los profesionales que desempeñan el
trabajo de entregar un Incremento de producto “Terminado”, que
potencialmente se pueda poner en producción, al final de cada Sprint.
Los Equipos de Desarrollo son estructurados y empoderados por la
organización para organizar y gestionar su propio trabajo. La sinergia resultante
optimiza la eficiencia y efectividad del Equipo de Desarrollo.
Los Equipos de Desarrollo tienen las siguientes características:
 Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al
Equipo de Desarrollo cómo convertir elementos de la Lista del Producto
en Incrementos de funcionalidad potencialmente desplegables
15
 Los Equipos de Desarrollo son multifuncionales, contando como equipo
con todas las habilidades necesarias para crear un Incremento de
producto
 Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo,
todos son Desarrolladores, independientemente del trabajo que realice
cada persona; no hay excepciones a esta regla
 Scrum no reconoce sub-equipos en los equipos de desarrollo, no
importan los dominios particulares que requieran ser tenidos en cuenta,
como pruebas o análisis de negocio; no hay excepciones a esta regla
 Los Miembros individuales del Equipo de Desarrollo pueden tener
habilidades especializadas y áreas en las que estén más enfocados, pero
la responsabilidad recae en el Equipo de Desarrollo como un todo.
2.6. El Scrum Master

El Scrum Master es el responsable de asegurar que Scrum es entendido y
adoptado. Los Scrum Masters hacen esto asegurándose de que el Equipo
Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum.
 Esun líder que está al servicio del Equipo Scrum.
 Ayuda a las personas externas al Equipo Scrum a entender qué
interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no.
 Ayuda a todos a modificar estas interacciones para maximizar el valor
creado por el Equipo Scrum.
 El Scrum Master da servicio al Dueño de Producto
 El Scrum Master da servicio al Equipo de Desarrollo
 El Servicio del Scrum Master a la Organización
2.7. Eventos de Scrum

En Scrum existen eventos predefinidos con el fin de crear regularidad y
minimizar la necesidad de reuniones no definidas. Todos los eventos son
bloques de tiempo (time-boxes), de tal modo que todos tienen una duración
máxima. Una vez que comienza un Sprint, su duración es fija y no puede
acortarse o alargarse. Los demás eventos pueden terminar siempre que se
alcance el objetivo del evento, asegurando que se emplee una cantidad
apropiada de tiempo sin permitir desperdicio en el proceso.
Estos eventos están diseñados específicamente para habilitar las vitales
transparencia e inspección. La falta de alguno de estos eventos da como
resultado una reducción de la transparencia y constituye una oportunidad
perdida para inspeccionar y adaptarse.
2.8. El SPRINT
Es un bloque de tiempo (time-box) de un mes o menos durante el cual se crea
un incremento de producto “Terminado”, utilizable y potencialmente
desplegable. Es más conveniente si la duración de los Sprints es consistente a
16
lo largo del esfuerzo de desarrollo. Cada nuevo Sprint comienza
inmediatamente después de la finalización del Sprint previo.
Los Sprints contienen y consisten de:
 Reunión de Planificación del Sprint (Sprint Planning Meeting)
 Los Scrums Diarios (Daily Scrums)
 el trabajo de desarrollo
 Revision del Sprint (Sprint Review)
 Retrospectiva del Sprint (Sprint Retrospective).
2.9. Reunión de Planificación de Sprint (Sprint Planning Meeting)

Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.
La Reunión de Planificación de Sprint tiene un máximo de duración de ocho
horas para un Sprint de un mes. Para
Sprints más cortos, el evento es usualmente más corto. El Scrum Master se
asegura de que el evento se lleve a cabo y que los asistentes entiendan su
propósito. El Scrum Master enseña al Equipo Scrum a mantenerse dentro del
bloque de tiempo.
La Reunión de Planificación de Sprint responde a las siguientes preguntas:

 ¿Qué puede entregarse en el Incremento resultante del Sprint que
comienza?
 ¿Cómo se conseguirá hacer el trabajo necesario para entregar el
Incremento?
2.10. Objetivo del Sprint (Sprint Goal)

Es una meta establecida para el Sprint que puede ser alcanzada mediante la
implementación de la Lista de Producto. Proporciona una guía al Equipo de
Desarrollo acerca de por qué está construyendo el incremento. Es creado
durante la reunión de Planificación del Sprint. Los elementos de la Lista del
Producto seleccionados ofrecen una función coherente. Puede representar
otro nexo de unión que haga que el Equipo de Desarrollo trabaje en conjunto y
no en iniciativas separadas.
A medida que el equipo de desarrollo trabaja, se mantiene el objetivo del
Sprint en mente. Con el fin de satisfacer el objetivo del Sprint se implementa la
funcionalidad y la tecnología. Si el trabajo resulta ser diferente de lo que el
Equipo de Desarrollo espera, ellos colaboran con el Dueño del Producto para
negociar el alcance de la Lista de pendientes del Sprint (Sprint Backlog).
2.11. Scrum Diario (Daily Scrum)

Es una reunión con un bloque de tiempo de 15 minutos para que el Equipo de
Desarrollo sincronice sus actividades y cree un plan para las siguientes 24
horas. Esto se lleva a cabo inspeccionando el trabajo avanzado desde el
17
último Scrum Diario y haciendo una proyección acerca del trabajo que podría
completarse antes del siguiente.
El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los días
para reducir la complejidad. Durante la reunión, cada miembro del Equipo de
Desarrollo explica:
 ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo
del Sprint?
 ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo
del Sprint?
 ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo
logremos el Objetivo del Sprint?
El Scrum Master se asegura de que el Equipo de Desarrollo tenga la reunión,

pero el Equipo de Desarrollo es el responsable de dirigir el Scrum Diario. Se
asegura de que se cumpla la regla de que solo los miembros del Equipo de
Desarrollo participan en el Scrum Diario.
Los Scrum Diarios mejoran la comunicación, eliminan la necesidad de
mantener otras reuniones, identifican y eliminan impedimentos relativos al
desarrollo, resaltan y promueven la toma de decisiones rápida, y mejoran el
nivel de conocimiento del Equipo de Desarrollo. El Scrum Diario constituye
una reunión clave de inspección y adaptación.
2.12. Revision de Sprint (Sprint Review)

Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el
Incremento y adaptar la Lista de Producto si fuese necesario. Durante la
Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo
que se hizo durante el Sprint. Basándose en esto, y en cualquier cambio a la
Lista de Producto durante el Sprint, los asistentes colaboran para determinar
las siguientes cosas que podrían hacerse para optimizar el valor. Se trata de
una reunión informal, no una reunión de seguimiento, y la presentación del
Incremento tiene como objetivo facilitar la retroalimentación de información y
fomentar la colaboración.
Restringida a un bloque de tiempo de cuatro horas para Sprints de un mes.
Para Sprints más cortos, se reserva un tiempo proporcionalmente menor.
La Revisión de Sprint incluye los siguientes elementos:
 Los asistentes son el Equipo Scrum y los interesados clave invitados
por el Dueño de Producto
 El Dueño de Producto explica qué elementos de la Lista de Producto se
han “Terminado” y cuales no se han
“Terminado”
18
 El Equipo de Desarrollo habla acerca de qué fue bien durante el Sprint,
qué problemas aparecieron y cómo fueron resueltos esos problemas
 El Equipo de Desarrollo demuestra el trabajo que ha
“Terminado” y responde preguntas acerca del Incremento
 El Dueño de Producto habla acerca de la Lista de Producto en el
estado actual. Proyecta fechas de finalización probables en el tiempo
basándose en el progreso obtenido hasta la fecha (si es necesario)
 El grupo completo colabora acerca de qué hacer a continuación, de
modo que la Revisión del Sprint proporcione información de entrada
valiosa para Reuniones de Planificación de Sprints subsiguientes
 Revisión de cómo el mercado o el uso potencial del producto podría
haber cambiado lo que es de más valor para hacer a continuación
 Revisión de la línea de tiempo, presupuesto, capacidades potenciales y
mercado para la próxima entrega prevista del producto.
El resultado de la Revisión de Sprint es una Lista de Producto revisada, que
define los elementos de la Lista de Producto posibles para el siguiente Sprint.
Es posible además que la Lista de Producto reciba un ajuste general para
enfocarse en nuevas oportunidades.
2.13. Retrospectiva de Sprint (Sprint Retrospective)

Es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y
crear un plan de mejoras que sean abordadas durante el siguiente Sprint.
La Retrospectiva de Sprint tiene lugar después de la Revisión de Sprint y
antes de la siguiente Reunión de Planificación de Sprint. Se trata de una
reunión restringida a un bloque de tiempo de tres horas para Sprints de un
mes. Para Sprints más cortos se reserva un tiempo proporcionalmente menor.
El Scrum Master se asegura de que el evento se lleve a cabo y que los
asistentes entiendan su propósito. El Scrum Master enseña a todos a
mantener el evento dentro del bloque de tiempo fijado. El Scrum Master
participa en la reunión como un miembro del equipo ya que la responsabilidad
del proceso Scrum recae sobre él.
El propósito de la Retrospectiva de Sprint es:
 Inspeccionar cómo fue el último Sprint en cuanto a personas,
relaciones, procesos y herramientas
 Identificar y ordenar los elementos más importantes que salieron bien y
las posibles mejoras
 Crear un plan para implementar las mejoras a la forma en la que el
Equipo Scrum desempeña su trabajo.
Durante cada Retrospectiva de Sprint, el Equipo Scrum planifica formas de
aumentar la calidad del producto mediante la adaptación de la Definición de
“Terminado” (Definition of “Done”) según sea conveniente.
19
Para el final de la Retrospectiva de Sprint, el Equipo Scrum debería haber
identificado mejoras que implementará en el próximo Sprint. El hecho de
implementar estas mejoras en el siguiente Sprint, constituye la adaptación
subsecuente a la inspección del Equipo de Desarrollo a sí mismo.
2.14. Artefactos de Scrum

Los artefactos de Scrum representan trabajo o valor en diversas formas que
son útiles para proporcionar transparencia y oportunidades para la inspección
y adaptación. Los artefactos definidos por Scrum están diseñados
específicamente para maximizar la transparencia de la información clave, que
es necesaria para asegurar que todos tengan el mismo entendimiento del
artefacto.
2.15. Lista de Producto (Product Backlog)

La Lista de Producto es una lista ordenada de todo lo que podría ser necesario
en el producto, y es la única fuente de requisitos para cualquier cambio a
realizarse en el producto. El Dueño de Producto (Product Owner) es el
responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y
ordenación.
Una Lista de Producto nunca está completa. El desarrollo más temprano de la
misma solo refleja los requisitos conocidos y mejor entendidos al principio. La
Lista de Producto evoluciona a medida de que el producto y el entorno en el
que se usará también lo hacen. La Lista de Producto es dinámica; cambia
constantemente para identificar lo que el producto necesita para ser
adecuado, competitivo y útil. Mientras el producto exista, su Lista de Producto
también existe.
La Lista de Producto enumera todas las características, funcionalidades,
requisitos, mejoras y correcciones que constituyen cambios a ser hechos
sobre el producto para entregas futuras. Los elementos de la Lista de
Producto tienen como atributos la descripción, la ordenación, la estimación y
el valor.
El Equipo Scrum decide cómo y cuándo se hace el refinamiento.

Este usualmente consume no más del 10% de la capacidad del
Equipo de Desarrollo. Sin embargo, los elementos de la Lista de Producto
pueden actualizarse en cualquier momento por el Dueño de Producto o a
criterio suyo.
Los elementos de la Lista de Producto de orden más alto son generalmente
más claros y detallados que los de menor orden. Se realizan estimaciones
más precisas basándose en la mayor claridad y detalle; cuanto más bajo es el
orden, menor es el detalle. Los elementos de la Lista de Producto de los que
20
se ocupará el Equipo de Desarrollo en el siguiente Sprint tienen una
granularidad mayor, habiendo sido descompuestos de forma que cualquier
elemento puede ser “Terminado” dentro de los límites del bloque de tiempo del
Sprint
2.16. Lista de Pendientes del Sprint (Sprint Backlog)

Es el conjunto de elementos de la Lista de Producto seleccionados para el
Sprint, más un plan para entregar el Incremento de producto y conseguir el
Objetivo del Sprint. La Lista de Pendientes del Sprint es una predicción hecha
por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del
próximo Incremento y del trabajo necesario para entregar esa funcionalidad en
un Incremento “Terminado”.
La Lista de Pendientes del Sprint hace visible todo el trabajo que el Equipo de
Desarrollo identifica como necesario para alcanzar el Objetivo del Sprint.
La Lista de Pendientes del Sprint es un plan con un nivel de detalle suficiente
como para que los cambios en el progreso se puedan entender en el Scrum
Diario. El Equipo de Desarrollo modifica la Lista de Pendientes del Sprint
durante el Sprint y esta Lista de Pendientes del Sprint emerge a lo largo del
Sprint. Esto ocurre a medida que el Equipo de Desarrollo trabaja sobre el plan
y aprende más acerca del trabajo necesario para conseguir el Objetivo del
Sprint.
La Lista de Pendientes del Sprint es una imagen visible en tiempo real del
trabajo que el Equipo de Desarrollo planea llevar a cabo durante el Sprint, y
pertenece únicamente al Equipo de Desarrollo.
2.17. Incremento
El Incremento es la suma de todos los elementos de la Lista de Producto
completados durante un Sprint y el valor de los incrementos de todos los
Sprints anteriores. Al final de un Sprint, el nuevo Incremento debe estar
“Terminado”, lo cual significa que está en condiciones de ser utilizado y que
cumple la Definición de “Terminado” del Equipo Scrum. El incremento debe
estar en condiciones de utilizarse sin importar si el Dueño de Producto decide
liberarlo o no.
2.18. Transparencia de los Artefactos

Scrum se basa en la transparencia. Las decisiones para optimizar el valor y
controlar el riesgo se toman basadas en el estado percibido de los artefactos.
En la medida en que la transparencia sea completa, estas decisiones tienen
unas bases sólidas. En la medida en que los artefactos no son completamente
transparentes, estas decisiones pueden ser erróneas, el valor puede disminuir
y el riesgo puede aumentar.
21
El Scrum Master debe trabajar con el Dueño de Producto, el Equipo de
Desarrollo y otras partes involucradas para entender si los artefactos son
completamente transparentes. Hay prácticas para hacer frente a la falta de
transparencia; el Scrum Master debe ayudar a todos a aplicar las prácticas
más apropiadas si no hay una transparencia completa
La labor del Scrum Master es trabajar con el Equipo Scrum y la organización
para mejorar la transparencia de los artefactos. Este trabajo usualmente
incluye aprendizaje, convicción y cambio. La transparencia no ocurre de la
noche a la mañana, sino que es un camino.
2.19. Definición de “Terminado” (Definition of “Done”)

Cuando un elemento de la Lista de Producto o un Incremento se describe
como “Terminado”, todo el mundo debe entender lo que significa “Terminado”,
los miembros del Equipo deben tener un entendimiento compartido de lo que
significa que el trabajo esté completado, para asegurar la transparencia. Esta
es la definición de “Terminado” para el Equipo Scrum y se utiliza para evaluar
cuándo se ha completado el trabajo sobre el Incremento de producto.
Los Equipos de Desarrollo entregan un Incremento de funcionalidad de

producto en cada Sprint. Este Incremento es utilizable, de modo que el Dueño
de Producto podría elegir liberarlo inmediatamente. Si la definición de
“Terminado” para un incremento es parte de las convenciones, estándares o
guías de la organización de desarrollo, al menos todos los Equipos Scrum
deben seguirla. Si “Terminado” para un incremento no es una convención de
la organización de desarrollo, el Equipo de Desarrollo del Equipo Scrum debe
definir una definición de “Terminado” apropiada para el producto. Si hay
múltiples Equipos Scrum trabajando en la entrega del sistema o producto, los
equipos de desarrolladores en todos los Equipos
Scrum deben definir en conjunto la definición de “Terminado”.
Cada Incremento se integra con todos los Incrementos anteriores y es
probado exhaustivamente, asegurando que todos los Incrementos funcionan
en conjunto.
A medida que los Equipos Scrum maduran, se espera que su definición de
“Terminado” se amplíe para incluir criterios más rigurosos para una mayor
calidad. Cualquier producto o sistema debería tener una definición de
“Terminado” que es un estándar para cualquier trabajo realizado sobre él.
2.20. Ventajas y Desventajas

Ventajas
22
 El Scrum Master tiene el conocimiento necesario para lograr el objetivo
primario y secundario pro lo cual puede ir controlando el proyecto y
delegando roles
 Cada persona sabe lo que tiene que hacer y no es necesario estar
reorganizando una y otra vez los tracks(pistas) de cada persona
 entregables en tiempo y forma , puedes ir enviando entregables al
cliente mientras vas atacando los objetivos más sencillos, eso te hace
ganar tiempo para atacar los objetivos más complejos
 se involucra desde un principio y se da un rol a todos los stakeolders
(personas que van a participar en el proyecto incluyendo cliente final,
Testers,etc.)
Desventajas
 Algunos miembros de tu equipo pueden saltar pasos importantes en el
camino rápido para llegar al Sprint final
 El cliente siempre va esperar los informes con la fecha exacta, y
muchas veces los va pedir antes, cuando capaz no pudiste avanzar en
nada
 Demasiadas reuniones para poco avance, a veces es muy cansador y
estresante reunirse demasiadas veces por el mismo tema, algunos van
perdiendo el interés en el proyecto
 Si una persona renuencia o hay algún cambio es complicado remplazar
ese rol ya que es la persona que se lleva el conocimiento específico y
afecta a todo el proyecto
 No es aplicable a grandes escalas
2.21. Valores del trabajo

Puntualidad
El equipo debe ser puntual no solo a la hora de entregar un trabajo, sino que
también debe ser puntual en todas las actividades que se realice en el
transcurso del proyecto tanto como el Scum Mater hasta el equipo
desarrollador
Compromiso
Significa que cada miembro del equipo Scrum (es decir, todos, incluido Scrum
Master y Product Owner) hará el máximo esfuerzo posible y será
completamente transparente sobre el progreso del Sprint.
Respeto
Los miembros de un equipo Scrum respetan el conocimiento, las habilidades y
la experiencia profesional no solo del resto de miembros del equipo, sino
23
también de aquellas personas con las que se relacionan, sean de su propia
organización o de otra.
Coraje
El equipo debe tener coraje para resolver los impedimentos que puedan surgir
en el camino, anticipando los riesgos, sacando a la luz los problemas y
pensando en una solución. Hay que tener coraje para reconocer los errores
cometidos, ser transparentes y aprender de los mismos
2.22. Herramientas de trabajo

“Sprintometer” Scrum & XP project tracking
Es un simple pero ponderosa herramienta ágil para manejar proyectos de
SCRUM y XP. Fue originalmente creada por personas trabajando con
proyectos agiles para sus propios trabajos y ahora esta como un software libre
en el mercado. Durante el tiempo de desarrollo de esta herramienta se uso
varias ideas agiles para mejorarla.
3. Personas y Roles del Proyecto
Persona Rol Aptitudes Tarea

Es una persona
comprometida,
responsable,
colaboradora,
M Scrum Master perseverante, Guiar al equipo
organizado y
autodidacta,
entiende a
mayor
profundidad
sobre el tema
4. MODELOS USADOS PARA EL DESARROLLO DE SCRUM

4.1. Sprint Planning Meeting (Reunion de planeamiento Del Sprint)
En el sprint 0 nos proponemos a diseñar la base de datos de acuerdo con los
requisitos funcionales que nos presente el product Owner
Código Descripción de la tarea Prioridad

HU0-1 Entrevista con Product Owner Análisis
Crear un perfil que explique la finalidad del
HU0-2 Diseño
proyecto
24
Explicar al Product Owner como funciona la
HU0-3 Análisis
metodología a usar
Explicar al Equipo una definición del
HU0-4 Análisis
problema
Asignación de roles a los miembros del
HU0-5 Análisis
equipo
Capacitación de los miembros del equipo
HU0-6 Capacitación
en las herramientas a utilizar
Preparación del entorno de desarrollo de
HU0-7 Preparación
programación
Presentar un prototipo de una disponible
HU0-8 Diseño
solución del problema
HU0-9 Diseñar un modelo de base de Datos Diseño
HU0-10 Encontrar los casos de Uso funcionales Análisis
Diseñar interfaz de login
HU1-1 Diseño
HU1-2 Implementar interfaz de login Diseño
HU1-3 Implementar a historia de usuario Desarrollo
HU1-4 Realizar pruebas a la implementación Prueba
Elaborar historia de usuario para Gestionar
HU2-1 Diseño
Categoría
Diseñar interfaz de usuario para Gestionar
HU2-2 Desarrollo
Categoría
Realizar las pruebas necesarias de la
HU2-3 Prueba
reciente implementación
Elaborar historia de usuario para gestionar
HU3-1 Análisis
empresa
HU3-2 Diseñar interfaz para gestionar empresa Diseño
Implementar historia de usuario para
HU3-3 Desarrollo
gestionar notificaciones
HU3-4 Prueba
implementación de notificación
HU4-1 Elaborar historia de usuario para reserva Análisis
HU4-2 Diseñar interfaz para gestionar reserva Diseño
HU4-3 Desarrollo
gestionar estado
HU4-4 Prueba
implementación
HU5-1 Análisis
producto
HU5-2 Diseñar interfaz para gestionar producto Diseño
HU5-3 Desarrollo
gestionar producto
25
HU5-4 Prueba
implementación
HU6-1 Análisis
pedido
HU6-2 Diseñar interfaz para gestionar pedido Diseño
HU6-3 Desarrollo
gestionar servicio
HU6-4 Prueba
implementación
HU7-1 Diseñar interfaz de gestionar servicio Diseño
HU7-2 Implementar de gestionar grupo Desarrollo
Realizar las pruebas necesarias de
HU7-3 Prueba
gestionar grupo
HU8-1 Diseñar interfaz de gestionar detalle Diseño
HU8-2 Implementar de gestionar detalle Desarrollo
HU8-3 Prueba
gestionar detalle
HU9-1 Diseñar interfaz de gestionar rol Diseño
HU9-2 Implementar de gestionar rol Desarrollo
HU9-3 Prueba
gestionar rol
HU10-1 Diseñar interfaz de gestionar estado Diseño
HU10-2 Implementar de gestionar estado Desarrollo
HU10-3 Realizar las pruebas necesarias de estado Prueba
HU11-1 Diseñar interfaz de gestionar carrito Diseño
HU11-2 Implementar de gestionar carrito Desarrollo
HU11-3 Prueba
gestionar carrito
HU12-1 Diseñar interfaz de gestionar reporte Diseño
HU12-2 Implementar de gestionar reporte Desarrollo
HU12-3 Realizar las pruebas necesarias de reportes Prueba
4.2 Pila de Sprint (Sprint Backlog) Sprint 0
ID TAREA PRIORIDAD ESTADO RESPONSABLE
Entrevista con Product Belcy Arroyo

H0 Alta Terminado
Owner
H1 Crear un perfil que Alta Terminado Belcy Arroyo
explique la finalidad del
proyecto
H2 Explicar al Product Owner Alta Terminado Belcy Arroyo
como funciona la
26
metodología a usar
H3 Explicar al Equipo una Belcy Arroyo
Alta Terminado
definición del problema
Asignación de roles a los Belcy Arroyo
H4 Alta Terminado
miembros del equipo
Capacitación de los Belcy Arroyo
H5 miembros del equipo en Alta Terminado
las herramientas a utilizar
Preparación del entorno Belcy Arroyo
H6 de desarrollo de Alta Terminado
programación
Presentar un prototipo de Belcy Arroyo
H7 Alta Terminado
una disponible solución
Diseñar un modelo de Belcy Arroyo
H8 Alta Terminado
base de Datos
Encontrar los casos de Belcy Arroyo
H9 Alta Terminado
Uso funcionales
4.3. Elementos : Pila del sprint

5-sept
6-sept
7-sept
9-sept
SPRINT
0
7 6 5 2 1 1
2 6 5 4 2 1
TAREA RESPONSABLE
Entrevista Belcy Arroyo

con Product 2 2
Owner
Crear un Belcy Arroyo 2
perfil que 2
explique la
finalidad del
proyecto
Explicar al Belcy Arroyo 2
Product 1
Owner como
funciona la
metodología
a usar
Explicar al 3
Equipo una 2
definición del
problema
Asignación Belcy Arroyo 3
de roles a los 3
27
miembros del
equipo
Capacitación Belcy Arroyo 2 2
de los
miembros del
equipo en las
herramientas
a utilizar
Preparación Belcy Arroyo 2 2
del entorno 3
de desarrollo
de
programació
n
Presentar un Belcy Arroyo 2 2
prototipo de 3
una
disponible
solución del
problema
Diseñar un Belcy Arroyo 3 3 3
modelo de
base de
Datos
Encontrar los Belcy Arroyo 4 1 2 1
casos de Uso
funcionales
4.4. Sprint Review

Es una reunión informal, y el objetivo principal del Sprint Review es brindar
transparencia tanto al equipo como al cliente. El evento duró 1 y media
Este evento fue organizado por el Product Owner, y es necesaria la presencia de todo
el equipo de Scrum. El rol del Scrum Master es asegurar que el evento ocurre y que
cumple los tiempos establecidos, además de asegurar una colaboración de todo el
equipo.
El Product Owner. -el producto owner cumplió con algunos de los objetivos q se
había planteado para esta semana en el primer sprint.
 Optimizar el valor del trabajo del Equipo.

 Asegurarse de que el Product Backlog sea visible, transparente y claro para todos.
4.5. Sprint Restrospective

Durante el Sprint 0 se presentaron inconvenientes, en el momento de captura
los requerimientos del cliente.
28
Sobre el diseño de la base de datos, se realizaron varias correcciones hasta
llegar a la base de datos con la que se cuenta actualmente.
Para solucionar los inconvenientes se realizó una reunión donde se definió las
horas de entrada, salida, tanto las horas de trabajo como las horas de las
reuniones diarias para analizar el avance del proyecto y las soluciones a los
problemas de cada Sprint.
4.7. Ejecución de la iteración
PRIORIDA ESTIMACIO
ID TAREA TIPO ESTADO RESPONSABLE
D N
Entrevista con Product Terminad Belcy 100
HU0-1 Alta Análisis Arroyo
Owner o %
Crear un perfil que Belcy
Terminad Arroyo 100
HU0-2 Alta explique la finalidad del Diseño
o %
proyecto
Belcy
Explicar al Product
Terminad Arroyo 100
HU0-3 Alta Owner como funciona Análisis
o %
la metodología a usar
Belcy
Explicar al Equipo una Terminad Arroyo 100
HU0-4 Alta Análisis
definición del problema o %
Asignación de roles a Belcy
Terminad Arroyo 100
HU0-5 Alta los miembros del Análisis
o %
equipo
Capacitación de los Belcy
miembros del equipo Capacitació Terminad Arroyo 100
HU0-6 Alta
en las herramientas a n o %
utilizar
Belcy
Preparación del
Terminad Arroyo 100
HU0-7 Alta entorno de desarrollo Preparación
o %
de programación
Presentar un prototipo Belcy
Terminad Arroyo 100
HU0-8 Alta de una disponible Diseño
o %
solución del problema
Diseñar un modelo de Terminad Belcy 100
HU0-9 Alta Diseño Arroyo
base de Datos o %
Encontrar los casos de Terminad Belcy 100
HU0-10 Alta Análisis Arroyo
Uso funcionales o %
29
4.8. Lista de casos de uso y Diagrama de casos de uso
 CU1.Gestionar categoría
 CU2.Gestionar empresa
 CU3. Gestionar notificación
 CU4.Gestionar reserva
 CU5.Gestionar usuario
 CU6.Verificar estado
 CU7.Gestionar grupo
 CU8.Gestionar producto
 CU9.Gestionar detalle
 CU10.Gestionar servicio
 CU11.Gestionar carrito
 CU12.Generar reporte
 CU13.Generar pedido
 CU14.Gestionar rol
30
4.9. Diagrama de Clases
class Modelo de clases
CATEGORIA EMPRESA
NOTIFICACION
- codigo: integer - ciudad: varchar(50) DETALLE-NOTIFICACION
- imagen: varchar(50) - estado: varchar(50) USUARIO
- descripion: varchar(50)
- nombre: varchar(50) - fecha: date
- id: Integer
- hora: time - id: integer
1 *
- id: integer
- mensaje: varchar(50)
DETALLE CARRITO
1
- id: integer
* 1 *
RESERVA ESTADO
PRODUCTO
- estado: integer - estado-reserva: varchar(50)
- categoria: integer
- fecha-registro: date - id: integer
- codigo: Integer * USUARIO
- descripcion: varchar(50) - hora-registro: time 1
- id: int - id: integer - id: Integer
- monto: Integer - imagen: varchar(50)
- tipo-pago: money - nombre: varchar(50)
* 1 - usuario: varchar(50)
DETALLE *
- cantidad: integer
- id: integer *
CARRITO
- cantidad: integer *
*
- estado: varchar(50)
- id: integer DETALLE-GRUPO-PERMISO
SERVICIO
* - precio: integer
- id: integer
1
- codigo: Integer
- id: integer
- imagen: varchar(50) PERMISO GRUPO
- descripcion: varchar(50) - id: integer
- id: integer * * - nombre: varchar(50)
31
4.10. Paquetes y casos de Uso
uc gestionar empresas
CU11: GESTIONAR
CU7: GESTIONAR CARRITO
GRUPO
«extend»
CU5: GESTIONAR
USUARIO
CU8: GESTIONAR
PRODUCTO
CU12: GESTIONAR
REPORTE CU1: GESTINAR
CATEGORIA
CU13: GESTIONAR
administrador
PEDIDO
(from Actores) cliente
(from Actores)
CU3: GESTIONAR
CU6:VERIFICAR NOTIFICACION
GRUPO
«include»
CU4: GESTIONAR
CU9: GESTIONAR RESERVA
DETALLE
CU2: GESTIONAR
EMPRESAS
CU10: GESTIONAR
SERVIVIO
uc PAQUETES
CU2: GESTIONAR
EMPRESAS
ADMINISTRACION «trace»
(from Casos de uso principales)
«trace»
CU5: GESTIONAR
USUARIO
«trace»
CU14: ROL
32
uc SERVICIO
CU1: GESTINAR
CATEGORIA
SERVICIO «trace» (from Casos de uso principales)
«trace»
CU8: GESTIONAR
PRODUCTO
«trace» (from Casos de uso principales)
CU10: GESTIONAR
SERVICIO
33
4.11. Artefacto
4.11.2. Scrum TaskBoard
5. INCREMENTOS
5.1. SPRINT 1
a) Desarrollo de las fases de SCRUM
 CU1.Gestionar categoría
 CU2.Gestionar empresa
 CU3. Gestionar notificación
 CU4.Gestionar reserva
 CU5.Gestionar usuario
 CU6.Verificar estado
 CU7.Gestionar grupo
 CU8.Gestionar producto
 CU9.Gestionar detalle
 CU10.Gestionar servicio
 CU11.Gestionar carrito
 CU12.Generar reporte
 CU13.Generar pedido
 CU14.Gestionar rol
34
b) Objetivo del Sprint (sprint Goal)
Implementar los casos de uso obtenidos del product backlog y que tienen alta
prioridad para ir desarrollando en el sprint1
5.1.1. Personal y Roles del Proyecto
Persona Rol Aptitudes Tarea

Es una persona
comprometida,
responsable,
colaboradora,
Guiar al equipo
perseverante,
Belcy Arroyo Scrum Master organizado y
autodidacta,
entiende a mayor
profundidad sobre el
tema
Es una persona
comprometida,
Belcy arroyo Product Owner responsable, Diseñador
colaboradora,
perseverante,
organizado y
autodidacta
Es una persona
comprometida,
responsable,
Belcy Arroyo Equipo de colaboradora, Programador
Desarrollo perseverante,
organizado y
autodidacta
5.2. Planeación de Iteración
ID TAREA PRIORIDAD ESTIMACION

Elaborar historial de usuario de Gestionar
HU1-1 Alta 2 horas
categoría
HU1-2 Diseñar interfaz de gestionar categoría Alta 2 horas
HU1-3 Implementar la interfaz de gestionar categoría Alta 3 horas
Elaborar historial de usuario de Gestionar 3 horas
HU2-1 Alta
empresa
HU2-2 Diseñar interfaz de gestionar empresa Alta 2 horas
HU2-3 Implementar la interfaz de gestionar Empresa Alta 2 horas
HU3-1 Alta
notificación
HU3-2 Diseñar interfaz de gestionar Notificación Media 2 horas
HU3-3 Implementar la interfaz de gestionar Notificación Alta 2 horas
35
HU4-1 Elaborar historial de usuario de Gestionar reserva Alta 2 horas
HU4-2 Diseñar interfaz de gestionar Reserva Alta 2 horas
HU4-3 Implementar la interfaz de gestionar Reserva Alta 3 horas
HU5-1 Elaborar historial de usuario de Gestionar usuario Alta 2 horas
HU5-2 Diseñar interfaz de gestionar Usuario Alta 2 horas
HU5-3 Implementar la interfaz de gestionar Usuario Alta 3 horas
HU6-1 Elaborar historial de usuario de Verificar estado Media 2 horas
HU6-2 Diseñar interfaz de Verificar Estado Alta 3 horas
HU6-3 Implementar la interfaz de Verificar Estado Alta 2 horas
HU7-1 Elaborar historial de usuario de Gestionar grupo Alta 2 horas
HU7-2 Diseñar interfaz de gestionar Grupo Alta 3 horas
HU7-3 Implementar la interfaz de gestionar Grupo Alta 2 horas
HU8-1 Alta
producto
HU8-2 Diseñar interfaz de gestionar Producto Alta 3 horas
HU8-3 Implementar la interfaz de gestionar Producto Alta 2 horas
HU9-1 Elaborar historial de usuario de Gestionar detalle Alta 2 horas
HU9-2 Diseñar interfaz de Gestionar Detalle Alta 3 horas
HU9-3 Implementar la interfaz de Gestionar Detalle Alta 2 horas
HU10-1 Elaborar historial de usuario de Gestionar servicio Alta 2 horas
HU10-2 Diseñar interfaz de Gestionar Servicio Alta 3 horas
HU10-3 Implementar la interfaz de Gestionar Servicio Alta 2 horas
HU11-1 Elaborar historial de usuario de Gestionar carrito Alta 2 horas
HU11-2 Diseñar interfaz de Gestionar Carrito Alta 3 horas
HU11-3 Implementar la interfaz de Gestionar Carrito Alta 2 horas
HU12-1 Elaborar historial de usuario de Generar reporte Alta 2 horas
HU12-2 Diseñar interfaz de Gestionar Reporte Alta 3 horas
HU12-3 Implementar la interfaz de Gestionar Reporte Alta 2 horas
HU13-1 Elaborar historial de usuario de Generar pedido Alta 2 horas
HU13-2 Diseñar interfaz de Gestionar Pedido Alta 3 horas
HU13-3 Implementar la interfaz de Gestionar Pedido Alta 2 horas
HU14-1 Elaborar historial de usuario de Gestionar rol Alta 2 horas
HU14-2 Diseñar interfaz de Gestionar Rol Alta 3 horas
HU14-3 Implementar la interfaz de Gestionar Rol Alta 2 horas
FINAL DEL SPRINT 98
final
horas
5.3. Historia de Usuario

 5.3.1. CU1.Gestionar categoría
36
Historia De Usuario
Numero: HU1 Usuario: administrador
Nombre de Historia: Diseñar la interfaz Gestionar categoría
Prioridad en negocio: media Puntos estimados: 7
Riesgo en desarrollo: Alta Puntos reales:
Programador responsable: Belcy Arroyo
Descripción: Esta funcionalidad permitirá al administrador
añadir y eliminar las categorías
Condición de Satisfacción:
 El administrador podrá registrar y editar las categorías
Prototipo:
 5.3.2. CU2.Gestionar empresa
Historia De Usuario
Numero: HU2 Usuario: Usuario
Nombre de Historia: Diseñar la interfaz Gestionar empresas
Descripción: Esta funcionalidad permitirá al usuario
registrarse como empresa si tiene q ofrecer su algún
producto
37
 El admin y el usuario podrán registrar empresa
Prototipo:
5.3.3. CU3. Gestionar notificación
Historia De Usuario
Numero: HU3 Usuario: Administrar
Nombre de Historia: Diseñar la interfaz Gestionar Notificación
Descripción: Esta funcionalidad permitirá al administrador enviar y
recibir notificaciones
 El administrador recibir y enviar notificaciones
38
Prototipo:
 5.3.4. CU4.Gestionar reserva
Historia De Usuario
Nombre de Historia: Diseñar la interfaz Gestionar reserva
Descripción: Esta funcionalidad permitirá al Usuario registrar
reserva a las empresa
 El usuario podrá registrar reserva de los producto q deseé
39
Prototipo:
 5.3.5. CU5.Gestionar usuario
Historia De Usuario
Numero: HU7 Usuario: usuario
Nombre de Historia: Diseñar la interfaz Gestionar usuario
registrar sus datos
 El administrador podrá registrar sus datos
Prototipo:
40
 5.3.6. CU6.Verificar estado
Historia De Usuario
Nombre de Historia: Diseñar la verificar estado
Descripción: Esta funcionalidad permitirá al administrador ver
el estado de las pedido
 El administrador podrá ver el estado del pedido
41
Prototipo:
 5.3.7. CU7.Gestionar grupo(paqete)
Historia De Usuario
Nombre de Historia: Diseñar la interfaz Gestionar grupo
Descripción: Esta funcionalidad permitirá al gestionar los
grupos de empresa
 El administrador podrá registrar empresas
Prototipo:
42
 5.3.8. CU8.Gestionar producto (ITEM)
Historia De Usuario
Nombre de Historia: Diseñar la interfaz Gestionar Producto
registrar los producto q ofrecen las empresas
El administrador podrá registrar y eliminar los productos q registre
Prototipo:
43
 5.3.9. CU9.Gestionar detalle
Historia De Usuario
Nombre de Historia: Diseñar la interfaz Gestionar detalle
Descripción: Esta funcionalidad permitirá administrar gestionar la
factura de los carritos
 El administrador podrá mostrar la factura
44
Prototipo:
 5.3.10. CU10.Gestionar servicio
Historia De Usuario
Numero: HU10 Usuario: usuario
Nombre de Historia: Diseñar la interfaz Gestionar servicios
Descripción: Esta funcionalidad permitirá al usuario elegir los
servicios q requiere
 El usuario podrá registrar y editar los servicios q requiere
45
Prototipo:
 5.3.11. CU11.Gestionar carrito
Historia De Usuario
Nombre de Historia: Diseñar la interfaz Gestionar carrito
seleccionar los productos que deseé en su carrito
 El administrador podrá seleccionar y eliminar los productos
Prototipo:
46
 5.3.12. CU12.Generar reporte
Historia De Usuario
Nombre de Historia: Diseñar la interfaz Generar reporte
mostrar los reportes de las compras de los usuarios
 El administrador podrá registrar y mostrar los reportes
Prototipo:
47
 5.3.13. CU13.Generar pedido
Historia De Usuario
Nombre de Historia: Diseñar la interfaz Generar Pedido
Descripción: Esta funcionalidad permitirá al usuario generar
pedido con los productos q deseé
 El administrador podrá registrar y seleccionar los pedido
48
Prototipo:
 5.3.14. CU14.Gestionar rol
Historia De Usuario
Nombre de Historia: Diseñar la interfaz Gestionar Rol
registrar los roles de los que usan los sistemas
 El administrador podrá mostrar que tipo de usuario es
49
Prototipo:
50
5.4. Pila del Sprint 1
1er semana 2da semana 3ra semana 4ta semana
10-sept
12-sept
15-sept
19-sept
22-sept
24-sept
26-sept
31-sept
8-sept
7 - sept
14-sept
17-sept
21-sept
27-sept
29-sept
12-sept
Sprint Inicio Duracio
n
1 6-septiembre 16 dias
42 38 34 33 3 30 28 25 23 21 1 16 13 10 5 0
Tareas Pendientes 2 9
4 16 17 6 1 13 13 9 8 9 1 7 6 13 12 18
Horas de trabajo Pendientes 3 1
Pila Del Sprint
ESFUERZO
Código Tarea Tipo Estado Responsable
Elaborar historial Belcy

de usuario de arroyo
HU1-1 Requisitos Terminado 1 2
Gestionar
categoría
Diseñar interfaz Belcy
HU1-2 de gestionar desarrollo Terminado arroyo 2 1
categoría
Implementar la Belcy
interfaz de arroyo
HU1-3 Análisis Terminado 1 1
gestionar
categoría
Gestionar
empresa
empresa
HU2-3 interfaz de desarrollo Terminado arroyo 2 2
gestionar Empresa
Gestionar
notificación
Notificación
interfaz de arroyo
HU3-3 desarrollo Terminado 2 1
gestionar
Notificación
HU4-1 de usuario de Requisitos Terminado arroyo 1 2
Gestionar reserva
HU4-2 de gestionar desarrollo Terminado arroyo 2
Reserva
HU4-3 Implementar la desarrollo Terminado Belcy 2
51
interfaz de arroyo
gestionar Reserva
HU5-1 de usuario de Requisitos Terminado arroyo 1
Gestionar usuario
HU5-2 de gestionar desarrollo Terminado arroyo 1
Usuario
HU5-3 interfaz de desarrollo Terminado arroyo 1
gestionar Usuario
Verificar estado 2
HU6-2 de Verificar desarrollo Terminado arroyo 2
Estado 2
HU6-3 interfaz de desarrollo Terminado arroyo 1
Verificar Estado 2
Gestionar grupo
Grupo
gestionar Grupo
Gestionar
producto
HU8-2 de gestionar desarrollo Terminado arroyo 2 2 2
Producto
interfaz de arroyo
HU8-3 desarrollo Terminado 2 2
gestionar
Producto
Gestionar detalle
HU9-2 de Gestionar desarrollo Terminado arroyo 2 2
Detalle
HU9-3 interfaz de desarrollo Terminado arroyo 2 2 2
Gestionar Detalle
HU10-1 de usuario de Requisitos Terminado arroyo 2 2 2 2
Gestionar servicio
HU10-2 de Gestionar desarrollo Terminado arroyo 2 2 2
Servicio
interfaz de arroyo
HU10-3 desarrollo Terminado 2 2 2
Gestionar
Servicio
HU11-1 Elaborar historial Requisitos Terminado Belcy 1 3 2 2
52
Gestionar carrito
HU11-2 de Gestionar desarrollo Terminado arroyo 2 2
Carrito
Gestionar Carrito
Elaborar historial Belcy 2 3
Generar reporte
Diseñar interfaz Belcy 2 3
HU12-2 de Gestionar desarrollo Terminado arroyo 2
Reporte
Implementar la Belcy 2 3
HU12-3 interfaz de desarrollo Terminado arroyo
Gestionar Reporte
Elaborar historial Belcy 2 2 3
HU13-1 de usuario de Requisitos Terminado arroyo
Generar pedido
HU13-2 de Gestionar desarrollo Terminado arroyo
Pedido
Implementar la Belcy 2 3
Gestionar Pedido
Elaborar historial Belcy 2 2 3
HU14-1 de usuario de Requisitos Terminado arroyo
Gestionar rol
HU14-2 desarrollo Terminado
de Gestionar Rol arroyo
Implementar la Belcy 3 2 3
Gestionar Rol
5.5. Burndown (Grafica de tareas y Datos de tareas)
1ra semana 2da semana 3ra semana 4ta semana

1di 2di 3di 4di 5di 6di 7di 8di 9di 10di 11di 12di 13di 14di 15di 16dia
a a a a a a a a a a a a a a
HU1-1 1 2
HU1-2 2 1
HU1-3 1 1
HU2-1 2 2
HU2-2 2 1
HU2-3 2 2
HU3-1 2 1
HU3-2 1 1
HU3-3 2 1
53
HU4-1 1 2
HU4-2 2
HU4-3 2
HU5-1 1
HU5-2 1
HU5-3 1
HU6-1 2
HU6-2 2 2
HU6-3 2 1
HU7-1 2 2
HU7-2 2 2
HU7-3 1 1
HU8-1 2 2
HU8-2 2 2 2
HU8-3 2 2
HU9-1 2 2
HU9-2 2 2
HU9-3 2 2 2
HU10-1 2 2 2 2
HU10-2 2 2 2
HU10-3 2 2 2
HU11-1 1 3 2 2
HU11-2 2 2
HU11-3 2 3
HU12-1 3 2 3
HU12-2 2 2 3
HU12-3 2 3
HU13-1 2 2 3
HU13-2 2 3
HU13-3 2 3
HU14-1 3 2 3
HU14-2
HU14-3
Actual 42 37 33 31 30 28 27 24 22 19 16 15 14 11 5 1
planead 42 38 34 33 32 30 28 25 23 21 19 16 13 10 5 0
o
54
Chart Title
45
40
35
30
25
20
15
10
0
1dia 2dia 3dia 4dia 5dia 6dia 7dia 8dia 9dia 10dia 11dia 12dia 13dia 14dia 15dia 16dia
actual planeado
5.6. Grafica de esfuerzo y Datos de esfuerzo
1ra semana 2da semana 3ra semana 4ta semana

1dia 2di 3dia 4di 5di 6di 7dia 8di 9di 10dia 11di 12di 13dia 14di 15di 16dia
a a a a a a a a a
HU1-1 1 2
HU1-2 2 1
HU1-3 1 1
HU2-1 2 2
HU2-2 2 1
HU2-3 2 2
HU3-1 2 1
HU3-2 1 1
HU3-3 2 1
HU4-1 1 2
HU4-2 2
HU4-3 2
HU5-1 1
HU5-2 1
HU5-3 1
HU6-1 2
HU6-2 2 2
HU6-3 2 1
55
HU7-1 2 2
HU7-2 2 2
HU7-3 1 1
HU8-1 2 2
HU8-2 2 2 2
HU8-3 2 2
HU9-1 2 2
HU9-2 2 2
HU9-3 2 2 2
HU10-1 2 2 2 2
HU10-2 2 2 2
HU10-3 2 2 2
HU11-1 1 3 2 2
HU11-2 2 2
HU11-3 2 3
HU12-1 3 2 3
HU12-2 2 2 3
HU12-3 2 3
HU13-1 2 2 3
HU13-2 2 3
HU13-3 2 3
HU14-1 3 2 3
HU14-2
HU14-3
Actual 4 16 17 6 13 13 13 9 8 9 11 7 6 13 12 18
HORAS DE TRABAJO
20
18
16
14
12
10
8
6
4
2
0
1dia 2dia 3dia 4dia 5dia 6dia 7dia 8dia 9dia 10dia 11dia 12dia 13dia 14dia 15dia 16dia
horas
56
5.7. Scrum TaskBoard
57
5.9. Conclusión
En este sprint 1 planteamos todas las tareas que tenemos y como soy el scrum master,
product Owner y team tuve q resolver todas las tareas pero también recibí ayuda de algunos
compañeros.
58
6.7. Análisis de la arquitectura
6.7.1. Análisis de casos de uso
GESTIONAR RESERVA
sd GESTIONAR RESERVA
2.3: eliminar()
2: eliminar() 2.1: eliminar()
1.5: Ingresar datos()
1.1: crear reserva()
1: registrar()
1.2: visualizar reserva()

2.2: visualizarEliminar(visualizar) ControlarReserva Reserva
CLIENTE Lista de reserva
(fromactores)
1.4: insertar datos()

1.3: modificar reserva()
Modificar Reserva
59
60
6.7.2. Diagrama de componentes
6.7.3. Diagrama de despliegue
61
6.7.4. Diagrama organizado en capas
62
uc DIAGRAMA ORGANIZADO EN CAPAS
PRODUCTO CATEGORIA USUARIO

SERVICIO EMPRESA ROL RESERVA REPORTE
PEDIDO
«trace» «trace» «trace»

«trace» «trace» «trace» «trace» «trace» «trace»
ADMINISTRACION PEDIDO
SERVICIO
«trace» «trace» «trace»
PHP BASE DE DATOS

HOSTING NAVEGADOR INTERNET
«trace»
«trace» «trace»
«trace»
TCP/IP
6.8. Mecanismos que posibiliten que el usuario pueda aprender a

usar la aplicación
1º El usuario debe registrar sus datos
63
2º Ingresa y puede ver las distintas empresas
3º El cliente puede ver los distintos servicios que prestan a detalle y puede añadir al
carrito los productos que requiera, con sus respectivos precios. También puede hacer
la calificación de acuerdo al grado de satisfacción.
64
4º Le mostrará una notificación con un mensaje indicándole que su paquete a sido
aceptado
6.9. Bibliografía
MARCO TEÓRICO: https://proyectosagiles.org/que-es-scrum/

https://www.google.com/url?
sa=t&rct=j&q=&esrc=s&source=web&cd=11&cad=rja&uact=8&
ved=2ahUKEwjKmpbVpa7dAhXikOAKHRVNCNoQFjAKegQICBAC&url=https%3A
%2F%2Fww w.scrumguides.org%2Fdocs%2Fscrumguide%2Fv1%2Fscrum-guide-
es.pdf&usg=AOvVaw2W mdUBXkLtpmcUmFJldMPy
7. Anexos
65
66

Eventos Belsy

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Eventos Belsy

Cargado por

Copyright:

Formatos disponibles

Contenido

El uso de la tecnología se ha convertido en una herramienta primordial con mayores

¿Qué es un software de gestión en la Nube?

Tanto la información como el tráfico de datos que generamos con esas aplicaciones

Una forma de asegurar que las aplicaciones muestren un rendimiento óptimo en un

En el futuro, se espera que la mayoría de los esfuerzos de desarrollo de aplicaciones

1.2.2. Objetivo Especifico

✔ Establecer requerimientos funcionales para el diseño del sistema de

✔ Utilizar la metodología de desarrollo de software PUDS y SCRUM

✔ Diseñar e implementar una base de datos mediante la utilización de SGBD

✔ Implementar la interfaz del software acorde a los requerimientos del

1.3. Descripción del Problema

1.4. Formulación del Problema

Id, Código, descripción

 Gestionar reporte de pedido

1.6. Elaborar una tabla Backlog (Lista de deseos)

Elaborar historial de usuario de Gestionar categoría

1.7. Modelo de Dominio

Esta clase registra grupos de clientes

1.7.2. Identificar Relaciones

class Modelo de clases

2.2. Visión General de SCRUM

2.3. El equipo SCRUM (Scrum Team)

2.4. El Dueño del Producto (Product Owner)

2.5. El Equipo de Desarrollo (Development Team)

2.6. El Scrum Master

2.7. Eventos de Scrum

2.9. Reunión de Planificación de Sprint (Sprint Planning Meeting)

La Reunión de Planificación de Sprint responde a las siguientes preguntas:

2.10. Objetivo del Sprint (Sprint Goal)

2.11. Scrum Diario (Daily Scrum)

El Scrum Master se asegura de que el Equipo de Desarrollo tenga la reunión,

2.12. Revision de Sprint (Sprint Review)

2.13. Retrospectiva de Sprint (Sprint Retrospective)

2.14. Artefactos de Scrum

2.15. Lista de Producto (Product Backlog)

El Equipo Scrum decide cómo y cuándo se hace el refinamiento.

2.16. Lista de Pendientes del Sprint (Sprint Backlog)

2.18. Transparencia de los Artefactos

2.19. Definición de “Terminado” (Definition of “Done”)

Los Equipos de Desarrollo entregan un Incremento de funcionalidad de

2.20. Ventajas y Desventajas

2.21. Valores del trabajo

2.22. Herramientas de trabajo

3. Personas y Roles del Proyecto

Persona Rol Aptitudes Tarea

4. MODELOS USADOS PARA EL DESARROLLO DE SCRUM

Código Descripción de la tarea Prioridad

4.2 Pila de Sprint (Sprint Backlog) Sprint 0

ID TAREA PRIORIDAD ESTADO RESPONSABLE

Entrevista con Product Belcy Arroyo

4.3. Elementos : Pila del sprint

Entrevista Belcy Arroyo

4.4. Sprint Review

 Optimizar el valor del trabajo del Equipo.

4.5. Sprint Restrospective

4.7. Ejecución de la iteración

class Modelo de clases

SERVICIO «trace» (from Casos de uso principales)

«trace» (from Casos de uso principales)

(from Casos de uso principales)

4.11.2. Scrum TaskBoard

Persona Rol Aptitudes Tarea