Scrum trainer freddy vargas clase 3

1. SCRUM

2. Temario 4. Fases de Scrum 4.1. Inicio 4.2. Plan y estimación 4.3. Implementación 4.4. Revisión y retrospectiva 4.5. Lanzamiento 5. Escalando Scrum 5.1. Escalabilidad de Scrum 5.2. Scrum in programas y portfolios 5.3. Reuniones de Scrum de Scrums (SoS) 5.4. Transición a Scrum 5.5. Trazo de las funciones tradicionales de Scrum 5.6. Mantener involucrados a los socios 5.7. Importancia del apoyo ejecutivo 1. Descripción de Agile 1.1. El surgimiento de Agile 1.2. El manifiesto de Agile 1.3. Principios del manifiesto de Agile 1.4. Declaración de interdependencia 1.5. Métodos de Agile 1.6. Agile vs. TM 2. Descripción de Scrum 2.1. Principios de Scrum 2.2. Aspectos de Scrum 2.3. Procesos de Scrum 2.4. Ventajas de Scrum 3. Scrum Roles 3.1. Funciones de Scrum 3.1.1. Propietario del producto 3.1.2. Scrum Master 3.1.3. Equipo de Scrum 3.2. Funciones no central

3. 2. Descripción de SCRUM

4. 2. Descripción de Scrum 2.1. Principios de Scrum 2.2. Aspectos de Scrum 2.3. Procesos de Scrum 2.4. Ventajas de Scrum

5. 2.1 Principios de Scrum

6. Orígenes de Scrum • Jeff Sutherland • Scrums iniciales en Easel Corp en 1993 • IDX 500 personas haciendo Scrum • Ken Schwaber • ADM • Se presenta Scrum en OOPSLA 96 con Sutherland • Autor de tres libros sobre Scrum • Mike Beedle • Patrones Scrum en PLOPD4 • Ken Schwaber and Mike Cohn • Fundaron conjuntamente la Scrum Alliance en 2002, inicialmente dentro de la Agile Alliance

7. Introducción a SCRUM • 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. • SCRUM es una estrategia de gestión donde se aplican de manera regular un conjunto de prácticas para mejorar el trabajo colaborativo y obtener el mejor resultado posible en la gestión de un proyecto software.

8. • Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo. • Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes). • El negocio fija las prioridades. Los equipos se auto- organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad. • Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorandolo en otro sprint. Scrum en 100 palabras

9. SCRUM Es un marco de trabajo Existen una serie de roles Se marcan una serie de eventos Es un conjunto de buenas prácticas para desarrollar software de una manera iterativa.

10. Scrum ha sido utilizado por: •Microsoft •Yahoo •Google •Electronic Arts •High Moon Studios •Lockheed Martin •Philips •Siemens •Nokia •Capital One •BBC •Intuit •Intuit •Nielsen Media •First American Real Estate •BMC Software •Ipswitch •John Deere •Lexis Nexis •Sabre •Salesforce.com •Time Warner •Turner Broadcasting •Oce

11. Scrum ha sido utilizado para: • Software comercial • Desarrollos internos • Desarrollos bajo Contrato • Proyectos Fixed-price • Aplicaciones Financieras • Aplicaciones certificadas ISO 9001 • Sistemas Embebidos • Sistemas con requisitos 7x24 y 99.999% de disponibilidad • Joint Strike Fighter • Desarrollo de video juegos • Sistemas críticos de soporte vital, aprobados por laFDA • Software de control satelital • Sitios Web • Software para Handheld • Teléfonos portátiles • Aplicaciones de Network switching • Aplicaciones de ISV • Algunas de las más grandes aplicaciones en uso

12. Características • Equipos auto-organizados • El producto avanza en una serie de “Sprints" de dos semanas a un mes de duración • Los requisitos son capturados como elementos de una lista de “Product Backlog" • No hay prácticas de ingeniería prescritas • Utiliza normas generativas para crear un entorno ágil para la entrega de proyectos • Uno de los “procesos ágiles”

13. Principios de SCRUM Ahora vamos a ver los 6 principios clave de SCRUM • 1. Control de Proceso Empírico • 2. Auto-Organización • 3. Colaboración • 4. Priorización basada en valor • 5. Tiempo Definido • 6. Desarrollo iterativo

14. Control de Proceso Empírico “CONTROL DE PROCESO EMPIRICO” El cual esta basado en las ideas de • · Transparencia • · Inspección • · Adaptación

15. Transparencia Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado. La transparencia requiere que dichos aspectos sean definidos por un estándar común, de tal modo que los observadores compartan un entendimiento común de lo que se están viendo

16. Inspección Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso hacia un objetivo para detectar variaciones indeseadas. Su inspección no debe ser tan frecuente como para que interfiera en el trabajo. Las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos en el mismo lugar de trabajo.

17. Adaptación Uno de los tres pilares del control del proceso empírico; la retroalimentación se usa para hacer un ajuste al producto de trabajo que se está desarrollando o al proceso por el cual se está desarrollando.

18. LOS EVENTOS DE SCRUM

19. SPRINT • El corazón de Scrum. • Duración máxima de 1 mes. • Es el contenedor de los demás eventos. • Consiste en: Sprint planning, Daily meeting, Sprint review y Sprint retrospective. • La cancelación de un Sprint solo la puede hacer el Product Owner.

20. SPRINT PLANNING • Se define el trabajo a realizar, debe participar todo el equipo entero. • Para un sprint de 1 mes, la duración es de 8 horas. • Se eligen las tareas del product backlog siguiendo las siguientes normas: • ¿Qué se va a hacer en el sprint? • ¿cómo lo vamos a hacer? • El resultado es un sprint backlog y un sprint goal.

21. DAILY MEETING • Dura 15 minutos o menos. • Debe participar si o si el equipo de desarrollo, el SM y PO no tienen por qué estar. • Se responden las siguientes 3 preguntas: • ¿Qué hice ayer? • ¿Qué voy a hacer hoy? • ¿Tengo algún impedimento que necesito que me solucionen? • Oportunidad de inspección y adaptación.

22. SPRINT REVIEW • Se hace al final de Sprint, es la única reunión en donde participa el cliente. • El PO presenta los cambios hechos en el Sprint, y el equipo de desarrollo hace la demostración de lo desarrollado. • Dura 4 horas para un Sprint de 1 mes. • El cliente da feedback que nos ayudará a adaptarnos y a decidir con qué seguir. • El resultado de este evento es un Product backlog revisado para optimizar el trabajo del siguiente Sprint.

23. SPRINT RETROSPECTIVE • Se realiza luego del Sprint review • Duración de 3 horas para un sprint de 1 mes. • Es una oportunidad del equipo Scrum de inspeccionarse a sí mismo. • Se proponen mejoras relacionadas al proceso Scrum. • Al final de la retrospectiva el equipo tiene un listado de mejoras que debe aplicar en el siguiente Sprint.

24. ARTEFACTOS SCRUM

25. PRODUCT BACKLOG • Es un listado de tareas ordenadas por importancia. • El orden de las tareas es responsabilidad exclusiva del Product Owner. • El PO está constantemente actualizandolo. • El equipo de desarrollo escoge las tareas del PB para crear el Sprint Backlog • El equipo de desarrollo estima las tareas del PB.

26. • Es el listado de tareas del Product Backlog que se harán en cada Sprint. Se crea en el Sprint planning. • Es propiedad exclusiva del equipo de desarrollo. • El Sprint backlog no cambia en medio del sprint, solo se pueden agregar nuevas tareas por parte del equipo de desarrollo. SPRINT BACKLOG

27. DEFINITION OF DONE / READY El marco de trabajo Scrum destaca los 3 elementos expuestos previamente como imprescindibles. Sin embargo, hay otros que, a pesar de no formar parte del core, son necesario para asegurar la calidad de la metodología Scrum. Definition of Done (DoD): La DoD es un documento que define qué se considera hecho en un equipo Scrum. La idea es establecer una serie de criterios comunes para especificar cuando un ítem está completamente terminado y que aplique a todos los ítems que forman parte del incremento. Definition of Ready (DoR): El DoR es un documento que define cuándo un requerimiento (historia de usuario o similar) se considera listo para que el equipo de desarrollo pueda entenderlo, valorarlo e incluirlo en un Sprint Planning con idea de acometerlo en un Sprint.

28. • Es una representación gráfica del estado de trabajo que resta por hacer dentro de unSprint. • El eje X muestra el tiempo de desarrollo, el Y las tareas a hacer. • El equipo de desarrollo es el encargado de gestionarlo. • No es obligatorio de usar, lo que es obligatorio es medir cómo va un Sprint, siempre. BURN-DOWN CHARTS

29. AUTO-ORGANIZACION “AUTO-ORGANIZACION” Scrum esta diseñado para empleados de hoy Que tienen mucho mas que ofrecer que solo su conocimiento técnico. Y tu puedes entregar el mayor valor cuando se organizan por ellos mismos.

30. COLABORACION “COLABORACION” • Que involucra que todos los INTERESADOS trabajando e interactuando juntos para entregar el mayor valor al cliente

31. PRIORIZACION BASADA EN VALOR “PRIORIZACION BASADA EN VALOR” • Los requerimientos y sus tareas respectivas son priorizadas basadas en el valor que representan para el cliente. • De esta manera, los requerimientos mas valiosos para el cliente se hacen primero, conduciendo a incrementar el Retorno de la Inversión.

32. TIEMPO DEFINIDO “TIEMPO DEFINIDO” • El tiempo es el factor mas crucial en proyectos SCRUM y las juntas y periodos de trabajo tienen tiempo definido. • La junta “Daily Standup” es una junta de 15 minutos • La duración de un SPRINT es limitada de acuerdo a las necesidades del proyecto, y puede variar entre 1 y 6 semanas.

33. DESARROLLO ITERATIVO “DESARROLLO ITERATIVO” • El cual permite correcciones hasta que la gente involucrada tiene una mejor idea de Qué requerimientos van a ser cubiertos como parte del proyecto, e incorporan este aprendizaje de una manera iterativa.

34. ENTONCES…. • Scrum es un proceso iterativo e incremental que puede ser utilizado para desarrollar cualquier producto o administrar cualquier trabajo. Sus principales atributos son: – Un enfoque orientado a que los equipos desarrollen 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 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

35. En lugar de hacer todo de una cosa a la vez ... ...los equipos Scrum hacen un poco de todo todo el tiempo Requisitos Diseño Código Test • Desarrollo secuencial vs. superpuesto

36. 2.2. Aspectos de Scrum

37. Aspectos de SCRUM Ahora, vamos a ver los Aspectos de SCRUM • 1. Organización • 2. Justificación de Negocio • 3. Calidad • 4. Cambio • 5. Riesgo

38. ORGANIZACIÓN Los roles de SCRUM vienen en 2 categorías: Roles Principales y Roles no Principales • Los roles principales incluyen: • · Product Owner, • · Scrum master, y • · Scrum team Juntos hacen el Scrum CORE team

39. Los roles no principales incluyen • · Interesados o Stakeholders • · “Scrum Guidance Body” • · “Vendors” o Proveedores

