archivo

Archivos diarios: julio 3, 2011

Cuando el testing rompe la fluidez en los entregables de los proyectos de desarrollo de software en una organización es necesario estudiar las causas.

Puede ser debido a que el trabajo de los equipos de proyecto son de calidad deficiente y/o que el testing impone unos procedimientos que no van de la mano con la metodología de desarrollo elegida en los proyectos.

Por regla general la culpa está repartida, es más, incluso si se analiza la situación en profundidad las causas se encuentran en la no existencia de una política de desarrollo de software en la organización que permita adoptar la solución más adecuada en los proyectos (se adoptan métodos o procesos rígidos) y en una mala orientación y comunicación de los objetivos a las diferentes partes, ya que el fin no debe ser el proceso sino la entrega de productos de calidad (evitando las causas que originan la crisis del software).

Una vez sentadas las bases, sí que se debe exigir a todas las partes implicadas en el proyecto que realicen su trabajo adecuadamente y acorde a lo que se espera del mismo. Si los desarrolladores actúan negligentemente, van en contra de la calidad, si el equipo de testing rompe la fluidez del desarrollo por circunstancias no justificadas (exceso de formalismo, celo, solicitando información que puede resultar costosa de obtener, etc…), se rompe el ritmo de desarrollo y entregas, lo cual hace perder enfoque, retrasa planificaciones y provoca la inversión de esfuerzo en tareas prescindibles (o lo que es lo mismo resta esfuerzo en tareas de mayor importancia en el proyecto), lo cual al final también va en contra de la calidad.

El testing es una ayuda muy importante en el desarrollo de software, ya que tiene como objetivo minimizar el número de errores que pasan a una etapa posterior en el desarrollo o que llegan a producción. Estas incidencias detectadas a tiempo suponen un impulso en la calidad del software y ahorran tiempo y esfuerzo. El testing es necesario, pero debe caminar de manera fluida con el proceso de desarrollo de software.

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.