Evitar quebraderos de cabeza al final de los proyectos

Me planteaba una cuestión muy interesante uno de los alumnos de mi curso de Gestión de Proyecto con Team System de CampusMVP: ¿Cómo reducir los problemas en las fases finales del proyecto? Ya respesta obvia es: evitando que exista una fase final. Os imaginaís que pasaria si en los viajes a la luna quien diseño el Apolo hubiese dejado para el final pensar en como aterrizar:

– ¿Algien tiene un sistema de aproximación por ahí?
– Upss… no… pero corre estos scripts que te instalaran uno…
– Han fallado…
– Espera que te parcheo la capa de acceso a datos y quiza funcionen… Manolo!!!! recompila!!!! En debug que en release no hemos probado…
– Ahora funcionan los scripts… pero no veo nada en los controles…
– Lo mismo es no funciona el databinding pero eso los compila Pepe, que esta de vaciones. Solo lo puede compilar en su equipo y no tenemos la clave… Tendrás que aterrizar mañána…
– Cagón la puta, otra vuelta a luna… es ya la quinta…
– Tranquilo que mañana va el programador y te lo instala…

Esto que es absurdo es algo que ocurre a menudo en los proyectos de software.

La fase de implantación de un proyecto de software (o la de liberación en el caso del software ‘en caja’), siempre ha sido problemática. Pasar de un entorno de desarrollo a un entorno de producción nuestro proyecto o asegurar que el software se despliega en los equipos de nuestros clientes de manera correcta y ‘suave’ es algo vital para el éxito de nuestros proyectos. Los motivos por los cambios de entorno o despliegues son tan críticos son diversos, pero están relacionados con dos factores principalmente: la heterogeneidad de los entornos y la mayor carga que sufren las aplicaciones en producción.

La percepción respecto a los problemas de despliegue de los clientes ha cambiado. La percepción de los clientes respecto a la calidad del software en general ha cambiado, escribía sobre esto no hace mucho en mi blog: La calidad en el software no es opcional. Los clientes son cada vez más reacios frente a las aplicaciones que no se depliegan suavemente.

El enfoque tradicional en desarrollo del software ha sido centrarse en desarrollar la funcionalidad del sistema y solo al final preocuparnos por la integración y la desplegabilidad de los diferentes componentes. La industria del software ha descubierto que estas características del software son algo de suma importancia que no se puede dejar para el final del proyecto. Abordar estos aspectos al final del proyecto suele ser equivalentes ha olvidarlos.

¿Cuales son las soluciones que plantean la ingeniería del software y las herramientas de desarrollo modernas?

Pues el uso de técnicas como las construcciones frecuentes, bien sean diarias o incluso continuas. Las construcciones diarias consisten en construir una vez al día el software completo, desplegarlo en diferentes entornos de manera automática y ejecutar nuestros test automáticos en esos entornos. La construcción continua lleva la construcción frecuente al extremo, de manera que cada vez que se integra código en el gestor de fuentes se realiza el proceso de construcción, despliegue y testeo automático. Si estas pruebas automatizadas se ejecutan de manera correcta, podemos pasar esa build a nuestros testers para que ejecuten aquellas pruebas de aceptación que hayamos definido. Evidentemente, esto no es posible si no tenemos un tester en nuestros proyectos. Utilizando estas técnicas desde el comienzo de nuestros proyectos nos aseguramos que distribuimos la carga de trabajo necesaria para integrar y asegurar la desplegabilidad durante toda la vida del proyecto, evitando el efecto ‘en mi entorno funciona’ consistente en que cuando creemos que el proyecto esta ‘completo’ tenemos una fase muy larga y tortuosa de implantación y despliegue que siempre genera tensiones entre stakeholders y equipo de desarrollo.

Desde el punto de vista de las herramientas, Team System soporta estas técnicas modernas de desarrollo de software permitiéndonos definir construcciones automáticas, que ejecuten aquellos tests que consideremos necesarios o interesantes, y que podremos ejecutar a nuestro antojo para construir, integrar y desplegar nuestro software en entornos de test de manera automática cada vez que lo consideremos conveniente.

Desde el punto de vista de las metodologías modernas de desarrollo, casi todas abordan el tema de un modo u otro. Scrum obliga a que al final del cada sprint tengamos software que este completo para su implantación en si así lo decide el Product Owner. Solo el software que es completamente funcional y tiene la calidad suficiente puede ser demostrado en el Sprint Review Meeting. En MSF tenemos un rol dedicado a asegurar la desplegabilidad y facilidad de operación del sistema, el Deployment Manager y además el principio ‘Invertir en la calidad’ es uno de los que guían esta metodología.

4 comentarios sobre “Evitar quebraderos de cabeza al final de los proyectos”

  1. Aupa Rodrigo, ya las felicitaciones te quedan cortas.

    A mí me paso, que cuando cría que sabía todo sobre lo que hacía, vino la fase final, «deployment», y en esa fase creo que aprendi más que en los tiempos de desarrollo. Y es obvio que los días de deployment considerado en el project se hicieron semanas…xD

    Saludos,

  2. Me ha encantado el…
    «Pepe, que esta de vaciones. Solo lo puede compilar en su equipo y no tenemos la clave…»

    Quién no lo ha vivido alguna vez? xD

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *