Mi espacio

Definir un buen ecosistema software es garantía de comodidad, ventajas y mejoras durante el transcurso de un proyecto hasta alcanzar nuestros objetivos. Es lógico, dado que las herramientas que lo conforman están concebidas precisamente para eso, para automatizar y simplificar ciertas tareas.

Hasta ahora, mi experiencia definiendo ecosistemas software se ha limitado a entornos donde la localización de los miembros del equipo no suponía un problema, sin embargo, no debemos olvidar que la distribución geográfica puede ser una cuestión a tener muy en cuenta. De partida, si hay miembros con husos horarios distintos tendremos que tenerlo en cuenta a la hora de planificar nuestras tareas de integración continua. ¿Y qué pasa con la forma comunicación? La posibilidad de coger tu silla y sentarte al lado de un compañero para trabajar no existe. Un problema importante en los equipos de desarrollo software es la comunicación en el equipo, especialmente, transfiriendo información entre distintos roles.

Por otro lado, el acceso a la información es otra cuestión importante. Yo no quiero un acceso por VPN para poder recuperar el último informe de pruebas que se realizó la noche anterior. Quizás, si nos encontramos en nuestro lugar habitual de trabajo o contamos con nuestro ordenador portátil, no sea demasiado intrusivo dado que ahí encontraremos todo aquello que usamos frecuentemente. Pero, ¿Qué sucede si estoy en las oficinas del cliente y por cualquier motivo (no es la primera vez que me pasa) necesito acceder a determinada información? Con esto lo que intento transmitir es la importancia que tiene garantizar el acceso a la información y que por tanto, a la hora de definir nuestro ecosistema software la accesiblidad debemos tenerlo presente.

Por lo tanto, un ecosistema software se plantea como una solución (o mejora) a estos dos nuevos retos, por un lado la distribución geográfica, y por otro, el acceso a la información. ¿No es precisamente esto básico para las factorías de software?

Esta es una de esas entradas que llevo tiempo queriendo escribir y tras un tiempo pensando e intercambiando ideas con otros compañeros, he pensando que es momento de proporcionar mi perspectiva sobre los ecosistemas software.

En una de las entradas del blog de Brett Porter leí como usaba el término development ecosystem para referirse a como herramientas como Maven, Archiva y Continuum pueden ayudar a los equipos de desarrollo a ser más eficientes.

Un ecosistema software es un espacio de trabajo en el que conviven una serie de herramientas que acompañadas de unas buenas prácticas permiten a un equipo de desarrollo modelar una metodología de trabajo.

Me resulta complicado proporcionar una definición corta para transmitir una idea que es simple pero que implica muchísimas cosas:

• [...una serie de herramientas...]: ¿Qué herramientas?
• [...acompañadas...]: ¿Quiere decir esto que las herramientas por sí solas aportan poco?
• [...buenas prácticas...]: Aquel documento donde está explicado qué hacer, cómo y cuándo.
• [...modelar una metodología...]: Planificación, organización, medición, control, etc.

Todos los equipos de desarrollo software, incluyendo aquellos que se organizaban para realizar las prácticas de alguna asignatura de la carrera, tienen su propio ecosistema software. Los ecosistemas software surgen como necesidad de alcanzar nuestros objetivos de la forma más eficiente posible. Un equipo de trabajo puede alcanzar sus objetivos siguiendo Métrica v3 y usando poco más que una suite ofimática como OpenOffice y cualquier IDE de desarrollo para las tareas propias de codificación. Sin embargo, siendo este nuestro ecosistema software creo que nos costaría muchísimo responder a ciertas preguntas como:

1. Cuál es el próximo hito en la planificación
2. Qué sistema de versionado (version naming) se está llevando a cabo y cómo comprobarlo
3. Cuánto costó elaborar un informe de calidad previo a obtener una nueva versión
4. Cuál es la actividad del proyecto
5. Qué métricas e indicadores de calidad se tienen del proyecto y cómo se obtienen
6. y un largo etcétera.

