SCRUMMSc. Lic. Carla Salazar Serrudo

Departamento de Informática y Sistemas Universidad Mayor de San Simón

Cochabamba, 2016

SCRUM

• Scrum es una framework para la gestión de proyectos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo The New ProductDevelopment Game[Harvard Business Review Ene-Feb 1986] en el que ponen de manifiesto que:

• El mercado competitivo de los productos tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad.

• Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.

• El mercado exige ciclos de desarrollo más cortos.

Definición de SCRUM

• SCRUM es un marco de trabajo que permite resolver problemas complejos y se caracteriza porque es

• Ágil• Fácil de entender• Difícil de dominar, aplicar o tener un completo conocimiento

• SCRUM ha sido creado para la gestión de procesos de desarrollo de software, pero puede ser utilizado en diferentes tipos de proyectos, con requisitos inestables, que requieren rapidez y flexibilidad.

• SCRUM NO es un proceso o técnica para construir productos, más bien es un marco de trabajo en el que se puede incluir procesos y técnicas.

Origen de SCRUM• El rugby es un tipo de fútbol, que se juega con una pelota ovalada y es un

deporte de fuerte contacto físico• En el rugby se respetan mucho las reglas, tanto por parte de los jugadores,

como del público.• Se fomenta la sociabilidad, compañerismo, la honestidad, el respeto, la

disciplina, la lealtad, el sacrificio y el altruismo.• Las decisiones del árbitro, en general, son respetadas• El Scrum o la melé, una de las formaciones más reconocibles del rugby, es

una puja frente a frente, de un grupo de cada equipo formado por un máximo de ocho y un mínimo de cinco jugadores en tres líneas que se enfrentan agazapados y asidos entre sí, para comenzar a empujar con el fin de obtener el balón que ha sido lanzado en medio de ellos y sin tocarlo con la mano.

Orígenes de SCRUM

Historia de SCRUM

• Jeff Sutherland aplicó el modelo SCRUM al desarrollo de software en 1993 en Easel Corporation (Empresa de macro-juegos de compras), en Informix y en Ascential Software.

• En 1995 lo presentó junto con Ken Schwaber como proceso formal para la gestión de desarrollo de software en OOPSLA 95.

• El 2001 serían dos de los promulgadores del Manifiesto Ágil.

Modelo de SCRUM

Pilares de SCRUM

• SCRUM se basa en lo empírico.• El empirismo afirma que el conocimiento viene de la experiencia y la

toma de decisiones se basa en lo que es conocido.• Los tres pilares de todo proceso empírico son:

• Transparencia• Inspección• Adaptación

Transparencia

• Los aspectos significantes del proceso deben ser visibles para todos• Los observadores deben compartir un entendimiento común del

proceso.• Por ejemplo:

• Se debe compartir un lenguaje común entre todos los participantes• Debe existir una definición común de “Done” (terminado) tanto para los

desarrolladores como para los que deben aceptar el producto.• Los problemas deben ser conocidos por todo el equipo• La información debe estar disponible para todo el equipo

Ejemplo de tablero Kanban

Tablero Kanban, unos días después

Inspección

• Se debe inspeccionar frecuentemente los aspectos del proceso SCRUM para detectar variaciones que no son permitidas al tiempo de alcanzar la meta.

• Las inspecciones no deberían ser tan frecuentes que consigan información acerca de cómo se está haciendo el trabajo

• Deben realizarse con inspectores que sean diligentes y expertos en el tema.

Adaptación

• Si después de la inspección se determina que uno o más aspectos del proceso SCRUM se han desviado más allá de los límites aceptables, el proceso o el material que está siendo procesado debe ser ajustado.

• Los ajustes deben hacerse lo mas antes posible, para minimizar el desvío.• SCRUM incluye cinco oportunidades para transparencia, inspección y

adaptación:• Sprint Planning• Daily Scrum• Sprint Review• Sprint Demonstration• Sprint Retrospective

Componentes de SCRUM

• Roles• SCRUM Team• SCRUM Master• Product Owner

• Artefactos• Product Backlog• Sprint Backlog• Burn Down

• Actividades• Planning Sprint• Daily meeting• Sprint• Sprint demostration• Sprint review

Roles de SCRUM: Product Owner• Product Owner (Dueño del producto): Es el responsable de obtener

el máximo valor del producto y el máximo desempeño del equipo.• El Product Owner es la única persona responsable por administrar el

