README – cómo saber

Los archivos README tienen una larga tradición en los proyectos de software. Originalmente, estos archivos de texto sin formato contenían información sobre la licencia e instrucciones sobre cómo compilar el artefacto correspondiente a partir del código fuente o notas importantes sobre la instalación del programa. No existe ningún estándar real sobre cómo construir un archivo README de este tipo.

Desde que GitHub (adquirida por Microsoft en 2018) inició su marcha triunfal como plataforma de alojamiento de código libre para proyectos de código abierto, existe desde bastante pronto la función de mostrar el archivo README como página de inicio del repositorio. Todo lo que se necesita es crear un simple archivo de texto llamado README.md en el directorio raíz del repositorio.

Para poder estructurar los archivos README de forma más clara, se buscó una posibilidad de formato simple. Rápidamente se eligió la notación markdown porque es fácil de usar y se puede renderizar de forma bastante eficiente. Esto facilita la lectura de las páginas de resumen y permite utilizarlas como documentación del proyecto.

Es posible enlazar varios archivos markdown como documentación del proyecto. Así se crea una especie de mini WIKI que se incluye en el proyecto y también se versiona a través de Git.

El asunto tuvo tanto éxito que soluciones de autoalojamiento como GitLab o la comercial BitBucket también han adoptado esta función.

Ahora, sin embargo, se plantea la cuestión de qué contenido es mejor escribir en un archivo README de este tipo para que también represente un verdadero valor añadido para los forasteros. Con el paso del tiempo, se han establecido los siguientes puntos:

  • Breve descripción del proyecto
  • Condiciones de uso del código fuente (licencia)
  • Cómo utilizar el proyecto (por ejemplo, instrucciones para compilar o cómo integrar la biblioteca en proyectos propios)
  • Quiénes son los autores del proyecto y cómo se puede contactar con ellos
  • Qué hacer si desea apoyar el proyecto

Mientras tanto, las llamadas insignias (pegatinas) se han hecho muy populares. A menudo hacen referencia a servicios externos, como el servidor gratuito de integración continua TravisCI. Ayudan a evaluar la calidad del proyecto.

También hay varias plantillas para archivos README en GitHub. Sin embargo, tienes que fijarte en las circunstancias reales de tu propio proyecto y juzgar qué información es realmente relevante para los usuarios. Estas plantillas ayudan mucho a averiguar si se ha pasado por alto algún punto.

El hecho de que prácticamente todos los fabricantes de soluciones de servidores de gestión de control de código fuente hayan integrado ya la función de mostrar el archivo README.md como página de inicio del proyecto para el repositorio de código significa que un README.me también es algo útil para los proyectos comerciales.

Aunque la sintaxis para markdown es fácil de aprender, puede ser más conveniente utilizar directamente un editor MARKDOWN para la edición extensiva de este tipo de archivos. Debes asegurarte de que la vista previa también se muestra correctamente y no se ofrece un simple resaltado de sintaxis.

Los enlaces sólo son visibles para los usuarios registrados.

Los enlaces sólo son visibles para los usuarios registrados.

Anti-Pattern de números de versión

publicado también en inglés en DZone 04.2020

Después de que la banda de los cuatro (GOF) Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides publicaran el libro Design Patterns: Elements of Reusable Object-Oriented Software, aprender a describir problemas y soluciones se hizo popular en casi todos los campos del desarrollo de software. Del mismo modo, aprender a describir lo que no se debe hacer y los antipatrones se hizo igualmente popular.

En las publicaciones que trataban estos conceptos, encontramos recomendaciones útiles para el diseño de software, la gestión de proyectos, la gestión de la configuración y mucho más. En este artículo, compartiré mi experiencia con los números de versión para artefactos de software.

La mayoría de nosotros ya estamos familiarizados con un método llamado versionado semántico, un conjunto de reglas potentes y fáciles de aprender sobre cómo deben estructurarse los números de versión y cómo deben aumentar los segmentos.

Ejemplo de numeración de versiones:

  • Mayor: Cambios incompatibles en la API.
  • Menor: Añade nuevas funcionalidades.
  • Patch: Corrección de errores y correcciones.
  • Label: SNAPSHOT que marca el estado “en desarrollo”.

