Ingeniería de Requerimientos y 

metodologías ágiles. SCRUM
Ing. Alice Rambo
Índice
 Introducción a las metodologías ágiles
 Requerimientos
 Procesos
 Relato de un caso de aplicación – Ver ejemplo del
Jardín.
 Presentación de un video
 Problemas frecuentes. Ejemplo de las Magdalenas.
 Instancia de trabajo grupal. Actividad 1
 Planteo de la Actividad 2
 Devolución Final
Historia
 Depende del tipo de proyecto
 proyecto con valor para el usuario mas que para seguir
una planificación, es cuando los requisitos o ambientes
son cambiantes, ejemplo mercado cambiante el
cambio es algo necesario, adaptarse es mas
importante que predecir el proyecto.
 Scrum empezó en el año 94 lleva ya 22 años
Manifiesto ágil año 2001
 Cuatro puntos aplicaciones sw o cualquier tipo de
proyecto con cambios
1. individuos e interacciones mas importante que
procesos y herramientas. ejemplo en comidas rápidas
es mas importante el proceso que el personal, la gente
se cambia y el proceso se mantiene en un restaurante
de cocina especifica es mas importante la gente y el
producto tiene requerimientos mas específicos.
2. software que funciona mas importante que
documentación exhaustiva
3. colaboración con el cliente sobre negociación de
contratos
4. responder ante el cambio sobre seguimiento de un
plan va a haber cambio, el cambio es bueno y se debe
vivir con ello
Principios y valores ágiles
 prioridad mayor satisfacción del cliente haciendo
entregas continua de software valioso para él
 los cambios son bienvenidos siempre
 la medida principal del progreso es el software
funcionando
 el gestor es un facilitador no un controlador
 equipos auto-organizados y multidisciplinarios
 inspeccionar y adaptar
 mejora continua
 respeto, claridad y comunicación
 ritmo sostenible
 la arquitectura y diseño emergen
Introducción – Metodologías ágiles
 Cuando es necesario presentar un producto de
software, se recurren a metodologías de desarrollo que
hacen hincapié en el resultado, en detrimento de por
ejemplo la documentación.
 Los ciclos de desarrollo son realmente cortos, de bajo
costo e implementación inmediata.
 Scrum es una metodología ágil, se aplica al desarrollo
de software cuando su utilización lo amerita. Su
implementación es realizada por un grupo pequeño de
profesionales, no más de 8.
 El equipo responde a una estructura, con un
Coordinador General, y los demás integrantes entre los
cuales se encuentra el mismo cliente y el usuario final,
interactúan con un alto nivel de comunicación.
 Se definen acciones en base a metas específicas dadas
por la visión del Cliente y/o Usuario Final.
Introducción – Qué es SCRUM ?
Requerimientos de Scrum

Los requisitos del sistema a nivel formal se definen al

inicio del proyecto, siendo el “product backlog” el
documento que evoluciona durante todo el desarrollo.
Los requisitos del sistema los desarrolla un equipo
especializado en ingeniería de requisitos a través del
proceso de elicitación con el cliente. En Scrum la visión
del cliente es conocida por todo el equipo y el product
backlog se realiza y evoluciona de forma contínua con
aportes de todo el equipo.
La pila de producto
 La pila de producto es el corazón de Scrum. Es donde empieza todo. La Pila de
Producto es, básicamente, una lista priorizada de requisitos, o historias, o
funcionalidades, o lo que sea. Cosas que el cliente quiere, descritas usando la
terminología del cliente. Llamamos a esto historias, o a veces simplemente elementos
de la Pila.
Ciclo de Vida del Sprint
 Procesos – Planificación del Sprint.

Exposición de prioridades.
Resolución de dudas.

Objetivo del Sprint.

Estimación del esfuerzo

para cada requisito.

PP: Propietario del Producto.

SM: Scrum Master. Product Backlog / Pila del Producto
E: Miembro del Equipo.
Velocidad
 determina cual es el numero de cosas o el esfuerzo
que puede realizar el equipo durante esas semanas
 no es el jefe del proyecto, es el equipo el que estima
 el equipo evalúa la velocidad de acuerdo a sus
capacidades.
 cuantas historias de usuario, cuanto trabajo puedo
llevar a cabo
 Depende del numero de personas en el equipo,