Product Backlog.• La administración del Product Backlog incluye:

• Escribir claramente los items del Product Backlog; • Priorizar los items del Product Backlog para alcanzar las metas de la mejor

forma posible• Garantizar el valor del trabajo que el equipo de desarrollo está realizando • Asegurar que el Product Backlog sea visible, transparente y claro para todos• Asegurar que el Team entienda los items del Product Backlog en el nivel

necesario

Product Owner (2)

• El Product Owner es una persona, no un comité. El Product Ownerrepresenta los deseos de un comité en el Product Backlog.

• El Product Owner tiene éxito si toda la empresa respeta sus decisiones. Las decisiones del Product Owner se reflejan en el contenido y orden del Product Backlog

• Solo el Product Owner puede cambiar el conjunto de requisitos.

Product Owner en Scrum

El equipo de desarrollo: Team• El Team consiste de profesionales que deben realizar el trabajo de entrega

del “incremento” resultante al final de cada Sprint. Sólo los miembros del equipo pueden crear el incremento.

• Los equipos deben organizar y gestionar su propio trabajo. La sinergia del equipo ayuda a la eficiencia y efectividad del equipo.

• Los equipos de trabajo tienen siguientes características:• Auto-organizados: Nadie puede decir al equipo cómo transformar el Product Backlog

en incrementos. Solo los del equipo pueden decidir• Multidisciplinarios: Los equipos incluyen todas las habilidades necesarias para crear

el incremento• Misma categoría: Todos los miembros del equipo son Desarrolladores• Unidad: Si bien cada desarrollador tiene sus habilidades y destrezas, el resultado del

trabajo pertenece al equipo.• El equipo no contiene sub-equipos dedicados a trabajos especializados

Tamaño del Equipo• El tamaño óptimo de un equipo debe ser pequeño para mantener la

agilidad y lo suficientemente grande para completar el trabajo.• Se recomienda por lo menos 3 desarrolladores para que exista

interacción y producción• Equipos con más de 9 desarrolladores requieren demasiado trabajo

de coordinación.• El Product Owner y el Scrum Master no deben ser incluidos dentro

del tamaño del equipo.

Scrum Master

• El Scrum Master es responsable de garantizar el entendimiento y conocimiento de SCRUM

• Scrum Master garantiza que el equipo aplica la teoría, práctica y reglas de SCRUM

• Scrum Master ayuda al equipo a entender cuáles interacciones son útiles y cuáles no lo son.

Scrum Master: apoyo al Product Owner

• Buscar técnicas para gestionar el Product Backlog de manera efectiva• Facilitar la comunicación con el equipo• Enseñar a crear las historias de usuario de manera clara y concisa• Comprender la planificación del producto a largo plazo• Entender y practicar la agilidad• Facilitar el desarrollo de eventos Scrum

Scrum Master: apoyo al equipo

• Entrenar al equipo en la auto-organización y el trabajo multidisciplinario.

• Eliminar los impedimentos del progreso del equipo• Facilitar eventos Scrum• Entrenar al equipo en aspectos de Scrum que no estén bien

adoptados y entendidos

Scrum Master: apoyo a la organización

• Guíar y entrenar para la adopción de Scrum en la organización• Planificar la implementación de Scrum• Ayudar a los empleados y a los empleados en el entendimiento y

aplicación de Scrum• Apoyar el incremento de productividad del equipo• Trabajar con otros Scrum Masters para incrementar la efectividad de

la aplicación de Scrum en la organización

Actividades de Scrum

• SCRUM incluye eventos pre-establecidos para crear regularidad y minimizar la necesidad de realizar reuniones extras

• SCRUM incluye eventos que tienen un máximo de duración. Esto garantiza una planificación y uso de tiempo apropiados, sin desperdicio de tiempo.

• Los eventos de SCRUM se constituyen en una oportunidad para inspeccionar y adaptar. Estos eventos también están diseñados para permitir la transparencia y la inspección

• Sino se los realiza, no existirá transparencia, inspección y adaptación.

El Sprint• El corazón de SCRUM es un Sprint.• Un Sprint es un evento de tiempo delimitado, de mas o menos un

mes de duración, en el cual se crea un producto (incremento)• Los Sprints deben tener una duración consistente en el desarrollo del

producto. Un nuevo Sprint debe comenzar inmediatamente después de la conclusión del previo Sprint.

