Gestión de Equipos de Desarrollo. Max Déboli Director de Desarrollo Lagash MVP Azure

Transcripción

1 Gestión de Equipos de Desarrollo Max Déboli Director de Desarrollo Lagash MVP Azure

2 Contexto Metodologías agiles de desarrollo de Software y como las usamos nosotros

3 Agenda Introducción a las metodologías agiles Iteraciones Planning Scrum Board y Burndown Chart Testing Daily Meetings Retrospectivas Integración Continua

4 Introducción a las Metodologías Agiles

5 Dónde hemos estado? Esquema tradicional de desarrollo en cascada

6 Algunas Características Metodología detallada (muy burocrática) Mucha documentación y administración Se basa sobre supuestos de procesos (soluciones) predictivos e invariables Se espera un delivery final lejano en el tiempo, con mucha incertidumbre Consecuencias Resultados poco predecibles 52% de proyectos por sobre 160% de costos Bajos resultados, poco éxito, baja satisfacción

7 Cono de Incertidumbre Baja precisión al inicio (+-60%) Personas: aumenta incertidumbre Solo al avanzar decrece incertidumbre Definiciones iniciales inexactas SIEMPRE erróneas Los resultados de una solución de software son MUY difíciles de predecir + Metodología en cascada Gran definición inicial Gran entrega final (lejana en el tiempo) Incertidumbre inicial + proceso no evolutivo FRACASO!!!

8 Cambio de paradigma Plan-driven (tradicional) Vs. Value-driven (ágil)

9 Concepto Hecho Proyecto tradicional Hecho Proyecto Agil Vs. Hecho Hecho Hecho Hecho Hecho Hecho Hecho Hecho Hecho!! 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.

10 Scrum Procesos Ágiles Adaptive Software Development DSDM Extreme Programming Crystal Feature Driven Development Pragmatic Programming MSF 4.0 For Agile

11 SCRUM Metodología de desarrollo Ágil Incremental Iterativa Adaptación del proceso utilizado por Toyota desde los 80 para la elaboración de nuevos productos

12 Dinámica de trabajo

13 Iteraciones

14 Iteraciones Tradicionales Planificación Especificación Desarrollo Pruebas V 1.0 Desarrollo Pruebas 1ra Etapa 2da Etapa 3ra Etapa 4ta Etapa Fecha Estimada de Entrega Carga de Trabajo

15 Iteraciones Tradicionales vs. Iteraciones Agiles 1 Semana 1 Mes 3 Meses 3 Semanas Planificación Especificación Desarrollo Pruebas V Mes 1 Mes 1 Mes 1 Mes 1 Mes V 1.0 V 0.1 V 0.2 V 0.3 V 0.4

16 Iteraciones Tradicionales vs. Iteraciones Agiles Carga de Trabajo Iteraciones Agiles Iteración Tradicional

17 Estructura de la iteración Reunion con el PO Retrospectiva Planificación Desarrollo Demo D L M M J V S D L M M J V S D L M M J V S 13 Días Efectivos de Desarrollo

18 Duración de las Iteraciones Agiles Carga de Trabajo 4 Semanas 2 Semanas

19 Planning Reunion con el PO Retrospectiva Planificación Desarrollo Demo

20 Por qué es importante el planning? Chance de estimar Compromiso Momento de acuerdo Aprender de nuestros errores

21 Planning ágil 1er parte: presentación de lo nuevo 2da parte: planificación Product Backlog priorizado Se pueden usar herramientas como planning poker Presentación de lo nuevo Planificación

22 Planning Poker Cards

23 Otros escenarios distintos Requerimientos, Casos de uso Product Backlog sin priorizar Múltiples Product Owners Adaptación

24 Conclusión Inteligencia + Adaptación No desgastar al equipo Dialogo

25 Scrum Task Board y Burndown Chart

26 Scrum Task Board (aka Corcho) Es una tabla de tareas que contiene todo el trabajo que se esta realizando en el sprint actual, como así también información útil para compartir entre equipos Tres columnas para el manejo de tareas. Pendiente En progreso Terminado

27 Scrum Task Board

28 Scrum Task Board

