Mi espacio

Así es como se llamaba el taller que ayer se celebró en la Escuela Técnica Superior de Ingeniería Informática. El taller fue organizado por Joaquín Peña y estaba enmarcado dentro del Máster Ingeniería y Tecnología del Software (Universidad de Sevilla).

A continuación podéis encontrar las transparencias que utilicé en mi intervención “Ecosistemas Software”:

Han pasado ya varios meses desde que se celebrase la segunda desconferencia. Pero lo importante es que durante estos días se ha estado organizando la tercera desconferencia.

¿Cuándo?

Miércoles, 22 de Julio de 2009 a las 19:00

¿Dónde?

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

En esta ocasión, mi compañero y amigo Antonio Manuel Muñiz y yo, nos hemos ofrecido a preparar un pequeño taller sobre:

• Instalación y configuración de Apache Archiva
• Integración de mis proyectos maven con Apache Archiva
• Instalación y configuración de SONAR
• Integración de mis proyectos maven con SONAR
• Instalación y configuración de Apache Continuum
• Integración de mis proyectos maven con Apache Continuum

Evidentemente, es una propuesta, luego saldrán muchos otros temas.

Hace unos días leía en el blog de kybele consulting una entrada muy interesante sobre métodos de estimación software. En la entrada se hace referencia a unas transparencias en las que hay información con la que estoy de acuerdo, sin embargo, y probablemente sea un problema particular mío, todo eso me suena a pura teoría más propia de una asignura de aquella carrera que tanto me aburrió.

Estoy convencido de que mucha gente pensará que estoy equivocado, y es probable, sin embargo, creo que en cualquier método de estimación de proyectos software (incluidos productos) en el que no tengamos en cuenta a los recursos (al equipo), la incertidumbre será abundante. Muchas veces me veo obligado a planificar proyectos incluyendos costes y la sensación que tengo es de levantar el dedo y ver para qué lado sopla el viento. ¿Cuántas veces no se ha preparando una oferta para un concurso público haciendo ingeniería inversa? El dinero que hay es X, pues a partir de ahí defino mi oferta (planificación, recursos, tecnología, etc).

Una de las líneas de trabajo en los ecosistemas software es la base histórica de proyectos. Realizar una estimación teniendo en cuenta tus recursos (conocimientos, habilidades, especialización, etc) y una base histórica, sigue siendo predecir, pero lo cierto es que cada vez acertamos más. A continuación un breve listado de situaciones que hacen que la estimación se parezca a la realidad con la misma probabilidad que un niño de 3 años escriba en un post-it los números del euromillón:

1. Optar por un marco tecnológico en el que no se tenga experiencia. Hace un “Hola mundo” no es tener experiencia.
2. Que en el equipo definido no haya un líder tecnológico. Un líder tecnológico no es un jefe de proyecto.
3. No disponer de un entorno de desarrollo flexible, cómodo y fácil de usar. Podemos llamarlo Ecosistema Software.
4. Ausencia de metodología. Si es un proyecto pequeño y un equipo pequeño, el correo electrónico puede ser su ecosistema, pero en el resto de casos, mal vamos.
5. Reacios a los cambios. Si no admites y pones trabas a que lo requisitos cambiarán, entonces tienes el riesgo de que el mal rollo aparezca.
6. El proyecto tiene un tamaño que no puedes controlar. Muy simple, pasas de ejecutar proyectos de 3-5 personas durante 3-8 meses a 6-15 personas durante 12-18 meses. Los proyectos que se prolongan en el tiempo tienen ciertos aspectos que no aparecen en proyectos pequeños.
7. Tu diseño está condicionado por el cliente y no te siente a gusto desde el comienzo. Mal empezamos porque tu crees que deberían de confiar en ti como proveedor de software y dejarte libertad.

Como en todas las listas que hago, siempre se podrían añadir más puntos. Lo dejo para quienes leen este espacio.

Hace ya casi dos años que venimos definiendo nuestro ecosistema software. A continuación os muestro una ilustración con su arquitectura lógica:

Nuestro departamento de Desarrollo Software cuenta con un commiter en Sonar y un contributor en Apache Continuum.

¿Alguna duda?

Nuestro ecosistema software tiene cosas que mejorar, y ahí está lo bueno. Siempre hay ideas nuevas para mejorar el ecosistema y con ello refinar nuestra forma de trabajar. Hace algún tiempo publicábamos un simple plugin de TRAC que nos genera una página wiki con los requisitos que recogemos con la herramienta REM. Evidentemente era una primera aproximación que seguimos usando pero ha llegado el momento de avanzar, de ahí el título de esta entrada. A continuación algunas cosas que considero básicas para una herramienta de modelado de requisitos:

