Eclipse: 5 años lanzando software a tiempo.

Hoy he estado viendo la presentación que Eric Gamma realizó en la JavaPolis 2006. Me parece que es una referencia para cualquier persona que tenga que dedicarse a la gestión de procesos en una compañía de software, y desde luego de obligada visión para cualquiera que esté interesado en estos temas. En las siguientes líneas intentaré condensar los cuarenta minutoes a los que no llega la charla.

Y es que no muchas compañías pueden vanagloriarse de de haber estado liberando software en los plazos establecidos durante cinco años consecutivos. Como dice Eric, shipping matters, al menos si quieres hacer crecer una comunidad.

El proyecto Eclipse está actualmente distribuido a lo largo de todo el globo pero comenzó como un desarrollo cerrado en el que simplemente algo no existía si no había sido liberado previamente. Nadie podía hablar de proyectos que no habían sido liberados. Es fácil comprender que esto suponía una gran barrera entre los desarrolladores y los usuarios ya que era imposible recoger feedback hasta que el producto no se lanzaba.

Es muy interesante ver como Eclipse migró a una cultura orientada al lanzamiento de software. La regla es sencilla: "Si algo contribuye al lanzamiento de software, incluso indirectamente, entonces se considera bueno. Si algo no contribuye, entonces es malo". ¿Vamos a liberar enormes documentos de diseño? ¿No? Ok, entonces no los haremos. Dentro de la cultura se valora siempre la habilidad para liberar software. ¿Has liberado software? Bien, entonces puedes hablar.

En 2001 Eclipse realizó la transición a un proceso abierto de desarrollo. Pero un proceso abierto de desarrollo genera una comunidad, y una comunidad requiere atención. De repente los desarrolladores se encontraron con que los usuarios podían interactuar con su bugzilla, que en los newsgroups aparecían constantemente preguntas, etc. Para sobrevivir a este efecto, Eric señala como algo fundamental el invertir en interacción con la comunidad. Cada desarrollador de Eclipse puede invertir el 30% de su tiempo en interactuar con la comunidad. Se trata de romper las barreras entre los usuarios y los desarrolladores.

En un proceso de desarrollo abierto las dos partes se comprometen y las dos partes ganan. El proyecto le ofrece al usuario el compromiso de escuchar y reaccionar a su feedback, demostrar un progreso continuo y hacer transparente el proceso de desarrollo, es decir, mostrar los planes de desarrollo, permitir acceso a las diferentes milestones, etc. Por otra parte, como contrapartida los usuarios comenzarán a involucrarse y a resolver las preguntas fáciles (si la comunidad es saludable los desarrolladores sólo tendrán que gastar su tiempo en contestar las preguntas complejas), informarán sobre errores y defectos, validarán la tecnología escribiendo plug-ins, enviarán mejoras y parches, etc.

Para conseguir un proceso de desarrollo abierto se requieren live betas, es decir, se requiere que el software se pueda probar pronto, conforme se va creando. Esto requiere que el proyecto sea saludable ya que se debe obtener calidad en todo momento. En Eclipse esto son las milestones. Eclipse lanza una versión mayor de su software por año, de otro modo sería demasiado estrés para el equipo, el resto son milestones.

El proceso de desarrollo comienza con una fase de calentamiento que dura un mes. En esta fase cualquiera puede hacer lo que desee y nadie le va a pedir cuentas por ello. Es una fase también en la que se analiza lo que se ha hecho en la versión anterior y se buscan posibles mejoras. Al final de esta fase se crea el plan inicial de lanzamiento.

Posteriormente se entra en el proceso de milestones. Eclipse lanza de siete a ocho milestones por año. Inicialmente una milestone duraba tres semanas pero pronto encontraron que a medida que el proyecto se hizo complejo esta medida no era suficiente, así que en la actualidad cada iteración consume seis semanas. El objetivo inicial es conseguir software saludable, y las milestones les ayudan a mantener la forma, es decir mantener siempre un ritmo de trabajo saludable. De este modo, cuando llega el momento de lanzar la versión final, el espacio que hay entre la última milestone y una versión de producción no es tan grande y el esfuerzo a realizar es menor. Una vez terminada cada milestone es firmada por los diferentes equipos.

Un proceso de desarrollo transparente requiere también planificación transparente, es decir, mostrar el plan al público. Este plan ya no será nunca más estático, sino dinámico, y se actualizará continuamente según la evolución del proyecto y el feedback de la comunidad. Para eso los elementos que forman el plan tienen estados: commited, proposed o deferred.

Una milestone saludable significa consumible, es decir, que pueda ser probada (testable) y que pueda ser demostrada (demo-able), y al mismo tiempo debe ser honesta, es decir, con un tiempo fijo de lanzamiento y un incremento en las funcionalidades. Con cualquier milestone de Eclipse los usuarios deben ser productivos. El software debe siempre ser continuamente consumible, continuamente interesante y debe continuamente escuchar el feedback.

Para conseguir estos objetivos los equipos de desarrollo tienen que consumir sus propios productos. Eclipse trabaja con un sistema de integración continua multi-componente (es decir cada componente, cada equipo, tiene su sistema de CI que se coordinan para dar el resultado final). La milestone se divide a su vez en dias y semanas. Cada dia un equipo debe consumir lo que ha creado el día anterior y comenzará a trabajar sobre esa base. A su vez, cada semana, los diferentes equipos comenzarán a consumir todo lo que el resto de equipos realizaron la semana anterior. Finalmente, el último gran salto es la milestone, en la que serán los usuarios finales los que consumirán el producto en el que se ha trabajado durante las últimas semanas. Todo esto lleva a un feedback continuo, primero el equipo, después el resto de equipos, para llegar finalmente al usuario final.

Finalmente el proceso termina con el end game. Este se divide en fases de pruebas y corrección de errores: test-fix-test-fix-test ... Eclipse no tiene una sección de testers. Todo desarrollador es un tester. El ritmo de hacer tests puede ser cansino, por ello no pasan más de dos días realizando tests y a continuación pasan a corregir errores. Una vez corregidos, se vuelven a los tests, y el ciclo continua. El ciclo se vuelve más duro y estricto conforme avanza el tiempo y se acerca la fecha definitiva. El número de bugs es menor, hay más revisiones y se controla mucho más el número de regressions.

Posteriormente Eric Gamma habla sobre la transición en productos comerciales hacia un Open Commercial Software Development, que según él (yo estoy de acuerdo) es el futuro del software comercial. El objetivo es conseguir la misma transparencia que hay en Eclipse pero en proyectos comerciales. Todo ello requiere que el proyecto comercial:

• Ofrezca acceso directo al sitio web de los desarrolladores.


• Ofrezca acceso al código fuente (o parte), que exista una comunidad, que los propios clientes puedan crear mejoras y parches, ...


• Permita interactuar directamente con el equipo de desarrollo.


• Ofrezca acceso a todas las versiones previas, milestones, betas o versiones de integración.

Creo que esto resume más o menos lo que es la charla de Eric. Parecen un conjunto de ideas muy a tener en cuenta, y que pueden ayudar a muchas organizaciones que realmente sufren para ser capaces de lanzar lo que inicialmente parece como una simple versión de producción pero que sin un proceso de desarrollo adecuado se puede convertir en un infierno que se alarga durante meses o incluso años.