Ingeniería Ágil – Resultados del segundo encuentro ágil en Barcelona

 

En este encuentro participaron 11 personas que explicaron sus experiencias, los beneficios y dificultades que habían encontrado en los siguientes temas:
  • Integración continua con pruebas automatizadas y TDD.
  • Deuda técnica vs perfeccionismo.
  • Integración continua en entornos multiequipo.
  • Aprovechamiento de los nightly builds para métricas de calidad y pruebas de stress.
  • El valor aportado al cliente mediante prácticas de ingeniería ágiles.
Otros resultados del encuentro:
  • Se identificaron nuevos temas del “track” de ingeniería para próximos encuentros: herramientas, frameworks, resistencia a la introducción de metodologías ágiles, pair programming, automatización de los tests de aceptación y documentación automática.
  • Se propusieron los siguientes workshops:
    • Aplicación práctica de TDD
    • Integración continua con Maven 2
    • Integración continua con Hudson

Para obtener más valor de próximos encuentros, se propusieron las siguientes técnicas:

  • Exposiciones de experiencias reales, en que los asistentes realicen preguntas y proporcionen consejos.
  • Talleres alrededor de un objetivo ficticio, preparado con anterioridad para obtener el máximo de la sesión.
A continuación se detallan las ideas que se trataron respecto a estos temas.
 

 
Pruebas unitarias
 
Las pruebas unitarias son uno de los principales protagonistas del desarrollo ágil:
  • Las pruebas unitarias son claves para realizar cambios con seguridad (cuando se introducen nuevas funcionalidades, se hacen refactorings, etc.), por el hecho de disponer de una malla de pruebas automatizadas que avisa cuando algo se rompe.
  • Las pruebas unitarias sirven como documentación técnica del uso del código.
Sin embargo:
  • La integración es un problema complicado, que no se resuelve únicamente con pruebas unitarias. Para ello existen frameworks específicos:
    • Para solucionar la relación con la base de datos: DBUnit, MockObjects, etc.
    • Inyección de dependencias, Aspect Oriented Programming como Spring. La comunidad Open Source está dirigiendo sus pasos hacia esta filosofía, que permite desacoplar y probar de manera independiente componentes y permite no escribir el código de servicios transversales (como requisitos no funcionales) dentro del código de negocio (por ejemplo, no escribir el try/match/rollback, realizar pruebas sin servidor de aplicaciones, no necesitar un pool de conexiones, utilizar URL rewritting, limpiar diariamente una tabla, etc.).
  • Las pruebas unitarias están lejos del “negocio”, pierden un poco de vista el objetivo al que están sirviendo.
 
Pruebas funcionales

 

  • La automatización de pruebas funcionales y de aceptación es más compleja, aunque cada vez existen mejores herramientas: Fitnesse, HTTPUnit, Jmeter, etc.
  • El cliente debería participar en su definición.
 
TDD
 
Se distinguieron los siguientes enfoques para el desarrollo guiado por pruebas:
  • TDD en pruebas de aceptación. Los casos de pruebas de aceptación se escriben en el momento de crear una historia de usuario y quedan ligados a ella. Estas condiciones permiten:
    • Verificar que la historia ha sido completada.
    • Mueven el rol del experto en pruebas funcionales al inicio del proceso, evitando que aparezcan errores (al clarificar el objetivo de la historia), en lugar de sólo dedicarse a buscarlos.
  • TDD en pruebas unitarias.
    • Siguiendo XP y TDD, primero se deben escribir las pruebas. Sin embargo, es difícil pensar en abstracto, hacer arquitectura y diseño durante la elaboración de casos de prueba para unas clases que todavía no existen. De cualquier manera, existe buena literatura al respecto, mencionándose a la autora Lisa Crispin.
    • Hay que asumir el esfuerzo de cambiar el código y pruebas ya existentes, así como refactorizar.
Cómo solucionar la deuda técnica

 

  • Ante preguntas del tipo ¿Qué hacer cuando la deuda técnica acumulada es grande, cuando hay necesidad de hacer grandes refactorings o el número de bugs acumulados es alto? se plantearon diferentes respuestas:
    • Explicar al cliente los problemas existentes y crear historias específicas para resolverlos, de manera que la decisión de qué problemas arreglar y cuando hacerlo sea suya.
    • Solucionar los problemas dentro de historias que den valor al cliente, arreglando la parte de deuda técnica afectada.
Deuda técnica vs perfeccionismo
 
Una tarea puede dilatarse por condicionantes propias de la condición humana:
  • Cuando una persona crea algo, se siente responsable y puede querer un resultado perfecto.
  • Las personas buscan no sólo realizar tareas, sino su satisfacción personal. Esto puede llevar, por ejemplo, a “dispersión técnica” (entendida como utilización de técnicas innecesarias o sobredimensionadas que no aportan valor y que incluso pueden llegar a complicar en exceso el producto).
Dilatar el tiempo de un proyecto de esta forma es encarecerlo. El tiempo dedicado a hacer una tarea no pertenece al desarrollador, si no a quien le paga, que es su empleador y, en última instancia, el cliente. Por ello, puede ser conveniente tener siempre algo de deuda técnica: “no tienes que tener el mejor producto”.
 
 
Integración continua

 

  • Integración en un entorno multiequipo.
    • La integración continua minimiza la necesidad de disponer de diferentes ramas para grupos de programadores, pero siguen siendo necesarias en caso de que estos grupos trabajen en proyectos u objetivos de negocio bastante desacoplados que pueden subir a producción en momentos diferentes. En ese caso, cada equipo puede trabajar en su propia rama (con integración continua) y, cuando se decide que el trabajo de un equipo debe formar  parte de una entrega, integrar manualmente hacia una rama central (donde ya no debería haber marcha atrás). Cualquier arreglo de bug en esta versión ya va directamente desde el desarrollador hacia esta rama.
    • Perforce gestiona mejor las “marchas atrás” que Subversión.
  • Aprovechar los nightly builds para realizar tareas que serían demasiado costosas en cada commit:
    • Métricas de calidad, por ejemplo con Checkstyle y Simian reports (como detector de “copy & paste”s).
    • Pruebas de stress.
  • Se resaltan las cualidades de Maven 2 como herramienta de integración continua.
 
El valor aportado al cliente mediante prácticas de ingeniería ágiles
 
Resultó especialmente interesante el análisis de estas prácticas no sólo a nivel de ingeniería, sino también considerando su impacto en la gestión del proyecto y, especialmente, en el valor que aportan al cliente.
  • ¿Por qué conviene al cliente que el equipo trabaje de manera ágil, utilizando integración continua con pruebas automatizadas?
  • ¿Le interesa un esfuerzo/coste superior en las primeras iteraciones del proyecto que se verá compensado en el medio plazo?
  • ¿Qué cobertura y profundidad hay que aplicar con automatización de pruebas?.
La respuesta fue: DEPENDE. Depende del grado de calidad que quiera el cliente (de cómo él defina lo que entiende que es calidad), del producto, del proyecto, del conocimiento de los requisitos que tenga el cliente, de tener una estrategia empresarial orientada a calidad (cosa que puede repercutir en tener unos precios más altos que la competencia), etc.
De cualquier manera, se subraya los beneficios de aplicar estas técnicas:
  • Mayor flexibilidad frente a cambios: disponer de una malla de tests que avisa cuando algo se rompe.
  • Y, en definitiva, mayor calidad respecto a:
    • Expectativas del cliente.
    • Minimización de errores.
    • Mantenimiento del sistema.
Temas y metodología a seguir en próximos encuentros
 
Se identificaron los siguientes temas para el “track” sobre ingeniería ágil:
  • Herramientas de soporte al desarrollo ágil, frameworks y plataformas.
  • Resistencia a la introducción de metodologías ágiles
  • Pair programming
  • Automatización de los tests de aceptación
  • Documentación automática
Se propusieron los siguientes workshops:
  • Aplicación práctica de TDD
  • Integración continua con Maven 2
  • Integración continua con Hudson
Para obtener más valor de próximos encuentros, se propusieron las siguientes técnicas:
  • Exposiciones de experiencias reales, en que los asistentes realicen preguntas y proporcionen consejos.
  • Talleres alrededor de un objetivo ficticio, preparado con anterioridad para obtener el máximo de la sesión.
Para apuntarse a los próximos encuentros en Barcelona sobre los temas y workshops anteriores: http://agile-spain.wikidot.com/quedadas-barcelona.
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.

 

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s