40. • ROLES CENTRALES • ROLES NO CENTRALES Los roles de Scrum se dividen en dos grandes categorías:

41. Los roles centrales son aquellos que obligatoriamente se requieren para crear el producto del proyecto, están comprometidos con el proyecto, y por último son los responsables del éxito de cada sprint del proyecto y del proyecto en su totalidad ROLES CENTRALES

42. ROLESCENTRALES Haytrespapelesprincipalesen Scrum

43. - Representa los grupos de interés y es responsable de asegurar que el equipo scrum ofrecezca valor. El Product Owner describe los requerimientos del negocio en forma de historias de usuarios con las aportaciones de los miembros del equipo Scrum Core y gestiona la Prioridad del Product Backlog. LaVozdelCliente. DUEÑO DEL PRODUCTO (PRODUCT OWNER)

44. Product Owner - Representa al cliente - Tiene la visión de negocio - Reune el feedback de los usuarios - Define las nuevas funcionalidades - Toma las decisiones de producto

45. . Representa la voz del cliente Es responsable de logar el máximo valor de negocio del Proyecto Es el responsable de decidir sobre los criterios de aceptación para diversas tareas Proporciona financiación para el proyecto y supervisa el proyecto para confirmar la realización de beneficios Define la lista de prioridades de las necesidades Responsable de preparar la prioritized product backlog para reflejar las necesidades cambiantes de los clientes Es el responsable de crear historias de los usuarios en el proceso desarrollar historias de usuarios Es responsable de la preparación de la píla de producto priorizada Es responsable de priorizar los riesgos Es responsable de mantener involucrados a los socios Responsabilidades del Propietario del producto

46. SCRUM MASTER • El papel del Scrum Master se basa en el concepto de liderazgo de servicio en el que los líderes logran resultados por dar atención a las necesidades del equipo. EL SCRUM MASTER TAMBIÉN INSTRUYE A TODOS LOS INTERESADOS ACERCA DE LOS VALORES Y MÉTODOS DE SCRUM. ESTA RESPONSABILIDAD ES MÁS IMPORTANTE Y CRÍTICA AL INICIO, CUANDO ES LA TRANSICIÓN A LOS MÉTODOS DE SCRUM.

47. Scrum master - Lidera al equipo usando SCRUM - Gestiona los impedimentos - Sirve de escudo al equipo - No es el jefe - Es un facilitador

48. Es responsable de proporcionar al equipo Scrum con un entorno favorable para la creación de entregables Es responsable de crear una conciencia de las prácticas de Scrum entre los miembros del equipo Scrum Es responsable de resolver los conflictos entre los miembros del equipo Scrum Es responsable de asegurar que los requisitos y las historias de los usuarios perteneciente a un sprint acordado no se cambien Es responsable de asegurar que las reuniones diarias de Standup/pié se ejecuten de manera oportuna y estructurada Responsabilidades del SCRUM MASTER

49. El Equipo Scrum es un grupo de personas que son responsables de la comprensión de los requerimientos del negocio especiﬁcados por el propietario del producto. EQUIPO SCRUM (Scrum Team)

50. Team - Tienen un perfil técnico - Comprometidos con el producto - Capacidades para entregar en plazo - Se autogestionan en el día a día

51. Tienen conocimiento general de varios campos y son expertos en al menos uno, pero más allá de la experiencia, son las habilidades sociales de los miembros del equipo que determinan el éxito Los miembros ideales del Scrum Team son independientes, auto- motivados, se enfocan en el cliente y tienen un alto sentido de responsabilidad y de la colaboración. El equipo debe ser capaz de fomentar un ambiente de reflexión independiente y de tomar decisiones con el fin de extraer los mayores beneficios. SCRUM TEAM

52. -Auto-organizado -Multi-funcional - Caraa caradelacomunicación - Laentrega del productoiterativo CARACTERÍSTICAS DELEQUIPO SCRUM

53. Estima las historias de usuarios En ocasiones al equipo Scrum también se le denomina equipos de desarrollo En Scrum es preferible tener a los equipos coubicados Tiene la autoridad y responsabilidad de determinar las mejores formas para convertir los elementos de la lista priorizada de pendientes del producto en entregables completados Responsabilidades del SCRUM TEAM

54. Los roles no esenciales son aquellos papeles que no son obligatoriamente necesarios para el proyecto Scrum y pueden no estar involucrados en el proceso de Scrum. Los Non-core roles pueden incluir lo siguientes: 1. STAKEHOLDER(S) Es un termino que incluye a los clientes, los usuarios y patrocinadores que a menudo interactúan con el Product Owner, Scrum Master y Scrum Team para proporcionarles las entradas (inputs) y facilitar la creación del producto del proyecto, servicio, o cualquier otro resultado. o Clientes o Usuarios o Patrocinador ROLES NO ESENCIALES

55. 2. VENDEDORES Losvendedores incluyen aindividuos u organizaciones externas que ofrecen productos y servicios que no están dentro de lascompetencias básicasde la organización delproyecto. 3. SCRUMGUIDANCEBODY ElScrumGuidanceBody(SGB)esuna función opcional. Porlo general, secompone de un grupo de documentos y/o un grupo de expertos que normalmente están involucrados en la deﬁnición de los objetivos relacionados con gubernamentales, la seguridad y otros parámetros la calidad, las regulaciones clave de la organización. Estos objetivos guían la labor llevada acabo por el Product Owner, ScrumMaster y ScrumTeam.

57. ENTREGA BASADA ENVALOR Un proyecto es un NEGOCIO COLABORATIVO para cualquiera que desee crear nuevos productos o servicios, o para obtener resultados según han sido deﬁnidos en el Project Vision Statement (Declaración de la Visión del Proyecto). Los proyectos son por lo general afectados por limitaciones de Tiempo, costo, alcance, calidad, recursos y la capacidad de la organización. Por lo general se busca que los resultados generados por los proyectos resulten en algún tipo de valor de negocio o servicio. Dado a que el valor es una razón principal de cualquier organización para seguir adelante con un proyecto, la entrega basada en valor (Value-Driven Delivery) debe ser el foco principal. El ofrecer valor es algo que está arraigado en el marco de Scrum.

58. Con el ﬁn de aportar Value-driven Delivery (Entrega basada en valor), es importante: - Entender lo que le agrega valor a los clientes y a los usuarios, y dar prioridad a las necesidades de alto valor del Prioritized Product Backlog. - Disminuir la incertidumbre y encargarse de los riesgos que potencialmente puedan disminuir el valor en caso se materialicen. Es importante trabajar en estrecha colaboración con el Stakeholder del proyecto y mostrar incrementos de productos. - Crear entregables basados en las prioridades previamente deﬁnidas en la producción incrementos durante cada Sprint. De esta forma, los clientes empiezan a darse cuenta del valor desde el principio del proyecto. - El concepto de entrega basada en valor hace que el marco de Scrum sea muy atractivo para los Stakeholders y la alta dirección de las empresas.

59. RESPONSABILIDAD DELOSOTROS ROLES Es importante señalar que si bien el Product Owner es el principal responsable de la Justiﬁcación del Negocio, otras personas que trabajan en el proyecto Scrum también contribuyen de manera signiﬁcativa de la siguiente manera: - El patrocinador - Los clientes y usuarios - - En la Guía de Scrum Body - El Scrum Master - El Scrum Team

61. SCRUM:CALIDAD En Scrum, la calidad se deﬁne como la capacidad del producto o productos completados que cumplen los Criterios de Aceptación y alcanzan el valor de negocio que espera el cliente. Para asegurar que un proyecto cumpla con los requisitos de calidad, Scrum adopta un enfoque de Mejora Continua donde el equipo aprende de sus experiencias y del compromiso de los stakeholders. Esto ayuda a mantener al día el Prioritized Product Backlog con los cambios en los requisitos. El Prioritized Product Backlog no está completo hasta el cierre o la terminación del proyecto. Loserrores odefectossedetectandurantelaspruebasdecalidad respectivasynocuandoel productoﬁnal oservicio estácasiterminado

62. Los requisitos de calidad para un proyecto se determinan tomando varios factores como son: - La necesidad del negocio que el proyecto cumplirá. - La capacidad y la buena disposición de la organización para cumplir con las necesidades del negocio. - Las necesidades futuras y actuales de la audiencia. - El alcance de un proyecto es la suma total de todos los incrementos del producto y el trabajo necesario para desarrollar el producto ﬁnal. - Calidad, es la capacidad de las entregas para cumplir con los requisitos de calidad del producto y saCsfacer las necesidades del cliente .

63. GESTION DE CALIDAD EN SCRUM El CLIENTE es el socio más importante para cualquier proyecto, por lo tanto es importante entender las necesidades y requerimientos de los clientes. Generalmente, en un entorno de Scrum, el Product Owner se centra en requerimientos y objetivos del negocio, que en conjunto representan la voz del cliente.). Control de Calidad en Scrum le permite a los clientes tomar conciencia de los problemas en el proyecto desde el principio y les ayuda a reconocer si un proyecto les va a funcionar o no. En Scrum, la Gestión de calidad se facilita a través de tres actividades interrelacionadas: • Planiﬁcación de la calidad • Control de calidad • Garantía de calidad

65. CAMBIO Un principio fundamental de Scrum es el reconocimiento de los stakeholders (por ejemplo, clientes , usuarios y patrocinadores) cambian de opinión acerca de lo que quieren y necesitan en todo el proyecto que es muy difícil, si no imposible, para los stakeholders deﬁnir todos los requisitos durante la iniciación del proyecto. La práctica de Scrum se basa en la aceptación del cambio y de convertirlo en una ventaja competitiva.

66. La solicitud de cambio se presenta por lo general como Change Requests. Los Change Requests no son aprobados hasta que se obtiene una aprobación formal. se recomienda que los pequeños cambios que no tienen un impacto signiﬁcativo en el proyecto sean aprobados directamente por el Product Owner. SOLICITUDES DE CAMBIO APROBADAS Y NO APROBADAS

67. EQUILIBRIO FLEXIBILIDAD Y ESTABILIDAD Scrum ayuda a las organizaciones a ser más flexibles y abiertas al cambio. Sin embargo, es importante entender que aunque el marco de Scrum hace hincapié́ en la flexibilidad, también es importante tener estabilidad durante todo el proceso de cambio. De la misma manera que la rigidez extrema es ineficaz, la flexibilidad extrema también es improductiva. La clave es encontrar el equilibrio adecuado entre la flexibilidad y la estabilidad ya que se necesita la estabilidad con el fin de realizar el trabajo. Por lo tanto, Scrum utiliza desarrollo iterativo y sus otras características y principios para lograr este equilibrio. Scrum mantiene la flexibilidad de que las solicitudes de cambio pueden ser creados y aprobados en cualquier momento durante el proyecto; Sin embargo, consiguen prioridad cuando se crea o se actualiza el Product Backlog.

