Hoy vamos a hablar de varias practicas utilizadas en metodologías ágiles. Algunos de vosotros, quizás, al verlas pensaréis que son metodologías en si mismas pero no es así. Este pequeño equivoco se produce porque en muchas ocasiones solo se adoptan estas prácticas dejando de lado el resto de la metodología. Pero bueno, vamos a entrar en materia.

Desarrollo orientado a pruebas

También conocido como TDD (Test Driven Development). Esta técnica se utiliza en el desarrollo de software y consiste en diseñar e implementar las pruebas antes de empezar con el desarrollo del código. Estos test se implementan pensando en las pruebas necesarias a realizar para probar las nuevas funcionalidades o mejoras que se van a desarrollar en la siguiente iteración. Hay que destacar que no es solo una técnica enfocada a pruebas, sino que también es un método de diseño de software.

Esta práctica requiere que se creen pruebas unitarias automatizadas para definir los requisitos que se van a implementar a continuación, de este modo, al escribir el código se escribirá el mínimo para pasar los test evitando de esta forma escribir código innecesario. También y aunque parezca una tontería, con este método se nos obliga a tener pruebas implementadas de todas las funcionalidades implementadas porque, para que engañarnos, cuando uno se queda sin tiempo en un proyecto, lo primero que cae es la documentación, y después, la implementación de los test unitarios.

Las fases para cada ciclo de desarrollo serían las siguientes:

1. Añadir pruebas: Para cada modificación o nueva funcionalidad que se vaya a desarrollar. Para esto, obviamente, hace falta entender perfectamente los requisitos que se van a implementar. Ni que decir tiene, que la primera vez que pasemos estos test tras su implementación, deberían de fallar.
2. Validar las pruebas: Ejecutarlas para ver que efectivamente fallan con los nuevos requisitos.
3. Escribir el código de las nuevas funcionalidades. En esta fase, no es necesario que el código sea elegante o esté perfectamente refactorizado, para esto ya habrá una fase posteriormente.
4. Ejecutar las pruebas y ver que todas pasan con éxito para asegurarnos que todos los requisitos están correctamente implementados. Recordemos que los test de prueba nos deberían garantizar dicha implementación.
5. Refactorizar el código y volver a ejecutar las pruebas para comprobar que no hemos roto nada.

Por supuesto lo ideal sería hacer un ciclo completo por cada nueva funcionalidad o mejora para que no se den casualidades del tipo de romper algo y que otra modificación lo enmascare, de esta forma no perdemos control sobre nuestro código, pero en equipos de trabajo con varios desarrolladores, las exigencias temporales de los proyectos no suelen permitir esto.

Como para todo, esta práctica tiene sus ventajas y sus inconvenientes, así que deberíais ponderar vosotros mismo si esta práctica os va a beneficiar o no.

Integración continua

Entendemos por integración continua la compilación y la ejecución de pruebas del proyecto la cual nos ayuda a incrementar la velocidad de desarrollo. Dicho proceso de integración continua nos permite una constante comprobación de los cambios realizados por los desarrolladores. De esta forma podemos comprobar que dichos cambios no producen fallos en otras partes del proyecto, es decir, no producen problemas de integración con el código de nuestro proyecto.

Pero, ¿en que consiste un entorno de integración continua? Pues bien, esto no es más que un proceso automatizado de construcción del software desde los repositorios y despliegue de este en un entorno de integración en que se realizan las pruebas. Existen muchas acciones que pueden desencadenar que se lance este proceso automático de integración, por ejemplo: Una determinada hora del día (generalmente de noche), previamente a un pase entre entornos, y sin duda una de las más utilizadas, cada vez que se realiza una subida de código al repositorio. En general, cada equipo debe adaptar el sistema a su proyecto. No es lo mismo lanzar una compilación que tarda entre dos y cinco minutos que una que tarda dos horas. Igualmente no es lo mismo desplegar algo que solo tarda unos diez minutos que algo que tarda mucho más. De esta forma, quizás nos interese realizar la compilación cada vez que uno de nuestros desarrolladores realice una subida al repositorio y solo realizar el despliegue un par de veces al día. Como he dicho, estas son decisiones que habrá que tomar según el proyecto y entorno en el que nos encontremos.

La utilización de los sistemas de integración continua nos obliga a adoptar una serie de buenas prácticas o de prácticas recomendadas, entre las que se incluyen las siguientes:

• Utilización de repositorios de código: El utilizar la integración continua nos obliga a utilizar repositorios de código (CVS, SVN, GIT, …) y a trabajar de forma correcta con estos. Seguro que alguno está pensando que esto es básico, pero os sorprendería la cantidad de gente en el ámbito empresarial que no los utiliza.
• Construcción automática de nuestro sistema: Y cuando hablo de construcción no solo me refiero a la compilación, sino que incluimos también la generación de documentación, archivos distribuibles y el despliegue en un entorno clonado de producción. Es decir, todos aquellos elementos que nuestro proyecto posea. Y además, todo ello echo con una sola instrucción y de forma automática.
• Construir nuestro sistema asiduamente: Como ya he comentado anteriormente, una buena práctica es cada vez que se realiza una subida de código al repositorio, de esta forma podremos detectar rápidamente los fallos y problemas de integración y corregirlos. Existen muchas sistemas divertidos para darle un poco de competitividad sana a esto, por ejemplo, utilizar señales visuales si la build se rompe (Jenkins y Hudson, tienen plugins muy divertidos), un sombrero con orejas de burro para el que rompe la build. Y podéis encontrar prácticamente de todo, la gente tiene mucha imaginación, desde semáforos, lámparas de lava hasta vacas que mugen o robots que bailan.
• Disponibilidad de entregables: La construcción asidua hace que estén siempre disponibles entregables actualizados de la aplicación, en este sentido, se facilita que equipos de QA, documentación, marketing y otros relacionados con el proyecto, pero no con el desarrollo, puedan tener de forma fácil las últimas versiones.

