SCRUM. The art of doing twice the work in half the time. Sutherland, Jeff

Transcripción

1 SCRUM The art of doing twice the work in half the time Sutherland, Jeff

2 Proyecto? La definición clásica de proyecto: construcción de un resultado único, en unas fechas previstas y con unos recursos previstos de antemano. Clásico Nuevo Entrega temprana de resultados Respuesta ágil y flexible Mercados que evolucionan rápidamente Gestión ágil, no se formula sobre la necesidad de anticipación, sino sobre la de adaptación continua.

3 Qué es Scrum? Scrum es una metodología ágil para gestionar proyectos de software, simple, que requiere de trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto. Es un modo de desarrollo adaptable, antes que predictivo. Orientado a las personas, más que a los procesos. Emplea el modelo de construcción incremental basado en iteraciones y revisiones.

4 Nuestro escenario cambia Nonaka y Takeuchi son los primeros en identificar estos nuevos entornos de producción a los que denominan campos de scrum en el artículo The New New Product Development Game.

5 Características con las que se enfrentan las empresa que desarrollan con modelos de gestión ágil : Incertidumbre Auto-organización Control sutil Difusión del conocimiento Fases de desarrollo solapadas

6 Manifiesto ágil manifesto.html principles.html

7 Principios del Manifiesto Ágil 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 Objetivos La gestión ágil de proyectos no es una gestión de anticipación (requisitos, diseño, planificación y seguimiento) sino de adaptación (visión, exploración y adaptación). La gestión ágil tiene como objetivos: Valor: Innovación Reducción de tiempo de desarrollo Agilidad y flexibilidad Fiabilidad.

9 Cómo funciona? Se identifican 5 fases A partir de una necesidad del cliente construye el producto de forma incremental. Incrementa a través de iteraciones breves llamadas sprint. Fuente Scrum Master

10

11 Marco técnico de Scrum Roles: Artefactos: Eventos: o El equipo scrum. o Pila del producto. o Sprint. o El dueño del producto. o Pila del sprint. o El Scrum Master. o incremento. o Reunión de planificación del sprint. o Scrum diario. o Revisión del sprint. o Retrospectiva del sprint.

12 Roles cerdos y los pollos Un cerdo y un pollo van caminando por la carretera. El pollo le dice al cerdo: -Oye, por qué no abrimos un restaurante? El cerdo se vuelve y le responde: -Buena idea, cómo quieres que lo llamemos? El pollo se lo piensa y propone: - Por qué no lo llamamos Huevos con jamón. -No cuentes conmigo -responde el cerdo-. En ese caso, tú sólo estarías IMPLICADO, mientras que yo estaría realmente COMPROMETIDO.

13 Product owner (cliente) Interesados - Visión del producto/negocio Historias de usuario Marca prioridades Scrum Manager (facilitador) Equipo - Pequeños y auto-organizados Multidisciplinar Colaborativos, comunicación transparente Puede existir una cabeza visible Team Leader - Usuarios de la aplicación Clientes y vendedores Gestores, directivos

14 Quién debe participar en las demos del producto? Planificamos? Quién decide lo que cuesta hacer una tarea? Quién se va a encargar de asignar las tareas a cada desarrollador? Quién decidirá la arquitectura del sistema?

15 Artefactos Product backlog (pila del producto) es la lista de requisitos de usuario que está en constante evolución durante el desarrollo del producto. Puede incluir funcionalidades, mejoras, tecnología y corrección de errores. Sprint backlog (pila del sprint) es lista de tareas que debe realizar el equipo durante el sprint para generar el incremento previsto. Incremento: resultado de cada sprint.

16 Pila del producto Ejemplo

17 Pila del sprint

18 Incremento Incremento es la parte de producto desarrollada en un sprint, y se debe encontrar completamente terminada, probada y en condiciones de ser usada El cliente tiene que ver un avance. El sprint le da valor.

19 Eventos Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central que genera el pulso de avance a ritmo de tiempos prefijados (time boxing). Reunión de Planificación del sprint: reunión de trabajo que marca el inicio de cada sprint en la que se determina cuál es el objetivo del sprint y las tareas necesarias para conseguirlo. Scrum diario: breve reunión diaria del equipo 10/15 minutos, en la que cada miembro responde a tres cuestiones: Qué hice ayer? Qué voy a hacer hoy? Cosas que puede necesitar, o impedimentos que deben eliminarse para poder realizar el trabajo. Revisión del sprint: análisis e inspección del incremento generado, y adaptación de la pila del producto si resulta necesario. Retrospectiva del sprint: revisión de lo sucedido durante el Sprint. Reunión en la que el equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el próximo sprint.

20 Planificación del sprint La forman el product owner, el equipo y el Scrum manager. Solo se planifica el sprint no todo el proyecto. Tiene dos partes: 1ª parte (max. 4horas) El product owner expone sus necesidades y da su visión del producto. Se decide que elementos de la pila del producto se van a desarrollar. 2ª parte El equipo divide las historias de usuario en tareas. El equipo estima las unidades de trabajo de cada tarea. Propuesta de trabajo. Resultado: Pila del sprint Duración del sprint. Fecha de la reunión de revisión Objetivo del sprint

21 Pila del sprint

22 Rellenar una tarea

23 Cómo se mide Estimación de póker Práctica ágil para realizar estimaciones y duración de tareas. El equipo emplea un juego de cartas para estimar. Fibonacci Estimaciones solo en base a la serie de Fibonacci.

24 Comienza el sprint

25 Durante el sprint

26 Durante el sprint

27 Sprint. Cómo trabajamos durante el sprint? Reunión diaria de seguimiento. Se hace de pie y dura 15 minutos. El Scrum master dirige la reunión y le hace a todos los miembros del equipo tres preguntas: Qué hiciste? Qué vas a hacer en el próximo tiempo? Problemas? Cada miembro del equipo selecciona una tarea y la pone en la zona en proceso (WIP), actualiza el tiempo pendiente o la marca como finalizada. El equipo refresca el gráfico de avance del sprint. El Scrum Manager comienza la gestión de necesidades e impedimentos identificados.

28 Scrum diario Lo forma el equipo y Scrum manager. Como mucho dura 15 minutos. Reunión de pie. Cada miembro del equipo responde a tres preguntas: Qué hice ayer? Qué voy a hacer hoy? Cosas que puede necesitar, o impedimentos que deben eliminarse para poder realizar el trabajo. Se ven los avances y se identifican necesidades e impedimentos.

29 Revisión del sprint La forman el product owner, el equipo y el scum manager y puede que algún interesado. Como mucho 4 horas. Se enseña el incremento al cliente. No necesita preparación. Si algo no convence, debe entrar en el siguiente sprint

30 Burn Down. Monitoriza el avance del sprint Herramienta del equipo para gestionar y seguir el trabajo de cada sprint. Es una representación gráfica del avance del sprint.

31 Ejemplo

32 Gráfico del producto o Burn-up Herramienta de gestión y seguimiento para el propietario del producto. Presenta de un vistazo: Versiones de producto Funcionalidades Velocidad estimada Fechas probables para cada versión Margen de error previsto en las estimaciones Avance real

33 Enlaces de interés Flexibilidad con Scrum CC by-nc Juan Palacio

34 Equivocate, aprende y mejora para la próxima vez

35 1. ProductBackLog. Definir historias de usuario (requisitos del sistemas) 2. Planificación de un sprint. 2 semanas de duración a. b. c. 3. Realizar sprint a. b. 4. Seleccionar historias de usuario a desarrollar División en tareas Estimación Reunión diaria Actualización de tareas y gráfico (Burn down) Revisión y conclusiones