sábado, septiembre 29, 2012

Mi experiencia con SCRUM

Hay que reconocer que el desarrollo iterativo no fue inventado por la metodologías ágiles pero si fue reforzado por ellas.

Esta es la historia...


Antecedentes
Hace tres meses (hoy es 29 de septiembre de 2012) vengo liderando un proyecto móvil con las siguientes características:
  • Dispositivo IPADs, (aunque se quiere que tambien funcione en web)
  • PhoneGap como framework de implementación de la interfaz gráfica
  • Arquitectura: SOA - Consulta a la capa de datos a través de mediaciones sobre Websphere ESB
  • Motor de reglas de negocio: DROOLS.
  • Duración del proyecto: 8 meses aproximadamente
  • Fecha de inicio: Mayo de 2012
  • Ciclo de vida cascada
  • Reporte en Project Server
  • Horas de equipo de 5 personas con 45 horas diarias laborales de trabajo.
Cuando recibí  el proyecto ya se encontraba 2 meses avanzado y el entregable para pruebas del cliente era para mediados de noviembre. Por lo tanto solo hasta 3 semanas antes de esa DEADLINE (nombre muy bien puesto.. si seguiamos asi.. sería la muerte) podría hacer clic en el sistema.


Nudo
Decidí implementar todo lo que había leído y recopilado de SCRUM (ver diapositivas) y defendido en las cursos de gerencia de proyectos informáticos que dicto en el un pregrado (Ingeniería de sistemas - Universidad Eafit - Medellín) y un posgrado (Especialización en Ingeniería de Software - Universidad de Medellin)

Elementos adoptados de SCRUM:
  • Product Backlog
  • Sprint Backlog  (reporte de avance en google docs)
  • 3 Sprints de 1 mes (concertado con el equipo)
  • Burndown Chart (reporte de avance en google docs)
  • Velocidad  (reporte de avance en google docs)
  • Standup meeting 
  • Sprint review
  • Sprint retrospective
No se adoptaron:
  • Un el backlog de tareas sin dueño y cada cual va y "selecciona" la tarea que quiere.
  • El cliente inmerso en el equipo
  • Escritura de historias de usuario.
Se conservó:
  • Artefactos requeridos por la metodología de la empresa:
    • Casos de uso
    • Documento de arquitectura
    • Casos de prueba
    • Manual de instalación y despliegue
    • Manual de usuario
    • Prototipo navegable
  • Gestión de proyectos basada en el PMBoK

Y se tenían los siguientes problemas
  • El único que conocía el avance era el gerente de proyecto
  • Los ingenieros tenía un listado de tareas que realizaban según disponibilidad de los insumos sin un objetivo común
  • Los ingenieros percibían que no iban a alcanzar a realizar la entrega pero no lo habian comunicado.

Desenlace
Luego de implantar Scrum estas son algunas de las conclusiones.
  • El seguimiento es propiedad del equipo, no solo del gerente del proyecto. Siendo el burndown chart una propiedad del equipo y un compromiso de todos tenerla actualizada.(a todos nos da felicidad de la gráfica baje!!!)
  • Las reuniones de seguimiento diario han mejorado comunicación y dinámica del equipo (más detalle acá)
  • Se resolvieron problemas de salida a pruebas mucho tiempo antes de enfrentarnos con ellos en 
  • El cliente tiene un lugar donde hacer  "clic" y percibir el avance.
  • El equipo se encuentra altamente motivado.
  • Mitigación temprana de riesgos de desarrollo, y pruebas.
  • Equipo enfocado en un objetivo común: EL SPRINT!!.
  • Obtencion de una velocidad del equipo que permite predecir entregas (de 25 a 33 horas por día - similar a lo que dice PSP, que solo es efectiva la mitad de nuestro tiempo laboral).
  • Menos presión sobre el cronograma
  • Un enfoque a los objetivos
Burndown Chart - Iteración 1

Velocidad - Iteración 1