archivo

Archivos Mensuales: diciembre 2012

Que un proyecto sea complejo y/o tenga numerosas resistencias no debe ser excusa para tratar de obtener la mayor calidad posible del software y del producto dentro del contexto en el que nos toque trabajar.

Por ese motivo, los equipos de proyecto deben establecer mecanismos para garantizar esos umbrales de calidad y la coordinación general del mismo debe armonizarlos y exigirlos siempre teniendo en cuenta el contexto y nuestras posibilidades, y también las características del sistema que se desarrolla: un sistema crítico en el que se pone en juego la integridad de las personas, del medio ambiente o la cuenta de resultados de una organización requerirá unos mecanismos de control más estrictos que otros tipos de aplicaciones (en lógica, ese sistema debería tener un presupuesto de trabajo acorde a esas características).

Meses trabajando en el proyecto, con un desgaste importante y en el que cada día es una aventura nueva. Decenas de personas trabajando, de organizaciones y departamentos distintos. Riesgos que aparecen de forma continua. Y detrás de todo una agenda que cumplir, que podremos negociar con el área usuario (o no), pero que al fin y al cabo te establece unos hitos y unos límites.

Este puede ser el día a día de gran parte de los proyectos de desarrollo de software en los que estamos trabajando, en resumen, mucha dificultad y mucho trabajo para conseguir que salga adelante de la manera más satisfactoria posible para todas las partes. Si además, tratamos de que llegar lo más próximo al límite de la calidad que nos permite tener el contexto del proyecto el esfuerzo será muchísimo mayor.

El equipo de testing no debería ser ajeno a las intrahistorias del proyecto, a la complejidad que se está teniendo en el proceso de desarrollo, si me apuráis incluso a ese sufrimiento para sacar el trabajo adelante, por ese motivo recomiendo que los testers participen activamente en los trabajos porque de esta forma su empatía con el resto del equipo le permitirá entender por qué se ha actuado de una manera o de otra.

De esta manera no solo la labor del tester es más efectiva sino que los controles de calidad tienen en cuenta todo lo que ha pasado.

Resulta demoledor para los desarrolladores cuando haciendo una presentación del estado de desarrollo del proyecto al equipo de testing, estos empiezan a fijarse en detalles sin importancia teniendo en cuenta todo lo que se ha tenido que pasar para llegar a ese momento, es como si después de haberte perdido en el bosque un día de tormenta, lo primero que te dicen cuando llegas a casa es que hay que ver que cómo es posible que se te caído un botón de la camisa.

Como vengo haciendo al final de estos dos últimos años, os pongo la lista de los 25 artículos más visitados desde que empecé con el blog. Os pongo los enlaces de acceso, por si os interesa leer alguno.

1.- Desarrollo de software. Ciclo de vida RUP (Rational Unified Process).
2.- Desarrollo de software. El analista funcional y el analista orgánico.
3.- Mantenimiento adaptativo.
4.- Orientación al producto.
5.- La importancia de un buen análisis funcional.
6.- Ahora más que nunca hay que mirar al software libre.
7.- Mantenimiento correctivo y mantenimiento evolutivo.
8.- Las precondiciones y postcondiciones en los casos de uso.
9.- Ciclo de vida iterativo incremental.
10.- Ciclo de vida clásico o en cascada.
11.- LCOM4 y la falta de cohesión en las clases.
12.- Delimitar el alcance del proyecto.
13.- Desarrollo de software. Programación extrema (eXtreme Programming: XP).
14.- Empresas de desarrollo de software: ¿estructura vertical u horizontal?.
15.- La crisis del software.
16.- Complejidad ciclomática.
17.- Reducción de tiempos muertos.
18.- El papel de los usuarios en un proyecto de desarrollo de software.
19.- Testing de caja gris (Grey box testing).
20.- Proyectos de desarrollo de software: La importancia de las métricas y de la documentación.
21.- Pruebas de regresión.
22.- Desarrollo de software. Método de desarrollo de sistemas dinámicos (DSDM) III.
23.- El paso a producción.
24.- Ciclo de vida por prototipos.
25.- PMD: Security – Array is stored directly.

