<ul><li>Presentación Marta Padilla </li></ul><ul><li>Desarrollo Agile </li></ul><ul><li>Agile Manifesto </li></ul><ul><li>...
<ul><li>Background </li></ul><ul><ul><li>Ingeniera superior en informática </li></ul></ul><ul><ul><li>Project Manager  con...
<ul><li>Grupo de tecnologías de desarrollo de software basadas en una serie de principios comunes: </li></ul><ul><ul><li>D...
<ul><li>“ Mientras que valoramos los conceptos de la </li></ul><ul><li>derecha… </li></ul>valoramos AÚN MÁS los de la izqu...
<ul><li>SCRUM es una metodología de desarrollo de software concreta que se engloba dentro de las metodologías ágiles (“Agi...
<ul><li>SCRUM no define procesos y técnicas para desarrollar productos, sino que es un framework (esqueleto) que sienta un...
<ul><li>Se basa en 3 principios: </li></ul><ul><li>Transparencia:  Todos los aspectos que influencian el resultado deben d...
<ul><li>Equipo y roles </li></ul><ul><li>Iteraciones fijas – Sprints </li></ul><ul><li>Reuniones </li></ul><ul><ul><li>Reu...
<ul><li>Equipo y Roles </li></ul><ul><ul><li>En SCRUM existen 3 roles distintos: </li></ul></ul><ul><ul><ul><li>SCRUM Mast...
<ul><li>El SCRUM Master es responsable de asegurar que el equipo se adhiere a los valores de SCRUM, a sus practicas y a su...
<ul><li>El Product Owner es el  único  responsable del Product Backlog y de asegurar el  valor  comercial del trabajo que ...
<ul><li>Para que el Product Owner tenga éxito, toda la organización debe respetar sus decisiones: </li></ul><ul><ul><li>Na...
<ul><li>Cada Sprint, el equipo transforma el Product Backlog  en un incremento del producto final que esta potencialmente ...
<ul><li>Los equipos se auto-organizan: Nadie (ni tan sólo el SCRUM Master) le dice al equipo cómo transformar el Product B...
<ul><li>Iteraciones fijas: Sprint </li></ul><ul><ul><li>Es el “corazón” de SCRUM.  </li></ul></ul><ul><ul><li>Dura de 1 me...
<ul><li>Durante el Sprint el SCRUM Master tiene que asegurar que no se realicen cambios que afecten a los objetivos del Sp...
<ul><li>En SCRUM, el horizonte temporal del proyecto se reduce a un mes o a quince días (dependiendo de la duración del Sp...
<ul><li>Sólo el  Product Owner  puede cancelar un Sprint. </li></ul><ul><li>Sólo si el objetivo del  Sprint  pasa a ser ob...
<ul><li>Reuniones </li></ul><ul><ul><li>Reunión de Release Planning </li></ul></ul><ul><ul><li>Reunión de Sprint Planning ...
<ul><li>En la reunión de Release planning se establece el plan y los objetivos de la Release, además de decidir la estrate...
<ul><li>En la mayoría de organizaciones ya existe un proceso para planear  Releases , en el que se definen los objetivos g...
<ul><li>También llamada “reunión de kick-off” para el Sprint, es en esta reunión que se planea la iteración. Se limita a 8...
<ul><ul><li>Durante la segunda (el “ Cómo ”), el equipo decide cómo se van a desarrollar dichos puntos. </li></ul></ul><ul...
<ul><li>El Sprint Review tieen lugar al final del Sprint. Limitado a 4 horas para Sprints de 1 mes, en general se estima q...
<ul><li>En general, se sigue un patrón del tipo: </li></ul><ul><ul><li>El Product Owner identifica lo que se ha hecho y lo...
<ul><li>Tiene lugar después del Sprint Review y antes del próximo Sprint Planning, estimado en 3 horas. </li></ul><ul><li>...
<ul><li>Reunión diaria de 15 minutos, que tiene lugar en el mismo sitio y a la misma hora cada día. Durante la reunión (se...
<ul><li>La reunión diaria de SCRUM mejora las comunicaciones entre el equipo, eliminando la  necesidad de muchos otras reu...
<ul><li>Artifacts </li></ul><ul><ul><li>Product Backlog:  Lista prioritizada de todo aquello que es necesario para complet...
<ul><li>El Product Backlog contiene los requerimientos para el producto que el equipo va a desarrollar.  </li></ul><ul><li...
<ul><li>Representa todo aquello necesario para desarrollar y lanzar un producto con éxito: </li></ul><ul><ul><li>Funciones...
<ul><li>Consiste en las tareas que el equipo reqliza durante 1 Sprint para transformar los requerimientos del Product Back...
<ul><li>El gráfico Sprint Backlog Burndown muestra la cantidad de trabajo aún por realizar en un Sprint. </li></ul><ul><li...
<ul><li>Hemos visto los elementos de SCRUM que se pueden considerar como “reglas”, pensadas para dar coherencia al desarro...
<ul><li>3 puntos de inspección / adaptación: </li></ul><ul><li>Daily SCRUM  – Inspeccionamos el progreso del Sprint y hace...
<ul><li>Como hemos visto, SCRUM se basa en entregar incrementos del producto final, potencialmente listos para una Release...
 
Próxima SlideShare
Cargando en…5
×

Gestión de Proyectos Agile - Scrum

15.871 visualizaciones

Publicado el

Publicado en: Tecnología, Empresariales
2 comentarios
11 recomendaciones
Estadísticas
Notas
Sin descargas
Visualizaciones
Visualizaciones totales
15.871
En SlideShare
0
De insertados
0
Número de insertados
61
Acciones
Compartido
0
Descargas
523
Comentarios
2
Recomendaciones
11
Insertados 0
No insertados

No hay notas en la diapositiva.
  • PRESENTACIÓN A ACABAR – DRAFT Añadir cómo Agile suele asociarse con test-driven development, etc
  • IDEA DE LA PRESENTACIÓN: Explicar mis experiencias como SCRUM Master en Avis, una multinacional europea con sede en UK. Me centraré en los beneficios / complicaciones particulares de la implementación. No es un recopilatorio de “pros y contras” de SCRUM en general. También: los trucos que utilizamos, que pueden ser útiles, lo que identificamos que era más importante, etc.
  • .
  • Gestión de Proyectos Agile - Scrum

    1. 2. <ul><li>Presentación Marta Padilla </li></ul><ul><li>Desarrollo Agile </li></ul><ul><li>Agile Manifesto </li></ul><ul><li>Agile y SCRUM </li></ul><ul><li>Elementos de SCRUM </li></ul><ul><ul><li>Equipo y roles </li></ul></ul><ul><ul><li>Iteraciones fijas – Sprints </li></ul></ul><ul><ul><li>Reuniones </li></ul></ul><ul><ul><li>Artifacts </li></ul></ul><ul><li>Preguntas </li></ul>
    2. 3. <ul><li>Background </li></ul><ul><ul><li>Ingeniera superior en informática </li></ul></ul><ul><ul><li>Project Manager con base técnica </li></ul></ul><ul><ul><li>Experiencia internacional </li></ul></ul><ul><li>Project manager en un entorno de desarrollo de software en GB </li></ul><ul><ul><li>Involucrada en la definición y implantación de metodologías de desarrollo y project management </li></ul></ul><ul><ul><li>Definición </li></ul></ul><ul><ul><ul><li>Miembro del steering group para definir la implantación concreta en varios equipos de desarrollo </li></ul></ul></ul><ul><ul><li>Implantación </li></ul></ul><ul><ul><ul><li>Doble rol: SCRUM Master / Project Manager </li></ul></ul></ul><ul><ul><ul><li>Coach para la posterior implantación en otros equipos </li></ul></ul></ul><ul><li>Consultora a través de empresa propia, fastzink </li></ul><ul><ul><li>Project Management </li></ul></ul><ul><ul><li>Procesos, técnicas y metodología de desarrollo de software </li></ul></ul><ul><li>Certificaciones: </li></ul><ul><ul><ul><li>PMP </li></ul></ul></ul><ul><ul><ul><li>Certified SCRUM Master </li></ul></ul></ul>
    3. 4. <ul><li>Grupo de tecnologías de desarrollo de software basadas en una serie de principios comunes: </li></ul><ul><ul><li>Desarrollo iterativo </li></ul></ul><ul><ul><li>Equipos que se auto-organizan </li></ul></ul><ul><ul><li>Equipos que priman la colaboración </li></ul></ul><ul><ul><li>Procesos adaptables con capacidad de respuesta al cambio, etc. </li></ul></ul>
    4. 5. <ul><li>“ Mientras que valoramos los conceptos de la </li></ul><ul><li>derecha… </li></ul>valoramos AÚN MÁS los de la izquierda” El término “Agile Development” se acuñó en 2001, junto con el llamado “Agile Manifesto”: Personas e interacciones Software que funciona Colaboración con el cliente Responder al cambio Procesos y herramientas Documentación comprensible Negociación del contrato Seguir el plan
    5. 6. <ul><li>SCRUM es una metodología de desarrollo de software concreta que se engloba dentro de las metodologías ágiles (“Agile”). </li></ul><ul><li>No es la única: Existen otras metodologías como DSDM, XP, Evo, etc. </li></ul>SCRUM DSDM XP Metodologias ágiles
    6. 7. <ul><li>SCRUM no define procesos y técnicas para desarrollar productos, sino que es un framework (esqueleto) que sienta unas bases en las cuales enmarcar procesos y técnicas de desarrollo concretas. </li></ul><ul><li>SCRUM… </li></ul><ul><li>Está basado en la teoría de control de procesos empíricos </li></ul><ul><li>Es iterativo e incremental </li></ul><ul><li>Optimiza la predictibilidad y control de riesgos </li></ul>
    7. 8. <ul><li>Se basa en 3 principios: </li></ul><ul><li>Transparencia: Todos los aspectos que influencian el resultado deben de ser visibles al cliente. </li></ul><ul><li>Inspección: Todos los aspectos del proceso deben de ser inspeccionados frecuentemente para detectar variaciones inaceptables en el mismo o en el producto resultante. </li></ul><ul><li>Adaptación: Si se detectan variaciones inaceptables, se deben tomar medidas para adaptar dichos procesos o dicho resultado. </li></ul><ul><li>Más adelante veremos cómo los “componentes” de SCRUM hacen posible que estos 3 principios se cumplan en todo momento. </li></ul>
    8. 9. <ul><li>Equipo y roles </li></ul><ul><li>Iteraciones fijas – Sprints </li></ul><ul><li>Reuniones </li></ul><ul><ul><li>Reunión de Release Planning </li></ul></ul><ul><ul><li>Reunión de Sprint Planning </li></ul></ul><ul><ul><li>Daily SCRUM (SCRUM diario) </li></ul></ul><ul><ul><li>Reunión de Sprint Review </li></ul></ul><ul><ul><li>Reunión de Sprint Retrospective </li></ul></ul><ul><li>Artifacts </li></ul><ul><ul><li>Product Backlog </li></ul></ul><ul><ul><li>Sprint Backlog </li></ul></ul><ul><ul><li>Gráficos de Release / Sprint Burndown </li></ul></ul>
    9. 10. <ul><li>Equipo y Roles </li></ul><ul><ul><li>En SCRUM existen 3 roles distintos: </li></ul></ul><ul><ul><ul><li>SCRUM Master: Responsable de asegurar que la metodología SCRUM se entiende y se sigue. </li></ul></ul></ul><ul><ul><ul><li>Product Owner: Responsable de maximizar el valor de negocio de lo que el equipo hace. </li></ul></ul></ul><ul><ul><ul><li>Equipo: Los que realizan el trabajo (desarrolladores). </li></ul></ul></ul><ul><ul><li>Una observación acerca de cerdos y gallinas… </li></ul></ul>
    10. 11. <ul><li>El SCRUM Master es responsable de asegurar que el equipo se adhiere a los valores de SCRUM, a sus practicas y a sus reglas. </li></ul><ul><li>Ayuda no sólo al equipo, sino a la organización en general a adoptar SCRUM. </li></ul><ul><li>Guía al equipo de SCRUM , conduciéndolo a ser más productivo y a crear productos de más alta calidad. </li></ul><ul><li>Enseña al equipo a ser más autosuficiente. </li></ul><ul><li>El SCRUM Master no es el jefe de proyecto a la manera tradicional, dictando las tareas explícitamente: El equipo se organiza por sí mismo en gran parte. </li></ul>
    11. 12. <ul><li>El Product Owner es el único responsable del Product Backlog y de asegurar el valor comercial del trabajo que el equipo realiza. </li></ul><ul><li>Mantiene el Product Backlog y asegura que sea visible a todo el mundo. </li></ul><ul><li>Gracias a él, todo el mundo sabe que tareas tienen la máxima prioridad, con lo que todos las personas implicadas pueden saber en qué se está trabajando. </li></ul><ul><li>Es una sola persona (no un comité ). </li></ul>
    12. 13. <ul><li>Para que el Product Owner tenga éxito, toda la organización debe respetar sus decisiones: </li></ul><ul><ul><li>Nadie tiene permiso para mandar al equipo trabajar con diferentes prioridades. </li></ul></ul><ul><ul><li>De igual manera, el equipo no puede permitir escuchar a otras personas en la organización. </li></ul></ul><ul><ul><li>Por eso es tan importante que el Product Backlog sea visible y que exista un único Product Owner. </li></ul></ul>
    13. 14. <ul><li>Cada Sprint, el equipo transforma el Product Backlog en un incremento del producto final que esta potencialmente listo para una Release . </li></ul><ul><li>Los miembros del equipo deben de tener las habilidades necesarias para crear dicho incremento. </li></ul><ul><li>Aunque sean especialistas en ciertos aspectos (por ejemplo, desarrollador, testeador, administrador de red, etc.), deben de tener la actitud correcta y cuando sea necesario salir de su “zona cómoda”, ser capaces de hacerlo. </li></ul>
    14. 15. <ul><li>Los equipos se auto-organizan: Nadie (ni tan sólo el SCRUM Master) le dice al equipo cómo transformar el Product Backlog en un incremento del producto final que esta potencialmente listo para una Release; el equipo lo decide por sí solo. Las sinergias que se producen en el proceso aumentan la eficiencia y efectividad del equipo. </li></ul><ul><li>El tamaño ideal para un equipo es de siete personas (más – menos dos). Cuando hay menos de cinco, no hay mucha interacción y la productividad se resiente. Cuando el equipo es más grande, es muy complicado de manejar bajo el framework SCRUM. </li></ul>
    15. 16. <ul><li>Iteraciones fijas: Sprint </li></ul><ul><ul><li>Es el “corazón” de SCRUM. </li></ul></ul><ul><ul><li>Dura de 1 mes a 15 días. </li></ul></ul><ul><ul><li>Duración fija durante la vida del proyecto </li></ul></ul><ul><ul><li>Todos los Sprints tienen el mismo ciclo de vida. </li></ul></ul><ul><ul><li>Todos los Sprint acaban con un incremento del producto final que está potencialmente listo para una Release. </li></ul></ul><ul><ul><li>Cada sprint empieza inmediatamente después del anterior. </li></ul></ul>
    16. 17. <ul><li>Durante el Sprint el SCRUM Master tiene que asegurar que no se realicen cambios que afecten a los objetivos del Sprint. La composición del equipo y la calidad del trabajo hecho permanecen constantes durante el Sprint. </li></ul><ul><li>Los Sprints consisten en: </li></ul><ul><ul><li>Reunión de Sprint Planning </li></ul></ul><ul><ul><li>Desarrollo (trabajo) + SCRUM diario </li></ul></ul><ul><ul><li>Reunión de Sprint Review </li></ul></ul><ul><ul><li>Reunión de Sprint Retrospective </li></ul></ul>
    17. 18. <ul><li>En SCRUM, el horizonte temporal del proyecto se reduce a un mes o a quince días (dependiendo de la duración del Sprint); por eso es adecuado para los productos complejos donde un “horizonte temporal más largo sea demasiado peligroso. </li></ul><ul><li>La predictibilidad del proyecto tiene que ser controlada al menos cada mes . </li></ul>
    18. 19. <ul><li>Sólo el Product Owner puede cancelar un Sprint. </li></ul><ul><li>Sólo si el objetivo del Sprint pasa a ser obsoleto. Por ejemplo, por un cambio de estrategia de la compañía, del mercado, etc. Debido a la corta duración del Sprint, casi nunca se da el caso de que deba cancelar un Sprint. </li></ul><ul><li>Las cancelaciones son “traumáticas” y consumen tiempo – Por eso sólo deben de ocurrir en las circunstancias mencionadas anteriormente. </li></ul>
    19. 20. <ul><li>Reuniones </li></ul><ul><ul><li>Reunión de Release Planning </li></ul></ul><ul><ul><li>Reunión de Sprint Planning (kickoff) </li></ul></ul><ul><ul><li>Daily SCRUM (SCRUM diario) </li></ul></ul><ul><ul><li>Reunión de Sprint Review </li></ul></ul><ul><ul><li>Reunión de Sprint Retrospective </li></ul></ul>
    20. 21. <ul><li>En la reunión de Release planning se establece el plan y los objetivos de la Release, además de decidir la estrategia que el equipo SCRUM y el resto de la organización van a seguir. </li></ul><ul><li>Básicamente se trata de contestar a las siguientes preguntas: </li></ul><ul><ul><li>¿ Cómo podemos transformar el objetivo en un producto de calidad, de la mejor manera posible ? </li></ul></ul><ul><ul><li>¿ Cómo podemos dejar al cliente satisfecho y conseguir un buen retorno de nuestra inversión ? </li></ul></ul>
    21. 22. <ul><li>En la mayoría de organizaciones ya existe un proceso para planear Releases , en el que se definen los objetivos generales, que permanecen inalterables durante la vida del proyecto. En el caso de SCRUM, se suele utilizar 15-20% del tiempo que se utiliza en estos otros casos más tradicionales. Esto es porque se realiza planificación just-in-time : En cada Sprint y en cada SCRUM diario. </li></ul><ul><li>Si nos fijamos en los números finales, seguramente finalmente se pasará más tiempo planeando en esta nueva forma de planificación que en la tradicional. </li></ul>
    22. 23. <ul><li>También llamada “reunión de kick-off” para el Sprint, es en esta reunión que se planea la iteración. Se limita a 8 horas por Sprint, dividida en dos partes de 4 horas: </li></ul><ul><ul><li>Durante la primera parte (el ¨ Qué ”) se decide que puntos del Product Backlog se van a trabajar en el Sprint </li></ul></ul><ul><ul><ul><li>El Product Owner presenta el Product Backlog priorizado y junto con el equipo se decide los puntos para el Sprint. Además del Product Backlog, se utilizan como inputs la capacidad y la productividad pasada del equipo. </li></ul></ul></ul>
    23. 24. <ul><ul><li>Durante la segunda (el “ Cómo ”), el equipo decide cómo se van a desarrollar dichos puntos. </li></ul></ul><ul><ul><li>Son (generalmente) 4 horas en las que el equipo discute y decide cómo transformaran l os puntos descritos en el PBL en un incremento del producto listo para el cliente. </li></ul></ul><ul><ul><li>Normalmente se empieza diseñando el trabajo, y al hacerlo, se identifican las tareas. Estas tareas son piezas de trabajo necesarias para convertir las descripciones abstractas del PBL en el producto final. Esta lista de tareas es lo que vamos a llamar Sprint Backlog (SBL). </li></ul></ul>
    24. 25. <ul><li>El Sprint Review tieen lugar al final del Sprint. Limitado a 4 horas para Sprints de 1 mes, en general se estima que no supere el 5% del tiempo del Sprint. </li></ul><ul><li>Se discute con los actores involucrados en el proyecto (stakeholders) sobre lo que se ha realizado, y se discute sobre la dirección del proyecto en un futuro inmediato. Es una reunión informal en el que se presenta la funcionalidad realizada hasta el momento y en el que se fomenta la colaboración. </li></ul>
    25. 26. <ul><li>En general, se sigue un patrón del tipo: </li></ul><ul><ul><li>El Product Owner identifica lo que se ha hecho y lo que no durante el Sprint. </li></ul></ul><ul><ul><li>El equipo discute lo que ha ido bien y los que no, los problemas y cómo se solucionaron. </li></ul></ul><ul><ul><li>El equipo realiza una demostración del trabajo hecho y contesta las posibles preguntas de los stakeholders presentes. </li></ul></ul><ul><ul><li>El Product Owner discute el PBL actual y comenta los próximos milestones teniendo en cuenta las actuales métricas de velocidad del equipo. </li></ul></ul><ul><ul><li>En general, el Sprint Review es muy útil para la próxima reunión de Sprint Planning. </li></ul></ul>
    26. 27. <ul><li>Tiene lugar después del Sprint Review y antes del próximo Sprint Planning, estimado en 3 horas. </li></ul><ul><li>En él, el SCRUM Master alienta al equipo a revisar, dentro el framework SCRUM, los procesos de desarrollo y las prácticas actuales, para hacer que el próximo Sprint sea más productivo y más efectivo para todos. </li></ul><ul><li>El principal propósito de la reunión Retrospective es ver cómo fue el último Sprint en relación a los miembros del equipo, sus relaciones y interacciones, los procesos y las herramientas usadas. </li></ul>
    27. 28. <ul><li>Reunión diaria de 15 minutos, que tiene lugar en el mismo sitio y a la misma hora cada día. Durante la reunión (se aconseja que los miembros estén de pie, y por eso a veces se le llama “ stand up meeting ”), se cada miembro del equipo responde a las tres preguntas siguientes, fundamentales en SCRUM: </li></ul><ul><ul><li>En qué ha estado trabajando desde el último SCRUM diario. </li></ul></ul><ul><ul><li>En qué va a trabajar hasta el próximo SCRUM diario. </li></ul></ul><ul><ul><li>Qué obstáculos (si los hay) tiene para realizar dicho trabajo. </li></ul></ul>
    28. 29. <ul><li>La reunión diaria de SCRUM mejora las comunicaciones entre el equipo, eliminando la necesidad de muchos otras reuniones. Sirve para identificar y eliminar obstáculos que impiden el avance en el desarrollo, hace patente la necesidad de tomar decisiones rápidas y homogeniza el nivel de conocimiento sobre el estado del proyecto entre todos los miembros del equipo. </li></ul><ul><li>El SCRUM Master es el responsable de … </li></ul><ul><ul><li>Asegurar que la reunión tiene lugar </li></ul></ul><ul><ul><li>Conducir la reunión (la gente sea breve, todo el mundo hable, etc.) </li></ul></ul><ul><ul><li>Asegurar que las “gallinas” no hablen en la reunión ni interfieran en ella </li></ul></ul>
    29. 30. <ul><li>Artifacts </li></ul><ul><ul><li>Product Backlog: Lista prioritizada de todo aquello que es necesario para completar el proyecto. </li></ul></ul><ul><ul><li>Sprint Backlog: Lista de tareas que transforman el Product Backlog para 1 Sprint en un incremento del producto final que esta potencialmente listo para una Release. </li></ul></ul><ul><ul><li>Gráficos de Burndown (Release burndown o Sprint burndown): Medidas del tiempo restante en la Release / Sprint. Mide los ítems restantes a través del tiempo de una Release / Sprint. </li></ul></ul>
    30. 31. <ul><li>El Product Backlog contiene los requerimientos para el producto que el equipo va a desarrollar. </li></ul><ul><li>El Product Backlog es responsabilidad única y exclusivamente del Product Owner. Se encarga no sólo de su contenido, sino de su disponibilidad, visibilidad y priorización. </li></ul><ul><li>El Product Backlog nunca está completo; evoluciona a medida que el producto y el entorno donde dicho producto se enmarca evolucionan. Es dinámico, y siempre debe asegurar que el producto desarrollado sea apropiado, competitivo y útil. </li></ul><ul><li>Mientras el producto exista, el Product Backlog existe. </li></ul>
    31. 32. <ul><li>Representa todo aquello necesario para desarrollar y lanzar un producto con éxito: </li></ul><ul><ul><li>Funciones, tecnologías, modificaciones, mejoras, resolución de defectos, etc. </li></ul></ul><ul><li>Cada punto del Product Backlog debe tener: </li></ul><ul><ul><li>Descripción </li></ul></ul><ul><ul><li>Prioridad </li></ul></ul><ul><ul><ul><li>Depende del riesgo, valor aportado y necesidad </li></ul></ul></ul><ul><ul><li>Estimación (preliminar) </li></ul></ul><ul><ul><ul><li>Calculada inicialmente durante la reunión de Release Planning, y refinadas a medida que el mismo Producto Backlog es revisado. </li></ul></ul></ul><ul><ul><ul><li>Responsabilidad del equipo. </li></ul></ul></ul><ul><li>Está ordenado por prioridad, determinando así las actividades de desarrollo inmediatas. </li></ul>
    32. 33. <ul><li>Consiste en las tareas que el equipo reqliza durante 1 Sprint para transformar los requerimientos del Product Backlog en un incremento acabdo. </li></ul><ul><li>Las tareas deben de ser simples. </li></ul><ul><li>El equipo es el encargado de actualizar el Sprint Backlog . Puesto que las tareas son unidades pequeñas (tareas simples), es posible que acaben apareciendo tareas nuevas o algunas desaparezcan durante el Sprint. </li></ul><ul><li>El Sprint Backlog es una imagen a tiempo real del trabajo que el quipo planea acabar durante un Sprint, y es propiedad exclusiva de éste equipo. </li></ul>
    33. 34. <ul><li>El gráfico Sprint Backlog Burndown muestra la cantidad de trabajo aún por realizar en un Sprint. </li></ul><ul><li>Se crea sumando las estimaciones del tiempo del Sprint Backlog aún por hacer, cada día. </li></ul><ul><li>Es un gráfico de línea, con el que el equipo mide la evolución para completar un Sprint. Sólo se consideran dos variables: </li></ul><ul><ul><li>Trabajo aún por realizar </li></ul></ul><ul><ul><li>Fecha </li></ul></ul><ul><li>El gráfico Release Burndown suma el tiempo aún por realizar del Product Backlog. Las unidades de tiempo suelen ser Sprints. </li></ul>
    34. 35. <ul><li>Hemos visto los elementos de SCRUM que se pueden considerar como “reglas”, pensadas para dar coherencia al desarrollo de un proyecto. </li></ul><ul><li>Pero, de todas formas, las reglas son muy flexibles y cuando el equipo se encuentra en una situación que los elementos anteriores no cubren explícitamente, SCRUM aboga por usar la creatividad y encontrar una forma nueva… usando el método empírico, que es el corazón mismo de SCRUM. </li></ul><ul><ul><li>Inspección - Adaptación </li></ul></ul>
    35. 36. <ul><li>3 puntos de inspección / adaptación: </li></ul><ul><li>Daily SCRUM – Inspeccionamos el progreso del Sprint y hacemos adaptaciones para el siguiente día de trabajo. </li></ul><ul><li>Sprint Review – Inspeccionamos el progreso hacia la Release y hacemos adaptaciones para el siguiente Sprint. </li></ul><ul><li>Sprint Retrospective – Inspeccionamos el pasado Sprint y hacemos adaptaciones para mejorar el siguiente. </li></ul>
    36. 37. <ul><li>Como hemos visto, SCRUM se basa en entregar incrementos del producto final, potencialmente listos para una Release, al final de cada Sprint. </li></ul><ul><li>Es decir, estos incrementos deben de ser estar “acabados” – el cliente podría usarlos si así lo requiriera. </li></ul><ul><li>Cada incremento debe de aportar nueva funcionalidad respecto a Sprints anteriores, y debe de estar completamente probado (asegurando que todos los incrementos acabados hasta la fecha funcionan). </li></ul>

    ×