archivo

Archivos diarios: enero 3, 2012

Este antipatrón es el resultado de dividir partes del desarrollo de software entre diferentes equipos de trabajo sin que exista una comunicación real o eficaz entre los mismos.

Por lo que cuando se tienen que utilizar elementos de desarrollo comunes o uno tiene que utilizar algún artefacto o módulo construido por el otro, el efecto será como recoger el mismo al otro lado de un muro una vez que ha sido lanzado por encima de él.

¿Que hay de malo en todo esto? Problemas de integración entre componentes, problemas a la hora de asumir responsabilidades (casi siempre se echará la culpa al otro grupo que está tras el muro), traspaso de marrones, falta de identidad de equipo de proyecto común (es más, cuando surjan conflictos si no se solucionan de manera adecuada, más que parte del equipo de proyecto se verá a la otra (u otras partes) como enemigos, etc…

Lo primero que habría que plantearse es si realmente el proyecto necesita trabajar con más de un equipo de proyecto. En el caso de que así sea, si es posible que compartan una localización. Tanto si ocupan o no la misma localización es necesaria una coordinación y comunicación constante entre los equipos y la existencia de una dirección común entre los mismos (surgirán conflictos y si no se solucionan a nivel horizontal, alguien tendrá que resolverlos), además de unos procesos que definan unas líneas comunes de trabajo y actuación.

Se trata de otro antipatrón muy típico. Se dice que un sistema de información es una gran bola de lodo cuando su desarrollo no ha seguido una lógica, patrón o estructura común, es decir, no se ha respetado una arquitectura, no se ha gestionado adecuadamente el modelo de datos de la aplicación (nomenclatura no apropiada para los objetos, datos duplicados e incoherentes, etc…), no se han seguido prácticas comunes de programación y gestión de la configuración, no se han respetado buenas prácticas que minimicen la deuda técnica, se ha descuidado el rendimiento del sistema, etc…

Como podréis ver, este antipatrón se produce como consecuencia directa de la aplicación de otros antipatrones.

Se le denomina gran bola de lodo porque aunque el sistema funcione (y es cierto que aunque sea milagrosamente algunos sistemas así llegan a funcionar e incluso son aceptados por los usuarios) su mantenimiento es insufrible: requiere un gran esfuerzo (coste) y cada paso a producción de una nueva versión o un nuevo parche lo haremos con gran temor por mucho testing que hagamos, ya que el acoplamiento será tal que un cambio en un elemento podrá provocar errores hasta en el punto más insospechado de la aplicación.

¿Qué circunstancias puede llevar a sistemas de estas características? Muchas. Generalmente se tratará de sistemas en los que han participado diferentes equipos de trabajo sin existir una coordinación real o eficaz entre los mismos, en desarrollos donde los equipos de proyecto tenían una rotación alta y, como en el caso anterior, no ha existido una continuidad en la coordinación, en mantenimientos donde se han sucedido equipos distintos incluso de empresas distintas, etc…

Por supuesto, todo lo anterior se podría evitar o minimizar si además de esa coordinación, existieran unos mecanismos adecuados de control de calidad.

Me pasa que cuando leo libros, artículos o me fijo en determinadas actitudes interesantes intento aplicar determinados cambios en mi comportamiento personal y profesional siempre tendentes a mejorar de manera individual y, ya sea fruto de ese cambio individual o a través de acciones concretas, tratar de mejorar mi entorno.

¿Lo consigo siempre? que más quisiera yo, pese a que los cambios individuales solo dependen de mi y de nadie más. Cambiar los hábitos resulta complicado y lo que en la teoría parece sencillo, la cruda realidad demuestra que su aplicación no es tan simple.

Lo que sí tengo claro, independientemente de que no consiga aplicar en el ámbito personal o profesional determinados cambios, es que cualquiera puede ser un agente del cambio. Sí cualquiera, estés donde estés, encuentres donde te encuentres, pintes lo que pintes.

Para empezar, tu cambio individual ya de por sí te transforma a ti y a lo que está a tu alrededor porque una visión, actitud o acción diferente hace distinta tu relación con los demás y la forma en que afrontas o enfocas las tareas que haces. No pienses en que los cambios se consiguen de la noche a la mañana, llevan su tiempo, tanto que, en ocasiones, has conseguido tus objetivos y no te has dado ni cuenta.

Por ejemplo, puede resultar complicado que empiece a aplicar metodologías ágiles una organización no acostumbrada a trabajar con ellas o que no las contempla en sus procesos de desarrollo, lo cual a su vez puede verse reforzado con el hecho de que los clientes tampoco las estén aplicando, ante esto, nos podremos preguntar, ¿cómo puedo aplicar las metodologías ágiles en una situación como esta? Tal vez no lo puedas hacer, pero como ya he venido comentando ser ágil es primero cuestión de actitud, lo demás vendrá después. Cambia tu actitud, trabaja de manera ágil, seguro que poco a poco las cosas ya no son como eran porque entre otras cosas y como dije antes, tú has cambiado.

Muchas veces te asaltarán pensamientos del tipo: “si la empresa en la que trabajo no hace nada por mi, ¿por qué voy a hacer algo yo por ella?”, y no te faltará razón cuando los tengas. Las organizaciones y sus gestores son desmotivadores natos, tanto que si se quedasen quietos por lo menos te quedarías igual. Ahora bien, ten en cuenta siempre una cosa, el primer beneficiado por un cambio serás tú y es un error privarte de él por no querer que tu organización se beneficie del mismo.

Entre la teoría y la práctica o entre la teoría y la realidad hay mucho camino, cada entorno es diferente y además varía con el tiempo, te toca a ti asumir el cambio y adaptarlo a tu realidad.

Incluso en el mejor de los casos donde realmente sean relativamente pocos los cambios a realizar en el producto software una vez entregado, siempre será necesario disponer de un presupuesto para el mantenimiento del sistema de información.

Si esto sucede incluso en la mejor de las situaciones, ¿qué pasa con esos proyectos mastodónticos desarrollados en cascada donde han existido infinidad de contingencias y en los cuales no ha existido una previsión para el mantenimiento del sistema o la previsión se ha quedado muy lejos de lo necesario?.

Pues que probablemente el sistema fracase o que tras mucho, mucho tiempo empiece a ver la luz. Eso sí, tras un desgaste tremendo por parte del equipo de desarrollo que tendrá que trabajar con un sistema mucho más grande que lo que puede abarcar y en un entorno de producción donde las presiones del área usuaria y de la dirección serán constantes.

Me resulta muy curioso cómo determinados directores usuarios se niegan a pagar el mantenimiento del sistema porque entienden que ya han pagado lo suficiente y todo eso a pesar de que son conscientes de que han estado cambiando especificaciones hasta el final y que muchas de ellas no han resultado acertadas.

Al final, uno descubre que se trata, en gran parte, de un problema pedagógico y es que una de las líneas de actuación (tal vez no la más importante, pero sí a tener en cuenta) para empezar a dignificar nuestra profesión, mejorar el resultado de nuestros productos y a la vez la satisfacción del cliente y luchar contra la crisis del software es empezar a formar a los stakeholders no desarrolladores en la realidad de los proyectos de desarrollo de software.

Otro antipatrón que revela la falta de experiencia de un programador o de un equipo de desarrollo es la acumulación a nivel de código fuente de funcionalidades de negocio en un elemento de la interfaz.

De esta forma no se consigue una adecuada separación de capas entre la vista y el negocio de manera que quedan acopladas y se dificulta en consecuencia el mantenimiento del elemento de la interfaz y en general de la propia aplicación si este antipatrón se ha aplicado de manera sistemática.