Este documento proporciona información sobre la metodología Scrum que se utilizará para el desarrollo del sistema "Pet's Friends". Describe los roles clave como el Product Owner, el Scrum Master y el Equipo, así como los eventos principales como las reuniones diarias, las revisiones y retrospectivas del sprint. Además, explica los artefactos como el Product Backlog, el Sprint Backlog y los gráficos de seguimiento. El objetivo es desarrollar el sistema en iteraciones cortas para entregar valor al cliente de forma continua.

1.  CURSO:
TEMA:
Software II
Metodología Scrum
 ALUMNAS:
• Cholán Vigo, Anice
• López Young, Naysha
 DOCENTE:
 FACULTAD:
 CICLO:
Díaz Pulido, Arturo
Ing .Informática
VI

2. • Tradicionalmente estas metodologías se centran en el
control del proceso, estableciendo rigurosamente las
actividades, herramientas y notaciones al respecto, dado
estas reglas estas metodologías se caracterizan por ser
rígidos y dirigidos por la documentación que se genera en
cada una de las actividades desarrolladas.
• Este enfoque no resulta ser el más adecuado para muchos
de los proyectos actuales donde el entorno del sistema es
muy cambiante, y en donde se exige reducir drásticamente
los tiempos de desarrollo pero manteniendo una alta
calidad.

3. El concepto de Scrum tiene su origen en un estudio de 1986 sobre los
nuevos procesos de desarrollo utilizados en productos exitosos en
Japón y los Estados Unidos (cámaras de fotos de Canon,
fotocopiadoras de Xerox, automóviles de Honda, ordenadores de HP y
otros).
En 1993 se realizó el primer Scrum para desarrollo de software y en 1995
el proceso fue formalizado. En 2001 un grupo de personas muy
relevantes en lo que empezaba a ser el desarrollo ágil escribieron los
valores fundamentales de los procesos ágiles.
En la actualidad, Scrum se está utilizando en diferentes tipos de
negocio y, especialmente, en el desarrollo de software.

4.  Scrum es una metodología ágil y flexible para gestionar el
desarrollo de software, cuyo principal objetivo es maximizar el
retorno de la inversión para su empresa (ROI). Se basa en construir
primero la funcionalidad de mayor valor para el cliente y en los
principios de inspección continua, adaptación, auto-gestión e
innovación.

5.  En Scrum un proyecto se ejecuta en bloques temporales cortos y
fijos (iteracionesde un mes natural y hasta de dos semanas, si así se
necesita). Cada iteración tiene que proporcionar un resultado
completo, un incremento de producto final que sea susceptible de
ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

6.  Planificación de la iteración:
El primer día de la iteración se realiza la reunión de
planificación de la iteración. Tiene dos partes:
Planificación de
la iteración
Ejecución de la
iteración
Selección de
requisitos
Inspección y
adaptación

7. PreJuego
PreJuego
• Planeamiento: El propósito es establecer la visión, definir
expectativas y asegurarse la financiación.
• Montaje (Staging): El propósito es identificar más requerimientos y
priorizar las tareas para la primera iteración. Las actividades son
planificación, diseño exploratorio y prototipos.
Juego • El propósito es implementar un sistema listo para entrega en una
o
serie de iteraciones de treinta días llamadas “corridas” (sprints).
Desarro
llo
PosJuego
• Liberación: El propósito es el despliegue operacional. Las
actividades, documentación, entrenamiento, mercadeo y venta.

8. VENTAJAS
 Programación organizada.
DESVENTAJAS
 Es recomendable emplearlo solo
en proyectos a corto plazo.
 Menor taza de errores.
 Satisfacción del programador.
 Altas comisiones en caso de
fallar.

9.  Enfatiza valores y prácticas de gestión, sin pronunciarse sobre
requerimientos, prácticas de desarrollo, implementación y demás
cuestiones técnicas.
 Hace uso de Equipos auto-dirigidos y auto-organizados.
 Puede ser aplicado teóricamente a cualquier contexto en donde un