Un cambio de API incompatible se produce cuando se elimina o cambia el nombre de una función o clase accesible desde el exterior. Otra posibilidad es un cambio en la firma de un método. Esto significa que el valor de retorno o los parámetros se han modificado con respecto a su implementación original. En estos escenarios, es necesario aumentar el segmento Mayor del número de versión. Estos cambios suponen un alto riesgo para los consumidores de la API porque tienen que adaptar su propio código.

Cuando se trata de números de versión, también es importante saber que 1.0.0 y 1.0 son iguales. Esto tiene efecto en el requisito de que las versiones de una versión de software tienen que ser únicas. Si no, es imposible distinguir entre artefactos. En mi experiencia profesional, he participado varias veces en proyectos en los que no había procesos bien definidos para crear números de versión. El efecto de estas circunstancias era que el equipo tenía que asegurar la calidad del artefacto y se confundía con qué versión del artefacto estaba tratando en ese momento.

El mayor error que he visto es el almacenamiento de la versión de un artefacto en una base de datos junto con otras entradas de configuración. El procedimiento correcto debería ser: colocar la versión dentro del artefacto de forma que nadie después de una liberación pueda cambiarla desde fuera. La trampa en la que podrías caer es el proceso de cómo actualizar la versión después de un lanzamiento o instalación.

Puede que tenga una lista de comprobación para todas las actividades manuales durante una publicación. Pero, ¿qué sucede después de que una versión se instala en una etapa de prueba y por alguna razón otra versión de la aplicación tiene que ser instalada. ¿Todavía tiene que cambiar manualmente el número de versión? ¿Cómo averiguar qué versión está instalada o cuándo la información de la base de datos es incorrecta?

Detectar la versión correcta en esta situación es un reto muy difícil. Por esa razón, tenemos el requisito de mantener la versión dentro de la aplicación. En el próximo paso, discutiremos una forma segura y simple de resolver este problema de forma automática.

Nuestra precondición es una simple construcción de una librería Java con Maven. Por defecto, el número de versión del artefacto está escrito en el POM. Después del proceso de construcción, nuestro artefacto es creado y nombrado como: artefacto-1.0.jar o similar. Mientras no renombremos el artefacto, tendremos una forma adecuada de distinguir las versiones. Incluso después de un renombrado con un simple truco de empaquetado y comprobación, entonces, en la carpeta META-INF, somos capaces de encontrar el valor correcto.

Si usted tiene la Versión hardcoded en una propiedad o archivo de clase, también funcionaría bien, siempre y cuando no se olvide de actualizar siempre. Tal vez la ramificación y la fusión en los sistemas SCM como Git podría necesitar su atención especial para tener siempre la versión correcta en su código base.

Otra solución es utilizar Maven y el mecanismo de colocación de tokens. Antes de que corras a probarlo en tu IDE, ten en cuenta que Maven utiliza dos carpetas diferentes: sources y resources. La sustitución de tokens en sources no funcionará correctamente. Después de una primera ejecución, tu variable es reemplazada por un número fijo y desaparece. Una segunda ejecución fallará. Para preparar tu código para el reemplazo de tokens, necesitas configurar Maven como primero en el ciclo de vida de construcción:

<build>
   <resources>
      <resource>
         <directory>src/main/resources/</directory>
         <filtering>true</filtering>
      </resource>
   </resources>
   <testResources>
      <testResource>
         <directory>src/test/resources/</directory>
         <filtering>true</filtering>
      </testResource>
   </testResources>
</build>
XML

Después de este paso, necesita conocer la propiedad ${project.version} del POM. Esto le permite crear un archivo con el nombre version.property en el directorio resources. El contenido de este archivo es sólo una línea: version=${project.version}. Después de una compilación, encontrará en su artefacto la version.property con el mismo número de versión que utilizó en su POM. Ahora, usted puede escribir una función para leer el archivo y utilizar esta propiedad. Podrías almacenar el resultado en una constante para usarla en tu programa. ¡Eso es todo lo que tienes que hacer!

Ejemplo: https://github.com/ElmarDott/TP-CORE/blob/master/src/main/java/org/europa/together/utils/Constraints.java

Un tonto con una herramienta sigue siendo un tonto

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 Deutsch

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.

