Historia de una integración (i): El principio

Esta es la historia de un proyecto de desarrollo software. Como toda buena historia tiene momentos difíciles, personajes complejos, un final féliz y más de una lección que aprender.

Antecedentes

En enero del 2008 comenzó una nueva etapa profesional para mi, cambié de compañía en búsqueda de nuevos retos y proyectos donde trabajar, y continuar aprendiendo, en lo que verdaderamente me apasiona, las nuevas tecnologías de desarrollo software. Atrás dejé una cómoda posición como Analista en una factoria de software al cargo de varios aburridos y antediluvianos proyectos de mantenimiento de una importante TELCO.

Así me encontré al frente de un equipo de desarrollo de 3-6 personas, residente en un importante cliente del sector sanitario público, y dirigiendo un buen número de proyectos Java, consistentes en nuevos desarrollos y mantenimientos.

Pero no sólo yo tenía ganas de cambios para el 2008. En una decisión tan valiente como inesperada, el cliente decide implantar un completo sistema SAP R/3 para sustituir la gran mayoría de sus sistemas de gestión.

Para esta obra faraónica se ha confiado en la típica pirámide de empresas, compuesta por (i) la super multinacional que aporta el nombre, más la élite, (ii) la cárnica el grupo hispano líder que aporta referencias de éxito en proyectos similares más la clase media y (iii) la empresa regional con aspiraciones que aporta el toque local, instalaciones y una masa de programadores a buen precio. Una organización digna de un imperio persa.

El proyecto

Mi parte en la historia sería la de dirigir un proyecto consistente en desarrollar una aplicación web Java que hiciera de front-end para varios módulos del futuro SAP R/3 del cliente. El proyecto empezó oficialmente en junio con la idea de llevarlo de forma paralela a la implantación de SAP. El objetivo era poner en funcionamiento una primera versión para el 1 de enero del 2009 para un número de usuarios controlado y poco a poco ir difundiendo su uso. A día de hoy la aplicación está implantada de forma completa y funcionando estable y eficázmente.

Como os imaginaréis ha sido una experiencia apasionante pero también muy exigente. Aunque me ha hecho pasar más de un trago amargo, en general estoy satisfecho con su resultado final y sobretodo con lo aprendido por el camino. Un camino que intentaré plasmar en esta serie de posts que espero se conviertan en un útil ejercicio de retrospectiva al que estais todos invitados.

Ecosistema software

No quería cerrar el post sin contar algo de verdad. Así que describiré las distintas partes que forman el ecosistema software que he ido construyendo desde mi llegada.

• Eclipse. Una de las primeras decisiones que tomé fue usar Eclipse JEE como ide principal, por su potencia como editor e integración con el resto de herramientas y librerias que usamos. Anteriormente se usaba una antiquísima versión del IntelliJ IDEA pero no entraba en los planes corporativos adquirir licencias más modernas.
• CVS. Es el sistema de control de versiones que tiene implantado nuestro cliente para todos sus proyectos. No hay más. Mi parte aquí se redució a fomentar algunas buenas prácticas de uso, principalmente a incorporar las dependencias de cada proyecto en su estructura.
  
• Tomcat. Las aplicaciones se implantan en un servidor JBoss 3.2.6 y en un 4.2.2 las más recientes, pero en desarrollo usamos un Tomcat 6 como servidor individual por su mayor velocidad de arranque y fácil integración con Eclipse. Nuestras máquinas de desarrollo no son ninguna maravilla y Eclipse no se integra con JBoss 3.2.6 por si solo (sí con el 3.2.3), para ello necesitabamos las JBoss Tools. Pero entonces todo el entorno iba a pedales, cuando con Tomcat 6 vuela.
• ANT. El cambio a Eclipse-Tomcat y el hecho de incoporar las dependencias a la estructura de proyecto obligó a crear nuevos scripts Ant para automatizar las tareas de construcción de los proyectos. Aunque sólo los nuevos proyectos y los antiguos más significativos han sido migrados al nuevo entorno.
  