68. Si hay una solicitud de cambio que puede tener un impacto significativo sobre un Sprint en progreso, el Product Owner, después de consultar con los StakeHolders decide si se puede esperar hasta el próximo Sprint o si representa una situación urgente que puede requerir finalizar el Sprint actual y comenzar uno nuevo. El marco de Scrum especifica claramente que el alcance de un Sprint no se puede cambiar una vez que comienza el Sprint. Si el cambio requerido es tan importante que los resultados del Sprint no tendrían ningún valor sin él, entonces el Sprint debe ser terminado.

69. LOSCAMBIOSAUNSPRINT

71. QUÉ SON LOS RIESGOS? Riesgo se deﬁne como un evento incierto, que puede afectar los objetivos de un proyecto y puede contribuir a su éxito o fracaso. El Riesgo con un impacto positivo en el proyecto se denomina oportunidad, mientras que las amenazas son riegos que podrían afectar negativamente . La gestión del riesgo debe hacerse con pro-actividad y es un proceso iterativo que debería comenzar al inicio del proyecto y continuar durante todo el proyecto. El proceso de gestión del riesgo debe seguir algunos pasos estandarizados para asegurar que los riesgos son identiﬁcados, evaluados y un curso de acción está determinado y para actuar en consecuencia.

72. DIFERENCIAENTRERIESGOSYPROBLEMAS LOS RIESGOS: Son las incertidumbres relacionadas con un proyecto que podría alterar signiﬁcativamente el resultado del proyecto de una manera positiva o negativa. Dado a que los riesgos son las incertidumbres (futuro), no tienen ningún impacto actual en el proyecto, pero podrían tener un impacto potencial. Ejemplo: Incluso después de un amplio entrenamiento, es posible que los representantes del servicio al Cliente no estén listos para tomar pedidos el día oﬁcial del lanzamiento. LOS PROBLEMAS: Son generalmente certezas que se están produciendo en el proyecto, por lo que no hay necesidad de realizar una evaluación de la probabilidad como lo haríamos para un riesgo. Los problemas deben atenderse. Ejemplo: Los requisitos no son claros.

73. PROCEDIMIENTO DEGESTIÓNDERIESGOS (RISKS) La gestión de riesgos se compone de cinco pasos: 1. Riesgo Identificación: El uso de diversas técnicas para identificar todos los riesgos potenciales. 2. Riesgo Evaluación: La evaluación y la estimación de los riesgos identificados. 3. Riesgo Priorización: La priorización del riesgo a ser incluido en el Prioritized Product Backlog. 4. Riesgo Mitigación: Desarrollo de una estrategia adecuada para hacer frente al riesgo. 5. Riesgo Comunicación: La comunicación de los resultados de los primeros cuatro pasos.

74. 2.3. Procesos de Scrum

75. Fase Procesos Roles 1. INICIO 1. Crear la Vision del Proyecto PO 2. Identificar al Scrum Master y a los interesados PO , SM 3. Formar el Equipo Scrum PO , SM , ES 4. Desarrollo de Epicas/Personas PO , SM , ES 5. Crear la Lista Priorizada de Pendientes del Producto PO , SM , ES 6. Realizar la Planificacion del Lanzamiento PO , SM , ES •PO = Product Owner •SM = Scrum Master •ES = Equipo Scrum

76. I. Iniciación (6 procesos) En esta fase se crea la Visión del Proyecto que sirve de enfoque y dirección del mismo. Se crean e identifican roles claves del proyecto como el Scrum Master, Product Owner, interesados, equipo del proyecto. Así mismo, se define la lista de prioridades o el Product Backlog la cual sirve de base para la elaboración del plan de lanzamiento y tamaño de cada Sprint. Procesos • Crear la visión del proyecto (Create Project Vision) • Identificar al Scrum Master y a los interesados o socios del proyecto (Identify Scrum Master and Stakeholder(s)) • Formación del equipo Scrum (Form Equipo Scrum) • Desarrollo de épica(s) (Develop Epic(s)) • Creación de la lista priorizada de pendientes del producto (Create Prioritized Product Backlog) • Realizar el plan de lanzamiento (Conduct Release Planning)

77. Procesos SCRUMIniciar • Crear la visión del proyecto • Identificar al Scrum Master y al socio • Formación de un equipo Scrum • Desarrollo de épicas • Creación de la lista priorizada de pendientes del producto • Realizar el pan de lanzamiento Planear y Estimar Historias de estimar y historias de • Elaborar Usuario • Aprobar, asignar usuario • Elaboración de tareas • Estimar tareas • Elaboración de la lista de pendientes del Sprint Implementar • Crear entregables • Llevar a cabo el Standup diario • Mantenimiento de la lista priorizada de pendientes del producto Revisión y Retrospectiva • Convocar Scrum de Scrums • Demostración y validación del Sprint • Retrospectiva de Sprint Lanzamiento • Envío de Entregables • Retrospectiva del Proyecto

78. Salida s Herramientas Entrada

79. Proceso: 1. Crear la Visión del Proyecto Entradas Caso de Negocio del Proyecto (*) • Documento bien estructurado o simplemente una declaración verbal que expresa la razón para iniciar un proyecto. • Puede ser formal y detallado, o informal y breve. • Incluye información sobre: antecedentes del proyecto, objetivos del negocio y resultados deseados, lista de riesgos identificados, y estimaciones de tiempo, esfuerzo y costo. • El Proyecto se inicia con la presentación del Caso de Negocio del Proyecto.

80. Proceso: 1. Crear la Visión del Proyecto Entradas Visión de la Compañía • Ayuda a que el proyecto mantenga su enfoque en los objetivos de la organización y el futuro probable de la empresa. • El Propietario del Producto se puede guiar por el Visión de la Compañía para crear la Declaración de la Visión del Proyecto. Entradas Misión de la Compañía • Ofrece un marco para la formulación de las estrategias de la empresa y orienta la toma de decisiones en general de la empresa. Entradas

81. Proceso: 1. Crear la Visión del Proyecto Estudio de Mercado • Investigación organizada, la recopilación , la comparación y el análisis de datos relacionados con las preferencias de los clientes sobre los productos. • Incluye numerosos datos sobre las tendencias del mercado, la segmentación del mercado y los procesos de comercialización. Entradas Entradas Recomendaciones del Cuerpo de Asesoramiento de SCRUM • Grupo de documentos y/o grupo de expertos que están involucrados en la definición de objetivos relacionados con la calidad, las regulaciones gubernamentales, la seguridad y otros parámetros claves de la organización. • NO toma decisiones relacionadas al proyecto. • Es importante asegurarse de que la visión del proyecto esté alineada con las recomendaciones proporcionadas por el Cuerpo de Asesoramiento de Scrum y que los procesos cumplan con las normas y directrices establecidas por el SBOK (la Administración)

82. Proceso: 1. Crear la Visión del Proyecto Reunión de la Visión del Proyecto • Reunión con los Interesados del Programa, Propietario de Producto del Programa, Scrum Master del Programa, y Jefe Propietario de Producto. • Ayuda a identificar el contexto empresarial, requerimientos del negocio y las expectativas de los socios con el fin de desarrollar una Declaración de la Visión del Proyecto. • Scrum cree en la participación y colaboración cercana con todos los representantes de las empresas para obtener su buy-in (convencimiento de su importancia) del proyecto y para ofrecer un valor más significativo. Herramientas

83. Proceso: 1. Crear la Visión del Proyecto Análisis FODA • Enfoque estructurado para la planificación que ayuda a evaluar las Fortalezas, Oportunidades, Debilidades y Amenazas relacionados al proyecto. • La realización del FODA permite la identificación precoz de las prioridades, los cambios potenciales y los riesgos. Herramientas

84. Proceso: 1. Crear la Visión del Proyecto Análisis de Brechas • Técnica que se utiliza para comparar el estado actual con el estado deseado. • Normalmente, se inicia un proyecto para que una organización alcance una situación deseada, por lo que llevar a cabo un Análisis de Brechas ayudaría a quienes toman decisiones a determinar la necesidad del proyecto. Herramientas

85. Proceso: 1. Crear la Visión del Proyecto Identificación del Propietario del Producto (*) • El Propietario del Producto es la persona responsable de lograr el valor máximo empresarial para el proyecto. • Representa la voz del Cliente. • Cada Equipo Scrum tendrá un Propietario de Producto designado. Un pequeño proyecto puede tener sólo un Propietario de Producto, mientras que los proyectos más grandes pueden tener varios. Salidas Enunciado de la Visión del Proyecto (*) • Una buena visión del proyecto explica la necesidad del negocio, y que es lo que el proyecto tiene como objetivo satisfacer, en lugar de cómo se va a satisfacer la necesidad. • No deberías ser muy específico y debe ser flexible, ya que es posible que esté basado en suposiciones. • Debe centrase en el problema y no la solución. Salidas

86. Fase: Iniciar Proceso: 2. Identificar al Scrum Master y al Socio(s)

87. Proceso: 1. Crear la Visión del Proyecto Acta de Constitución del Proyecto • Es una declaración formal de los objetivos y resultados deseados del proyecto. • En varias organizaciones, el Acta de Constitución del Proyecto es el documento oficial y formal que autoriza el proyecto, dándole al equipo la autoridad por escrito para comenzar el proyecto. Salidas Presupuesto del Proyecto • Documento financiero que incluye el costo de las personas, materiales y otros gastos relacionados en un proyecto. • Típicamente es firmado por los Patrocinadores para asegurar que haya suficientes fondos disponibles. Salidas

88. Proceso: 2. Identificar al Scrum Master y al Socio(s) Entradas Disponibilidad y compromiso de las personas • Antes de seleccionar al Scrum Master y a los Interesados, se debe confirmar su disponibilidad. • Sólo los miembros que estarán disponibles y que puedan comprometerse plenamente con el proyecto deben ser seleccionados. Entradas Matriz de Recursos Organizacionales • Es una representación jerárquica de una combinación de una estructura de organización funcional y una estructura organizativa proyectizada. • Las organizaciones matriciales reúnen a miembros de varios equipos del proyecto de diferentes departamentos funcionales. • Los miembros del equipo en una organización matricial cumplen dos objetivos: funcionales y de proyecto. Entradas Matriz de Requerimientos de Habilidades • Conocido como marco de competencias. • Se utiliza para evaluar las carencias de habilidades y los requisitos de formación para los miembros del equipo.

89. Proceso: 2. Identificar al Scrum Master y al Socio(s) Entradas Jefe Scrum Master • Los grandes proyectos requieren que múltiples Scrum Masters trabajen en paralelo. • Es posible que la información obtenida por un equipo se le deba comunicar adecuadamente a los otros equipos. Es el Jefe Scrum Master el responsable de esta actividad. • La coordinación entre distintos Equipos Scrum que colaboran en un proyecto se realiza a través de la Reunión Scrum de Scrums (SoS). Esto es análogo al Daily Standup Meeting y es facilitado por el Jefe Scrum Master. Entradas Requisitos de Personal • Es importante documentar las funciones y responsabilidades de todos los que se verían involucrados en la realización de las tareas del proyecto. • El Propietario del Producto o el Scrum Master colaboran con el Departamento de Gestión Humana de la empresa para determinar y concluir los requerimientos del personal.

