Trabajo Práctico Tercer Trimestre

Instituto Técnico Industrial San Judas

Tadeo

Orientación: Informática

Curso: 7 B

Tema: Scrum

Docente: Vazquez, Matias

Alumnos: Lanosa, Juan Ignacio; Lopez, Joaquin;

Morales, Brenda; Taschetta, Santiago.

17 de octubre de 2017
Parte I
Metodologı́a Scrum
1. Introducción
Scrum es un framework en el cual la gente puede lidiar con problemas de complejidades
adaptativas, mientras se entregan productos del valór más alto posible.

Scrum es:
Ligero
Simple de entender
Dificil de dominar

Scrum es un framework 1 que ha sido usado para manejar desarrollos de productos complejos
desde la década del 1990. Scrum no es un proceso o una técnica para construir productos; en
cambio, es un framework dentro del cual se pueden emplear varios procesos y técnicas. Scrum
vuelve clara la eficacia relativa de las prácticas de administración y desarrollo.

Las reglas de Scrum enlazan eventos, roles y artefactos, gobernando las relaciones y las
interacciones entre ellos.

2. Teorı́a de Scrum
Scrum está fundado en la teoria empı́rica de control de procesos, o empirismo. El empirismo
afirma que el conocimiento proviene de la experiencia y en las decisiones basadas en lo que es
conocido. Scrum emplea un acercamiento iterativo e incremental para optimizar la previsibilidad
y el control de riesgos.

Tres pilares defienden cada implementación del proceso empı́rico de control: la transparencia,
la inspeción, y la adaptación.

2.1. Transparencia
Los aspectos significantes del proceso deben ser visibles para aquellos responsables del resul-
tado. La transparencia requiere que aquellos aspectos sean definidos por un estándar común
para que los observadores tengan una comprensión común de lo que están viendo.

2.2. Inspección
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el pro-
greso hacia el ”Sprint Goal” 2 para detectar variaciones no deseadas. La inspección no debe ser
tan frecuente como para que interfiera con el trabajo.
1
Un framework, entorno de trabajo o marco de trabajo, es un conjunto estandarizado de conceptos, prácticas
y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver
nuevos problemas de ı́ndole similar.
2
El Sprint Goal (Objetivo del Sprint) es un objetivo que se le da al Sprint para ser cumplido durante su
desarrollo.

1
2.3. Adaptación
Si un inspector determina que uno o más aspectos del proceso sobrepasan los lı́mites acepta-
bles, y que el resultado del producto será inaceptable, el proceso o el material siendo procesado
debe ser ajustado. Este debe ser realizado lo antes posible para minimizar desvı́os futuros.

Scrum prescribe cuatro eventos formales de inspección y adaptación

Planificación del Sprint (Sprint Planning)

Scrum Diario (Daily Scrum)

Revisión del Sprint (Sprint Review)

Retrospectiva del Sprint (Sprint Retrospective)

3. El Equipo de Scrum
El Equipo de Scrum consiste de un Propietario del Producto (Product Owner), el Equipo
de Desarrollo (Development Team), y un Maestro de Scrum (Scrum Master). Los Equipos de
Scrum son autoorganizados y multifuncionales. Los equipos deciden cual es la mejor manera
de cumplir con su trabajo, sin depender de otros que no formen parte del equipo. El modelo de
equipos en Scrum esta diseñado para optimizar la flexibilidad, la creatividad y la productividad.

El Equipo de Scrum entrega productos de forma iterativa e incremental, maximizando las

oportunidades para la retroalimentación. Las entregas incrementales de un producto ”Termi-
nado” (Done) aseguran que una versión potencialmente útil del producto se encuentre siempre
disponible.

3.1. El Propietario del Producto (Product Owner)

El Propietario del Producto es el responsable de maximizar el valor del producto y del trabajo
del Equipo de Desarrollo. Como se realiza esta tarea varı́a según organizaciónes, Equipos de
Scrum, e individuos.

El Propietario del Producto es la única persona responsable de administrar el Backlog del

Producto (Product Backlog). La administración del Backlog incluye:

Expresar claramente los ı́tems del Backlog del Producto;

Ordenar los ı́tems del Backlog para alcanzar los objetivos y misiones de la mejor manera;

Optimizar el valor del trabajo que realiza el Equipo de Desarrollo;

Asegurar que el Backlog sea visible, transparente y claro para todos, y que muestre en
que trabajará el Equipo de Scrum;y,

Asegurar que el Equipo de Desarrollo comprenda los ı́tems presentes en el Backlog.

Las tareas pueden ser realizadas por el Propietario del Producto, o por el Equipo de Desa-
rrollo. Sin embargo, el Propietario del Producto será el responsable.

2
 El Propietario del Producto es una persona, no un grupo. Este puede representar los deseos
de un grupo, pero aquellos que deseen cambiar la prioridad de algún item del Backlog deberá
dirigirse al Propietario del Producto.

Para que el Propietario del Producto tenga éxito, toda la organización debe respetar sus
decisiones. Las decisiones del Propietario del Producto son visibles en el contenido y en el orden
del Backlog del Producto. Nadie tiene o puede decirle al Equipo de Desarrollo que trabaje desde
un conjunto de requerimientos distintos, y el Equipo de Desarrollo no tiene permitido actuar
sobre lo que alguien más diga.

3.2. El Equipo de Desarrollo (Development Team)

El Equipo de Desarrollo consiste de profesionales que se encargan del trabajo de entregar un
Incremento del producto ”Terminado” al final de cada Sprint. Solo los miembros del Equipo
de Desarrollo pueden encargarse de este Incremento.

Los Equipos de Desarrollo están estructurados por la organización para organizar y manejar
su propio trabajo. La acción conjunta resultante optimiza la eficacia generál del Equipo de
Desarrollo.

Los Equipos de Desarrollo tienen las siguientes caracterı́sticas:

Se autoorganizan. Nadie puede decirle al Equipo de Desarrollo como transformar el Bac-

klog en un Incremento;

Son multifuncionales, con todas las habilidades necesarias como equipo para crear un
Incremento de un producto;

Los miembros del Equipo de Desarrollo no tienen otro tı́tulo que el de Desarrollador
(Developer), sin importar el trabajo realizado por la persona;

No hay subequipos en el Equipo de Desarrollo, sin importar de los dominios particulares

que son necesarios; y,

los miembros individuales del Equipo de Desarrollo pueden tener habilidades especializa-
das y áreas de enfoque, pero la responsabilidad pertenece al Equipo de Desarrollo como
un conjunto.

3.2.1. Tamaño del Equipo de Desarrollo

El tamaño óptimo del Equipo de Desarrollo debe ser lo suficiente pequeño para mantenerse
ágil y lo suficiente grande para completar una porción significante del trabajo en un Sprint.
Menos de tres miembros reducen la interacción, lo que resulta en un decrecimiento de la pro-
ducción. Equipos más pequeños pueden encontrar limitaciones durante el Sprint, causando que
no se pueda entregar un Incremento a tiempo. Tener más que nueve miembros requiere mucha
coordinación. Equipos de Desarrollo grandes generan mas complejidad de la que un proceso
empı́rico puede manejar. El Propietario del Producto y el Scrum Master no forman parte de
esta cuenta a menos que también ejecuten el trabajo del Backlog.

3
3.3. El Maestro de Scrum (Scrum Master)
El Scrum Master es el responsable de asegurar que Scrum sea entendido y puesto en práctica.
Los Maestros de Scrum hacen esto asegurando que el Equipo de Scrum se adhiera a la teorá
de Scrum, sus prácticas y sus reglas.

El Scrum Master es un sirviente-lı́der para el Equipo de Scrum. El Maestro ayuda a aquellos

por fuera del Equipo de Scrum a entender cuál de sus interacciones con el Equipo son benefi-
ciosas y cuáles no. El Maestro ayuda a todos a cambiar esas interacciones para maximizar el
valor creado por el Equipo de Scrum.

3.3.1. Servicios del Scrum Master al Propietario del Producto

El Scrum Master ayuda al Propietario del Producto en diversas formas, incluyendo:
Encontrando técnicas para efectivas para la administración del Backlog;
Ayudando al Equipo de Scrum a entender la necesidad de ı́tems claros y concisos para el
Backlog;
Comprendiendo el Planificación del producto en un ambiente empı́rico;
Asegurando que el Propietario del Producto conozca cómo organizar el Backlog para
maximizar el valor;
Comprendiendo y practicando la agilidad, y;
Facilitando los eventos de Scrum tal como sea necesario o requerido.

