Las 10 prácticas ágiles más útiles (I)

Hoy voy a hablar de un tema muy en boga: las técnicas o prácticas ágiles. De ellas, se ha hecho un estudio a expertos profesionales en la materia. El estudio ha sido conducido por Teodora Bozheva, una excelente formadora en algún curso de calidad en el que he tenido el placer de asistir. Podéis ver los datos fuente aquí.

Pero tal como estuve hablando con Teodora, los datos no son más que eso, así que me animé a pedirle permiso para a partir de sus datos, darle una vuelta de tuerca y llegar más a fondo. Vamos con ello intentar responder a varias preguntas no sólo sobre las técnicas agiles, sino también sobre nuestro propio conocimiento de dichas técnicas.

Vamos a partir de los resultados, que podemos ver en la siguiente gráfica:

Lo primero a destacar, es que no hay una diferencia abismal entre los primeros y los últimos en este grupo.
Vamos a ver un poco los más útiles:

• Automated Builds: la compilación automática, forma parte tradicionalmente de los sitemas de integración continua, aunque es perfectamente válido el considerarlo de forma autónoma.
• Continuous integration: el 2º clasificado, viene a confirmar que la automatización de tareas, se sigue considerando una técnica ágil muy útil.

Hagamos un breve inciso aquí para tener en cuenta que los dos primeros clasificados están muy relacionados. De hecho, habrá defensores que lo consideren como uno sólo. Los dos siguientes, están también relacionados, y sí que podrían considerarse técnicas puramente ágiles (mucho más asociadas a las metodologías ágiles que las dos primeras, por ejemplo):

• Daily stand up meeting: la técnica de realizar breves reuniones de pie, diariamente, y de forma informal pero con un objetivo definido de poner en común las tareas en curso de cada uno, y los problemas encontrados o que nos atascan.
• Iteration planning: tradicionalmente vinculado a la programación extrema (Extreme Programming o XP), esta práctica consiste en la ejecución de la iteración: desde el desglose y estimación de las tareas, su asignación, y posterior desarrollo, ejecución de pruebas unitarias, etc., hasta la siguiente iteración.

Algunos puntos importantes a indicar aquí sobre estas dos prácticas: la primera es extremadamente económica de implementar. Cualquier proyecto puede incorporar esta técnica, sin coste ni importantes efectos colaterales (salvo quizás el incremento de visión de los integrantes del equipo). La segunda, sin embargo, exige una involucración más profunda en las metodologías ágiles. Exige por tanto, un cambio significativo en la forma de organizar el trabajo, planificarlo, y reportarlo.

Para terminar hoy, vamos a quedarnos con dos técnicas ágiles, que a pesar de estar incluidas aquí, son en realidad técnicas habituales en cualquier desarrollo de software ("ágil" o no):

• Coding Standards: Se trata de disponer de estándares de codificación  o de desarrollo específicos del proyecto.
• Unit Testing: consiste en la planificación, diseño, programación y ejecución de pruebas enfocadas a probar un único componente o función.

En primer lugar resulta curioso el considerarlos técnicas ágiles. En segundo lugar, son aspectos prácticamente de uso obligatorio en cualquier desarrollo moderno de hoy en día. En cuanto al coste, ambos son elementos costosos de implantar, ya que requieren de formación específica, y en algunos casos, de herramientas específicas tanto para su uso como para su verificación.

Dejaremos para otro día, la segunda parte de este artículo, revisando las técnicas que quedan.

Cuanto antes empieces a codificar más tarde terminará el proyecto

Este proverbio, lo he encontrado en la web de Calidad del Software. Le he dado una leída, y me he dicho: "pero qué pedazo de tontería es ésta".

Pensándolo un poco más despacio...no deja de tener razón. Me explicaré.

En mi experiencia, han sido ya muchos proyectos durante todos estos años en los que aunque se ha hecho el debido análisis y diseño, la presión por parte de la gerencia ha acabado obligando a que "el equipo que vaya echando código, y tú en paralelo ya harás el análisis y diseño". Al final, incluso la planificación iba muy por detrás de la ejecución de actividades.

Esto tiene sus contrapartidas:

• Es necesario dar una visión (funcional), que aunque incompleta, permita al equipo "saber hacia dónde va". Esto obliga a que al menos, esté completada esa visión en el análisis funcional. Es decir, no basta con solamente poner los requisitos (historias de usuario en Scrum) que vayan a empezar de forma inmediata.
• Aunque creamos saber "hacia dónde va" nuestro desarrollo, no todo puede hacerse en base a "bloques independientes". Muchas veces, aceptamos que el software evoluciona en cuanto a sus requisitos (véase SCRUM). Sin embargo, estamos ciegos al pensar que la arquitectura del sistema no va a cambiar también. Y aquí es donde los desarrollos iterativos chocan con la triste realidad de tener que incorporar en cada iteración (o release), un gran esfuerzo en integrarse con lo existente, y probarlo todo otra vez.
• El tamaño importa: en un desarrollo pequeño, estos comentarios pueden ser de escasa importancia. El esfuerzo en "asentar" un software sin análisis o diseño o arquitectura, puede ser despreciable. Conforme el tamaño del software aumenta (y es importante identificar muy al principio el tamaño del software), todo esto cobra importancia de forma exponencial.
• Muchas veces se olvida que la documentación de análisis, diseño y arquitectura son parte de los entregables. ¿Por qué? Simplemente porque realizar el mantenimiento de una aplicación, basándose solamente en los comentarios que nos han dejado los antecesores, es un suicidio. Queda muy bien lo de "yo no necesito documentar, ya que dejo buenos comentarios". Esta frase es muy típica de la gente poco experimentada, que apenas ha hecho mantenimientos, o los ha hecho de aplicaciones con poca trayectoria.

