O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Introducción al Marco de Trabajo Scrum

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 65 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Introducción al Marco de Trabajo Scrum (20)

Anúncio

Mais recentes (20)

Introducción al Marco de Trabajo Scrum

  1. 1. Introducción al Marco de TrabajoIntroducción al Marco de Trabajo SCRUMSCRUM
  2. 2. AgendaAgenda Marco de Trabajo SCRUM Introducción al Marco de Trabajo Scrum:Introducción al Marco de Trabajo Scrum: (a) Introducir a los participantes en el mundo del Desarrollo Ágil (Agile) (b) Presentar los principios y prácticas para la gestión ágil y evolutiva de proyectos, a través del marco de trabajo SCRUM: roles, artefactos y eventos. ContenidosContenidos: ● Metodologías Ágiles de Desarrollo de Software: ● Metodologías Ágiles vs. Tradicionales ● Marco de Trabajo Scrum
  3. 3. Introducción A pesar del carácter estratégico de los sistemas informáticos, para garantizar el cumplimiento de la Misión, Visión, y Objetivos de cualquier organización pública o privada, frecuentemente la gestión de los proyectos de desarrollo de software, se ve afectada por diversas problemáticas como las siguientes: ● No se adaptan a los cambios. ● Calidad insuficiente y muy variable. ● Proyectos que exceden sus tiempos y costos.
  4. 4. Introducción Con base en lo anterior se ha llegado a un acuerdo de lo que significa un proyecto de software exitoso, en tres dimensiones: • A tiempo. • En presupuesto. • Cumpliendo el alcance definido (incluye adaptabilidad a los cambios y calidad).
  5. 5. Metodologías Ágiles de Desarrollo de Software: Principios ● Durante el transcurso de los años 90 el ambiente cambiante y turbulento era cada vez más la regla que la excepción. Por lo tanto surgió la necesidad de desarrollar metodologías livianas y maniobrables que pudieran operar en ese ambiente turbulento. Estas metodologías son conocidas colectivamente hoy en día como “metodologías ágiles”. ● Se entiende como Desarrollo ágil de Software a un paradigma de Desarrollo de Software basado en procesos ágiles.
  6. 6. Metodologías Ágiles de Desarrollo de Software: Principios ● Lo ágil se define como la habilidad de responder de forma versátil al cambio para maximizar los beneficios. ● Las metodologías ágiles varían en su forma de responder al cambio, pero en general comparten las siguientes características: – Los individuos y sus interacciones son más importantes que los – procesos y las herramientas. – El software que funciona es más importante que la documentación exhaustiva. – La colaboración con el cliente en lugar de la negociación de Contratos. – La respuesta al cambio en lugar de aferrarse a un plan.
  7. 7. Metodologías Ágiles de Desarrollo de Software: Alianza Ágil ● En una reunión celebrada en febrero de 2001 en Utha (EEUU), con la participación de un grupo de 17 expertos de la industria del software, nace el término “ágil” aplicado al desarrollo de software. ● Su objetivo fue esbozar los valores y principios que debían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que pueden surgir a lo largo del proyecto. ● Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas.
  8. 8. Metodologías Ágiles de Desarrollo de Software: Alianza Ágil ● Tras esta reunión se creó “The Alliance”, una organización dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que los adopten. ● El punto de partida fue el Manifiesto Ágil, un documento que resume la filosofía ágil.
  9. 9. Metodologías Ágiles de Desarrollo de Software: El Manifiesto Ágil ● Individuos e interacciones sobre procesos y herramientas ● Software que funciona sobre documentación exhaustiva ● Colaboración con el cliente sobre negociación de contratos ● Responder ante el cambio sobre seguimiento de un plan 
  10. 10. Metodologías Ágiles vs. Tradicionales Metodologías Ágiles Metodologías Tradicionales La planificación del trabajo sólo comprende el ciclo en el que se está trabajando (normalmente 30 días). Trabajo y gestión guiada por un plan general del proyecto que comprende todo su ciclo de desarrollo. Descubrimiento progresivo de requisitos, e incorporación de cambios en cualquier iteración del desarrollo. Conocimiento detallado de los requisitos antes de comenzar el diseño del proyecto. “Refactorización” de código como modelo de trabajo compatible con el punto anterior “Hacerlo bien a la primera”. Evitar la re-codificación y el re-trabajo que supone una pérdida de eficiencia Comunicación directa entre los integrantes del equipo (incluido cliente). Comunicación formal según el plan de comunicación del proyecto. Equipos auto-gestionados. Gestión de equipos centralizada No existe contrato tradicional Existe un contrato prefijado. El cliente es parte del equipo de desarrollo. El cliente interactúa con el equipo de desarrollo mediante reuniones. Pocos artefactos y roles Más artefactos y roles Menos énfasis en la arquitectura del software. La arquitectura del software es esencial y se expresa mediante modelos.
  11. 11. Metodologías Ágiles vs. Tradicionales
  12. 12. Metodologías Ágiles vs. Tradicionales
  13. 13. SCRUM: Introducción La palabra SCRUM procede del vocabulario del rugby y significa melé; es decir, que los compañeros del equipo se amontonan, forman una piña y empujan todos en la misma dirección.
  14. 14. SCRUM: Introducción ● SCRUM es un modelo de desarrollo ágil caracterizado por: – Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto. – Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto-organizados, que en la calidad de los procesos empleados. – Solapamiento de las diferentes fases del desarrollo, en lugar de realizarlas una tras otra en un ciclo secuencial o de cascada. – Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986) ● SCRUM está pensado en un desarrollo de software en un proceso iterativo e incremental es decir nos va a dar las pautas para gestionar a las personas que realizaran el trabajo. ● Reduce al máximo la burocracia y actividades no orientadas a producir software que funcione y produce resultados en periodos muy breves de tiempo (cada 30 días), por medio de iteraciones o Sprints. ● Ideal para proyectos con un rápido cambio de requerimientos.
  15. 15. SCRUM: Introducción ● Los principales atributos de SCRUM son: – Un enfoque orientado a que los equipos desarrollen sistemas y productos de manera iterativa e incremental cuando los requerimientos cambian de manera rápida. – Un proceso que controla el caos de conflictos de intereses y necesidades – Una manera de mejorar las comunicaciones y maximizar la cooperación – Una manera de maximizar la productividad – Escalable a múltiples proyectos y toda la organización – Una forma que todos se sientan bien con su trabajo, entendiendo que cada uno con sus contribuciones hizo lo mejor que podía hacer – SCRUM está basado en el control empírico de procesos. Se utiliza cuando la capacidad de predicción es vaga, la incertidumbre alta o el proceso es demasiado complejo para ser modelado y definido.
  16. 16. Marco de Trabajo SCRUM Contexto Sólo abarca prácticas de gestión sin entrar en las prácticas de desarrollo. Delega completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo más productivos posibles y, le da gran protagonismo a las reuniones que realicen a lo largo del proyecto. Sus raíces teóricas están en las teorías de la auto-organización.
  17. 17. Marco de Trabajo SCRUM : Componentes
  18. 18. Marco SCRUM Técnico
  19. 19. Roles de SCRUM ● Responsable de la Pila de Producto y su correcta priorización ● Prioriza funcionalidades ● Puede cambiar la funcionalidad y prioridades para cada sprint (pero no durante el mismo) ● Acepta o rechaza los resultados del sprint ● Responsabilidad del producto ● El PO aporta la visión general que el cliente ha transmitido, y desglosa las historias de usuario en tareas. Dueño del Producto / Product Owner (PO)
  20. 20. Roles de SCRUM ● Formación y entrenamiento de procesos ● Incorporación de Scrum en la cultura del equipo ● Garantía de cumplimiento de roles y responsabilidades ● Remueve impedimentos ● Facilitador ● Asegura que se cumpla Scrum Scrum Master (Facilitador):
  21. 21. Roles de SCRUM ● Auto – gestionado ● Auto – organizado ● Multifuncional ● Transforman los requerimientos en funcionalidad en cada incremento Equipo Scrum (5 a 9 personas)
  22. 22. Roles de SCRUM: Cerdos y Gallinas ● Hay dos categorías: – Cerdos (comprometidos con el proceso) – Gallinas (no son parte del proceso pero hay que considerarlos). ● Un cerdo y un gallina se encuentran por la calle:
  23. 23. Roles de SCRUM: Cerdos y Gallinas ● Roles de cerdo: (parte del proceso) – Scrum Master (el facilitador del Scrum, asegura y guía en el proceso Scrum, quita escollos). – Dueño del producto (representa la voz del cliente) – Miembros del equipo Scrum (responsables de crear el producto) ● Roles gallina: (no son parte del proceso) – Usuarios (quienes utilizarán el producto) – Stakeholders (clientes y aquellos que permiten que exista – el proyecto) – Gerentes (administradores de la administración)
  24. 24. Proceso SCRUM
  25. 25. Ciclo SCRUM Pila de producto -- Requisitos priorizados. -- Listado con los requisitos del sistema. Selección de la Pila de producto (Product Backlog) -- Funcionalidades Pila del sprint Nueva Funcionalidad • Dueño del Producto (modificar cuidando la inversión). • Stakeholders (usuario, soporte técnico, administradores, etc )
  26. 26. Los “Sprint” / Iteraciones ● Un Sprint es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad y su duración está entre 2-4 semanas. ● Dentro de cada Sprint, Scrum gestiona la evolución del proyecto mediante reuniones breves de seguimiento diarias en las que se revisa el trabajo realizado desde el hito anterior y los planes para el hito siguiente.
  27. 27. Los “Sprint” / Iteraciones ● Durante el Sprint NO se puede modificar el trabajo que se ha acordado en el Backlog. ● Sólo es posible cambiar el curso de un Sprint, abortándolo, y sólo lo puede hacer el Scrum Master si decide que no es viable por alguna de las razones siguientes: – La tecnología acordada no funciona. – Los circunstancias / objetivos / prioridades han cambiado. – El equipo ha tenido interferencias. ● Se planifica en detalle el trabajo al inicio de cada Sprint asumiendo que los objetivos no van a cambiar durante el mismo. De esta manera se atenúa el riesgo.
  28. 28. Los “Sprint” / Iteraciones
  29. 29. Artefactos SCRUM ● El primer paso en la estimación y planificación ágil es la creación de la Pila del Producto / Backlog, o sea la definición del proyecto a realizar. ● La pila del producto es la lista ordenada de todo aquello que esperan el cliente, los usuarios, y en general los interesados. ● Constituye el listado con la estimación inicial de los requisitos de los usuarios o propietarios del sistema para planificar el proyecto. ● Es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de los sucesivos sprints Backlog del Producto – Pila de Producto:
  30. 30. Artefactos SCRUM ● La pila del producto nunca se da por completada; está en continuo crecimiento y evolución. ● Al comenzar el proyecto incluye los requisitos inicialmente conocidos y mejor entendidos, y evoluciona conforme avanza el desarrollo ● Gracias a su carácter dinámico, refleja aquello que el producto necesita incorporar para adecuarse a las circunstancias, en todo momento. ● El propietario del producto mantiene la pila ordenada por la prioridad de los elementos, siendo los más prioritarios los que confieren mayor valor al producto, o por alguna razón resultan más necesarios, y determinan las actividades de desarrollo inmediatas Backlog del Producto – Pila de Producto:
  31. 31. Artefactos SCRUM ● Se denomina “preparación” (grooming) de la pila del producto a las actividades de priorización, detalle y estimación de los elementos que la componen. ● Es un proceso que realizan de forma puntual, en cualquier momento, continua y colaborativa el propietario del producto y el equipo de desarrollo. ● Otras personas aparte del Dueño de Producto pueden añadir elementos a la Pila de Producto. No obstante, no pueden asignarles niveles de importancia. ● No debe consumir más del 10% de la capacidad de trabajo del equipo. ● La responsabilidad de estimar el esfuerzo previsible para cada elemento, es de las personas del equipo que previsiblemente harán el trabajo. Preparación de la Pila del Producto:
  32. 32. Artefactos SCRUM ● Una historia de usuario (user storie) es una representación de un requisito escrito por el usuario final en lenguaje común (se plasma lo que el cliente quiere, como lo quiere y para que lo quiere), con el fin de que el equipo que va a trabajar pueda comprender con claridad la necesidad y su prioridad). ● Las historias de usuario están divididas en dos apartados diferentes: el enunciado y los criterios de aceptación (de gran relevancia para estimar el esfuerzo y realizar las pruebas de validación). ● Las historias de usuario se construyen bajo un mismo esqueleto que centra el foco de las características del producto. ● Primero se determina quién propone la historia de usuario, ● luego se describe la característica que se cubre con la historia de usuario y ● finalmente se especifica la razón por la que dicha característica es necesaria. Elementos de la Pila del Producto → Historias de Usuario:
  33. 33. Artefactos SCRUM ● Las Historias de Usuario deben cumplir las siguientes características: – Independientes. Deben ser atómicas en su definición. Es decir, se debe intentar que no dependa de otras historias para poder completarla. – Negociables. Son entidades vivas. Deben ser ambiguas en su enunciado para poder debatirlas, dejando su concreción a los criterios de aceptación. – Valoradas. Deben ser valoradas por el cliente. Para poder saber cuanto aporta al Valor de la aplicación y junto con la estimación convertirse en un criterio de prioridad. – Estimables. Tener su alcance lo suficientemente definido como para poder suponer una medida de trabajo en la que pueda ser completarla. – Pequeñas. Para poder realizar una estimación con cierta validez y no perder la visión de la Historia de Usuario, se recomienda que sean mayores de dos días y menores de dos semanas. – Verificables. Este es el gran avance de las Historias de Usuario. Que, junto con el cliente, se acuerdan unos Criterios de Aceptación que verifican si se ha cumplido con las funcionalidades descritas y esperadas Historias de Usuario:
  34. 34. Artefactos SCRUM Historias de Usuario:
  35. 35. Artefactos SCRUM Pila de Producto:
  36. 36. Artefactos SCRUM Pila de Producto: Listado con los requisitos del sistema. Listado de todas las a implementar. Es dinámico. Mientras exista un producto, existirá la Pila del Producto también existe.
  37. 37. Artefactos SCRUM ● Los criterios de aceptación, son el mecanismo por el cual se define si una historia de usuario fue desarrollada según la expectativa del Dueño del Producto (como representante de los criterios del cliente) y se si puede dar como hecha (done). Su uso aporta muchas ventajas, las que me parecen más importantes: – Fomentan la comunicación entre Dueño del Producto y equipo para aclarar las expectativas – Ayudan en la estimación de la historia al imponerle límites. – Garantizan que el trabajo realizado será lo solicitado por el Dueño del Producto. – Reducen las necesidad de hacer consultas al PO durante el sprint, con la consiguiente pérdida de productividad del equipo y del PO. – Sirven de guía para el desarrollo de las pruebas. Deben cubrir los casos de uso positivos o comunes (el trayecto feliz) pero también las excepciones o “corner case” Historias de Usuario → Criterios de Aceptación:
  38. 38. Artefactos SCRUM ● Un criterio de aceptación es el mecanismo por el cual se define si una historia de usuario fue desarrollada según la expectativa del Dueño del Producto (como representante de los criterios del cliente) y se si puede dar como hecha. ● Ayudan al equipo de desarrollo a entender mejor cómo se espera que el producto se comporte (expectativas claras) y facilita la estimación de la historia. ● Sirven de guía para el desarrollo de los test. Deben cubrir los casos de uso positivos o comunes (el trayecto feliz) pero también las excepciones o “corner case” ● Las calidades de un criterio de aceptación eficaz se definen bajo el método SMART. SMART significa Specific (Especifico), Measurable (Medible), Achievable (Alcanzable), Relevant (Relevante) y Time-bound (Temporalmente limitado). Historias de Usuario → Criterios de Aceptación:
  39. 39. Artefactos SCRUM ● La pila del sprint (sprint Backlog) es la lista de las tareas necesarias para construir las historias de usuario que se van a realizar en un sprint. ● La construye el equipo en la reunión de planificación del sprint, indicando para cada tarea el esfuerzo previsto para realizarla. ● La pila del sprint descompone las historias de usuario en unidades de tamaño adecuado para hacer seguimiento del avance a diario, e identificar riesgos y problemas sin necesidad de procesos de gestión complejos. ● Es también una herramienta para la comunicación visual directa del equipo. ● Al final del sprint se busca un incremento en la funcionalidad. Backlog del Sprint – Pila de Sprint:
  40. 40. Artefactos SCRUM ● Realizada de forma conjunta por todos los miembros del equipo. ● Cubre todas las tareas identificadas por el equipo para conseguir el objetivo del sprint. ● Sólo el equipo la puede modificar durante el sprint. ● Las tareas demasiado grandes deben descomponerse en otras más pequeñas. ● Es visible para todo el equipo. Idealmente en un tablero o pared en el mismo espacio físico donde trabaja el equipo. Pila del Sprint - Condiciones:
  41. 41. Artefactos SCRUM ● Son soportes habituales: – Tablero físico o pared. – Hoja de cálculo. – Herramienta colaborativa o de gestión de proyectos. ● Y sobre el más adecuado a las características del proyecto, oficina y equipo, lo apropiado es diseñar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios: – Incluir la siguiente información: Pila del Sprint, persona responsable de cada tarea, estado en el que se encuentra y tiempo de trabajo que queda para completarla. – Incluir sólo la información estrictamente necesaria. – Debe servir de medio para registrar en cada reunión diaria del sprint, el tiempo que le queda a cada tarea. – Facilitar la consulta y la comunicación diaria y directa del equipo. Pila del Sprint – Formatos y Soporte:
  42. 42. Artefactos SCRUM Backlog del Sprint – Pila de Sprint:
  43. 43. Artefactos SCRUM Un Panel de Scrum, funciona como un radiador de información, allí podemos encontrar como van esas dos semanas de trabajo del equipo, más que como va el proyecto, como se mencionó anteriormente lo importante no es el proceso, son las personas y las iteraciones, de esa forma en el Panel. Panel de SCRUM:
  44. 44. Artefactos SCRUM Gráfica de Avance (Burn-Down): ● En esta gráfica podemos encontrar cuando la persona tiene que acabar cierta tarea, la idea es visualizar cuando se acaban las tareas. ● Al principio se lleva un consenso es decir un punto son 8 horas o un día pero se interioriza inmediatamente.
  45. 45. Artefactos SCRUM
  46. 46. Artefactos SCRUM Incremento: ● El incremento es la parte de producto es la parte de producto realizada en un sprint potencialmente entregable: terminada y probada ● No se deben considerar como Incremento a prototipos, módulos o sub-módulos, ni partes pendientes de pruebas o integración. Idealmente en Scrum: ● Se produce un “incremento” en cada iteración. ● Cada elemento de la pila del producto se refiere a funcionalidades entregables, no a trabajos internos del tipo “diseño de la base de datos”.
  47. 47. Eventos: Reuniones en SCRUM
  48. 48. Eventos: Reuniones en SCRUM ● Reunión para Planificar el Sprint (Planning Meeting) (Planificación): ● Reunión Diaria (Daily Scrum) (Sincronización) ● Reunión de Revisión del Sprint (Sprint Review Meeting) (Revisión) ● Retrospectiva del Sprint (Sprint Retrospective) (Retrospectiva)
  49. 49. Eventos: Reuniones en SCRUM
  50. 50. Eventos: Reuniones en SCRUM Reunión de Planificación de Sprint:
  51. 51. Eventos: Reuniones en SCRUM Reunión de Planificación de Sprint:
  52. 52. Reunión de Revisión de Sprint → Seguimiento (Demo) Lista de comprobación para demos de Sprint: ● Asegurarse de presentar claramente el objetivo del Sprint. Si hay personas en la demo que no saben nada sobre tu producto, tomar un par de minutos para describirlo. ● No perder mucho tiempo preparando la demo, especialmente en llamativas presentaciones. Concentrase en mostrar código funcionando. ● Concentrar la preparación en hacer que la demo sea rápida en lugar de bonita. ● Mantener la demo a nivel de negocio, dejar los detalles técnicos aparte. ● Concentrarse en “qué hemos hecho” en lugar de “cómo lo hemos hecho”. ● En la medida de lo posible, dejar que la audiencia pruebe el producto por si misma. ● No mostrar un montón de pequeños errores solucionados y funcionalidades triviales. Mencionarlos, pero no los mostrarlos, ya que normalmente se tarda mucho y desvía la atención de las historias más importantes.
  53. 53. Estimaciones en SCRUM Las estimaciones se realizan por primera vez en la reunión de planificación al inicio del Sprint y se revisan a diario, registrando sus cambios en el Backlog del Sprint; esta actividad puede ser realizada inmediatamente antes o después del Scrum diario. Para ello se recomienda: ● Estimar el esfuerzo, en lugar de la duración. ● Estimar el esfuerzo total pendiente para terminar la tarea; no se estima el esfuerzo consumido (Burn-Down). ● Se buscan unidades manejables, lo usual es que estén en un mínimo de 2 horas y un máximo de 20.
  54. 54. Estimaciones en SCRUM: “Planning Pocker” ● El objetivo del planning poker (póker de planificación) es obtener una medida de tamaño relativo de todas las historias respecto a sí mismas ● Se planifica con todo el equipo y una baraja de cartas llamada Planning Poker, que sigue una seudo distribución de Fibonacci de la siguiente forma tenemos el 1, 2, 3, 5, 8, 13, 20,40 y 100 por que Scrum quiere dar la sensación de que se realiza una estimación ● Al efectuar el planning poker sobre todo el backlog, da como resultado que todas las historias han sido estimadas con muy poco esfuerzo en una medida llamada story points o “puntos de historia” (no en base a tiempo).
  55. 55. Estimaciones en SCRUM: “Planning Pocker”
  56. 56. Priorización en SCRUM ● La etapa de priorización es sencilla y depende exclusivamente del Product Owner. Sabiendo ya el tamaño de las historias, debe priorizarlas por valor que agreguen a a la misión, visión y objetivos estratégicos de la organización y su entorno. ● La priorización se realiza balanceando el valor respecto al costo y respecto a los riesgos de cada objetivo. ● La prioridad puede cambiar todo el tiempo; pero el tamaño en story points debe mantenerse fijo con la estimación original (o sea: como regla general, no reestimar)
  57. 57. Reuniones en SCRUM Su propósito, es fomentar el intercambio de comunicación, se tratan temas como ¿qué hiciste ayer?, ¿qué vas a hacer hoy?, ¿qué impedimentos tienes?, con el fin de detectar los posibles errores u obstáculos y para llevar actualizado el panel. Para ello se recomienda: ● Realizarla cada día en el mismo sitio y a la misma hora, con una duración máxima de 15 minutos y se siguiere sea la primera actividad del día. ● Deben acudir todos los miembros del equipo. ● Qué exista contacto visual entre todos los participantes y manteniendo el foco y el orden. Reunión Diaria / Scrum Diario:
  58. 58. Eventos: Reuniones en SCRUM Reunión de Revisión de Sprint: ●Análisis y revisión del incremento generado ●Constituye la presentación de resultados del equipo Planificación Revisión (máximo 4 horas)
  59. 59. Reuniones en SCRUM Reunión de Revisión de Sprint: ● Reunión del equipo, Scrum Master, Poduct Owner (PO), con todos los roles gallina ● Duración máxima: 4 horas (2h. recomendado) ● Objetivo: Presentar al Propietario del producto y a las gallinas las funcionalidades implementadas. ● Presentación de producto terminado ● Todo el equipo participa ● Propuesta modificaciones en el Blacklog por PO
  60. 60. Reuniones en SCRUM Reunión de Revisión de Sprint: Lista de comprobación para demos de Sprint: ● Presentar claramente el objetivo del Sprint. Si hay personas en la demo que no saben nada sobre tu producto, tomar un par de minutos para describirlo. ● Evitar hacer presentaciones llamativas. Concentrarse en mostrar código funcionando. ● Concentrar la preparación en hacer que la demo sea rápida en lugar de bonita. ● Mantener la demo a nivel de negocio, dejar los detalles técnicos aparte. ● Concentrarse en “qué hemos hecho” en lugar de “cómo lo hemos hecho”. ● En la medida de lo posible, dejar que la audiencia pruebe el producto por si misma. ● No mostrar un montón de pequeños errores solucionados y funcionalidades triviales. Mencionarlos, pero no los mostrarlos, ya que normalmente se tarda mucho y desvía la atención de las historias más importantes.
  61. 61. Reuniones en SCRUM Reunión de Retrospectiva de Sprint: Buscan detectar los puntos positivos y negativos del Sprint para generar propuestas de mejora para futuros Sprints. ● Todos los miembros del equipo responden a dos preguntas: ✔ ¿Qué cosas se realizaron con éxito en el último Sprint? ✔ ¿Qué cosas se podrían mejorar? ● El Scrum Master anota todas las respuestas. ● El equipo prioriza las mejoras posibles. ● El Scrum Master no proporciona respuestas, sino que ayuda al equipo a encontrar la mejor forma de trabajar con Scrum. ● Las acciones de mejora localizadas que se puedan implementar en el próximo Sprint deben introducirse en el Backlog como elementos no funcionales.
  62. 62. Proceso de Desarrollo SCRUM ● Se utiliza un proceso ágil iterativo e incremental que respeta las cinco etapas tradicionales de un proyecto que facilitan su gestión y control; ellas son: planificación, análisis, diseño, construcción y prueba, e implementación. ● Se definen, en forma clara, los entregables de cada etapa y el alcance global, reflejando estos puntos en la planificación de todas las tareas involucradas ● Este tipo de proceso de desarrollo permite hacer entregas parciales que se van complementando según avanza el proyecto.
  63. 63. Información y Recursos ● Libro Scrum Manager Guía de formación Versión 2.6 – Julio 2016 - (http://www.scrummanager.net/bok/) ● Open Knowledge Scrum (http://www.scrummanager.net/oks/) ● Blog (http://www.scrummanager.net/blog/) ● Acerca de la certificación Scrum Manager®. (http://www.scrummanager.net/certificacion) ● Preguntas frecuentes sobre cursos y exámenes Scrum Manager® (http://www.scrummanager.net/faq-formacion- scrum-manager)
  64. 64. Información y Recursos ● Twitter. (https://twitter.com/scrummanager) ● Facebook. https://www.facebook.com/Scrum-Manager-144889095527292/ ● Google+ (https://google.com/+ScrummanagerNet/) ● Pinterest (https://es.pinterest.com/scrummanager/pins/) ● Grupo profesional en LinkedIn (http://www.linkedin.com/e/gis/855957) ● Comunidades Google + (https://plus.google.com/communities/116174698722878580028)

×