1 / 42

Ingeniería de Software Procesos Ágiles - SCRUM

Ingeniería de Software Procesos Ágiles - SCRUM. Alejandro Pacheco Masdíaz. Temas. Modelo Tradicional de Desarrollo de Software ¿Qué es SCRUM? Comentarios Finales. Esquema tradicional cascada. Ciclo de vida de software . Análisis. Diseño. Construcción. Análisis. Diseño.

shakti
Download Presentation

Ingeniería de Software Procesos Ágiles - SCRUM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Ingeniería de SoftwareProcesos Ágiles - SCRUM Alejandro Pacheco Masdíaz

  2. Temas • Modelo Tradicional de Desarrollo de Software • ¿Qué es SCRUM? • Comentarios Finales

  3. Esquema tradicional cascada Ciclo de vida de software Análisis Diseño Construcción Análisis Diseño Pruebas Integradas Pruebas Aceptación Despliegue Operación y Mantenimiento Construcción y Pruebas Unitarias Pruebas integradas Pruebas aceptación meses Despliegue Operación y Mantenimiento Ciclo de vida de software

  4. Complejidad en proyectos Clasificación de complejidad en proyectos de desarrollo Poco Claros • Cuando los requerimientos están muy claros y la tecnología es conocida (se tiene el expertise en la misma) el proyecto es simple. • La dimensión “personas” agrega otro factor de complejidad. Anarquía Requerimientos Complejo Complicado Simple Complicado Claros Conocida Desconocida Tecnología

  5. Errores de estimación • El eje horizontal contiene hitos típicos de proyectos. • El eje vertical contiene el grado de error que se ha encontrado en estimaciones realizadas por especialistas en estimación para distintas etapas de proyectos. • Al principio de un proyecto, la estimación está entre un 25% y 400% del valor real. Por ejemplo, un proyecto estimado en 20 semanas puede durar entre 5 y 80. • La exactitud en la estimación depende del nivel de refinamiento en la definición del software, mientras más refinada está la definición (más a la derecha en el gráfico), más exacta es la estimación. Por lo tanto, para una etapa del proyecto, aunque se cuente con más tiempo para refinar la estimación, no se mejora la exactitud. Cono de Incertidumbre Variabilidad de la estimación 4x 2x 1,5x 1,25x 1,0x 0,8x 0,67x 0,5x 0,25x Hitos Definición inicial del producto Definición del producto aprobada Levantamiento requerimientos completo Diseño interfaz de operación completo Diseño detallado completo Software aceptado

  6. Control Predictivo vs Empírico El desarrollo de Software es un proceso y como tal puede ser “controlado” para obtener un resultado esperado a partir de un objetivo dado. Las técnicas para controlar procesos se pueden clasificar en dos grandes grupos: modelo definido (predictivo) y empírico: Método Consideraciones • Recomendado cuando: • Se conoce y entiende cómo opera el proceso. • Es posible predecir el comportamiento del proceso. • Se basa en contar con modelo definido del proceso y determinar la entrada necesaria para obtener un comportamiento dado. Modelo definido Empírico • Recomendado cuando el proceso es demasiado complicado para el Modelo Definido. • Se basa en el monitoreo continuo del proceso y en la adaptación del control.

  7. Qué usar en Desarrollo? Poco Claros Control Empírico SCRUM Anarquía Requerimientos Complejo Complicado Simple Complicado Claros Conocida Desconocida Tecnología • Dada la naturaleza no determinística de los procesos de desarrollo de software, es más adecuado un mecanismo de control empírico, basado en el monitoreo y adaptación continua. • SCRUM es un método empírico para gestionar proyectos de desarrollo, que da muy buenos resultados en entornos complejos.

  8. Temas • Modelo Tradicional de Desarrollo de Software • ¿Qué es SCRUM? • Comentarios Finales

  9. ¿Qué es Scrum? • Scrum es un proceso empírico para gestionar y controlar el proceso de desarrollo (se usa para gestionar proyectos complejos desde 1990). • Scrum entrega funcionalidad de negocio cada 30 días. • Scrum es una envoltura a prácticas ya existentes de ingeniería de software. • Scrum permite desarrollar sistemas y productos de manera iterativa e incremental, donde los requerimientos varían rápidamente. • Scrum es una forma de mejorar la comunicación y maximizar la cooperación. • Scrum es una forma de detectar y eliminar los impedimentos que aparecen cuando se desarrollan productos. • Scrum permite maximizar la productividad. • Scrum es escalable a grandes proyectos. • Scrum cumple con CMM3 e ISO 9001.

  10. Actores Equipo Scrum (pigs) Resto (chickens) • Stakeholders. • Otros usuarios. • Personas de otros equipos. • Etc. Product Owner Scrum Master Equipo • El concepto de “cerdos” y “gallinas” viene de la diferencia entre comprometerse y participar: Cuando se elaboran huevos con tocino, la gallina participa, pero el cerdo se compromete.

  11. Roles y responsabilidades Rol Responsabilidades Product Owner • “Pincha y corta” en todo lo que tenga relación con los requerimientos. • Define las características del producto. • Gestiona las características y releases del proyecto para optimizar el ROI. • Prioriza los requerimientos de acuerdo al valor para el negocio. • Inspecciona los incrementos y realiza adaptaciones al proyecto. • Puede cambiar los requerimientos y las prioridades en cada Sprint (ciclo). Equipo • Multifuncional, siete más/menos dos personas. • Selecciona los objetivos de cada iteración y especifica el trabajo a realizar. • Se compromete con lo que puede completar en cada iteración. • Tiene la autoridad para hacer cualquier cosa dentro de las guías y estándares existentes para cumplir con los objetivos de la iteración. • Se gestiona a sí mismo. • Colabora con el Product Owner para maximizar el valor para el negocio. • Realiza demos del resultado del trabajo al Product Owner. Scrum Master • Se asegura que el equipo es completamente funcional, productivo y que mejora la calidad. • Promueve la estrecha colaboración entre todos los roles y funciones. Además, elimina impedimentos que surgen en el proceso. • Protege al equipo de interferencias externas. • Se asegura que se sigue el proceso. • Le enseña al Product Owner y al equipo cómo cumplir con su rol.

  12. Proceso SCRUM Flujo de proceso SCRUM Product Backlog Sprint Backlog Burndown Cada 24h Scrum Master Daily Scrum Visión Sprint (30 días) Sprint Planning (parte 2) Sprint Review Planificación No hay cambios (ni duración ni entregable) Producto potencialmente Instalable en producción Sprint Backlog (Tareas) Estimación de ROI, plan de releases, hitos Observaciones Modificaciones al Product Backlog Product Backlog seleccionado Product Owner Mejoras al proceso Sprint Planning (parte 1) Sprint Retrospective Product Backlog Requerimientos priorizados que emergen en el proceso

  13. Product Owner • El Product Owner es responsable de la visión de qué debe ser producido para maximizar el valor de negocio. • El Product Owner obtiene información de los clientes, usuarios finales, equipo, managers, stakeholders, ejecutivos, expertos de la industria, etc. • El Product Owner transforma esto en una lista simple de qué debe ser producido, priorizado en base al valor de negocio y riesgo. • La lista es llamada Product Backlog.

  14. Product Backlog • El Product Backlog es la lista maestra de características, funcionalidades y otros trabajos requeridos, priorizados en base al valor de negocio y riesgo, a juicio del Product Owner. • Los ítems de mayor prioridad deben ser completados por el equipo lo antes posible. • El Product Backlog es continuamente revisado (se agregan, quitan y modifican ítems) por el Product Owner, para maximizar el éxito para el negocio de los esfuerzos del equipo.

  15. Product Backlog Se registran y priorizan todos los requerimientos Funcionales y No Funcionales

  16. Equipo • El tamaño ideal en Scrum es 7 +/- 2. • El equipo es cross-functional. Tiene todas las habilidades para producir un producto terminado (diseñadores, codificadores, testers, etc.) y todos contribuyen basados en sus competencias, más que en el cargo. • El equipo es auto-organizado y auto-gestionado. Es responsable de comprometerse y auto-gestionarse para cumplir el objetivo (o acercarse lo más posible). Scrum provee herramientas para ayudar a esto.

  17. Sprint • El equipo trabaja en un periodo fijo de tiempo, llamado Sprint. • Los Sprints duran entre 1 y 4 semanas. • Los Sprints ocurren uno después de otro, sin down-times entre ellos. Es muy importante trabajar de manera sostenida. • El equipo y el Product Owner deciden con anticipación el largo de los Sprints.

  18. Sprint Planning • Antes de cada Sprint, el equipo selecciona con qué requerimientos del Product Backlog se comprometerá para el final del Sprint, empezando por los de mayor prioridad. • El equipo crea un plan a nivel de tareas para cumplir el compromiso. Esta lista de tareas se llama Sprint Backlog. • El equipo trabaja para crear una asignación inicial de tareas y compara el total de horas estimadas con el total de horas disponibles, para asegurarse que el compromiso es razonable. • Cada uno de los integrantes del equipo participa, independiente de su experiencia.

  19. Sprint Planning (2) • Es muy importante que el Product Owner no presione al equipo para que se comprometa con más de lo que ellos encuentran razonable. Si hay presión, el equipo se sobre-comprometerá y los requerimientos no se completarán o tendrán baja calidad o el equipo se “quemará” luego de varios sprints. • Muchos managers al principio se preocupan de que el equipo se sub-comprometa. En realidad, a la mayoría de los equipos les ocurre lo contrario: les puede tomar varios sprints para aprender a no sobre-comprometerse.

  20. Modificaciones al Sprint • Durante el sprint, lo que el equipo comprometió a entregar no cambia y el final de sprint no cambia. • Esto permite que el equipo haga y mantenga compromisos, enfoca al equipo y provee estabilidad durante el Sprint. Además, entrena al Product Owner a pensar claramente en lo que está en el Product Backlog. • Aunque el Product Owner no puede realizar cambios en el sprint, sí puede realizar todos los cambios que estime conveniente en el Product Backlog antes de empezar el siguiente Sprint.

  21. Daily Scrum • Cada día, el equipo tiene una reunión de 15 minutos para actualizar entre ellos el progreso y exponer impedimentos. Normalmente, estas reuniones se realizan de pie, para fomentar la brevedad. • Cada miembro del equipo expone 3 cosas: qué hizo entre la reunión anterior y ésta, qué realizará entre esta reunión y la siguiente, y qué impedimentos tiene para completar su trabajo. • El Scrum Master anota los impedimentos y luego ayuda a resolverlos. • Otros (chickens) pueden asistir a la reunión, pero no hablan. Esta reunión no es para monitorear al equipo.

  22. Control de avance • Cada día, el equipo actualiza tablas y gráficos simples que hacen visible cómo están progresando hacia el cumplimiento de los objetivos del Sprint. • El Sprint Backlog lista todas las tareas y las horas remanentes para cada una. El gráfico de quemado de horas muestra el total de horas remanentes para completar todas las tareas. • Estas tablas y gráficos ayudan a que el equipo se auto-gestione y entreguen lo que se comprometieron para el final del Sprint.

  23. Sprint Backlog El Sprint Backlog evoluciona dentro del Sprint. Para cada tarea del Sprint Backlog, se registran diariamente las horas faltantes para completar la tarea (ETC: EstimatedTo Complete).

  24. Quemado (burndown) de horas Horas estimadas que faltan para terminar las tareas del Sprint Backlog. Quemado teórico de horas. Se asume un consumo uniforme.

  25. Scrum Master • El Scrum Master es un nuevo rol. Puede ser cumplido por un Jefe de Proyecto o miembro del equipo. • El Scrum Master sirve al equipo (ayudándoles a eliminar los impedimentos que se detectan), protege al equipo (de cualquier interferencia externa) y enseña y guía acerca del uso de Scrum. • Sin un Scrum Master, el equipo tiene un alto riesgo de fracasar.

  26. Producto • El objetivo del equipo es completar al 100% lo que ellos se comprometieron, idealmente un incremento de un producto potencialmente “vendible” o instalable en producción. • Debe cumplir el concepto de “Done” acordado con el Product Owner. Para software, significa funcionalidad que ha sido diseñada, completamente implementada y completamente testeada, sin mayores defectos. • Muy pocos equipos pueden producir un producto potencialmente vendible al final del Sprint 1, pero a medida que avanzan se acercan más a este objetivo.

  27. Sprint Review • Al final del Sprint, el Product Owner, Equipo, Scrum Master y Stakeholders se reúnen para ver una demo de lo que el equipo ha producido. • El Product Owner obtiene feedback de todos con el objetivo de mejorar lo que se construyó. • El feedback es incorporado al Product Backlog. • Si un producto no cumple con el concepto de “Done”, entonces no se muestra en esta reunión.

  28. Sprint Retrospective • El equipo, Product Owner y Scrum Master se reúnen al final de cada Sprint para revisar la forma de trabajo y ven maneras de mejorar la eficiencia. • Éste es un mecanismo de mejora continua donde se detectan problemas y se resuelven o escalan.

  29. Tiempos Flujo de proceso Scrum Sprint (30 días) Sprint Planning (8h) Daily work (1 día) Sprint Review (4h) Planning Daily Scrum (15 min) Sprint Retrospective (4h) Visión Estimación de ROI, plan de releases, hitos

  30. Temas • Modelo Tradicional de Desarrollo de Software • ¿Qué es SCRUM? • Comentarios Finales

  31. Cambiando el paradigma Desarrollo cascada versus desarrollo ágil Desarrollo cascada Desarrollo ágil Medición de éxito Cumplimiento del plan Respuesta al cambio, código funcionando Cultura de gestión Comando y control Liderazgo, colaborativo Requerimientos y Diseño Grande y al principio Continuo, emergente, just-in-time Codificación Codificar todos los requerimientos, probar después Codificación y pruebas unitarias, entrega periódica Pruebas y QA Grandes, planificadas, al final Continuo, concurrente, probar temprano Planificación Pert, Gantt, recursos y plazos estimados Planificaciones de 2 niveles, alcance estimado

  32. Cambiando el paradigma Dirigido al Plan (tradicional) versus Dirigido al Valor (ágil) • En el método tradicional, los Requerimientos son fijos y se estiman los recursos y la fecha (plazo). Está orientado a cumplir un plan. • En los métodos ágiles los recursos y la fecha (plazo) son fijos y se estiman los requerimientos que maximizan el valor al negocio y que pueden ser implementados en esos plazos con esos recursos. Cascada/Tradicional Ágil Dirigido al Plan Recursos Requerimientos Fecha Dirigido al Valor Estimado Fijo Recursos Fecha Requerimientos

  33. Scrum es un proceso continuo

  34. Scrum junto a otras prácticas Scrum sirve de envoltorio a otras prácticas de Ingeniería de Software Proceso de Desarrollo para proyecto específico Integración continua, pair programming, etc. Otras prácticas de desarrollo, por ejemplo XP. Test Driven Programming SCRUM • Scrum se puede complementar con otras prácticas de desarrollo, siempre que no quiebren el proceso de Scrum. Por ejemplo: integración continua, test driven programming, pair programming, no overtime, userstories, etc. • El conjunto resultante conforma un proceso de desarrollo robusto: control adaptivo y prácticas para reducir riesgo y aumentar calidad. SCRUM

  35. Velocidad Consumo de ítems del Product Backlog por sprint Ítems remanentes del Product Backlog, a medida que avanzan los Sprints Proyección lineal de la velocidad del equipo Se puede proyectar cuándo se terminarán los ítems del Product Backlog

  36. Planificación continua Proyecto tradicional Desarrollo Estabilización Planificación Proyecto SCRUM P D E P D E P D E P D E P D E P

  37. “Done” • Ejemplo de “done”: • Diseñado. • Refactorizado. • Codificado. • Revisión de código. • Revisión de diseño. • Pruebas Unitarias. • Pruebas Integradas. • Pruebas de carga. • Pruebas de seguridad. • Pruebas de aceptación. • Documentado. • El equipo y el Product Owner definen el concepto de “Done”. • Ítems del Product Backlog que no estén “done” no deben ser mostrados en Sprint Review.

  38. Concepto del “Done” Proyecto tradicional Done Proceso de desarrollo tradicional (Cascada) Proyecto Scrum Done Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 … Sprint N Done Done Done Done Done Done Done Done

  39. Múltiples equipos de desarrollo Escalabilidad de Scrum DailyScrums Sprint 1 Sprint 2 Sprint 3 Scrum of Scrums

  40. Descomposición del trabajo • Trabajo es descompuesto por objetivos. • Se reporta para hacer seguimiento del progreso en alcanzar objetivos.

  41. Interacción entre equipos Integration Scrum team 1 Product Owner Scrum Master Equipo Integration Scrum team 1.1 Integration Scrum team 1.2 Equipo Equipo Product Owner Product Owner Scrum Master Scrum Master

  42. Preguntas

More Related