90. Proceso: 2. Identificar al Scrum Master y al Socio(s) Costos de Formación y capacitación • El Propietario de Producto debería evaluar las necesidades de capacitación de los miembros potenciales del equipo y facilitar la formación para eliminar lacarencia. • El Propietario del Producto es normalmente responsable de la evaluación y la selección de los miembros del equipo, pero a menudo lo hace en consulta con el Scrum Master. • Una formación adecuada se le debe proporcionar a los miembros del Equipo Scrum, tanto antes del inicio de los trabajos ya también mientras están trabajando en sus proyectos. Los miembros del Equipo Scrum deben estar dispuestos a aprender de los demás y de quienes tienen más experiencia en el equipo. Herramientas Costos de los Recursos • Una de las principales consideraciones en la selección de las personas tiene que ver con las ventajas y desventajas relacionadas con el nivel de experiencia en comparación al salario. Herramientas

91. Proceso: 2. Identificar al Scrum Master y al Socio(s) Criterios de Selección (*) • Cuando hay flexibilidad en la elección del Scrum Master, se deben considerar los siguientes criterios de selección:  Habilidades para la resolución de problemas.  Disponibilidad  Compromiso  Estilo de Liderazgo Servant • En la identificación de los Interesados, es importante recordar que se incluye a todos los clientes, los usuarios y patrocinadores, quienes influyen en el proyecto a lo largo de su ciclo de vida. Herramientas Asesoramiento de Expertos de Recursos Humanos • Puede ser útil en al identificación del Scrum Master y de los Interesados. • El Departamento de Recursos Humanos posee un conocimiento específico sobre los empleados de una organización y las diversas técnicas que pueden ayudar a identificar. Herramientas

92. Proceso: 2. Identificar al Scrum Master y al Socio(s) Identificación del Scrum Master (*) • El Scrum Master es un facilitador y Servant Leader que se asegura de que el Equipo Scrum esté dotado de un ambiente propicio para completar el proyecto con éxito. • Es la responsabilidad del Propietario de Producto identificar al Scrum Master para un proyecto Scrum. Salidas Identificación de StakeHolders ( Interesados) • Interesados es un término colectivo que incluye a los clientes, los usuarios y los patrocinadores, con frecuencia interactúan con el Equipo Scrum Principal en el proyecto durante todo el proceso de desarrollo del producto. • Es para los socios que el proyecto produce los beneficios deseados de colaboración. Salidas

93. Fase: Iniciar Proceso: 3. Formación de un Equipo Scrum

94. Proceso: 3. Formación de un Equipo Scrum Entradas Requisitos de Recursos • Estos requisitos incluyen todos los recursos, sean personas o no, necesarios para que el Equipo Scrum funcione con eficacia. • Estos recursos incluyen infraestructura de oficinas, espacios de reunión, los equipos de trabajo, Scrumboards, etc. • En caso de equipos virtuales, recursos adicionales, tales como herramientas de Colaboración, videoconferencia, repositorios de documentos compartidos, servicios de traducción, etc.

95. Proceso: 3. Formación de un Equipo Scrum Selección del Equipo Scrum • El Equipo Scrum es la base de cualquier proyecto de Scrum y el tener a los • miembros adecuados para el equipo es vital pára la entrega exitosa de los proyectos Scrum. • Los miembros del Equipo Scrum son generalistas/especialistas ya que cuentan con conocimiento de diversos campos y son expertos en al menos uno. • Los miembros ideales del Equipo Scrum son independientes, auto-motivados, se enfocan en el cliente, y tiene un sentido de la responsabilidad y lacolaboración. Herramientas Asesoramiento de Expertos de Recursos Humanos • Puede ser útil para la formación del Equipo Scrum. • El Departamento de Recursos Humanos posee un conocimiento específico sobre los empleados de una organización y las diversas técnicas que pueden ayudar al Propietario del Producto, Scrum Master y a los patrocinadores para identificar a los mejores miembros del equipo. Herramientas

96. Proceso: 3. Formación de un Equipo Scrum Costo asociado con el personal • Todos los costos asociados con los requisitos de las personas deben ser evaluados, analizados, aprobados y presupuestados.Herramientas Costos de los Recursos • Los costos asociados con todos los requisitos no relacionados con las personas deben ser evaluados, analizados, aprobados y presupuestados. • Un recurso en el entorno del proyecto es identificado como aquello que se usa para realizar una trae o actividad, incluyendo pero no limitado a equipos, materiales, servicios externos y el entorno físico. Herramientas

97. Proceso: 3. Formación de un Equipo Scrum Identificación del Equipo Scrum • También conocido como Development Team, es un grupo o equipo de personas que son responsables de la comprensión de los requerimientos del negocio especificados por el Propietario del Producto, la estimación de Historias de Usuario y la creación definitiva de los entregables del proyecto. Salidas Personal de Reemplazo /Sustitutos • Aunque la disponibilidad y compromiso por los miembros del equipo se confirman por adelantado, pueden surgir problemas, tales como una enfermedad, emergencia familiar, o simplemente el hecho de renuncia de un miembro. • El tener reemplazantes asegura que no haya una disminución importante en la productividad debido a la falta de un miembro del equipo. Salidas

98. Fase: Iniciar Proceso: 4. Desarrollo de Épicas

99. Proceso: 4. Desarrollo de Épicas Entradas Leyes y regulaciones • Las leyes son externas a la organización e impuesta por una entidad gubernamental. • Las regulaciones pueden ser o bien interna o externa. Las regulaciones internas son aquellas que son aplicables dentro de la empresa, por lo general basadas en la política de la empresa. Las regulaciones externas son las relativas a los criterios, las normas y requisitos gubernamentales establecidos. • A veces, algunas de las leyes y reglamentos que afectan a múltiples proyectos Scrum pueden incluirse como parte del Cuerpo de Asesoramiento de Scrum. Entradas Información previa del proyecto • Información y conocimientos adquiridos en proyectos anteriores y similares dentro de la organización son insumos valiosos para el desarrollo de Épicas y de la evaluación de riesgos.

100. Proceso: 4. Desarrollo de Épicas Entradas Solicitudes de Cambio Aprobados • Solicitudes de Cambio Aprobadas que vienen del programa o portafolio son entradas que se añadirán a la lista de cambios del proyecto aprobados para su ejecución en sprints futuros. • Cada cambio puede requerir su propia Épica o Historia de Usuario. • También podría ser resultado de otros procesos de Scrum. Entradas Solicitudes de Cambio No Aprobados • Los pedidos de cambios se presentan por lo general como Solicitudes de Cambio y permanecer en un estado de “no aprobado” hasta que sean formalmente aprobados. Entradas Riesgos del Programa y Portafolio • Riesgos relacionados con un portafolio o programa también tendrán un impacto en los proyectos que forman parte del respectivo portafolio o programa. • Durante evaluación de riesgos de portafolio o programa, si se determina que el riesgo puede afectar a un proyecto individual, la información relevante debe ser comunicada al Propietario de Producto y equipo Scrum.

101. Taller de Historias de Usuario • El Scrum Master facilita estas sesiones en las que todo el Equipo Scrum Principal interviene, y en ocasiones, es deseable incluir a otros Interesados. • Estos talleres ayudan al Propietario de Producto a dar prioridad a los requisitos y permitir que el Equipo Scrum Principal tenga una perspectiva compartida de los Criterios de Aceptación. • Es una buena plataforma para discutir y aclarar todos los elementos de un producto y a menudo profundizar en los detalles más pequeños para garantizar la claridad. Herramientas Proceso: 4. Desarrollo de Épicas Reuniones de Grupo de Usuarios (*) • Implica la participación de socios relevantes (usuarios o clientes del producto). Ellos • proporcionan información de primera mano acerca de las expectativas del usuario. Esto ayuda en la formulación de los Criterios de Aceptación para el producto y proporciona información valiosa para el desarrollo deÉpicas. • Son de vital importancia en la prevención del trabajo costoso que puedan deberse a la falta de claridad con respecto a las expectativas yexigencias. Herramientas

102. Herramientas Proceso: 4. Desarrollo de Épicas Reuniones de Grupo de Enfoque (Focus Group) • Se reúnen las personas en una sesión guiada para proporcionar sus opiniones, percepciones o valoraciones de un producto, servicio o resultado deseado. • Los participantes tienen la libertad de hacerse preguntas el uno al otro y de obtener aclaraciones sobre temas o conceptos específicos. • Cunado los miembros del grupo tienen diferentes opiniones o puntos de vista, no se escatiman esfuerzos para resolver las diferencias con el fin de llegar a un consenso. Entrevistas con usuarios o clientes • Es importante para ganar el contexto y la visión necesaria para desarrollar Épicas. • Estas entrevistas ayudan a: identificar y entender las necesidades y expectativas del interesado, reunir opiniones y hechos, comprender la perspectiva del interesado sobre el producto final y recopilar la retroalimentación sobre el producto. Herramientas Cuestionario • Una forma económica de obtener una perspectiva estadística cuantitativa Herramientas y cualitativa de una gran número de usuarios o clientes. • Gran cuidado debe ser ejercido en el diseño de cuestionarios, la selección del público debe ser adecuada, y la determinación de un método apropiado de implementación de encuestas.

103. Proceso: 4. Desarrollo de Épicas Cambios Aprobados • Solicitudes de Cambio No Aprobadas pueden ser aprobadas por el Propietario de Producto durante el proceso Desarrollo de Épicas, a veces con sugerencias proporcionada por los socios relevantes. Salidas Riesgos identificados • Al crear Épicas, nuevos riesgos pueden ser identificados y estos riesgos identificados constituyen una salida muy importante de esta etapa. Salidas

104. Proceso: 4. Desarrollo de Épicas Épicas () • Se escriben en las etapas iniciales del proyecto, cuando la mayoría de las Historias de Usuario son funcionalidades de alto nivel o descripciones de productos que están ampliamente definidas. • Son Historias de Usuario grandes sin refinar en la Lista Priorizada de Pendientes del Producto. Salidas

105. Proceso: 5. Creación de la Lista Priorizada de Pendientes del Producto

106. Proceso: 5. Creación de la Lista Priorizada de Pendientes del Producto Entradas Requerimientos del Negocio • La suma de todos los conocimientos adquiridos a través de diversas herramientas como entrevistas a los clientes o usuarios, Cuestionarios, Análisis de Brechas, Análisis FODA, y otras reuniones, ayuda a desarrollar una mejor perspectiva sobre los requerimientos de negocio y ayuda en la creación de la Lista Priorizada de Pendientes del Producto.

107. • Todas las herramientas usadas para los procesos Aprobar, Estimar y Comprometer Historias de Usuario se pueden utilizar para crear estimaciones de alto nivel para Épicas cuando creamos la Lista Priorizada de Pendientes del Producto. Se mencionan las herramientas:  Reuniones de Grupos de Usuario  Planning Poker  Fist of Five  Metodo KANO  Puntos para Estimación de Costos  Otras técnicas de estimación. Herramientas Proceso: 5. Creación de la Lista Priorizada de Pendientes del Producto Métodos de Estimación de Historias de Usuario