experiencia aptitudes y habilidades, de la historia del
equipo
Velocidad
 como se mide: en horas, en historia de usuarios, en
actividades
 la estimación mejora al avanzar el proyecto y el
conocimiento del producto
 se puede tener un sprint cero de prueba para aprender
a estimar y preparar al equipo, pero los tres primeros
sprint sirven para estimar realmente velocidad real del
equipo de acuerdo a sus capacidades.
 incorporar personas por lo general atrasa el proyecto.
 estimación método de las cartas
Burn­Down­Chart
 cuanto hicimos, cuanto nos falta
 líneas que se cruzan
 el sprint burn down chart que son las tareas realizadas y las
faltantes
 si las pendientes se vuelven mesetas representan
problemas
 otra gráfica es la que se actualiza al final de cada sprint y es
la gráfica de la pila de productos que debería ir bajando
(salvo que se incorporen tareas)
 pongo la historia, la descompongo en tareas y las tareas se
pasan de pendientes a realizadas
 cuando hay tareas transversales como requisitos no
funcionales u organizacionales, generalmente se incorporan
criterios en cada historia que generan tareas dentro de cada
historia (también puede crearse una historia ficticia)
Burn­Down­Chart
 Procesos – Reunión diaria y Revisión

Reunión diaria.

Revisión del trabajo,

resolución de trabas.

Presentación del
incremento,
sugerencias, anuncio
del próximo sprint.

Planificación del próximo Sprint

Pila del Sprint Sprint

PP: Propietario del Producto.
SM: Scrum Master.
E: Miembro del Equipo. Reunión Diaria
I: Stakeholders Incremento del Producto
Ciclo de Vida del Sprint
Planificación del Sprint
El Propietario del Producto prioriza
el Product Backlog y lo presenta al
equipo.

El trabajo es seleccionado de la
parte superior de la pila de
prioridad.

El Equipo selecciona aquello que

podrá cumplir durante el sprint.

El PP podrá redefinir el Product

Backlog.

El equipo recibe información

detallada de distintas fuentes.

Los elementos seleccionados se

desglosan en tareas a cumplirse
en el sprint.
Reunión diaria del Equipo
El Equipo se reúne diariamente, no
más de 15 minutos.

Sincronizan el progreso del

trabajo, se informan las trabas con
las que podrían encontrarse.

Se previenen la duplicación de
esfuerzos.

Alimenta la dinámica del equipo y

su espíritu. Mejora la productividad
ante la presión de informar
diariamente de los progresos.

Los objetivos claros y la dirección

son compartidas por todo el
equipo.

Se responden básicamente a: Qué

hice, que haré y que problemas
puedo tener con lo que voy a
hacer.
Incremento del producto
Al final de cada Sprint, el equipo
debería emitir un incremento de la
calidad del Producto.

Este incremento es lo que se le

muestra a las partes interesadas,
usuarios finales para su
aprobación.

En esta etapa el equipo debe

encontrar posibles errores en el
código, cuyas modificaciones
podrán formar parte de sucesivos
Sprint.

El versionado se produce cuando

el PP aprueba el incremento.
Revisión del Sprint
La revisión del Sprint, provee la
posibilidad de dar cuenta de los
avances del proyecto al finalizar el
Sprint.

Durante la revisión, el Equipo

presenta las funcionalidades,
responde preguntas a las partes
interesadas acerca de estas
explicaciones, y toma de nota de
los cambios sugeridos.

El PP analiza con las partes

interesadas y los miembros del
Equipo potenciales cambios al
Product Backlog.

Se identifican nuevas
funcionalidades que se incorporan
al product backlog y lo prioriza el
dueño del producto
Retrospectiva del Sprint
Es una reunión propuesta por el
Scrum Master con el Equipo.

Se analizan las conclusiones del

Sprint, en la que se determina que
cambios podrías realizarse. En
esta etapa se discute cómo
realizar estos cambios en
próximos Sprint.

Esta etapa permite al Equipo

evolucionar contínuamente
durante la vida de un proyecto. Es
un proceso de colaboración entre
el PP, el Scrum Master y el Equipo.

Los miembros del Equipo

identifican qué ha ido bien y qué
puede mejorarse.
Update del Product Backlog
El Product Backlog es un
documento dinámico, vivo.

Su contenido puede cambiar