Como todo, este tipo de práctica también tiene sus desventajas, pero en mi opinión salvo casos muy específicos, en son depreciables frente a las ventajas que nos ofrece. Algunas de estás desventajas serían, por ejemplo, favorece la realización de un menor número de subidas al repositorio por miedo de los desarrolladores a romper la build, se necesita mantener un entorno clonado del de producción con el gasto que esto conlleva y se requiere que cada vez que haya cambios que afecten al método de despliegue del proyecto, estos haya que automatizarlos, lo que en general provoca un mayor tiempo de mantenimiento del sistema.

Pair Programming (Programación por parejas)

Una de las técnicas más controvertidas sin lugar a dudas. Principalmente consiste en que dos programadores trabajen juntos en un mismo ordenador escribiendo código de forma simultanea, de forma que mientras que uno de ellos escribe código y se preocupa de la parte técnica, el otro revisa lo que se va escribiendo y se encarga de generar ideas de mejora. Ambos roles son conocidos como “driver”, el que escribe el código, y “Observer” el que lo revisa. ¿Por qué digo que es una de las más controvertidas? Pues principalmente, por razones obvias, son dos personas trabajando en un ordenador, lo que inicialmente se percibe como que se va a realizar la mitad del trabajo. Esto unido a entornote de outsourcing donde se cobra por programador/hora pues no da inicialmente una sensación de productividad y de aprovechamiento de recursos. Pero dejando estás opiniones a un lado, tiene sus ventajas y sus inconvenientes como todo.

Sobre las ventajas podríamos decir que:

• La transferencia de conocimiento entre programadores y la formación de estos se realiza de un modo más fácil y controlado. Siendo una gran ventaja emparejar a un programador novel con una veterano, el programador novel aprenderá rápidamente conceptos técnicos y de negocio.
• Mejor código, desde el punto de vista técnico, de optimización y de claridad. El código se escribe para que ambos programadores lo entiendan y programadores con más experiencia pueden aportar muy buenas ideas a programadores menos expertos.
• Mejora la capacidad de enfrentamiento a los problemas, ya que como siempre se ha dicho, dos cabezas piensan mejor que una. Muchas veces, y seguro os ha pasado a todos, basta con discutir algo con alguien en voz alta para que os llegue la solución a algo con lo que llevabais varias horas lidiando.
• Reducción de errores. El hecho de que el código sea escrito y supervisado de forma simultanea, hace que se solventen muchos errores que de otra forma saldrían más tarde generando costes adicionales al proyecto.
• Trabajar con alguien siempre es más ameno y divertido, o cual hace afrontar el trabajo con una mentalidad más positiva. Además, saber que tienes a otra persona en la que apoyarte, da más moral y confianza a la hora de afrontar retos difíciles.
• Evitamos distracciones como por ejemplo leer el correo, consultar redes sociales, blogs, navegando por Internet ya que nuestro compañero nos está mirando por encima del hombro. Esto favorece una mayor disciplina de trabajo.
• Evita interrupciones externas. Es más difícil que vayan a molestar a dos personas que están discutiendo sobre algo o simplemente trabajando juntas que a una persona que trabaja aislada.
• Y una evidente, necesitamos menos ordenadores.

Como todo también tiene sus desventajas:

• El principal, como ya he dicho, es que dos personas están realizando el trabajo de uno. Y esto no cambia hasta que de verdad empieza a funcionar bien y la eficiencia se duplica.
• Por lo general muchos desarrolladores prefieren trabajar solos. Nuestros casos, nuestra música y nuestro teclado. Esto puede resultar a veces difícil de cambiar.
• Roces entre desarrolladores por diferentes hábitos. Desde tabulaciones, hasta nombre de variables, pasando por nombres de funciones, distribución del código, etc… Lo mejor, tener todo esto definido de antemano. Formateo de código automático, patrones para nombrar funciones, variables y paquetes; y esquema de paquetes de la aplicación. Y sobretodo, el ego, algo muy extendido entre los desarrolladores.
• –       Problemas de intimidación por parte de desarrolladores sin experiencia al emparejarlos con desarrolladores experimentados, o a la inversa, problemas de desarrolladores experimentados que encuentren tedioso la autorización de un desarrollador novel.

En mi opinión, quizás en el día a día no sea necesario utilizar siempre esta programación por parejas, pero tiene momentos en los que es de muchísima utilidad. Por ejemplo, a la hora de afrontar nuevos retos en tecnologías que se desconocen, a la hora de afrontar proyectos en áreas de negocio poco conocidas, y sobre todo de cara a introducir a nuevos desarrolladores en un proyecto. No hay que estar todo el día con ellos, pero un par de horas de programación por parejas, sobre todo ante retos técnicos o zonas de negocio complicadas si que me parece muy útil.

Bueno, hasta aquí esta serie de artículos sobre el desarrollo ágil. Espero que os haya servido de algo y os decidáis a incorporar algunos de los puntos o todos, recordemos lo que ya hemos dicho con anterioridad, “no nos tenemos que ajustar a las metodologías y prácticas ágiles, estás se tienen que ajustar a nuestras necesidades”, de está forma adaptaremos aquello que realmente nos pueda beneficiar tanto económicamente como para mejorar como desarrolladores y equipo. Nos vemos.