- Introducción
- Conceptos en "Scrum"
- Los
roles - Las
reuniones - Los
documentos - Todo
junto: Resumen de un proceso "Scrum" - Conclusión
- Bibliografía
Desarrollado en 2001 por Kent Beck y otras
personalidades, el "Desarrollo Ágil" del
"Software" (véase "Manifiesto Ágil", por
otras fuentes) se presenta como una nueva forma de desarrollarlo,
"haciéndolo y ayudando a otros a que lo hagan".
Así, las distintas metodologías de
desarrollo ágil llegan a valorar:
A los individuos y su iteración con el
software, por encima de los procesos y herramientas
para el desarrollo del mismo.El software funcional, por encima de
una documentación objetiva y exhaustiva del
mismo.La colaboración de los desarrolladores
con los clientes, por encima de la
negociación contractual.La respuesta del software al cambio,
por encima del seguimiento de un plan para con el
mismo.
No obstante, y pese a que en esta nueva visión de
la Ingeniería del Software se valoran más estos
aspectos, no hay que olvidar la importancia de los
demás.
Así, ¿Que entendemos por Desarrollo
Ágil?. La respuesta es clara:
Sin ser la antítesis a la Ingeniería del
Software tradicional, esta nueva forma de desarrollar software es
la combinación de una filosofía
(entregas tempranas, necesidades del cliente satisfechas, equipos
pequeños, métodos informales, simplicidad,…)
y unas directrices de desarrollo (entregas por
encima de análisis y diseño, comunicación
activa desarrollador-cliente,…).
Por ello, las metodologías de desarrollo
ágil presentan una ayuda para la
superación de debilidades reales, presentes en la
Ingeniería del Software tradicional.
A continuación se nombrarán algunos
ejemplos de metodologías ágiles
conocidas:
Programación Extrema (eXtreme
Programming – XP).Desarrollo Adaptativo de Software (Adaptative
Software Development).Método de Desarrollo de Sistemas
Dinámicos (MDSD).Melé (Scrum),
Cristal (Crystal Clear).
Desarrollo Conducido por Características
(Featured Driven Development).Modelado Ágil (Agile
Modeling).Agile Unified Process –
AUP.Essential Unified Process –
EssUP.Lean Software Development –
LSD.Open Unified Process –
OpenUP.
Todas las metodologías nombradas son
fieles al "Manifiesto Ágil", si bien no son aplicables a
todo tipo de proyectos software.
Metodología propuesta: Melé –
Scrum
Una de las metodologías de desarrollo ágil
del software más conocidas es Melé, en
inglés "Scrum". A continuación
pasaremos a explicar el funcionamiento y aspectos importantes de
esta metodología, con el fin de un mejor entendimiento y
uso de la misma.
¿Qué es?
Conocemos su contexto, conocemos los aspectos más
importantes de la Ingeniería del Software ágil,
pero ¿Qué es Scrum?.
Primeros pasos
Como breve introducción a esta
metodología, podemos decir que Scrum es un enfoque
ágil al desarrollo del software. Una de las
metodologías más conocidas y utilizadas presentes
en el "Manifiesto Ágil".
Con Scrum, los proyectos software avanzan a
través de una serie de iteraciones llamadas
"Sprints". Cada "Sprint" tiene una
duración de 2-4 semanas.
Así, si bien un enfoque ágil se puede
utilizar para gestionar varios tipos de proyectos, Scrum es ideal
para aquellos que cambian rápidamente, o cuyos requisitos
emergen continuamente, como es el caso del desarrollo de
software.
¿Metodología o marco de
trabajo?
No obstante, más que un proceso completo de
desarrollo o una metodología en si misma, Scrum es un
marco de trabajo (aun así, en este
documento hablaremos de Scrum en todo momento como una
metodología).
En palabras de Ken Schwaber
-importante desarrollador software, que junto a Jeff
Sutherland formuló las primeras versiones del proceso de
desarrollo software con Scrum-, "Scrum no es una
metodología, es un marco de trabajo". Esto quiere
decir que Scrum no te va a decir exactamente lo que debes hacer,
y que normalmente deberemos utilizarlo en conjunto con otra
metodología de desarrollo ágil (comúnmente
XP).
Historia y
Características
Pasaremos ahora a describir los hechos más
importantes en cuanto a la historia de esta
metodología, así como sus
características más
importantes.
Historia
El origen del concepto lo encontramos en
1986, año en que se realizaron estudios
sobre nuevos procesos de desarrollo software, utilizados en
Japón y Estados Unidos.
Fueron desarrollados grandes proyectos de éxito a
partir de estos nuevos procesos, y los equipos que los
desarrollaron partían de requisitos software muy
generales, novedosos, y con un límite de tiempo para salir
al mercado realmente reducido. En los mencionados estudios se
comparaba el patrón de trabajo de estos equipos con la
colaboración de los jugadores de los equipos de
Rugby, y su formación, llamada
Scrum (Melé en español).
El primer Scrum se desarrollo en
1993, cuyo objetivo era el desarrollo de
software, formalizado en 1995.
Más tarde, en 2001, varias personalidades
en cuanto al desarrollo ágil del software presentaron los
valores fundamentales de los procesos ágiles ("Manifiesto
Ágil").
Ya desde 1995 gran cantidad de empresas
empezaban a utilizar Scrum para el desarrollo de
sus proyectos, desde empresas pequeñas a grandes
multinacionales.
En la actualidad, Scrum se usa para
multitud de tipos de negocios, especialmente en el desarrollo de
software, para lo que fue inicialmente pensado.
Características
Scrum recoge todas las prácticas y
actitudes reconocidas como buenas para el desarrollo ágil
del software, y las sitúa en el centro del
proceso. De ahí se deducen sus características, que
podemos resumir de la siguiente forma:
Desarrollo Sofware iterativo e
incremental: En Scrum, la planificación del
proyecto maneja explícitamente los
requerimientos del cliente, y realiza una
priorización de los mismos en función del valor
que proporcionan al cliente y su coste de desarrollo (ROI),
desarrollando el producto de manera
incremental, de manera que el cliente no
tiene que esperar hasta el último día para
conseguir un producto funcional, pudiendo dirigir de manera
individualizada y sistemática cada
iteracción del producto(véase
"El Sprint"). Así, el cliente puede ir
recuperando poco a poco su inversión, y no
todo de golpe al final, como pasaba en las
metodologías tradicionales; puede utilizar un producto
al que le falten características poco relevantes,
puede sacarlo al mercado sin que este llegue a su fase final
de desarrollo, hacer nuevas sugerencias o peticiones a medio
camino de desarrollo, etc…Orientación a personas: En
Scrum se le da mas responsabilidad y
autoridad al equipo, al ser un equipo
multidisciplinar. Se quiere que sea este el
que decida como funcionar de manera
eficiente, de modo que sea el propio equipo
el que mejore su entorno de trabajo y pueda
mostrar resultados de manera regular; también se
fomenta la innovación en el mismo, con
respecto al proyecto que se está desarrollando,
facilitando la motivación y realización
personal de los miembros del equipo.Planificación con tiempo, tareas y
personas: En Scrum, la
planificación se orienta a los
objetivos y requerimientos que plantea el cliente, y esta es
realizada por el propio equipo, el mismo que
se ocupa de la planificación de cada
iteración del producto,
asignándose tareas y tiempos para cada
miembro, las cuales son detectadas por el equipo en conjunto,
siendo así más fiables, ya que
se basan en las experiencias e
información de todos los miembros del
equipo.Control del progreso del proyecto:
En Scrum, es el equipo el que se compromete a informar
diariamente del progreso de las tareas que el mismo
se ha asignado (véase "Las reuniones"), informando del
avance de las mismas así como de los
problemas que vayan surgiendo. Esto mejora la
transferencia de información así como de
experiencias y de soluciones, y produce una
sinergia mucho más fuerte entre los miembros del
equipo. En Scrum, más que un jefe de proyecto, hay un
facilitador (véase "Los roles") que
vela por la participación de todos los miembros
del equipo.Gestión de cambios: En Scrum,
los cambios están
permitidos y aceptados en el inicio de
cada iteración, considerándose como
algo natural, y permitiendo al cliente presentarlos una vez
demostrados los resultados de cada iteración. Esto
mejora la flexibilidad del proyecto,
permitiendo al cliente adaptarlo de mejor manera a sus
necesidades e intenciones.Retrospectivas y análisis "post
mortem": En Scrum las retrospectivas se hacen al
final de cada iteración (véase "El Sprint"),
permitiendo que un mejor aprendizaje por parte del equipo,
que puede ser de esta manera más productivo a la hora
de desarrollar el proyecto.Timeboxing: El
"timeboxing" consiste en fijar un
tiempo máximo para una tarea,
la toma de una decisión determinada, etc… y
considerar este tiempo como máximo en vez de trabajar
hasta conseguir el objetivo. En Scrum, esta
técnica se utiliza en todas las
tareas, lo que facilita la toma de decisiones
y el enfoque de resultados.
Una vez comprendidas las características
generales de esta metodología, pasaremos a desarrollar sus
conceptos más importantes, los cuales hay
que manejar con fluidez para comprender un proceso de desarrollo
software con Scrum.
El "Sprint"
Como hemos comentado anteriormente (Vease "Primeros
pasos", en este documento), un "Sprint" es una
iteración en Scrum, durante la cual se
desarrolla una parte "funcional" del proyecto, de
manera que el cliente, al final de cada Sprint, puede ver parte
de su inversión.
Un Sprint está acotado en el
tiempo, dependiendo del equipo en cada caso, pero
siempre tiene una duración máxima de un mes (30
días), y es el periodo durante el cual el Equipo
(véase "Los roles") trabaja para desarrollar ciertos
requisitos del Product Backlog (véase "Los
documentos") en un Incremento del
Producto.
No obstante, pese a que la duración de un Sprint
es variable, la duración ideal del mismo
se estima en torno a dos semanas (más de 4
semanas de duración hacen perder agilidad al equipo, y
menos de 2 ponen en duda que se pueda sacar algo de valor o
"funcional" del mismo). El objetivo prioritario de un Sprint es
conseguir algo "de valor" que presentar al
Product Owner y los Stakeholders
(véase "Los roles"). Así, ciñéndonos
al estándar de las dos semanas, podemos decir que cada
Sprint:
Proporciona Feedback sobre lo que se
está haciendo en cada momento con el
proyecto.Reduce riesgo de fallas en el
diseño y otros aspectos, ya que un fallo afecta
solamente a la iteración presente.Aumenta la facilidad de respuesta ante
cambios de requerimientos, ya que estos se pueden
añadir o adaptar en el siguiente Sprint del
producto.Mejora la capacidad de adaptación del
equipo, analizando en cada momento la forma en que
trabajan.Fuerza al equipo a seguir un enfoque
ágil del proyecto, en vez de recurrir a
metodologías tradicionales.
Al principio de cada Sprint se
planifican todas las tareas, objetivos y
actividades que se van a desarrollar durante el transcurso del
mismo, lo que se considera la "Meta del Sprint"
(véase Planificación del Sprint, en "Los
documentos"). Si por cualquier motivo no se puede alcanzar la
"Meta del Sprint", este se cancela (o si ciertas circunstancias
anulan el valor de esta meta).
Durante el desarrollo del Sprint se va
midiendo el progreso del mismo, mediante el
Sprint Backlog (véase "Los documentos") y
un gráfico BurnDown (véase "Los
documentos"). También se llevan a cabo reuniones
diarias, que explicaremos en la sección
concerniente a "Las reuniones" en este documento.
Al finalizar cada Sprint, se lleva a
cabo una Revisión del Sprint (véase
"Las reuniones"), para revisar la parte desarrollada y
presentarla, y también una Retrospectiva del
Sprint (véase "Las reuniones") para analizar
formas de mejorar el rendimiento o técnicas del equipo en
función de la experiencia adquirida en esa
iteración.
En Scrum los roles se
dividen en dos categorías, atendiendo a la
implicación en el proyecto de los miembros de esas
categorías.
Así, podemos distinguir la categoría de
los "cerdos", y la de las
"gallinas".
"En un plato de huevos con tocino
el cerdo está comprometido, la gallina solo está
involucrada"
Roles Cerdo: Los integrantes de este
rol son aquellas personas comprometidas con el
proyecto, los que responden ante sus fallos, y los
que se comprometen a desarrollarlo con calidad. Así,
dentro de este rol podemos distinguir:El Dueño del Producto o "Product
Owner": Integrante del proceso que representa
la voz del cliente, lo que este necesita y
desea. Sus responsabilidades son variadas:Se sitúa como representante de todos
los interesados(clientes, usuarios finales,…)
en el proyecto, tiene capacidad para tomar decisiones
concernientes al mismo y actúa como interlocutor
único ante el equipo.
Define objetivos del proyecto,
así como dirige sus resultados y se
preocupa por la priorización de los requisitos del
cliente (ROI –Return Of Investment-)
para formar el Product Backlog (véase "Los
documentos"). Además, colabora con el equipo de manera
activa, para llevar a cabo la planificación,
revisión, etc… de cada iteración o
Sprint.El Facilitador o "Scrum Master": Se
sitúa como protección del
equipo, a modo de barrera ante los obstáculos
que éste tenga para llevar a cabo cada Sprint. No
obstante, no es el líder del equipo,
ya que como ya dijimos (véase
"Características"), el mismo se auto-organiza. Todo
esto se puede resumir en:Se encarga de hacer cumplir las
reglas a todos los integrantes del equipo, lo que
implica asegurarse de que la lista de requisitos priorizados
esté lista antes de cada iteración, y facilitar
las distintas reuniones que se hacen en Scrum (véase
"Las reuniones").Se encarga, como ya hemos comentado, de
situarse como barrera ante los impedimentos que
surjan, y eliminar los mismos. Estos impedimentos se
detectan en las reuniones que se realizan diariamente
(véase "Las reuniones").El Equipo o "Scrum Team": El equipo
está compuesto por un conjunto de
personas que toman la
responsabilidad de
desarrollar el producto con calidad y de
acuerdo a todo lo especificado en cada iteración o
Sprint y en el proyecto en general. De manera general, sus
características son las
siguientes:Tiene un tamaño
medio-reducido, de entre 5 y 9
personas. Esto sucede por que un número
inferior a 5 personas provoca un riesgo ante imprevistos con
algún miembro del equipo, y un número superior
a 9, provoca problemas de comunicación entre los
miembros del mismo, y por tanto, una deficiente
colaboración, pudiéndose formar subgrupos. No
obstante, existen técnicas utilizadas para casos con
equipos demasiado grandes o pequeños (como el
"Scrum de Scrums", véase "Las
reuniones").Lleva a cabo una auto-organización de
sus miembros, de manera que sus integrantes
confían los unos en los otros, y comparten
información. Para auto-organizarse ellos mismos,
llevan a cabo tareas como la selección de los
requisitos a los que se compromete cada uno,
estimar la complejidad de los mismos, decidir como van a
realizar el trabajo, etc…Se trata de un equipo
multidisciplinar, lo que significa que todos
los miembros del equipo están integrados en todo el
proyecto, teniendo el conocimiento y las habilidades para
manejar todo tipo de tareas en el proyecto. Además, el
equipo debe ser estable, trabajar en una
misma localización, y dedicarse a
tiempo completo al proyecto, dependiendo en
la menor medida de lo posible de medios externos al
proyecto.Roles Gallina: Los integrantes de
este rol son aquellas personas que no están tan
comprometidas con el proyecto, aquellas que simplemente
están interesadas en el mismo
–"La gallina alimenta al proyecto "poniendo huevos", no
se ve comprometida como el cerdo que va al matadero"- , por
que están invirtiendo un dinero en él, etc. No
son parte del proceso Scrum, pero deben tenerse en
cuenta. Por tanto, las influencias de los
integrantes de este rol se tienen en cuenta, hasta el punto
en que no entorpezcan el proyecto. Dentro de este rol podemos
distinguir:Los Usuarios del Producto: Es el
destinatario del sistema, aquel para el cual
el sistema está diseñado. Participa en
cada Sprint, al inicio del mismo, dando a conocer
sus requerimientos y necesidades al Product Owner.
También participa al finalizar cada Sprint.Los Clientes, Proveedores,
Inversores,… o "Stakeholders": Son
quienes ponen el dinero y esperan los
beneficios por parte del proyecto. Participan sobre todo
revisando las iteraciones o Sprints,
evaluando estos incrementos o velando por el cumplimientos de
las metas y tiempos de desarrollo.Los Administradores: Se trata de
gente encargada de la contabilidad,
secretaria, servicios, etc…
Durante todo el proceso de desarrollo del producto, se
llevan a cabo distinto tipo de reuniones, tanto a
nivel de Sprint, como diariamente:
Reuniones diarias:
Durante el transcurso de cada Sprint se desarrollan una serie
de reuniones de carácter diario. Estas
son:Daily Scrum: En esta
reunión diaria se tratan aspectos
relacionados con el estado actual del Sprint
en curso del proyecto. La duración suele ser de
15 minutos, independientemente del
tamaño del equipo, y todos los
integrantes de la misma se
sitúan de pie, para contribuir a que la
reunión sea breve. Además, se suele "castigar"
a aquellos que lleguen tarde a la misma. La ubicación
y hora de la reunión es la misma todos los
días. Algunas de las preguntas típicas de este
tipo de reuniones son:¿Qué has hecho desde ayer?
¿Qué es lo que estás planeando
hacer hoy?¿Has tenido algún problema que te haya
impedido alcanzar tu objetivo?Scrum de Scrums: Se trata de una de
las técnicas utilizadas cuando los
equipos (véase "Scrum Team", en "Los
roles"), son demasiado grandes, y se forman
grupos de personas que forman equipos individuales. Se suele
hacer después del Daily Scrum. En
ellas los distintos grupos de equipos discutir los
aspectos importantes de su trabajo,
asistiendo una persona de cada equipo.
Algunas de las preguntas típicas que se hacen en este
tipo de reunión, aparte de las ya presentes en el
Daily Scrum, que se mantienen, son:¿Qué ha hecho tu equipo desde nuestra
última reunión?¿Qué hará tu equipo antes de
que nos volvamos a reunir?¿Hay algo que demora o estorba a tu
equipo?¿Estás a punto de poner algo en el
camino del otro equipo?Planificación del Sprint (Sprint
Planning): Se lleva a cabo antes de empezar
con el siguiente Sprint o iteración del
proyecto (cada 15 o 30 días). Se suele dividir en
dos partes, ambas con una duración
máxima de 4 horas:Selección de los Requisitos:
En esta parte el equipo recoge los requisitos
priorizados del cliente, que van a reflejar lo que
se quiere del proyecto. El cliente puede
preguntar dudas, y el equipo selecciona aquellos requisitos
más importantes, y se compromete a desarrollarlos para
esa iteración que comienza. De esta forma, se
establece el contenido del String Backlog
(véase "Los documentos).Planificación de la
Iteración: En esta parte, una vez
obtenidos los requisitos priorizados, se planifican
las tareas que son necesarias desarrollar para el
cumplimiento de esos requisitos. Los miembros del equipo
se auto-asignan las tareas.Revisión del Sprint (Sprint
Review): Al igual que cada una de las dos partes de
la Planificación del Sprint, tiene una duración
máxima de 4 horas. En este caso, la reunión se
realiza al finalizar el proceso de desarrollo del
Sprint, y en ella el equipo se encarga de
transmitir al cliente la finalización de la
iteración y le presenta los requisitos
completados, mediante la entrega del incremento
funcional del producto (o "demo"). Así, el
cliente puede evaluar la
iteración y plantear los
cambios o actualizaciones que considere
necesarios, re-planificando de esta manera el proyecto desde
la primera iteración.Retrospectiva del Sprint (Sprint
Retrospective): Duración máxima de 4
horas, al igual que la anterior reunión. En esta,
que se realiza después de la revisión
del Sprint, el equipo analiza su manera de
trabajar en la anterior iteración, ya
finalizada, y plantea cambios en la misma con
el fin de mejorar el rendimiento del
desarrollo del producto, así como su
productividad. Por otra parte, el
facilitador (véase "Los roles"), se
encarga al mismo tiempo de ir eliminando los
obstáculos que se vayan presentando y siendo
identificados.
A lo largo de un proyecto con Scrum, es
necesario redactar diferentes tipos de
documentos, tanto a nivel de proyecto, como de Sprint.
Los más importantes son:
Lista de Objetivos/ Requisitos Priorizada
(Product Backlog): Este documento representa
lo que el cliente espera del proyecto en
cuanto a objetivos y requisitos, así
como entregas. Por tanto, el propio cliente se encarga de
crear y gestionar esta lista, con la ayuda de un facilitador
y el equipo, quien se encarga de establecer un presupuesto
para completar cada requisito. Tiene las siguientes
características:Para cada objetivo o requisito de la
lista, se refleja también el valor que
este ofrece al cliente y el coste de desarrollo, de
manera balanceada, es decir, se utiliza el Retorno de la
Inversión (ROI). La lista puede ir evolucionando
durante el desarrollo del proyecto, e incluirse nuevos
requisitos.Se reflejan todas las entregas o Sprints
esperables, es decir, las entregas o incrementos del
sistema que el cliente espera recibir a medida que se
desarrolla el producto.Además, se en ella se incluyen riesgos
y obstáculos y las medidas para
solventarlos.Lista de Tareas de la Iteración
(Sprint Backlog): En este caso se refleja la
totalidad de tareas para la iteración o Sprint en
curso, con el fin de cumplir los
objetivos o requisitos para esa entrega o
incremento, y entregar algo funcional al cliente acorde con
lo esperado. Por tanto, esta lista se desarrolla al
principio de cada Sprint (véase
"Planificación del Sprint" en "Las
reuniones"). Tiene las siguientes
características:Para cada objetivo o requisito se
reflejan todas sus tareas, como se ha
auto-asignado el equipo esas tareas y el
esfuerzo necesario para completarlas.
Además, se pueden observar aquellos puntos donde se
tienen problemas o no se avanza, permitiendo
una más fácil toma de
decisiones.Cada objetivo o requisito está
ordenado por (ROI), es decir, están
priorizados, según el valor que
aportan al cliente y el coste de desarrollo.Si hay una dependencia de una tarea sobre
otra, se coloca esta tarea por debajo de la que
depende.El tiempo aproximado de desarrollo de cada
tarea debe rondar entre las 4
y 16 horas, de manera que todas las tareas
estén balanceadas (una duración
mayor dificultaría el control del progreso en la
tarea, y una duración menor crearía tareas poco
relevantes ).Gráficos de Trabajo Pendiente
(BurnDown Charts): Se trata de
gráficos, que reflejan la
velocidad con la que avanza nuestro proyecto.
Es decir, en el podemos ver que nos queda por hacer y
que tenemos pendiente, ofreciéndonos una
vista general de la rapidez con la que el proyecto en general
o el Sprint en curso en particular está avanzando. Por
tanto, podemos distinguir dos tipos de
gráficos:Gráfico de los días
pendientes para completar el
proyecto (Product BurnDown Chart), que se
construye a partir del Product Backlog.Gráfico de las horas
pendientes para completar la iteración o
Sprint en curso, que se construye a partir
del Sprint Backlog.
Una vez vistos todos los conceptos de esta
metodología, y entendido el proceso, la totalidad de un
proceso Scrum para el desarrollo software puede resumirse con el
siguiente esquema ([1]):
Después de una visión general de esta
metodología, queda claro que Scrum es muy útil para
el desarrollo de proyectos ágiles software, en particular
para aquellos en constante cambio y con una necesidad de feedback
por parte del cliente constante.
Por otra parte, se trata de una metodología
considerada como un marco de trabajo, por lo que resulta en
muchos casos imprescindible utilizarla en conjunto con otras
metodologías software, sobre todo con XP (eXtreme
Programming).
Wikipedia:
http://es.wikipedia.org/wiki/Archivo:Agile_Software_Development_methodology.jpg
http://es.wikipedia.org/wiki/Scrum
http://en.wikipedia.org/wiki/Ken_Schwaber
Campus Virtual
UEM:
http://campusvirtual.uem.es/moodle/file.php/46797/Tema3.Desarrollo_Agil._2011-2012.PDF
Libros:
http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
"Scrum y XP desde las trincheras"
– Henrik Kniberg.
Otros sitios
web:
http://www.mountaingoatsoftware.com/topics/scrum
http://www.donpoligono.com/news/index.php?option=com_content&view=article&id=1999:curso-de-qmetodologia-efectiva-de-gestion-de-proyectos-scrumq&catid=43:noticias&Itemid=86
http://www.proyectosagiles.org/historia-de-scrum
http://www.proyectosagiles.org/scrum-proceso-trabajo-2-0
http://www.proyectosagiles.org/timebox
http://www.proyectosagiles.org/que-es-scrum
http://www.dosideas.com/wiki/Sprint
http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum/proceso-roles-de-scrum.html
http://www.proyectosagiles.org/cliente-product-owner
http://www.proyectosagiles.org/equipo-team
http://www.proyectosagiles.org/facilitador-scrum-master
http://rolandojaldin.blogspot.com/2011/04/los-roles-gallina-scrum.html
http://www.proyectosagiles.org/planificacion-iteracion-sprint-planning
http://www.proyectosagiles.org/retrospectiva-sprint-retrospective
http://www.proyectosagiles.org/lista-requisitos-priorizada-product-backlog
http://www.proyectosagiles.org/lista-tareas-iteracion-sprint-backlog
http://www.proyectosagiles.org/graficos-trabajo-pendiente-burndown-charts
Autor:
Enviado por:
Ricardo Martínez
Cobo
[1] Enlace a la imagen del esquema (para
mayor resolución):
http://es.wikipedia.org/wiki/Archivo:Ficha_scrum.png