durante la vida del Proyecto, por
distintas cuestiones, por ejemplo
debido a mejoras detectadas por
las partes interesadas y el PP.

La gestión del Product Backlog lo

hace el PP durante todo el
Proyecto.

Etapa en la cual se producen

acomodamientos en la pila del
Product Backlog. Se disparan
ajustes en las prioridades, a tener
en cuenta en los futuros Sprint.
Problemas del Sprint
 problemas en el sprint planning
 ausencia del dueño el producto o poca colaboración
del mismo, o no da las prioridades correctamente
 Se debe poder responder al cambio.
 el scrum master o el dueño del producto puede
cuestionar las estimaciones del equipo.
 el scrum master quiere indicar quien debe hacer las
tareas o cuando se deben cumplir, el equipo debe
autogestionarse solo
 el dueño del producto no tiene en cuenta la velocidad
del equipo.
 dirección y control vs equipos autorganizados
Relato de un caso de aplicación. 
Ejemplo del Jardín. ­ 1 de 4
La nueva propietaria de la casa de campo se dio un paseo por
los jardines. Algunas partes estaban en muy mal estado. Llamó
a su capataz y le dijo lo preocupada que estaba: se había
comprometido con su circulo de negocios a dar una recepción
en un mes, y tenía serias dudas de si eso sería posible.
Esa misma mañana, el capataz hizo unas cuantas llamadas a
otros colegas suyos. Le confirmaron que, aunque contratase a
la mejor empresa de jardinería de la provincia, tenerlo todo
listo le llevaría como mínimo dos meses. Tan sólo la
elaboración del plano del nuevo jardín, con el detalle de las
diferentes zonas, tipos de plantas y ornamentos, le llevaría casi
tres semanas, contando con que la propietaria pudiese dedicar
suficiente tiempo a la revisión y aprobación del estudio.

