Metodologia Scrum/ Veterinaria "PET´S FRIEND´S" utilizando metodologis Scrum

1. UNIVERSIDAD NACIONAL DE TRUJILLO
SEDE VALLE JEQUETEPEQUE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
ESCUELA DE INGENIERÍA INFORMÁTICA
MONOGRAFÍA
METODOLOGÍA SCRUM
AUTORES:


CHOLÁN VIGO ANICE YUVITZA
LÓPEZ YOUNG NAYSHA MARISELA
GUADALUPE – PERÚ
-2013-

2. INDICE
DEDICATORIA………………………………………………………………………..3
INTRODUCCION…………………………………….………………………………..4
1. MARCO TEÓRICO…………………………….………………………………….5
1.1.
Capítulo I: INTRODUCCION A LA METODOLOGÍA SCRUM ……………...5
1.1.1. METODOLOGÍAS ÁGILES……………………………………………...5
1.1.2. HISTORIA DE LA METODOLOGÍA SCRUM………………………….….5
2. Capítulo II: METODOLOGÍA SCRUM………..……….………………………………6
2.1.
¿QUÉ ES SCRUM?.......................................................................................6
2.2.
¿CUÁNDO SE UTILIZA? ………………………………………………………..6
2.3.
¿CÓMO FUNCIONA? ………………………..…………………………….6
2.3.1. Planificación de la iteración………………………………………….…..7
2.3.2. Ejecución de la iteración………………………………………………….7
2.3.3. Inspección y adaptación………………………………………………….8
2.4.
CICLO DE VIDA DE SCRUM………………….…………………………………8
2.5.
VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA SCRUM………….9
2.6.
CARACTERÍSTICAS SCRUM………………………...…………………………9
3. Capítulo III: COMPONENTES Y CONCEPTOS EMPLEADOS……………………10
3.1.
ROLES……………………………………………………………………………10
3.2.
SPRINT …………………………………………………………………………..10
3.2.1. CANCELACIÓN DE UN SPRINT …………………………..……………..11
3.2.2. REUNIÓN
DE
PLANIFICACIÓN
DE
SPRINT (SPRINT
PLANNING
MEETING) …………………………………………….....12
3.2.3. OBJETIVO DEL SPRINT (SPRINT GOAL) ……………………………….12
3.2.4. SCRUM DIARIO (DAILY SCRUM) …………………………..…………….13
3.2.5. REVISIÓN DE SPRINT (SPRINT REVIEW) ……………………...……….13
3.2.6. RETROSPECTIVA DE SPRINT (SPRINT RETROSPECTIVE) ……..….14
4. Capítulo IV: METODOLOGIA SCRUM VETERINARIA PET´S FRIEND´S…....15
4.1.
FUNDAMENTACION………………………………………………………….15
4.2.
VALORES DE TRABAJO……………………………………………………16
4.3.
ARTEFACTOS…………………………………………………………………16
4.4.
RESULTADOS ESPERADOS………………………………………………..21
CONCLUSIONES……………………………………………………………………….….22
ANEXOS………………………………………………………………………….………….23
LINKOGRAFIA……………………………………………………………………………..25
2

3. Dedicamos este trabajo a Dios quien nos da la
fortaleza para seguir cada día adelante.
A nuestros padres a quienes valoramos, apreciamos,
respetamos y son un ejemplo en nuestra vida.
Así mismo a nuestro profesor Arturo, gracias por su
tiempo, por su apoyo, por la sabiduría que nos
transmite en el desarrollo del curso y permitirnos llegar
a la culminación del presente trabajo.
3

4. INTRODUCCION
Si hablamos de proyectos de desarrollo, el ciclo de la gestión de proyectos clásica
“cierre de oferta – toma detallada de requisitos – diseño – desarrollo – entrega del
producto final” no es un enfoque demasiado realista para el entorno que vivimos
actualmente. Constantemente surgen nuevas necesidades, funcionalidades no
contempladas inicialmente, cambios de requisitos, refinamientos del diseño, etc. que
son ignorados, normalmente como “fuera del alcance inicial”. Sin embargo, es esto
precisamente lo que el cliente necesita.
Como respuesta a este problema nacen las metodologías ágiles como Scrum que
garantizan flexibilidad y adaptabilidad frente a los cambios se produzcan a lo largo del
proyecto basándose en equipos de personas multidisciplinares y auto organizados que
se enfocan a aportar el máximo valor al cliente desde el principio. El cliente tiene
visibilidad inmediata sobre el producto y por tanto, la posibilidad de acertar con sus
deseos es mayor. Los miembros del equipo están más motivados e involucrados en el
objetivo final del proyecto e incrementa su productividad y satisfacción.
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. La
metodología
propuesta
es
adecuada
para
todo
proceso
de
desarrollo/diseño/implantación: diseño de los planos de un producto, desarrollo de una
estrategia de producto, desarrollo del contenido de un programa, implantación de
procesos de gestión de servicios... y en general, cualquier proceso donde el output sea
algo que el cliente pueda validar cada poco tiempo y tenga la capacidad de
reorientarlo en base a sus necesidades.
4

