• 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.

• 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.

• 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.

• 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.

• 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 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.

• 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.

• 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).

• 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.

• ¿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?.

• 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.

• 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

• Aplicación práctica de TDD
• Integración continua con Maven 2
• Integración continua con Hudson

• 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.