A pesar de la aplicación de metodologías y el despliegue de factorías de software, la industria del desarrollo está aún lejos de alcanzar los niveles de eficiencia y productividad obtenidos en otras ingenierías. Reflexionamos sobre las características que hacen del software una disciplina diferente a las demás y por qué la agilidad y la adaptabilidad constituyen las claves del éxito.
El caos en el software
En el año 1994 apareció la primera edición del informe CHAOS del Standish Group sobre le eficiencia en la fabricación de software. En aquella edición del estudio se daba el alarmante dato de un 189% de sobre costos en la construcción de software. En la edición mucho más reciente de 2004 los datos mejoraron aunque se mantenían ciertamente pobres. Por citar alguno, tan sólo un 29% de proyectos concluyeron satisfactoriamente, frente a un 53% de proyectos que no cumplieron con las expectativas de los usuarios y un 18% que definitivamente fueron suspendidos.
Independientemente de que este estudio haya sido objeto de críticas, convierte en cifras la percepción más o menos generalizada de que los actuales procesos de construcción del software instaurados, principalmente en las grandes compañías, resultan ineficientes. Muchos de estos proyectos acaban siendo suspendidos por no poder soportar los sobre costos o el write-off derivado de los retrasos y la mala gestión. Otros, aun siendo finalizados, acaban en un cajón por no responder a las expectativas de los usuarios finales generando insatisfacción y desconfianza en los propios procesos de desarrollo.
Como conclusión, el Standish Group propone las siguientes 10 claves para el éxito en el desarrollo de software:
- Involucración de los usuarios
- Soporte de gestión ejecutiva
- Objetivos de negocio claros
- Enfoque a la optimización
- Proceso ágil
- Gestión de proyectos
- Gestión financiera
- Recursos humanos preparados
- Metodología formal
- Herramientas e infraestructuras estándar
Un botón más en el formulario
En los últimos años, la mayoría de organizaciones que disponen de un área de TI significativa, han abordado de alguna u otra manera el problema de la eficiencia en el proceso de desarrollo de software. En este sentido, las líneas de trabajo fundamentales han sido:
- Definición e implantación de metodologías
- Organización y despliegue de factorías de software
Por supuesto, ambas líneas de trabajo son complementarias siendo el estándar de facto de esta tendencia el de una factoría de software que funciona en el contexto de aplicación de una metodología. En algunos casos, es la propia organización la que, a partir de algún modelo de calidad como CMMI, define su propia metodología y la aplica en proyectos de desarrollo, tanto en factorías de software como en equipos más reducidos.
En cualquier caso, las líneas de actuación llevadas a cabo se sustentan en una clara estrategia de industrialización en la fabricación de software. El objetivo buscado sería la aplicación sistemática de economías de escala tomando como modelo los patrones de funcionamiento empleados con éxito en la ingeniería industrial o civil. En otros palabras, la panacea de construir software en una cadena de montaje, a partir de un diseño, un conjunto de piezas prefabricadas, y personal especializado en ejecutar cada etapa del proceso.
Sin embargo, ¿es posible realmente asimilar el desarrollo de software con, por ejemplo, la fabricación de un puente? Efectivamente, en ambas actividades se parte de unos requerimientos que deben quedar reflejados en una especificación y posteriormente en la materialización final del producto. Pero, parece evidente, incluso no deseable, que un producto software no sea algo inmutable y permanente como lo es un puente, ni tampoco lo sea por tanto su especificación o diseño. Más aún, cuando se trata de software, resulta francamente complicado explicar a los usuarios finales que los requisitos no se puedan cambiar una vez comenzada la construcción. Cualquier intento en ese sentido siempre tiene como resultado a un usuario que nos pregunta con manifiesta incredulidad: “¿me estás diciendo que es imposible añadir un botón más al formulario?”.
Palabras en un papel
A finales del pasado año se inauguró el Puente de la Constitución en Venecia, obra del arquitecto español Santiago Calatrava. Lamentablemente, y sin entrar a valorar artísticamente la obra, la críticas e insatisfacción generalizada por el resultado provocaron que la inauguración se desarrollara en la más absoluta indiferencia. En este caso, al menos para una mayoría de los venecianos, el resultado no satisfizo para nada las expectativas. Es más, se cometieron errores de bulto en el diseño (o quizá en la toma de requerimientos) al no proyectar un acceso para minusválidos. No obstante, el puente sigue en pie, y después de 11,2 millones de euros gastados (4 más de los presupuestados) ningún ciudadano sensato, o al menos que pague sus impuestos, plantearía la demolición o modificación sustancial del mismo.
Lo anterior no pretende ni mucho menos demostrar que ninguna ingeniería o proceso de construcción escapa a los errores o a la comentada ineficiencia. No se trata de establecer comparaciones peyorativas sino de entender la naturaleza distinta que se sustancia en el software a diferencia de otras disciplinas: la adaptabilidad. Si nos limitamos a pensar tan sólo en los costes asociados al material empleado en la construcción del puente de Calatrava, es fácil estar de acuerdo en que un diseño previo absolutamente cerrado es un requisito indispensable previo a la construcción. Sin embargo, el software está “hecho de” código, o sea, es en sí mismo una especificación, un diseño, “palabras en un papel”.
Así como los venecianos entienden que dadas las circunstancias tendrán que vivir con este “Puente de la Constitución”, los usuarios de una aplicación no podrán entender jamás cómo no es posible modificar, evolucionar o adaptar el sistema software que necesitan para su trabajo. En resumen, el usuario visualiza el software como, literalmente, algo “blando” y adaptable completamente a sus necesidades.
Bibliotecas de conocimiento
¿Significa ésto que no es posible una industria del software al igual que existe para las ingenierías clásicas? En mi opinión, no sólo es posible sino que es absolutamente necesaria a tenor de los cifras citadas al comienzo de este artículo. Lo discutible en este caso es qué modelo de industrialización resulta apropiado dada la naturaleza particular no rígida del software.
Las metodologías clásicas de software, llamadas “pesadas”, se han aproximado al problema de la industrialización fundamentalmente en términos tayloristas. Básicamente, el proceso de desarrollo se ha dividido en tareas llamadas de valor, el análisis o el diseño, y tareas de bajo nivel como la codificación, asimilando ésta última con las tareas repetitivas ejecutadas en una típica cadena de montaje. El límite de esta tendencia estaría representado por las arquitecturas guiadas por el modelo como MDA para las que el código se genera de forma semi-automática a partir de modelos especificados en UML.
Frente al modelo clásico, se está desarrollando otro enfoque, en el contexto de las llamadas metodologías ágiles, inspirado libremente en el Sistema de Producción de Toyota, en el que priman valores como el conocimiento y la responsabilidad compartidos, la adaptabilidad y la mejora continua. Es verdad que algunas metodologías clásicas como El Proceso Unificado prevén el cambio en los distintos procesos de gestión, pero habitualmente conllevan una carga documental tan enorme que se produce una natural reticencia a acometerlos. Bajo el punto de vista “agile”, el proceso de codificación es en sí mismo una actividad de diseño que demanda habilidad y creatividad, y las actividades pesadas, propias de una “cadena de montaje”, son ejecutadas con herramientas de construcción, compiladores o IDEs.
Por otro lado, la “agilidad” no es sólo aplicable a proyectos de tamaño reducido. Es posible aplicar este enfoque también en factorías de software, donde el objetivo no sea tanto el “montaje” de piezas prefabricadas, sino la construcción a partir de arquetipos que resuelvan ciertos problemas tipo y sirvan como bibliotecas de conocimiento y de buenas prácticas. En este sentido estaríamos hablando de la aplicación de economías de gama en oposición a las mencionadas de escala.
Conclusión
Curiosamente, la queja más repetida entre los desarrolladores que codifican bajo supuestos tayloristas es la de que los usuarios no saben lo que quieren o que no piensan en los requisitos antes de demandarlos, ni tampoco evalúan el impacto que suponen los cambios. Por el contrario, la de los usuarios de negocio va en el sentido contrario, poniendo de manifiesto la rigidez y las barreras que encuentran a la hora de gestionar el cambio en los sistemas software. En beneficio del entendimiento entre los distintos implicados, resulta indispensable resolver esta paradoja de la única manera posible, reconociendo la propia naturaleza flexible del software e incorporándola a los procesos de desarrollo definidos en las organizaciones.