1. Posibilidad de categorizar y etiquetar los requisitos.
2. Posibilidad de reutilizar categorías y etiquetas entre proyectos.
3. Reutilizar requisitos entre proyectos para evitar introducirlos múltiples veces
4. Relacionar requisitos y definir en qué cosiste la relación (dependencia, ámbito, de interés, etc…)
5. Representaciones gráficas (grafos) con los requisitos y sus relaciones
6. Generación de artefactos documentales como entregables según perfiles
7. Versionado de requisitos
8. Posibilidad de que los requisitos tengan archivos adjuntos (documentos, audio y vídeo)
9. Que para usarla sólo necesitemos un navegador web (y quizás ni conexión permanente si usamos algo como Google Gear)
10. Que gestione correctamente una petición de cambio (quién la solicita, por qué, cómo, cuándo, etc.)

La lista se podría extender muchísimo. ¿Qué le pedirías tú?

Esta semana (lunes y martes) he estado en Madrid recibiendo un curso sobre metodologías ágiles. El curso fue impartido por Diego Parrilla (The Server Labs). No puedo hablar sobre el éxito del curso porque desconocía sus objetivos (sólo iba como invitado), sin embargo, el material que nos entregaron realmente bueno, y Diego, un profesional como mucha experiencia de la buena.

El curso me ha venido muy bien, he podido constatar qué cosas estamos haciendo bien y que cosas tenemos aun por mejorar. Tras un año y medio poniendo en marcha una metodología de trabajo para desarrollar software y el ecosistema software correspondiente, y escuchar a Diego, me gustaría destacar los siguientes puntos:

1. Las metodologías ágiles implican mucha participación por parte del cliente, por lo tanto, hay que saber elegir cómo y cuándo aplicarlas.
2. En caso de que tu cliente acepte trabajar así, cuéntale en todo momento lo que estás haciendo. Sé totalmente transparente, incluso los impedimentos, dificultades y problemas.
3. Inspeccionar y cambiar, la clave para conseguir agilidad. Reinventarse constantemente.
4. Conseguir agilidad es más sencillo con equipos pro-activos, con iniciativa y con experiencia. Parece una obviedad, ¿verdad? Pues no lo olvides si pretendes montar un piloto. Si la experiencia no abunda, busca la figura del mentor (mentoring).
5. La ubicación de los miembros del equipo en el lugar de trabajo es muy importante. Piensa como distribuyes al equipo, influye en la comunicación.
6. Para que las cosas salgan bien, el cliente tiene que formar parte del equipo. En la iteración-0 debes marcarte como objetivo hacer que el cliente se implique y tenga claro que él también desempeña un rol (a parte del product-owner).

Vuestras sugerencias y experiencias serán bienvenidas.

El pasado viernes 17 de octubre se celebró la segunda edición de la desconferencia del grupo Ecosistemas Software. Tal y como se adelantaba en la lista, la asistencia sería muy reducida, finalmente asistimos 5 personas (Paco, Viki, Darío, Felipe y el que escribe). Pero tuvo su lado positivo, esta desconferencia estuvo más acotada y dirigida que la anterior, y nos permitió participar mucho más.

A continuación cito algunos de los temas que se trataron (18:20h – 21:15h aprox.):

1. Dado que teníamos una nueva incorporación, Felipe se presentó, nos contó donde trabajaba, a qué se dedicaba, cuál era su marco tecnológico, cómo era su ecosistema, etc…
2. Estuvimos hablando sobre las distintas formas de distribuir nuestros aplicativos Java (war, jar, ear, aar, zip, con instaladores, etc)  y yo estuve hablando sobre las ventaja de usar el plugin de maven assembly y como lo estoy usando en Opina y otros proyectos.
3. Y por último sobre metodologías de trabajo y especialización en los equipos.

El segundo punto sí estaba previsto que lo tratásemos y así lo hicimos, sin embargo, y esto es lo bueno que tienen estas reuniones, salen temas realmente interesantes donde uno aprende mucho justificando sus ideas y escuchando a los demás.

Algunas cuestiones/ideas interesantes que me gustaría destacar:

1. Felipe planteó que las aplicaciones web se podían distribuir en formato WAR y que los parámetros de configuración fueran proporcionados por el contenidor o servidor de aplicaciones a través de un recurso JNDI. Desde luego es una forma de que WAR sea válido en cualquier entorno de despliegue siempre y cuando se conozca el nombre del recurso que el administrador de sistemas asigne.
2. El plugin Assembly es muy útil para diseñar los distribuibles clásicos: binario, fuentes, etc.
3. Debemos organizar una desconferencia para hablar única y exclusivamente de metodologías y su vinculación con los ecosistemas software.
4. Las desconferencias debemos guiarlas y centrar los temas que se van a tratar.
5. Deberíamos elegir otras opciones que no sean los viernes.

