La estrategia ágil aplicada al desarrollo del software: cómo hacer crecer tu software

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

Primero la teoría, ahora la práctica. Vamos a aprender cómo implementar el enfoque de "crecimiento" en el desarrollo del software.

En mi artículo anterior, expliqué la idea de hacer crecer el software en comparación con la de construirlo. Al adoptar un enfoque orientado al crecimiento, puedes sacar partido a la naturaleza del software: versatilidad, flexibilidad y facilidad de actualización frente a una estrategia de desarrollo más rígida. Hoy, vamos a examinar la implementación práctica de esta estrategia de "crecimiento".

Hacer crecer el software: ¿por dónde empezar?

Paso 1: el caso de uso

Al comienzo de cada proyecto nuevo, lo primero en lo que debes centrarte es en disponer de un caso de uso que funcione de forma integral. Para que sea más efectivo, debe incluir las siguientes características: ser vertical, típico y básico.

Debe ser vertical para que implique y afecte a todos los niveles de software y, por lo tanto, se requiera un poco de cada uno. Por ejemplo, una aplicación web debe incluir tanto el front-end (niveles de datos y presentación) como el back-end (niveles de base de datos y procesamiento de datos).

Debe ser típico en el sentido de que, al completarlo, se haga frente a los principales retos y a los más frecuentes. Por ejemplo, si el software dispone de una base de datos, querrás comprobarla para asegurarte de que los riesgos se encuentran bajo control.

Por último, debe ser lo más básico posible e incluir el menor número de variables. El objetivo es completar el caso de uso con rapidez para poder obtener comentarios en muy poco tiempo.

A primera vista, el caso de uso solo es el origen de una funcionalidad que proporciona un nivel reducido de valor.

Y sin embargo:

  • Aporta algo de valor, aunque sea muy poco.
  • Es demostrable, lo que quiere decir que el valor resulta claro para los usuarios. Además, podrás obtener comentarios sobre su funcionalidad.
  • Facilita el diseño del software al tener en cuenta los aspectos más importantes y garantizar la gestión de los riesgos, lo que contribuye a que el resto del proceso de desarrollo se lleve a cabo con menos complicaciones.
  • Este valor se aprecia con rapidez, lo que compensa en gran medida el poco valor aportado.

Paso 2: hacer crecer el software

Una vez que dispongas de este pequeño elemento funcional, puedes pasar a la fase de crecimiento, tal y como comentamos en el artículo anterior. Esto implica que debes:

  • Añadir únicamente pequeños cambios que siempre aporten valor.
  • Asegurarte de que los cambios y el valor que aportan siempre pueden demostrarse.
  • Integrar siempre estas modificaciones en el resto del software.
  • Llevar a cabo estos cambios en diferentes partes del software sin que se vea afectada la integridad de la versión.

En cualquier momento, podemos cometer un error y volver con rapidez al estado anterior. Algo así resulta sencillo, ya que los pasos que se dan son pequeños y, si hay que desechar el código, esto no supone un problema, ya que la cantidad de trabajo que se pierde es pequeña.

Esto es posible porque trabajamos con una mentalidad de "crecimiento".

Gestión de producto: trabajo paso a paso

Al hacer crecer el software, es muy importante que el incremento de trabajo que se lleva a cabo sea reducido. Para ello, te recomendamos que tengas en cuenta las siguientes directrices:

Proporciona información clara sobre las restricciones a la hora de distribuir las tareas pendientes

  • El software debe estar activo en todo momento, ofrecer la capacidad de demostrar sus funcionalidades y encontrarse completamente integrado.
  • Todos los elementos de la lista de tareas pendientes deben aportar valor.
  • Para obtener información y comentarios lo antes posible, es necesario dividir los elementos de esta lista.

Adopta la mentalidad adecuada

  • La primera fase del trabajo debe ofrecernos la posibilidad de obtener una versión activa, así como garantizar que la arquitectura de software se adapta al proyecto.
  • Al elaborar software funcional, proporciona una versión mínima.
  • Asegúrate de estar listo para descartar cualquier fragmento de código que impida que el software "crezca" con facilidad.

Sigue los principios de la gestión de productos

  • Diseña características reducidas, pruébalas y, a continuación, optimízalas. La idea es seguir la metodología Lean Startup que describimos en un artículo anterior.
  • Trabaja de forma incremental e itera tan rápido como sea posible.
  • Asegúrate de que los riesgos se tienen en cuenta, con el fin de que no se vea afectada la velocidad de desarrollo del producto.
  • No pierdas tiempo en tareas que no aportan valor.

Los riesgos de ignorar la mentalidad de crecimiento

Si sigues trabajando con una mentalidad orientada a la construcción de software, limitarás el progreso que puedes conseguir al implementar unas prácticas ágiles. Además, creerás que has adoptado una metodología de este tipo, pero, en realidad, tus operaciones de producto seguirán siendo las mismas. Estas son las consecuencias a las que podrías tener que enfrentarte:

  • Tu capacidad para llevar el producto al entorno de producción es limitada. Planificas de forma explícita los periodos de lanzamiento para el trabajo de producción en lugar de disponer de código que puede entregarse en cualquier momento. El resultado inmediato es que cada lanzamiento viene acompañado de una serie de sorpresas inesperadas y desagradables.
  • El producto no se ha diseñado para que pueda modificarse. Cuanto más crece el código base, más difícil resulta modificarlo. El equipo es cada vez menos predecible y las estimaciones sobre tiempos de producción se disparan. Como consecuencia, los desarrolladores se quejan cada vez que reciben una nueva solicitud.
  • El sistema se rebela. Debido a la falta de flexibilidad, la estructura se rebela contra la empresa y sus usuarios con el fin de limitar la evolución (y el esfuerzo necesario) tanto como sea posible. Por ejemplo, la definición de "listo" pasa a ser cada vez más estricta y basada en procedimientos. El equipo comienza a sufrir el "síndrome del lavadero", que hace referencia a las solicitudes no planificadas que retrasan el lanzamiento, pero que resultan esenciales para el usuario final.
  • Trabajo vs. estrategia. Tu equipo va a instalarse en la mentalidad de completar trabajo, en lugar de pensar sobre el verdadero significado del producto y el servicio que debe proporcionar.

Si pensamos sobre ello, el resultado de adoptar una metodología ágil al mismo tiempo que se mantiene una mentalidad orientada a las versiones es seguir trabajando de la misma forma, lo que se va a traducir en una "falsa metodología ágil". En una situación así, es imposible realizar avances reales y tangibles.

Una analogía vital

Para finalizar, queremos plantear una analogía entre el desarrollo del software y la forma en la que crecen los elementos de la naturaleza. El entorno natural es tan complejo que la única forma de comprender su complejidad es mediante el análisis de los principios fundamentales que han permitido el desarrollo de la vida. A la hora de analizar la complejidad de los proyectos de desarrollo de software, la estrategia debería ser exactamente la misma.

Applause Circle Logo