Figura 1: Resolución de problemas – “A bisserl was geht immer”, Monaco Franze

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.

Figura 2: Cobertura de las pruebas con Cobertura

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.

Figura 3: Plugin Maven JDepend – números con poco significado

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

Referencias

Los enlaces sólo son visibles para los usuarios registrados.

Así es como el conocimiento empresarial se hace tangible

La experiencia de sus propios empleados es un factor económico importante para cualquier organización. Por eso es tan importante almacenar permanentemente la experiencia y los conocimientos y ponerlos a disposición de los demás empleados. Un servidor central de gestión del conocimiento se encarga de esta tarea y contribuye a garantizar la productividad de la empresa a largo plazo.

(c) 2011 Marco Schulz, Materna Monitor, Ausgabe 2, S.32-33
Artículo original traducido del Deutsch

La complejidad del actual mundo laboral, altamente interconectado, requiere la interacción fluida de una gran variedad de especialistas. La transferencia de conocimientos desempeña aquí un papel importante. Este intercambio se hace más difícil cuando los miembros del equipo trabajan en distintos lugares con diferentes husos horarios o proceden de entornos culturales diferentes. Las empresas con sedes en todo el mundo conocen este problema y han desarrollado estrategias adecuadas para la gestión del conocimiento en toda la empresa. Para introducirla con éxito, la solución informática que se utilice debe considerarse como una metodología en lugar de centrarse en la herramienta en sí. Una vez tomada la decisión por una determinada solución informática, debe mantenerse de forma coherente. Los cambios frecuentes de sistema reducen la calidad de los vínculos entre los contenidos almacenados. Al no existir una norma normalizada para la representación de los conocimientos, pueden producirse importantes pérdidas de conversión al cambiar a nuevas soluciones informáticas.

Diferentes mecanismos para diferentes contenidos

La información puede almacenarse en los sistemas informáticos de diversas formas. Las distintas formas de representación difieren en su presentación, estructuración y uso. Para poder editar documentos sin conflictos y versionarlos al mismo tiempo, como es necesario para las especificaciones o la documentación, las wikis [1] son ideales, ya que se desarrollaron originalmente precisamente para este uso. Los documentos que allí se almacenan suelen ser específicos de cada proyecto y también deben organizarse de esta manera.

Los documentos transversales de la wiki son, por ejemplo, explicaciones de términos técnicos, una lista central de abreviaturas o un Quién es quién de los empleados de la empresa con datos de contacto y áreas temáticas. Estos últimos, a su vez, pueden enlazarse con la explicación del término técnico. De este modo, el contenido completo puede mantenerse actualizado de forma centralizada y vincularse cómodamente a los documentos de proyecto correspondientes. Este procedimiento evita repeticiones innecesarias y los documentos que hay que leer se hacen más cortos, pero siguen conteniendo toda la información necesaria. Johannes Siedersleben ya describió los riesgos de una documentación demasiado larga en su libro Softwaretechnik [2] en 2003.

Los conocimientos que tienen más carácter de FAQ se organizan mejor a través de un foro. La agrupación por temas, en los que se depositan preguntas del tipo “¿Cómo puedo…?”, facilita la búsqueda de posibles soluciones. Especialmente atractivo es el hecho de que un foro de este tipo evoluciona con el tiempo en función de la demanda. Los usuarios pueden formular sus propias preguntas y publicarlas en el foro. Por regla general, las respuestas cualificadas a las nuevas preguntas no tardan en llegar.

Los candidatos idóneos para los blogs son, por ejemplo, información general sobre la empresa, informes de situación o tutoriales. Se trata de documentos que tienen más carácter informativo, no están ligados a un formulario o son difíciles de asignar a un tema concreto. Las informaciones breves (tweets [3]) a través de Twitter, agrupadas temáticamente en canales, también pueden enriquecer el trabajo de los proyectos. Además, minimizan el número de correos electrónicos en la propia bandeja de entrada. Algunos ejemplos son recordatorios sobre un evento determinado, una noticia sobre nuevas versiones de un producto o información sobre un proceso de trabajo finalizado con éxito. La integración de los tweets en el trabajo de un proyecto es relativamente nueva y, por tanto, las soluciones de software adecuadas son escasas.

Por supuesto, la lista de posibilidades está lejos de agotarse en este punto. Sin embargo, los ejemplos ya ofrecen una buena visión de cómo las empresas pueden organizar sus conocimientos. Conectando los sistemas individuales a un portal [4] que disponga de una búsqueda global y una administración de usuarios, se crea rápidamente una red que también es adecuada como solución en la nube.

La facilidad de uso es un factor decisivo para la aceptación de una plataforma de conocimiento. Largos periodos de formación, una estructuración poco clara y un manejo engorroso pueden provocar rápidamente el rechazo. Con la autorización de acceso a los contenidos individuales a nivel de grupo, también se satisface la seguridad. Un buen ejemplo de ello es la wiki empresarial Confluence [5]. Permite asignar diferentes permisos de lectura y escritura a los niveles de documentos individuales.

Naturalmente, no se puede esperar que un desarrollador describa su trabajo con las palabras adecuadas para la posteridad después de haberlo aplicado con éxito. El hecho de que la calidad de los textos de muchas documentaciones no siempre es suficiente también ha sido reconocido por la Universidad de Ciencias Aplicadas de Merseburg, que ofrece el curso Edición técnica [6]. Por ello, la lectura cruzada por parte de otros miembros del proyecto ha demostrado ser un medio adecuado para garantizar la calidad del contenido. Para facilitar la redacción de los textos, resulta útil disponer de una pequeña guía, similar a la Convención de Codificación.

Conclusión

Una base de datos de conocimientos no puede implantarse de la noche a la mañana. Se necesita tiempo hasta que se ha recopilado suficiente información. Sólo mediante la interacción y la corrección de pasajes incomprensibles el conocimiento alcanza una calidad que invita a la transferencia. Hay que animar a cada empleado a enriquecer los textos existentes con nuevos conocimientos, a resolver pasajes incomprensibles o a añadir términos de búsqueda. Si el proceso de creación y distribución de conocimientos se vive de esta manera, quedarán menos documentos huérfanos y la información estará siempre actualizada.

Opciones de automatización en la gestión de la configuración del software

El desarrollo de software ofrece algunas formas extremadamente eficaces de simplificar tareas recurrentes mediante la automatización. La eliminación de tareas tediosas, repetitivas y monótonas y la consiguiente reducción de la frecuencia de errores en el proceso de desarrollo no son, ni mucho menos, todas las facetas de este tema.

(c) 2011 Marco Schulz, Materna Monitor, Ausgabe 1, S.32-34
Artículo original traducido del Deutsch

La motivación para establecer automatismos en el panorama informático es en gran medida la misma. Las tareas recurrentes deben simplificarse y ser resueltas por máquinas sin intervención humana. Las ventajas son menos errores en el uso de los sistemas informáticos, lo que a su vez reduce los costes. Por sencilla y ventajosa que parezca la idea de que los procesos se ejecuten de forma independiente, la puesta en práctica no es tan trivial. Rápidamente se hace evidente que para cada posibilidad de automatización identificada, la implantación no siempre es factible. Aquí también se aplica el principio: cuanto más complejo es un problema, más difícil es resolverlo.

Para sopesar si merece la pena el esfuerzo económico que supone introducir determinados automatismos, hay que multiplicar los costes de una solución manual por el factor de la frecuencia con que hay que repetir este trabajo. Estos costes deben compararse con los gastos de desarrollo y funcionamiento de la solución automatizada. Sobre la base de esta comparación, rápidamente queda claro si una empresa debe aplicar la mejora prevista.

Herramientas de apoyo al proceso de desarrollo

Especialmente en el desarrollo de proyectos de software, existe un considerable potencial de optimización mediante procesos automáticos. Los desarrolladores cuentan con el apoyo de multitud de herramientas que deben ser hábilmente orquestadas. La gestión de configuraciones y versiones, en particular, trata con gran detalle el uso práctico de una amplia variedad de herramientas para automatizar el proceso de desarrollo de software.