Si queréis consultar las listas de los dos últimos años:

Los 25 artículos más leídos de mi blog
Los 25 artículos más leídos de mi blog II

Los extremos nos llevan a situaciones no deseadas. Cuando nos olvidamos que la agilidad es la capacidad de adaptarnos al contexto y que para ello es fundamental la interacción entre las personas, su capacidad de comunicación y diálogo y la orientación al valor del producto y pensamos que sus logros se obtienen a partir de la aplicación de metodologías, prácticas o estrategias concretas, nos alejamos, precisamente, de sus valores y principios.

La agilidad es actitud, primero requiere entender su base conceptual, después está la técnica y todo ello con nuestra experiencia en background. Si te centras en metodologías te estás tapando los ojos ante el contexto, ante las circunstancias que rodean al desarrollo y que te van a acompañar, al menos durante un tiempo, en el proyecto.

Al final, te conviertes en un esclavo del proceso, de esas prácticas que se consideran que sirven para todo, de esa talla única que viste cualquier desarrollo, en definitiva, te conviertes en un esclavo de precisamente de aquello de lo que pretendías escapar.

Contar con presupuesto te permite el suficiente margen de maniobra para solucionar los posibles problemas que puede tener un sistema de información. Sin embargo, el dinero por sí mismo no arregla nada si las decisiones que se toman son incorrectas, si no se desarrolla con intención o no se resuelven los problemas que existen de raíz.

Puedes echar decenas y decenas de miles de euros a un sistema y no incrementar proporcionalmente su valor.

Este antipatrón surge cuando se cuenta con un importante presupuesto que bien utilizado podría mejorar el producto pero que en lugar de centrarse en los problemas existentes en el sistema, se invierte en un crecimiento desproporcionado y/o difícil de controlar del sistema que mezcla la resolución de esos problemas con una ampliación funcional generalmente de aspectos secundarios.

En esta situación se divide el enfoque y el presupuesto entre lo principal y lo accesorio poniendo ambos al mismo nivel, a la que vez que se dota de una mayor complejidad al sistema, generándose resistencias que afectan al directamente al esfuerzo (y coste) necesario para desarrollar. Por tanto, el presupuesto para arreglar los verdaderos problemas del sistema queda debilitado a la vez que la deuda técnica va creciendo y en consecuencia los costes de desarrollo.

Llegado a un extremo (y a veces no es necesario escorarse tanto) nos habremos “comido” el presupuesto y los problemas (o la mayoría de ellos) seguirán ahí, y lo que es todavía peor, con otros nuevos que posiblemente se han añadido, con un producto más complejo de evolucionar y con una confianza muy erosionada por parte del cliente o del área usuaria (independientemente de que ellos hayan tenido mucho o poco que ver en la priorización de las tareas y en la estrategia utilizada).

El enfoque clásico, predictivo o en cascada del desarrollo de software tiene como objetivo final el cumplimiento de a la agenda: “Estas son las condiciones contratadas y esto es lo que hay: alcance, coste y plazos”.

La premisa es que las condiciones de partida no van a cambiar y que la información existente para realizar las estimaciones era suficiente para que la desviación en lo vértices el triángulo de hierro no afecte a la calidad final de los trabajos.

Puedo no estar de acuerdo con esta estrategia de desarrollo de software, teniendo en cuenta que mi apuesta es por los enfoques iterativos incrementales siguiendo prácticas ágiles, pero no por ello es una estrategia descartable ya que puede ser válida o la solución más óptima en determinados tipos de contextos.

Además, a priori, suena bien eso de cumplir la agenda, porque de ello se desprende tranquilidad y predecibilidad (sé lo que me gasto, sé lo que voy a obtener y cuándo) y es cierto, en teoría parece que no presente grietas.

