You are on page 1of 23

1

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

Ao de la Diversificacin Productiva y del


Fortalecimiento de la Educacin

Modelo SCRUM

Integrantes:

Catedrtico:

Catedra:

Ayra Villanueva cristian

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

Dedicatoria :

Quiero dedicarle este trabajo A Dios

que me ha dado la vida y fortaleza


para terminar este proyecto de investigacin,
A mis Padres por estar ah cuando ms los
necesitaba especial a mi madre por su ayuda y
...constante cooperacin en los momentos ms
difciles.

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

CONTENIDO

Caratula2
Dedicatoria.3
Contenido ..4
Introduccin..5
Historia..6
7
Capitulo i ..8
Caracterstica del problema
Formulacin del problema
Objetivos

Capitulo ii .13
Teora cientfica
Base conceptuales
Capitulo iii ..15
Conclusiones
anexos
bibliografa

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

INTRODUCCIN
Scrum es un marco de trabajo en el que equipos cross-funcionales pueden crear productos
o desarrollar proyectos de una forma iterativa e incremental. El desarrollo se estructura en
ciclos de trabajo llamados Sprints (tambin conocidos como iteraciones). Estas iteraciones
no deben durar ms de cuatro semanas cada una (siendo dos semanas la duracin ms
habitual) y tienen lugar una tras otra sin pausa entre ellas. Los Sprints estn acotados en el
tiempo finalizan en una fecha determinada independientemente de si el trabajo ha
finalizado por completo o no, y jams se prorrogan. Normalmente los equipos Scrum
escogen una duracin de Sprint y la mantienen para todos sus Sprints hasta que mejoran
y pueden emplear ciclos ms cortos. Al principio de cada Sprint, un Equipo cross-funcional
(de en torno a siete personas) selecciona elementos (peticiones del cliente) de una lista
priorizada. El equipo acuerda un objetivo colectivo respecto a lo que creen que podrn
entregar al final del Sprint, algo que sea tangible y que estar terminado por completo.
Durante el Sprint no se podrn aadir nuevos elementos; Scrum se adapta a los cambios
en el siguiente Sprint, pero el pequeo Sprint actual est pensado para concentrarnos en
un objetivo pequeo, claro y relativamente estable. Todos los das el Equipo se rene
brevemente para inspeccionar su progreso y ajustar los siguientes pasos necesarios para
completar el trabajo pendiente. Al final del Sprint, el Equipo revisa el Sprint con los
diferentes Stakeholders (interesados e involucrados en el producto) y realiza una
demostracin de lo que han desarrollado. Se obtiene feedback que podr ser incorporado
en el siguiente Sprint. Scrum enfatiza un producto funcionando al final del Sprint que est
realmente terminado. En el caso del software, esto significa un sistema que est integrado,
testado, con la documentacin de usuario generada y potencialmente entregable.

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

HISTORIA
El concepto de Scrum tiene su origen en un estudio de 1986 sobre los nuevos procesos de
desarrollo utilizados en productos exitosos en Japn y los Estados Unidos (cmaras de
fotos de Canon, fotocopiadoras de Xerox, automviles de Honda, ordenadores de HP y
otros). Los equipos que desarrollaron estos productos partan de requisitos muy generales,
as como novedosos, y deban salir al mercado en mucho menos del tiempo del que se
tard en lanzar productos anteriores. Estos equipos seguan patrones de ejecucin de
proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos
altamente productivos y multidisciplinares con la colaboracin entre los jugadores de Rugby
y su formacin de Scrum (mel en espaol).
Scrum es una metodologa gil de desarrollo de proyectos que toma su nombre y principios
de los estudios realizados sobre nuevas prcticas de produccin por Hirotaka Takeuchi e
Ikujijo Nonaka a mediados de los 80. (V. Navegapolis: El nuevo escenario). Aunque surgi
como modelo para el desarrollo de productos tecnolgicos, tambin se emplea en entornos
que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones
frecuentes en el desarrollo de determinados sistemas de software. Jeff Sutherland aplic el
modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los
macro-juegos de compras y fusiones se integrara en VMARK, luego en Informix y
finalmente en Ascential Software Corporation). Desde 1995 miles de proyectos en todo el
mundo han utilizado Scrum para el desarrollo de productos, tanto en empresas pequeas,
startups con tan slo 3 personas desarrollando un producto, como en multinacionales,
entre las que se encuentran las siguientes:

Sectores

Media
Telcos

Software,
Hardware

Ejemplos de empresas que utilizan metodologas giles como


Scrum

BBC, BellSouth, British Telecom, DoubleYou, Motorola, Nokia,


Palm, Qualcomm, Schibsted, Sony/Ericsson, Telefonica I+D,
TeleAtlas, Verizon

Adobe, Autentia, Biko2, Central Desktop, Citrix, Gailn, IBM, Intel,


Microfocus, Microsoft, Novell, OpenView Labs, Plain Concepts,
Primavera, Proyectalis, Softhouse, Valtech, VersionOne.

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

Internet

Amazon, Google, mySpace, Yahoo

ERP

SAP

Banca
Inversin

Bank of America, Barclays Global Investors, Key Bank, Merrill


Lynch

Sanidad
Salud

Patientkeeper, Philips Medical

Defensa
y
Aeroespacial

Boeing, General Dynamics, Lockheed Martin

Juegos

Blizzard, High Moon Studios, Crytek, Ubisoft, Electronic Arts

Otros

3M, Bose, GE, UOC, Ferrari

En 1996 lo present junto con Ken Schwaber como proceso formal, tambin para gestin
del desarrollo de software en OOPSLA 96. Ms tarde, en 2001 seran dos de los
promulgadores del Manifiesto_gil. En el desarrollo de software scrum est considerado
como modelo gil por la Agile Alliance.
En la actualidad, Scrum se est utilizando en diferentes tipos de negocio y, especialmente,
en el desarrollo de software. La Scrum Alliance es la organizacin sin nimo de lucro que
se encarga de difundir Scrum en este mbito

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

TEORIA DE SCRUM
Scrum es una metodologa de desarrollo muy simple, que requiere trabajo duro porque no
se basa en el seguimiento de un plan, sino en la adaptacin continua a las circunstancias
de la evolucin del proyecto. Scrum es una metodologa gil, y como tal:
Es un modo de desarrollo de carcter adaptable ms que predictivo.
Orientado a las personas ms que a los procesos.
Emplea la estructura de desarrollo gil: incremental basada en iteraciones y
revisiones.

Se comienza con la visin general del


producto, especificando y dando detalle a las
funcionalidades o partes que tienen mayor
prioridad de desarrollo y que pueden llevarse
a cabo en un periodo de tiempo breve
(normalmente de 30 das). Cada uno de estos
periodos de desarrollo es una iteracin que
finaliza con la produccin de un incremento
operativo del producto. Estas iteraciones son
la base del desarrollo gil, y Scrum gestiona
su evolucin a travs de reuniones breves
diarias en las que todo el equipo revisa el
trabajo realizado el da anterior y el previsto
para el da siguiente.

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

CONTROL DE LA EVOLUCION DEL PROYECTO


Scrum controla de forma emprica y adaptable la evolucin del proyecto, empleando las
siguientes prcticas de la gestin gil:

Revisin de las Iteraciones


Al finalizar cada iteracin (normalmente 30 das) se lleva a cabo una revisin con todas las
personas implicadas en el proyecto. Este es el periodo mximo que se tarda en reconducir
una desviacin en el proyecto o en las circunstancias del producto

Desarrollo incremental
Durante el proyecto, las personas implicadas no trabajan con diseos o abstracciones. El
desarrollo incremental implica que al final de cada iteracin se dispone de una parte del
producto operativa que se puede inspeccionar y evaluar.

Desarrollo evolutivo
Los modelos de gestin gil se emplean para trabajar en entornos de incertidumbre e
inestabilidad de requisitos. Intentar predecir en las fases iniciales cmo ser el producto
final, y sobre dicha prediccin desarrollar el diseo y la arquitectura del producto no es
realista, porque las circunstancias obligarn a remodelarlo muchas veces. Para qu
predecir los estados finales de la arquitectura o del diseo si van a estar cambiando. En
Scrum se toma a la inestabilidad como una premisa, y se adoptan tcnicas de trabajo para
permitir esa evolucin sin degradar la calidad de la arquitectura que se ir generando
durante el desarrollo. El desarrollo Scrum va generando el diseo y la arquitectura final de
forma evolutiva durante todo el proyecto. No los considera como productos que deban
realizarse en la primera fase del proyecto. (El desarrollo gil no es un desarrollo en fases)

Auto-organizacin
Durante el desarrollo de un proyecto son muchos los factores impredecibles que surgen en
todas las reas y niveles. La gestin predictiva confa la responsabilidad de su resolucin
al gestor de
Proyectos. En Scrum los equipos son auto-organizados (no auto-dirigidos), con margen de
decisin suficiente para tomar las decisiones que consideren oportunas.

