Continuous Delivery: ¿Por qué te puede interesar?

Empecemos definiendo qué es Continuous Delivery (CD): Consiste básicamente en la implantación de un proceso repetible y confiable para la liberación de software evitando, en la medida de lo posible, la intervención humana. Los autores de Continuous Delivery [1] aconsejan que la única intervención por nuestra parte para la liberación de una nueva versión sea la de pulsar el botón de despliegue para lo que será necesario disponer en todo momento de una versión de software estable listo para la entrega.

Este objetivo es realmente ambicioso y como te puedes imaginar su puesta en marcha requiere un esfuerzo importante por lo que deberías hacerte algunas preguntas antes de planteártelo. Para ayudarte en esta  decisión te recomiendo que leas las siguientes situaciones, si te resultan demasiado familiares te puede compensar hacerte con el libro y profundizar en sus ideas.

Situaciones derivadas de un proceso de despliegue manual

En muchas organizaciones la gestión de la configuración del entorno de producción se lleva a cabo directamente por equipos de operaciones. De esta forma cuando se requiere cambiar la cadena de conexión a una base de datos, el acceso con certificado o el uso del canal seguro para una aplicación se lleva a cabo manualmente en los servidores de producción. Este hecho puede provocar las siguientes situaciones:

• Para desplegar un sistema es necesaria la edición de elaborados manuales de instalación que describen secuencialmente los pasos que deberá realizar el equipo de operaciones.
• El proceso de despliegue finalmente no sigue el plan establecido, en diferentes momentos es necesario  improvisar y no se sigue el manual. 
• Se hace necesario establecer una conexión telefónica permanente entre desarrollo y operaciones durante el proceso de despliegue. En ocasiones se requiere desplazar algún miembro del equipo de desarrollo a las instalaciones del equipo de operaciones.
• Se hace necesaria la realización de pruebas manuales en entorno de producción para asegurarnos que la aplicación se ejecuta correctamente y que interacciona de forma adecuada con sistemas externos.
• Falla un despliegue en producción aun después de haberse desplegado perfectamente en entorno de pre-producción.
• Los nodos de un cluster tienen diferentes versiones de sistemas operativos, componentes de terceros o parches, lo que deriva en que la aplicación se comporta de diferente forma dependiendo del nodo que atiende la petición.
• El equipo de operaciones requiere más tiempo del estimado inicialmente para preparar el entorno requerido por una versión específica de nuestro software.
• No es posible retroceder a una versión anterior de un sistema después de un determinado pase que implica bases de datos, servidores de aplicaciones, parches de sistemas operativos, etc.
• La configuración de los sistemas se llevan a cabo manualmente a través de herramientas de administración proporcionadas por los propios Sistemas Operativos, SGBD, servidores de aplicaciones, etc.

Situaciones derivadas de desplegar en entorno real justo cuando finalizamos el desarrollo

Esto suele ser muy común y no deja de ser un problema puesto que existe un enorme número de riesgos asociados a la arquitectura técnica (¡pueden exigir tocar código!) que se descubrirán cuando el equipo de desarrollo da por finalizado su trabajo. Obviamente cuanto más tardemos en "conocer" el entorno de producción mayores y más peligrosos se harán estos riesgos, de esto ya hablamos en un post anterior por lo que argumentábamos que el día 1 era el mejor momento para el despliegue. A continuación se describen alguna de las situaciones que nos podemos encontrar