3.3.2. Servicios del Scrum Master al Equipo Desarrollador

El Scrum Master ayuda al Equipo Desarrollador en diversas formas, incluyendo;
Guiando el Equipo de Desarrollo en la autoorganización y en la multifuncionalidad;
Ayudando al Equipo de Desarrollo a crear productos de alto valor;
Removiendo impedimentos al progreso del Equipo de Desarrollo;
Facilitando los eventos de Scrum tal como sea necesario o requerido; y,
Guiando al Equipo de Desarrollo en los ambientes en los cuales Scrum no se encuentra
todavı́a completamente adoptado y comprendido.

3.3.3. Servicios del Scrum Master a la organización

El Scrum Master ayuda a la organización en diversas formas, incluyendo:
Dirigiendo y Guiando la organización hacia la adopción de Scrum;
Planeando implementaciones de Scrum dentro de la organización;
Ayudando a que los empleados y los stakeholders3 comprendan y pongan en práctica
Scrum y el desarrollo de producción empı́rico;
3
Un stakeholder hace referencia a una persona, organización o empresa que tiene interés el proyecto de
desarrollo. Las partes interesadas podrı́an ser los trabajadores de esa organización, sus accionistas, los clientes,
los proveedores de bienes y servicios, proveedores de capital, las asociaciones de vecinos afectadas o ligadas, los
sindicatos, las organizaciones civiles y gubernamentales que se encuentren vinculadas, etc.

4
 Generando cambios que incrementen la productividad del Equipo de Scrum: y,

Trabajando con otros Scrum Masters para incrementar la efectividad de la aplicación de

Scrum en la organización.

4. Eventos de Scrum
Los eventos son utilizados en Scrum para crear regularidad y para minimizar la necesidad
de reuniones no definidas en Scrum. Todos los eventos son eventos que se prolongan durante el
tiempo, y cada uno tiene una duración máxima. Una vez que comienza un Sprint, su duración
es fijada y esta no puede ser acortada o alargada. Los eventos remanentes pueden terminar
cuando el propósito del evento se cumpla, asegurando que una cantidad apropiada de tiempo
es empleada, sin permitir malgaste de tiempo en el proceso.

Además del Sprint mismo, el cual contiene el resto de los eventos, cada evento en Scrum es una
oportunidad para inspeccionar y adaptar algo. Estos eventos están especı́ficamente diseñados
para permitir transparencia e inspecciones. No poder incluir alguno de estos eventos resultará
en una reducción de transparencia y es una oportunidad perdida para inspeccionar y adaptar.

4.1. El Sprint
El corazón de Scrum es el Sprint, un marco de tiempo de un mes o menos durante el cual
se crea un Incremento del producto ”Terminado”, funcional, y potencialmente entregable. Lo
mejor es que los Sprints tengan duraciones consistentes a lo largo del desarrollo. Un nuevo
Sprint comienza tras la conclusión del Sprint previo.

Un Sprint contiene y consiste del Planificación del Sprint, el Scrum Diario, el trabajo de
desarrollo, la Revisión del Sprint, y la Retrospectiva del Sprint.

Durante el Sprint:

No se harán cambios que pongan en peligro el Objetivo del Sprint (Sprint Goal);

La calidad de los objetivos no decrecerá; y,

El fı́n del Sprint puede ser clarificado y renegociado entre el Propietario del Producto y
el Equipo de Desarrollo al agregarse nuevos conocimientos.

Cada Sprint puede ser considerado como un proyecto con no más de un mes de horizonte.
Como con un proyecto, los Sprints son utilizados para lograr algo. Cada Sprint tiene una
definición de lo que va a ser construido, un diseño, y un plan flexible que guiará su construcción,
el trabajo, y el producto resultante.

Los Sprints tienen un lı́mite de un mes de duración. Cuando el horizonte de un Sprint es muy
largo, la definición de lo que está siendo construido puede cambiar, la complejidad puede subir,
y los riesgos pueden incrementar. Los Sprints habilitan la posibilidad de predicción al asegurar
la inspección y la adaptación del progreso hacia el Objetivo del Sprint al menos una vez por
més.