108. Lista Priorizada de Pendientes del Producto • Contiene una lista priorizada de los requerimientos del negocio y de los proyect, que son de altos niveles de Historias de Usuario. • Se basa en tres factores principales: el valor, riesgo o incertidumbre, y dependencias. • También se le conoce como Lista de Pendientes del Producto Ajustados con Riesgo dado que incluye riesgos identificados y evaluados relacionados con el proyecto. • Valor. Es la responsabilidad del Propietario de Producto asegurar en primer lugar la entrega de los productos que ofrezcan el mayor valor. Incluso un producto de gran valor no puede ser parte del primer release si hay otros productos de mayor valor que son suficientes para un primer lanzamiento. • Riesgo o Incertidumbre. Cuánta más incertidumbre existe, más riesgoso es el proyecto. Por lo tanto, es importante que a los productos de mayor riesgo, se les de la mayor prioridad. • Dependencias. Las dependencias pueden afectar cómo se priorizan las Historias de Usuario. Dos de las formas más comunes para resolver dependencias son, o bien dividir una sola historia en varias partes, o combinar historias interdependientes. • Estimaciones, Las estimaciones de alto nivel para las Épicas también se encuentran en la Lista Priorizada de Pendientes del Producto. Salidas Proceso: 5. Creación de la Lista Priorizada de Pendientes del Producto

109. Criterio Terminado Conjunto de reglas que se aplican a todas las Historias de Usuario. • Una definición clara de “Terminado” es crítica. Ya que elimina la ambigüedad de los requisitos y ayuda a que el equipo se adhiera a las normas de calidad obligatoria. • Una Historia de Usuario se considera “Terminado” cuando se demuestra y se aprueba por el Propietario del Producto que juzga sobre la base de los Criterios “Terminado” y los Criterios de Aceptación de las Historias de Usuario. Salidas Proceso: 5. Creación de la Lista Priorizada de Pendientes del Producto

110. Fase: Iniciar Proceso: 6. Realizar el Plan de Liberaciones

111. Proceso: 6. Realizar el Plan de Liberaciones Entradas Calendario de Vacaciones • Es importante para el Equipo Scrum estar al tanto de las fechas claves y la disponibilidad de todos los miembros del equipo. • Esto se puede lograr mediante el uso de un calendario compartido que proporciona información sobre los días feriados, licencias, faltas al trabajo, los planes de viaje, eventos, etc. • Ayudará al equipo en la planificación y ejecución de sprints.

112. • Se llevan a cabo para desarrollar un Plan de Liberaciones. • El Plan define cuando varios conjuntos de funcionalidad o productos utilizables serán entregados al cliente. • El objetivo principal es hacer que el Equipo Scrum tenga una visión general de las liberaciones y el calendario de entrega del producto que están desarrollando para que puedan alinearse con las expectativas del Propietario de Producto y los socios relevantes. • No es necesario que en estas sesiones se elabore un Plan de Liberaciones detallado de todo el proyecto. Este Plan se puede actualizar continuamente a medida que la información relevante está disponible. Herramientas Proceso: 6. Realizar el Plan de Liberaciones Sesiones de Planificación de Liberaciones Métodos de Priorización de Liberaciones • Estos métodos son específicos a la industria y organización y generalmente son determinados por la alta dirección de la organización.Herramientas

113. Salidas Proceso: 6. Realizar el Plan de Liberaciones Clientes Objetivos para la Liberación • No todos los lanzamientos se dirigirán a todos los socios o usuarios. • Los Interesados optan por limitar ciertos comunicados a un subconjunto de usuarios. • El Plan de Liberación debe especificar los clientes en quienes se va a enfocar la lberación. Lista Priorizada de Pendientes del Producto Refinada • Se puede refinar en este proceso. • Es posible que haya más claridad sobre las Historias de Usuario en la Lista Priorizada de Pendientes del Producto después de que el Equipo Principal de Scrum lleve a cabo Sesiones de Planificación de Liberaciones con los Interesados. Salidas

114. Salidas Proceso: 6. Realizar el Plan de Liberaciones Cronograma de Planificación de Liberaciones (*) • Indica que entregas van a ser realizadas a los clientes, junto con intervalos planificados y fechas para las liberaciones. • Puede que no haya una liberación prevista a finales de cada Sprint. A veces, una liberación puede ser planificada después de que un grupo de Sprints se ha completado. • La entrega debe ser liberada cuando ofrece valor empresarial suficiente para el cliente. Tamaño del Sprint (*) • Basada en las diversas entradas que incluyen Requerimientos del Negocio y Calendario de Planificación de Liberaciones, el Propietario del Producto y el Equipo Scrum deciden sobre el Tamaño del Sprint para el proyecto. • Una vez determinado, el tamaño del Sprint a menudo sigue siendo el mismo durante todo el proyecto. Salidas

115. Iniciar • Crear la visión del proyecto • Identificar al Scrum Master y al socio • Formación de un equipo Scrum • Desarrollo de épicas • Creación de la lista priorizada de pendientes del producto • Realizar el pan de lanzamiento Planear y Estimar Historias de estimar y historias de • Elaborar Usuario • Aprobar, asignar usuario • Elaboración de tareas • Estimar tareas • Elaboración de la lista de pendientes del Sprint Implementar • Crear entregables • Llevar a cabo el Standup diario • Mantenimiento de la lista priorizada de pendientes del producto Revisión y Retrospectiva • Convocar Scrum de Scrums • Demostración y validación del Sprint • Retrospectiva de Sprint Lanzamiento • Envío de Entregables • Retrospectiva del Proyecto

116. Fase: Planear y Estimar Proceso: 7. Elaborar Historias de Usuario

117. • El Propietario de Producto, basado en su interacción con los socios, conocimiento del negocio, experiencia y las aportaciones del equipo, desarrolla las Historias de Usuario que formarán la Lista Priorizada de Pendientes del Producto inicial para el proyecto. • El objetivo de este ejercicio es crear Historias de Usuario elaborados y refinados que sean aprobados y calculados, ya a su vez el Equipo Scrum se pueda comprometer. • Aunque el Propietario del producto tiene la responsabilidad primordial de la escritura de Historias de Usuario, y a menudo lleva a cabo este proyecto por si solo, un Taller de Escritura de Historias de Usuario puede ser considerado si se desea. Herramientas Reuniones de Grupo de Enfoque • Técnica cualitativa para medir y entender las necesidades de los usuarios y las expectativas acerca de un producto propuesto. • Un pequeño grupo de usuarios es seleccionado para formar el grupo de enfoque. • Normalmente se adhieren a un determinado formato en el que al grupo se le hacen preguntas que luego discuten entre ellos. • Cada reunión del grupo de enfoque puede tener sus propias reglas de discusión a lo decidido por los organizadores. • Se llevan a cabo en presencia de un moderador. Herramientas Proceso: 7. Elaborar Historias de Usuario Experiencia para escribir Historias de Usuario

118. Salidas Proceso: 7. Elaborar Historias de Usuario Historias de Usuario(*) • Una Historia de Usuario indica tres cosas acerca de la exigencia: ¿Quién, qué y porqué? • Los requisitos expresados en Historias de Usuario son declaraciones breves, simples y fáciles de entender. • Los resultados de formato estándar predefinidos resultan en una major comunicacón entre los socios y mejores cálculos determinados por el equipo.

119. Salidas Proceso: 7. Elaborar Historias de Usuario Criterios de Aceptación de Historias de Usuario • Cada Historia de Usuario está asociado con Criterios deAceptación. • Las Historias de Usuario son subjetivas, por lo que los Criterios de Aceptación proporcionan la objetividad requerida para que la Historia de Usuario sea considerada como “Terminado”, o no, durante la Reunión de Revisión. • El Propietario de Producto define y comunica los Criterios de Aceptación al Equipo Scrum. • Es importante, y la responsabilidad del Scrum Master, asegurar que el Propietario del Producto no cambie los Criterios de Aceptación de una Historia de Usuario que ya está comprometido a un Sprint.

120. Fase: Planear y Estimar Proceso: 8. Aprobar, Estimar y Asignar Historias de Usuario

121. Entradas Historias de Usuario • Las Historias de Usuario tienen estimaciones de alto nivel de los procesos de Creación de la Lista Priorizada de Pendientes del Producto y Elaborar Historias de Usuario. • Estas estimaciones sería utilizadas por el Propietario del Producto para crear una lista de Historias de Usuario aprobados que se estiman con mayor precisión por el Equipo Scrum. Proceso: 8. Aprobar, Estimar y Asignar Historias de Usuario

122. Proceso: 8. Aprobar, Estimar y Asignar Historias de Usuario Estimación de Tamaño ≠ Estimación de Duración

123. Proceso: 8. Aprobar, Estimar y Asignar Historias de Usuario Planning Poker También llamada Estimation Poker, es una técnica de estimación o cálculo que utiliza el consenso para estimar los tamaños relativos de las Historias de Usuario o el esfuerzo requerido para crearlos. La historia se presenta y se discute sobre ella. • Los miembros del equipo escogen la carta con la estimación. • Todos dan la vuelta a la carta a la vez. • Los miembros con la estimación más baja y más alta exponen sus razones, y se repite el proceso de estimación. Herramientas

124. Proceso: 8. Aprobar, Estimar y Asignar Historias de Usuario Fist of FIve Mecanismo sencillo para llegar a un consenso en un grupo e iniciar una conversación. • Tras el debate inicial sobre una propuesta o una decisión pendiente, se les pide a los miembros del Equipo Scrum que voten en una escala del 1 al 5 usando sus dedos. • El valor en el uso de esta técnica no es sólo la creación de consenso, sino también la reflexión y la charla ya que a cada miembro del equipo se le pide que explique el motivo de su clasificación. • Una vez que el equipo ha discutido, se tomará una decisión colectiva. • Un dedo: No estoy de acuerdo con la conclusión del grupo y tienen grandes preocupaciones. • Dos dedos: No estoy de acuerdo con la conclusión del grupo y me gustaría hablar de algunos problemas menores. • Tres dedos: No estoy seguro y me gustaría asumir la conclusión del consenso del grupo. • Cuatro dedos: Estoy de acuerdo con la conclusión del grupo y me gustaría discutir algunos problemas menores. • Cinco dedos: Estoy totalmente de acuerdo con la conclusión del grupo. Puntos Herramientas

125. Proceso: 8. Aprobar, Estimar y Asignar Historias de Usuario Puntos para Estimación del Costo • La estimación del costo se puede lograr mediante el uso de unidades relativas en lugar de unidades absolutas. • Con el fin de estimar el costo de implementar una Historia de Usuario, el Equipo Scrum puede utilizar Puntos de Historia, en lugar de unidades monetarias. Delphi • Técnica de estimación basada en grupo para la determinación de la cantidad de trabajo que está involucrado y el tiempo que tardará en completarse. • Los individuos de un equipo de forma anónima proporcionan estimaciones para cada función y las estimaciones iniciales se trazan en una gráfica. • Posteriormente el equipo analiza los factores que influyeron en sus estimaciones y proceden a una segunda ronda de estimación. Este proceso s repite hasta que las estimaciones de los individuos sean similares y se llegue a un consenso para la estimación final. • Planning Poker es un ejemplo de esta técnica. Herramientas