• La primera vez que el equipo de operaciones se "enfrenta" al nuevo software es el día D. Generalmente las organizaciones siguen una política común que minimiza este impacto pero siempre existe un motivo para que en desarrollo nos veamos obligados a realizar un proyecto que se sale de la norma provocando que el equipo de operaciones no se encuentre tan "cómodo" con el despliegue. 
• El entorno de pre-producción (lo más parecido que tendremos a producción) no está disponible hasta que nos encontramos demasiado cerca de la fecha límite.
• Derivado de lo anterior, las pruebas se han realizado sobre el entorno de desarrollo y la pre-producción no se comporta igual ante determinadas funcionalidades.
• Hay poca, o ninguna, colaboración entre el equipo de desarrollo y el de operaciones. 
• En proyectos de larga duración, en los que están implicados equipos de la propia organización y desarrollos subcontratados con proveedores externos es habitual que el despliegue sea el momento de revisar los documentos contractuales. Si el contrato se redactó a nuestro favor y el proveedor debe hacerse cargo de, por ejemplo, un cambio de plataforma, estamos de media enhorabuena... porque seguramente esto ocurra, de nuevo, pisando la fecha límite.

¿Te suena alguna de las anteriores situaciones? Aunque la lista está recopilada de Continuous Delivery [1] personalmente he de reconocer que las he sufrido un su gran mayoría y que podría ampliarla fácilmente.

Reducir estas situaciones es, desde mi punto de vista, suficiente motivo para afrontar el esfuerzo que requiere la implantación de CD, claro que el grado de automatización sugerida puede y debe variar dependiendo de la naturaleza de los sistemas que estemos desarrollando.

Existen dos motivos que a nosotros nos condujeron a CD:

1. Nos resultaba demasiado familiar las situaciones descritas anteriormente. 
2. Desde una perspectiva ágil cuanto menor sea la duración de la iteración mayor necesidad tendrás de automatización en el proceso de despliegue. En nuestro caso, el hecho de utilizar un tablero Kanban en el equipo de desarrollo nos ha generado la necesidad de aumentar la sofisticación del proceso de despliegue debido al flujo continuo promovido por dicho método

En próximos post resumiré las bases mínimas sobre las que se apoya CD, los beneficios esperados así como nuestras experiencias al implementarlo.


Referencias
[1] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Jez Humble y David Farley
[2] http://www.continuousdelivery.com/

¿Restricciones en el demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean

Lean Software Development es la adaptación al mundo del software del Sistema de Producción de Toyota (TPS) principal culpable de que Toyota pasara a ser el mayor fabricante mundial de automóviles e igualmente el motivo por el que todos asociamos a la marca con la Calidad.

Si ya has leído otras fuentes sobre Lean aquí no vas a encontrar nada nuevo, espero que este sea el primero de una serie de post desde nuestra experiencia y pretende dar una breve introducción de sus principios.

Lean Software Develompent no es una metodología, ni método, ni proceso de desarrollo sino que se trata de una serie de principios que debes adaptar a tu propio proceso con el objetivo final de mejorarlo. Por otro lado existen diferentes escuelas de pensamiento sobre Lean que se centran en aspectos distintos, para unos, por ejemplo, lo importante es la reducción del desperdicio (waste) mientras que otros se centran más en el flujo de trabajo. En este post nos centraremos en resumir los principios descritos por Mary y Tom Poppendeick.

PRIMER PRINCIPIO: Eliminar el desperdicio

Definición de desperdicio desde la perspectiva Lean: Todo lo que no aporta valor al usuario. Esto implica tener muy claro qué es valor... monográfico para un futuro post...

En fabricación uno de los mayores desperdicios es el inventario puesto que se debe almacenar, asegurar, mover, se desfasa… en este caso (y sin que sirva de precedente) la propiedad de intangibilidad del software juega a nuestro favor, pero me temo que existe un equivalente: el trabajo parcialmente hecho.

Kanban, por ejemplo, en su fase inicial aconseja la generación de estos almacenes (buffers) como mal menor para mejorar la cadencia del flujo de trabajo, pero una vez conseguido esto, potencia descubrir los cuellos de botella, solucionarlos y minimizar su uso. De hecho, el objetivo final es eliminarlos por completo al igual que hicieron en Toyota apoyándose en el Just In Time (JIT).

Otro de los grandes desperdicios de nuestra industria es la funcionalidad extra que no requería el usuario y finalmente no se utiliza. Sobre esto ya dejé una referencia sobre un grupo de trabajo recientemente creado en Cómo construir el producto que "realmente" esperan.

