archivo

Archivo de la etiqueta: entorno de desarrollo

El hecho de RUP siga un ciclo de vida que se puede considerar iterativo e incremental no implica que se le pueda considerar una metodología ágil y eso que sobre el papel podría considerarse que verifica los principios del manifiesto ágil.

Por ese motivo quien considere que RUP es ágil tienen una buena coartada. Se esté o no de acuerdo con que se considere una metodología ágil, lo que no deja dudas es que se trata de una metodología de carácter adaptativo, fruto de su vocación iterativa, incremental y unificada.

¿Por qué no lo considero una metodología ágil? Principalmente porque el marco de trabajo que define, implica liberaciones muy tardías en entornos de producción. Es cierto que en la etapa de construcción en cada iteración se pueden liberar versiones en entornos de desarrollo (o incluso preproducción) y que en las etapas finales de la construcción se pueden incluso hacer implantaciones en producción (si bien esta es la responsabilidad principal de la siguiente, la de transición).

Es decir, los usuarios seleccionados para participar en el proyecto de desarrollo de software, pueden proporcionar feedback en todas las etapas, siendo el más importante el que pueden proporcionar cuando están probando/trabajando con el sistema. Sin embargo, este feedback cuando resulta realmente valioso es cuando se está haciendo un uso real del sistema en un entorno de producción.

Esta característica, junto al hecho de que RUP plantea un marco de trabajo donde el proceso cobra una importancia especial, hace que la respuesta al cambio no sea ágil, ya que principalmente en la etapa de transición es donde se itera sobre el producto para ir adaptando el sistema a las necesidades y expectativas del usuario en aquellos aspectos en los que no se ha acertado en fases anteriores o como consecuencia de cambios en el negocio que se hayan producido durante el proceso de desarrollo.

Estas iteraciones se hacen sobre la versión del producto en la que se ha trabajado durante el ciclo de vida RUP, por lo que el esfuerzo necesario para hacer las modificaciones es mayor y en consecuencia el tiempo que tarda el usuario en poder disfrutar de ellos en el entorno de producción.

También se puede plantear el desarrollo como una secuencia de RUP, de manera que el proceso de desarrollo sea más liviano, de esta forma sí que se acercaría más a las metodologías ágiles, sin embargo, soy de la opinión de que RUP en origen tenía un enfoque más tipo big bang, orientándose a la entrega de una versión finalista del producto.

No es la primera vez que trato este tema.

Ya lo hice en el artículo “El paso a producción”, donde exponía algunas de las circunstancias que provocan que el proceso de implantación y aceptación de un sistema de información sea uno de los muros más complicados de escalar en los proyectos de desarrollo de software.

También lo hice, en el artículo “Un buen entorno de preproducción” donde exponía la necesidad de contar con una plataforma que permitiera hacer una implantación y un testing que no tuviera una desviación (o no fuera excesivamente significativa) de un entorno de explotación.

En esta entrada quiero destacar algunos aspectos que considero importantes para que la escalada del muro sea menos complicada:

– No solo son importantes entornos de preproducción que se asemejen a los entornos de producción. También resulta de gran interés disponer de entornos de desarrollo con infraestructuras similares a preproducción y producción (no necesariamente garantizando el mismo rendimiento y disponibilidad) y ponerlos a disposición de los proveedores para que de manera ágil y flexible puedan realizar implantaciones en entornos similares a donde tiene que funcionar el producto y así sea necesario recordar en menos ocasiones la siguiente cita de Vidiu Platon.

Proporcionar entornos de estas características requiere un esfuerzo, ya que supone otro nivel más de infraestructura a mantener, a la que hay que sumar la de producción (que además requiere un cuidado especial en lo que al rendimiento, disponibilidad y seguridad se refiere) y la de preproducción.

Es cuestión de analizar el esfuerzo que se requiere en los pasos a prueba y producción y determinar si es rentable hacer esta inversión. Desde mi punto de vista, en entornos donde tenemos un buen número de sistemas que interoperan entre sí (entre los que están aquellos en los que se delegan competencias) es recomendable.

Desarrollos iterativos e incrementales. Permiten que la complejidad del proceso de implantación se reparta entre diferentes entregas.