Introducción a las Metodologías Ágiles. Introducción a Scrum. Roles Ceremonias Artefactos Métricas

Transcripción

1

2 Introducción a las Metodologías Ágiles Introducción a Scrum Roles Ceremonias Artefactos Métricas

3 Mauricio Silclir Ingeniero en Sistemas de Información (UTN FRC) Scrum Master del Centro de Desarrollo de Software; Motorola Paula Izaurralde Especialista en Ingeniería en Sistemas de Información (UTN FRC) Especialista de Calidad en Motorola Mobility, Cba. Ayudante; Métricas de Software; UTN Córdoba Investigador categoría F LIDICALSO; UTN Certified Scrum Master Ayudante en Metodologías Ágiles en el Desarrollo de Software Investigador Categoría G; LIDICALSO; UTN Certified Scrum Master

4 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. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Ref:

5 Adaptabilidad Colaboración Feedback Visibilidad Entrega Rápida Foco en Valor Comunicación Title of Presentation 11 de abril de 2013 Reducir Desperdicios

6 Agile describe una, no el método en sí mismo Debajo del paraguas Agile, existen varios, como Extreme Programming, Scrum, Lean Development, etc. Cada una de estas metodologías persigue (comunicación mejorada, software funcional, colaboración y participación del cliente, feedback, simplicidad, respuesta a cambios)

7

8 Es una enfoque para la gestión de un proyecto. Más que una metodología o proceso, es un Marco de Trabajo Utiliza procesos Orientado a No está restringido a proyectos de software solamente Tiene una implementación (silver bullet), pero no es una bala de plata Su visión es opuesta a la propuesta por la metodología en cascada

9 Opuesta a la metodología en Cascada Requerimientos Diseño Código Prueba En vez de hacer una sola cosa a la vez......los equipos Scrum hacen un poco de todo, todo el tiempo Ref: The New New Product Development Game by Takeuchi and Nonaka. Harvard Business Review, January 1986.

10 Ciclo de vida Scrum

11 Criterios Básicos de Scrum Equipos pequeños, de entre 5 y 8 personas Ubicados en el mismo lugar físico de trabajo Dueño del Producto disponible (en casi cualquier momento!) El Dueño del Producto NO ES el Scrum Master Scrum Master preferentemente ubicado en el mismo lugar que el equipo de trabajo Tres criterios básicos: disciplina, disciplina y disciplina

12 Prácticas Fuertemente Recomendadas Automatización de pruebas unitarias Automatización de pruebas de sistema Herramientas integradas (por ejemplo, para mantener trazabilidad entre ítems) Integración Continua (builds automatizados, ejecución de pruebas, análisis estático de código, colección de métricas, etc.) Aprendizaje implícito Documentación implícita

13 Marco de Trabajo Scrum Ceremonias Planificación del Sprint Reunión Diaria Revisión del Sprint Retrospectiva del Sprint Artefactos Backlog de Producto Backlog de Sprint Planes de Proyecto y de Release Métricas Etc.

14 Dueño del Producto Define las funcionalidades, decide la fecha de release y su contenido Prioriza el Backlog de Producto Puede cambiar las funcionalidades y prioridades en cada sprint Acepta o rechaza los resultados del sprint Participa en las reuniones de Planificación de Sprint y revisión Scrum Master Asegura que el equipo sea completamente funcional y productivo Promueve la cooperación entre todos los roles y remueve barreras Protege al equipo de interferencias externas Asegura que el proceso sea cumplimentado Participa en las reuniones diarias, de planificación de sprint y revisión del mismo Equipo Típicamente de 5-9 personas Selecciona el Backlog de Sprint Tiene el derecho de hacer lo que sea dentro de los límites de las guías del proyecto para alcanzar el objetivo del sprint Se organiza a sí mismo y a su trabajo Demuestra los resultados del trabajo al Dueño del Producto

15 Marco de Trabajo Scrum Ceremonias Planificación del Sprint Reunión Diaria Revisión del Sprint Retrospectiva del Sprint Artefactos Backlog de Producto Backlog de Sprint Métricas Planes de Proyecto y de Release Etc.

16 Scrum Master Dueño del Producto Equipo Planificación Computadora? Planificación de Sprint SEGMENTO 1 El Dueño del Producto presenta el Backlog de Producto con más alta prioridad El equipo selecciona los ítems del Backlog de Producto con los que se puede comprometer SEGMENTO 2 Decidir la estrategia para alcanzar el objetivo del sprint (diseño) Las tareas son creadas Se estiman las tareas y el backlog de sprint De manera colaborativa, no solamente el Scrum Master! Máx. 4 horas Máx. 4 horas

17 Reglas NO son reuniones de reporte de estado al Scrum Master Son compromisos frente a los demás miembros del equipo Diaria En el mismo lugar A la misma hora (sea puntual!) 15 minutos Participantes (Equipo) El Scrum Master comienza la reunión al horario convenido (sin importar quién está presente y quién no!)