grupo de gente necesita trabajar junta para lograr una meta común.
 Desarrollo de software iterativos incrementales basados en prácticas
agiles.
 Iteraciones de treinta días; aunque se pueden realizar con más
frecuencia, estas iteraciones, conocidas como Sprint.

10.  En Scrum, el equipo se focaliza en construir software de calidad. La
gestión de un proyecto Scrum se centra en definir cuáles son las
características que debe tener el producto a construir (qué construir,
qué no y en qué orden) y en vencer cualquier obstáculo que pudiera
entorpecer la tarea del equipo de desarrollo.

11. Scrum
master:
• Persona que lidera al equipo guiándolo para que cumpla
las reglas y procesos de la metodología. Gestiona la
reducción de impedimentos del proyecto y trabaja con
el Product Owner para maximizar el ROI.
Product
owner (PO):
• Representante de lso accionistas y clientes que usan el
software. Se focaliza en la parte de negocio y el es
responsable del ROI del proyecto (entregar un valor
superior al dinero invertido). Traslada la visión del
proyecto al equipo, formaliza las prestaciones
en historias a incorporar en el Product Backlog y las
reprioriza de forma regular.
Team:
• Grupo de profesionales con los conocimientos técnicos
necesarios y que desarrollan el proyecto de manera
conjunta llevando a cabo las historias a las que se
comprometen al inicio de cada sprint.

12.  El corazón de Scrum es el Sprint, es un bloque de tiempo (timebox) 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 lo largo del esfuerzo de desarrollo. Cada nuevo
Sprint comienza inmediatamente después de la finalización del
Sprint previo.

13.  Cancelación de un Sprint:
Un Sprint puede ser cancelado antes de que el bloque de
tiempo llegue a su fin. Solo el Dueño de Producto tiene la
autoridad para cancelar el Sprint, aunque puede hacerlo bajo
la influencia de los interesados, del Equipo de Desarrollo o del
Scrum Master.
Un Sprint se cancelaría si el Objetivo del Sprint llega a quedar
obsoleto. Esto podría ocurrir si la compañía cambia la dirección
o si las condiciones del mercado o de la tecnología cambian.
En general, un Sprint debería cancelarse si no tuviese sentido
seguir con él dadas las circunstancias.

14.  Reunión de Planificación de Sprint (sprint planning
meeting) :
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.

15.  Objetivo del Sprint (sprint goal)
El Objetivo del Sprint 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.

16.  Scrum Diario (daily scrum)
El Scrum Diario 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 último Scrum Diario y haciendo una
proyección acerca del trabajo que podría completarse antes del
siguiente.

17.  Revisión 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.

18.  Retrospectiva de Sprint (sprint retrospective)
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.

19. Facilitar la información de referencia necesaria a las personas implicadas
en el desarrollo del sistema “Pet´s Friend´s”.
Personas y procedimientos implicados en el desarrollo
del sistema “Pet´s Friend´s”.

20. Las principales razones del uso de un ciclo de desarrollo iterativo e
incremental de tipo scrum para la ejecución de este proyecto son:
 Sistema modular Las características del sistema “Pet´s Friend´s”
permiten desarrollar una base funcional mínima y sobre ella ir
incrementando
las
funcionalidades
o modificando
el
comportamiento o apariencia de las ya implementadas.
 Entregas frecuentes y continuas al cliente de los módulos
terminados, de forma que puede disponer de una funcionalidad
básica en un tiempo mínimo y a partir de ahí un incremento y
mejora continua del sistema.

21. Requisitos de nuestro Cliente:





Tener un registro de los clientes.
Tener un registro de las mascotas.
Tener un registro de Atención en citas.
Registro de hospitalizaciones.
Emitir reportes de citas.
Los valores que deben ser practicados por todos los miembros
involucrados en el desarrollo y que hacen posible que la
metodología Scrum tenga éxito son:





Autonomía del equipo
Respeto en el equipo
Responsabilidad y auto-disciplina
Foco en la tarea
Información transparencia y visibilidad.