• Hudson. No fue hasta el último trimestre cuando conseguimos implantar Hudson como servidor de integración continua. Actualmente realiza las tareas de construcción, testing unitario y análisis de código Java con los plugins de Emma, Checkstyle y Findbugs.
  
• JIRA. Como herramienta de gestión de proyectos/tareas continuamos usando una antigua versión de JIRA. Es una maravilla y eso que no creo que estemos aprovechando todas sus posibilidades. Sólo echo de menos un wiki principal para todos los proyectos o individual por proyecto.

Mis planes para este año implican las siguientes mejoras:

• Selenium. Hemos estado experimentando con Selenium para hacer testing funcional de aplicaciones web. Sin embargo estamos teniendo problemas a la hora de ponerlo en funcionamiento en el Hudson. Lo que está dificultando mucho su aceptación y uso generalizado. Aún así lo encuentro básico para dar el siguiente paso de calidad en nuestro modelo de desarrollo. Todos sabemos el infierno que es actualmente el desarrollo web...
  
• Maven. Aunque Ant es una herramienta genial, el elevado número y hetereogeneidad de proyectos que llevamos hace difícil el mantenimiento de los scripts. Por eso y otras razones quiero probar Maven en uno o dos proyectos serios.
• Mylyn. Mylyn es un plugin para integrar Eclipse con la mayoría de sistemas de control de tareas/tickets de forma avanzada. No sólo permite tener visibilidad de los tickets en Eclipse, también dota de memoría a Eclipse para recordar qué ficheros del proyecto están asociados con cada tarea. Con lo primero espero, sobretodo, mejorar la trazabilidad entre lo que hace el código realmente y lo que dice la descripción de la tarea.
  
• Wiki. Tengo ganas de probar una wiki para gestionar la documentación interna que vamos generando, en lugar de, como hacemos ahora, crear y copiar documentos word a una carpeta compartida. También me gustaría probarla como herramienta de especificación de requisitos de los proyectos con capacidades reales de colaboración y control de versiones automatizado. La idea sería enlazar desde la descripción de las tareas en el Jira a las páginas del wiki.

Con ésto doy por terminada esta primera parte de introducción y ecosistema. En la segunda me centraré en la arquitectura de la aplicación.

Evaluando WireframeSketcher, plugin Eclipse para diseñar prototipos de pantallas

Me encuentro sumido en un nuevo proyecto, consistente en realizar una fase de análisis de una importante aplicación para gestionar de expedientes en un organismo público. Oh sí, metodología en cascada en toda regla...

Pero a lo que iba, una de las partes más importantes del entregable para el cliente son las pantallas, si no la más. Hasta ahora cuando me ha tocado hacer un esbozo de pantalla, alias wireframe, he sobrevivido con lo primero que he pillado. Pero esta vez, dada la cantidad de pantallas a hacer, me lo he tomado un poco más en serio y he descubierto esta pequeña maravilla: WireframeSketcher.

WireframeSketcher es un plugin para Eclipse que permite dibujar un wireframe de forma intuitiva, ágil y rápida. Muy rápida. Su paleta de componentes es muy completa, sirve tanto para aplicaciones web, como de escritorio. Destacar, también, una ayuda inteligente que te facilita alinear los componentes en base a guías. El acabado es estupendo, agnóstico a estilos y colores, como todo buen wireframe, y se exporta a PNG. Como muestra este screencast.

Requiere Eclipse 3.3. Se puede instalar de forma automática desde Eclipse usando http://wireframesketcher.com/updates como update site. Decir también que cuenta con su propia perspectiva y que de rendimiento va muy bien, no enlentece a Eclipse.

Aunque no todo iba a ser bueno. No es gratis. Pero tiene una versión de prueba permanente gratuita que lo único que hace es añadirte la marca de agua EVALUATION a las imagenes exportadas de las pantallas.
La otra buena noticia es que no es caro, 50-80 dolares cuesta una licencia. Para mí merece la pena, digo el dinero. Así que espero que mi jefe no ponga problemas.

Por qué Maven