El capataz se dirigía al despacho de la propietaria cuando el teléfono sonó. Uno de sus colegas había recordado que un amigo
suyo había pasado por un problema similar y que se lo había resuelto una nueva empresa de jardinería que trabajaba de una
manera bastante diferente a las demás. El capataz se hizo con el teléfono y los llamó.
El planteamiento que esa empresa le ofrecía era el siguiente: vendría un equipo de 7 personas, cada una especializada en
áreas concretas de creación de jardines. Se entrevistarían con la propietaria durante una mañana entera para entender qué
era lo que necesitaba y conocer mejor cómo era el jardín. Como resultado, redactarían una lista con las cosas que la señora
necesitaba. En este punto, sería muy importante lo siguiente:
Explicarían a la propietaria cuantos días de trabajo serían necesarios para hacer cada elemento del jardín. Con esta
información, y conociendo el servicio que cada uno de estos elementos ofrecería, la señora debería elegir en qué orden se
debería arreglar el jardín, concentrándose sobre todo en tener el máximo de cosas importantes en la fecha de la recepción.
Cada 15 días el equipo enseñaría a la propietaria los elementos del jardín que habría podido completar. Viendo el progreso
real del trabajo, la señora no se llevaría a engaños. Además podría realizar ajustes de lo que le enseñasen (de hecho, ella
todavía no se veía capaz de imaginar cómo quedaría todo el jardín) y, lo que era mejor, podría cambiar sus ideas sobre las
siguientes zonas, tipos de plantas y ornamentos, dado que todavía no se habría empezado a trabajar en ellos. Únicamente
necesitarían una mañana para enseñarle el estado del jardín y entender (tanto ella como el equipo) cuáles deberían ser los
objetivos de la siguiente quincena. Durante este tiempo también sería necesario poder contactar con ella para preguntas
puntuales.
Ejemplo del Jardín. ­ 2 de 4
Por otro lado, el equipo no conocía bien los problemas con
que podría encontrarse en una vez en el jardín:
La señora escogió qué puntos necesitaba que estuviesen
canalizaciones de agua en peor estado del que esperaban,
listos en la fecha de la recepción, es decir, en un mes.
aptitud de las tierras y orientación respecto a los nuevos
Debían incluir arreglar las partes más importantes de los
tipos de plantas deseados, búsqueda de herramientas
jardines de la entrada principal, el acceso hasta la casa y la
específicas en las que todavía no podían pensar, etc. Por
parte de detrás de la casa. En los laterales apenas se haría
esto, al principio de cada quincena sería el propio equipo
nada: allí donde tuviese que pasar un número alto de
quien decidiría cuántas cosas se vería capaz de completar.
invitados se haría un arreglo rápido para dar un aspecto
Durante este tiempo, y para poder respetar el compromiso más regular, siempre que ese arreglo fuese el máximo de
adquirido, sería muy importante que la propietaria no compatible con el trabajo a realizar en esa zona en la
realizase cambios sobre lo que se acordó hacer. Es decir, siguiente quincena .
antes de cada quincena la señora debería tener claro qué
sería lo más importante para ella. El propio equipo la
ayudaría, si fuese necesario.
El capataz pensó que estas reglas eran bastante razonables
y que, con esa manera de trabajar, su jefa podría tener el
mejor jardín posible para la recepción que tenía que dar en
un mes, con lo que contrató a la empresa.
El equipo se reunió con la señora durante toda una
mañana. A partir de las necesidades de la propietaria se
elaboró una lista de 50 puntos con los elementos de jardín y
tareas que las cubrían. Para estimar rápidamente cuantos
días de trabajo serían necesarios para completar cada
punto, su jefe los iba leyendo en voz alta y ellos indicaban
con las manos el número de días de trabajo. Si había una
diferencia importante entre lo que decían dos personas,
cada uno de ellos explicaba en qué se había basado su
estimación. Finalmente, se vio que para arreglar todo el
jardín serían necesarios dos meses y medio
aproximadamente.
Ejemplo del Jardín. ­ 3 de 4
El equipo preguntó y acordó con la señora los detalles Cada día por la mañana, nada más llegar, el equipo se
necesarios para empezar el trabajo de los primeros quince juntaba 10 minutos. De pie, se explicaban en qué cosas
días (los jardines de la entrada principal y la parte de detrás habían estado trabajando el día anterior, en qué iban a
de la casa, donde se haría el convite, cosas que trabajar ese día y qué problemas tenían. Tras esa mini
representaban los primeros 10 puntos de la lista). El equipo reunión, algunos seguían pensando sobre cómo resolver
después realizó un plan de trabajo: detalló la lista de tareas alguna situación concreta, mientras que su jefe llamaba por
necesarias para poder completar cada uno de los teléfono a su empresa, proveedores de maquinaria o
elementos que habían escogido con la propietaria, se herramientas, o iba directamente a hablar con el capataz
repartieron las tareas y se pusieron a trabajar. para conseguir algo que su equipo necesitaba.
El equipo decidió rehacer las canalizaciones de sólo esas
primeras zonas y de la bomba de riego que conectaba
directamente con ellas. No rehizo las canalizaciones
circundantes, sino que hizo lo mínimo necesario para que
siguiesen funcionando y que no fuese difícil poner las
nuevas cuando la señora decidiese la quincena en qué
trabajar en esas zonas no prioritarias
Tras los primeros 15 días, recorrieron el jardín con la señora
enseñándole lo que habían completado. Sólo había
quedado por terminar 1 punto de los 10 primeros
acordados. La señora pensó que en la siguiente quincena
(en la que el jardín debería estar listo para la recepción) era
más importante no hacer el punto pendiente y escoger bien
los siguientes. El equipo consensuó con ella hacer sólo 9
puntos de la lista y así asegurar más la calidad de cara a la
recepción. Después de hablar con la propietaria, los
miembros del equipo dedicaron un par de horas a analizar
cómo habían estado trabajando esa quincena, qué
problemas eran los más importantes que se estaban
encontrando de manera repetitiva (y que habría que
resolver en la siguiente quincena) y qué nuevas técnicas o
alternativas querían probar.
Ejemplo del Jardín. ­ 4 de 4
En el día previo a la recepción apenas hubo que hacer unos La propietaria había entendido que la flexibilidad para
retoques finales del trabajo realizado en la segunda hacer cambios y el hecho de tener un jardín siempre
quincena. preparado para nuevas recepciones era lo que más se
adaptaba a sus necesidades, con lo que convocó al equipo
La recepción fue todo un éxito. Los invitados felicitaron
para contratar y planificar los siguientes meses de trabajo.
repetidas veces a la propietaria por los hermosos y
acogedores jardines de su casa, cosa que la hizo sentir
especialmente bien.
Cada quincena el equipo repitió el mismo proceso: daban
una vuelta por el jardín con la señora, le enseñaban cómo
habían resuelto cada punto de la lista, consensuaban
cuales serían las cosas más importantes a hacer en la
siguiente quincena y preguntaban el detalle necesario.
Cada vez el equipo conocía mejor el jardín, con lo que su
velocidad de trabajo (y el número de elementos que
completaba) era mayor.
Llegó la última quincena de trabajo. Los puntos que
quedaban en la lista apenas tenían importancia. La
propietaria pensó que no valía la pena perder tiempo y
dinero en detalles que apenas nadie tendría en cuenta. Por
el contrario, le convenía más hacer un gran cambio en una
zona del jardín en la que ya se había trabajado: necesitaba
darle un aspecto un poco más oriental, ya que tras la
recepción había empezado a hacer negocios con personas
de China y Corea, y sería muy distendido tener
conversaciones con ellas en aquella parte del jardín.
Presentación de un video
Problemas frecuentes. 
¿Qué NO es Scrum?
Scrum no es una varita mágica
ni la piedra filosofal.
No se crea que por el simple
hecho de usar Scrum su vida
será más alegre y sus proyectos
grandes éxitos. Scrum es
simplemente una forma eficaz
de organizar el trabajo y
mejorar
las comunicaciones y relaciones
del equipo, al mismo tiempo es
eficaz para el
cumplimiento de objetivos. Es
rápido y divertido.
Problemas para Scrum
Algunas de las trabas con la
que te puedes encontrar a la
hora de implantar Scrum son:
✗ Compañeros
obstruccionistas o
malintencionados.
✗ Corporaciones
desorganizadas.
✗ Entornos de excesiva
burocracia.
✗ Falta de autoridad.
✗ Dirección no comprometida
con los objetivos y/o medios.
✗ Clientes conflictivos.
Problemas frecuentes. ­ El horno de las 
magdalenas 1 de 3
Supongamos que tenemos una fábrica de magdalenas que Pero entonces entra corriendo un mensajero con un
consta de las siguientes partes: encargo: un bizcocho urgente. El bizcocho ocupa el espacio
de tres moldes de magdalenas. Y Don Dueño de Producto
.- Una cinta sin fin en la que se van colocando los moldes
dice “parad la hornada, que hay que meter un bizcocho
de magdalena con la masa
urgente”. Don Equipo dice “mira, la hornada lleva dos
.- Un horno en el que se van introduciendo los moldes de minutos… ¿No puedes esperar tres minutos más para que
cinco en cinco y son horneados durante 5 minutos metamos el bizcocho?”
.- Una salida del horno, por la que las magdalenas ya
horneadas salen en dirección al cliente
Tenemos a dos personas operando la fábrica. Una opera la
cinta y va colocando los moldes. La otra opera el horno. La
primera se llama Don Dueño de Producto, y la segunda se
llama Don Equipo. Lo vamos pillando, ¿no? :twisted:
La fábrica de magdalenas funciona muy bien y los clientes
están contentos con el producto. Tan contentos que
empezamos a tener más clientes, más demanda, y a Don
Dueño de Producto le entran las prisas.
Entonces, en medio de una hornada, Don Dueño de
Producto se dirige a Don Equipo y le dice “oye, abreme el
horno que quiero ver cómo va todo”. Don Equipo le
responde “no hombre, no… Si abrimos el horno se va toda
la temperatura, y las magdalenas no suben”. Y Don Dueño
de Producto, refunfuñando, se aguanta.
Problemas frecuentes. ­ El horno de las 
magdalenas 2 de 3
“¡No! ¡No lo entiendes! ¡Es urgente! ¡El cliente lo
demanda!”. Don Equipo mira al cielo resignado y dice “ok,
ok, paramos la hornada y tiramos estos moldes para
empezar una hornada nueva de cinco minutos”.
Y entonces, para asombro de Don Equipo, Don Dueño de
Producto le mira con cara de horror y dice “¡No! no lo has
entendido… Hay que hacer el bizcocho en esta hornada y
*además* de las magadalenas“. Cuando Don Equipo logra
salir de su asombro le dice “pero vamos a ver… Lo primero
es que te vas a cargar las magdalenas que estan metidas,
pero incluso aunque aceptes eso, ¿dónde quieres que meta
el bizcocho si el horno ya esta lleno?”.

