TDD: Desarrollar a partir de pruebas

El desarrollo conducido por las pruebas o TDD (por sus siglas en inglés para Test Driven Development) por más que su nombre lo sugiera no es una técnica de testing. 

Es una técnica de diseño y desarrollo de software que propone un cambio de paradigma poniendo a las pruebas como pivote principal del proceso de desarrollo de software.

La idea es utilizar la capacidad de automatización de las pruebas (para esto existen varios frameworks que puedes aplicar) con varios objetivos como pueden ser:

• Comunicación: plasmar el entendimiento del problema en un lenguaje sin ambigüedad como es el código para diseñar los escenarios que sirvan como especificación de requisitos.
• Evidencia: generar una base de evidencia automática que nos permita mostrar como debe funcionar cada escenario previsto.
• Codificación: facilita generar el código estrictamente necesario para cumplir con la funcionalidad esperada. Eso sí, tiene la desventaja de que si el diseño de los casos no son completos puedes perder funcionalidad.
• Confianza: para encarar las mejoras la base de evidencia automatizada te dará la confianza que necesitas para realizar los cambios y mantener la seguridad de que todo continua funcionando.

Como todas estas técnicas, TDD tiene un ritmo. Depende del autor que leas habrá variación a continuación te dejo mi visión sobre los pasos que debes seguir para ejecutarla:

1. 1. Escribir una prueba que no pase: especificar el escenario a desarrollar.
2. 2. Escribir el código necesario para pasar la prueba.
3. 3. Verificar que se cumplen las condiciones del escenario especificado
4. 4. Refactorear: mejorar el comportamiento interno sin afectar el comportamiento observable.
5. 5. Volver al paso 1 y repetir hasta agotar la funcionalidad.

La agilidad no esta en el relajo, sino en la rapidez brindada por el ritmo de la metodología. Por lo tanto te sugiero que antes de empezar tengas un backlog priorizado que te permita decidir por donde empezar. Segundo que elijas cada funcionalidad y ejecutes el proceso hasta agotarla, y recién allí continúes con la siguiente. Aprovecha la etapa de refactorización para mejorar aspectos relacionados a la implementación o al diseño que puedan traerte problemas más adelante (ver post sobre deuda técnica) y así tender a un diseño simple.

No es una técnica infalible, porque como bien sabes no existe una solución 100% eficaz para todos los contextos pero es la base de varias de las metodologías ágiles y se continúa adoptando con muy buenos resultados.

Diagramas de secuencia y de colaboración

Estoy escribiendo sobre estos diagramas a pesar que son un tema bastante transitado dado que últimamente he recibido varias consultas sobre estos; y he observado que conceptualmente no se llegan a comprender para que sirven y eso lleva a que no se puedan aplicar correctamente.

Primero que nada hay que entender que son una forma más de comunicación en el marco de la definición de la arquitectura del proyecto y por lo tanto puede aplicar o no dependiendo del objetivo y las características del proyecto. En segundo lugar debemos tener en cuenta que son diagramas complementarios es decir no son excluyentes entre sí, de hecho tienen el mismo poder de expresión en cuanto a la comunicación de una idea.

Se dice que son diagramas dinámicos puesto que complementan a los diagramas de clases, componentes y paquetes en términos de ejecución de las instancias de las abstracciones diseñadas. El valor que agregan estos diagramas esta en que el arquitecto puede transmitir su idea de como deben implementarse los algoritmos que utilizan las transacciones.

A la pregunta, sobre si debo hacer un diagrama para cada proceso; mi respuesta es no necesariamente. La idea es que puedas tomar una muestra representativa de los procesos a desarrollar y a través de estos diagramas contarle a tus programadores cual es tu idea sobre el estilo y el uso de las abstracciones para que con ello se puedan guiar el desarrollo del resto de los procesos que no se han desarrollado. Como se trata de una herramienta de comunicación debes considerar el nivel de detalle necesario para contemplar todos los casos, recuerda que aquello que no pongas nadie lo podrá deducir.

El nivel de detalle que deben llevar dependerá no solo de la complejidad de los procesos sino también del tipo de recursos con los que cuentes; no es lo mismo diseñar para un rookie que para un experto.

En ambos tipos de diagramas lo que estamos mostrando son instancias de abstracciones, los mensajes que se envían entre sí y el orden en que lo hacen por eso se dice que tienen la misma capacidad de abstracción. Sin embargo los diagramas de interacción suelen ser mejores para procesos sincrónicos mientras que los de colaboración suelen serlo para procesos asincrónicos.

No hay una forma única de hacerlos, la efectividad que tengan dependerá del contexto. Tampoco son ya la herramienta de comunicación por excelencia pero suelen utilizarse aun en proyectos de gran porte.

Hay mucho para hablar sobre este tema, puesto que es muy amplio y no quiero hacer de este post algo exagerado, mi recomendación para encararlo es que habiendo analizado mis observaciones anteriores te los tomes como si estuvieras programando en "papel" y tus lineas de código en realidad fueran figuras. Esto no solo te ayudará a concentrarte en el diseño al máximo sino que te guiará en el nivel de detalle necesario. Y claro siempre puedes obtener feedback de tus diseños y así ir mejorando hasta encontrar tu estilo.

El origen: PDCA

También conocido como ciclo de Deming por su autor Edward Deming, el PDCA ( por sus siglas en inglés para plan-do-check-act) es un ciclo de mejora continua que consta de cuatro pasos construido sobre la idea orignal de Walter Shewhart.

El ciclo de dinámica iterativa y continua es utilizado por las organizaciones con objetivos variados tales como: mejora de productos/servicios, optimización de costos, gestión de la calidad, innovación, creatividad (revisate mi post sobre design thinking) entre otros. Por lo general si analizas en profundidad los procesos estándar encontrarás varias similitudes que te indicaran que se han inspirados por el PDCA principalmente por esto es que lo considero como el origen.

El PDCA consta como te comentaba antes de cuatro etapas:

Plan (planificar): con la planificación se estudian las oportunidades de mejora y se organizan las acciones que se van a realizar para su implementación fijándose los objetivos de mejora.

Do (ejecutar): Se ejecuta el plan estrategico diseñado con la planificación; es en definitiva la intervención que hacemos para implementar la mejora.

Check (verificar/validar): Se trata del periodo de prueba una vez ejecutada la mejora, con el cual tomamos medidas para conocer como se comportan las intervenciones que hemos realizado durante la ejecución.

Act (corregir): Analizamos los datos obtenidos con las mediciones realizadas durante la fase de verificación buscando conocer si las intervenciones han dado los resultados esperados. Si los han dado entonces la intervención se plasma en el estándar y de lo contrario podremos actuar para corregirlo. Tras ello volvemos a la fase Plan para continuar con el proceso de forma cíclica hasta terminar es decir alcanzar los objetivos planteados.

Vinculado originalmente a la mejora continua de procesos, como te comentaba hay varias formas de implementar el proceso PDCA. Es un tema que esta muy procesado por lo que puedes encontrar diferentes y muy buenas fuentes para continuar profundizando el tema o en su defecto puedes hacerme llegar tus dudas y las contestaré. 

DEUDA TÉCNICA ¿De qué trata el concepto? ¿Cuál es su origen?

Imagina que tienes una funcionalidad que necesitas agregar a uno de tus sistemas. Para ello hay inicialmente dos formas de hacerlo, una es rápida de implementar pero algo confusa (es decir, es seguro que esta opción te dará mucho trabajo mejorarlo en un futuro). La otra es hacerlo a partir de un diseño “limpio”, pero esta opción llevará más tiempo y esfuerzo de implementar.

Deuda técnica es una excelente metáfora ideada por Ward Cunningham para ayudarnos a pensar en este problema.

 “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.”

En esta metáfora, hacerlo de la forma rápida y confusa nos generaría una deuda técnica, con una mecánica similar a la deuda financiera. Al igual que una deuda financiera, la deuda técnica involucra el pago de intereses, que se configuran en forma de esfuerzo extra que tendríamos que realizar en un futuro a causa de haber elegido la opción de un diseño rápido y confuso. Y un principal que representa por el costo de eliminar la deuda técnica de forma definitiva.

Por lo tanto, podríamos optar por continuar pagando intereses u optar por pagar el principal a través de la aplicación de técnicas que nos lleven de un diseño rápido y confuso a uno mejor. A pesar del costo que nos trae el pago del principal, ganaremos a futuro al reducir el pago de intereses.

La idea no es eliminar toda la deuda técnica, sino concentrarse en aquellos casos donde el monto de interés que evitaríamos con la solución justifica el costo que tiene el pago del principal. De acuerdo con esto hay casos donde optar por un enfoque rápido y confuso puede ser razonable. Por ejemplo, al igual que una empresa incurre en deudas para tomar ventaja en una oportunidad de mercado los desarrolladores podrían considerar incurrir en una deuda técnica para alcanzar un hito importante para los objetivos del proyecto.

La metáfora se vuelve interesante porque generalmente las organizaciones productoras de software dejan que sus deudas técnicas se salgan de control y esto hace que pasen la mayor parte del esfuerzo futuro del desarrollo pagando intereses paralizantes. El tema es también que a diferencia de la deuda financiera, la deuda técnica no cuenta con una moneda que nos permita medirla de forma efectiva. Los pagos de interés por ejemplo deberían medirse en términos de la productividad del equipo, pero como medir la productividad es un tema complejo y pese a nuestros esfuerzos tal vez no consigamos medirla con exactitud, no podremos evaluar el efecto real de nuestra deuda técnica.

En resumen esta metáfora si bien es un concepto que no es nuevo, ejemplifica un problema que continua siendo interesante para los investigadores actuales. Distintos autores han tomado esta metáfora y la han extendido a diferentes áreas de la ingeniería de software particularmente a la vertical de calidad imagino que se debe a que es el área más difícil de evaluar cuantitativamente.

Sobre la construcción del software

Uno de los aspectos tal vez más importante al encarar un proyecto de software es definir como lo vamos a construir; aunque no lo parezca es un aspecto que esta muy influenciado por la naturaleza del proyecto y también por el tipo de organización que somos.

Considerando lo anterior, las opciones más elementales que tenemos para encarar el proyecto de software desde el punto de vista de la construcción (también conocidos como ciclos de vida) son las siguientes:

• Cascada: Hay distintas visiones en cuanto a las etapas que se cubren con este ciclo pero la característica que lo distingue es que ninguna etapa comienza hasta que no termine la anterior.
• Espiral: Es como una mezcla entre el ciclo en cascada y el desarrollo rápido de aplicaciones con la característica que lo distingue es el foco en la gestión del riesgo 
• Iterativo/Incremental: Este ciclo de vida propone ejecutar el proceso en varios ciclos repetitivos (con todas las etapas) como si fueran mini-cascadas que con cada nueva iteración la característica es que el producto ira creciendo en capacidad y alcance.
• Ágil: Se basan en las características de los procesos iterativos/incrementales para dar más agilidad al proceso, mas concentrados en las personas y el feedback temprano que en los procesos y la planificación.

Por supuesto que los anteriores no son las únicas opciones pero si las básicas, aquellas que reúnen las principales diferencias sobre las que se construyen el resto de las estrategias. Claro es que tu mismo puedes especificar tu propio proceso de desarrollo o ciclo de vida solo tienes que considerar que estos ciclos deben:

• Definir todas las etapas/actividades que se deben ejecutar
• Facilitar el seguimiento y la gestión de todo el ciclo
• Permite un marco de trabajo sobre el cual ejecutar el proceso

No hay una solución ideal para todos los proyectos, antes de empezar debes analizar el tipo de recursos que dispones, la cultura de la organización, el tipo de proyecto, características de los requisitos, limitaciones de tiempo, presupuesto y el tipo de alcance con todo ello sobre la mesa elegir el ciclo de vida que más se ajuste. De todas formas esto no te asegurará el éxito pero marcará el camino hacia él.

Mobile - ¿aplicaciones responsive o nativas?

¿Adaptación o Nativo? esta es una de las preguntas más repetidas de la nueva generación de aplicaciones software para dispositivos inteligentes. Cuando alguien que desarrolla software se hace esta pregunta es porque esta pensando en brindar su servicio a través de diferentes dispositivos que:

• Operan en diferentes plataformas
• Son de diferentes fabricantes
• Tienen diversas resoluciones

Lo cual seguramente tiene como objetivo llegar al público masivo, dado que las estadísticas muestran que hoy se tiene mayor interacción con dispositivos móviles que con ordenadores en el sentido tradicional. Por lo que en este contexto la pregunta inevitable es:

¿me conviene una web adaptativa (responsive) o software nativo para los dispositivos?

Hace unos años esta no era una pregunta sencilla puesto que no había ningún producto que se pueda utilizar para tener una única linea de producción que pueda compilarse en diferentes plataformas. Esto ya no es un problema puesto que existen varias plataformas que lo permiten, aunque esta claro que estas plataformas nunca serán tan efectivas y eficientes como construir directamente en el código nativo pero suelen ser una excelente opción. Mientras que la ventaja de la web era justamente una única linea de producción de software que pudiera adaptarse en el navegador a los diferentes dispositivos y ni siquiera debía ser compilada para cada plataforma. Pero claro el concepto de responsive era nuevo y se entendía como hacer que la web se viera bien en un espacio reducido lo cual no lograba el impacto visual y de usabilidad que sí podías lograr con una aplicación nativa.

Hoy el concepto de adaptación responsive, se entiende de otra forma y a través de herramientas como CSS 3 y HTML 5 puedes lograr que tu web se adapte a las diferentes resoluciones pero mutando en el proceso de forma tal que puedas aprovechar mejor la experiencia logrando no solo aplicaciones de alto impacto visual sino también de usabilidad. Con esto se disminuye tanto la brecha entre aplicaciones nativas y web que la pregunta inicial se reduce al siguiente análisis:

¿Quiero aprovechar la información del usuario en dispositivo? ¿quiero usar los dispositivos periféricos tale como: GPS, cámara, efectos especiales, alarmas, notificaciones, billetera electrónica, market place, etc.? si tu respuesta es SI entonces debes ir por las aplicaciones nativas, en cualquier otro caso la mejor alternativa puede ser la aplicación web responsiva dado que el hecho de no aprovechar las ventajas propias del dispositivo en tu aplicación no justificar la inversión y el impacto que consigas puede ser equivalente. La cuestión de la inversión no es menor porque si buscas que tu aplicación nativa sea óptima deberás contar con una linea de producción independiente para cada dispositivo, porque la opción de una herramienta (como Titanium) que compile una única linea de producción en cada plataforma será útil pero nunca igual de efectiva que una aplicación nativa.

En definitiva como todo en el software no hay una opción idónea para todos los casos sino que siempre dependerá de tus objetivos y del contexto en el que te encuentres.

Que es lo que vendemos?

Durante muchos años hemos creído que lo que estamos vendiendo es nuestro producto o servicio, pero hoy sabemos que vendemos una experiencia. Nos hemos movido del producto-centrismo cultura en la cual el centro de todo es el producto o servicio que tenemos para ofrecer hacia algo más sensorial buscando capturar a nuestro cliente a través de la experiencia de consumir lo que tenemos para ofrecer.

Con esta nueva cultura del look & feel, el producto o servicio es el centro de un conjunto de ondas que buscan cautivar al cliente a través de sus diferentes sentidos. Para ejemplificarlo, imagínate una tienda de ropa que busca cambiar la experiencia de sus clientes para mejorar sus ventas entonces como dije debe enfocarse en todos los sentidos de su público por lo tanto cuando:

• Pone música de ambiente le transmite al cliente el look de las prendas que tiene para ofrecer.
• Aromatiza el ambiente para amenizar acorde al tipo de prendas que ofrece
• Te permite tocar las prendas con lo que te llega a través del tacto
• Tiene una ambientación acorde al estilo de vida que te propone entonces te entra por la vista
• A través de los sonidos y los aromas te puede influenciar el sabor propio de su estilo.

Con esto te demuestra que no solo esta vendiéndote una prenda de ropa, sino un estilo de vida y te lo ha transmitido (sin hablarte) a través de todos tus sentidos. Lo has sentido, verdad?

La cultura del servicio implica que ya no es el cliente quien te hace un favor al comprar tu producto, sino que eres tu el que haces ese favor brindándole una experiencia cautivante que por ejemplo lo oriente hacia quien es y cual debe ser su estilo de vida.

Con los productos software el paralelismo es inevitable, pero con ciertas diferencias propias del mercado. La experiencia sigue siendo el objetivo y la conseguirás a través de estimular la intuición de tu público, lo que implica de alguna forma estimular sus sentidos a lo mejor no tan explicitamente como en el ejemplo de la tienda pero puedes llegar desde el pragmatismo, la sencillez de lo visual y su usabilidad lo cual brindará al usuario un entorno ameno, agradable y fácil de usar. Si además lo que ofreces resuelve el problema que tiene será un éxito.