18 Revisión del Sprint / Retrospectiva del Sprint Revisión del Sprint El equipo presenta la funcionalidad terminada (done) al Dueño del Producto y demás stakeholders Los miembros del equipo responden las preguntas de los stakeholders en relación a la demostración, y toman nota de los cambios propuestos Al finalizar la presentación, los stakeholders dan su impresión acerca del producto, cambios deseados y la prioridad de esos cambios - Reunión informal - 1h de preparación Retrospectiva del Sprint Provee una visión periódica de qué está funcionando y qué no está funcionando Típicamente de 1 hora Se realiza al final de cada sprint Todo el equipo participa (Scrum Master, Dueño del Producto, Equipo) Se pueden utilizar varias técnicas

19 Marco de Trabajo Scrum Ceremonias Planificación del Sprint Reunión Diaria Revisión del Sprint Retrospectiva del Sprint Artefactos Backlog de Producto Backlog de Sprint Métricas Planes de Proyecto y Release Etc.

20 Backlog de Producto Es la lista maestra de toda la funcionalidad deseada del producto. Esta lista expresa los requerimientos del dueño del producto en su lenguaje, está estimada y se encuentra ordenada de acuerdo a la prioridad de cada ítem. Crear un módulo de administración de usuarios Login de usuarios Definición de actividades del proyecto Actividades asignadas a cada usuario Permitir el registro de horas semanales por usuario Como administrador del sistema, quiero crear nuevos usuarios, modificar los datos de usuarios existentes y eliminar usuarios obsoletos, de manera de controlar el acceso al sistema de registro de horas. Prioridad: Alta Estimación: 13 story points Criterio de Aceptación: Discusiones: Incluir un dashboard de métricas básicas

21 Backlog de Sprint Crear estructura de BD Como administrador del sistema, quiero crear nuevos usuarios, modificar los datos de usuarios existentes y eliminar usuarios obsoletos, de manera de controlar el acceso al sistema de registro de horas. Prioridad: Alta Estimación: 13 sp Criterio de Aceptación: Discusiones: Crear web service para conexión LDAP Crear pantalla de login Crear casos de prueba automáticos para LDAP Crear casos de prueba manuales de la pantalla Crear las tablas de usuario, permisos y permisos/usuario en la BD, generando los scripts de las mismas. Crear los correspondientes mappings de Hibernate, y las clases DAO de Usuario y Permisos. Generar las pruebas unitarias para las DAO. Responsable: Mauricio Complejidad: Baja Estimación: 16 hs Discusiones: Actualizar el manual de usuario

22 Ítems de Backlog de Sprint Un ítem de backlog de sprint es una descripción de una tarea necesaria para completar una historia de usuario dada. El backlog de sprint está compuesto por todas las tareas necesarias para completar todas las historias comprometidas. Descripción: la descripción de la tarea. No tiene una estructura particular. Crear las tablas de usuario, permisos y permisos/usuario en la BD, generando los scripts de las mismas. Crear los correspondientes mappings de Hibernate, y las clases DAO de Usuario y Permisos. Generar las pruebas unitarias para las DAO. Responsable: Mauricio Complejidad: Baja Estimación: 16 hs Discusiones: Responsable: la persona encargada de llevar a cabo la tarea. Generalmente, los miembros del equipo se auto asignan las tareas. Complejidad: no es un campo mandatorio. Sirve de guía para las estimaciones. También se suele utilizar para distribuir el trabajo entre los miembros del equipo. Estimación: estimación en horas o días hombre. Es una estimación de esfuerzo. Discusiones: Registro de las decisiones que se van tomando (ej: de diseño), especificación más detallada de algún aspecto de la funcionalidad que se está implementando, etc.

23 Producto Épicas Historias de usuario Un producto puede incluir varias funcionalidades Una Épica es una historia de usuario de muy alto nivel que representa una funcionalidad específica Tareas Una historia de usuario está compuesta por varias tareas

24 Cálculo de la capacidad del equipo La capacidad del equipo es la cantidad de horas efectivas que dicho equipo tiene disponibles, para este sprint. Días disponibles Horas diarias disponibles % asignación al proyecto Capacidad en el sprint Capacidad total del equipo 436 Capacidad individual = dias_disp * horas_diarias_disp * porcentaje_asignacion Capacidad equipo = (capacidad individual)

25 Backlog de Sprint Historia #1 Estimación: 13 sp Tarea #1.1 Estimación: x1 horas Tarea #1.2 Estimación: y1 horas Tarea #1.n Estimación: z1 horas Velocidad Estimada 38 Historia #2 Estimación: 20 sp Tarea #1.1 Estimación: x1 horas Tarea #1.2 Estimación: y1 horas Tarea #1.n Estimación: z1 horas Cantidad de horas < capacidad del equipo Tarea #1.1 Estimación: x1 horas Historia #3 Estimación: 5 sp Tarea #1.2 Estimación: y1 horas Tarea #1.n Estimación: z1 horas