• Sprint contiene y consiste de:• Sprint Planning • Daily Scrums• Desarrollo del trabajo• Sprint Review• Sprint Retrospective.

El Sprint

• Durante el Sprint: • No se pueden realizar cambios que afecten la meta del Sprint• La composición del equipo de desarrollo debe mantenerse• Los aspectos de Calidad se deben cuidar • El alcance puede ser clarificado y re-negociado entre el Product Owner y el Equipo, si es

necesario.

• Cada Sprint puede ser considerado como un proyecto de un mes de duración. Cada Sprint tiene una definición de qué tiene que ser construido, un diseño y un plan flexible que debería guiar su construcción y el desarrollo del producto final

• Cada Sprint debe durar un mes calendario. Cuando un Sprint es demasiado largo, la definición de lo que se está construyendo puede cambiar, la complejidad puede aumentar y el riesgo puede crecer. Los Sprints necesitan ser predecibles para asegurar inspección y adaptación y para controlar el costo.

.

Cancelar un Sprint

• Un Sprint puede ser cancelado antes de que se cumpla su plazo de tiempo. • Solo el Product Owner tiene la autoridad para cancelar el Sprint. • A Sprint debería ser cancelado si el objetivo del Sprint se vuelve obsoleto. Esto

podría ocurrir si la compañía cambia de directrices o si el mercado o las condiciones de tecnología cambian. Rara vez ocurre, dado el corto tiempo del Sprint

• Cuando se cancela un Sprint, se deben revisar todos los “Done” y los ítems del Product Backlog también deben ser revisados.

• Se puede entregar el trabajo realizado y los ítems no completados deben ser re-estimados y puestos en el Product Backlog.

• La cancelación de Sprints consume recursos, puesto que hay que re-agrupar los ítems en otros Sprints, durante el Sprint Planning.

• Las cancelaciones de Sprint pueden ser muy traumáticas para el Scrum Team

Reunión Sprint Planning

• El trabajo a realizarse durante el Sprint se planifica en la reunión Sprint Planning. Se elabora un plan con todo el equipo de Scrum

• La reunión de Sprint Planning tiene un límite de 8 horas para 1 mes de Sprint. Para Sprints mas cortos, se debe acortar proporcionalmente la duración de la reunión. Ej: 2 semanas de Sprint, entonces 4 horas de reunión

• La reunión de Sprint Planning tiene 2 partes, cada una de las cuales es la mitad de toda la duración de la reunion. Cada parte responde lo siguiente:

• ¿Cuál debería ser el incremento resultante del Sprint?• ¿Qué trabajo debería hacerse para alcanzar el incremento?

Parte 1: ¿Qué debería hacerse en el Sprint?

• El equipo de desarrollo debe trabajar prediciendo la funcionalidad que debe desarrollarse durante el Sprint. El Product Owner presenta una lista ordenada de los items del Product Backlog y el equipo completo colabora en el entendimiento del trabajo del Sprint

• La entrada a esta reunión es el Product Backlog, el último incremento, la capacidad proyectada de desarrollo del equipo durante el Sprint y el desempeño pasado del equipo de desarrollo. La selección de los ítems a desarrollarse es decisión única del Equipo de Desarrollo.

• Después que el Equipo de Desarrollo selecciona los items del ProductBacklog a desarrollar durante el Sprint, el Equipo elabora el objetivo del Sprint. El objetivo del Sprint debería guiar la construcción del incremento.

Parte 2: ¿Cómo debería hacerse el trabajo?• El Equipo decide cómo debería construir la funcionalidad solicitada para tener el

DONE. Los ítems seleccionados para el Sprint + el plan para entregarlos se llama Sprint Backlog

• El Equipo empieza diseñando los ítems del Product Backlog. Pueden existir variaciones en el tamaño o en el esfuerzo estimado durante la reunión de Planificación del Sprint. El trabajo planificado se debe descomponer en unidades de un día o menos (enginnering task). El equipo se auto-organiza para entender el trabajo

• El Product Owner puede estar presente durante la segunda parte de la Reunión de Planificación para aclarar los ítems seleccionados para el Sprint. Si el Equipo determina que tiene poco o mucho trabajo, se puede re-negociar el Sprint Backlog con el Product Owner. El Equipo también puede invitar a otras personas para tener opiniones técnicas o del dominio de la aplicación.

