Fundamentos en Scrum
Descargar como PPTX, PDF6 recomendaciones3,149 vistas
El documento detalla la implementación de Scrum en IT Synergy, destacando el Manifiesto Ágil y los valores y principios que guían esta metodología. Se describen los roles fundamentales en Scrum, incluyendo el Product Owner, Scrum Master y el equipo de desarrollo, junto con los artefactos y actividades esenciales para la práctica de Scrum. Además, se mencionan logros y próximos pasos para continuar la adopción de prácticas ágiles en los proyectos de la organización.
Fundamentos en Scrum
- 1. BestGrowInn Scrum en el Mundo Real iT Synergy 30-10-2017
- 2. AGENDA 01 02 03 04 Manifiesto Agil Valores Scrum Scrum Roles Scrum 06 Logros Scrum en iTS y Próximos Pasos05Actividades Scrum
- 3. Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. Fuente: http://agilemanifesto.org/iso/es/manifesto.html Objetivo | Capacitación de <bajo/alto> nivel Manifiesto por el Desarrollo Ágil de Software
- 4. Principios del Manifiesto Ágil 03 0201 06 04 05 Aceptamos que los requisitos cambien incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Entregamos software funcional frecuentemente entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. Los proyectos se desarrollan en torno a individuos motivados Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. El método más eficiente y efectivo de comunicar información es la conversación cara a cara.
- 5. Principios del Manifiesto Ágil 09 0807 12 10 11 Los procesos Ágiles promueven el desarrollo sostenible Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado Es esencial El software funcionando es la medida principal de progreso. A intervalos regulares el equipo reflexiona Sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia
- 6. Scrum es el más conocido de los frameworks Ágiles. Es la fuente de gran parte del pensamiento que se encuentra detrás de los principios y valores del Manifiesto Ágil. Scrum es un framework pensado para construir productos: todo comienza cuando tenemos stakeholders que necesitan uno. Revisión de Roles, Artefactos y Actividades Que es Scrum
- 7. Valores Scrum 01 05 04 03 02 Coraje Porque no estamos solos, nos sentimos apoyados y tenemos más recursos a nuestra disposición. Esto nos da el coraje para enfrentar desafíos más grandes. Apertura Durante el trabajo en conjunto expresamos cotidianamente cómo nos va y qué problemas encontramos. Aprendemos que es bueno manifestar las preocupaciones, para que éstas puedan ser tomadas en cuenta Respeto A medida que trabajamos juntos, compartiendo éxitos y fracasos, llegamos a respetarnos los unos a los otros, y a ayudarnos mutuamente a convertirnos en merecedores de respeto. Compromiso Porque tenemos gran control sobre nuestro destino, nos comprometemos más al éxito Foco Porque nos enfocamos en sólo unas pocas cosas a la vez, trabajamos bien juntos y producimos un resultado excelente. De este modo logramos entregar ítems valiosos antes
- 8. Roles Scrum Product Ownertiene la responsabilidad de decidir qué trabajo deberá ser realizado de acuerdo a las necesidades y prioridades del negocio. Scrum Master actúa como líder servicial, ayudando al equipo y a la organización a hacer el mejor uso de Scrum. Equipo de Desarrollo construye el producto en forma incremental, en una serie de períodos cortos de tiempo llamados Sprints.
- 9. Roles Scrum – Product Owner Product Owner • Es la única persona responsable de delinear el producto más valioso posible para la fecha deseada. • El PO mantiene el Product Backlog y asegura que todos sepan qué hay en él y cuáles son las prioridades. • El PO no es responsable de todo. El Equipo Scrum completo es responsable de ser lo más productivo posible, de mejorar sus prácticas, de hacer las preguntas correctas, de ayudar al Product Owner. • El Equipo de Desarrollo es responsable de determinar cuánto trabajo puede ser tomado en un Sprint, y de producir un Incremento de Producto al finalizar el mismo • El PO lleva adelante esta tarea mediante la gestión del Product Backlog y asegurándose que el Product Backlog y el avance contra éste se mantengan visibles. • El PO, al decidir sobre qué debe hacer y qué debe posponer el Equipo de Desarrollo, toma las decisiones de alcance versus fechas que llevan al mejor producto posible.
- 10. Roles Scrum – Scrum Master Scrum Master • El ScrumMaster es un "líder servicial", que ayuda al resto del equipo Scrum a seguir su proceso. Debe tener una buena comprensión de Scrum y la habilidad de capacitar a otros en sus sutilezas. • El ScrumMaster trabaja junto al Product Owner para que éste logre crear y mantener el Product Backlog. • El ScrumMaster también es responsable de velar por la remoción de los impedimentos al avance del equipo. Estos impedimentos pueden ser externos al equipo, como por ejemplo la falta de apoyo de otro equipo, o internos, como ser que el Product Owner no sepa preparar el Product Backlog de forma adecuada. • El ScrumMaster fomenta la auto-organización. Los problemas deben ser resueltos por el equipo siempre que sea posible. • El ScrumMaster actúa como coach para el Equipo Scrum, ayudando a sus miembros a ejecutar el proceso Scrum. • El ScrumMaster es responsable de asegurar que Scrum sea comprendido e implementado, tanto dentro como fuera del equipo. Ayuda a personas fuera del equipo a entender el proceso y a comprender qué interacciones con el equipo son valiosas y cuáles no. El ScrumMaster ayuda a todos a mejorar para que el equipo Scrum sea más productivo y valioso.
- 11. Roles Scrum – Equipo de Desarrollo Equipo de Desarrollo • Está compuesto por los profesionales que hacen el trabajo necesario para poder entregar el Incremento de Producto. • Se auto-organizan para realizar su trabajo. • Scrum requiere que el Equipo de Desarrollo esté conformado por un grupo interdisciplinario de personas que, entre todos, reúnan las habilidades necesarias para entregar cada incremento del producto. • Los miembros del Equipo de Desarrollo tienen la responsabilidad de auto-organizarse para lograr el objetivo del Sprint, produciendo cada nuevo Incremento de Producto siguiendo el Plan del Sprint. • El Product Owner crea una lista ordenada de lo que hay que hacer. Los miembros del Equipo de Desarrollo hacen un pronóstico de cuánto pueden realizar en un Sprint y deciden cómo lo van a llevar a cabo.
- 12. Artefactos Scrum Incremento del Producto El artefacto más importante en Scrum es el Incremento de Producto. Cada Sprint produce un Incremento de Producto. Éste debe ser de calidad lo suficientemente alta como para ser entregado a usuarios finales. El Incremento de Producto debe cumplir con la Definición de Hecho (Done) actual del Equipo Scrum y cada parte del mismo debe ser aceptable para el Product Owner Sprint Backlog El Sprint Backlog es la lista de ítems del Product Backlog refinados que han sido elegidos para ser desarrollados en el Sprint actual, junto al plan del equipo para poder realizar el trabajo. Refleja el pronóstico de qué trabajo puede ser completado. Generado el Sprint Backlog, comienza el Sprint y el Equipo de Desarrollo desarrolla el nuevo Incremento de Producto definido por el Sprint Backlog. Product Backlog Es una lista ordenada de ideas para el producto, mantenida en el orden en que esperamos llevarlas a cabo. Toda idea de funcionalidad, mejora, bug fix, requerimiento de documentación, todas y cada una de las tareas que llevan a cabo se deriva de un ítem de Product Backlog. Cada ítem en el Product Backlog incluye una descripción y una estimación.
- 13. Actividades Scrum 01 05 04 03 02 Sprint Planning • Comprender el trabajo a realizar por el equipo de trabajo. • Acuerdo del equipo sobre el trabajo necesario • Duración de 2 a 4 horas. • Se determina el qué y el cómo se va a realizar y entregar al cliente. Daily Meeting Cada miembro del equipo cuenta tres cosas: • Qué he logrado desde el último scrum diario. • Qué pienso lograr entre este momento y el próximo scrum diario. • Qué está impidiendo mi avance. Sprint Retrospective Revisión de: • El proceso • Relación entre las personas • Potenciales mejoras • Duración de 1 hora Sprint Review • Duración máxima de 1 hora. • Discusión del incremento del producto logrado. • Se realiza por lo general demo del producto. No ppt. • Se actualiza el backlog como parte de la revisión del sprint. Refinamiento del Product Backlog Esta actividad se limita a: • Mantener el Product Backlog Ordenado • Eliminar items que no sean importantes • Agregar items, dividir, unir y estimar items
- 14. Logros SCRUM en iTS 03 0201 06 04 05 Alineación de procesos internos con SCRUM y DevOps Alineación de los procesos internos de Ingeniería con prácticas SCRUM y DevOps. Participación en Proyectos SCRUM externos Para observar las mejores prácticas, personalizarlas y aplicarlas en iTS. Incorporación de Actividades SCRUM en los Proyectos Se empieza a utilizar Dailys, Revisión de Sprint y Retrospectivas en los proyectos Estándar para Levantamiento de Información en Historias de Usuario Se construye desde los proyectos de PS y Super Sociedades. VSTS como herramienta de proyectos Para cualquier tipo de proyecto en iTS: Infra, desarrollo, BI, migración, etc. Proyecto Interno de Centro de Excelencia iTS. Para apoyar las nuevas metodologías y prácticas que soportan la base de la Transformación Digital en iTS
- 15. • Estimaciones por Puntos • Estados de Flujos • Ejecución de las actividades de scrum Políticas en iT Synergy con Scrum
- 16. Puntos de Historia de Usuario La unidad de estimación preferida en el agilísimo se denomina Puntos de Historia de Usuario (Story Points). Es una unidad que tiene en cuenta el tamaño y la complejidad de la tarea, y mide el peso relativo de cada una de las historias en estimación. Estimaciones en Scrum En la figura se muestra el tamaño relativo de dos cilindros comparados con el cilindro base (1x). Para el ser humano es más fácil utilizar medidas relativas que absolutas. ¿Cuántas onzas tiene una gaseosa grande? ¿Si no lo sabe por qué la pide? Porque conoce el tamaño relativo de las grandes y las pequeñas.
- 17. Para planificar un proyecto de software y realizar un seguimiento de los bugs mediante Scrum, los equipos usan el Product BackLog Item (PBI) y bug work ítems Type (WIT). Para obtener información en el portafolio de features, escenarios o experiencias de usuario, los Product Owners y los program manager pueden asociar PBI y Bugs a los features. Cuando los equipos trabajan en sprints, definen tareas que se vinculan automáticamente a los PBI y Bugs. Portafolio del Backlog
- 18. Estados en los Flujos de Scrum Product Backlog Item Bug Task
- 19. Sprint Review: Se debe realizar al finalizar el sprint pero dentro de las fechas del Sprint. Sprint Retrospective: Se debe realizar al finalizar el sprint, no necesariamente debe realizarse dentro de las fechas del Sprint. Sprint Planning: Se debe realizar antes de iniciar el Sprint, no necesariamente debe realizarse dentro de las fechas del Sprint Daily Scrum: Se debe realizar diario Ejecución de Actividades de Scrum
- 20. Próximos Pasos Entrenamiento en Prácticas Ágiles. Continuar Adoptación SCRUM y DevOps en Proyectos iTS Consolidar prácticas Ágiles no sólo en los proyectos sino en todas las áreas de iTS. Preparar Plan de Certificaciones.
- 21. /iTSynergy @iTSynergy iTSynergy iT Synergy Co Jimmy Quejada Software Engineer www.itsynergy.co (+571) 8058003 | (+57) 316 8770568 Jimmy.quejada@itsynergy.co
Notas del editor
- #4: El manifiesto ágil es un documento que resume en cuatro valores y doce principios las mejores prácticas para el desarrollo de software, basados en la experiencia de 17 industriales del software, en procura de desarrollos más rápidos conservando su calidad. Este artículo presenta de manera general la evolución de las metodologías para el desarrollo de software y una reseña de los valores y principios del manifiesto ágil. Seguimos estos principios: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. El software funcionando es la medida principal de progreso. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
- #8: A través del uso del trabajo en equipo y la mejora continua, Scrum tanto crea como depende de estos valores
- #13: El Product Backlog puede comenzar como una lista extensa o breve. Puede estar descrito de forma detallada o muy vaga. Típicamente empieza siendo breve e impreciso y se va convirtiendo en más extenso y concreto con el correr del tiempo. Aquellos ítems del Product Backlog que estén programados para ser implementados en breve serán "refinados": es decir clarificados, definidos en mayor detalle, divididos en fracciones más pequeñas, como parte de la actividad de Refinamiento del Product Backlog. El Product Owner es responsable de mantener el Product Backlog, aunque puede y deberíarecibir ayuda para construirlo y mantenerlo actualizado. Los ítems del Product Backlog pueden surgir del Product Owner, los miembros del Equipo de Desarrollo o incluso de otras partes interesadas.