5. 1. MARCO TEÓRICO:
1.1.
Capítulo I: INTRODUCCION A LA METODOLOGÍA SCRUM
1.1.1. METODOLOGÍAS ÁGILES
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. En este escenario, las
metodologías ágiles emergen como una posible respuesta para llenar ese vacío
metodológico.
Los objetivos de las metodologías ágiles, entre los cuales se destaca la preferencia de
algunos valores por sobre otros, por ejemplo: Individuos e interacciones, sobre
procesos y herramientas, Software operativo, sobre documentación extensiva Y
Colaboración con el cliente, sobre negociación de Contratos.
1.1.2. HISTORIA DE LA METODOLOGÍA SCRUM
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). Los equipos que desarrollaron estos productos partían de
requisitos muy generales, así como novedosos, y debían salir al mercado en mucho
menos del tiempo del que se tardó en lanzar productos anteriores. Estos equipos
seguían patrones de ejecución de proyecto muy similares. En este estudio se
comparaba la forma de trabajo de estos equipos altamente productivos y
multidisciplinares con la colaboración entre los jugadores de Rugby y su formación
de Scrum.
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.
5

6. 2. Capítulo II: METODOLOGÍA SCRUM
2.1.
¿QUÉ ES SCRUM?
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.
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.2.
¿CUÁNDO SE UTILIZA?
Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto
dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento
realinear el software con los objetivos de negocio de su empresa, ya que puede
introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin
ningún
problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo
que forma parte del proyecto, por lo que los profesionales encuentran un ámbito
propicio para desarrollar sus capacidades.
2.3.
¿CÓMO FUNCIONA?
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de
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.
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa
como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el
valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas.
De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y
el retorno de inversión mediante la replanificación de objetivos que realiza al inicio de
cada iteración.
6

7. 2.3.1. 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:
a) Selección de requisitos (4 horas máximo): El cliente presenta al equipo la lista
de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las
dudas que surgen y selecciona los requisitos más prioritarios que se compromete
a completar en la iteración, de manera que puedan ser entregados si el cliente lo
solicita.
b) Planificación de la iteración (4 horas máximo): El equipo elabora la lista de
tareas de la iteración necesarias para desarrollar los requisitos a que se ha
comprometido. La estimación de esfuerzo se hace de manera conjunta y los
miembros del equipo se auto asignan las tareas.
2.3.2. Ejecución de la iteración:
Cada día el equipo realiza una reunión de sincronización (15 minutos máximos). Cada
miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias
entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir
este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con
el compromiso adquirido. En la reunión cada miembro del equipo responde a tres
preguntas:
 ¿Qué he hecho desde la última reunión de sincronización?
 ¿Qué voy a hacer a partir de este momento?
 ¿Qué impedimentos tengo o voy a tener?
Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con su
compromiso y de que no se merme su productividad.
 Elimina los obstáculos que el equipo no puede resolver por sí mismo.
 Protege al equipo de interrupciones externas que puedan afectar su compromiso
o su productividad.
7

8. 2.3.3. Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos
partes:
a) Demostración (4 horas máximo): El equipo presenta al cliente los requisitos
completados en la iteración, en forma de incremento de producto preparado para
ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y
de los cambios que haya habido en el contexto del proyecto, el cliente realiza las
adaptaciones necesarias de manera objetiva, ya desde la primera iteración,
replanificando el proyecto.
b) Retrospectiva (4 horas máximo): El equipo analiza cómo ha sido su manera de
trabajar y cuáles son los problemas que podrían impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El Facilitador
se encargará de ir eliminando los obstáculos identificados.
2.4.
CICLO DE VIDA DE SCRUM
El ciclo de vida de Scrum es el siguiente:
a) Pre-Juego: Planeamiento. El propósito es establecer la visión, definir
expectativas y asegurarse la financiación. Las actividades son la escritura de la
visión, el presupuesto, el registro de acumulación o retraso Metodologías
Ágiles (backlog) del producto inicial y los ítems estimados, así como la
arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de
acumulación es de alto nivel de abstracción.
b) Pre-Juego: 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.
c) Juego o Desarrollo: El propósito es implementar un sistema listo para entrega
en una serie de iteraciones de treinta días llamadas “corridas” (sprints). Las
actividades son un encuentro de planeamiento de corridas en cada iteración, la
definición del registro de acumulación de corridas y los estimados, y
encuentros diarios de Scrum.
d) Pos-Juego: Liberación. El propósito es el despliegue operacional. Las
actividades, documentación, entrenamiento, mercadeo y venta.
Usualmente los registros de acumulación se llevan en planillas de cálculo
comunes, antes que en una herramienta sofisticada de gestión de proyectos.
Los elementos del registro pueden ser prestaciones del software, funciones,
corrección de bugs, mejoras requeridas y actualizaciones de tecnología. Hay
un registro total del producto y otro específico para cada corrida de 30 días. En
la jerga de Scrum se llaman “paquetes” a los objetos o componentes que
necesitan cambiarse en la siguiente iteración.
8

