traducido por I. A.
Aunque en los últimos años se ha dedicado un esfuerzo adicional considerable a las pruebas para mejorar la calidad de los proyectos de software [1], el camino hacia el éxito repetible de forma continua no es una cuestión de rutina. Una gestión rigurosa y específica de todos los recursos disponibles era y sigue siendo indispensable para lograr un éxito reproducible.
(c) 2016 Marco Schulz, Java aktuell Ausgabe 4, S.14-19
– Artículo original traducido del 
No es ningún secreto que muchos proyectos informáticos siguen teniendo sus dificultades para llegar a buen puerto. Se podría pensar que las numerosas herramientas y métodos nuevos que han surgido en los últimos años ofrecen soluciones eficaces a la situación. Sin embargo, si se echa un vistazo a los proyectos actuales, esta impresión cambia.
El autor ha podido observar a menudo cómo se pretendía dominar este problema introduciendo nuevas herramientas. No pocas veces, los esfuerzos acabaron en resignación. La supuesta solución milagrosa se convertía rápidamente en un pesado ladrón de tiempo con una enorme carga de autogestión. La euforia inicial de todos los implicados se convertía rápidamente en rechazo y no pocas veces culminaba en un boicot a su uso. Así pues, no es de extrañar que los empleados experimentados se muestren escépticos ante todos los esfuerzos de cambio durante mucho tiempo y sólo se ocupen de ellos cuando son previsiblemente exitosos. Debido a este hecho, el autor ha elegido la provocativa cita de Grady Booch, cofundador de UML, como título de este artículo.
Las empresas suelen dedicar muy poco tiempo a establecer una infraestructura interna equilibrada. Incluso el mantenimiento de los fragmentos existentes suele posponerse por diversas razones. A nivel de gestión, prefieren basarse en las tendencias del momento para ganarse a los clientes, que esperan una lista de palabras de moda como respuesta a su solicitud de propuestas. Sin embargo, Tom De Marco ya lo describió con detalle en los años setenta [2]: Las personas hacen los proyectos (véase la Figura 1).
Hacemos lo que podemos, pero ¿podemos hacer algo?
A pesar de las mejores intenciones y los intensos esfuerzos, los proyectos que llegan a buen puerto no son, por desgracia, la norma. Pero, ¿cuándo se puede hablar de un proyecto fracasado en el desarrollo de software? El abandono de todas las actividades por falta de perspectivas de éxito es, por supuesto, un motivo obvio, pero en este contexto es bastante raro. Más bien, uno se da cuenta de ello durante la revisión posterior al proyecto de las tareas completadas. En el controlling, por ejemplo, los puntos débiles salen a la luz al determinar la rentabilidad.
Los motivos de los resultados negativos suelen ser la superación del presupuesto estimado o de la fecha de finalización acordada. Normalmente se dan ambas condiciones al mismo tiempo, ya que el plazo de entrega en peligro se contrarresta aumentando el personal. Esta práctica alcanza rápidamente sus límites, ya que los nuevos miembros del equipo requieren un periodo de inducción, lo que reduce visiblemente la productividad del equipo existente. Las arquitecturas fáciles de usar y un alto grado de automatización mitigan un poco este efecto. De vez en cuando, también se pasa a sustituir al contratista con la esperanza de que las nuevas escobas barran mejor.
Un rápido vistazo a la lista de los 3 grandes proyectos fracasados en Alemania muestra cómo la falta de comunicación, una planificación inadecuada y una gestión deficiente repercuten negativamente en la percepción externa de los proyectos: Aeropuerto de Berlín, Sala Filarmónica del Elba de Hamburgo y Stuttgart 21. Gracias a la amplia cobertura mediática, estas empresas son suficientemente conocidas y no es necesario explicarlas en detalle. Aunque los ejemplos citados no procedan de la informática, también aquí pueden encontrarse las razones recurrentes del fracaso debido a la explosión de los costes y los retrasos.
La voluntad de crear algo grande e importante no basta por sí sola. Los responsables también necesitan las habilidades profesionales, de planificación, sociales y de comunicación necesarias, junto con la autoridad para actuar. Construir castillos en el aire y esperar a que los sueños se hagan realidad no produce resultados presentables.
Los grandes éxitos suelen lograrse cuando el menor número posible de personas tiene derecho a vetar decisiones. Esto no significa que haya que ignorar los consejos, pero no se pueden tener en cuenta todos los estados de ánimo posibles. Tanto más importante es que el responsable del proyecto tenga autoridad para hacer cumplir su decisión, pero no lo demuestre con toda la fuerza.
Es perfectamente normal que el responsable de la decisión no controle todos los detalles. Al fin y al cabo, delega la ejecución en los especialistas adecuados. He aquí un breve ejemplo: cuando a principios de la década de 2000 las posibilidades de crear aplicaciones web más grandes y complejas eran cada vez mejores, en las reuniones surgía a menudo la pregunta de qué paradigma debía utilizarse para implementar la lógica de visualización. Los términos “multinivel”, “cliente ligero” y “cliente pesado” dominaban los debates de los órganos decisorios de la época. Explicar al cliente las ventajas de las distintas capas de una aplicación web distribuida era una cosa. Pero dejar en manos de un profano en la materia la decisión de cómo quiere acceder a su nueva aplicación -a través del navegador (“thin client”) o de su propia interfaz gráfica de usuario (“fat client”)- es sencillamente una tontería. Así que en muchos casos fue necesario aclarar los malentendidos que surgieron durante el desarrollo. La solución del navegador gordo no pocas veces resultó ser una tecnología difícil de dominar, ya que los fabricantes rara vez se preocupaban por los estándares. En cambio, uno de los principales requisitos solía ser que la aplicación tuviera un aspecto casi idéntico en los navegadores más populares. Sin embargo, esto sólo podía conseguirse con un considerable esfuerzo adicional. Algo parecido pudo observarse durante el primer auge de las arquitecturas orientadas a servicios.
La consecuencia de estas observaciones demuestra que es indispensable elaborar una visión antes de iniciar el proyecto, cuyos objetivos se correspondan también con el presupuesto estimado. Una versión de lujo reutilizable con tantos grados de libertad como sea posible requiere un enfoque diferente al de una solución “conseguimos lo que necesitamos”. Es menos importante perderse en los detalles y más importante tener en mente la visión de conjunto.
Especialmente en los países de habla alemana, a las empresas les resulta difícil encontrar a los agentes necesarios para llevar a cabo con éxito un proyecto. Las razones pueden ser muy diversas y podrían ser, entre otras, que las empresas aún no han comprendido que los expertos rara vez quieren hablar con proveedores de servicios de contratación mal informados e insuficientemente preparados.
Hacer las cosas!
El éxito en la gestión de proyectos no es una casualidad. Durante mucho tiempo se ha señalado como una de las causas negativas el flujo insuficiente de información debido a la falta de comunicación. Muchos proyectos tienen su propio carácter inherente, que también está conformado por el equipo que acepta el reto para dominar conjuntamente la tarea fijada. Métodos ágiles como Scrum [3], Prince2 [4] o Kanban [5] recogen esta percepción y ofrecen soluciones potenciales para llevar a cabo con éxito proyectos de TI.
En ocasiones, sin embargo, se observa cómo los directores de proyecto transfieren las tareas de planificación a los desarrolladores responsables para su autogestión con el pretexto de los métodos ágiles recién introducidos. El autor ha experimentado a menudo cómo los arquitectos se han visto más implicados en el trabajo cotidiano de implementación en lugar de comprobar que los fragmentos entregados cumplen las normas. De este modo, la calidad no puede establecerse a largo plazo, ya que los resultados se limitan a representar soluciones que garantizan la funcionalidad y, debido a las presiones de tiempo y costes, no establecen las estructuras necesarias para garantizar la mantenibilidad futura. Ágil no es sinónimo de anarquía. A esta configuración le gusta adornarse con una caja de herramientas sobrecargada y llena de herramientas del departamento de DevOps y ya el proyecto parece insumergible. ¡Como el Titanic!
No en vano, desde hace años se recomienda introducir un máximo de tres nuevas tecnologías al inicio de un proyecto. En este contexto, tampoco es aconsejable apostar siempre por las últimas tendencias. A la hora de decidirse por una tecnología, primero hay que crear los recursos adecuados en la empresa, para lo que hay que prever tiempo suficiente. Las inversiones sólo resultan beneficiosas si la elección realizada va más allá de una simple exageración. Un buen indicador de coherencia es una amplia documentación y una comunidad activa. Estos secretos a voces llevan años debatiéndose en la bibliografía pertinente.
Sin embargo, ¿cómo se procede cuando un proyecto lleva establecido muchos años, pero en términos del ciclo de vida del producto se hace inevitable un giro hacia nuevas técnicas? Las razones de tal esfuerzo pueden ser muchas y varían de una empresa a otra. La necesidad de no perderse innovaciones importantes para seguir siendo competitivos no debe retrasarse demasiado. Esta consideración conduce a una estrategia bastante sencilla de aplicar. Las versiones actuales se mantienen en la tradición probada y sólo para la próxima versión importante o la siguiente se elabora una hoja de ruta que contenga todos los puntos necesarios para llevar a cabo un cambio con éxito. Para ello, se trabajan los puntos críticos y se realizan pequeños estudios de viabilidad, algo más exigentes que un tutorial de “hola mundo”, para ver cómo podría tener éxito una implantación. Por experiencia, son los pequeños detalles los que pueden ser las migajas en la balanza que determinen el éxito o el fracaso.
En todos los esfuerzos, el objetivo es alcanzar un alto grado de automatización. Frente a las tareas que se repiten constantemente y deben realizarse manualmente, la automatización ofrece la posibilidad de producir resultados repetibles de forma continua. Sin embargo, está en la naturaleza de las cosas que las actividades sencillas sean más fáciles de automatizar que los procesos complejos. Aquí es importante comprobar de antemano la viabilidad económica de los planes, para que los desarrolladores no den rienda suelta a su impulso natural de jugar y además trabajen en actividades cotidianas desagradables.
El que escribe, se queda
La documentación, tema controvertido, abarca todas las fases del proceso de desarrollo de software. Ya se trate de descripciones de API, del manual de usuario, de documentos de planificación de la arquitectura o de conocimientos adquiridos sobre procedimientos óptimos, describir no es una de las tareas preferidas de todos los protagonistas implicados. A menudo se observa que parece prevalecer la opinión común de que los manuales gruesos son sinónimo de funcionalidad extensa del producto. Sin embargo, los textos largos en una documentación son más bien una falta de calidad que agota la paciencia del lector porque espera instrucciones precisas que vayan al grano. En lugar de ello, recibe frases insulsas con ejemplos triviales que rara vez resuelven problemas.
Esta idea también puede aplicarse a la documentación de proyectos y ha sido presentada en detalle por Johannes Sidersleben [6], entre otros, bajo la metáfora sobre las novelas victorianas. Las universidades ya han hecho suyas estas conclusiones. La Universidad de Ciencias Aplicadas de Merseburg, por ejemplo, ha creado el programa de grado “Edición técnica” [7]. Es de esperar que en el futuro se encuentren más graduados de esta carrera en el panorama de los proyectos.
A la hora de seleccionar herramientas de colaboración como repositorios de conocimiento, siempre hay que tener en cuenta el panorama general. El éxito de la gestión del conocimiento puede medirse por la eficacia con la que un empleado encuentra la información que busca. Por este motivo, su uso en toda la empresa es una decisión de la dirección y obligatorio para todos los departamentos.
La información tiene una naturaleza diferente y varía tanto en su alcance como en el tiempo que permanece actualizada. Esto da lugar a diferentes formas de presentación como wiki, blog, sistema de tickets, tweets, foros o podcasts, por citar sólo algunas. Los foros representan de forma muy óptima el problema de preguntas y respuestas. Un wiki es ideal para el texto continuo, como ocurre en la documentación y las descripciones. Muchos webcasts se ofrecen como vídeos sin que la presentación visual añada ningún valor. En la mayoría de los casos, una pista de audio bien comprensible y correctamente producida es suficiente para distribuir conocimientos. Con una base de datos común y normalizada, los proyectos terminados pueden compararse eficazmente entre sí. Las conclusiones resultantes ofrecen un gran valor añadido en la elaboración de previsiones para futuros proyectos.
Pruebas y métricas: la medida de todas las cosas
Basta con hojear el Informe de Calidad 2014 para darse cuenta rápidamente de que la nueva tendencia son las “pruebas de software”. Las empresas ponen cada vez más contingentes a disposición para ello, que ocupan un volumen similar a los gastos de ejecución del proyecto. En rigor, en este punto uno apaga el fuego con gasolina. Bien mirado, el presupuesto ya se duplica en la fase de planificación. A menudo depende de la habilidad del gestor del proyecto encontrar una declaración adecuada para los fondos destinados al proyecto.
Sólo su comprobación coherente de la cobertura de los casos de prueba con herramientas de análisis adecuadas garantiza que al final se hayan realizado pruebas suficientes. Aunque cueste creerlo: en una época en la que las pruebas de software pueden crearse con más facilidad que nunca y en la que pueden combinarse distintos paradigmas, una cobertura de pruebas amplia y significativa es más bien la excepción (véase la figura 2).
Es bien sabido que no es posible demostrar que el software está libre de errores. Las pruebas sólo sirven para demostrar un comportamiento definido para los escenarios creados. Los casos de prueba automatizados no sustituyen la revisión manual del código por arquitectos experimentados. Un ejemplo sencillo son los bloques “try catch” anidados que aparecen de vez en cuando en Java y que tienen un efecto directo en el flujo del programa. A veces, el anidamiento puede ser intencionado y útil. En este caso, sin embargo, la gestión de errores no se limita a la salida de la traza de la pila en un archivo de registro. La causa de este error de programación radica en la inexperiencia del desarrollador y el mal consejo del IDE en este punto de encerrar la sentencia con su propio bloque “try catch” para una esperada gestión de errores en lugar de complementar la rutina existente con una sentencia “catch” adicional. Intentar detectar este error obvio mediante casos de prueba es un enfoque infantil desde el punto de vista económico.
Los patrones de error típicos pueden detectarse de forma rentable y eficiente mediante procedimientos de prueba estáticos. Las publicaciones que se ocupan especialmente de la calidad y la eficiencia del código en el lenguaje de programación Java [8, 9, 10] son siempre un buen punto de partida para desarrollar estándares propios.
La consideración de los tipos de error también es muy informativa. El seguimiento de incidencias y los mensajes de commit en los sistemas SCM de proyectos de código abierto como Liferay [11] o GeoServer [12] muestran que una gran proporción de errores afectan a la interfaz gráfica de usuario (GUI). A menudo se trata de correcciones de textos de visualización en botones y similares. La notificación de errores de visualización predominantes también puede residir en la percepción de los usuarios. Para ellos, el comportamiento de una aplicación suele ser una caja negra, por lo que tratan el software en consecuencia. No es en absoluto erróneo suponer que la aplicación tiene pocos errores cuando el número de usuarios es elevado.
Las cifras habituales en informática son métricas de software que pueden dar a la dirección una idea del tamaño físico de un proyecto. Utilizada correctamente, una visión de este tipo proporciona argumentos útiles para las decisiones de gestión. Por ejemplo, el número de casos de prueba necesarios puede derivarse de la complejidad cíclica según McCabe [13]. Las estadísticas sobre las líneas de código y los recuentos habituales de paquetes, clases y métodos también muestran el crecimiento de un proyecto y pueden proporcionar información valiosa.
Un tratamiento muy informativo de esta información es el proyecto Code-City [14], que visualiza dicha distribución como un mapa urbano. Es impresionante ver dónde pueden surgir monolitos peligrosos y dónde se producen clases y paquetes huérfanos.
Conclusión
En el día a día, uno se contenta con repartir ajetreo y poner cara de estresado. Al producir innumerables metros de papel, se demuestra posteriormente la productividad personal. La energía así consumida podría emplearse de forma mucho más sensata mediante un planteamiento consecuentemente meditado.
Según el “Sapere Aude” de Kant, hay que fomentar y exigir soluciones sencillas. Los empleados que necesitan estructuras complicadas para destacar su propio genio en el equipo pueden no ser pilares de apoyo sobre los que construir éxitos conjuntos. La cooperación con coetáneos indoctos se reconsidera rápidamente y, si es necesario, se corrige.
Muchos caminos llevan a Roma, y Roma no se construyó en un día. Sin embargo, no se puede negar que en algún momento ha llegado el momento de abrirse camino. La elección de los caminos tampoco es un problema indecidible. Hay caminos seguros y senderos peligrosos en los que incluso los excursionistas experimentados tienen sus dificultades para llegar sanos y salvos a su destino.
Para que la gestión de un proyecto tenga éxito, es esencial conducir el pelotón por terreno sólido y estable. Esto no excluye fundamentalmente las soluciones no convencionales, siempre que sean adecuadas. La afirmación en las instancias decisorias: “Todo lo que dices es correcto, pero en nuestra empresa hay procesos a los que no se puede aplicar tu exposición” se refuta mejor con el argumento: “Eso es totalmente correcto, por lo que ahora nuestra tarea consiste en idear formas de adaptar los procesos de la empresa de acuerdo con los casos de éxito conocidos, en lugar de dedicar nuestro tiempo a enumerar razones para que todo siga igual”. Estoy seguro de que está de acuerdo en que el objetivo de nuestra reunión es resolver problemas, no ignorarlos.” … más voz