Una foto (Darío, Viki, Paco, Felipe, Dani) en las oficinas de BitRock. Aprovecho para darles las gracias por su hospitalidad.

Tras el parón veraniego, el grupo de ecosistemas-software organiza “Desconferencia 02″. Como ya sucediera en su primera edición, esta nueva edición se volverá a celebrar en las instalaciones de BitRock.

La desconferencia se celebrará el próximo viernes 17 a las 18:00h:

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

Para esta segunda edición voy a preparar algunas cositas sobre distribuibles en Java. Supongo que luego saldrán otros muchos temas. Se ruega a todos los que tengan pensado asistir confirmen su asistencia en la lista de correo. El espacio es limitado y además tengo que saber la gente que asistirá para comprar unos refrescos y algo para picar.

Recientemente hemos entregado a un cliente una aplicación software dentro de un proyecto que está a punto de terminar. Sólo queda cerrar algunos flecos que no dependen directamente de nosotros, sino del propio cliente. El proyecto era pequeño:

• 5 meses en total
• 4 meses desarrollando la aplicación
• 1 Jefe de proyecto, 1 desarrollador del lado del cliente, 2 desarrolladores JEE y 1 asegurador de la calidad

Para la construcción hemos contado con:

• Marco tecnológico Java: Spring framework, Eclipse Birt, Hibernate
• ExtJS
• DEIN – Ecosistema Software (de esto ya os hablaré)

Me gustaría contar algunas lecciones que hemos aprendido:

1. Nos es conveniente homogeneizar los entornos de desarrollo local de todos los miembros del equipo. Aunque el cliente nos indique cuál es su entorno de producción y eso quede reflejado en los requisitos no funcionales del análisis, es altamente aconsejable la disparidad. Es una forma muy simple se disminuir riesgos y asegurar un mayor nivel de calidad. Concretamente en este proyecto hemos usado:
   1. Ubuntu, Eclipse, Jetty, JDK 1.5 (entorno de desarrollo local)
   2. Windows XP, Eclipse, Tomcat JDK 1.6 (entorno de desarrollo local)
   3. Debian, Tomcat, Apache, JDK 1.5 (entorno de despliegue virtualizado que DEIN proporciona)
2. Las tareas de análisis nunca terminan. Cuando el analista decide que hay una versión estable de los requisitos y se ponen en marcha las tareas de implementación, se activa un proceso iterativo entre el diseño-implementación y el análisis. El objetivo final para el cliente es que lo que le entreguemos satisfaga sus espectativas, sin embargo, nosotros compartimos ese mismo objetivo y además tenemos que asegurarnos de que lo construido y lo analizado está sincronizado y se corresponden. ¿Por qué? Porque aunque sean desarrollos a medida (llave en mano) es probable que surjan ampliaciones, revisiones, etc. y por eso mismo tenemos que ser consecuentes con lo que hacemos. No es la primera vez que me encuentro un documento de análisis perfectamente maquetado con una página inicial en la que se indica que lo validó tal persona hace un año y recientemente se ha publicado una versión.
3. Es importantísimo hacerle ver al cliente cuánto cuestan los cambios y todo lo que adicionalmente solicita. Entiendo que es una tarea complicada, pero ahí está la destreza de un buen jefe de proyecto. Lo que no podemos hacer es admitir cambios y mejoras durante la evolución del proyecto con el fin de mejorar la experiencia de los usuarios finales, y que luego, cuando el proyecto está terminando te inunden en procesos eternos llenos de burocracia.
4. En tu planificación prioriza al máximo el obtener una primera release que puedas mostrar a los usuarios finales. Haz todas las entregar parciales que puedas y la disponibilidad del cliente permita. En este proyecto concretamente, el cliente ha tenido la oportunidad de ver todos los avances de forma diaria. DEIN se encargaba se desplegar todas las noches un SNAPSHOT del proyecto en el entorno de despliegue, que por supuesto estaba disponible para el cliente.
5. Establece sesiones de trabajo (preferiblemente, semanalmente) con todos los miembros del equipo. Aprovecha esta sesiones de trabajo para hacer una puesta en común de perspectivas, dudas, aclaraciones, consideraciones, propuestas, etc…
6. Procura que todos tus proyectos tengan algo de I+D+I. Disponer de un departamento de verdad de I+D+I no es sencillo y requiere inversión, pero cuando no se tiene esa opción, algo debemos hacer. Cuidado con los experiementos en proyectos pequeños, es muy sencillo incumplir en la planificación si algo no sale todo lo bien que esperábamos.