126. Proceso: 8. Aprobar, Estimar y Asignar Historias de Usuario Historias de Usuario Aprobadas, Estimadas y Comprometidas • Las Historias de Usuario se estiman por el equipo utilizando las distintas técnicas de estimación. • Después de la estimación, el equipo se compromete en un subconjunto de Historias de Usuario aprobados y estimados que creen que pueden completar en el próximo Sprint. Estas Historias de Usuario se convertirán en parte de la Lista de Pendientes del Sprint. Salidas

127. Proceso: 9. Elaboración de Tareas Reuniones de Planificación de Tareas • El equipo Scrum se reúne para planificar el trabajo que se realizará en el Sprint. • El equipo revisa las Historias de Usuario ya comprometidos en la parte superior de la Lista Priorizada de pendientes del Producto. • El Propietario del Producto está presente en esta reunión en caso se requiera. • Esta reunión será time-boxed, con la longitud estándar limitada a dos horas por semana durante el Sprint. • A veces también se conoce como Reunión de Planificación del Sprint. Herramientas

128. Proceso: 9. Elaboración de Tareas Tarjetas de Vocabulario • Las Historias de Usuario se escriben en pequeñas Tarjetas. • Sólo los detalles esenciales están documentados en las tarjetas, que pueden ser utilizados por el Equipo Scrum para colaborar y discutir. Descomposición • Es una herramienta mediante la cual las tareas de alto nivel se dividen en tareas detalladas con niveles más bajos. Herramientas

129. Proceso: 9. Elaboración de Tareas Determinación de Dependencias • Ayuda a los Equipos Scrum a determinar el orden relativo en el que las tareas deben ejecutarse para crear los entregables del Sprint. • Existen numerosos tipos de dependencias: obligatorias y discrecionales, internas y externas, o alguna combinación de estas dependencias. • Mandatorias. Que son ya sea inherente a la naturaleza del trabajo, como una limitación física, o puedan deberse a las obligaciones contractuales o los requisitos legales. • Discrecionales. Se colocan en el flujo de trabajo por decisión propia. Normalmente, son determinados por el Equipo Scrum, basadas en las experiencias del pasado o en las mejores prácticas. • Externas. Son las tareas, actividades o productos que están fuera del alcance del Equipo Scrum, pero son necesarias para completar una tarea de proyecto o crear una prestación del proyecto. • Internas. Son las dependencias de tareas Herramientas

130. Proceso: 9. Elaboración de Tareas Lista de Tareas • Lista complete con todas las tareas a la que el Equipo Scrum se ha comprometido para el Sprint actual. • Contiene descripciones de cada tarea junto con las estimaciones derivadas durante el proceso de Elaboración de Tareas. • Deben incluir cualquier esfuerzo de prueba y de integración de manera que el Incremento del Producto del Sprint se puedea integrar con éxito en las entregas anteriores de Sprints. Dependencias • Describen la relación e interacción entre diferentes tareas de un proyecto y pueden ser clasificadas como obligatorias o discrecionales, o interna o externa. • Hay numerosas maneras de identificar, definer y presenter las tareas y sus dependencias. Dos métodos comunes involcucran el uso de diagramas de flujo del producto y diagramas de Gantt Salidas Salidas

131. Proceso: 10. Estimar Tareas Criterios de Aceptación de Historias de Usuario • El Equipo Scrum debe asegurarse de que los Criterios de Aceptación definidos sean apropiados para las Historias de Usuario y proporcionen claridad en cuanto a los requisitos para el Equipo Scrum. • En el desarrollo de los Criterios de Aceptación de Historias de Usuario, lo siguiente debe ser considerado: Criterios de Aceptación no deben ser vagos, ambiguos o demasiado generalizados. Criterios de Aceptación definidos aseguran de que el equipo sea capaz de verificar que los resultados estén alineados con las metas y objetivos de la organización patrocinadora. Entrada

132. Proceso: 10. Estimar Tareas Reuniones de Estimación de Tareas • Le permiten al Equipo Scrum estimar el esfuerzo necesario para completar una tarea o conjunto de tareas y estimar el esfuerzo de las personas y otros recursos necesarios para llevar a cabo los trabajos dentro de un Sprint determinado. • El equipo Scrum puede utilizar diversas técnicas como segmentación (descomposición), la opinión de expertos, estimación análoga, y la estimación paramétrica. • También se conoce como Reunión de Planificación del Sprint. También se puede combinar con la Reunión de Planificación de Tareas Criterios de Estimación • El objetivo principal de utilizar estos criterios, es mantener los tamaños d estimación relativos y minimizar la necesidad de reestimación. • Se pueden expresar de muchas maneras, dos ejemplos comunes son los Puntos de Historia y el Tiempo Ideal Herramientas

133. Proceso: 10. Estimar Tareas Reuniones de Estimación de Tareas • Le permiten al Equipo Scrum estimar el esfuerzo necesario para completar una tarea o conjunto de tareas y estimar el esfuerzo de las personas y otros recursos necesarios para llevar a cabo los trabajos dentro de un Sprint determinado. • El equipo Scrum puede utilizar diversas técnicas como segmentación (descomposición), la opinión de expertos, estimación análoga, y la estimación paramétrica. • También se conoce como Reunión de Planificación del Sprint. También se puede combinar con la Reunión de Planificación de Tareas Criterios de Estimación • El objetivo principal de utilizar estos criterios, es mantener los tamaños d estimación relativos y minimizar la necesidad de reestimación. • Se pueden expresar de muchas maneras, dos ejemplos comunes son los Puntos de Historia y el Tiempo Ideal Herramientas

134. Proceso: 10. Estimar Tareas Lista de Tareas y su Esfuerzo Estimado • Lista de las tareas asociadas con las Historias de Usuario incluidos en un Sprint. • El esfuerzo estimado se expresa en téminos de los Criterios de Estimación acordados por el Equipo. • Es usado por el Equipo Scrum durante la Reunión de Planificación del Sprint para crear la Lista de Pendientes del Sprint y el Gráfico del Trabajo Consumido del Sprint. • También se utiliza para determiner cuando el equipo necesita reducer su compromiso, o cuando puede asumir Historias de Usuario adicionales durante la Planificación del Sprint. Lista de Tareas Actualizada • También puede haber re-estimaciones resultantes de una revision de los principios de Sprints, o un cambio en la comprensión colectiva del Equipo Scrum relacionado a las Historias de Usuario y los requisitos. Salidas Salidas

135. Proceso: 11. Elaboración de la Lista de Pendientes del Sprints Velocidad previa del Sprint • Velocidad del Sprint es la velocidad en la que el equipo puede completar el trabajo en un Sprint. • Por lo general, se expresa en las mismas unidades que las utilizadas para la estimación. • Se mantiene un registro de la Velocidad de Sprint del equipo para cada sprint y se utiliza como referencia en los siguientes Sprints. • Cualquier cambio en la situación o las condiciones desde el último sprint se tienen en cuenta para asegurar una estimación precisa de la Velocidad del Sprint para el próximo sprint. Calendario del Equipo • Contiene información sobre la disponibilidad de los miembros del equipo, incluyendo la información correspondiente a las vacaciones de los empleados, fechas de licencia, entre otros. • Ayuda al equipo no sólo en la planificación y ejecución de sprints eficientes, sino también en la alineación de Sprints con las fechas de liberación. Entradas Entrada Entrada

136. Proceso: 11. Elaboración de la Lista de Pendientes del Sprints Reuniones de Planificación del Sprint • Durante esta reunión, las Historias de usuario, los cuáles son aprobados, calculados, y con los cuales ya hay un compromiso, serán examinados por el Equipo Scrum. • El Equipo Scrum también crea la Lista de Pendientes del Sprint y Gráfica del Trabajo Consumido del Sprint. Herramientas de Seguimiento del Sprint • Una variedad de herramientas se puede utilizar para realizar el seguimiento del trabajo en un Sprint, pero uno de los más comunes es un ScrumBoard, también conocido como Task Board o Progress Chart. • El Scrumboard se divide en secciones: To Do (a veces conocido como Work not Started), Work in Progress, y Completed Work. Métricas de Seguimiento del Sprint • Velocidad. Representa el # de Historias de Usuario o# de funcionalidades entregadas en un solo Sprint. • Valor del Negocio Entregado. Mide el valor de las Historias de Usuario entregados desde el punto de vista comercial. Herramientas Herramientas Herramientas

137. Proceso: 11. Elaboración de la Lista de Pendientes del Sprints Lista de Pendientes del Sprint • Lista de las tareas a ser ejecutadas por el Equipo Scrum en el prósimo Sprint. • Es una práctica, que la Lista de Pendientes del Sprint se represente en un Scrumboard o tablero de tareas, que proporciona yna representación visible constantemente de la situación de las Historias de Usuario. • También se incluyen algunos riesgos asociados con las diversas tareas. Todas las actividades de mitigación para hacer frente a los riesgos identificados también serán incluidos como tareas. Gráfica del Trabajo Consumido del Sprint (Sprint Burndown Chart ) • Es un gráfico que muestra la cantidad de trabajo que queda en el Sprint actual. • Un gráfico relacionado es una Gráfico del Trabajo Realizado del Sprint (Sprint Burnup Chart) que muestra el trabajo realizado del Sprint. Salidas Salidas Salidas

139. Proceso: 12. Crear Entregables ScrumBoard El equipo utiliza un Scrumboard para planificar y realizar un seguimiento de los progresos realizados durante cada SprintEntrada

140. Proceso: 12. Crear Entregables Registro de Impedimentos Impedimento es cualquier obstáculo o barrera que reduce la productividad del Equipo Scrum. • Los impedimentos deben ser registrados formalmente por el Scrum Master en un registro de impedimentos, y pueden ser discutidos durante las Reuniones Diarias y la Reunión de Revisión del Sprint. Entrada

141. Proceso: 12. Crear Entregables Experiencia del Equipo Se refiere a la experiencia colectiva de los miembros del Equipo Scrum para entender las Historias de Usuario y tareas en la Lista de Pendientes del Sprint con el fin de crear los entregables finales. • Los miembros del Equipo Scrum tienen la autoridad y la responsabilidad de determinar los mejores medios para convertir los elementos de la Lista Priorizada de Pendientes del Producto en productos terminados, sin necesidad de participación de todos los socios del equipo. Software • Las herramientas automatizadas pueden ser utilizadas para la programación, la recopilación de información y la distribución Herramientas Herramientas