Colaboracin
Las prcticas y el entorno de trabajo giles facilitan la colaboracin del equipo. sta es
necesaria, porque para que funcione la autoorganizacin como un control eficaz cada
miembro del equipo debe colaborar de forma abierta con los dems, segn sus capacidades
y no segn su rol o su puesto.

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

10

Eventos de Scrum
En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la
necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo
(time-boxes), de tal modo que todos tienen una duracin mxima. Una vez que comienza
un Sprint, su duracin es fija y no puede acortarse o alargarse. Los dems 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.
Adems del propio Sprint, que es un contenedor del resto de eventos, cada uno de los
eventos de Scrum constituye una oportunidad formal para la inspeccin y adaptacin de
algn aspecto. Estos eventos estn diseados especficamente para habilitar las vitales
transparencia e inspeccin. La falta de alguno de estos eventos da como resultado una
reduccin de la transparencia y constituye una oportunidad perdida para inspeccionar y
adaptarse.

A).-El Sprint
El corazn 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 ms conveniente si la duracin de los Sprints es consistente a lo largo del
esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente despus de la
finalizacin del Sprint previo.
Los Sprints contienen y consisten de la Reunin de Planificacin del Sprint (Sprint Planning
Meeting), los Scrums Diarios (Daily Scrums), el trabajo de desarrollo, la Revisin del Sprint
(Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective).
Durante el Sprint:
No se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint Goal);

Los objetivos de calidad no disminuyen; y,

El alcance puede ser clarificado y renegociado entre el Dueo de Producto y el


Equipo de Desarrollo a medida que se va aprendiendo ms.

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 definicin de
qu se va a construir, un diseo y un plan flexible que guiar la construccin y el trabajo y
el producto resultante.
Los Sprints estn limitados a un mes calendario. Cuando el horizonte de un Sprint es
demasiado grande la definicin de lo que se est construyendo podra cambiar, la
complejidad podra elevarse y el riesgo podra aumentar. Los Sprints habilitan la
predictibilidad al asegurar la inspeccin y adaptacin del progreso al menos en cada mes
calendario. Los Sprints tambin limitan el riesgo al costo de un mes calendario.

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

11

B).- Reunin de Planificacin de Sprint (Sprint Planning Meeting)


El trabajo a realizar durante el Sprint se planifica en la Reunin de Planificacin de Sprint.
Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.
La Reunin de Planificacin de Sprint tiene un mximo de duracin de ocho horas para un
Sprint de un mes. Para Sprints ms cortos, el evento es usualmente ms corto. El Scrum
Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su
propsito. El Scrum Master ensea al Equipo Scrum a mantenerse dentro del bloque de
tiempo.
La Reunin de Planificacin de Sprint responde a las siguientes preguntas:
Qu puede entregarse en el Incremento resultante del Sprint que comienza?

Cmo se conseguir hacer el trabajo necesario para entregar el Incremento?

Los elementos que conforman el desarrollo Scrum son:

Las reuniones

Planificacin de sprint: Jornada de trabajo previa al inicio de cada sprint en la que


se determina cul va a ser el trabajo y los objetivos que se deben cumplir en esa
iteracin.
Reunin diaria: Breve revisin del equipo del trabajo realizado hasta la fecha y la
previsin para el da siguiente.

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

12

C).-Objetivo del Sprint (Sprint Goal)


El Objetivo del Sprint es una meta establecida para el Sprint que puede ser
alcanzada mediante la implementacin de la Lista de Producto. Proporciona una
gua al Equipo de Desarrollo acerca de por qu est construyendo el incremento.
Es creado durante la reunin de Planificacin 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 funcin coherente, que puede ser el objetivo del Sprint. El objetivo del
Sprint puede representar otro nexo de unin 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 tecnologa. Si el trabajo resulta ser diferente de lo que el Equipo de Desarrollo
espera, ellos colaboran con el Dueo del Producto para negociar el alcance de la
Lista de pendientes del Sprint (Sprint Backlog).
Revisin de sprint: Anlisis y revisin del incremento generado.

D).- Scrum Diario (Daily Scrum)


El Scrum Diario es una reunin 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 proyeccin acerca del trabajo que podra completarse antes del
siguiente.
El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los das para reducir
la complejidad. Durante la reunin, 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 algn impedimento

E).- Revisin de Sprint (Sprint Review)