Maven es la última pieza que he decidido acoplar en mi entorno de desarrollo o ecosistema software. Para los que no lo conozcais, Maven es una herramienta para gestionar el ciclo de vida de un proyecto Java. Desde mi primer trabajo hasta ahora he estado usando Ant para esta tarea con excelentes resultados.

Entonces por qué cambiar

Soy un apasionado de la parte de construcción de proyectos, lo que en inglés llaman Build Engineering. Llevo ya muchos proyectos, de desarrollo y mantenimiento, de todos los sabores y algún sinsabor también, hasta proyectos con un único servidor de desarrollo compartido y proyectos cero automatizados. Así que he comprobado y sufrido la importancia del sistema de construcción de un proyecto. Hasta que punto es capaz de multiplicar la productividad del equipo, aumentando la velocidad y eficacia de ejecución de los procesos del ciclo de vida.
En mi opinión más importante que usar tal framework o tal otro. Aún más valioso si queremos realizar testing e integración continua. Y en definitiva el camino para convertir nuestra profesión en una verdadera ingeniería.

Por eso, en mi opinión usar Maven, sobre otras alternativas, aporta las siguientes ventajas.

Estandariza la estructura de directorios

Hasta ahora cada proyecto ha tenido una estructura arbitraria, basada en el criterio del lider técnico, en la estructura de generación del IDE corporativo o simplemente copiada de otro proyecto. Así es común encontrarse con que en cada proyecto un mismo tipo de fichero se encuentra en carpetas diferentes sin ninguna razón especial, dificultando el día a día de los que trabajan con varios proyectos de forma paralela.

Maven propone una misma estructura para todos los proyectos, pero permitiendo que pueda configurarse de forma personalizada en caso necesario (convención sobre configuración).

Estandariza el ciclo de vida

Si la estructura de directorio de cada proyecto es un mundo, del ciclo de vida ni hablamos. Cada proyecto tiene sus propias fases, con su nombre, orden y requisitos que hay que aprenderse...

Maven aporta una implementación de ciclo de vida. Sin tener que programar nada. De modo que ejecutar cualquier fase del ciclo de vida es siempre igual en todos los proyectos Maven. Para el desarrollador común aprender a manejar un proyecto Maven implica haber aprendido a manejar todos los proyectos Maven.

Además este ciclo de vida es extensible, permitiendo, en caso necesario, añadir tareas personalizadas implementadas en Java o Ant, entre otros lenguajes.

Reutilización

El año pasado implantamos Hudson como servidor de integración continua. Además de las tareas de test y construcción lo usamos para sacar informes de calidad de código y cobertura. Todo mediante scripts Ant. Pero nuestros proyectos son muchos, muy hetereogeneos y ninguno usaba checkstyle, findbugs, ni cobertura, así que no fue nada inmediato configurarlos para Hudson, no es que nos llevara horas, pero si un rato por proyecto al tener que añadir librerias y modificar el script Ant.

Mientras que con Maven si habría sido inmediato gracias a su sistema de reutilización, tanto de uso de plugins como de herencia de configuración. Fue el momento que empecé a pensar en serio en usar Maven, hasta entonces no me salian las cuentas ventajas/coste.

Integración

La integración de Maven con las herramientas y frameworks que usamos en la actualidad es total. Además de las citadas anteriormente están Eclipse, Selenium, CVS, SVN, Hibernate y Axis2.

Gestión de dependencias

Uno de los problemas más complejos a la hora de configurar un proyecto es la gestión de dependencias. Hasta ahora yo siempre he optado por incluir todas las dependencias en la propia estructura del proyecto y por tanto en el scm. A pesar de la posible redundancia y malgasto de espacio por tener muchas dependencias repetidas entre todos los proyectos.

Maven aporta un sistema de gestión de dependencias basado en repositorios y una fuerte configuración en el proyecto.


También destacar que Maven está basado en la experiencia, criterio y buenas practicas de la gente de Apache. Como puede apreciarse en las características que trae de serie, como filtering, perfiles, arquetipos, sistema multi-módulo y construcción del sitio web del proyecto. Y esto es todo, ya iré contando como me va...