26

27 Nombre de la métrica Propósito/Objetivo Formula Responsable de Colectarla Período de Reporte Tendencia de Regresión Lineal Sprint BurnDown Chart (SBDC) Provee un indicador diario del progreso respecto del trabajo comprometido para el sprint actual. Trabajo Pendiente + Tendencia = Trabajo pendiente del día anterior a ayer + Trabajo pendiente de ayer + Trabajo pendiente de hoy) / 3 Scrum Master Se colecta una vez por día. Es la métrica principal de seguimiento del Sprint.

28 Día 1 Día 2 Día 3 Día 4 Día 5 Día 6 Día 7 Día 8 Día 9 Día 10 Día 11 Día 12 Día 13 Día 14 Día 15 Día 16 Día 17 Día 18 Día 19 Día 20 Horas Pendientes 250 Burndown Burndown Lineal (Burndown) 50 0

29

30 # Story Points Nombre de la métrica Propósito/Objetivo Formula Responsable de Colectarla Período de Reporte Velocity (Veln) La Velocity permite a los miembros del equipo conocer el ratio de progreso del equipo completo. Vel[n] = # Story Points por Sprint Scrum Master Se colecta un punto por Sprint. Se utiliza para la planificación de cada sprint, y para los ajustes en el release. Velocity Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Velocity

31 Nombre de la métrica Release BurnDown Chart Propósito/Objetivo Ayuda a determinar la probable fecha de finalización del release, teniendo en cuenta la performance (velocidad) del equipo y los cambios introducidos en el alcance. Formula Intersección de las líneas de tendencia de la velocidad del equipo y el trabajo introducido al release. Provee una aproximación a la fecha de release. Responsable de Período de Reporte Colectarla Scrum Master Se recolecta un punto por Sprint. Se utiliza para la planificación de cada sprint, y para los ajustes en el release.

32

33 Trabajo restante Cambios en el Alcance Lineal (Trabajo restante) Lineal (Cambios en el Alcance)

34 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 # Story Points Nombre de la métrica Deferred Ratio (DFRT) Propósito/Objetivo Muestra el número de historias de usuariodiferidas por sprint, en relación a la cantidad total de user stories inicialmente comprometidos en el sprint. Formula Deferred Ratio = # User Stories Diferidas/ # Total User Stories del Sprint Responsable de Colectarla Scrum Master Período de Reporte Se colecta un punto por Sprint. Se utiliza para la planificación de cada sprint, y para los ajustes en el release. 35 Deferred Ratio Deferred Ratio 5 0

35 Revisiones del sprint Métodos comunes Tamaño Puntos de historia # Historias de Usuario LOCs Satisfacción del cliente 5 métricas básicas Esfuerzo Capacidad Esfuerzo estimado Pila de defectos Defectos Calendario Duración del sprint Plan de Release

36 Herramientas de Soporte para Scrum Pizarra y Post-its (y buena letra) Excel (o cualquier cosa parecida)

37 Herramientas de Soporte para Scrum Orientadas a Agile Sistemas ALM (Application Life-cycle Management)

38 Preguntas

39

40 Una mirada retrospectiva al desarrollo ágil: el camino recorrido y a recorrer Organizan: LIDICALSO - Cátedra de Métricas del Software - Cátedra de Metodologías Ágiles Disertante: Diego Rubio Fecha: 7 de Mayo 2013 Horario: 18:30 a 20:30 Requerimientos Agiles Organizan: LIDICALSO - Cátedra de Métricas del Software - Cátedra de Metodologías Ágiles Disertantes: Natalia Andriano, Claudio Gonzalez Fecha: 4 de Junio 2013 Horario: 18:30 a 20:30 Testing Ágil Organizan: LIDICALSO - Cátedra de Métricas del Software - Cátedra de Metodologías Ágiles Disertantes: Marcela Garay Moyano, Paula Izaurralde, Luciano Marzo Fecha: 6 de Agosto 2013 Horario: 18:30 a 20:30 Agendas:

41 Autor Título Editor Referencia Mike Cohn Mountain Goat Software atsoftware.com/topics/s crum Agile Manifesto g/ Mike Cohn User Stories Applied Addison Wesley ISBN: VersionOne VersionOne Scrumworks Danube mworks Team Foundation System Microsoft com/enus/library/ms242904(v S.80).aspx Rational Team Concert IBM rtc

42 Versión Fecha Descripción Autor 1.0.0_Draft_A 5 - Abril Primera versión adaptada del Material de la Cátedra de Métricas del Software/Metodologías Ágiles de Desarrollo de Software Abril 2013 A línea base después de revisión. Mauricio Silclir y Natalia Andriano. María Paula Izaurralde María Paula Izaurralde