SEGUNDO PRINCIPIO: Desarrollar con Calidad

Este principio aconseja construir con calidad y descubrir los errores en ciclos tempranos: test unitarios, test de integración, test de sistemas… automatizados.

Evitar mantener vivos los errores apuntados en el sistema de seguimiento de tareas. Obviamente es importante identificar y realizar el seguimiento de los errores, pero en el enfoque Lean un error detiene la cadena de producción para solucionarlo. Un error apuntado en el sistema de seguimiento de tareas es trabajo parcialmente hecho... lo que va en contra del primer principio.

TERCER PRINCIPIO: Crear conocimiento

El proceso de desarrollo del software se acerca al desarrollo de productos (segunda derivada del TPS) y ambos tienen en común que son procesos basados en el conocimiento. Lean aconseja amplificar este conocimiento desde dos dimensiones:

• Es importante aprender sobre el producto en sí. En esto nos ayuda el desarrollo iterativo potenciando una alta realimentación. 
• Igualmente importante es aprender sobre el propio proceso. Lean asigna la responsabilidad de la mejora del proceso al equipo de trabajo (quien mejor conoce la forma de trabajar es quien hace el trabajo), justificando la dedicación de parte del tiempo productivo en la mejora del proceso. 

CUARTO PRINCIPIO: Aplazar las decisiones

Posponer las decisiones irreversibles hasta el último momento responsable, esto es, justo antes de que la decisión sea demasiado tarde.

También muy relacionado con el desarrollo de producto lo que facilita su aplicación al software. Si Toyota lo aplica al diseño de coches… en el software no debería ser más complejo. No implica no tomar decisiones, sino identificar aquellas que son irreversibles o costosamente reversibles y tomar la decisión la más tarde posible.

Por otra parte se potencia diseñar los sistemas lo suficientemente flexibles. Pero ojo, no todos las partes de nuestros sistemas necesitan el mismo grado de flexibilidad… no olvidemos que la flexibilidad no es gratis por lo que se debe aplicar este principio con sentido común y en muchos casos basándonos en la experiencia.

QUINTO PRINCIPIO: Entregar con rapidez

Los requisitos cambian, por lo que necesitamos desarrollar el software tan rápido como nos sea posible para que los usuarios/clientes no tengan tiempo a cambiarlos.

Bien, de acuerdo… aún así los requisitos cambian… pero si entregamos el producto lo antes posible y obtenemos una rápida realimentación (tercer principio) estaremos en una mejor situación para que los cambios se corrijan sobre el diseño actual en lugar de sobre el código escrito dentro de unos meses: eliminamos desperdicio (primer principio).

SEXTO PRINCIPIO: Respetar a las personas

En el aspecto de personal TPS se centra en los siguientes aspectos:

• Liderazgo emprendedor. Una organización que respeta a sus personas desarrolla buenos líderes y se asegura de que los equipos tienen el tipo de liderazgo que fomenta el compromiso motivando a su gente en crear productos de calidad. 
• Personal técnico experto. Una organización Lean debe desarrollar y nutrir experiencia técnica en el área/tecnología en que trabaja. Se me vienen a la cabeza diferentes empresas por lo bien o mal que aplican este principio con su personal...
• Responsabilidad en la planificación y el control. En lugar de decirle a la gente qué tiene que hacer y cómo ha de hacerlo se promueve la auto-organización que permita la consecución de unos razonables objetivos. Potenciar la flexibilidad necesaria para que la gente solucione por sí mismos los problemas…lo fácil es decirlo, verdad? A nosotros nos ha llevado 6 meses de esfuerzo apoyados en el uso de Kanban que personalmente creo que es un facilitador estupendo para este y otros principios Lean.

SÉPTIMO PRINCIPIO: Optimizar el conjunto

Cuando se piensa en la optimización desde una perspectiva Lean se piensa en la optimización del conjunto de la cadena de valor, traspasando la fronteras internas por las que dicha cadena atraviesa.

