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



4 comentarios:

  1. - revisiones par
    - control de versiones

    Para la segunda iteración comenzamos a implementar:
    - integración continua con verificación de codigo java y sql
    - TDD

    ResponderEliminar
  2. Me parece genial esta iniciativa, sin embargo pienso que la prioridad inicialmente se le debe dar a la parte de ingeniería, a las practicas de ingeniería.

    SCRUM es fácil de implementar, condición por la cual ha sido el método preferido en el universo de metodologías agile, sin embargo también es muy fácil fallar en el intento de construir equipos de desarrollo que produzcan aplicaciones en tiempo, dentro del presupuesto y de calidad (lo que el cliente quiere o mejor aun lo que realmente necesita) usando SCRUM.

    SRCUM esta totalmente orientado a la dirección de los proyectos pero no hace mención de la parte técnica, a las practicas de ingeniera. Yo considero que las practicas de ingeniería usadas son primordiales para llegar a construir equipos hiperproductivos de desarrollo.

    La parte técnica es aun mas importante que la parte de dirección y/o metodología. Es mas importante la sustancia que el procedimiento. No porque a un ferrocarril se le pongan alas quiere decir que puede volar.

    Practicas como: control de versiones (esta es la base de CI), pruebas automáticas (unitarias, integración y funcionales) -sin pruebas automáticas hacer CI es un caos-, refactoring, continuos integration, continuos delivery (pipeline), principios OOP, uso de patrones, son fundamentales en el éxito o fracaso de un proyecto.

    El código mal escrito, genera altos costos, por lo general este es un síntoma que deteriora los proyectos de manera progresiva, no existe cura desde el punto de vista metodológico para este mal que aqueja muchos proyectos de software, es ahí donde las practicas juegan un papel fundamental pues la metodología poco puede hacer en contra de esta enfermedad.

    La idea es que incluir una nueva funcionalidad tome un tiempo constante a pesar del momento de su inclusión, me refiero a que desarrollar una funcionalidad debe tomar el mismo tiempo cuando el proyecto se esta empezando a cuando el proyecto o código lleva años.

    La llamada technical debt, de la cual sufren en su mayoría equipos que no usan las practicas de ingeniería apropiadas, es un síntoma mas de código mal escrito, esto al final se traduce en altos costos de mantenimiento, altos costos para incluir nuevas funcionalidades, altos costos para cambiar funcionalidades existentes, listas de errores interminables... en resumen trasnocho, horas extra, proyectos estallado y clientes insatisfechos.

    Yo he desarrollado código, malo, horrible, probablemente todavía es una grosería, el problema radica en que es difícil saber lo que no se sabe, aun cuando ya llevaba como 4 años tirando código seguía escribiendo programas que podrían causar una ulcera hasta al mas benévolo, las aplicaciones funcionaban..., bueno hasta cierto grado, pero era una pesadilla hacer un cambio, listas interminables de errores... Solo desde el momento en que empecé a trabajar en un entorno que usa las practicas que arriba mencione me di cuenta de lo mal desarrollador que era/soy.

    Yo primero apostaría a cambiar desde la base, empezar por implementar las practicas de ingeniería apropiadas, capacitar el equipo, motivarlos a los desarrolladores a investigar, a que se metan en el rollo de mejoramiento continuo, clean code, software craftsmanship. Yo empezaría con dos cosas muy importantes, VCS y CI, desde que el equipo de trabajo tenga un servidor CI y pueda desplegar la aplicación automáticamente todos los días tendrá mucho terreno ganado, pero acá debo resaltar que para implementar CI efectivamente las pruebas automáticas son fundamentales. Desde ese momento, cuando tenes mejor código, estarás en una mejor posición para montar la metodología.

    Precisamente he estado leyendo mucho del tema ultimamente, me contas que te parecen los enlaces:

    http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
    http://martinfowler.com/bliki/FlaccidScrum.html
    http://xprogramming.com/blog/2009/01/30/context-my-foot/
    http://tech.groups.yahoo.com/group/extremeprogramming/message/148122




    ResponderEliminar
  3. Pues uno de los elementos claves ha sido el equipo motivado... y eso lo hemos logrado.. y tenemos un compromiso con la calidad y mejora.

    Nuestro segundo paso es:
    - Integración continua
    - TDD

    Pero los beneficios del desarrollo iterativo e incremetnal los percibimos inmediatamente.

    Y vos sabes que coincido con vos.. sobre buen código y buenas prácticas de desarrollo se puede montar cualquier metodologia de desarrollo y gest8ion.

    Cuando preguntaste que practicas de ingeniería habia implementado, vos sabes que son muchas... unas orientadas al codigo, otras a la documentación, otras al despliegue, etc.


    Pero.... nuestro objetivo 2 es CODIGO BONITO!!!! y cuento con el equipo motivado y con las aptitudes para lograrlo.!!!

    ---
    Se te reciben links para estudiar igual que sugerencia de libros.

    ResponderEliminar