Pero solo en teoría, el castillo de naipes se desmorona en el momento en que las condiciones de partida cambian (es posible que incluso se desmorone antes, si la estimación ha sido deficiente) y eso es algo que se producirá con una probabilidad muy alta, causas puede haber muchas, como por ejemplo que cambie el proceso que se quiere informatizar, que la implicación de una de las partes sea menor que la esperada, que la complejidad sea superior a la prevista, etc… pero lo más frecuente es que el propio usuario se de cuenta en el proceso de desarrollo de ciertas mejoras o cambios que permitan dar al producto un mayor valor.

¿Dónde comienza el antipatrón? Cuando se pasa de velar por el cumplimiento de la agenda a una situación de culto por la agenda, de manera que no se trata de buscar una solución mediante la flexibilización de alguna de las variables: coste, plazos, alcance y calidad, sino que se pretende conseguir la cuadratura del círculo de manera que se asuman los cambios sin variar las condiciones de partida.

Y esto no suele traer buenos resultados, para empezar se producirá un desgaste en las relaciones entre los diferentes equipos implicados que hará todavía más complicada la consecución de los objetivos, dará lugar a un sobreesfuerzo por parte de muchas personas con el objeto de compensar esa desviación lo que terminará pasando factura en la calidad y en la productividad y por último el producto final será el reflejo de todos estos problemas y situaciones.

Tener a tu cargo amigos es el camino más rápido para perderlos y/o hacerle perder dinero a tu organización.

Es muy importante trabajar con gente con la te llevas bien porque te hace todo más fácil: existe entendimiento, se conoce a las personas, sus días buenos, los malos, sus fortalezas, sus debilidades, etc… El problema surge cuando ese llevarse bien se torna en amistad y se pierde la objetividad (amistad no implica necesariamente pérdida de objetividad, el problema es cuando alguna de las partes se deja llevar por esta situación).

¿Problemas?

– No aceptar que alguien a quien consideras tu amigo te rectifique comportamientos o te pida resultados.

– No tratar a tu amigo por el mismo rasero que al resto de compañeros.

Las emociones y los sentimientos son importantes siempre y cuando no sirvan para manipular o para crear injusticia: no estás solo en tu equipo o en la organización, hay muchas personas cuyo trabajo depende de lo bien que se hagan las cosas y la propia entidad depende de su productividad, la cual puede verse lastrada por este tipo de comportamientos.

El antipatrón no es tener amigos a tu cargo y la solución no pasa necesariamente por evitar esta situación, sino que trata de los problemas que trae consigo cuando se anteponen los sentimientos a la objetividad.

Si la amistad ha surgido como consecuencia del trabajo diario en un proyecto suele haber menos problemas porque ha nacido dentro de un contexto en el que cada cual juega un rol. Si en un momento dado, alguno cambia de proyecto, se mantiene la amistad y mucho tiempo después se vuelve a trabajar juntos, la situación no es la misma ya que tenemos la virtud o el defecto de que olvidamos pronto.

Debemos entender que la amistad son 24 horas al día y que hay un período del mismo en el que se superpone la relación profesional y es fundamental entender esto para, por un lado, conservar la amistad y por otro ser consecuente con tus responsabilidades.

Tener muchos entornos es sinónimo de sembrar de incoherencias una serie de servidores y/o de bases de datos. A veces puede resultar lo más cómodo pero es una visión cortoplacista porque al final te terminas arrepintiendo y no tardarás en darte cuenta como el usuario está probando en un entorno que no debe ser, tus desarrolladores trabajan en otros que no tampoco lo son, mientras que tu ya no sabes ni cuál es el bueno.

Tiene que haber diferentes entornos (no cuento las posibles instalaciones en local de los desarrolladores que tienen mucho peligro si no se hacen integraciones y sincronizaciones con frecuencia): lo normal es que hayan tres o cuatro (en función de si el producto se desarrolla internamente o para un tercero): integración del equipo de desarrollo, integración (del cliente), preproducción y producción. En función de la naturaleza del proyecto y/o de problemáticas concretas el número de entornos puede crecer o disminuir.

Cuando crece demasiado o innecesariamente, te darás cuenta en el momento en que todo se convierte en un caos. La solución es tratar, cuanto antes, de una situación más estable.