Es cierto que el caso que he expuesto es algo extremista, pero os puedo asegurar, porque lo he sufrido, como un proyecto se lleva adelante a base de documentos de texto, hojas de cálculo, intercambio de correo y de vez en cuando intercambio de código fuente a través de correo para que un miembro del equipo hiciera que aquello “ensamblase” bien.

Por lo tanto, la correcta definición de un ecosistema software nos ayudará a flexibilizar y agilizar tareas, que en cierta medida se traducen en eficiencia y productividad.

Algunos factores que condicionan la definición y configuración de un ecosistema software:

1. Marco tecnológico: Las herramientas que conformen nuestro ecosistema software en gran medida estarán condicionadas por nuestro marco tecnológico. Obviamente no es igual trabajar con tecnología Java que con tecnología .NET
2. Desarrollo de negocio: Es muy importante si nuestra actividad se centra en el desarrollo de soluciones a medida o por el contrario desarrollamos una línea de productos. En el primer caso, una vez entregada una versión estable, nuestra implicación queda resumida a una garantía de mantenimiento. Sin embargo, desarrollar un producto tiene muchas más implicaciones que requieren atender de forma eficiente la interacción con los consumidores de nuestros productos.

Disponer de un ecosistema software estable y bien definido puede ser un valor añadido de cara a nuestros clientes. Construir un ecosistema software no es sencillo ni es una tarea que se pueda llevar a cabo en semanas, entre otras cosas porque implica un cambio en la cultura de empresa puesto que estamos hablando de nuestra forma de trabajar.

Más adelante intentaré hablar sobre los ecosistemas software como paso previo para las factorías de software.

El pasado jueves 12 se celebró en la oficina de BitRock la primera desconferencia de ecosistemas software. Durante los días previos estaba un poco preocupado por la acogida que podría tener, sin embargo, al ver que la sala no paraba de llenarse de gente, comencé a ponerme más nervioso aun porque no había nada oficialmente preparado. Personalmente creo que una reunión de este tipo no tiene precio. Poder compartir conocimiento y experiencias de esta forma me parece algo increíble y de un valor incalculable.

Si las cuentas no me fallan creo que asistimos una 20 personas. Todo comenzó con una breve presentación de los motivos que me llevaron a crear la lista de correo ecosistemas software. Posteriormente la gente se fue presentando comentando su experiencia, marco tecnológico, etc. Después, el resto vino solo. Salieron a relucir muchos temas y como no podía ser de otra forma, se expusieron los ecosistemas software que cada uno usábamos.

Tras 2 horas de conversación, se habló de la segunda desconferencia y la conveniencia de organizar algunas exposiciones breves (5-10 minutos) sobre algunos temas de interés. Y como no podía ser de otra forma, para seguir conociéndonos unas cervezas y refrescos en un bar (que llenamos por completo) cerca de la oficina.

Ahora sólo me queda agradecer públicamente a BitRock su hospitalidad y al resto de gente, su asistencia y participación activa durante la desconferencia. Nos veremos en la Desconferencia 02 de Ecosistemas Software.

A finales de 2007 se anunciaba la creación de una lista de correo llamada ecosistemas software. Han pasado ya algunos meses desde su creación y los números están ahí: 69 miembros y una baja actividad (al menos eso es lo que dice googlegroups). Sin embargo, hay gente que tiene ganas de aprender y compartir sus conocimientos y experiencias, y por ello, hemos decidido organizar una desconferencia en Sevilla.

La desconferencia se llevará a cabo el próximo jueves 12 de junio en las instalaciones de BitRock:

BitRock S.L.
C/ Salado 11 - Local 15
41010 Sevilla
Spain

La hora de inicio será a las 19:00h (puntualidad, por favor!). Inicialmente hay varios temas que se han planteado en un hilo de la lista para romper el hielo, pero la idea es que sea un coloquio abierto y que la gente se anime a participar.

Hace algún tiempo comentaba en este blog que estábamos trabajando en un herramienta de modelado de requisitos. Mientras obtenemos resultados en este sentido hemos preparado un pequeño plugin que se encarga de hacer lo siguiente:

Entiendo que este plugin está muy limitado, sin embargo, para aquellos que usáis TRAC y no tenéis otra cosa, quizás os resulte útil. Si hay algún interesado:

Requisitos

• REM
• Trac 0.10.4 o superior
• LXML

Instalación

• Descargar los fuentes
• Ejecutar: python setup.py bdist_egg
• En el directorio dist/ encontraremos el correspondiente archivo EGG.
• easy_install –always-unzip fichero.egg

Configuración en TRAC

• Editar el archivo trac.ini y añadimos la siguiente sección en caso de que no exista:

[components]
tracquirement.* = enabled

• Luego tendremos que asignar el permiso TRACQUIREMENT_USE a quien corresponda.

A continuación os dejo una captura de pantalla del resultado:

El plugin ha sido liberado con licencia GNU GPL v2.

Es probable que gran parte de los que os dejáis caer por este blog no conozcáis REM. Tal y como se indica en la página oficial de esta herramienta:

REM (REquisite Management) es una herramienta experimental gratuita de Gestión de Requisitos diseñada para soportar la fase de Ingeniería de Requisitos de un proyecto de desarrollo software de acuerdo con la metodología definida en la Tesis Doctoral “Un Entorno Metodológico de Ingeniería de Requisitos para Sistemas de Información”, presentada por Amador Durán en septiembre de 2000.

Los que hemos estudiado en la Escuela Técnica Superior de Ingeniería Informática de la Universidad de Sevilla conocemos esta herramienta. Hace tiempo comentaba que se había creado la lista de correo ecosistemas-software. Uno de los objetivos de esta lista es intercambiar ideas y opiniones sobre qué herramientas componen los ecosistemas de desarrollo software de grupos de trabajo y áreas/departamentos de desarrollo. Pues bien, en todos los ecosistemas que he tenido que implementar (consultoría tecnológica, instalación, configuración, integración y formación) me he encontrado que el analista se queda sin nada, es decir, no había nada para que al menos los requisitos funcionales y no funcionales quedasen reflejados en “algún sitio”. Ese “algún sitio” es para mi en los últimos años, una wiki.

Como primera aproximación no estaría nada mal algo como lo que se expone en la ilustración:

¿Habrá noticias en breve?

En esta ocasión escribo para comunicar que se ha creado una nueva lista de correo para tratar temas relacionados con ecosistemas software basados en herramientas con licencias de código abierto. La lista de correo acaba de ser creada y esperamos que sea bien aceptada por la comunidad de desarrolladores. Para más información sobre la lista de correo:

http://groups.google.com/group/ecosistemas-software

Particularmente mi aportación estará centrata en las herramientas con la que tengo experiencia, sin embargo, tengo mucho interés por conocer otras configuraciones de ecosistemas software. Esas herramientas son Maven, Archiva y Continuum, todas ellas de Apache Foundation.

Hace algún tiempo escribí un breve post para dar una pincelada sobre lo que entiendo por integración continua. Una de las cosas que comentaba era que no había tenido la oportunidad de poner en marcha este modo de interaccionar en proyectos reales, sin embargo, ahora ya tengo algunas experiencias y me estoy haciendo una idea de lo que quiero conseguir. Quizás más adelante pueda contar lo que sí estoy consiguiendo, pero esto es otro tema porque no sólo depende de los conocimientos teóricos, de las herramientas disponibles o la infraestructura necesaria, sino que depende de hacer ver a todos los miembros del grupo lo realmente positivo que puede llegar a ser este modo de trabajar, de que los miembros superen cierta curva de aprendizaje y de que en el sitio donde llevas a cabo tu trabajo te permitan modelar este tipo de prácticas.

Ahora lo interesante es conocer qué nos puede aportar la integración continua, que si Martin Fowler me lo permite, voy a referirme a ella como una práctica en la que lo todo gira en base a dos cuestiones:

1. Diseñar mecanismos y procedimientos para que los efectos de tus causas puedas controlar. Cuando estamos desarrollando, implementar una cierta funcionalidad o subir la versión de una librería, y que posteriormente esto se refleje en nuestro sistema de control de versiones, tiene su efecto. En este caso la causa sería el commit. Pues bien, si ese commit va acompañado de pruebas unitarias, pruebas de sistemas y pruebas de integración, podremos conocer el verdadero efecto de la causa. Si el efecto es el esperado, perfecto!, en caso contrario habrá buscar otra causa para alcanzar el efecto deseado.
2. Y por otro lado, la automatización de esos mecanismos y procedimientos. Será la automatización la que nos permita centrarnos en lo verdaderamente importante, la solución de los problemas. ¿Cuántos grupos de trabajo conocéis que sean todos y cada uno de sus miembros lo suficientemente cuidadosos, delicados y meticulosos con su trabajo para tener la certeza de que los pequeños detalles no quedan ocultos? Cómo esta situación es difícil de encontrar y en caso de encontrarla la productividad de la empresa nos agobiaría, necesitamos hacer algo que nos proporcione indicadores que reflejen todos los detalles (grandes y pequeños) y que por otro lado no tengamos que repetir una y otra vez las mismas acciones de forma manual.

Lo que buscamos es algo que nos permita modelar mecanismos y procedimientos que se puedan ejecutar o realizar de forma automática y que nos hagan ver claramente los efectos de todas las causas que se originan.

Algunos ejemplos de efectos que se me ocurren en este momento pueden ser:

• Generación de documentación. Como responsable de QA no quiero llevarme la desagradable sorpresa de que tras cuatro meses de desarrollo la documentación Javadoc que se ha generado no está lo suficientemente elaborada. Necesito algo que todas las noches me genere la documentación Javadoc y la publique a través de HTTP en formato HTML.
• Despliegues automáticos de las releases del proyecto. Los tester no pueden estar esperando a que alguien les depliegue una determinada versión del proyecto (o producto, en este caso daría igual) para continuar con su trabajo.
• Análisis de código. No quiero esperar a tener un poco de tiempo libre en el que poder ejecutar mi plugin PMD o Clover y darme cuenta de lo que se está haciendo y cómo se está haciendo.
• Integración. No quiero estar al 80% de un proyecto y darme cuenta de que el proyecto únicamente se ha probado con JDK1.5 en Jetty y la respuesta sea que no hubo tiempo para otras pruebas. Efectivamente, es posible que no haya tiempo si esas pruebas las tienes que hacer manualmente y encima tienes que mantener todos estos entornos, sin embargo, de poder automatizarlo, el tiempo no sería tu principal problema.

Estos son sólo algunos de los ejemplos que se me han ocurrido, sin embargo, la lista podría ser más extensa. Pues bien, en cada uno de esos ejemplos están los objetivos que pretendo conseguir con la integración continua. La solución está en los ecosistemas de software, ¿verdad Brett? Estoy prácticamente seguro que Carlos Sánchez opina lo mismo y máxime cuando le de algunos ingredientes como maven, Mylyn, archiva, continuum, etc.

El objetivo de esta entrada es presentar lo que entiendo por integración continua y cómo enjaca esta nueva pieza dentro del ecosistema que constituye un entorno de desarrollo y las metodologías que se aplican. Según la R.A.E.:

ecosistema: Comunidad de los seres vivos cuyos procesos vitales se relacionan entre sí y se desarrollan en función de los factores físicos de un mismo ambiente.

En nuestro caso los seres vivos son los distintos miembros del equipo con su correspondiente rol, los procesos vitales podrían ser las tareas que deben realizar para “sobrevivir” y que se desarrollan a partir de unas pautas, normas y procedimientos que las metodologías arbitran.

“La integración continua es una práctica en el desarrollo de software que consiste en poner en común todas las tareas que se han realizado en un intervalo de tiempo y, mediante la automatización de ciertos procesos, comprobar cuáles han sido los efectos de dichas tareas“.

Que este post sirva como presentación para un nuevo tema dentro de este blog.