Entonces Don Dueño de Producto se enfada de verdad. “¡Estoy harto de quejas! No entendéis los malos tiempos que vivimos
y lo importante que es este encargo, el cliente siempre tiene la razón. Hay que hacerlo y hay que hacerlo. Si no se puede,
pues se tiene que poder. Y punto. Y si no hay sitio, pues lo colocais encima de esos tres moldes de magdalenas, y como
escuche mas quejas voy a empezar a escribir cartas de despido a la voz de ya”.
Ante la amenaza, Don Equipo abre el horno (con lo que se va la temperatura), coloca el bizcocho encima de tres moldes (con
lo que el bizcocho queda cerca de la resistenci superior del horno y las magdalenas aplastadas), cierra el horno y espera tres
minutos a que termine la hornada, también conocida como Sprint. El resultado es el lógico:
Horno Magdalenas Scrum
Claro, al realizar el envío al cliente, este lo devuelve indignado. Así que ahora tenemos que hacer cinco magdalenas, un
bizcocho y las cinco magdalenas que tocaría hacer ahora. Suponiendo que hagamos bien las cosas, generamos ahora mismo
un retraso de ocho magdalenas: tenemos que parar la linea, meter cinco magdalenas y luego meter el bizcocho, y
aprovecharíamos el segundo turno para meter al menos dos magdalenas nuevas, así que en dos turnos produciríamos dos
magdalenas nuevas además de todo el trabajo rechazado.
Si desde el principio hubieramos hecho las cosas bien y hubieramos esperado al segundo turno para meter el bizcocho, solo
habríamos generado un retraso de tres magdalenas (las que ocupa el bizcocho). Ahora sin embargo hemos generado deuda
técnica, y típicamente Don Dueño de Producto ser irá poniendo cada vez más nervioso y seguirá pieiendo que metamos más
cosas de las que caben en el horno
Problemas frecuentes. ­ El horno de las 
magdalenas 3 de 3
Moralejas (algunas ;-) ):

1.- Los equipos necesitan su temperatura adecuada. Ni tan frío

que no cueza ni tan caliente que se queme. La sopa, por ejemplo,
tiene su temperatura de cocción a la que todos los ingredientes
dan su punto. Más frío y no sabrá a nada, más caliente y se
quemará. Esta temperatura adecuada de equipo es lo que yo
denomino un “estrés saludable” o, en términos Agile, el “paso
sostenible”, es decir, el ritmo que podemos mantener
indefinidamente sin cansarnos.

2.- El Dueño de Producto debe de manejar la Pila de Producto, no

la Pila de Sprint. Si el Dueño de Producto se dedica a interferir en
el espacio de trabajo del equipo (Sprint), no podemos esperar que
emerja la autogestión ni los estados hiper-productivos asociados a
Scrum. Eso no quiere decir que el equipo no informe diariamente
del progreso, proporcione toda la visibilidad posible y acepte el
criterio del Dueño de Producto en las entregas (si el Dueño de
Producto dice que no vale, es que no vale). Esto también aplica a
cualquier entorno jefe-empleados, no necesariamente a Scrum:
los equipos tienen que tener su espacio y su margen de
maniobra, y la microgestión solo conduce a la suboptimización y
al bajo rendimiento.

3.- Ante una situación de deuda técnica cualquier momento es

mejor que el siguiente para decir “alto” y aplicar el principio Lean
de Jidoka. Dicho de otra forma, cuando uno está en el fondo de un
pozo lo primero que tiene que hacer es dejar de cavar. Tened en
cuenta que, como otros tipos de deuda, crece a interés
compuesto (por cierto, es falso que Einstein dijera que se trata de
la mayor fuerza del Universo o el mayor invento del siglo veinte ;-)
).
Actividad

Instancia de trabajo grupal. Actividad Planteo

Devolución Final

Scrum no es una metodología. Scrum ni
siquiera es un proceso. A lo sumo podríamos
definirlo como un metaproceso: una maquinita
que nos ayuda a construir iteractiva e
incrementalmente nuestro propio proceso.

Scrum = reglas + espíritu + buenas prácticas

Scrum es simple pero dificil. ¿Por qué? Porque
su definición es clara y concisa, pero a la hora
de utilizar esa definición es necesario
interpretarlo dependiendo del contexto en el
que nos encontremos. La definición de Scrum es
incompleta a propósito