Reflexiones sobre el proceso de evaluación del rendimiento y desarrollo profesional como jefe de equipo

Encaramos el final del primer trimestre. Por estas fechas todos habremos pasado ya por el llamado Proceso de Evaluación del Rendimiento y Desarrollo Profesional o similar. Seguro que, al leer esta última frase, la mayoría habéis esbozado una familiar mueca de desencanto y quizás hasta cinismo. Una sensación que comparto con vosotros. El caso es que no queria dejar pasar la ocasión de reflexionar en voz alta sobre este tema, desde mi posición de jefe de un equipo de desarrollo.

Qué está en mi mano y qué no

Logicamente, el objetivo principal de la persona que es evaluada es conseguir una subida de sueldo y/o de posición. Desgraciadamente yo poco puedo hacer aquí. Como jefe de un equipo de 2-5 personas dentro de una empresa con más de 1000 empleados no tengo ningún efecto real sobre este aspecto. Mis opciones se reducen a usar mi pequeña influencia sobre mi jefe, para destacar la labor de los más brillantes y confiar en que sus méritos sean tenidos en cuenta a la hora de repartir la bolsa. Este año dificil, si no imposible, por cierto.

Lo que sí está en mi mano es facilitar el resto de objetivos que todos deberiamos tener, saber qué he hecho bien, qué he hecho mal y cómo puedo mejorar. Y es en esta parte en lo que me centro.

Antes de la entrevista

Como cualquier tipo de encuentro o reunión, la entrevista debe ser preparada con suficiente antelación. Programando es fácil deshacer cualquier metedura de pata, pero en las relaciones con personas no es tan sencillo, sobretodo si una de las personas es jefe.

Así que redacto el informe-formulario del proceso con mimo, reflexionando sobre el evaluado, su año, preferencias y futuro. La parte de evaluación no tiene mucho secreto, una nota por cada objetivo fijado el año anterior, una nota global más un campo de texto libre. La parte de desarrollo profesional basicamente consiste en definir los objetivos para el próximo año.

Los objetivos deben ser personalizados. Si bien hay ciertos objetivos fijos como adquirir mayores conocimientos en la plataforma J2EE, se debe personalizar y especificar tecnologías concretas. Un objetivo que me gusta mucho es el de redactar un pequeño artículo técnico o leer un libro. Dejando siempre el título a libre elección pero proporcionando algunos ejemplos.

Sólo resta tomar unas notas sobre algunas cosas de las que quieres hablar durante la entrevista pero que no tienen porqué reflejarse en el informe. Luego pongo el informe a disposición del evaluado y cuando nos viene bien a los dos tenemos la entrevista.

La entrevista

Durante la entrevista intento buscar el diálogo y que no se quede en la simple lectura de un informe. Por eso empiezo pidiendo la opinión del entrevistado sobre el año general, lo mejor y lo peor. Si no se suelta le pido que le ponga una nota del 1 al 10 e intento ser más explicito preguntándole por algun proyecto o suceso concreto.

De aquí pasamos a la parte de evaluación. Para dar un toque gráfico, suelo pintar una gráfica formada por una recta creciente hacia la derecha que simboliza lo que yo esperaba de él y luego otra función más irregular que representa su rendimiento durante este año bajo mi punto de vista. Para comunicar sus puntos fuertes y débiles, uso la técnica del sandwich, empezando y terminando por cosas positivas y dejando lo menos positivo en medio.

En la parte de desarrollo profesional hablamos de sus objetivos para el próximo año y lo que espero de él como miembro de mi equipo. En caso de que tenga alguna petición concreta, la valoro y cambio el informe si procede (normalmente sí).

Un proceso continuo

Si el trabajo durante el año ha sido bueno, no debería haber ningún problema durante la entrevista y se convierte más en un trámite que otra cosa. Se aprovecha para dar ánimos y conocerse un poco mejor basicamente.