142. Proceso: 12. Crear Entregables Entregrables del Sprint • Al final de cada Sprint, se complete un mínimo de productos o entregables. • La entrega debe poseer todas las características y funcionalidades definidas en las Historias de Usuario incluidas en el Sprint, las cuales deben ser probadas con éxito. Scrumboard actualizado • Se actualiza con regularidad a medida que el equipo produce más trabajo. • Al final del Sprint, el Scrumboard se restablecerá o borrará y un Nuevo Scrumboard se creará para el próximo Sprint. Riesgos mitigados • A medida que el Equipo Scrum ejecuta el trabajo de los entregables de acuerdo a las Historias de Usuario en la Lista Priorizada de Pendientes del Producto, lleva a cabo las acciones de mitigación que se han definido para abordar cualquier riesgo identificado. • El equipo documenta los nuevos riesgos identificados y las medidas de mitigación adoptadas. • El registro de los riesgos del proyecto es un documento vivo, actualizado de forma continua durante todo el proyecto Salidas Salidas Salidas

143. Proceso: 13. Llevar a cabo el Standup Diario Experiencia del día previo • Los miembros del Equipo Scrum mantienen al tanto a sus compañeros de equipo en la Reunión Diaria. • Esta sesión se denomina Standup porque los miembros están de pie durante toda la reunión. • Los miembros del equipo discuten logros y la experiencia del días anterior. Entrada

144. Proceso: 13. Llevar a cabo el Standup Diario Reunión Diaria Standup • Es una reunión diaria de corta duración. • Time-boxed a 15 minutos. • Los miembros del equipo se reúnen para informar de sus progresos en el Sprint y planificar las actividades del día. • La duración de las reuniones es muy corta y se espera que todos los miembros del Equipo Scrum asistan. • La reunión no se cancela o se retrasa si uno o más miembros no pueden asistir. • En la reunión, cada miembro del Equipo Scrum proporciona respuestas a las tres preguntas diarias. • Se recomiendan los debates entre el Scrum Master y el equipo o entre algunos miembros del Equipo Scrum, pero estas discusiones suceden después del Daily Standup para asegurar que la reunión sea corta. Herramientas Herramientas

145. Proceso: 13. Llevar a cabo el Standup Diario Tres preguntas diarias • En la Reunión Diaria Standup, facilitado por el Scrum Master, cada miembro del Equipo Scrum proporciona información en forma de respuestas a las tres preguntas específicas: ¿Qué Hice ayer? ¿Qué voy hacer hoy? ¿Qué impedimentos u obstáculos (si los hay) estoy enfrentando en la actualidad? • Al centrarse en estas tres preguntas, todo el equipo puede tener una comprensión clara de la situación laboral. • En ocasiones, otros elementos pueden ser discutidos, pero esto se reduce al mínimo para respetar el aspecto time-boxed de la reunión. • Es muy recomendable que las dos primeras preguntas sean respondidas por los miembros del equipo de manera cuantificable, si es posible, en lugar de respuestas largas y cualitativas. Herramientas

146. Proceso: 13. Llevar a cabo el Standup Diario Cuarto de Guerra • En Scrum, es preferible que el equipo esté colocado, en otras palabras, que todos los miembros del equipo trabajen en el mismo lugar. • Está diseñado de tal manera que los miembros del equipo pueden moverse libremente, trabajar y comunicarse fácilmente ya que se encuentran cerca el uno del otro. • Típicamente, hay tarjetas índices, fichas, notas adhesivas, y otras herramientas de baja tecnología, y de alto contacto, que se encuentran disponibles en el Cuarto de Guerra para facilitar el flujo de trabajo, la colaboración y la resolución de problemas. • La sala es a veces ruidosa debido a las conversaciones del equipo, pero estas conversaciones contribuyen al progreso del equipo. • Un buen Cuarto de Guerra no tiene cubículos y permite que todo el equipo se siente junto para asegurar la comunicación cara a cara, lo que conduce a la formación de equipos y la apertura. Videoconferencia • Cuando el equipo está distribuido, se hace imperativo el uso de herramientas de videoconferencia para permitir la comunicación cara a cara Herramientas Herramientas

147. Proceso: 13. Llevar a cabo el Standup Diario Equipo Scrum Motivado Reuniones Diarias Standup propagan la idea de que cada miembro del equipo es valioso y es un importante contribuyente, lo que mejora la moral individual del equipo. • Esto, junto con el concepto de equipos de auto-organizacón, mejora la motivación general, conduce a un major rendimiento del equipo y mejora la calidad de los resultados producidos. Salidas

148. Proceso: 14. Mantenimiento de la Lista Priorizada de Pendientes del Producto Entregables Rechazados • En los casos en que una entrega no cumpla con los criterios de aceptación, esto se considera como entregables rechazados. • Los entregables rechazados normalmente no se encuentran en una lista separada. Simplemente permanecen en la Lista Priorizada de Pendientes del Producto y no son marcados como “Terminado” para que puedan ser repriorizados y sean considerados para el desarrollo en el próximo Sprint. Lista de Pendientes del Producto del Programa actualizado • Los cambios en la Lista de Pendientes del Producto del Programa pueden ser el resultado de cambios en cualquiera de las condiciones internas o externas. • Las condiciones externas pueden incluir el cambio de situaciones de negocio, tendencia de la tecnología, o requisitos de cumplimiento legal. • Los factores internos podrían estar relacionados con las modificaciones en la estrategia o las políticas de la organización, riesgos identificados y de otros factores. Entradas Entrada Entrada

149. Proceso: 14. Mantenimiento de la Lista Priorizada de Pendientes del Producto Reuniones de Revisión Lista de Pendientes del Producto del Programa • El Propietario del Producto puede tener reuniones múltiples y separadas con los socios, el Scrum Master y el Equipo Scrum relevante para asegurar que él o ella tenga suficientes información para hacer cambios en la Lista Priorizada de Pendientes del Producto. • La intención de las reuniones es asegurar que las Historias de Usuario y los Criterios de Aceptación se entiendan y se escriban correctamente por el Propietario del Producto de modo que reflejen los requisitos de los Interesados; que las Historias de Usuario sean entendidos por todos los miembros de Equipo Scrum; y que las Historias de Usuario de los usuarios de alta prioridad sean refinados para que el Equipo Scrum pueda estimar correctamente y comprometerse con este tipo de Historias de Usuario. Pendientes del Producto Técnicas de comunicación • Scrum promueve la comunicación precisa y eficaz sobre todo a través de colocación del Equipo Scrum. Herramientas Herramientas Herramientas

150. Proceso: 14. Mantenimiento de la Lista Priorizada de Pendientes del Producto Lista Priorizada de Pendientes del Producto actualizado • Puede ser actualizado con nuevas Historias de Usuario, nuevas Solicitudes de Cambio, nuevos Riesgos Identificados, Historias de Usuario actualizados, o la nueva prorización de Historias de Usuario existentes. Cronograma de Planificación de Liberaciones actualizado. • Puede ser actualizado para reflejar el impacto de las Historias de Usuario nuevas o modificadas en la Lista Priorizada de Pendientes del Producto. Salidas Salidas Salidas

152. Proceso: 15. Convocar Scrum de Scrums Scrum Master o Representantes Equipo Scrum • Normalmente, un miembro de cada Equipo Scrum representará a su equipo en la Reunión de Scrum de Scrums • En la mayoría de los casos, este es el Scrum Master, pero a vece alguien más puede representar al equipo. Agenda de la Reunión • El propósito de la reunión es comunicar el progreso entre múltiples equipos. • El Jefe Scrum Master (o cualquier Scrum master que facilite la reunión) puede anunciar una agenda antes de la reunión. • Cualquier impedimento que enfrente un equipo que pueda afectar a otros equipos, se debe indicar para ser tratado durante la reunión SoS. • Además si un equipos de da cuenta de un problema de gran escala, un cambio o riesgo que pueda afectar a otros equipos, esto debe ser comunicado en la reunión SoS. Entradas Entrada Entrada

153. Proceso: 15. Convocar Scrum de Scrums Reuniones Scrum de Scrums • Son reuniones preferentemente cortas (no time-boxed para permitir un mayor intercambio de información entre equipos) donde los representantes de los Equipos Scrum se reúnen para compartir el estado de los equipos respectivos. • La Reunión SoS se llevará cabo en intervalos predefinidos o cuando sea requerido por los Equipos Scrum. Cuatro preguntas por equipo • Cada representante del equipo Scrum proporcionará actualizaciones de su equipo. • ¿En qué ha estado trabajando mi equipo desde la última reunión? • ¿Qué va a hacer mi equipo hasta la próxima reunión? • ¿Con qué contaban otros equipos que mi equipo hiciera que no se ha hecho? • ¿Qué piensa hacer nuestro equipo que pueda afectar a otros equipos? Herramientas Herramientas

154. Proceso: 15. Convocar Scrum de Scrums Reuniones Scrum de Scrums • Son reuniones preferentemente cortas (no time-boxed para permitir un mayor intercambio de información entre equipos) donde los representantes de los Equipos Scrum se reúnen para compartir el estado de los equipos respectivos. • La Reunión SoS se llevará cabo en intervalos predefinidos o cuando sea requerido por los Equipos Scrum. Cuatro preguntas por equipo • Cada representante del equipo Scrum proporcionará actualizaciones de su equipo. • ¿En qué ha estado trabajando mi equipo desde la última reunión? • ¿Qué va a hacer mi equipo hasta la próxima reunión? • ¿Con qué contaban otros equipos que mi equipo hiciera que no se ha hecho? • ¿Qué piensa hacer nuestro equipo que pueda afectar a otros equipos? Herramientas Herramientas

155. Proceso: 15. Convocar Scrum de Scrums Mejor Coordinación del Equipo • La reunion SoS facilita la coordinación de trabajo entre varios Equipos Scrum. • Esto es especialmente importante cuando hay tareas que impliquen dependencias entre equipos. • Mediante el uso de reunions SoS, las organizaciones tienen más Colaboración que las personas que trabajan en equipos cerrados donde esencialmente se preocupan por sus propias responsabilidades. Problemas Resueltos • Reuniones SoS es un foro donde todos los miembros del Equipo Scrum tienen la oportunidad de debater de forma transaparente los problemas que influyen es nsu proyecto. • Esta discusión oportuna y la resolución de problemas en la reunion SoS mejora en gran medida la coordinación entre los diferentes Equipos Scrum, y también reduce la necesidad de crear un Nuevo trabajo y diseñ Salidas Salidas

156. Proceso: 16. Demostración y Validación del Sprint Reuniones de Revisión del Sprint • Los miembros del Equipo Principal de Scrum y los Interesados correspondientes participan en esta reunión para aceptar los entregables en acuerdo con los Criterios de Aceptación, y donde se rechazan las entregas inaceptables. • Estas reuniones son convocadas al final de cada Sprint. • El Equipo Scrum demuestra los logros del Sprint, incluyendo las nuevas funcionalidades o productos creados. • Esto proporciona una oportunidad para que el Propietario del Producto y los Interesados inspeccionen lo que se ha completado hasta el momento, y para determinar si algún cambio se debe hacer en el proyecto o procesos en Sprints posteriores Herramientas

157. Proceso: 16. Demostración y Validación del Sprint Entregables Aceptados • Los entregables que cumplen con los Criterios de Aceptación son aceptados por el Propietario de Producto. • El objetivo de un Sprint es crear entregables potencialmente listos para ser entregados, o incrementos de productos que cumplan con los Criterios de Aceptación definidos por el Cliente y el Propietario del Producto. Entregables Rechazados • Si los entregables no cumplen con los Criterios de Acpetación, tales entregables son rechazados. Salidas Salidas

