Gestión de Equipos de Desarrollo

Max Déboli

Director de Desarrollo – Lagash

MVP Azure

mdeboli@lagash.comhttp://mdeboli.wordpress.com

Contexto

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

Agenda

• Introducción a las metodologías agiles

• Iteraciones

• Planning

• Scrum Board y Burndown Chart

• Testing

• Daily Meetings

• Retrospectivas

• Integración Continua

Introducción a las Metodologías Agiles

¿Dónde hemos estado?

Esquema tradicional de desarrollo en cascada

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

• Baja precisión al inicio (+-60%)• Personas: aumenta incertidumbre• Solo al avanzar decrece incertidumbre

Cono de Incertidumbre

•Definiciones iniciales inexactas SIEMPRE erróneas•Los resultados de una solución de software son MUY difíciles de predecir

Metodología en cascadaGran definición inicial

Gran entrega final (lejana en el tiempo)

+

Incertidumbre inicial + proceso no evolutivo

FRACASO !!!

Cambio de paradigmaPlan-driven (tradicional)

Vs.Value-driven (ágil)

Concepto “Hecho”

Proyecto Agil

Hecho Hecho Hecho Hecho Hecho Hecho Hecho

Hecho

Vs.

Proyecto tradicional

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.

Procesos Ágiles• Scrum

• Adaptive Software Development

• DSDM

• Extreme Programming

• Crystal

• Feature Driven Development

• Pragmatic Programming

• MSF 4.0 For Agile

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

Dinámica de trabajo

Iteraciones

Iteraciones Tradicionales

EspecificaciónPlanificación Desarrollo Pruebas V 1.0

Desarrollo Pruebas

Carga de Trabajo

1ra Etapa2da Etapa

3ra Etapa

4ta Etapa

Fecha Estimadade Entrega

Iteraciones Tradicionales vs. Iteraciones Agiles

Planificación Desarrollo Pruebas V 1.0

V 0.1

Especificación

V 0.2

V 1.0

V 0.3 V 0.4

3 Meses 3 Semanas1 Semana 1 Mes

1 Mes 1 Mes 1 Mes 1 Mes 1 Mes

Iteraciones Tradicionales vs. Iteraciones Agiles

IteracionesAgiles

IteraciónTradicional

Carga de Trabajo

Estructura de la iteración

Demo

Retros-pectiva

Reunion con el PO

Planifi-cación

Desarrollo

L VM M J V S D M M JL D M M JLV S SD

13 Días Efectivos de Desarrollo

Duración de las Iteraciones Agiles

4 Semanas

2 Semanas

Carga de Trabajo

Planning

Demo

Retros-pectiva

Reunion con el PO

Planifi-cación

Desarrollo

¿Por qué es importante el planning?

• Chance de estimar

• Compromiso

• Momento de acuerdo

• Aprender de nuestros errores

Planning ágil

• 1er parte: presentación de lo nuevo

• 2da parte: planificación

• Product Backlog priorizado

• Se pueden usar herramientas como planningpoker

Presentación de lo nuevo Planificación

Planning Poker Cards

Otros escenarios distintos

• Requerimientos, Casos de uso

• Product Backlog sin priorizar

• Múltiples Product Owners

• Adaptación

Conclusión

• Inteligencia + Adaptación

• No desgastar al equipo

• Dialogo

Scrum Task Boardy

Burndown Chart

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

Scrum Task Board

Scrum Task Board

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.

Scrum Task Board

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.

Scrum Task Board

Pendiente En Curso Terminado

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.

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.

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.

Burndown Chart

Burndown Chart

Burndown Chart

Burndown Chart

Testing

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

Tester dentro del equipo

Product Owner

ScrumMaster

Developers

Tester

Team

Tester fuera del equipo

Product Owner

ScrumMaster

Developers

Tester

Dev Team

QA Team

Iteraciones con el equipo de QA

Pruebas V 0.1

Desarrollo V 0.1Pruebas

DesarrolloPruebasUnitarias

V 0.1

4 Semanas

4 Semanas

2 Semanas

6 Semanas

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

Daily Meeting

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

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 ScrumMaster

Retrospectiva

Demo

Retros-pectiva

Reunion con el PO

Planifi-cación

Desarrollo

¿Por qué es importante la retrospectiva?

• Evaluación de objetivos cumplidos

• Compromiso de mejora

• Momento de sincerarse

Algunos problemas

• Retrospectivas muy ‘pesadas’

• Mucha gente en la retrospectiva

• Integrantes del equipo que no están dispuestos a participar activamente

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

¿Quién puede asistir?

• El equipo completo

• ¿Gerentes?

• ¿Product Owner(s)?

• ¿Líderes?, ¿Project Managers?

• ¿Stakeholders?

Retrospectiva de integración

• Integración de distintos equipos

• Confianza

• Diálogo

No hay recetas

Experiencia

Contexto

Ideas

Integración Continua

Check-in

Load Testing

Unit Testing

Compilación

Prueba final

Todo Ok

¡Todo MAL!

Bibliografía

¿Preguntas?

mdeboli@lagash.com