5
4.1.1. Calcelar un Sprint
Un Sprint puede ser cancelado antes de que su tiempo de duración termine. Solo el Dueño
del Producto tiene la autoridad para cancelar el Sprint, aunque él o ella podrı́a hacerlo bajo la
influencia de los stakeholders, el Equipo de Desarrollo, o el Scrum Master.

Un Sprint serı́a cancelado si el Objetivo del Sprint se volviera obsoleto. Esto puede ocurrir
si la compañia cambia su orientación, o si el mercado o las condiciones tecnológicas cambian.
En general, un Sprint debe ser cancelado si ya no tiene sentido dadas las circunstancias. Pero
dada la corta duración de los Sprints, la cancelación rara vez tiene sentido.

Cuando un Sprint es cancelado, cualquier producto ”Terminado” presente en el Backlog como

un ı́tem es revisado. Si parte del trabajo es entregable, el Propietario del Producto generalmente
lo acepta. Todos los ı́tems del Backlog sin terminar son reestimados y reinsertados en el Backlog
del Producto. El trabajo hecho en ellos pierde valor rápidamente y con frecuencia debe ser
reestimado.

La cancelación de un sprint consume recursos, ya que todos tienen que reagruparse en una
Planificación de Sprint nueva para poder comenzar otro Sprint. Las cancelaciones de Sprints
son con frecuencia traumáticas para el Equipo de Scrum, y son muy raras.

4.2. Planificación del Sprint

El trabajo a ser realizado en el Sprint es planificado durante la Planificación del Sprint. Este
plan es creado por el trabajo conjunto de todo el Equipo de Scrum.

La Planificación del Sprint tiene una duración máxima de ocho horas para un Sprint de un
mes. Para Sprints más cortos, el evento es usualmente más corto. El Scrum Master asegura
que el evento tome lugar y que los participantes comprendan su propósito. El Scrum Master le
enseña al Equipo de Scrum como mantenerse dentro del margen de tiempo.

La Planificación del Sprint responde las siguientes preguntas:

¿Qué puede ser entregado en el Incremento resultante del próximo Sprint?

¿Como será alcanzado el trabajo necesario para entregar el Incremento?

4.2.1. Tema Uno: ¿Que puede ser hecho en este Sprint?

El Equipo Desarrollador trabaja para pronosticar la funcionalidad que será desarrollada
durante el Sprint. El Propietario del Proyecto discute el objetivo que el Sprint deberá alcanzar
y los ı́tems del Backlog del Producto que, de ser completados en el Sprint, lograrı́an el Objetivo
del Sprint. Todo el Equipo de Scrum colabora para comprender el trabajo del Sprint.

Los datos a utilizar en estas reuniones son el Backlog del Producto, el último incremento
del producto, la capacidad proyectada por el Equipo Desarrollador durante el Sprint, y el
rendimiento pasado del Equipo Desarrollador. El número de ı́tems seleccionados del Backlog
del Producto para el Sprint es decido completamente por el Equipo Desarrollador.

6
 Luego de que el Equipo Desarrollador pronostica los items del Backlog que entregará en el
Sprint, el Equipo de Scrum arma un Objetivo del Sprint. Este es un objetivo que será alcanzado
dentro del Sprint a través de la implementación del Backlog del Producto, y provee una guı́a
para el Equipo Desarrollador sobre la finalidad del Incremento.

4.2.2. Tema Dos: ¿Como se logrará el trabajo elegido?

Habiendo declarado el Objetivo del Sprint, y seleccionado los ı́tems del Backlog del Producto
para el Sprint, el Equipo Desarrollador decido como va a construir esta funcionalidad para
que esta se convierta en un Incremento del producto ”Terminado”. Los ı́tems seleccionados del
Backlog del Producto para el Sprint, además del plan para entregarlos se llama Backlog del
Sprint.

Para el final de la Planificación del Sprint, el Equipo Desarrollador deberı́a ser capaz de
explicar al Propietario del Producto y al Scrum Master como planea trabajar para cumplir el
Objetivo del Sprint y crear el Incremento.

4.2.3. Objetivo del Sprint

