Metodología de desarrollo SCRUM
•
1 recomendación•912 vistas
Orienta el ingeniero en Electrónica Víctor Garzón Marín y CSo. de Smartsoft PLAY. SCRUM: minimiza el el riesgo en el desarrollo de proyectos de software de manera colaborativa.
Recomendados
Recomendados
Más contenido relacionado
Último
Último (20)
Destacado
Destacado (20)
Metodología de desarrollo SCRUM
- 2. V í c t o r G a r z ó n M a r í n Ing. Electrónica y Telecomunicaciones MSc (C) Telemática Universidad del Cauca C To . S m a r t s o f t P L AY S c r u m M a s t e r C e r t i f i e d Scrum Agile Institute vgarzom@gmail.com
- 5. Certeza y Acuerdo Sim pleCom plicado Com plejo Anarquía Alta certeza Baja certeza AltoacuerdoBajoacuerdo Stacey RD. Strategic management and organizational dynamics: the challenge of complexity. 3rd ed. Harlow: Prentice Hall, 2002
- 6. Efectividad de la comunicación Papel (Documentos) Grabación de Audio Grabación de Video 2 personas por e-mail 2 personas por telefono 2 personas en un tablero
- 8. Manifiesto Ágil Personas e interacciones sobre procesos y herramientas Software funcionando sobre documentación comprensible Colaboración con clientes sobre negociación de contratos Responder a los cambios sobre seguir un plan Aunque hay valor en los elementos de la derecha valoramos más los de la izquierda
- 10. Entrega de valor PROYECTOS TRADICIONALES PROYECTOS ÁGILES Análisis Diseño Desarrollo Pruebas Valor para el cliente: Producto Entregado Iteración 1 Iteración 2 Iteración 3 … Iteración n Valor para el cliente: Producto Entregado
- 13. Razones de fracaso de proyectos ágiles 2014, VersionOne, Inc. All Rights Reserved. Annual State of Agile Development Survey
- 14. Por qué SCRUM?
- 15. Métodos Ágiles • Scrum (Ken Schwaber) • XP (Kent Beck) • Lean Software Development (Mary Poppendieck) • Crystal(Alistair Cockburn) • Dynamic System Development Method (Dane Faulkner) • Adaptive Software Development (Jim Highsmith) • Feature Driven Development (Jeff DeLuca) Más preceptivo (Más reglas para seguir) RUP (120+) XP (13) SCRUM (9) Kanban (3) Do Wathever!! (0) Más adaptativo (menos reglas para seguir)
- 16. Métodos Ágiles 2014, VersionOne, Inc. All Rights Reserved. Annual State of Agile Development Survey Scrum y sus variantes representan más del 73% de las metodologías que están siendo usadas.
- 17. Beneficios • Se puede gestionar las expectativas del cliente de manera regular (requisitos desarrollados, velocidad de desarrollo, calidad), y se puede tomar decisiones en cada iteración. Considera que: – El cliente no sabe exactamente qué es lo que necesita, lo va sabiendo conforme va viendo cuales son los resultados del proyecto. – El cliente necesita hacer cambios a corto plazo (nuevos requisitos o cambios en los ya realizados). – El equipo necesita saber si lo que ha entendido es lo que el cliente espera.
- 18. Beneficios • El cliente puede obtener resultados importantes y utilizables desde las primeras iteraciones. • El cliente puede comenzar el proyecto con requerimientos de alto nivel. Sólo es necesario el detalle de requerimientos de las primeras iteraciones que son las que aportan más valor. • Se puede administrar de manera natural los cambios que van apareciendo durante el proyecto. • Al finalizar cada iteración el equipo puede decidir como mejorar su proceso de trabajo, en función de la experiencia obtenida.
- 20. Beneficios • Permite mitigar desde el inicio los riesgos del proyecto. • Permite gestionar la complejidad del proyecto. • Permite optimizar el uso de recursos disponibles, generando continuamente las características del producto de mayor valor. • Dado que cada iteración debe dar como resultado requerimientos terminados, se minimiza el numero de errores que se producen en el desarrollo y se aumenta la calidad.
- 21. Restricciones • La disponibilidad del cliente debe ser alta durante todo el proyecto dado que participa de manera continua. • La relación con el cliente ha de estar basada en los principios de colaboración más que tratarse de una relación contractual. • Cada iteración debe dar como resultado requisitos implementados, de manera que el resultado sea realmente útil para el cliente y no deje tareas pendientes para futuras iteraciones o para la finalización del proyecto.
- 23. “Un marco de trabajo en el que las personas pueden hacer frente a problemas complejos adaptables, mientras que de manera productiva y creativa entregan productos del mayor valor posible”. Ligero Fácil de entender Extremada mente difícil de dominar Scrum NO es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos
- 24. Qué es Scrum? § Es el método Ágil más popular. § Puede ser aplicado a diferentes tipos de actividades, no solo a desarrollo de software. § Equipos enfocados al resultado, que trabajen de forma auto-dirigida. §Adaptación continua a las circunstancias de la evolución del proyecto. § Centrado en las personas y basado en los valores de honestidad, apertura, esfuerzo, respeto, enfoque, confianza, empoderamientoy colaboración.
- 26. Compromiso e Involucración “Había una vez una gallina emprendedora que quería montar un negocio. Como había cada vez más animales en la granja tuvo la gran idea de montar un restaurante. Para llevar a cabo su idea necesitaba un socio. Así que se dirigió hacia el animal que más confiabilidad le daba: Cerdo. - Hola Cerdo – le dijo Gallina. Quiero abrir un restaurante en la granja y he pensado que tal vez querrías ser mi socio. - No sé – respondió Cerdo. ¿Y cuál sería el plato estrella del restaurante? - ¡Qué te parece “huevos con jamón”! – respondió Gallina. - No gracias. Creo que tú estarías involucrada pero yo tendría que estar comprometido." The difference between INVOLVEMENT and COMMITMENT is like HAM and EGGS. The chicken is involved; the pig is committed. -Martina Navratilova
- 28. Eventos •Sprint •Planning •Daily •Review •Retrospective •Refinement Roles •Product Owner •Scrum Master •Equipo de desarrollo Artefactos •Product Backlog •Sprint Backlog •Incremento del producto “Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las relaciones e interacciones entre ellos” Reglas
- 29. Ciclo de SCRUM
- 31. • Responsable de qué será desarrollado y en qué orden • Empoderado para ser el punto central del producto • Comunica a los otros participantes la visión de lo que se espera obtener • Responsable del éxito de la solución desarrollada • Responsable de que se realice el trabajo que dé mayor valor de negocio (ROI) • Responsable de revisar el producto desarrollado • Trabaja de forma colaborativa con el Scrum Master y el equipo de desarrollo • Debe estar disponible para responder las preguntas sobre el producto tan pronto como se presenten Product Owner
- 32. Scrum Master • Guiar al equipo en crear y seguir su propio proceso SCRUM • FACILITADOR que ayuda al equipo a resolver problemas que se vayan presentando y a mejorar la aplicación de las prácticas de SCRUM • Líder de procesos ayudando al equipo a lograr un alto desempeño siguiendo SCRUM • Responsable por proteger al equipo de cualquier interferencia externa • Enseñar al equipo a autoadministrarse • Guía las reuniones de Scrum • Es un mentor, no una autoridad jerárquica en el equipo • Actúa como interface entre el equipo y la gerencia • Toma el liderazgo para resolver los impedimentos del equipo
- 33. • Responsables por determinar cómo entregar el producto solicitado por el PO • Se auto-organiza para determinar la mejor forma de cumplir con las metas definidas por el PO • Tamaño 7+/-2 (comúnmente entre 3 y 9) •Equipo multifuncional • Trabajo en Equipo • Comunicación constante y transparente • Enfocados y comprometidos “El talento gana juegos, pero el trabajo en equipo gana campeonatos.” Michael Jordan Equipo de Desarrollo
- 35. Product Backlog • Se busca hacer el trabajo mas valioso primero • El product owner es responsable por determinar y administrar la secuencia de trabajo • Inicialmente son las características requeridas para cumplir la visión del producto • El PO colabora con los involucrados para recolectar y definir los elementos del PB • Está en constante evolución, se pueden adicionar, eliminar o cambiar prioridades a los elementos (Refinement) Alta PrioridadBaja Prioridad
- 36. Elementos del Backlog • Características: Como jugador quiero poder saltar en cualquier momento de tal manera que pueda evitar obstáculos • Cambio: Como jugador deseo que el fondo del menú inicial sea ambientado en una estación espacial en vez de en una plataforma de despegue en tierra. • Defecto: Eliminar defecto 5 del sistema de registro de defectos, para evitar que los personajes queden por encima de los pop-ups. • Mejora técnica: Migrar los servicios web a mobile web services de azure. • Adquisición de conocimiento: Crear pruebas de concepto de los dos estilos gráficos y aplicar pruebas para determinar cual de los dos son mas atractivos para el usuario final.
- 37. Sprint Backlog • Se revisa el PB y se determinan los elementos de alta prioridad que puedan ser realmente incluidos en el sprint • Se determina la “Velocidad” del esquipo para determinar el tiempo (esfuerzo) • Se dividen los elementos del PB en tareas Codificar UI 8h Revision de pares 4h Diseñar menu 6h Animar menú 8h Elementos del Product Backlog Tareas
- 38. Incremento del producto potencialmente entregable • Una parte terminada del producto o un incremento del producto existente • El equipo tiene confianza en que el producto está listo para ser liberado • La liberación es una decisión de negocio
- 39. Sprint
- 40. Sprint • Cada Sprint debe crear lago de valor tangible para el usuario o el cliente. • Iteraciones regulares (Time Box), entre 1 – 4 semanas. • Durante el Sprint no se permiten cambios en el Sprint Backlog o en la conformación del equipo. • Se realiza una planeación al inicio de cada Sprint y una retrospectiva al final.
- 41. Planeación del Sprint (8h para un sprint de 1 mes) Qué Hacer? • El Product Owner define el Objetivo del Sprint. • Tomando los elementos de más alta prioridad del Product Backlog, el equipo de desarrollo determina los elementos que se compromete a implementar en el Sprint. Cómo hacerlo? • Los elementos del PB seleccionados se dividen en tareas para crear el Sprint Backlog. Codificar UI 8h Revision de pares 4h Diseñar menu 6h Animar menú 8h Elementos del Product Backlog Tareas
- 42. Daily SCRUM (Daily) 15 minutos • Punto de inspección y adaptación. • El equipo se reune para comunicar y entender el estado. • Esencial para conocer el progreso continuo y evitar bloqueos. • No tiene como objetivo reportar progreso al ScrumMaster, PO o cualquier otro stakeholder. • El PO puede participar pero de forma pasiva. • El SM se asegura de que la reunión se lleve a cabo y se cumpla con el tiempo, pero es responsabilidad del ED.
- 43. Revisión del Sprint (Review) 4h para un sprint de 1 mes • Demostración de las nuevas funcionalidades desarrolladas durante el sprint. • Se inspecciona lo entregado y se obtiene retroalimentación de los asistentes para poder adaptar el plan para próximos sprints. • Deben asistir todos los involucrados relevantes, para dar retroalimentación valiosa. • El resultado es el PB revisado, que define los elementos posibles para el siguiente sprint.
- 44. Reunión de retrospectiva (Retrospective) 3h para un sprint de 1 mes • Se enfoca en la mejora continua del proceso. • Solo participa el equipo Scrum. • Se inspecciona cuán colaborativo y productivo es el equipo y como hacer para mejorar. • Al final el equipo debe haber identificado y se debe haber comprometido con acciones de mejora al proceso.
- 45. Refinamiento del PB (Refinement) 10 % duración del Sprint • Lo lidera el Product Owner • Actividad Colaborativa entre el equipo SCRUM e involucrados externos. • Sólo el Product Owner toma las decisiones.
- 46. Resumen eventos SCRUM Evento Scrum Duración Sprint 4 Semanas 2 Semanas 1 Semana Planning 8 horas 4 horas 2 horas Daily 15 minutos Review 4 horas 2 horas 1 hora Retrospectiva 3 horas 1,5 horas 45 minutos Refinement 10 % de la duración del sprint
- 47. Herramientas para SCRUM • Redmine • Trello • Jira