archivo

Archivos Mensuales: junio 2011

En el desarrollo de software hay presiones entre las distintas partes que participan en los proyecto:

– Los clientes a los proveedores para que se cumplan o adelantes los plazos, para añadir nuevos requisitos cuando estos se han cerrado, para que el acabado del trabajo sea el mejor posible…

– Los proveedores a los clientes para que el alcance de los trabajos se limiten lo máximo posible, para que en el caso de que haya desviaciones, se intercambien por dinero o se reduzcan las tareas, para conseguir nuevos contratos…

– Los usuarios a los responsables técnicos del cliente para que a su vez presionen al proveedor para que se acepten mejoras más allá de las especificaciones pactadas, para que el producto que está en producción tenga corregidas sus deficiencias lo antes posible…

– Los proveedores a sus equipos de proyectos para que los trabajos no se vayan en coste, para que compensen con su esfuerzo todo el trabajo adicional que llega del cliente o para ajustar presupuestos difíciles de cumplir…

y podría seguir porque todas las partes se relacionan en un proyecto. La espiral de presión solo crea beneficios al que sabe aguantarla y maneja adecuadamente los hilos para conseguir lo que pretende (o parte), de hecho hay quienes se sienten cómodos en este tipo de situaciones porque cuando la cuerda se tensa demasiado muchos tratan de esquivar los problemas.

Yo creo que se pueden abordar los proyectos de otra manera sin tener que entrar en esa espiral de presiones, encuentros y desencuentros y lo digo siendo un jugador más de todo esto. Sin embargo, esto es un negocio y cuando hay dinero de por medio, nadie conoce a nadie.

Soy de la opinión de que en el desarrollo de software los requisitos funcionales y de interfaz de usuario deben quedar resueltos antes de empezar a codificar, sin embargo hay ciertos aspectos que no cobran su verdadera forma hasta que uno se enfrenta a su programación, hasta que se siente el código.

Sentir el código, es una cita que leí a Alex Bergonzini en su Twitter y desde luego no le falta razón ya que en la programación se enfoca el problema.

Martin Fowler también le da importancia a sentir el código en su siguiente reflexión (traducción libre): “Cuando te sientas a escribir código, aprendes cosas a las que no puedes llegar en el proceso de modelado… ya que hay un proceso de feedback al que solo puedes llegar desde la ejecución de determinadas funcionalidades y viendo como funcionan”.

El desarrollo de software es adaptativo y todo no se puede prever, a veces hay que experimentar hasta encontrar una solución satisfactoria para el usuario, eso es totalmente compatible con los desarrollos ágiles. Ahora bien, el hecho de que los principios ágiles indiquen que no hay que elevar ninguna funcionalidad a definitiva no quiere decir que todo deba ser consecuencia de la experimentación, porque construir y tirar módulos software además de ser caro puede provocar una desmotivación importante en el equipo de proyecto.

Esta profesión da lugar a momentos que en ocasiones resultan entretenidos, en otras ni fu ni fa y en otras, desagradables. Supongo que como en otros empleos.

Lo que sí tengo claro es que si no te gusta, esta profesión te lo puede hacer sentir bastante mal, aunque siempre queda la posibilidad de pensar exclusivamente en lo que te pagan, poco o mucho y tener presente que después del trabajo queda todavía mucha vida.

Esta sensación la podemos tener de vez en cuando o ser lo más común, dependerá mucho de dónde trabajemos, en qué trabajemos, de su contexto y sobre todo de lo que nos guste lo que hacemos.

¿Conozco a más gente que está satisfecha o insatisfecha en esta profesión? Si hiciéramos una encuesta no sé si la media llegaría al 5 y casi apostaría que no llegaría al 7. El desarrollo de software es muy ingrato, no está bien pagado y causa mucho desgaste.

No quisiera expresar exclusivamente sentimientos negativos, ya que cuando un desarrollo va bien, cuando te sientes cómodo en una organización y/o con tu equipo de trabajo, cuando te sientes valorado, cuando percibes que lo que estás haciendo sirve para mejorar algo, es tremendamente satisfactorio y nos hace olvidar o al menos dejar en segundo lado muchos de los sinsabores pasados.

Yo he disfrutado y odiado esta profesión y he pasado por la mayoría de la escala de grises que separa ambos extremos, ¿dónde estoy ahora? eso es lo de menos, la semana o el mes que viene lo mismo siento algo distinto, tal vez lo más importante de todo es que cuando he disfrutado su intensidad se ha impuesto a las sensaciones de los malos momentos.

No es lo más importante del desarrollo de software siguiendo principios ágiles, sin embargo, no se pueden entender desarrollos ágiles en sistemas con deudas técnicas elevadas o en proyectos donde la calidad del código sea deficiente.