Supongo que la lista podría continuar, pero son los que puedo contar y pueden ser útiles. En cuanto me autoricen, publicaré algunas capturas de pantalla (y con suerte un screencast) sobre el proyecto.

Supongo que con este título no estoy diciendo nada nuevo, sin embargo, el día a día nos dice otra cosa. Tan importante es desarrollar un software de calidad como su mantenimiento o explotación, de hecho, la experiencia nos dice que cuanto mejor hagamos el trabajo al principio más fácil y cómodamente abordaremos las etapas futuras.

Hablamos siempre de lo importante que es documentar, definir pruebas, refinar nuestras metodologías, definir buenas prácticas, especialización de los recursos y otras miles de cosas, pero todas ellas afectan -en gran medida- el equipo de desarrollo. ¿Y qué pasa con el resto de perfiles que interviene el ciclo de vida del software? ¿Qué pasa con los administradores de bases de datos y/o administradores de sistemas? ¿Cómo es nuestra relación con ellos? ¿Qué herramientas y procedimientos compartimos con ellos? Dentro del equipo de desarrollo hay “cosas” que comienzan a madurar y síntoma de ello es que a veces nos preguntamos, ¿Qué haríamos sin…?

En este post os hablaré concrétamente de Maven e Hibernate. En mi entorno profesional, estas dos herramientas son muy frecuentes y ambas tienen mucho que decir sobre la relación del equipo de desarrollo y el resto de perfiles que normalmente pertenecen al departamento de sistemas.

Desde hace tiempo la elaboración de libros blancos de buenas prácticas se ha convertido en una moda. En un próximo post daré mi opinión al respecto (“La parte oscura de los libros blancos”), pero por ahora sólo hago referencia porque son precisamente estos libros blancos los que indican/recomiendan/exigen el uso de herramientas como Maven e Hibernate. De qué vale que el equipo de desarrollo haga uso de este tipo de herramientas si luego nos encontramos con situaciones como estas:

• El despliegue del software lo lleva a cabo el propio departamento de sistemas y allí reina su propio libro blanco de buenas prácticas. Si nuestro proyecto está modelado con Maven, y contamos con un ecosistema software mínimamente definido, ¿Por qué tenemos que entregar un WAR con la aplicación que posteriormente descomprimen para configurar (base de datos, LDAP, SMTP, etc)? ¿Por qué los administradores de sistemas no usan Maven? Se podrían beneficiar de muchas cosas como por ejemplo los perfiles para los distintos entornos de despliegue, ejecución de pruebas que no pueden faltar y un largo etcetera. Creo que sería genial que tanto el equipo de desarrollo como el departamento de sistemas compartiesen el uso de Maven. Evidentemente, cada uno desde su perspectiva.
• ¿Por qué debemos entregar al DBA los script de creación de esquemas cuando de eso se encarga automáticamente hibernate? Recientemente preparamos para un proyecto un módulo con una interfaz de línea de comandos con varias finalidades, crear el esquema de base de datos, creación de sinónimos y carga inicial de información (tablas maestras). Con un módulo de estas características, el proceso de instalación como podéis imaginar queda resumido en ejecutar un par de sentencias desde la línea de comandos. Pues parece que esto no entraba dentro del libro blanco del departamento de sistemas.

Estos son sólo dos ejemplos que ponen de manifiesto que el equipo de desarrollo y el departamento de sistemas deben tener un único libro blanco de buenas prácticas y que existe una brecha que debe estrecharse cuanto antes.

En varias ocasiones he tenido oportunidad de charlar con responsables de departamentos de sistemas y una de sus preocupaciones es que los equipos de desarrollo les entregan software que una vez puesto en producción comienza a dar problemas. ¿Qué pasa en esta situación? Al igual que existen pruebas unitarias y funcionales, el departamento de sistemas puede disponer de pruebas de integración y sistemas que proporcionen unos indicadores para garantizar unos mínimos. No sería la primera vez que se pone en producción una aplicación con la configuración por defecto del pool C3P0 muy usado con Hibernate. Luego vienen las sorpresas. ¿Cómo comprueban los DBAs que las tablas de un sistema de información comienzan con un determinado prefijo? ¿Mirando los scripts? ¿No sería más fácil con un plugin de Maven?

Una vez más, la comunicación entre los distintos perfiles es fundamental para que el ciclo de vida de un software funcione.

En un equipo de trabajo dedicado a la ingeniería del software, la existencia de perfiles asociados a recursos concretos denota un alto nivel de especialización. Es normal encontrarse equipos de trabajo donde los recursos que los forman hacen de todo o casi de todo. Donde trabajo, eso no sucede. Desde hace algún tiempo, como parte de un cambio en la cultura de empresa, se comenzó a forjar un alto grado de especialización. Entre los distintos perfiles que se definieron, está el analista.

No quiero añadirle el completo “funcional”, prefiero referirme a él, como analista. Según la RAE, un analista es el que hace análisis, y un análisis es:

1. Distinción y separación de las partes de un todo hasta llegar a conocer sus principios o elementos.
2. Examen que se hace de una obra, de un escrito o de cualquier realidad susceptible de estudio intelectual.
3. Estudio, mediante técnicas informáticas, de los límites, características y posibles soluciones de un problema al que se aplica un tratamiento por ordenador.

He tomado de la RAE las acepciones más cercanas al tema que nos atañe. Pues bien, comenzaré con que no estoy de acuerdo con la parte de la tercera acepción en la que dice “...y posibles soluciones de un problema al que se le aplica un tratamiento por ordenador“. Dar soluciones a un problema considero que forma parte del diseño, y para eso ya tenemos a otros perfiles. Cuando nos encontramos ante un problema, lo primero que hacemos es obtener toda la información (datos, relaciones, semejanzas, contradicciones, etc) que es objetiva del problema. En este punto, dejamos a un lado cosas como “habrá querido decir…”, “supondrá esto que…”, es decir, las cuestiones subjetivas a un lado. Una vez que tenemos bien estructurada la información, entonces es cuando comenzamos a usar nuestro conocimiento en la materia del problema y podemos hacer uso incluso de suposiciones para encontrar una solución. Mi profesor de matemáticas nos decía que los problemas es fácil que se puedan resolver de múltiples formas, especialmente en las matemáticas. ¿Y no es cierto que un mismo proyecto software puede ser diseñado de múltiples formas? Sin embargo, los datos objetivos del problema son únicos, es decir, una persona puede ver un problema y obtener cierta información objetiva y, sin embargo, otra persona, puede ver esa misma información objetiva o incluso otra que la contenga.

A continuación expongo las principales funciones que deben recaer sobre el perfil de analista:

• Localización de las fuentes de información: Una vez que el analista toma contacto con el reto (sustituye al problema antes mencionado) debe detectar sus fuentes de información. En una gran parte de las ocasiones su fuente de información vendrá de usuarios expertos que le proporcionarán la información. En otros casos, tendrá que recurrir a biografía, internet, etc.
• Formalizar el reto: Evidentemente no puede retener toda esa información, necesitará organizarla, estructurarla, revisarla, etc. Por lo tanto, necesita seguir ciertas convenciones o prácticas para que él mismo pueda gestionar esa información.
• Interlocutor entre quien plantea el reto y quienes darán solución al reto: Según esto el punto anterior toda aun más fuerza porque el resultado de formalizar el reto no sólo le servirá a él, sino a otras personas (recursos).
• Velar porque la información objetiva que refleja el formalizar el reto siga íntegra: Tiene que ser capaz de analizar no sólo el reto sino también la solución, pero en este caso con el objetivo de asegurarse de que la información considerada en la solución es correcta.
• Proteger la solución: Siempre pueden aparecer datos que inicialmente estaban ocultos y, evidentemente, no podemos obviarlos, pero tampoco podemos permitir que el desarrollo de la solución deje de ser válido.

Evidentemente, no es fácil. De hecho considero que es un trabajo complicado y que requiere de ciertas habilidades/capacidades como por ejemplo:

• Capacidad de síntesis
• Capacidad comunicativa
• Buena oratoria
• Disciplina
• Orden
• Ser muy meticuloso con todo, incluso con los pequeños detalles.
• Capacidad de abstracción
• Capacidad de conceptualizar

Es probable que me haya dejado atrás tanto funcionalidades como habilidades/capacidades, supongo que cada uno tiene sus propias listas, pero creo estas resumen lo que busco en un buen analista. Personalmente creo que se comete un error cuando se dice que:

• Un analista primero tiene que haber sido desarrollador.
• Cuando se piensa que la evolución de un desarrollador es ser analista.
• Cuando se cree que para analizar hay que conocer las herramientas de usan los diseñadores

Procuraré escribir sobre la relación entre el perfil de analista y el resto de perfiles. Como curiosidad os recomiendo que busquéis en los portales de trabajo ofertas relacionadas con los analistas (informáticos). Al hilo de esta entrada os recomiendo leer “El arquitecto de software en versión española”.

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.