La estrategia ágil aplicada al desarrollo del software

Jean-Pierre Lambert Jean-Pierre Lambert
tiempo de lectura minutos
Applause Blog Logo

El desarrollo de software suele compararse con la construcción de una casa. Sin embargo, es un concepto con el que no estoy de acuerdo. Creo que una comparación más realista sería conseguir que una planta crezca de forma saludable y me gustaría explicar el motivo.

La expresión "construir software" se suele utilizar en relación con herramientas como compiladores o cadenas de suministro continuo. El principio en el que se basan estas utilidades es la capacidad de reproducción. Si ninguno de los factores se modifica, el resultado generado debe ser el mismo. En este esquema, de lo que hablamos es de una fábrica de software. Sin embargo, el proceso de desarrollo tiene más que ver con las herramientas utilizadas que con el propio trabajo. El proceso de desarrollo también puede denominarse "trabajo de arquitectura" o "diseño de software". En este caso, el proceso comparte más características con la idea de hacer crecer una planta que con la de construir una casa.

"Construir" es un concepto que encaja muy bien con el modelo de desarrollo en cascada:

  • El resultado final y la forma de construir se definen desde el principio.
  • Cada paso y componente se completan en orden y la integración se deja para el final.

Este esquema funciona porque el ámbito es conocido y puede reproducirse con facilidad.

Frente a esta visión, el software suele requerir métodos de desarrollo ágiles o, como mínimo, de carácter incremental o iterativo. En este enfoque, encaja mucho mejor el concepto "crecer", ya que aquí no hay un producto final predeterminado y puedes ajustar el software a medida que lo desarrollas.

  • El producto funcional existe en el momento en el que se inicia el bucle de retroalimentación.
  • Esta estrategia funciona porque el resultado final se mejora y optimiza sobre la marcha.

Construir vs. crecer: una cuestión de mentalidad

En el día a día, debatimos sobre la cuestión de la perspectiva. En este caso, las diferencias entre el punto de vista de la construcción y del crecimiento son considerables. La discrepancia principal se refleja en varios puestos.

1. El desarrollador

En lugar de diseñar una arquitectura con el fin de satisfacer la necesidad predeterminada para un proyecto, el desarrollar fomenta una estructura que puede evolucionar a lo largo del tiempo y adaptarse a los cambios en la medida en la que sean necesarios.

Por este motivo, el desarrollador promueve principios como YAGNI (siglas en inglés de You Aren't Gonna Need It, "no vas a necesitarlo"), que consiste en programar el mínimo imprescindible para la necesidad tal y como se ha definido en la actualidad. También contamos con el diseño emergente, en el que la arquitectura se concibe a lo largo del tiempo y a medida que se desarrollan las soluciones en lugar de anticipar el posible diseño de la estructura.

En resumen, la capacidad de ajustar el código sobre la marcha es la principal prioridad. Es inútil incluir puntos de ampliación repartidos por todo el código cuando podemos sustituir cada fragmento individual para satisfacer necesidades futuras.

Por lo tanto, se pueden tener en cuenta cambios radicales y frecuentes en la orientación del producto sin que esto suponga una pesadilla para el desarrollador. Todas las acciones se orientan a que el equipo pueda seguir la evolución de la necesidad.

En un enfoque de "crecimiento", el desarrollador fomenta una arquitectura que puede evolucionar a lo largo del tiempo y adaptarse a los cambios a medida que son necesarios.

2. El propietario/gestor del producto

En la misma línea, el propietario del producto (o gestor del producto, en función de la organización) adapta la forma en la que trabaja. En lugar de imaginar una solución hipotética ideal desde el principio del proyecto, se parte de una versión mínimamente viable del producto que demuestre la necesidad. A continuación, se itera a partir de los comentarios recibidos por parte de los usuarios. A diario, el propietario/gestor del producto diseña las características mínimas posibles y las prueba antes de desarrollarlas. Es decir, de "hacerlas crecer".

El principio clave es "no sabes nada", porque la verdad está en las manos de los usuarios. El equipo debe llegar a estos lo antes posible (al igual que una semilla a la luz del sol), con el fin de obtener comentarios con rapidez que permitan que el software se fortalezca y crezca. Sin los testimonios de los usuarios, trabajaríamos en un vacío en el que usaríamos una energía limitada para avanzar en una dirección que podría resultar inútil.

El fomento de la adaptación frente a las directrices claras

Por último, hacer crecer el software implica adaptar el proceso de desarrollo a su propia naturaleza: versatilidad, flexibilidad y facilidad de actualización. Esta mentalidad resulta esencial y puede encontrarse en cada puesto. En lugar de definir todos los parámetros desde el principio, fomentamos la evolución.

¿Cómo podemos poner esto en práctica? Echa un vistazo a mi segundo artículo, en el que me centro en la aplicación concreta en proyectos y productos.

Applause Circle Logo