29 Scrum Task Board Cómo lo utilizamos? Luego de la reunión de planificación, colocamos en la columna Pendientes los ítems del Sprint Backlog correspondientes junto con las tareas que los componen.

30 Scrum Task Board

31 Scrum Task Board Cómo lo utilizamos? Tomamos la tarea sobre la cual vamos a empezar a trabajar de la columna Pendientes y la colocamos en la columna En progreso. Una vez que esa tarea esta terminada, la colocamos en la columna Terminado. Si esta tarea era la ultima del Sprint Backlog Item, también lo colocamos en la columna Terminado. Si durante el desarrollo del Sprint aparecen elementos no planificados, estos los agregamos a la sección No Planificados del Board.

32 Scrum Task Board Pendiente En Curso Terminado

33 Burndown Chart Es una herramienta muy útil para saber cual es la evolución de nuestra iteración de una forma sencilla y directa. Nos muestra cual es la velocidad del equipo basado en el consumo de los puntos de historia/horas durante el transcurso del Sprint y nos permite prever si el equipo acabará todas las tareas en el tiempo estimado.

34 Burndown Chart Eje Y: Horas / Puntos de Historia. Eje X: Días del Sprint. Línea azul: Curva ideal de consumo de horas. Línea roja: Curva real de consumo de horas.

35 Burndown Chart Cómo lo usamos? A medida vamos terminando las tareas, se van disminuyendo los puntos de historia/horas asignados para esa tarea en el grafico. De esta forma vamos trazando nuestra línea de consumo de puntos de historia/horas. Es una buena herramienta para cambiar la actitud del equipo, ya que cuando la roja no baja sirve como elemento de presión / motivación.

36 Burndown Chart

37 Burndown Chart

38 Burndown Chart

39 Burndown Chart

40 Testing

41 Perfil del Tester Necesita conocimiento del negocio y técnico Debe tener una visión de usuario para probar el software desde el uso Debe tener una visión técnica para hacerlo fallar en circunstancias anormales Debe poder generar conjuntos de datos de prueba Debe poder automatizar las pruebas repetitivas

42 Tester dentro del equipo Product Owner ScrumMaster Developers Tester Team

43 Tester fuera del equipo Developers Dev Team Product Owner ScrumMaster Tester QA Team

44 Iteraciones con el equipo de QA 4 Semanas Desarrollo Pruebas V Semanas 2 Semanas Desarrollo Pruebas Unitarias V 0.1 Pruebas V Semanas

45 Sobre las pruebas unitarias Necesitan una arquitectura testeable : Mocking Dependency Injection Es difícil que no se transformen en una carga En arquitecturas con varias capas, muchas pruebas unitarias consisten en mapeo y pasaje de datos entre las capas Un code coverge alto no asegura buenas pruebas unitarias

46 Daily Meeting

47 Daily Meetings Reunión diaria En el mismo lugar y a la misma hora Reuniones rápidas No mas de quince minutos de duración Es importante que todos los miembros del equipo participen

48 Daily Meetings Tres preguntas: Qué hiciste ayer? Qué vas a hacer hoy? Tenes algún impedimento para realizar tu trabajo? Los impedimentos se transforman en responsabilidades a resolver para el Scrum Master

49 Retrospectiva Reunion con el PO Retrospectiva Planificación Desarrollo Demo

50 Por qué es importante la retrospectiva? Evaluación de objetivos cumplidos Compromiso de mejora Momento de sincerarse

51 Algunos problemas Retrospectivas muy pesadas Mucha gente en la retrospectiva Integrantes del equipo que no están dispuestos a participar activamente

52 Actividades Para tener un panorama de que siente el equipo Para hacer mas liviana la reunión Para poder recordar mas precisamente que paso durante el sprint Para poder evaluar y comprometernos a mejorar cosas mas puntuales

53 Quién puede asistir? El equipo completo Gerentes? Product Owner(s)? Líderes?, Project Managers? Stakeholders?

54 Retrospectiva de integración Integración de distintos equipos Confianza Diálogo

55 No hay recetas Ideas Contexto Experiencia

56 Integración Continua Check-in Todo Ok Todo MAL! Load Testing Unit Testing Compilación Prueba final

57 Bibliografía

58 Preguntas?

59