Probablemente este principio, junto con el anterior, sean los de más difícil aplicación sin el apoyo de la alta dirección. Hay que tener en cuenta que Lean sobrepasa los límites de un equipo de desarrollo por lo que determinados principios serán de difícil aplicación sin el adecuado compromiso de la jerarquía superior...

Y hasta aquí una primera explicación muy, muy resumida de los siete principios de Lean Software Development. No existe una guía de aplicación de los principios, pero en las referencias citadas abajo encontrarás una serie de prácticas y consejos que puedes utilizar para incorporarlos a tu propio proceso.

Reflexión

Personalmente creo que en momentos como el actual te puede llegar a interesar el pensamiento Lean porque, probablemente, tu organización, departamento IT o empresa esté sufriendo las restricciones de la severa crisis que atravesamos y todo lo anteriormente expuesto fue diseñado en una situación igualmente de enormes restricciones. Ten en cuenta que TPS se crea en Japón, en plana posguerra y en una empresa que no disponía de los recursos de las grandes compañías automovilísticas del momento (americanas).

Por otra parte, la demanda japonesa era significativamente menor a la que disfrutaban los colosos americanos, por lo que, la única forma de sobrevivir en esa situación era reinventar las reglas del juego y la forma de hacer las cosas. Aunque a Toyota le fue bien con la aplicación de estos principios no fue hasta la crisis del 74, debido a una importante contracción de la demanda mundial, que otras empresas (principalmente japonesas) empezaran a replicar el modelo, de nuevo bajo fuertes restricciones.

De ahí el título del post ¿Restricciones en la demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean. En mi caso este ha sido el motivo principal que me ha llevado a optimizar y mejorar la forma que tenemos de hacer las cosas, años atrás no existían estas restricciones sino que la situación era la contraria, recordemos que la demanda era tan grande que nuestro problema era encontrar profesionales en el mercado que nos permitieran seguir produciendo... Con la situación a la inversa (mantener la producción aun perdiendo personal) he acabado profundizando y guiando a mi equipo de desarrollo a través de Lean y Kanban (de nuestras experiencias con Kanban escribiré en breve).

Referencias

Mary y Tom Poppendieck, Lean Software Development - An Agile Toolkit, Addison Wesely, 2003.
Mary y Tom Poppendieck, Implementing Lean Software Development, Addison Wesely, 2006.

Cómo construir el producto que "realmente" esperan

El lunes de esta misma semana (11 de febrero) se juntaron en Londres, invitadas por Gojko Adzic (Impact Mapping), un grupo de personas que son ponentes y escritores habituales en temas relacionados con la concepción del producto. Esta idea se trata en diferentes técnicas como Impact Mapping, Lean Startup, Feature Injection, etc.

Yo di con ello porque actualmente, entre otras cuestiones, estoy adentrándome en temas de Lean y centrándome en uno de los principales problemas (desperdicios) que tenemos en nuestros proyectos: implementar funcionalidad que no interesan a nadie. Lean Sturtup se centra en estos asuntos pero no es fácilmente adoptable en todas las situaciones (no todos vivimos en un mundo con miles/millones de usuarios) de ahí que sigo buscando lo que más se adapte a la mía y, de momento, me detuve en Impact Mapping.

El enfoque Ágil se centra mucho en la entrega del producto, por lo que equipos ágiles perfectamente organizados y con alto rendimiento pueden estar cumpliendo a la perfección los objetivos de su sprint (si trabajan con Scrum, por ejemplo) pero estar desviándose totalmente del objetivo final: lo que realmente quieren los clientes/usuarios... iteración tras iteración entregan su versión incrementando funcionalidad y con la velocidad acordada...pero ¿realmente esto aporta valor? Si no es así, ni una ejecución de libro de un sprint te salvará de haber perdido las últimas 4 semanas...