Al final del Sprint se lleva a cabo una Revisin de Sprint para inspeccionar el Incremento y
adaptar la Lista de Producto si fuese necesario. Durante la Revisin de Sprint, el Equipo
Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basndose
en esto, y en cualquier cambio a la Lista de Producto durante el Sprint, los asistentes
colaboran para determinar las siguientes cosas que podran hacerse para optimizar el valor.
Se trata de una reunin informal, no una reunin de seguimiento, y la presentacin del
Incremento tiene como objetivo facilitar la retroalimentacin de informacin y fomentar la
colaboracin.
Se trata de una reunin restringida a un bloque de tiempo de cuatro horas para Sprints de
un mes. Para Sprints ms 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
propsito. El Scrum Master ensea a todos a mantener el evento dentro del bloque de
tiempo fijado.
La Revisin de Sprint incluye los siguientes elementos:

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

13

Los asistentes son el Equipo Scrum y los interesados clave invitados por el Dueo
de Producto;

El Dueo 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 cmo fueron resueltos esos problemas;

El Equipo de Desarrollo demuestra el trabajo que ha Terminado y responde


preguntas acerca del Incremento;

El Dueo de Producto habla acerca de la Lista de Producto en el estado actual.


Proyecta fechas de finalizacin probables en el tiempo basndose en el progreso
obtenido hasta la fecha (si es necesario);

El grupo completo colabora acerca de qu hacer a continuacin, de modo que la


Revisin del Sprint proporcione informacin de entrada valiosa para Reuniones de
Planificacin de Sprints subsiguientes.

F).- 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 despus de la Revisin de Sprint y antes de la
siguiente Reunin de Planificacin de Sprint. Se trata de una reunin restringida a un bloque
de tiempo de tres horas para Sprints de un mes. Para Sprints ms 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 propsito. El Scrum Master ensea a todos a
mantener el evento dentro del bloque de tiempo fijado. El Scrum Master participa en la
reunin como un miembro del equipo ya que la responsabilidad del proceso Scrum recae
sobre l.
El propsito de la Retrospectiva de Sprint es:
Inspeccionar cmo fue el ltimo Sprint en cuanto a personas, relaciones, procesos
y herramientas;

Identificar y ordenar los elementos ms importantes que salieron bien y las posibles
mejoras; y,

Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum
desempea su trabajo.

14

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

Artefactos de Scrum
Los artefactos de Scrum representan trabajo o valor en diversas formas que son tiles para
proporcionar transparencia y oportunidades para la inspeccin y adaptacin. Los artefactos
definidos por Scrum estn diseados especficamente para maximizar la transparencia de
la informacin clave, que es necesaria para asegurar que todos tengan el mismo
entendimiento del artefacto.

A).-Lista de Producto (Product Backlog)


La Lista de Producto es una lista ordenada de todo lo que podra ser necesario en el
producto, y es la nica fuente de requisitos para cualquier cambio a realizarse en el
producto. El Dueo de Producto (Product Owner) es el responsable de la Lista de Producto,
incluyendo su contenido, disponibilidad y ordenacin.
Una Lista de Producto nunca est completa. El desarrollo ms 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 tambin lo hacen.
La Lista de Producto es dinmica; cambia constantemente para identificar lo que el producto
necesita para ser adecuado, competitivo y til. Mientras el producto exista, su Lista de
Producto tambin existe.
La Lista de Producto enumera todas las caractersticas, 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 descripcin, la
ordenacin, la estimacin y el valor.
A medida que un producto es utilizado y se incrementa su valor, y el mercado proporciona
retroalimentacin, la Lista de Producto se convierte en una lista ms larga y exhaustiva. Los
requisitos nunca dejan de cambiar, as que la Lista de Producto es un artefacto vivo. Los
cambios en los requisitos de negocio, las condiciones del mercado o la tecnologa podran
causar cambios en la Lista de Producto.

B).- Lista de Pendientes del Sprint (Sprint Backlog)


La Lista de Pendientes del Sprint es el conjunto de elementos de la Lista de Producto
seleccionados para el Sprint, ms un plan para entregar el Incremento de producto y
conseguir el Objetivo del Sprint. La Lista de Pendientes del Sprint es una prediccin hecha
por el Equipo de Desarrollo acerca de qu funcionalidad formar parte del prximo
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 ms acerca del trabajo necesario para conseguir
el Objetivo del Sprint.
Segn se requiere nuevo trabajo, el Equipo de Desarrollo lo aade a la Lista de Pendientes
del Sprint. A medida que el trabajo se ejecuta o se completa, se va actualizando la

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