El Objetivo del Sprint es un fin que se le da al Sprint que puede ser cumplido durante la
implementacion del Backlog del Producto. Provee una guı́a para el Equipo Desarrollador sobre
por qué está construyendo el Incremento. Este es creado durante la Planificación del Sprint. El
Objetivo del Sprint le da al Equipo Desarrollador flexibilidad en cuanto a la funcionalidad a
implementar en el Sprint. Los ı́tems del Backlog del Producto entregan una función coherente,
que puede ser el Objetivo del Sprint.

Mientras el Equipo Desarrollador trabaja, debe mantener el Objetivo en mente. Si el trabajo

resulta ser diferente de lo que el Equipo Desarrollador esperaba, colaborarán con el Propietario
del Producto para negociar la envergadura del Backlog del Sprint dentro del Sprint.

4.3. Scrum Diario

El Scrum Diario es un evento de quince minutos de duración para que el Equipo Desarrollador
sincronice las actividades y cree un plan para las próximas 24 horas. Esto es hecho mediante la
inspeccion del trabajo desde el último Scrum Diario y pronosticando el trabajo que puede ser
hecho antes del próximo.

El Scrum Diario se lleva a cabo siempre a la misma hora y en el mismo lugar para reducir la
complejidad. Durante la reunión, los miembros Equipo Desarrollador explican:

¿Que hice yo ayer que ayudo al Equipo Desarrollador a cumplir con el Objetivo del Sprint?

¿Que voy a hacer hoy para ayudar al Equipo Desarrollador para cumplir con el Objetivo
del Sprint?

¿Veo algún impedimento que me impida a mı́ o al Equipo Desarrollador cumlir con el
Objetivo del Sprint?

7
 También puede darse el caso de que la reunión sea llevada a cabo al final del Scrum Diario.
En este caso, las preguntas serı́an las siguientes:

¿Que hice yo hoy que ayudo al Equipo Desarrollador a cumplir con el Objetivo del Sprint?

¿Que voy a hacer mañana para ayudar al Equipo Desarrollador para cumplir con el
Objetivo del Sprint?

¿Veo algún impedimento que me impida a mı́ o al Equipo Desarrollador cumlir con el
Objetivo del Sprint?

El Scrum Master debe asegurar que el Equipo Desarrollador tenga la reunión, pero el Equipo
Desarrollador es responsable de conducir el Scrum Diario. El Scrum Master le enseña al Equipo
Desarrollador a mantener el Scrum Diario dentro del Margen de los quince minutos. Además,
deberá hacer cumplir la regla de que solo el Equipo Desarrollador participe en el Scrum Diario.

El Scrum Diario mejora la comunicación, elimina otras reuniones, identifica impedimentos al

desarrollo que serán removidos, remarca y promueve la toma rápida de decisiones, y mejora el
nivel de conocimiento del Equipo Desarrollador.

4.4. Revisión del Sprint

La Revisión del Sprint tiene lugar al fin del Sprint para inspeccionar el Incremento y adaptar
el Backlog del Producto si es necesario. Durante la Revisión del Sprint, el Equipo de Scrum y
los stakeholders colaboran sobre que fue hecho durante el Sprint. Basándose en eso, y en los
cambios hechos al Backlog del Producto durante el Sprint, se discuten las cosas que pueden ser
hechas para optimizar el valor.

Esta reunión tiene una duración de cuatro horas para un Sprint de un mes. Para Sprints más
cortos, el evento es usualmente más cortos. El Scrum Master asegura que el evento tome luga
y que sus participantes comprendan su propósito. El Scrum Master le debe enseñar a todos a
mantenerse dentro del tiempo previsto.

La Revisión del Sprint incluye los siguientes elementos:

El Propietario del Producto explica que ı́tems del Backlog fueron ”terminados” y cuales
no;

El Equipo Desarrollador discute que funcionó durante el Sprint, y con qué problemas se
encontró, y como estos fueron resueltos;

El Equipo Desarrollador demuestra que el trabajo fué ”terminado”, y responde preguntas

sobre el incremento;

Todo el grupo discute sobre qué hacer luego, para que la Revisión del Sprint provea
información valiosa para subsecuentes Planificaciónes de Sprint; y,

Se revisa el cronograma, el presupuesto, capacidades potenciales, y mercados para la

próxima entrega del producto.

El resultado de la Revisión del Sprint es un Backlog del Producto revisado que define ı́tems
probables para el próximo Sprint.