• Al final de la Reunión de Planificación del Sprint, el equipo debería ser capaz de explicar al Product Owner y al Scrum Master cómo puede alcanzar la meta del Sprint.

Objetivo del Sprint

• El Objetivo del Sprint permite al Equipo tener alguna flexibilidad para conseguir la funcionalidad solicitada durante el Sprint.

• El objetivo del Sprint puede ser un hito del gran propósito del plan del producto.

• A medida que el equipo trata de alcanzar el objetivo del Sprint, pueden existir diferencias respecto a lo planificado. Entonces, se debe negociar con el Product Owner para cambiar el alcance del Sprint Backlog

Reunión Daily Scrum

• El Daily Scrum es una reunión de 15 minutos que realiza el Equipo para sincronizar sus actividades y para elaborar un plan para las siguientes 24 horas.

• El Daily Scrum debe realizarse en el mismo lugar y hora, cada día. Durante la reunión, cada miembro del Equipo debe explicar:

• ¿Qué hizo desde la última reunión?• ¿Qué debe hacer hasta la próxima reunión?• ¿Qué obstáculos hay en el camino?

• El Equipo usa el Daily Scrum para evaluar su progreso rumbo el objetivo del Sprint. Esta reunión optimiza la probabilidad de que el Equipo alcance el objetivo del Sprint, dado que los miembros del Equipo pueden replantear el resto de su trabajo del Sprint.

Reunión Daily Scrum (2)

• El Scrum Master se asegura que el Equipo efectivice la reunión diaria de 15 minutos, pero el equipo de desarrollo es responsable por conducir la reunión.

• Cada día, el Equipo debe explicar al Product Owner y al Scrum Master cómo piensan trabajar para alcanzar el Objetivo del Sprint y crear el Incremento.

• El Scrum Master refuerza la regla que en la reunion diaria solo pueden participar miembros del Equipo de desarrollo.

• La reunión diaria mejora la comunicación, elimina otras reuniones, identifica y remueve impedimentos de desarrollo, enfatiza y promueve la rápida toma de decisiones y mejora el nivel de conocimiento del Equipo. Es clave para inspeccionar y adaptar.

Sprint Review

• Es una reunión que se realiza al finalizar el Sprint para inspeccionar el Incremento y adaptar el Product Backlog, si es necesario.

• El Equipo Scrum presenta a la gente del negocio lo desarrollado durante el Sprint. Basado en este desarrollo, se determina qué es lo próximo a desarrollarse.

• Es una reunión informal donde se presenta el Incremento para conseguir retroalimentación y fomentar la colaboración del ProductOwner

• Es una reunión de 4 horas para un Sprint de 1 mes. Si el Sprint es más corto, la reunión debería durar proporcionalmente menos. Ejemplo: 2 semanas de Sprint debería tener 4 horas de Sprint Review.

Sprint Review (2)• El Sprint Review incluye los siguientes elementos:

• El Product Owner identifica qué ha sido terminado (Done) y qué no se ha terminado.• El Equipo expone el trabajo que ha sido terminado (Done) y responde a las consultas

acerca del Incremento• El Equipo expone qué ha ido bien durante el Sprint, qué problemas tuvieron y cómo

se fueron solucionando los problemas.• El Product Owner discute el Product Backlog actual y proyecta la probable conclusión

del proyecto, basado en el progreso actual• El grupo entero discute que será lo próximo a desarrollar con vistas a la siguiente

reunión Sprint Planning• El resultado del Sprint Review es el Product Backlog revisado, de manera

que se definen los ítems a desarrollarse el siguiente Sprint. En general, el Product Backlog puede ser cambiado para conseguir nuevas oportunidades

Sprint Retrospective

• Esta reunión es una oportunidad para que el Equipo Scrum inspeccione lo hecho y cree un plan de mejoras para el siguiente Sprint.

• Esta reunión se realiza después del Sprint Review y antes del siguiente Sprint Planning. Es una reunión de 3 horas para un Sprint de 1 mes.

• Los propósitos del Sprint Retrospective son:• Inspeccionar cómo fue el último Sprint respecto a las personas, relaciones,

procesos y herramientas.• Identificar y ordenar los ítems que salieron bien • Crear un plan para implementar mejoras al trabajo desarrollado por el Equipo

Scrum

Sprint Retrospective

• The Scrum Master alienta al Scrum Team a mejorar el proceso Scrum para el siguiente Sprint.

