El pasado Jueves, el suplemento informático de ElPais ( www.elpais.es ) publicó un artículo acerca de las Fábricas de Software en España. http://www.elpais.es/articulo.html?d_date=&xref=20050512elpcibtec_3&type=Tes&anchor=elpcibtec
Una parte del artículo nos informa sobre las empresas que han optado por desplazar sus centros de trabajo a provincias como Murcia, Badajoz, o Lerida. Me parece muy interesante, ya que se normalmente se gana en calidad de vida, y eso mejora en los resultados obtenidos.
Personalmente me encantaria la posibilidad de poder trabajar fuera de Madrid, pero lamentablemente, mi profesión de consultor me exige estar en Madrid y disponibilidad para viajar al cliente.
El articulo continua con comentarios de algunos responsables de las empresas más importantes del pais que estan apostando por "Fábricas de Software". Y me sorprendió la forma de afirmar que el diseño y la construcción son actividades separadas.
Es cierto que hoy por hoy los resultados obtenidos para desarrolar software dejan mucho que desear en comparación con otras ingenierias, pero eso no significa que la unica solución consiste en seguir apoyando a las metodologías clásicas en las que se acaba suponiendo que el desarrollo es una cadena de actividades que se puede realizar de forma sistemática como si se tratase de una cadena de producción.
El enfoque clásico de dividir las fases del proyecto en 1)Análisis 2)Diseño 3)Código 4)Pruebas no suele ser todo lo efectivo que parece a primera vista, cuanto más tiempo se dedique al análisis, con la esperanza de no haberse dejado en el camino, y con más detalle se quiera realizar el diseño para intentar minimizar los errores en el código, menos tiempo se dispone para poner una primera versión (incompleta por supuesto) a funcionar. El resultado es que se entrega el producto cuando ya no queda tiempo para rectificar, y acertar a la primera es una tarea imposible, debido al conflicto de intereses entre el proveedor y el cliente.
Las metodologías ágiles son una alternativa para mejorar la industria del desarrollo de aplicaciones, para evitar los conocidos males del sector en cuanto a efectividad de proyectos realizados con éxito.
Estas metodologías hacen incapié en una serie de procesos iterativos e interconectados que dan lugar a software de gran calidad. En cada una de las iteraciones se realizan tareas relacionadas con las cuatro fases comentadas anteriormente. Asi es común empezar con las pruebas, a partir de ese punto mejorar el diseño, y todo mientras escribimos código. Pero también se puede empezar diseñando, implementando y probando. Cada escenario nos ira pidiendo las tareas según avanzamos.
El argumento es sencillo, si el resultado más importante de un proyecto de software son los ejecutables que lo hacen funcionar, las fuentes con las se crean estos ejecutables son el activo de más valor, y por eso tenemos que cuidarlo.
Las fuentes, el código, tiene que cumplir una doble misión, transmitir a la máquina como comportarse y transmitir a los programadores lo que la máquina va a entender, para poder asi comprenderlo y mejorarlo, extenderlo o simplemente mantener los posibles errores que pudiesen aparecer. Esta dualidad es muy dificil de conseguir, y debido a la dinámica de los proyectos el código se da por terminado cuando ha cumplido solo una parte de su misión.
La situación más habitual nos la encontramos al observar la reacción de los jefes de proyecto, o los clientes, al plantearles la necesidad de mejorar el diseño sin añadir funcionalidad. Esta técnica se denomina Refactoring, y no suele gustar a la gente NoTécnica
Es muy dificil, y practicamente imposible, craer una solución aceptable a la primera, es necesario dos o tres intentos hasta que se llega a una situación de équilibrio máquina/hombre. Esta forma de dividir los esfuerzos entre añadir código nuevo o modificar el existente es una de las claves para conseguir nuestro doble objetivo, código que funcione en una máquina a la vez que es entendible por personas. El diseño es una actividad que realizaremos continuamente, al escribir documentos, diagramas o código, y diseñaremos hasta el último día del proyecto.
Por todo esto no creo en la visión que se plantea de las "Fábricas de Software", en las que unos pocos realizan el diseño y se lo pasan a los programadores para que lo implementen.
Me gustaria oir hablar de centros de desarrollo, pero no de fábricas, el término fábrica transmite algo más que el mero hecho de fabricar, implicitamente se refiere a realizar tareas repetitivas que van a dar lugar a un programa.
En un centro de desarrollo se pueden concentrar muchos programadores, y eso puede ser muy bueno para la mayoria de los proyectos, en terminos de reducción de costes, asi como de mejora del clima laboral, pero para poder beneficiarse de estas mejoras hay que combatir los efectos negativos de la centralización, en concreo reducir la distancia entre el cliente y los técnicos.