En fin, volvamos al motivo principal de este post, lo interesante de este encuentro es el intento de todas estas personas por encontrar unos puntos comunes en las diferentes técnicas que las permitirá evolucionar de la mano. Hay quien lo empieza a comparar con el Manifiesto Ágil (imagino que por lo resumido y el número de puntos), otros dicen que sirve para explicar y acercar el Manifiesto a la gestión de las organizaciones,  todavía le están buscando nombre... Este es el resultado de tan "sesuda" reunión.

Great results happen when:

1. People know why they are doing their work
2. Organizations focus on outcomes and impacts rather than features
3. Teams decide what to do next based on immediate and direct feedback from the use of their work
4. Everyone cares

Creo que yo no aportaría mucho siguiendo hablando de ello, por lo que si te interesan estos temas puedes empezar por el blog de Gojko The February Revolution que explica los 4 puntos con suficiente detalle y si continúas interesado visita con frecuencia la comunidad de Google+ creada para compartir y evolucionar estas ideas: FebMeeting.

"Practicando" la Integración Continua (IC)

Después de invertir un tiempo considerable en su configuración disponemos de máquinas de Build que son capaces de compilar el código de nuestros proyectos, tenemos definiciones de compilación en diferentes formatos (integración continua, programadas, incrementales) y hemos adoptado la buena práctica de únicamente desplegar en producción las carpetas de despliegue generadas por estas máquinas.

Día 1: El mejor momento para el despliegue

Las puestas en producción suelen ser complicadas, incluso si hemos superado los innumerables problemas durante el desarrollo del producto, hemos corregido a tiempo los errores detectados en las pruebas y disponemos de una versión estable para el despliegue, en ocasiones nos encontramos superando la fecha de entrega en varias semanas por la necesidad de "afinar el sistema" al entorno de producción.

Puede parecer demasiado prematuro (e irreal) pero lo cierto es que no encontraremos en la vida de un proyecto mejor momento para su puesta en producción que su primer día de vida. Bien, tal vez tengamos que acotar lo que entendemos por "primer día" puesto que desde el momento de la concepción del sistema hasta que se escribe la primera línea de código pueden pasar varios días, tal vez semanas o incluso meses...

Durante las puestas en producción nos encontramos con una serie de problemas difíciles de predecir y reproducir, por lo que suele ser complicado aprender y replicarlo en el siguiente proyecto: debemos desplegar por sorpresa en servidores de 64 bits, la versión del Componente X de producción no coincide exactamente con la de Preproducción/Desarrollo, no alcanzamos desde los servidores de producción determinado Servicio Web, no está habilitada la IP de los nuevos servidores para el envío de correos, no se ejecutó el script con los permisos sobre determinados objetos de la base de datos... en resumen, la casuística tiende a infinito...

Cuanto más se retrasa la puesta en producción de nuestro sistema más funcionalidad incorpora, más lógica de negocio, mayor necesidad de configuración y de integración con otros sistemas... en definitiva, más riesgo a manejar. De ahí la afirmación que el primer día es el mejor momento para el despliegue.

Dependiendo del entorno, tecnología u organización el "primer día" puede traducirse como "la primera semana" o "el primer mes" pero lo cierto es que siempre habrá un único momento del proyecto en el que el despliegue es sencillo, pasado ese momento la complejidad va en aumento.

En nuestros proyectos intentamos evitar este problema cambiando el orden natural del despliegue, en lugar de desplegar al finalizar proyecto o en la primera iteración entregable, desplegamos un ¡Hola Mundo! tan pronto como nos es posible. Con esto no me refiero a las 3 líneas de código que escribimos al iniciarnos en un nuevo lenguaje de programación. En realidad nuestro ¡Hola Mundo! debe hacer algo más: 