• El Scrum Team, durante cada reunión de Retrospective, planifica cómo mejorar la calidad del producto redefiniendo el concepto de “Done”, como sea adecuado.

• El Scrum Team deberían identificar las mejoras que deberían implementarse en el siguiente Sprint.

• Implementar las mejoras significa aplicar la “Adaptación” a partir de la “Inspección”

• La reunión de Retrospective provee una oportunidad formal para enfocar en la inspección y la adaptación

Artefactos de Scrum

• Los artefactos de Scrum representan una valiosa manera de brindar transparencia y oportunidades para inspección y adaptación

• Los artefactos de Scrum maximizan la transparencia para garantizar éxito al Scrum Team en la entrega del incremento (Done)

Product Backlog

• El Product Backlog es una lista ordenada de todo lo que puede ser necesario para el producto, es decir es una fuente de requisitos para construir el producto.

• El Producto Owner es responsable por el Product Backlog: contenido, disponibilidad y orden.

• El Product Backlog nunca está completo. Los primeros desarrollos se basan en el conocimiento inicial del producto. El Product Backlog evoluciona a la par del producto y del ambiente.

• El Product Backlog es dinámico: cambia constantemente para identificar qué necesita el producto para ser apropiado, competitivo y útil. Mientras existe el producto, el Product Backlog también existe.

• El Product Backlog es una lista de todas las características, funciones, requisitos, mejoras y correcciones que se debe hacer para las futuras entregas. Los ítems de Product Backlog tienen atributos de descripción, orden y estimación

Product Backlog (2)

• El Product Backlog se puede ordenar por valor, riesgo, prioridad y necesidad. Los ítems que se encuentran en la cima de la pila del producto son aquellos que inmediatamente se desarrollarán. Se supone que estos ítems han sido los más considerados y los que más consenso tienen acerca de su valor.

• Los ítems de la cima del Product Backlog son mas claros y más detallados que los que están abajo. Por lo tanto, se pueden estimar mejor que los ítems menos detallados

• Los ítems del Product Backlog que pueden ser “Done” (terminados) en el Sprint, se consideran “listos” para seleccionarse durante la reunión de Sprint Planning

• El producto gana valor a medida que se usa y esto produce retroalimentación del mercado. Por lo tanto, el Product Backlog cada vez llega a ser una lista muy grande y exhaustiva. Los requisitos no dejan de cambiar, por lo que el Product Backlog se convierte en un artefacto con vida.

• Los requisitos cambian de acuerdo a los cambios del negocio, del mercado y de la tecnología.

Orden en el Product Backlog

Ejemplo de Product Backlog

Backlog item EstimaciónPermitir que un invitado a hacer una reserva. 3

Como invitado, quiero cancelar una reserva. 5

Como invitado, quiero cambiar las fechas de una reserva. 3

Como un empleado de hotel, puedo ejecutar informes de los ingresos por habitación disponible

8

Mejorar el manejo de excepciones 8

... 30

... 50

Ejemplo de Product Backlog

Historias de usuario = ítems Product Backlog

Más ejemplos de historias de usuario

Y más ejemplos HU

Ejemplos de HU

Mas ejemplos de historias de usuario

Más ejemplos de historias de usuario (2)

Product Backlog con prioridades y estimaciones

Product Backlog Grooming

• El refinamiento del Product Backlog (grooming) es el acto de añadir detalles, estimar y ordenar los ítems en el Product Backlog.

• Es un proceso continuo en el cual el Product Owner y el Equipo colaboran en detallar los ítems del Product Backlog. Sin embargo, el Product Owner los puede cambiar, en cualquier momento.

• El refinamiento se realiza durante el Sprint, aunque el Scrum Teamdebe decidir cómo y cuándo hacerlo.

• El Equipo es responsable por todas las estimaciones. Aunque el Producto Owner puede influir ayudando a entender la complejidad de cada ítem.

Monitorear el progreso hacia la meta

• El trabajo restante debe ser examinado. El Product Owner hace seguimiento al trabajo faltante con vista al Sprint Review. El ProductOwner compara esta cantidad con el trabajo restante en un previo Sprint Review para evaluar el progreso y completar el trabajo en el tiempo deseado. Esta información es transparente para todo el personal.

• Se usan diagramas de burndown o burnup para predecir el progreso debido a su gran utilidad. La experiencia también juega un papel muy importante para este monitoreo.

Gráfico Burn - Down

Sprint Backlog