No es lógico establecer un contexto que favorezca un desarrollo ágil y sin embargo se descuide la arquitectura del software y la codificación, teniendo en cuenta que el código lo comparte todo el equipo de proyecto que realiza tareas de programación.

Con respecto a la calidad del código, Martin Fowler, comenta lo siguiente en su libro “Refactoring: Improving the Design of Existing Code”: “Cualquier tonto puede escribir código que un ordenador pueda entender. Los buenos programadores escriben código que los humanos puedan entender”.

Si yo fuera proveedor de servicios de software intentaría tener invertido una buena parte de mis proyectos en plazo fijo, es decir, en proyectos donde facture por horas. En este tipo de trabajos, salvo que se gestionen muy mal o la calidad del servicio sea deficiente, se ganará dinero, tal vez no tanto como en otros, pero la seguridad de tener cubierto una buena parte de tu presupuesto, también tiene su valor.

Tanto se ha trabajado así entre clientes y proveedores que incluso en los proyectos orientados a cumplir un servicio, los proveedores siempre ponen sobre la mesa las horas cuando ven que existe una desviación en el presupuesto.

Si se contrata un servicio, debe estar por encima del esfuerzo ejecutado, ya que eso es lo que se ha contratado, un presupuesto cerrado.

El adjudicatario del servicio medirá internamente los costes del proyecto basado en las horas y el avance del mismo y también puede expresar al cliente su preocupación por las desviaciones en el presupuesto y ese es el límite al que se puede llegar.

Si las desviaciones son consecuencia de que el proyecto no va sobre las líneas especificadas en el contrato, sí que resulta razonable negociar y tal vez intercambiar unas tareas por otras o cambiar presupuesto de los trabajos.

Sin embargo poner sobre la mesa las horas y ser esa la base para una nueva negociación es un error. Si están justificadas plantea las causas y no tengas problemas en intentar que se te escuche. Si no hay una justificación en el proyecto, mi recomendación es que se asuman los errores y no se intenten compartir con el cliente, ya que al desgaste que se produce en el desarrollo normal del proyecto, se le añadirá otro que puede hacer muy complicadas las relaciones en el mismo y hará más difícil alcanzar los objetivos y si estos no se consiguen nadie terminará contento, nadie gana, aunque se consigan beneficios económicos.

La simplicidad es ágil. Siempre que se pueda es necesario huir de soluciones complejas. Tal vez la solución más simple no sea la mejor pero a larga se podrá comprobar como las complejas tampoco lo son y el esfuerzo para llegar a ellas, su coste de mantenimiento y la más que posible pérdida de productividad por parte de los usuarios harán inviable un retorno de la inversión a corto/medio plazo o incluso su propia recuperación.

¿Por qué tienen éxito muchas soluciones basadas en herramientas ofimáticas? Son sencillas.

Cierto es que aunque hagas un sistema de información absolutamente idéntico, nunca podrá competir con la flexibilidad con la que puede trabajar el usuario en ellas y con el rendimiento que supone trabajar con una solución que tiene en local o que se encuentra en su red de área local y eso hace por ejemplo que los usuarios muestren rechazo cuando le sustituyes estas soluciones por una aplicación.

Sin embargo es su simplicidad el principal motivo por el cual sus usuarios se sienten ligados a ellas.

A veces nuestra propia creatividad pone muy cuesta arriba el desarrollo de un sistema de información y tenemos que tener muy presente que nuestro objetivo no es ser artistas, sino desarrollar aplicaciones que sean útiles a los usuarios, dentro de unos plazos y presupuestos definidos.

Sucede con demasiada frecuencia que cuando se entrega una evolución de un software, ya sea en una iteración en un desarrollo iterativo incremental o en un mantenimiento correctivo o evolutivo, se realiza testing exclusivamente sobre las funcionalidades que se han desarrollado y no se comprueban otros segmentos del programa que se han podido ver afectados por los cambios realizados en el código.

En muchos casos son las prisas por cumplir plazos en el proyecto, en otros por la necesidad de solucionar una urgencia y en otros tantos porque no se piensa que determinados cambios en el código puedan provocar efectos colaterales en la aplicación.

Las posibilidades de que se produzcan este tipo de problemas dependerá mucho de la calidad de la codificación y de la sección del código que se esté tocando, ya que no es lo mismo tocar una clase con un alto acoplamiento que otra.

Para reducir el riesgo de que aparezcan efectos colaterales, es conveniente la realización de pruebas de regresión que se basan principalmente en realizar testing sobre funcionalidades de la aplicación que presentan riesgo de haber sido afectadas por los cambios. El esfuerzo necesario en realizar estas pruebas dependerá del nivel de automatización de las mismas que se tenga hasta el momento en el rango que va desde las pruebas unitarias hasta las funcionales.

Sobre las pruebas de regresión y en general sobre el hecho de que en la programación no hay que dar nada por sentado, podemos recordar la siguiente cita de Doug Linder: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido”.