Si el trabajo ha sido malo y como superior has dejado que pase todo el año sin solucionarlo, va a ser bastante más duro... pero a mi aún no se me dió el caso :-)

Por eso abogo porque exista una comunicación continua entre el equipo. Por un lado a la hora de evaluar, se debe aplaudir el trabajo bien hecho, tanto el brillante ocasional como el cotidiano meticuloso. Y también criticar el trabajo de baja calidad y explicar cómo se podría mejorar. Si el tiempo no lo permite, tendrás que aceptarlo como esté pero deja clara la deficiencia.

El lado del desarrollo profesional se puede abordar con sesiones de programación por parejas, revisiones de código, coaching o simplemente sentándote con él para mostrarle alguna tecnología o herramienta que no estais usando pero que sería interesante.

Además la comunicación debe ser cúanto más pública y natural mejor. Es decir, usa el día a día, sin esconderte, no hace falta que sea en reuniones. A mi en realidad no me gusta hacer muchas reuniones de grupo. Solemos tener apenas una o dos por trimestre siempre justificadas. Y si la cosa no es grave prefiero hacer los tirones de oreja en ellas, delante de todo el mundo, eso sí, sin abusar. Si la cosa es más seria entonces sí, mi recomendación es hablar en privado y con el discurso muy preparado.

Tags: Buenas prácticas de uso de un sistema de control de versiones (ii)

Este post es la segunda parte de aquel Buenas prácticas de uso de un sistema de control de versiones que publiqué en noviembre del año pasado. Está dedicado exclusivamente al uso de tags. Sé que prometí incluir branches y merge, pero habrá que dejarlo para otro día...

Antes de nada, lo primero sería definir qué es un tag en un sistema de control de versiones. Bien pues un tag es una marca que se asocia al estado de un proyecto en un determinado momento para poder acceder a él posteriormente. Por supuesto, los tags se pueden crear, listar y borrar.

La primera buena práctica sería... usa tags!. Es sorprendente la cantidad de gente que usa sistemas de control de versiones pero nunca ha usado tags. El uso de tags es la técnica más eficaz para volver atrás a un estado concreto del proyecto. Ya sea para hacer un checkout o para usarlo en comparaciones.

A continuación paso a exponer las que para mí, según mi experiencia y criterio, son buenas prácticas en el uso de tags:

• Reutiliza el esquema de nomenclatura de versiones del proyecto para dar nombre a los tags. El esquema debe ordenar de forma incremental en el tiempo los nombres para facilitar la presentación del listado con todos los tags del proyecto.
  Así por ejemplo, yo utilizo el típico esquema X.Y.Z, donde X es el número de versión mayor, Y es versión menor y Z es versión de bug. Como CVS no soporta el carácter punto, utilizo el guión bajo como separador. Es decir, la versión v2.4.3 se traduce al tag v2_4_3.

• Si no tienes un esquema, es el momento de crearlo. No uses la fecha como nombre para un tag. Mucho menos en formato ddmmaaaa, que no se ordena de forma incremental.

• Asegúrate de que tienes la versión correcta del proyecto antes de crear un tag. ¿Han subido tus compañeros sus últimos cambios? ¿Te has hecho un update?

• Crea un tag por cada release del proyecto que se produzca. Aunque sea una release interna. Esto te permitirá continuar desarrollando y aún así poder volver sin esfuerzo al estado del código de la release, por si necesitas corregir algún bug, realizar una pequeña mejora o simplemente realizar una entrega o distribución.

• En general, crea un tag por cada suceso con implicación externa que ocurra en el proyecto. Como una entrega a un entorno de integración, el fin de un sprint, la realización de una demo, etc. Crear un tag es un momento, pero volver al estado de un proyecto un par de semanas después, deshaciendo los cambios a mano, es un infierno.

• Recuerda que siempre puedes borrar los tags que dejen de tener sentido.

• Crea un tag para marcar el inicio de un branch. Esto lo veremos más en detalle en la tercera parte.

• Crea un tag para marcar la realización de un merge. Esto lo veremos más en detalle en la tercera parte.