8
4.5. Retrospectiva del Sprint
La Retrospectiva del Sprint es una oportunidad para que el Equipo de Scrum se inspeccione
a si mismo y cree un plan de mejoras que serán puestas en práctica durante el próximo Sprint.

La Retrospectiva del Sprint ocurre tras la Revisión y antes de la próxima planificación del
Sprint.Esta reunión tiene un tiempo de duración de tres horas para un Sprint de un mes.
El Scrum Master asegura que el evento tome lugar y que los participantes comprendan su
propósito. El Scrum Master les enseña a todos a mantenerse dentro del margen de tiempo.

El propósito de la Retrospectiva del Sprint es:

Inspeccionar como funcionó el último Sprint en cuanto a la gente, relaciones, procesos y

herramientas;

Identificar y ordenar los ı́tems principales que funcionaron bien y buscar mejoras poten-
ciales; y,

Crear un plan para implementar mejoras sobre la forma en la que el Equipo de Scrum
hace su trabajo.

Al fin de una Retrospectiva del Sprint, el Equipo debe haber identificado mejores que se
implementaran en el Próximo Sprint. Aunque las mejoras pueden ser implementadas en cual-
quier momento, la Retrospectiva del Sprint provee una oportunidad formal para enfocarse en
la inspección y adaptación.

5. Artefactos de Scrum
Los artefactos de Scrum representan trabajos o valores para proveer transparencia y opor-
tunidades para inspección y adaptación. Los Artefactos definidos por Scrum están diseñados
especı́ficamente para maximizar la transparencia de la información crucial para que todos ten-
gan la misma comprensión del artefacto.

5.1. Backlog del Producto

El Backlog del Producto es una lista ordenada de todo lo que serı́a necesario en el producto
y es la única fuente de requerimientos para que cualquier cambio se haga al producto. El
Propietario del Producto es el responsable del Backlog del Producto, incluyendo su contenido,
disponibilidad y orden.

El Backlog del Producto nunca es terminado. El desarrollo más temprano de este solo pre-
senta los requerimientos iniciales y mejor conocidos. Este evoluciona junto con el producto y
el ambiente en el cual será utilizado. Mientras que el producto exista, el Backlog de este existe
por igual.

El Backlog del Producto lista todas las caracterı́sticas, funciones, requerimientos, mejoras, y
arreglos que constituyen los cambios a ser hechos al producto en próximas entregas.

9
 El refinamiento del Backlog del Producto es el acto de agregar detalles, estimados, y orden
a los ı́tems del Backlog del Producto. Este es un proceso en el cual el Propietario del Producto
y el Equipo de Desarrollo colaboran en el detallado del Backlog del Producto. El Equipo de
Scrum decide cómo y cuando se realiza el refinamiento.

Los ı́tems en lugares principales en el Backlog del Producto son usualmente más claros y más
detallados que los demás; mientras más se baja, menos es el detalle.

5.2. Backlog del Sprint

El Backlog del Sprint es un grupo de ı́tems seleccionados para el Sprint, además de un
plan para entregar el Incremento y completar el Objetivo del Sprint. El Backlog del Sprint
un pronóstico llevado a cabo por el Equipo de Desarrollo sobre qué será llevado a cabo en el
próximo Incremento y el trabajo necesario para entregar ese Incremento ”Terminado”.

Cuando se requiere nuevo trabajo, el Equipo Desarrollador lo agrega al Backlog del Sprint.
Cuando se realiza trabajo, se actualiza el tiempo estimado para el trabajo restante. Cuando se
considera que elementos del Backlog del Producto son innecesarios, estos son removidos. Solo
el Equipo Desarrollador puede modificar el Backlog del Sprint.

5.3. Incremento
El Incremento es la suma de todos los ı́tems del Backlog del Producto completados durante
el Sprint y el valor del incremento de todos los Sprints previos. Al final de un Sprint, el nuevo
Incremento debe estar ”Terminado”, y esto independientemente de la decisión del Propietario
del Producto de lanzarlo o no.

6. Definición de ”Terminado”
Cuando un ı́tem del Backlog del Producto o un Incremento es descrito como ”Terminado”,
todos deben entender lo que ”Terminado” significa. Aunque esto varı́a significativamente para
cada Equipo de Scrum, los miembros deben tener un entendimiento compartido de lo que hace
falta para que un trabajo esté completo, para asegurar la transparencia.