Esta frase tampoco tiene porqué ser tomada a la inversa: si vamos retrasando la programación, llega un punto en que la definición ya está casi cerrada. Es absurdo que pretendamos tener el 100% de la documentación cerrada para empezar a programar. Hay que evaluar la madurez de lo que tenemos, y controlar los riesgos de que cambien las cosas.

A este respecto, nada mejor que contar con la experiencia de un buen analista y un buen arquitecto que cierren los puntos clave, un jefe de proyecto experimentado que coordine la aprobación y seguimiento de esta documentación inicial....y a partir de ahí, versionar esa documentación.

La desgracia, es que muchos programadores (por no decir todos), se sienten cómodos aplicando cambios al código. Pero no actualizando la documentación conforme esos mismos cambios. Además, esto se ve agravado con el hecho de que los jefes de equipo y proyecto no fomentan actualizar esa documentación. Así que dada esta escuela de comportamiento, seguimos fomentando las malas prácticas.

Y ojo, no se trata de tocar la documentación con cada línea de código. Si sabemos qué se ha tocado, bastaría juntar cada 2, 3 o 4 semanas de desarrollo, los principales cambios técnicos y funcionales, y dedicar un rato a que algunos documentos no se desfasaran. También aquí hay que ser pragmáticos, si el entregable principal es el documento funcional, apliquemos ahí el mayor esfuerzo. Si es el técnico, pues lo mismo.

Hablemos de estándares

Los estándares, en el mundo del software, son uno de los facilitadores más sencillos que existen. Sin embargo, tienen muchos detractores y están muy mal vistos por colectivos que ven en el desarrollo del software un medio de expresión, un "arte", y que están en contra de las normas y directrices.

Las normas y directrices ayudan a luchar contra las diferencias que presentan los distintos componentes de un proyecto:

• Diversidad cultural
• Creencias
• Niveles de conocimiento
• Años de experiencia
• Personalidad
• Barrera idiomática
• Jerga Profesional

¿Y qué deberían cumplir estas normas, reglas o estándares?

• Simples, fáciles de entender
• Si es posible, incluir ejemplos de uso, y demostración de su utilidad práctica
• Los estándares no pueden ser extensos. Nadie va a recordar un documento de 200 hojas.
• Los estándares pueden ser muchos. Por ejemplo, si en nuestra empresa se programa en 20 lenguajes, puede haber una mini guía o estándar por cada uno.

Recomendaciones:

• Mantener vivos los estándares. Pocas cosas hay peores que dejar las cosas en el olvido. Las tecnologías evolucionan, y los estándares están muy relacionados con las tecnologías del momento. Es por eso que los documentos donde se recojan los estándares han de estar actualizados constantemente. Las actualizaciones han de estar disponibles, y la gente ha de conocer de forma clara el motivo de la actualización. 
• Evitar actualizaciones muy frecuentes: por ejemplo, que sólo los proyectos nuevos a partir de una fecha utilicen la última versión de los estándares. No hay peor cosa para la gente que esté en un proyecto, que la distraigan cambiando las normas. Bastante cambian ya los requisitos, los hitos, las entregas, etc., como para que encima cambie la forma en que hacemos las cosas en el día a día.
• Realizar formaciones. De nada sirve dar a la gente al principio del proyecto un documento para que se lo lea. Tampoco será muy útil tratar de castigar o penalizar a quien no lo siga. Mucho más práctico será realizar cursos periódicamente, que además de sobre los estándares, puede incluir las últimas novedades de la tecnología que se use (esto suele ser mejor reclamo que los estándares en sí).
• Incentivar el uso. Puede aplicarse un incentivo positivo: por ejemplo, dar premios o bonus a los desarrolladores que mejor resultados tengan en los tests relacionados con estos estándares (y mejor si son pruebas automatizadas).
• Penalizar el desuso. Yo en general, estoy en contra de esta práctica, pero habrá quien la vea útil. Es la contraria de la anterior, y consistiría en penalizar a los desarrolladores con peores prácticas (desde el punto de vista de los estándares recomendados).

Pues nada, ahora que sabemos la teoría, dejaremos para un próximo post el ir aterrizando estándares "palpables" para algunas tecnologías. Nos vemos.