15

Estimacin de trabajo restante. Cuando algn elemento del plan pasa a ser considerado
innecesario, es eliminado. Solo el Equipo de Desarrollo puede cambiar su Lista de
Pendientes del Sprint durante un 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.

C).- 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 Definicin de Terminado del Equipo Scrum.
El incremento debe estar en condiciones de utilizarse sin importar si el Dueo de Producto
decide liberarlo o no.

Los elementos

Pila del producto: lista de requisitos de


usuario que se origina con la visin inicial
del producto y va creciendo y
evolucionando durante el desarrollo.
Pila del sprint: Lista de los trabajos que
debe realizar el equipo durante el sprint
para generar el incremento previsto.
Incremento: Resultado de cada sprint

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

16

LOS ROLES
.-El Dueo de Producto (Product Owner)
El Dueo de Producto es el responsable de maximizar el valor del producto y del trabajo
del Equipo de Desarrollo. El cmo se lleva a cabo esto podra variar ampliamente entre
distintas organizaciones, Equipos Scrum e individuos.
El Dueo de Producto es la nica persona responsable de gestionar la Lista del Producto
(Product Backlog). La gestin de la Lista del Producto incluye:

Expresar claramente los elementos de la Lista del Producto;

Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y
misiones de la mejor manera posible;

Optimizar el valor del trabajo desempeado por el Equipo de Desarrollo;

Asegurar que la Lista del Producto es visible, transparente y clara para todos, y que
muestra aquello en lo que el equipo trabajar a continuacin; y,

Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del


Producto al nivel necesario.

El Dueo de Producto podra hacer el trabajo anterior, o delegarlo en el Equipo de


Desarrollo. Sin embargo, en ambos casos el Dueo de Producto sigue siendo el
responsable de dicho trabajo.
El Dueo de Producto es una nica persona, no un comit. El Dueo de Producto podra
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 travs del Dueo de
Producto.
Para que el Dueo de Producto pueda hacer bien su trabajo, toda la organizacin debe
respetar sus decisiones. Las decisiones del Dueo de Producto se reflejan en el contenido
y en la priorizacin de la Lista del Producto. No est permitido que nadie pida al Equipo de
Desarrollo que trabaje con base en un conjunto diferente de requerimientos, y el Equipo de
Desarrollo no debe actuar con base en lo que diga cualquier otra persona.

.-El Equipo de Desarrollo (Development Team)


El Equipo de Desarrollo consiste en los profesionales que desempean el trabajo de
entregar un Incremento de producto Terminado, que potencialmente se pueda poner en
produccin, al final de cada Sprint. Solo los miembros del Equipo de Desarrollo participan
en la creacin del Incremento.
Los Equipos de Desarrollo son estructurados y empoderados por la organizacin 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 caractersticas:

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

17

Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de


Desarrollo cmo convertir elementos de la Lista del Producto en Incrementos de
funcionalidad potencialmente desplegables;
Los Equipos de Desarrollo son multifuncionales, contando como equipo con todas
las habilidades necesarias para crear un Incremento de producto;
Scrum no reconoce ttulos 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 anlisis
de negocio; no hay excepciones a esta regla; y,
Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades
especializadas y reas en las que estn ms enfocados, pero la responsabilidad
recae en el Equipo de Desarrollo como un todo.

Tamao del Equipo de Desarrollo


El tamao ptimo del Equipo de Desarrollo es lo suficientemente pequeo como para
permanecer gil y lo suficientemente grande como para completar una cantidad de trabajo
significativa. Tener menos de tres miembros en el Equipo de Desarrollo reduce la
interaccin y resulta en ganancias de productividad ms pequeas. Los Equipos de
Desarrollo ms pequeos podran encontrar limitaciones en cuanto a las habilidades
necesarias durante un Sprint, haciendo que el Equipo de Desarrollo no pudiese entregar un
Incremento que potencialmente se pueda poner en produccin. Tener ms de nueve
miembros en el equipo requiere demasiada coordinacin. Los Equipos de Desarrollo
grandes generan demasiada complejidad como para que pueda gestionarse mediante un
proceso emprico. Los roles de Dueo de Producto y Scrum Master no cuentan en el clculo
del tamao del equipo a menos que tambin estn contribuyendo a trabajar en la Lista de
Pendientes de Sprint (Sprint Backlog).