• "Nos saluda" desde el Log. Lo cual no es decir poco; esto implica que hemos definido la estrategia de tratamiento de Logs, tenemos acceso de escritura donde quiera que se registre y el equipo de desarrollo dispone de accesos de lectura para verificar que el "recién nacido" respira.
• Establece conexión con los orígenes de datos que utilizará (SGBD, WebServices, ...) y nos informa positiva o negativamente a través del Log.
• Disponemos de, al menos, una prueba unitaria y una prueba de sistema. En realidad buscamos asegurarnos que existen los proyectos de pruebas asociados y se lanzan junto con la compilación. Las pruebas en este momento no nos preocupan demasiado, con un AssertTrue(true) tendremos el efecto deseado: 100% de las pruebas ejecutadas y funcionando.
• Nuestra máquina de Build dispone de una definición de compilación que obtiene nuestro (escaso) código, ejecuta las pruebas (obviamente pasan) y nos proporciona la carpeta de despliegue.

Durante nuestro "primer día de proyecto" hacemos las tareas que solíamos realizar en los últimos días: solicitar un código de identificación para nuestro sistema en producción, darlo de alta en la CMDB corporativa, escribir los manuales de instalación... La ventaja es que a partir de ese momento (la primera semana del proyecto) somos capaces de asegurar que nuestro sistema se ejecuta correctamente en el entorno de producción. Vale, al usuario le aporta poco o nada, de hecho se trata de una producción oculta...pero a nosotros nos aporta una información de gran valor.

Obviamente para desplegar un ¡Hola Mundo! no es necesario automatizar las pruebas ni utilizar máquinas de compilación remota. En nuestro caso lo hacemos así porque es la configuración por defecto de nuestros proyectos y garantiza que cualquier incremento de código no rompa la build ni deje test sin funcionar, obviamente se deben desarrollar más allá del AssertTrue(true). Lo que realmente nos interesa es verificar que el nuevo sistema "se levanta" correctamente en producción, conecta con los sistemas con los que se  deberá integrar y nos informa positivamente al respecto. No hacemos nada que no haríamos unos meses después (no desperdiciamos tiempo ni recursos) y anticipándonos convertimos en problemas reales los riesgos futuros y al despejarlos en un instante tan prematuro el tiempo corre a nuestro favor.

Día 2 del proyecto: el mejor momento para desplegar la versión 0.2 

Bueno, si lo dicho anteriormente puede llegar a encajar (al menos en un porcentaje aceptable de proyectos)  ¿Por qué no repetirlo al día siguiente? Y por "día siguiente" queremos decir tan pronto como sea posible... 

La idea es que si ya dispongo de una versión operativa en producción, no debo esperar hasta la entrega final para volver a realizar el despliegue. Si todos los días despliego mi nueva funcionalidad, todos los días validaré que el procedimiento de despliegue funciona y el "día D" pasará de ser "los 4 días D" a un despliegue rutinario... nosotros nos estamos aproximando a esta idea a partir del enfoque explicado por Jez Humble y David Farley en Continuous Devivery (CD).

Ahora bien, si para desplegar nuestro ¡Hola Mundo! no teníamos muchas restricciones, en esta nueva fase sí que necesitaremos un buen control de código fuente y una práctica "real" de integración continua. El enfoque que sigue CD es automatizar al máximo el proceso de despliegue (el objetivo final es que la única intervención humana sea pulsar el botón) por lo que igualmente necesitaremos  máquinas de compilación remotas.

El esfuerzo de implantar Continuous Delivery (CD) va mucho más allá que la buena práctica de desplegar y validar nuestro sistema tan pronto como sea posible explicada gráficamente con nuestro ¡Hola Mundo! El objetivo que perseguimos es que diariamente se valide nuestro proceso de puesta en producción, lo cual no implica que todo los días deba liberar una versión, sino que disponemos de un procedimiento que funciona y nos ofrece las garantías necesarias para poder asumir un despliegue inmediato si tuviera la necesidad de hacerlo de urgencia.

Esto son palabras mayores y el esfuerzo no es trivial, actualmente estimo que llevaremos andado una buena parte del camino...en próximos post iremos explicando en más detalle los entresijos de CD y cómo, poco a poco, lo vamos afrontando nosotros. 