• Es el conjunto de ítems seleccionados del Product Backlog para desarrollarse durante el Sprint además de un plan de entrega del producto y la realización del objetivo del Sprint.

• Sprint Backlog es la funcionalidad o que el Team debe desarrollar durante el Sprint.

• Sprint Backlog define el trabajo a desarrollar por el Team para convertir los ítems del Product Backlog en un Incremento “Done”

• Sprint Backlog es un plan bastante detallado que cambia a medida que se comprende mejor durante el Daily Scrum. El Team modifica el Sprint Backlog durante el Sprint y el Sprint Backlog surge durante el Sprint.

Sprint Backlog (2)

• Si se requiere un nuevo trabajo, el Team lo añade al Sprint Backlog• Cuando un trabajo es ejecutado o terminado, se actualiza la

estimación de lo restante. • Si los elementos de un plan se consideran innecesarios, se eliminan.• Solo el Team puede cambiar el Sprint Backlog, durante el Sprint.• Sprint Backlog es una imagen visible y en tiempo real del trabajo que

el Team ha planeado llevar a cabo durante el Sprint.• Sprint Backlog solo pertenece al Team.

Ejemplo de Sprint BacklogTareasCodificar UI

Codificar negocio

Testear negocio

Escribir ayuda online

Escribir la clase foo

L8

16

8

12

8

M4

12

16

8

M J

4

11

8

4

V

8

8

Agregar error logging

8

10

16

8

8

Ejemplo de Sprint Backlog

Ejemplo de tarea a partir de Historia Usuario

Monitorear progreso del Sprint

• Se puede examinar el trabajo restante en el Sprint Backlog.• El Team hace seguimiento del trabajo restante en las reuniones

diarias para pronosticar la probabilidad de alcanzar el Sprint Goal.• Al hacer el seguimiento, el equipo gestiona su progreso.• Scrum no toma en cuenta el tiempo gastado en desarrollar los ítems

del Sprint Backlog. El trabajo restante y la fecha son las únicas variables de interés.

Tablero de mando - Kanban

Un Sprint Burndown Chart

Hour

s

Hour

s

40

30

20

10

0 Mon Tue Wed Thu Fri

TareasCodificar UICodificar NegocioTestear NegocioEscribir ayuda online

L8

168

12

M M J V4

1216

711

81016 8

50

Incremento

• El incremento es la suma de todos los ítems del Product Backlogterminados durante el Sprint y en todos los Sprints previos.

• Al final del Sprint, el nuevo incremento deberá ser “Done”, lo que significa que debe ser usable y debe cumplir con las condiciones de la definición de “Done” establecidos por el Scrum Team, a menos que el Product Owner decida liberarlo tal cual.

Definición de “Done”

• Todo el Scrum Team debe entender de la misma forma el concepto de “Done” para asegurar transparencia

• El concepto de “Done” es usado para garantizar que el trabajo está completo para ser el Incremento del producto

• Esta definición guía al Team en conocer cuántos ítems del Product Backlogpuede seleccionar durante la reunión de Sprint Planning.

• El propósito de cada Sprint es entregar Incrementos que cumplan la definición de “Done”. Cada incremento debe ser usable. Cada incremento es adicionado a los incrementos anteriores a través de pruebas exhaustivas para asegurar que todos los incrementos trabajan juntos.

• A medida que el Scrum Team madura, el concepto de “Done” se vuelve mas amplio y riguroso para conseguir mayor calidad.

Conclusión

• Scrum es libre de usar.• Los roles, artefactos, reuniones y reglas de Scrum son INMUTABLES y

aunque se puede aplicar parte de Scrum, el resultado NO ES SCRUM• Scrum solo existe con todos sus elementos y funciones y también

como contenedor de otras técnicas, métodos y prácticas.

Bibliografía

• Sebastián Priolo, “Métodos ágiles”, Ed. Banfield, 2009• Wikipedia, “SCRUM”, mayo 2012• Jeff Sutherland, Ken Schwaber, The SCRUM GUIDE: The rules of the game,

October 2011. • Manuel Trigas Gallego, Ana Cristina Domingo Troncho, “Metodología

SCRUM – Desarrollo detallado de la fase de aprobación de un proyecto informático mediante metodologías ágiles”, Curso Gestión de proyectos Informáticos, http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.pdf (septiembre 2014)

• Jorge Abad, Introducción a SCRUM, diapositivas, 2015.