158. Proceso: 17. Retrospectiva del Sprint Reuniones de Retrospectiva del Sprint • Es un elemento importante del marco de Scrum llamado “inspeccionar- adaptar” y es el paso final en un sprint. • Todos los miembros del Equipo Scrum asisten a la reunión, que es facilitada o moderada por el Scrum Master. • Se recomienda, pero no se requiere que el Propietario de Producto asista. • Un miembro del equipo documenta las charlas y los elementos para acciones futuras. • Es esencial tener esta reunión en un ambiente abierto y relajado para obtener la participación de todos los miembros del equipo. • Los objetivos principales de la reunión son identificar tres elementos específicos: Las cosas que el equipo tiene que seguir haciendo: mejores prácticas Las cosas que el equipo necesita empezar a hacer: mejoras en el proceso Las cosas que el equipo necesita dejar de hacer: problemas de proceso y embotellamiento • Estas áreas se discuten y una lista de Acciones de Mejora Acordadas es creada. Herramientas Herramientas

159. Proceso: 17. Retrospectiva del Sprint Explorer – Shopper – Vacationer – Prisoner (ESVP) • Este es un ejercicio que puede realizarse al inicio de la reunión para entender la mentalidad de los participantes y establecer el tono de la reunión. • Se les pide a los asistentes que indiquen de forma anónima el término que mejor representa cómo se sienten con respecto a su participación en la reunión. Explorer. Quiere participar y aprender todo lo que se discutió en la retrospectiva. Shopper. Quiere escuchar todo y elegir lo que desea de la retrospectiva. Vacationer. Quiere relajarse y ser turista en la retrospectiva. Prisoner. Quiere estar en otro lugar y asiste a la retrospectiva ya que se requiere. • El Scrum Master luego recopila las respuestas, prepara y comparte la información con el grupo. Herramientas

160. Proceso: 17. Retrospectiva del Sprint Reuniones Scrum de Scrums • Son reuniones preferentemente cortas (no time-boxed para permitir un mayor intercambio de información entre equipos) donde los representantes de los Equipos Scrum se reúnen para compartir el estado de los equipos respectivos. • La Reunión SoS se llevará cabo en intervalos predefinidos o cuando sea requerido por los Equipos Scrum. Cuatro preguntas por equipo • Cada representante del equipo Scrum proporcionará actualizaciones de su equipo. • ¿En qué ha estado trabajando mi equipo desde la última reunión? • ¿Qué va a hacer mi equipo hasta la próxima reunión? • ¿Con qué contaban otros equipos que mi equipo hiciera que no se ha hecho? • ¿Qué piensa hacer nuestro equipo que pueda afectar a otros equipos? Herramientas Herramientas

161. Proceso: 17. Retrospectiva del Sprint Speed Boat • Es una técnica que se puede utilizar para llevar a cabo la reunión de Retrospectiva. • Los miembros del equipo hacen que son tripulantes en un speed boat. El barco debe llegar a una isla, lo cual es simbólico de la visión del proyecto. • Las notas adhesivas son utilizadas para registrar “los motores” y “anclas”. Los motores les ayudan a llegar a la isla, mientras que los anclajes les impiden llegar. • Este ejercicio es time-boxed a unos pocos minutos. • Una vez que todos los elementos están documentados, la información se analiza y prioriza mediante un proceso de votación. Los motores se reconocen y se planifican las acciones de mitigación de los anclajes, dependiendo de la prioridad. Métricas y técnicas de medición • Velocidad de Equipo. # Puntos de Historia hecho en un determinado Sprint. • Índice de éxito de Terminado. % de Puntos de Historia que han sido Terminados, en relación a los que se han llevado a cabo. Herramientas Herramientas

162. Proceso: 17. Retrospectiva del Sprint Métricas y técnicas de medición • Estimación de eficacia. # o % de discrepancia entre el tiempo previsto y el tiempo verdadero que se ha utilizado en las tareas e Historias de Usuario. • Clasificación de retroalimentación de repaso. La retroalimentación puede ser solicitada por los Interesados, usando calificaciones cuantitativas o cualitativas que proporcionan una medición del rendimiento del equipo. • Calificación de la moral del equipo. El resultado de autoevaluaciones de la moral del equipo. • Retroalimentación de los compañeros. Retroalimentación de 360 grados se puede utilizar para solicitar información y crítica constructiva sobre el rendimiento del equipo. • Progreso para la liberación. El valor del negocio proporcionado en cada versión, así como el valor representado por el progreso actual hacía una liberación Herramientas

163. Proceso: 17. Retrospectiva del Sprint Acciones de Mejora Acordadas • Es el primer resultado del proceso. Es la lista de elementos configurables que el equipo ha llegado a hacer frente a los problemas y mejorar los procesos con el fin de mejorar su desempeño en el futuro Sprint. Elementos de Acción Acordados y Fechas • Una vez que las Acciones de Mejora Acordadas se han elaborado y refinado, los puntos de acción para aplicar las mejoras pueden ser considerados por el Equipo Scrum. • Cada elemento de acción tendrá una fecha de vencimiento definida para su conclusión Salidas Salidas

165. Proceso: 18. Envío de Entregables Plan Piloting • Es una entrada opcional que se puede utilizar para trazar una implementación piloto en detalle. • El alcance y los objetivos del despliegue, despliegue objetivo base de usuarios, un cronograma de implementación, planes de transición, preparación de usuario necesaria, los criterios de evaluación para el despliegue, y otros elementos relacionados con el despliegue se especifican en este plan y son compartidos con los socios. Entradas . Entrada

166. Proceso: 19. Retrospectiva del Proyecto

167. 2.4. Ventajas de Scrum

168. Backlog del producto Backlog del sprint Incremento del producto con calidad productiva Sprint de 2-4 semanas Scrum diario

169. Gestión regular de las expectativas del cliente El cliente establece sus expectativas indicando el valor que le aporta cada requisito del proyecto y cuando espera que esté completado. El cliente comprueba de manera regular si se van cumpliendo sus expectativas, da feedback, ya desde el inicio del proyecto puede tomar decisiones informadas a partir de resultados objetivos y dirige estos resultados del proyecto, iteración a iteración, hacia su meta. Se ahorra esfuerzo y tiempo al evitar hipótesis.

170. Resultados anticipados (“time to market”) • El cliente puede empezar a utilizar los resultados más importantes del proyecto antes de que esté finalizado por completo. • Siguiendo la ley de Pareto (el 20% del esfuerzo proporciona el 80% del valor), el cliente puede empezar antes a recuperar su inversión (y/o autofinanciarse) comenzando a utilizar un producto al que sólo le faltan características poco relevantes, puede sacar al mercado un producto antes que su competidor, puede hacer frente a urgencias o nuevas peticiones de clientes, etc.

171. Flexibilidad y adaptación • De manera regular el cliente redirige el proyecto en función de sus nuevas prioridades, de los cambios en el mercado, de los requisitos completados que le permiten entender mejor el producto, de la velocidad real de desarrollo, etc. • Al final de cada iteración el cliente puede aprovechar la parte de producto completada hasta ese momento para hacer pruebas de concepto con usuarios o consumidores y tomar decisiones en función del resultado obtenido.

172. Retorno de inversión (ROI) • De manera regular, el cliente maximiza el ROI del proyecto. Cuando el beneficio pendiente de obtener es menor que el coste de desarrollo, el cliente puede finalizar el proyecto.

173. Mitigación de riesgos • Desde la primera iteración el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigación de manera anticipada. "Si hay que equivocarse o fallar, mejor hacelo lo antes posible". El feedback temprano permite ahorrar esfuerzo y tiempo en errores técnicos. • La cantidad de riesgo a que se enfrenta el equipo está limitada a los requisitos que se puede desarrollar en una iteración. La complejidad y riesgos del proyecto se dividen de manera natural en iteraciones

174. Equipo motivado • Las personas están más motivadas cuando pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo. • Las personas se sienten más satisfechas cuando pueden mostrar los logros que consiguen.

175. ¿Qué beneficios y ventajas le va a proporcionar el método SCRUM a mi negocio?

176. A) A NIVEL DE LA PLANTILLA: • Se crean roles que fomentan el trabajo en equipo: el Product Owner delimita aquello a construir en el próximo sprint, el equipo de desarrollo se encarga de llevar a cabo el trabajo y de presentarlo al cliente. A partir del feedback del cliente se decide cómo se encaminara el siguiente sprint. Por último el Scrum Masters se asegura que todo este proceso ocurre de una forma óptima en las mejores condiciones. • Incremento de la motivación de los trabajadores: los equipos de trabajo se autogestionan sus tareas y además ven los frutos de su trabajo rápidamente ya que en un breve periodo de tiempo pueden enseñarle su “obra” al cliente. • Fomenta la creatividad de la plantilla: breves espacios de tiempo con necesidad de innovar hacen sacar lo mejor de uno mismo y de un grupo de trabajo.

177. B) A NIVEL DE PROCESOS: • Transparencia en el desarrollo de los procesos y mayor control de cada etapa: se trabaja alrededor de un documento llamado sprint backlog en el cual se especifica cómo el equipo de trabajo va a llevar a cabo las tareas durante el siguiente sprint Cada tarea especificada en este documento se divide en horas y no es asignada a un miembro en concreto sino que es trabajada de un modo conjunto y multidisciplinar por de los diferentes miembros del equipo. • Feedback continua y ritmo predictible de trabajo: se tiene un gran control sobre el desarrollo de cada etapa, los errores pueden ser rectificados rápidamente sin afectar prácticamente al timming (sin la implementación del método SCRUM esto sería inviable). Por este motivo se mejora la calidad del producto/ servicio. • Pone en sintonía al cliente con el proveedor (equipo de desarollo), estrechando los lazos colaborativos cara a cara y creando productos y servicios adaptados sistemáticamente a las necesidades del cliente (ahorro de tiempo). ¡De este modo se cumple aquello que se promete! • El mayor coste de su implementación no es el de una inversión económica sino que viene determinado por los esfuerzos y la capacidad para organizar y gestionar correctamente la adopción de esta metodología.

178. C) A NIVEL DE RESULTADOS • Mayor productividad: incrementa la productividad fruto del incremento de la motivación grupal y del control de cada etapa contenido en un timeline (que es muy breve y específico); conjuntamente propician una reducción de los riesgos en todo el proceso. • Permite una adaptabilidad a los cambios continuos del mercado aportando así una ventaja competitiva: se genera una gran capacidad de reacción frente a las novedades empresariales. • Maximiza el retorno de la inversión (ROI): esto se consigue gracias a invertir el tiempo, dinero y esfuerzo a aquello que realmente ofrece valor al negocio, la priorización de las necesidades del cliente en cada momento juegan un papel clave.

Scrum trainer freddy vargas clase 3

Estás leyendo una previsualización.

Eche un vistazo a continuación

Scrum trainer freddy vargas clase 3

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a Scrum trainer freddy vargas clase 3 (20)

Más reciente (20)