TDD - Test Driven Development

TDD es una técnica propuesta en 2002 por Kent Beck (firmante del Manifiesto Ágil y autor de la metodología Extreme Programming) y altamente extendida desde entonces. Desarrollar atendiendo a esta técnica implica asumir que el código fuente incluye las pruebas unitarias, de tal forma que, no se puede considerar terminado un método/módulo si no existen las correspondientes pruebas que lo validan.

El algoritmo de esta técnica es bastante sencillo aunque el impacto en la forma de programar es muy alto por lo que para el programador es difícil interiorizar el proceso cuando se comienza a aplicar la técnica. El algoritmo consta de 3 partes:

1. Implementar la Prueba Unitaria que deberá cumplir el software que tenemos que construir. Si somos capaces de ejecutar la prueba (es muy posible que no llegue ni a compilar) la prueba no pasará.

2. Implementar el código mínimo necesario de negocio que hace que la prueba pase. Es importante destacar que el algoritmo propone que no busquemos el código óptimo en este momento (para eso está el último paso), únicamente nos interesa que la prueba pase (de ahí el nombre del método…el desarrollo lo dirigen las pruebas, nuestra meta principal es conseguir que las pruebas pasen, obviamente es crítico elegir bien el conjunto de pruebas necesarias para llegar a implementar el método/módulo/sistema que marcan las especificaciones).

3. Refactorizar el código escrito en el punto 2. La técnica de refactorización forma parte de la metodología Extreme Programming y se puede definir como alterar la estructura interna de un determinado código fuente sin alterar su comportamiento externo. Esta técnica obligatoriamente requiere para su aplicación de un robusto conjunto de pruebas automáticas que nos garantice que los pequeños cambios incorporados en el código no alteran su comportamiento. Las refactorizaciones se deben realizar siempre en pequeños y atómicos cambios.

La refactorización es un tema suficientemente extenso como para tratarlo por separado pero aplicado en un contexto de TDD nos deberemos centrar sobre todo en la robustez del código y en evitar el código duplicado generado en el paso 2. Cada pequeño cambio en el código implica que se vuelven a ejecutar las pruebas unitarias para verificar que no hemos “estropeado” nada con la refactorización.

Atendiendo a las interfaces gráficas de las herramientas de automatización de las pruebas unitarias se suele resumir el algoritmo de TDD con 3 palabras:

1. Rojo
2. Verde
3. Refactorizar

Rojo cuando se escribe la prueba se ejecuta por primera vez, obviamente no pasa y la interfaz la marca en rojo (en realidad lo que suele ocurrir es que rompemos la compilación...ni tan siquiera conseguimos el rojo). Verde cuando se escribe el código fuente que implementa el objeto de la prueba. Refactorizar…cuando mejoramos el código. Ojo, ese habitual olvidarse de este último paso, consiguiendo lo contrario de lo que pretende la técnica: un código de peor calidad.

Como se ha comentado anteriormente lo difícil de la prueba es ponerla en marcha, cambiar la forma de programar. M. Poppendieck asocia TDD al segundo principio de Lean Software Development: Build Quality-In, por su parte Henrik Kniberg comenta que sería lo último a lo que renunciaría en un equipo de desarrollo, M. Cohn le atribuye a una mejora significativa de la productividad de los equipos de desarrollo. Obviamente, las referencias (y sus promesas) son suficientemente solventes como para plantearnos el esfuerzo, pero hay que reconocer que nuestro primer acercamiento a TDD ha sido ciertamente "durillo". Probablemente por falta de experiencia en pruebas unitarias (+ mocks). Aunque no descartamos seguir profundizando e intentando su puesta en marcha, he de reconocer que la hemos postergado un poco en favor de otras prácticas más "ligeras" sobre las que podamos obtener un mayor ratio coste/beneficio.



Referencias utilizadas:
Diseño Ágil con TDD, Carlos Blé y colaboradores.