Los Equipos Desarrolladores entregan un Incremento cada Sprint. Este Incremento es usable,
por lo que el Propietario del Producto puede lanzarlo de inmediato.

Junto con la maduración de un Equipo de Scrum, se espera que la definición de ”Terminado”

se expanda para incluir criterios más rigurosos para lograr una mayor calidad.

10
7. Grafico de Ciclo de trabajo
El conjunto total de producción bajo el framework de scrum se podrı́a graficar de la forma
siguiente:

11
Parte II
Metodologı́a en V
8. Introducción
La metodologı́a de desarrollo en v, o modelo en v, es utilizada en gran parte para proyectos
pequeños que abarcan de 1 a 5 personas en el equipo. Posee una curva de aprendizaje no muy
elevada, y se dedica a la planificación de desarrollos generalmente informales.

Consiste en un modelo que podrı́a representarse en dos lı́neas, que se unen en el final, armando
un esquema de V. En el vértice final, se representa la corriente del desarrollo.

Es confiable porque ofrece la posibilidad de probar cada una de las implementaciones nuevas
luego de su completado; a cada fase de desarrollo, corresponde una verificación.

9. Niveles

Este modelo está compuesto por 4 niveles que componen el esquema usado de guia; consis-
te,básicamente en:

12
9.1. Nivel 1
Orientado al relevamiento de datos del cliente; se encuentran los requerimientos que va a
tener el sistema, se desarrollan los conceptos que van a estar dentro del contexto del programa.
Este nivel es el que va a contener el principio y el final.

El final, es un test de que el programa cumpla todos los requisitos relevados.

9.2. Nivel 2 ”Fase funcional”

Se abstraen los conceptos relevados en el nivel uno en funciones o servicios; se entiende y
declara la visibilidad sobre los valores y métodos que va a tener el programa en interfaz con el
usuario y con programas con los que se relacione. Se realiza una versión preliminar que sirve
como boceto de nuestro sistema.

En el lado derecho, nos encontramos con una fase de prueba de cada uno de los servicios, en
el que se verificarán valores devueltos y operaciones correctas sobre datos.

9.3. Nivel 3 ”Fase diseño”

Define la arquitectura del sistema requerida, y se prueba en distintas plataformas para veri-
ficar funcionamiento. Se realiza un diseño detallado del sistema y un plan de integración. Del
lado derecho estan las pruebas de esta integración del diseño.

9.4. Nivel 4 ”Implemmentación”

Desarrollo de los elementos unitarios, también llamados módulos del programa. Consiste en
la codificación pura de cada una de las partes del programa.

10. Fases del Desarrollo

En cada una de los niveles, podremos ir probando lo que tenemos hecho a través de modelos,
lotes de prueba, datos de ejemplo, etc. Esto nos permite realizar de una forma bastante flexible
el desarrollo, ya que mientras estamos en cualquiera de los niveles, podremos volver atrás, y
cambiar determinadas partes, requeridas por el cliente, seguramente, mientras se trabaja.

Los niveles 1 y 2 tienen una pequeña dificultad comparado a realizar un cambio en los 2
niveles posteriores, ya que requieren el remodelado del diseño, y la refactorizacion de codigo,
lo cual lleva trabajo extra.

Mientras un equipo trabaja en el lado izquierdo del modelo, otro equipo puede ocuparse de
desarrollar los lotes de prueba para el lado derecho, el testing de la interfaz de usuario, codificar
o probar el diseño.

Es requerı́a una gran cantidad de iteraciones en el desarrollo, pero a diferencia del modelo
de cascada clasico, pero cada iteración no es necesario que abarque todas los niveles.

13
11. Objetivos propuestos por el sistema
Regular el proceso de desarrollo;
Minimización de los riesgos del proyecto;
Mejorar y garantizar la calidad del proyecto;
Reducción de los gastos totales durante el proyecto; y,
Mejorar la comunicación entre los clientes y el equipo.

12. Ventajas
Es uno de las metodologı́as más rápidas y baratas que hay disponibles. Se puede utilizar
en desarrollos con equipos que no tengan experiencia en ninguna metodologı́a de desarrollo.
Es facil de aprender y hay documentación suficiente para entregar al equipo y comenzar a
implementarla rápidamente. También provee de una etapa paralela que puede estar probando
lo implementado, lo cual da una seguridad constante de que todo está funcionando como debe
(poca probabilidad de no saber donde hay un fallo).