La existencia de una lógica de compilación independiente, por ejemplo en forma de un simple script de shell, ya es un buen enfoque, pero no siempre conduce a los resultados deseados. En estos casos, son necesarias soluciones independientes de la plataforma, ya que es muy probable que el desarrollo tenga lugar en un entorno heterogéneo. Una solución aislada siempre supone un mayor esfuerzo de adaptación y mantenimiento. Por último, los esfuerzos de automatización deben simplificar los procesos existentes. Las herramientas de compilación actuales, como Maven y Ant, aprovechan esta ventaja de la independencia de la plataforma. Ambas herramientas encapsulan toda la lógica de compilación en archivos XML independientes. Dado que XML ya se ha establecido como estándar en el desarrollo de software, la curva de aprendizaje es más pronunciada que con las soluciones rudimentarias.

El uso de lógicas de compilación centrales constituye la base de otros automatismos durante el trabajo de desarrollo. Las pruebas automatizadas en forma de pruebas unitarias en un entorno de integración continua (IC) son un aspecto de ello. Una solución CI combina todas las partes de un software en un todo y procesa todos los casos de prueba definidos. Si el software no se ha podido construir o una prueba ha fallado, se avisa al desarrollador por correo electrónico para que corrija rápidamente el error. Los servidores CI modernos se configuran con un sistema de gestión de versiones, como Subversion o Git. Esto hace que el servidor inicie una compilación sólo cuando se han realizado realmente cambios en el código fuente.

Los sistemas de software complejos suelen depender de componentes externos (bibliotecas) en los que no puede influir el propio proyecto. La gestión eficaz de los artefactos utilizados en el proyecto es el principal punto fuerte de la herramienta de compilación Maven, lo que ha contribuido a su uso generalizado. Cuando se utiliza correctamente, elimina la necesidad de archivar las partes binarias del programa dentro de la gestión de versiones, lo que se traduce en repositorios más pequeños y tiempos de commit (finalización con éxito de una transacción) más cortos. Las nuevas versiones de las bibliotecas utilizadas pueden integrarse y probarse más rápidamente sin necesidad de realizar copias manuales propensas a errores. Las bibliotecas desarrolladas internamente pueden distribuirse fácilmente de forma protegida en la red de la empresa con el uso de un servidor de repositorios independiente (Apache Nexus) en el sentido de la reutilización.

Al evaluar una herramienta de compilación, no hay que descuidar la posibilidad de elaborar informes. El seguimiento automatizado de la calidad del código mediante métricas, por ejemplo a través de la herramienta Checkstyle, es un excelente instrumento para que la dirección del proyecto evalúe de forma realista el estado actual del proyecto.

No demasiadas nuevas tecnologías

Con todas las posibilidades de automatización de procesos, se pueden tomar varios caminos. No es raro que los equipos de desarrollo mantengan largas discusiones sobre qué herramienta es la más adecuada para el proyecto en curso. Esta pregunta es difícil de responder en términos generales, ya que cada proyecto es único y hay que comparar las ventajas e inconvenientes de las distintas herramientas con los requisitos del proyecto.

En la práctica, la limitación a un máximo de dos tecnologías novedosas en el proyecto ha demostrado su eficacia. La idoneidad de una herramienta también depende de si en la empresa hay personas con los conocimientos adecuados. Una buena solución es una lista publicada por la dirección con recomendaciones de las herramientas utilizadas que ya están en uso o pueden integrarse en el paisaje de sistemas existente. Así se garantiza que las herramientas utilizadas sigan siendo claras y manejables.

Los proyectos que se prolongan durante muchos años deben someterse a una modernización de las tecnologías utilizadas a intervalos más amplios. En este contexto, hay que encontrar momentos adecuados para migrar a la nueva tecnología con el menor esfuerzo posible. Fechas sensatas para pasar a una tecnología más reciente son, por ejemplo, el cambio a una nueva versión principal del propio proyecto. Este procedimiento permite una separación limpia sin tener que migrar los antiguos estados del proyecto a la nueva tecnología. En muchos casos, esto no es tan fácil de hacer.

Conclusión

El uso de automatismos para el desarrollo de software puede, si se emplea con sensatez, contribuir enérgicamente a la consecución del objetivo del proyecto. Como todas las cosas, un uso excesivo conlleva algunos riesgos. La infraestructura utilizada debe seguir siendo comprensible y controlable a pesar de toda la mecanización, para que el trabajo del proyecto no se paralice en caso de fallos del sistema.