Antes de poder evaluar el impacto real que pueden tener la adopción de prácticas ágiles como testing, refactoring o clean code a nivel de la organización, es interesante considerar en qué punto estamos a nivel de producto y equipo. En muchas ocasiones, ignorar el contexto puede llevarnos al fracaso y a la pérdida de confianza en estas prácticas que tan beneficiosas son cuando se aplican de forma correcta.
Veamos pues cuando puede ser un buen momento para comenzar a hacer testing y qué condicionantes debemos tener en cuenta.
Estado del producto
Si nos centramos inicialmente en el producto, podemos identificar dos situaciones fundamentales: ¿Estamos descubriendo producto o, por el contrario, estamos en un proceso de delivery continuo de funcionalidad?
Si estamos descubriendo producto, el objetivo principal será el de validar una hipótesis de negocio que nos confirme si vamos por la vía correcta o no. Esta suele ser una situación en la que probablemente iniciaremos el proyecto desde cero (green field) y en la que se pueden llegar a dar, al menos, dos escenarios posibles:
- Construir un MVP lo más rápidamente posible para validar la idea de negocio y luego tirarlo a la basura para continuar con el desarrollo del producto real. De esta forma se desarrolla la mínima cantidad de software posible y el coste es menor, dejando temporalmente de lado principios de diseño y prácticas técnicas como testing, refactoring y demás. Es importante remarcar la parte de luego tirarlo a la basura, ya que negocio no tiene que poder pensar que es factible seguir construyendo sobre la base actual.
- Construir un producto nuevo, pero con una mentalidad más continuista, de forma que, aunque el avance sea más lento al principio, el producto sea ya el definitivo desde el minuto cero.
En el segundo escenario es también muy probable que tengamos que iterar repetidamente sobre el dominio, ya que las abstracciones que identifiquemos estarán todavía sujetas a cambios al no estar del todo bien definidas (identificación del lenguaje ubicuo). En este contexto es donde nos puede resultar de gran ayuda la dimensión del testing como herramienta de diseño, ya que los continuos cambios irán metiendo cada vez más presión al diseño y a la arquitectura y tendremos que ser capaces de refactorizarlos. En esta situación, sería interesante que el equipo ya pudiera tener cierta soltura con testing y refactoring para dar soporte a este proceso.
Iniciar un proyecto nuevo usando testing, refactoring y TDD es un gran propósito, pero si todavía no contamos con las habilidades necesarias, se puede acabar generando mucha frustración en el equipo.
Si por el contrario, el producto ya se encuentra en una fase más estable de definición en la que nos estamos centrando en conseguir un delivery rápido y sostenible, testing nos puede ayudar a ir ganando confianza en la calidad y mantenibilidad del producto, de forma que el código pueda llegar a producción en las mejores condiciones posibles.
Estado del equipo
En otro orden de cosas, el estado actual del equipo puede ser todavía más relevante, ya que asimilar ciertas prácticas puede requerir de un mindset y unos conocimientos mínimos previos a la hora de entender su objetivo principal o sus valores.
En este sentido, hay que tener cuidado en entornos con equipos en pleno crecimiento, ya que los consensos alcanzados por el equipo pueden estar todavía formándose. Así pues, lo ideal sería contar con un background mínimo de refactoring y clean code antes de comenzar con testing, especialmente si estamos en un entorno con mucho legacy en el que a medida que creamos estructuras para sustentar el cambio mediante tests, vamos refactorizando el código que nos encontramos.
Por último y como sucede con muchos de los valores que introduce la cultura DevOps a distintos niveles de la organización, el estado de madurez de la automatización de los procesos involucrados, es decir, pipeline de construcción y CI/CD (continuous integration + continuous delivery), va a ayudar mucho a que la integración de nuestros tests en el proceso completo de entrega de valor. Si estos procesos o pipelines no existen, será necesario ir creándolos con el fin de que el equipo en general se pueda beneficiar de la simplicidad e integración que ofrecen (evitando que cada uno haga la guerra por su parte).
El concepto de Walking Skeleton del Growing Object-Oriented Software, Guided by Tests nos ofrece una oportunidad de preparar el pipeline de construcción, testing y despliegue con la primera historia de usuario de la aplicación.
Para profundizar en cómo algunos de estos matices que afectan a los equipos o al producto pueden afectar también al proceso de implantación de prácticas técnicas como testing, os recomiendo profundizar con dos grandes libros como son Team topologies y Accelerate: Building and Scaling High-Performing Technology Organizations, los cuales nos ayudarán a comprender mejor cómo organizar nuestro equipos y nuestros flujos de trabajo.