Se involucra al usuario en las pruebas, que se realizan segun el rol que tendrá cada uno de
ellos en el uso.

13. Desventajas
Cada fase tiene que estar respaldada por su documento correspondiente y test, se habla de
una amplia documentación, debes realizar dos procesos al mismo tiempo, es difı́cil que el cliente
exponga explı́citamente todos los requisitos, el cliente debe tener paciencia pues obtendrá el
producto al final del ciclo de vida, las pruebas pueden ser caras y, a veces, no lo suficientemente
efectivas, el producto final obtenido puede que no refleje todos los requisitos del usuario.

14. Caracterı́sticas de los modelos de desarrollo evoluti-

vo clásicos
El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse
se va refinando de acuerdo a los comentarios o nuevos requerimientos por parte del cliente
o usuario final. Se entrelazan las etapas de especificación, desarrollo y validación en vez de
separarse.

Tenemos dos tipos de desarrollo evolutivo:

desarrollo exploratorio: Se trabaja a par con el cliente para explorar todos los requerimien-
tos y entregar un sistema final. Se comienza con las partes del sistema que se comprenden
mejor, y luego evoluciona implementando todos los nuevos atributos aportados y pro-
puestos por el cliente.
Prototipos desechables: El objetivo del proceso evolutivo de este tipo es comprender todos
los requerimientos y entonces desarrollar una definición mejorada de los requerimientos
para el sistema. El prototipo se propone experimentar con los requerimientos del cliente
que no se comprenden completamente.

14
 Para implementar modelo en V, podemos utilizar cualquiera de los dos encares. El
segundo conlleva un trabajo de prueba y error, y prototipos compilados más seguido. El
primero, lleva más tiempo en realizar una entrega, pero deberia comprender, teóricamente,
los requisitos pedidos al pelo.

Se utiliza una metodologı́a similar a un espiral; cada una de las iteraciones que se
realizan en el desarrollo va a evolucionar de la anterior, y si no se cumplen los requisitos
pedidos, no se va a avanzar hasta hacer que todo funcione correctamente.

15
Índice

I Metodologı́a Scrum 1
1. Introducción 1

2. Teorı́a de Scrum 1
2.1. Transparencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2. Inspección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.3. Adaptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3. El Equipo de Scrum 2
3.1. El Propietario del Producto (Product Owner) . . . . . . . . . . . . . . . . . . . 2
3.2. El Equipo de Desarrollo (Development Team) . . . . . . . . . . . . . . . . . . . 3
3.2.1. Tamaño del Equipo de Desarrollo . . . . . . . . . . . . . . . . . . . . . . 3
3.3. El Maestro de Scrum (Scrum Master) . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3.1. Servicios del Scrum Master al Propietario del Producto . . . . . . . . . . 4
3.3.2. Servicios del Scrum Master al Equipo Desarrollador . . . . . . . . . . . . 4
3.3.3. Servicios del Scrum Master a la organización . . . . . . . . . . . . . . . . 4

4. Eventos de Scrum 5
4.1. El Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Calcelar un Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Planificación del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Tema Uno: ¿Que puede ser hecho en este Sprint? . . . . . . . . . . . . . 6
4.2.2. Tema Dos: ¿Como se logrará el trabajo elegido? . . . . . . . . . . . . . . 7
4.2.3. Objetivo del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Scrum Diario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Revisión del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Retrospectiva del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5. Artefactos de Scrum 9
5.1. Backlog del Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Backlog del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Incremento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6. Definición de ”Terminado” 10

7. Grafico de Ciclo de trabajo 11

II Metodologı́a en V 12
8. Introducción 12

9. Niveles 12
9.1. Nivel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Nivel 2 ”Fase funcional” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.3. Nivel 3 ”Fase diseño” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.4. Nivel 4 ”Implemmentación” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

16
10.Fases del Desarrollo 13

11.Objetivos propuestos por el sistema 14

12.Ventajas 14

13.Desventajas 14

14.Caracterı́sticas de los modelos de desarrollo evolutivo clásicos 14

17