22. Persona
Naysha López
Young
Anice Cholán
Vigo
Naysha / Anice
Contacto
mary.9333@hotmail.com
Rol
Scrum master
951052101
aychv_10@hotmail.com
Product owner
979544907
Team

23. • Pila de producto o Product Backlog:
Responsabilidades del gestor de producto:
 Presencia en las reuniones en las que el equipo elabora la pila del
sprint. Resolución de dudas sobre las historias de usuario que se
descomponen en la pila del sprint.
 Responsabilidades del Scrum Manager.
 Supervisión y asesoría en la elaboración de la pila de la pila del
sprint.
 Responsabilidades del equipo técnico.
 Elaboración de la pila del sprint.

24. • Pila de sprint o Sprint Backlog:
Responsabilidades del gestor de producto:
 Registró en la lista de pila del producto de las historias de
usuario que definen el sistema.
 Mantenimiento actualizado de la pila del producto en todo
momento durante la ejecución del proyecto.
 Orden en el que desea quiere recibir terminada cada
historia de usuario.
 Incorporación / eliminación /modificaciones de las historias
o de su orden de prioridad.

25. Responsabilidades del Scrum Manager:
 Supervisión de la pila de producto, y comunicación con el gestor del
producto para pedirle aclaración de las dudas que pueda tener, o
asesorarle para la subsanación de las deficiencias que observe.
Responsabilidades del equipo técnico:
 Conocimiento y comprensión actualizada de la pila del producto.
Resolución de dudas o comunicación de sugerencias con el cliente.
Responsabilidades del resto de implicados:
 Conocimiento
y
comprensión
actualizada de la pila del producto.

26. Gráfica de producto o Burn Up: Utilizado por el Product Owner , datos
que muestra:






Las versiones previstas de un producto
Funcionalidades de cada una de ellas
Velocidad estimada
Fechas probables para cada versión
Margen de error previsto en las estimaciones
Avance real
Responsabilidades del Scrum Manager:
• Supervisión del gráfico de producto, y comunicación con el gestor
del producto para pedirle aclaración de las dudas que pueda
tener, o asesorarle para la subsanación de las deficiencias que
observe.

27. Responsabilidades del equipo técnico:
• Conocimiento y comprensión actualizada del plan del producto.
Resolución de dudas o comunicación de sugerencias.
Responsabilidades del resto de implicados:
• Conocimiento y comprensión actualizada del plan de producto.
Resolución de dudas o comunicación de sugerencias.

29. Gráfica de avance o Burn Down: Utilizado por el Scrum Team para
seguimiento del trabajo de cada Sprint:
Responsabilidades del gestor de producto:
• Sin responsabilidades específicas, más allá de mantenerse
regularmente informado del avance del sprint y disponible para
atender decisiones para la resolución de opciones en sprints
sobrevalorados o infravalorados (la gráfica de avance predice una
entrega anterior o posterior a la fecha prevista)
Responsabilidades del Scrum Manager:
• Supervisión de la actualización diaria por
parte del equipo.
Responsabilidades del equipo técnico:
• Actualización diaria del gráfico de avance.

30. Gráfica de avance o Burn Down: Utilizado por el Scrum Team para
seguimiento del trabajo de cada Sprint:

31.  Reunión de inicio de sprint:
Llevaremos a cabo nuestro trabajo un periodo de 3 semanas, así
realizaremos ajustes en los cambios dependiendo a nuestra capacidad
como equipo, al final de cada sprint nuestro equipo presentara avances
logrados, y el resultado obtenido es un producto potencialmente
entregable al cliente.
Responsabilidades del gestor de producto
 Asistencia a la reunión.
 Exposición y explicación de las historias
que necesita para la próxima iteración y
posibles restricciones de fechas que
pudiera tener.

32. Responsabilidades del Scrum Manager
 Moderación de la reunión
Responsabilidades del equipo técnico
 Confección de la pila del sprint.
 Auto-asignación del trabajo.
 Reunión técnica diaria:
Nuestro equipo tiene el deber de tener reuniones diarias un aproximado
de 15 minutos o más, para resolver problemas o aportar en nuestro
proyecto, para bien de este y claro de nuestro cliente.
Responsabilidades del Scrum Manager
 Supervisión de la reunión y anotación de las necesidades o
impedimentos que pueda detectar el equipo.
 Gestión para la solución de las necesidades o impedimentos
detectados por el equipo.

33. Responsabilidades del equipo técnico
 Comunicación
individual
del
trabajo realizado el día anterior y el
previsto para día actual.
 Actualización individual del trabajo
pendiente.
 Actualización del gráfico de avance.
 Notificación de necesidades o impedimentos previstos u
ocurridos para realizar las tareas asignadas.

34.  Creación de la Pila De Producto:
El cliente ordena en bloques de trabajo, según su prioridad de
entrega.







Gestión de Citas, incluyendo
Gestión de Registros
Gestión de Enfermedades.
Gestión de Historiales
Gestión de Hospitalización.
Gestión de Vacunas
Pagos y Factura
 Revisión del Sprint:
Participaremos todos los integrantes del equipo; un aproximado de 4
horas, presentación del incremento del proyecto y sugerencias, por
ultimo anunciaremos el próximo Sprint.

35.  Retrospectiva:
Se trata de una reunión restringida a un bloque de tiempo de tres horas
para Sprints de un mes. Identificamos y ordenamos los elementos más
importantes que salieron bien y las posibles mejoras.
 Reunión de cierre de sprint:
Reunión para probar y entregar el incremento al gestor del producto.
Características:
 Prácticas: sobre el producto terminado, no sobre simulaciones o
imágenes).
 De tiempo acotado máximo de 2 horas.

36. Responsabilidades del gestor de producto
 Asistencia a la reunión.
 Recepción del producto o presentación de reparos.
Responsabilidades del Scrum Manager
 Moderación de la reunión
Responsabilidades del equipo técnico
 Presentación del incremento.

37. Cada prueba es especificada mediante un documento que
establece las condiciones de ejecución, las entradas de la
prueba, y los resultados esperados. Estos casos de prueba son
aplicados como pruebas de regresión en cada iteración.
Cada caso de prueba llevará asociado un procedimiento de
prueba con las instrucciones para realizar la prueba, y
dependiendo del tipo de prueba dicho procedimiento podrá ser
automatizable mediante un script de prueba.

38.  Cumplimento de expectativas:
El cliente establece sus expectativas indicando el valor que le aporta
cada requisito / historia del proyecto, el equipo los estima y con esta
información el Product Owner establece su prioridad. De manera regular,
en las demos de Sprint el Product Owner comprueba que efectivamente
los requisitos se han cumplido y transmite se feedback al equipo.
 Flexibilidad a cambios:
Alta capacidad de reacción ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La
metodología está diseñada para adaptarse a los cambios de
requerimientos que conllevan los proyectos complejos.

39.  Reducción del Time to Market:
El cliente puede empezar a utilizar las funcionalidades más
importantes del proyecto antes de que esté finalizado por
completo.
 Mayor calidad del software:
La metódica de trabajo y la necesidad
de obtener una versión funcional
después de cada iteración, ayuda a la
obtención de un software de calidad
superior.

40. Fig.2. Ingreso datos del cliente
Fig.1. Ingreso al Sistema

41. Fig.3. Ingreso datos de la mascota

42. Fig.4. Historial Clínico

43. Fig.5. Vista Principal

44.  El origen de las metodologías ágiles proviene del mundo del
desarrollo de software, pero actualmente se están empezando a
emplear en ámbitos diferentes.
 Scrum es una metodología ágil y flexible para gestionar el
desarrollo de software, cuyo principal objetivo es maximizar el
retorno de la inversión para su empresa (ROI).
 El corazón de Scrum es el Sprint, es un bloque de tiempo (timebox) de un mes o menos durante el cual se crea un incremento
de
producto
“Terminado”,
utilizable
y
potencialmente
desplegable.