Scrum es el balance entre el el pragmatismo y
el idealismo

La dinámica de un proyecto Scrum puede
resumirse a grandes rasgos como una serie de
iteraciones durante las cuales se irán
desarrollando orgánicamente tanto producto
como proceso

Scrum es, recordemos, equilibrio inestable. O lo
que es igual, el balance entre límites y libertad

La finalización de tareas no entrega valor
alguno; sólo la historias completadas entregan
valor

Scrum es como las suegras, siempre te estan
señalando tus defectos - "Scrum is like your mother-
in-law," Ken Schwaber said at the recent Agile
Vancouver conference. "It's constantly pointing out
your shortcomings.

Scrum define solamente cuatro artefactos ‣ Product
Backlog ‣ Sprint Backlog ‣ Burndown de tareas ‣
Backlog de impedimentos

Tomando un enfoque distinto de la misma situación,
podríamos comenzar a considerar al error como
inversión. Al equivocarnos aprendemos qué no
debe hacerse. Pero también nos dimos la suficiente
libertad como para encontrar un diamante entre
tanto carbón

Semana a semana el facilitador ayuda a que el
equipo responda una pregunta simple: qué cambiar
y por qué. A este proceso lo llamamos facilitación
guiada por el dolor. El dolor no es infligido sino
detectado y expuesto a la luz.

Una buena retrospectiva consiste en inspeccionar y
adaptar nuestra forma de trabajo

La retrospectiva es el corazón que le da vida a un
proyecto Scrum. Es el motor que nos empuja a vivir
un proyecto persiguiendo lo que podemos llamar
una útopia útil: la perfección existe, es imposible de
alcanzar y, sin embargo, todos los días intento estar
más cerca.
Devolución Final
Diferencia entre la implicación y el compromiso en la realización de un proyecto:
Aunque esta metáfora se utiliza en Scrum para agrupar los roles principales distinguiendo entre aquellos
que ponen “la carne en el asador” (cerdos), y el resto de afectados y participantes (gallinas), es
igualmente aplicable a las actitudes de los componentes de un equipo de trabajo, independientemente
de la metodología utilizada.
Muchas gracias !!!
Bibliografía
 Agile Project Manegement with Scrum. Ken Scwaber. Microsoft Press.
 Agile Software Development with Scrum. Ken Scwaber. Prentice Hall 2002
 SoManifiesto de desarrollo ágil. http://agilemanifesto.org/iso/es/
 Experiencia-Implantacion-CMMI-DEV-v1-2-metodologias-agiles-y-software-libre. José Manuel Navarro. Kybele Consulting y
Universidad Rey Juan Carlos.
 Actas de 1a Conferencia Agile-Spain CAS 2010. Agustín Yagüe Panadero. Juan Garbajosa Sopeña. Jénnifer Pérez Benedi .
Pedro Pablo Alarcón Cavero.
 IMPLANTACIÓN DE LAS NORMAS ISO/IEC 15504 E ISO/IEC 12207 CON MÉTODOS ÁGILES Y SCRUM Mª Carmen García,
Emanuel Irrazabal y Javier Garzás
 SCRUM Y XP DESDE LAS TRINCHERAS. Cómo hacemos Scrum. Henrik Kniberg. Prólogos de Jeff Sutherland y Mike Cohn.
 Flexibilidad con Scrum - Jorge Serrano
 ScrumManager . Manual. Juan Palacio.
 Explicando Scrum a mi abuela - Jorge Serrano - MVP Visual Developer –
http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx Ultima visita: 2014/10/15
 http://www.proyectalis.com/2007/01/21/un-caso-de-estudio/ . Ultima visita: 15/11/2014
 http://www.scrumforteamsystem.com ultima visita: 03/12/2014
 http://www.Principles behind the Agile Manifesto.htm ultima visita: 15/11/2014
 http://www.Manifesto for Agile Software Development.htm ultima visita 15/11/2014
 Cyment, Alan. El espíritu de Scrum, El arte de amar los lunes. V0.2 -
http://es.scribd.com/doc/84799747/El-espiritu-de-Scrum
 Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series)
 Shore, James. The Decline and Fall of Agile. http://www.jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
 Hundermark, Peter (traducido por Cyment, Alan) . Un mejor Scrum - http://www.scrumsense.com/wp-
content/uploads/2012/03/Un-mejor-Scrum-2.pdf