Adelantamos la detección de errores funcionales en el proceso de desarrollo de software

En ASPgems damos la vuelta al tradicional modelo en cascada para dar paso a marcos de trabajo ágiles

El proceso de desarrollo de software tiene varias fases. Antiguamente se cogía un proyecto entero y, tras varios meses haciendo especificaciones para saber qué queríamos hacer, se separaba en diferentes fases (diseño, test técnico,…). Estamos hablando del clásico waterfall, modelo en cascada, que desde nuestra experiencia falla porque está basado en una premisa errónea: que sabemos lo que tenemos que construir. Y esto no es así. Ya que cuando se comienza a desarrollar un producto tenemos una idea aproximada de lo que queremos y del camino a seguir, no una certeza.

Sustituimos el modelo en cascada por ciclos iterativos de corta duración

Para nosotros la clave es operar con marcos de trabajo agile que tienen como resultado una reducción en los tiempo, acortando cada una de las fases que duraban de media varios meses. Así, se trata de realizar varios ciclos iterativos de corta duración (no más de cuatro semanas según scrum, por ejemplo) con la consiguiente optimización de tiempo.

Validación funcional

Dentro de este marco se suelen dar dos tipos de validaciones: la técnica y la funcional. Generalmente la validación técnica se realiza justo antes de integrar trabajo en la rama principal del proyecto, mientras que la validación funcional suele hacerse después de que dicha integración se haya llevado a cabo.

Por ejemplo, en el momento en que un desarrollador quiere integrar su trabajo con la rama principal del proyecto, pide una revisión técnica al resto del equipo técnico por medio de un Pull/Merge Request. Una vez validados los aspectos técnicos e integrado el código en la rama principal, ésta se despliega en staging, donde se realizará la validación funcional por parte de quien corresponda.

En este punto nos encontramos con uno de los problemas. Generalmente varios desarrolladores se encuentran trabajando simultáneamente en diferentes funcionalidades que, posteriormente, el encargado de la validación funcional tendrá que revisar. Pero, puesto que todas las funcionalidades están integradas en la rama principal del proyecto, en el caso de que una de ellas no pase la validación funcional, se retrasa la subida a producción de todas las demás, retrasando la duración total del proyecto.

Para decirlo de un modo sencillo, si estuviéramos hablando de Lean esas funcionalidades que no podemos lanzar pese a estar aprobadas se corresponden con stock innecesario al que no le damos salida. ¿Eficiente? En absoluto.

Adelantamos el proceso de validación funcional

Lo que proponemos es, en vez de validar todas las funcionalidades en bloque, adelantar este proceso e ir validándolas de una en una a medida que las vayamos teniendo para, de este modo, no retrasar su subida a producción. Trabajamos en un nuevo entorno: App Review

De este modo, evitamos los bloqueos y pérdidas de tiempo al realizar de manera individual las validaciones. Estas iteraciones se realizan en otro entorno previo a staging diferente, App Review, en el que adelantamos la detección de errores.

Hasta hace un tiempo, el coste operativo de habilitar nuevos entornos era bastante elevado, pero ahora no es así: la tecnología para desarrollarlos está disponible y al alcance de nuestra mano por lo que el coste es marginal. En el caso de las app reviews, se levanta un entorno nuevo por cada una de las funcionalidades en desarrollo.

El Product Owner tiene el control del delivery

Además de adelantar la detección de errores funcionales, mediante servicios de integración continua podemos poner un control de forma que una vez que el Product Owner haga su validación, integre directamente la funcionalidad en la rama principal del proyecto provocando un despliegue automático en staging y, en caso de creerlo conveniente, el posterior despliegue a producción.

De este modo, él puede tomar el control de cuándo desplegar sin la necesidad de una tercera persona, volviendo a ahorrar tiempo.