Ingeniería de Software Procesos Ágiles - SCRUM

Presentación del tema: "Ingeniería de Software Procesos Ágiles - SCRUM"— Transcripción de la presentación:

1 Ingeniería de Software Procesos Ágiles - SCRUM
- TIENDAS PARIS - Proyecto Infraestructura NewPOS Plan de Trabajo 09/04/2017 Ingeniería de Software Procesos Á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 Pruebas integradas Pruebas aceptación Despliegue Operación y Mantenimiento Construcción y Pruebas Unitarias Pruebas Integradas Pruebas Aceptación meses

4 Complejidad en proyectos
Tecnología Requerimientos Claros Poco Conocida Desconocida Anarquía Complejo Complicado Simple Clasificación de complejidad en proyectos de desarrollo 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.

5 Errores de estimación Cono de Incertidumbre
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 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 Variabilidad de la estimación 4x 0,25x 2x 0,5x 0,67x 0,8x 1,0x 1,25x 1,5x

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 Modelo definido 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. 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? SCRUM Control Empírico Requerimientos
Tecnología Requerimientos Claros Poco Conocida Desconocida Anarquía Complejo Complicado Simple Qué usar en Desarrollo? Control Empírico SCRUM 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 09/04/2017 ¿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) Product Owner Scrum
Master Stakeholders. Otros usuarios. Personas de otros equipos. Etc. 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
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 Sprint Scrum Master Daily Scrum
Product Backlog Requerimientos priorizados que emergen en el proceso Product Backlog seleccionado Sprint Backlog (Tareas) Sprint (30 días) Producto potencialmente Instalable en producción Daily Scrum Cada 24h Sprint Planning (parte 2) Retrospective Sprint Planning (parte 1) Sprint Review Mejoras al proceso Scrum Master Product Owner Sprint Backlog Burndown Visión Estimación de ROI, plan de releases, hitos Planificación Observaciones Modificaciones al Product Backlog No hay cambios (ni duración ni entregable)

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: Estimated To 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 Sprint Retrospective (4h)
Tiempos Flujo de proceso Scrum Sprint (30 días) Planning Sprint Planning (8h) Daily work (1 día) Daily Scrum (15 min) Sprint Review (4h) 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. Dirigido al Plan Dirigido al Valor Estimado Fijo Requerimientos Recursos Fecha Cascada/Tradicional Ágil

33 Scrum es un proceso continuo
Requeri-mientos emergentes Sistema emergente Releases

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 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, user stories, etc. El conjunto resultante conforma un proceso de desarrollo robusto: control adaptivo y prácticas para reducir riesgo y aumentar calidad.

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 Planificación Desarrollo Estabilización Proyecto SCRUM P P D E P D E P D E P D E P D E

37 “Done” El equipo y el Product Owner definen el concepto de “Done”.
09/04/2017 “Done” 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. 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.

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

39 Múltiples equipos de desarrollo
Escalabilidad de Scrum Daily Scrums 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 Equipo Product Owner Scrum Master Integration Scrum team 1.2 Equipo Product Owner Scrum Master

42 Preguntas