archivo

Archivos diarios: julio 17, 2011

Martin Fowler creó el concepto de integración continua como una técnica o estrategia que consiste en programar automáticamente el proceso de compilación y ejecución de pruebas unitarias de un software que se está desarrollando.

El objetivo de la técnica consiste en detectar errores unitarios y de integración lo antes posible. Si se dejan estas comprobaciones para etapas muy tardías del proyecto los costes de corrección de estas incidencias se disparan) sobre todo en equipos de proyecto de tamaño medio o grande que trabajan en diferentes localizaciones).

No es una estrategia exclusiva de metodologías ágiles (podría ser utilizada perfectamente en metodologías del proceso unificado como RUP o en la fase de construcción de metodologías clásicas como por ejemplo el ciclo de vida en cascada), si bien su aplicación en las mismas resulta de gran importancia tanto en el proceso de desarrollo como para reducir los tiempos de implantación del sistema.

Se entiende integración continua cuando el proceso se programa para que se ejecute automáticamente. También podría considerarse cuando la integración se realice de forma planificada, aunque se realice de forma manual, en intervalos razonablemente cortos de tiempo. No es integración continua si se ejecuta de manera esporádica o en momentos próximos a la entrega.

Si problemático resulta el desarrollo de software, el paso a producción en muchos casos no lo es menos. La implantación de un sistema de información con una cierta envergadura no es un proceso trivial y es necesario, en el caso de que el tiempo que se tarde no sea bueno, medir y mejorar el proceso para intentar alcanzar una mejora continua que lleve a unos umbrales aceptables.

Jim Highsmith, firmante del manifiesto ágil, hace una reflexión sobre este tema en su artículo “Shortening the tail“.

Este autor denomina como “tail” a todo el proceso posterior a que una evolución de un producto se considere terminada por parte del equipo de proyecto. En este proceso se incluirían las actividades de testing, pruebas de regresión, integración, pruebas de integración, documentación, corrección de incidencias de la entrega y paso a producción.

De hecho la definición exacta que da de tail es todavía más elocuente (voy a dejar algunas palabras en inglés para no restar significado): Es el tiempo transcurrido desde el “code slush” o “feature freeze” hasta el despliegue del producto.

Comenta Jim Highsmith que el tail más largo que encontró fue de dieciocho meses. Afortunadamente no he tenido uno tan largo, los peores tiempo con que me he encontrado han sido de tres o cuatro meses, si bien, ha sido debido generalmente a que el proceso de desarrollo lo había fraccionado en varias entregas, lo que daba lugar a que el tiempo se repartiera entre las mismas. Probablemente si sumara los tiempos de las mismas serían muy superiores a los meses que he indicado.

Tail de larga duración para entregas o evoluciones simples son un problema, ya que marcan el tiempo en el que un usuario por término medio podrá disfrutar de una evolución del producto (no cuento los posibles parches rápidos que se puedan instalar, ya que estos, generalmente tienen otro proceso de implantación).

Estas evoluciones en muchos casos no son caprichos, sino necesidades que si no son cubiertas provocan una ineficacia en el trabajo desarrollado por los usuarios y en consecuencia un impacto en los resultados del departamento y en consecuencia de la organización. Es por ello que se debe dar la importancia que se merece la optimización de estos tiempos.

Todos quisiéramos llevarnos bien con todo el mundo pero no es así. Cada cual tiene su manera de ver las cosas, defiende lo suyo y tiene distintos niveles de empatía.

En el trabajo hay que ser profesional y que por encima de todo se encuentre el deseo de sacar el trabajo adelante de la mejor manera posible.

Habrá días donde no puedas ver a alguien, con razón o sin razón, pero una vez pasado el tiempo suficiente, si hay una tarea o un proyecto donde se requiere la participación de ambos hay que mirar hacia adelante para ejecutarlo.

No tienes por qué olvidar, no tienes por qué engañarte a ti mismo y opinar de manera diferente sobre esa persona, pero sí hay que ser profesional y centrarte en el cumplimiento de los objetivos que tienes marcados.

Sucede en todos los trabajos pero en el desarrollo de software este tipo de circunstancias están a la orden del día. Proyectos con presupuestos muy limitados, ofertas imposibles y metodologías arcaicas, no ayudan a crear los mejores ambientes de trabajo posibles.

Si se dirigen los problemas hacia lo personal y no se le da un enfoque profesional, los problemas terminarán por ahogar el proyecto.

El desarrollo siguiendo los principios ágiles tiene como objetivo principal conseguir la satisfacción del usuario a través del cumplimiento de sus expectativas.

El modelado de un proceso suele resultar complejo en el sentido de que se están informatizando unas dinámicas de trabajo que hasta ahora se realizaban utilizando otros instrumentos (incluyendo productos informáticos como por ejemplo soluciones ofimáticas para realizar determinadas tareas).

Resulta muy complicado en la mayoría de los casos acertar a la primera con una solución que satisfaga al usuario y sea productiva. La solución más adecuada se consigue a través del feedback.

Las metodologías unificadas como RUP o las ágiles tienen en cuenta esta dinámica de funcionamiento como algo natural en el desarrollo de software ya que tiene una naturaleza adaptativa y no predictiva (que es el enfoque que siguen las metodologías tradicionales, como el ciclo de vida clásico o en cascada).

Aceptar esta realidad no es perder el tiempo ya que lo que hace es aproximarte más hacia el objetivo. Perder el tiempo es desarrollar funcionalidades que no se van a utilizar o realizar documentación que no tiene ningún tipo de utilidad.