9. 2.5.
VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA SCRUM
VENTAJAS
DESVENTAJAS
 Programación organizada.
 Es recomendable emplearlo solo en
proyectos a corto plazo.
 Menor taza de errores.
 Altas comisiones en caso de fallar.
 Satisfacción del programador.
2.6.
CARACTERÍSTICAS SCRUM

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.

Dentro de cada Sprint se denomina el Scrum Master al Líder de Proyecto quien
llevará a cabo la gestión de la iteración.

Se convocan diariamente un “Scrum Daily Meeting” el cual representa una
reunión de avance diaria de no más de 15 minutos con el propósito de tener
realimentación sobre las tareas de los recursos y los obstáculos que se
presentan. En la cual se responden preguntas como: ¿Qué has hecho desde el
último encuentro? ¿Qué obstáculos hay para cumplir la meta? ¿Qué harás
antes del próximo encuentro?
9

10. 3. Capítulo III: COMPONENTES Y CONCEPTOS EMPLEADOS
3.1.
ROLES
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.
El equipo Scrum está formado por los siguientes roles:
 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.
3.2.
SPRINT
El corazón de Scrum es 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 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 la Reunión de Planificación del Sprint
(Sprint Planning Meeting), los Scrums Diarios (Daily Scrums), el trabajo de
desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint
(Sprint Retrospective).
10

11. Durante el Sprint:
 No se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint Goal).
 Los objetivos de calidad no disminuyen.
 El alcance puede ser clarificado y renegociado entre el Dueño de Producto y el
Equipo de Desarrollo a medida que se va aprendiendo más.
Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes. Al
igual que los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene una
definición de qué se va a construir, un diseño y un plan flexible que guiará la
construcción y el trabajo y el producto resultante.
3.2.1. 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.
Pero debido a la corta duración de los Sprints, rara vez la cancelación tiene sentido.
Cuando se cancela un Sprint, se revisan todos los Elementos de la Lista de Producto
que se hayan completado y “Terminado”. Si una parte del trabajo es potencialmente
entregable, el Dueño de Producto normalmente lo acepta. Todos los Elementos de la
Lista de Producto no completados se vuelven a estimar y se vuelven a introducir en la
Lista de Producto. El trabajo finalizado en ellos pierde valor con rapidez y
frecuentemente debe volverse a estimar.
Las cancelaciones de Sprint consumen recursos, ya que todos deben reagruparse en
otra Reunión de Planificación de Sprint para empezar otro Sprint. Las cancelaciones
de Sprint son a menudo traumáticas para el Equipo Scrum y son muy poco comunes.
11

12. 3.2.2. REUNIÓN DE PLANIFICACIÓN DE SPRINT (SPRINT PLANNING
MEETING)
El trabajo a realizar durante el Sprint se planifica en la Reunión de Planificación de
Sprint. 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?
3.2.3. 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. El objetivo del Sprint ofrece al equipo de
desarrollo cierta flexibilidad con respecto a la funcionalidad implementada en el Sprint.
Los elementos de la Lista del Producto seleccionados ofrecen una función coherente,
que puede ser el objetivo del Sprint. El objetivo del Sprint 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).
12

13. 3.2.4. 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.
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?
3.2.5. 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.
Se trata de una reunió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.
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.
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”.
 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).
13

14. 3.2.6. RETROSPECTIVA DE SPRINT (SPRINT RETROSPECTIVE)
La Retrospectiva de Sprint 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 quelos 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.
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. Aunque las mejoras pueden implementarse en cualquier momento, la
Retrospectiva de Sprint ofrece un evento dedicado para este fin, enfocado en la
inspección y la adaptación.
14

15. 4. Capítulo IV: METODOLOGIA SCRUM “VETERINARIA PET´S FRIEND´S”
Este documento describe la implementación de la metodología de trabajo scrum en la
Clínica Veterinaria para la gestión del desarrollo el proyecto “Pet´s Friend´s”.
Incluye junto con la descripción de este ciclo de vida iterativo e incremental para el
proyecto, los artefactos o documentos con los que se gestionan las tareas de
adquisición y suministro: requisitos, monitorización y seguimiento del avance, así como
las responsabilidades y compromisos de los participantes en el proyecto.
Propósito de este documento
Facilitar la información de referencia necesaria a las personas implicadas en el
desarrollo del sistema “Pet´s Friend´s”.
Alcance
Personas y procedimientos implicados en el desarrollo del sistema
Friend´s”.
“Pet´s
Descripción General de la Metodología
4.1.
Fundamentación
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.

Previsible inestabilidad de requisitos.
o
o
Es posible que durante la ejecución del proyecto se altere el
orden en el que se desean recibir los módulos o historias de
usuario terminadas.
o

Es posible que el sistema incorpore más funcionalidades de las
inicialmente identificadas.
Para el cliente resulta difícil precisar cuál será la dimensión
completa del sistema, y su crecimiento puede continuarse en el
tiempo suspenderse o detenerse.
Requisitos del nuestro Cliente:
o
o
o
o
Tener un registro de los clientes.
Tener un registro de las mascotas.
Tener un registro de Atención en citas.
Registro de hospitalizaciones.
15

16. o
Emitir reportes de citas.
4.2.
Valores de trabajo
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.
Personas y roles del proyecto.
Persona
Contacto
Naysha López Young
Rol
mary.9333@hotmail.com
/ 951052101
Scrum master
Aychv_10@hotmail.com
Anice Cholán Vigo
979544907
Team
Naysha / Anice
4.3.

Product owner
Artefactos
Pila de producto o Product Backlog: Aquí el responsable es el dueño del
Producto; relacionamos los requisitos del producto, no detallados
excesivamente, todos los integrantes del equipo puede añadir elemento pero
solo el Product Owner añade prioridades.
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.
16

17. Responsabilidades del equipo técnico


Elaboración de la pila del sprint.
Pila de sprint o Sprint Backlog: Requisitos comprometidos por el equipo para
el sprint; cada integrante se compromete para el desarrollo del producto, tener
suficientemente detallado para su ejecución.
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.
o Orden en el que desea quiere recibir terminada cada historia
de usuario.
o Incorporación / eliminación /modificaciones de las historias o
de su orden de prioridad.
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.
Gráficas para registro y seguimiento del avance.
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
17

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

19. Responsabilidades del equipo técnico



Actualización diaria del gráfico de avance.
Comunicación y reporting directo
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.
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.
19

20. 
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.
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.
Creación de la Pila De Producto: El cliente ordena en bloques de
trabajo, según su prioridad de entrega.
o
o
o
o
o
o
o



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.
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.
20

21. 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

4.4.
Presentación del incremento.
Resultados esperados
 Documentos de reportes de pruebas aplicadas al software
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.

o
Documentación de reporte de aplicación de la metodología scrum
como estrategia de administración de proyectos de software
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.
o
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
o
o
requerimientos que conllevan los proyectos complejos.
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.
21

22. CONCLUSIONES

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 (time-box) de un mes
o menos durante el cual se crea un incremento de producto “Terminado”,
utilizable y potencialmente desplegable.

Las cancelaciones de Sprint consumen recursos, ya que todos deben
reagruparse en otra Reunión de Planificación de Sprint para empezar otro
Sprint. Las cancelaciones de Sprint son a menudo traumáticas para el Equipo
Scrum y son muy poco comunes.

. El objetivo del Sprint ofrece al equipo de desarrollo cierta flexibilidad con
respecto a la funcionalidad implementada en el Sprint.
22

23. ANEXOS
Apéndice A: Metodología Scrum
23

24. Apéndice B: Sprint - Scrum
Apéndice C: Scrum – Usuario
24

25. LINKOGRAFÍA

http://www.slideshare.net/2008PA2Info3/scrum-csar-ortiz

http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologiascrum.html

http://spanishpmo.com/index.php/roles-y-reuniones-en-la-metodologia-scrum/

http://books.google.com.pe/books?id=Wa9AXT7zHVwC&pg=PA30&dq=aplicaci
on+de+scrum+en+software&hl=es-419&sa=X&ei=TJcUonEKsn6kQfti4HoDA&ved=0CDUQ6AEwAA

http://miguelcrispin.blogspot.com/2010/12/ciclo-de-vida-de-desarrollo-desoftware.html
25