.- El Scrum Master
El Scrum Master es el responsable de asegurar que Scrum es entendido y adoptado. Los
Scrum Masters hacen esto asegurndose de que el Equipo Scrum trabaja ajustndose a la
teora, prcticas y reglas de Scrum.
El Scrum Master es un lder que est al servicio del Equipo Scrum. El Scrum Master ayuda
a las personas externas al Equipo Scrum a entender qu interacciones con el Equipo Scrum
pueden ser de ayuda y cules no. El Scrum Master ayuda a todos a modificar estas
interacciones para maximizar el valor creado por el Equipo Scrum.

El Servicio del Scrum Master al Dueo de Producto


El Scrum Master da servicio al Dueo de Producto de varias formas, incluyendo:
Encontrar tcnicas para gestionar la Lista de Producto de manera efectiva;

Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista


de Producto claros y concisos;

Entender la planificacin del producto en un entorno emprico;

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

18

Asegurar que el Dueo de Producto conozca cmo ordenar la Lista de Producto


para maximizar el valor;

Entender y practicar la agilidad; y,

Facilitar los eventos de Scrum segn se requiera o necesite.

El Servicio del Scrum Master al Equipo de Desarrollo


El Scrum Master da servicio al Equipo de Desarrollo de varias formas, incluyendo:
Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional;

Ayudar al Equipo de Desarrollo a crear productos de alto valor;

Eliminar impedimentos para el progreso del Equipo de Desarrollo;

Facilitar los eventos de Scrum segn se requiera o necesite; y,

Guiar al Equipo de Desarrollo en el entorno de organizaciones en las que Scrum


an no ha sido adoptado y entendido por completo.

El Servicio del Scrum Master a la Organizacin


El Scrum Master da servicio a la organizacin de varias formas, incluyendo:
Liderar y guiar a la organizacin en la adopcin de Scrum;

Planificar las implementaciones de Scrum en la organizacin;

Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el


desarrollo emprico de producto;

Motivar cambios que incrementen la productividad del Equipo Scrum; y,

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

19

Propietario del producto: El responsable de obtener el mayor valor de producto para


los clientes, usuarios y resto de implicados.
Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto.
Scrum Manager: gestor de los equipos que es responsable del funcionamiento de
la metodologa Scrum y de la productividad del equipo de desarrollo.

Valores
Scrum es una carrocera para dar forma a los principios giles. Es una ayuda para
organizar a las personas y el flujo de trabajo; como lo pueden ser otras propuestas de
formas de trabajo gil: Cristal, DSDM, etc. La carrocera sin motor, sin los valores que dan
sentido al desarrollo gil, no funciona.

Delegacin de atribuciones (empowerment) al equipo para que pueda autoorganizarse y tomar las decisiones sobre el desarrollo.
Respeto entre las personas. Los miembros del equipo deben confiar entre ellos y
respetar sus conocimientos y capacidades.
Responsabilidad y auto-disciplina (no disciplina impuesta).
Trabajo centrado en el desarrollo de lo comprometido

Informacin, transparencia y visibilidad del desarrollo del proyecto

20

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

ROLES

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

21

COMPONENTES
PROPIETARIO DEL
PRODUCTO

PILA DEL PRODUCTO

Determina las prioridades


Una sola persona

SCRUM MANAGER

Gestiona y facilita la
ejecucin del proceso

PILA DEL SPRINT

EQUIPO

Construye el producto

Parte del producto


desarrollada en un sprint
en condiciones de ser
usada

Asesoran y observan

REUNIONES

SPRINT

PLANIFICACION DEL SPRINT

CICLO DE DESARROLLO
BASICO DE SCRUM
DE DURACION
RECOMENDADA DE 30
DIAS EN EL QUE SE
DESARROLLA IN
INCREMENTO DE
PRODUCTO

Una jornada de
trabajo.

El propietario del
producto explica las
prioridades
REUNION DIARIA

15 minutos de
duracin dirigida por el
managuer

Solo puede
intervenir el equipo
REVICION DEL SPRINT

Requisitos comprometidos
por el equipo para el sprint
INCREMENTO

INTERESADOS

Relacin de requisitos de
producto
El propietario es
responsable

VALORES

Empowerment y compromiso de
las personas
Foco en desarrollar lo
comprometido
Trasparencia y visibilidad en el
equipo

22

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

CAPITULO I
CARACTERIZACIN DEL PROBLEMA

OBJETIVOS

CAPITULO II
TEORIA CIENTFICA
BASES CONCEPTUALES

23

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

CAPITULO III
Conclusiones

Bibliografa

You might also like