MSc. Lic. Carla Salazar Serrudo Departamento de Informática y Sistemas Universidad Mayor de San Simón Cochabamba, 2016
SCRUM • Scrum es una framework framework para la gestión de proyectos, proyectos, expuesta expuesta por Product uct Hirotak Hirotakaa Takeuch akeuchii e Ikujiro Ikujiro Nonaka, Nonaka, en el el artículo artículo The New Prod Develop Development ment Game[Harvard Business Business Review Ene-Feb 1986] 1986] en el que ponen de manifiesto que: • El mercado competitivo de los productos tecnológicos, 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.
SCRUM • Scrum es una framework framework para la gestión de proyectos, proyectos, expuesta expuesta por Product uct Hirotak Hirotakaa Takeuch akeuchii e Ikujiro Ikujiro Nonaka, Nonaka, en el el artículo artículo The New Prod Develop Development ment Game[Harvard Business Business Review Ene-Feb 1986] 1986] en el que ponen de manifiesto que: • El mercado competitivo de los productos tecnológicos, 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 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 diferentes tipos de proyectos, 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.
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
• 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
• 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.
• 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
• 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 (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
• El Product Owner es una persona, no un comité. El Product Owner
representa 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 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 reestimados 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?
• 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 Product Backlog 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 Product Owner • 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ón
Permitir 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 Team debe 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 Product Owner 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 Bur Burn n - Down
Sprint Backlog • Es el conjun conjunto to de ítems ítems selecciona seleccionados dos del Product Product Backlog Backlog para para
desarrollarse durante durante el Sprint además de un plan de entrega del producto y la realización del objetivo del Sprint. • Sprint Sprint Backlog es la funcionali funcionalidad dad o que el Team Team debe desarro desarrollar llar durante durante el Sprint. • Sprint Sprint Backlog define define el trabajo trabajo a desarrollar desarrollar por el Team Team para para converti convertirr los ítems ítems del Product Product Backlog Backlog en un Increment Incremento o “Done” • Sprint Backlog es un plan bastante bastante detallado detallado que cambia cambia a medida que se comprende comprende mejor durante durante el Daily Daily Scrum. El Team Team modifica modifica el Sprint Sprint Backlog durante durante el Sprint Sprint y el Sprint Sprint Backlog Backlog surge surge durante durante el Sprint.
Sprin Sprintt Back Backlo log g (2) (2) • Si se requiere un nuevo nuevo trabajo, el Team Team lo añade al Sprint Backlog • Cuando un trabajo es ejecutado o terminado, se actualiza la
estimación de lo restante. restante. • Si los elementos de un plan se consideran innecesarios, se eliminan. • Solo el Team Team puede cambiar el Sprint Sprint Backlog, durante durante el Sprint. • Sprint Backlog es una imagen visible y en tiempo real del trabajo que el Team Team ha planeado llevar a cabo durante durante el Sprint. • Sprint Backlog solo pertenece al Team. Team.
Ejemplo de Sprint Backlog Tareas Codificar UI Codificar negocio Testear negocio Escribir ayuda online Escribir la clase foo Agregar error logging
L
M
M
J
V
8
4
8
16
12
10
4
8
16
16
11
8
8
8
8
8
8
4
12 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
s r u o H
Tareas
L
Codificar UI Codificar Negocio Testear Negocio Escribir ayuda online
M
M
J
8
4
8
16
12
10
7
8
16
16
11
12
50 40 30 20 s r u o H
10 0
Mon
Tue
V
Wed
Thu
Fri
8
Incremento • El incremento es la suma de todos los ítems del Product Backlog
terminados 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 Backlog puede 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.
