Scrumrf. Gestión ágil a la española

Hace unos días Ricardo García de Tonkalabs se puso en contacto conmigo para enseñarme la aplicación que ha creado con otro amigo: Scrumrf.

Se trata de una aplicación para gestionar proyectos de manera ágil. En el Tour podéis ver algunas de las funcionalidades, que son las que cabría esperar como poder crear proyectos, sprints, tareas, gestionar tu backlog, el calendario, y poder ver diferentes gráficas como las de burndown o burnup.

Las metodologías ágiles entre las "skills" más buscadas del momento (al menos en UK)

Hace unos días me llegó un correo del portal de empleo Reed.co.uk donde se comentaba que aas metodologías ágiles son una de las 10 habiliddes más buscadas para contractors en UK. El artículo al que referenciaba se puede leer aquí.

Parece ser que las metodologías ágiles entraron en el Top Ten de habilidades de Reed en Noviembre, y siguen ahí como una de las cualidades más buscadas. Es también interesante que al menos en el Reino Unido (ya no te digo en España) existe una carencia de profesionales formados y cualificados para la aplicación de estas metodologías. Richard Nott, director web de CWJobs afirmaba lo siguiente:

TV oriented development

En una de las empresas en las que trabajé en rlanda me pasó lo que probablemente fue ha sido el momento más rocambolesco de mi carrera. Y es que a veces los managers tienen una extraña concepción de lo que puede y no puede motivar a un equipo.

Os pongo en situación: Un banco pagando X dinero (mucho, mucho) al mes durante 24 meses y la aplicación no ha llegado a nada. Ya se sabe como son estas cosas. Grandes especificaciones que tardan meses en completarse y mientras tanto ni una línea de código, a vivir. Llega el momento y resulta que no llegamos a esos 50000 usuarios concurrentes que necesitamos. Hay que contratar personal extra. Ahí llego yo, con seis meses ya de retraso acumulado y sin rumbo claro. Pasan los meses y poco cambia. Por mucho que queramos hacer cosas todo está dirigido por especificaciones inamovibles e irrealistas. Proyecto abocado al fracaso.

Llega el momento del ultimatum. El banco lo quiere ya y necesitamos la aplicación en quince días. ¿Cómo podemos motivar al equipo? Pues a alguien se le ocurrió la siguiente idea tan fenomenal y que he bautizado como TVDD o TV-Driven Development:

1. Comprar una televisión de 42 pulgadas (doy fe de que se puede reusar posteriormente para apostar a las carreras de caballos).


2. Colocar la televisión en la entrada para que sea lo primero que ven los empleados al entrar en la oficina.


3. Mostrar lo más grande que se pueda la cuenta atrás para el día fatídico. 15,14,13,12,...


4. Preparar un PowerPoint cada día donde figuren las incidencias más críticas en JIRA y mostrarlo en grande como índice.


5. En sucesivas páginas del PowerPoint, relatar la incidencia y el responsable de arreglar esas incidencias.


6. Hacer saber a los empleados que esta medida es para que todos mantengamos el foco en el objetivo a conseguir en las próximas dos semanas y que nadie se dedique a otra cosa más que a solucionar sus incidencias.

Así que los "afortunados", y me incluyo porque a mi me tocó alguna, llegábamos por la mañana tan tranquilo y nos encontrabamos con un pantallón donde veías los días, y si "tenías suerte" tu nombre saldría en grande y tendrías tus minutos de gloria ya que alguien te habría asignado un marrón del que probablemente nunca habías oido hablar porque se había colado entre los cientos de documentos Word que los business analyst habían estado reenviando de aquí para allá.

Si alguno está interesado en aplicar esta metodología en su empresa, por favor que me avise primero para evitar acercarme a un kilómetro a la redonda :-) No os tengo que decir que la metodología falló estrepitósamente. En realidad nos lo tomamos bastante a guasa. Lamentablemente la cuenta atrás terminó en el número 7. El banco canceló el proyecto y hubo que despedir a la mitad de la plantilla.

El final es feliz ya que la empresa perdió mucha de la gente que no estaba favoreciendo al rumbo. De hecho, eramos !9 arquitectos! (para unos 50 desarrolladores) y nos quedamos en 3, lo que es un número mucho más razonable. Conseguimos que se cambiase la forma de trabajo a una metodología ágil y reconstruir el producto con iteraciones claras. La empresa por fin, tras unas semanas consiguió un producto que vender, y de hecho se consiguió vender a varios bancos mucho más pequeños. Han pasado varios años, muchos nos hemos ido y la empresa no está pasando los mejores momentos, pero es uno de los lugares donde más he aprendido sobre como transformar algo que está podrido desde su raíz incapaz de sacar algo a la luz en una empresa que realmente produce productos y vende software que funciona.

En definitiva, que si un proyecto está retrasado, seguramente ni el no tener una televisión de 42", ni el no tener una cuenta atrás, ni el no tener JIRAs amenazantes, ni el traer refuerzos de última hora van a hacer que el proyecto se salve. Profesionalidad y asumir el "mea culpa", reconocer que las cosas se están haciendo mal y cambiar completamente el chip.

En mi opinión, sólo con la honestidad se puede salir adelante en proyectos como este. No sé si alguno tenéis experiencias parecidas. Os animo a compartirlas

Kanban vs. Scrum en castellano

A esto le hay que dar publicidad. Angel Medinilla lo comenta mucho mejor en su blog. Desde hace unos días en Agile Spain estaban traduciendo el libro Kanban vs. Scrum al castellano.

El resultado de la traducción ha quedado un poco grande (74Mb), pero están en ello. Los cracks que nos permiten disfrutar del contenido traducido son Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano.

Gracias a todos ellos. El libro lo podeís descargar desde aquí.

PS: Imagen via crisp.se

We Are Developers!

Se me pasa Enero y todavía no he escrito ningún post serio. Y esto no puede ser. En Diciembre tuve la suerte de ser invitado a las III Jornadas Java de Alicante donde hablé un poco sobre mi experiencia en el desarrollo ágil. Las transparencias de mi charla están aquí, pero como tuvimos mala suerte no hubo manera de recuperar el audio. Así que como hay una serie de diapositivas que necesitan su explicación, voy a ver si tengo la constancia para mantener una serie de posts sobre el tema.

La primera imagen que mostraba en la charla era super llamativa:



Es un cartel de la película 300. Esta es una de las cosas que he aprendido desde que soy desarrollador. Y es que un equipo pequeño puede hacer las cosas mucho mejor que un equipo 50 veces mayor. Parece una barbaridad, pero al menos a mi la experiencia me ha mostrado que es así. En mi caso personal tengo a Jobsket. No nos quiero tirar flores. Somos tres personas y hacemos lo que podemos, lo mejor que podemos. Pero todos los clientes a los que vamos se quedan alucinados con el producto y con el hecho de que seamos tres personas en el equipo. Técnicamente todo el mundo coincide en que somos mucho mejores que las alternativas. El aspecto comercial ya es otra historia, claro :)

Pero no quiero ser egocentrista aquí. En la charla hablaba de otra historia. Una historia de tres amigos que fueron capaces de hacer un producto mejor y más querido que el desarrollado por una empresa con más de cien personas dedicadas al mismo. Mis amigos tenían el software funcionando a los pocos meses, mientras que a la empresa en cuestión le llevó años ponerlo en marcha, y creo que aún están en ello. Cuando lo puso en producción causó el caos absoluto: pésimo rendimiento y consumo de memoria y recursos, falta de usabilidad, quejas de los usuarios, vamos que casi causan una huelga general.

Por el contrario todos los usuarios del software de mis amigos lo quieren con locura. ¿Cómo lo consiguieron? Pues siguiendo una serie de medidas muy simples y de mucho sentido común:

• Desarrollo iterativo.


• Despliegue de versiones cada poco tiempo.


• Implementar sólo las funcionalidades que quieren los usuarios.


• Reunirse frecuentemente con los usuarios y que sean ellos los que decidan como quieren que funcione el interfaz.


• Evitar el desarrollo en cascada. No perder el tiempo con arquitecturas mastodónticas que tardan meses en materializarse.


• No perder demasiado el tiempo en documentación. Es necesaria, pero al estar los usuarios tan metidos en el diseño del sistema, lo cierto es que todos ya sabían como se usaba la aplicación. Evitar documentar al principio.


• Trabajo. No hace falta ser los mejores para que todo funcione. Normalmente con dedicación, empeño y disciplina todo se consigue.

Son unos cracks. La gran clave por la que los usuarios querían la aplicación artesanal y no la llamémosla industrial era sin duda la involucración de los usuarios. En realidad el equipo de mis amigos no eran tres personas, sino que eran ellos tres más los cientos de usuarios que participaron en su desarrollo. Usuarios que fueron construyendo ellos mismos la aplicación. Usuarios a los que se les tuvo muy en cuenta a la hora del desarrollo. Y a la hora de la verdad, los usuarios sienten esa aplicación como suya. Es algo en lo que han participado y que se ha desarrollado tal y como a ellos les es más útil para ahorrarse trabajo. Trabajando de esta manera, es muy difícil que los usuarios prefieran otro proyecto, lo desarrollen, 3, 30 o 300 personas.

No sé si soy yo pero para mi el cartel y la película de 300 me recuerda un montón a un departamento de desarrollo. Me imagino que otros departamentos pueden pensar lo mismo del suyo, pero el hecho de que somos un tipo de trabajadores que suele estar aislado, que sufre la ira de managers y usuarios :), y ahí estamos, resistiendo, intentando ser profesionales y hacer las cosas bien mientras los comerciales nos asedian con nuevos marrones y funcionalidades. No sé como lo veis vosotros, pero a mi se me asemeja la historia bastante. Eso sí, al final los espartanos siempre pierden. mmmm, da que pensar :)

Resumen de Agilismo.es en AdictosAlTrabajo

Que envidia la nota sobre el primer coding dojo organizado por agilismo.es en Madrid. En AdictosAlTrabajo publican una nota sobre como fue este evento. Destacan la edad de los participantes, parece que el preocuparse por tu código, por su calidad, por hacer bien lo que te gusta y en definitiva, por ser un buen profesional viene más a los treinta que a los veinte.

El video sirve para ponerle la cara a muchas de las personas que frecuentan Agile Spain. Y se nota que había muy buen rollo.

Transparencias III Jornadas Java de Alicante

Ayer estuve hablando en las III Jornadas de tecnología Java en Alicante donde estuve hablando de metodologías ágiles y de como aplicar algunos de sus principios en lenguaje Java.

Creo que la charla fue bien y bueno os dejo aquí las transparencias. Me reservaré unos cuantos posts para hablar de la parte de historietas de guerra que en las transparencias no queda muy claro lo que significa.

Desarrollo con Java y metodologías agiles

View more documents from Jobsket.

Una pena no poder poneros el video pero a mitad de la charla se le acabó la pila al micrófono así que dejo de funcionar y no se oía nada por el streaming.

Estaré en la III Jornada de Tecnologías Java en la Universidad de Alicante

Dentro de dos semanitas, el 1 de Diciembre tendré el placer de participar en la III Jornada de Tecnologías Java en la Universidad de Alicante a las que muy amáblemente me invitó a participar Domingo Gallardo.

El título de la charla es "Desarrollo y pruebas de proyectos Java en un entorno ágil" y bueno hablaré un poco sobre lo que voy contando aquí en este blog. Meteré bastantes batallitas irlándesas que es donde más me he empapado de todo lo que implica el agilismo, pero sobre todo intentaré explicar lo que significa para mi el ser un profesional del software, que es lo que siempre he querido ser, y como conseguirlo aplicando técnicas ágiles.

La charla lleva la coletilla Java pero será simplemente para poner algunos ejemplos. El 95% por cien de la presentación se puede aplicar a cualquier lenguaje. Pues nada, que os animo a pasaros por allí.

Agile Open Spain, Octubre 2009, Madrid

En Agile Spain han anunciado el Agile Open Spain un evento que promete ser muy interesante. Me permito copiar de su página web:

Con los objetivos de difundir las metodologías ágiles en España (Scrum, eXtreme Programming. Lean Software Development) y compartir experiencias, el viernes 23 de octubre por la tarde y el sábado completo tendrá lugar el primer Agile Open Spain en las instalaciones de la Escuela Universitaria de Informática en el Campus Sur de la Universidad Politécnica de Madrid.

El Agile Open Spain es un evento sin ánimo de lucro organizado de manera muy participativa. Esta diseñado para compartir entre los asistentes sus experiencias, ideas, experimentos y retos sobre metodologías ágiles (despliegue, planificación ágil, retrospectivas, ingeniería, herramientas, gestión de producto, calidad, etc.), basándonos en el formato de Open Space, para promover la colaboración y que la conferencia se convierta en aquello que sus asistentes deseen. No existe una agenda fijada, sino que entre todos crearemos la conferencia, elegiendo temas y participando. Contaremos con algunas de las personas que más saben de metodologías ágiles en España, así que ten por seguro que la conversación será interesante.

España no destaca por la cantidad de eventos independientes relacionados con el agilismo, así que esta se me antoja como una oportunidad muy buena para aprender, compartir y conocer experiencias, hacer networking, y en definitiva empaparse de todo lo que el agilismo puede ofrecer.

Podéis ver la localización aquí e inscribiros en el evento desde este enlace. El evento es gratuito y las plazas son limitadas.

Charlas sobre metodologías ágiles en Øredev 2008

Al hilo del post anterior. En Viddler hay unos cuantos videos sobre metodologías ágiles con algunas de las presentaciones de la Øredev 2008



Seguro que hay algo interesante por ahí.

Adoptando metodologías ágiles en un entorno hostil

Ayer estuve viendo una presentación de esas que te enganchan. Se trata de Agile Tales de Claudio Perrone que podéis encontrar unas líneas más abajo. Es de esas presentaciones en las que tienes pocas esperanzas puestas pero que en los cinco primeros minutos te enganchan y después quieres saber como termina.

Claudio cuenta en los 50 minutos de la charla la historia de un proyecto "difícil", de esos que hay por ahí. Uno de esos proyectos que llevan años ejecutándose pero del que nunca ha salido ningún resultado. Un proyecto tóxico, en el que alguna compañía ya ha desaparecido en el intento de sacarlo adelante. Pero bueno, eres joven, y todopoderoso. Nadie te puede superar técnicamente. Lo sabes absolutamente todo en tu dominio. Has trabajado muchos años ya, has tenido puestos importantes, eres contractor, en definitiva, un experto. Nadie te puede vencer.




Hasta que claro, llegas a un proyecto como este en donde lo importante no es la capacidad técnica sino la capacidad comunicativa y el carisma. Puñaladas traperas, agendas escondidas, dobles intereses, acomodamiento, hipocresia, sarcasmo, un equipo de desarrolladores absolutamente desmotivado donde el desarrollador más amable te comenta "no eres bienvenido aquí". No parece el entorno más agradable para sacar un proyecto adelante. Seguro que a más de uno le suena.

Pero Claudio lo consiguió, y en esta charla comenta como lo hizo. La base es alterar lo preestablecido. Forzar a los desarrolladores a trabajar en iteraciones pequeñas para que obtengan resultados visibles y aumente la motivación del equipo; forzar al equipo de QA a testear desde el comienzo y a olvidarse de pasar meses preparando docuemntos de pruebas para testear una aplicación que no da visto la luz; acostumbrar a los managers a trabajar con transparencia, a establecer unos objetivos fijos al principio de las iteraciones y respetarlos hasta el final; trabajar duro en las iteraciones para implantar esa inercia en el equipo gracias a la transparencia de los Sprints diarios. Todas estas son algunas de las sugrencias de Claudio que son consecuencias de adoptar una metodología ágil en una empresa anquilosada en procesos obsoletos y abocados al fracaso.

Agile tales of creative customer collaboration

View SlideShare presentation or Upload your own. (tags: communication creativity)

Muy recomendable el escuchar la charla. Aquí tenéis también las transparencias.

La build y la botella

En nuestro trabajo tenemos una botella como la de la foto. Bueno, en realidad es muuuuucho más grande. De un metro más o menos. Es de publicidad de Heineken, de esas de plástico. Tenemos implantado un Cruise Control bastante básico, pero que cumple su cometido. Cuando alguien rompe la build porque ha hecho commits de funcionalidad inacabada, o funcionalidad que rompe los tests existentes, o se ha olvidado de configurar dependencias, pues tiene que poner un euro en la botella.

La verdad es que esta medida tan simple tiene unos efectos muy curiosos. El más obvio y evidente es que nadie quiere romper la build, ya que aunque sólo sea un euro, nadie quiere regalarlo. Así que los desarrolladores somos mucho más cuidadosos con lo que subimos y con no romper nada de lo que hay ya hecho.

Otro efecto muy beneficioso es la cura de modestia. A nadie le gusta ser el que rompe la build. Hoy, un chico nuevo ha roto la build por primera vez, y le tocó poner el euro correspondiente. El hombre fue cabizbajo a depositar el euro ante la guasa general que se suele montar. No es que este hombre sea inmodesto, ni mucho menos, pero es que la sensación que tuve yo la primera vez que rompí esta build es de cura de modestia. Los desarrolladores tendemos a que se nos suba el ego muy rápidamente. Y siempre viene bien que alguien nos baje los humos, aunque sea el Cruise Control, y que tengamos que darnos un paseito ante la guasa general del resto del equipo mofándose (amistosamente) de que te toca apoquinar.

Además la gente es muy legal y hoy otro chico dejaba un euro por la build que había roto ayer. Y es que a uno tampoco le gusta quedar debiendo nada, aunque sea a la botella.

La verdad es que para la cantidad de gente que estamos trabajando en el equipo, y siendo diferentes equipos trabajando en diferentes componentes interconectados, yo personalmente tengo clarísimo que la salud de la build se debe en gran medida a los efectos de esa botella.

¿Estáis usando integración continua en vuestro equipo? Mi consejo, usar una botella. Hará de la build algo más estable y además añade un toque de diversión al día a día. Ah, y a final de año, pues siempre se puede hacer una cena con el dinero de la botella. ¡Faltaría más!

Foto by ^Vanessa^@Flickr

Scrum: Me encantan las Sprint demos

La verdad es que cuanto más trabajo con Scrum, más me gustan las Sprint demos. Como la mayoría sabéis, Scrum se basa en la ejecución de pequeñas iteraciones de varias semanas denominadas Sprints donde se va implementando funcionalidad que se ha decidido al comienzo de cada una de esas iteraciones. Durante los diferentes Sprints se pueden ir lanzando releases, y una vez finalizados todos los Sprints hemos terminado el desarrollo.

Una de las partes más críticas en Scrum es el fin de Sprint. Una vez terminado una iteración se suele hacer una demostración del producto. Estas demostraciones teóricamente deberían incluir a los clientes, pero todo depende realmente de cómo y para qué se está utilizando Scrum en la compañía.

Una de las cosas más curiosas de la demo de final de Sprint es que, al menos en nuestro caso, el desarrollo se para completamente. La gente pasa a centrarse durante una semana completa en sacar la demo adelante, y durante este tiempo pasan muchas cosas. Esto abre la cuestión sobre si es realmente valioso el parar a los desarrolladores durante cinco días completos poniendo esfuerzo en preparar algo que puede que en el futuro cambie, o algo para lo que hay que poner un montón de parches que después habrá que recodificar. Mi opinión es que es tremendamente valioso, básicamente por todo lo que pasa en ese proceso de preparación de la demo:

• Se realiza un esfuerzo por integrar toda la funcionalidad creada durante las últimas semanas en un formato compacto y demostrable al cliente final lo cual revela numerosos bugs y problemas imprevistos. Lo más importante aquí es que estos problemas se detectan por adelantado en las primeras fases de desarrollo, mientras que en una metodología de software tradicional estos errores se detectarían al final y serían mucho más complejos de resolver.
  
  Los desarrolladores somos muy vagos en cuanto a end-to-end testing se refiere. A menudo diferentes equipos trabajan en diferentes componentes y funcionan como islas independientes unas de la otras. Descuidar la interación entre componentes puede traer problemas a largo plazo, y las demos ayudan a forzar la integración frecuente de dichos componentes evitando posibles riesgos.
  


• Irremediablemente se crearán soluciones temporales, o hablando más claro: parches. Estos parches estarán ahí en la demo, pero su presencia obliga a preparar y planificar soluciones reales para el siguiente Sprint. El equipo se ve obligado a reservar el tiempo necesario para solucionar estos problemas, y eso ayuda a no encontrarse sorpresas no planificadas de última hora y el tener que hacer esos sobreesfuerzos de los que siempre nos estamos quejando.


• Las demos obligan al pragmatismo y a la creación de artefactos distribuibles. Otro aspecto que yo considero importante es que los desarrolladores no pueden ser "mega-creativos" y crear soluciones que les lleve meses ver la luz (caso aún posible, pero que de darse estaríamos ante proyectos en si mismos y requerirían Sprints propios). El desarrollador se debe centrar en implementar funcionalidad de manera pragmática y siempre pensando en tener algo que entregar, algo que distribuir, algo que se pueda demostrar.
  
  Esto abre otro debate sobre como integrar en un Sprint funcionalidades no tan fácilmente demostrables como puedan ser cambios internos en la arquitectura, refactorizaciones, etc. Pero eso ya es un tema diferente.
  
  
• Involucración por parte de los desarrolladores. Personalmente creo que la demo no debe ser realizada por única persona, sino que aquí el Scrum Master debe actuar como simple maestro de ceremonias. Obligar a los desarrolladores a participar en la demo les obliga a involucrarse más en la misma. El esfuerzo inevitablemente será mayor ya que no es lo mismo poner tú mismo la cara que el que la tenga que poner otro por ti.


• El efecto moral de ver que el proyecto avanza. En nuestro caso por ejemplo hacemos la demo para toda la compañía. Vosotros ya sabéis como es el desarrollo de software. A menudo la mayoría de equipos trabajan de manera independiente, y prácticamente sólo tienen contacto para conocer los problemas que unos tienen con el trabajo del otro. "¿Oye, qué tenía que pasar en este escenario?", "¡Este caso de uso está mal, estamos perdidos.", "¡Change Request", ...
  
  Me atrevería a decir que es común que la sensación cross-team de las personas ajenas al desarrollo de una aplicación al terminar cada iteración sea más pesimista que cuando el Sprint había comenzado, ya que el único input que han tenido estos equpos han sido problemas. El presentar una demo y mostrar que los objetivos marcados a principio de Sprint se han cumplido, y que no todo está tan mal como la gente se piensa, es una fenomenal forma de mostrar que el trabajo se ha realizado, que todo va bien, y de ayudar a recuperar esa moral que se pueda haber perdido durante el esfuerzo de desarrollo.



• Visibilidad para el cliente. Teóricamente las demos deberían incluir al cliente. En muchos casos esto no es posible físicamente, pero lo ideal es hacerlo. En nuestro caso por ejemplo, las demos internas se trasladan a otro equipo que se encargará de repetirla con el cliente final, ya en sus oficinas. Con la demo el cliente puede comprobar que se está progresando, lo cual en el mundo del software no es tan común, además de poder validar todos sus requisitos y sugerir cambios cuando sea necesario.

Y esto sería más o menos el resumen de lo que pasa durante esos días que se prepara la demo, al menos en nuestro caso. ¿Cómo son vuestras demos? ¿Las hacéis? ¿Se diferencian mucho sobre esto?

Sonar, gestión de calidad del código y Open Source

Un compañero de trabajo me enseñaba hace unos días una herramienta Open Source que no conocía y que me ha parecido realmente muy buena. Se trata de Sonar, una herramienta de gestión de la calidad del código fuente para Java.

La idea es muy simple. Sonar consiste en un servidor web y una base de datos donde se van almacenando métricas sobre nuestro código. La parte cliente está basada en Maven, e integra una serie de productos de sobra conocidos, como son Cobertura, PMD o Checkstyle, de forma que cuando hacemos una build Sonar envía todos estos datos al servidor donde se almacenan y agregan para mostrar información útil sobre el proyecto.



La instalación es muy simple y en su web tienen un tutorial que te muestra como usar Sonar en 2 minutos. Ahora bien, doy fe que para proyectos grandes puede dar algunos problemas. Yo lo he probado en el trabajo y me he encontrado con algunas dificultades:

• La base de datos por defecto (Derby) se queda pequeña fácilmente, así que tuve que utilizar un Oracle Express que tenía por ahí.


• Si usas Maven 2.0.9 hay que eliminar toda extensión cargo-webdav que tengamos en los poms ya que si no se producirá un error.

El proyecto tiene un servidor de demo con estadísticas de proyectos conocidos, pero para demostrar que no es truco me decidí a probarlo con jLibrary, y a mostrar estadísticas para verguenza personal :)

Lo único que hay que hacer es arrancar el servidor de sonar, irse al directorio del proyecto y en vez del típico mvn clean install ejecutar mvn org.codehaus.sonar:sonar-maven-plugin:1.4.2:sonar. Muy sencillo.

Así que vamos allá, lo primero sería la compatibilidad con reglas, buenas prácticas y convenciones de código. Ahí no hemos acabado demasiado mal:



Que por cierto, si navegas por los paquetes te lleva a nivel de clases y si pinchas en una clase te muestra el código fuente coloreado y con tooltips mostrándote cuales son los problemas. Muy útil y muy sencillo.




Entrando ya en temas escabrosos, podemos irnos a la pestaña de métricas que es mucho más interesante. Argh! 10% de cobertura y 12% de test success. Shame on me! La verdad es que ahí se muestra uno de los problemas del proyecto y es que los tests están diseñados para ejecutarse desde una única suite y no individualmente, por lo que la mayoría fallan y por lo tanto hay muy poca cobertura. La excusa para esto siempre fue el tiempo de ejecución de los tests (para que crear un documento en 100 tests si ya lo hago en uno), y acelerar un poco las pruebas. Pero bueno, es una muy mala práctica y no es algo que le pueda recomendar a nadie.



Y en las estadísticas Sonar te muestra también la evolución temporal de todas las métricas. En mi caso como sólo ejecuté Sonar una vez, no hay nada que ver, pero la siguiente imagen muestra la evolución de Wicket:



Más métricas por aquí...




Bueno, y ya quedaría la compatibilidad con reglas:



Y la complejidad de las clases:


Como veis esta herramienta muestra mucha información, y super sencilla de utilizar. Definitivamente pasa a mi caja de herramientas.

Transparencias de la JAOO 2008

Esta semana se celebra la JAOO 2008 y conforme han ido pasando los días han ido poniendo las diferentes transparencias en la web. Ahora mismo hay un buen montón sobre temas muy defentes, pero vaya que las hay que realmente prometen.

La verdad es que había empezado a hacer una lista con los títulos de todas las que me interesaban pero he parado porque la lista me estaba quedando enorme. Escalabilidad, Arquitectura, Metodologías Ágiles, Ruby, REST, Java, Cloud Computing, ...

En especial, la serie de charlas del Martes que parece que estaban dedicadas a Arquitectura parece super-super-super interesante. En fin, una envidia el no poder estar ahí pero habrá que aprovechar para empaparse del conocimiento que emanan estas jugosas transparencias :-)

Agile Spain

Agile Spain es una de las webs que están en los links de mi blog. Links que por otra parte son un desastre porque aunque están muchas de las páginas que leo, otras muchas no las he puesto y otras como ésta han desaparecido; y es que Agile Spain fue una excelente página de referencia, pero ya se sabe que mantener un portal de este tipo requiere mucho tiempo y dedicación, y muchas veces la ayuda, repercusión y reconocimiento que se obtiene es muy poca.

El caso es que José Manuel Beas me comenta que está intentando relanzar la iniciativa, esta vez en forma de grupo de Google y que pretende continuar la labor ejercida por la web. Por ahora la actividad es poca, pero seguro que si hay gente que lee el blog y está interesada en crear una comunidad de gente interesada en las metodologías ágiles pues tendrá mucha más actividad en poco tiempo. ¡El caso es ponerse! Y siempre es agradable compartir comentarios con gente que comparte intereses y profesión.

Así que aquí queda el enlace al grupo de Agile-Spain.

¿Lego como herramienta de gestión ágil?

Hoy, repasando lecturas pendientes me he topado con una entrada muy interesante en la que probablemente es hoy por hoy mi fuente favorita de información, InfoQ. Se trata del artículo Lego is not for kids anymore en el que comentan posts de otras personas que han encontrado en Lego una forma efectiva de gestionar su tiempo y proyectos.

Comienzan con un artículo de Michael Hunger en el que habla de como ha cambiado su forma de trabajar utilizando bloques de lego. Y de manera muy interesante. En la figura de abajo se ven cinco bloques de piezas, cada uno para los diferentes días de la semana. En cada bloque hay piezas de diferentes colores representando los diferentes proyectos y finalmente hacia arriba representaría el tiempo. ¡Realmente visual!



Por otra parte Takeshi Kakeda presentaba en la conferencia Agile 2008 una presentación acerca de como utilizar bloques de lego para la gestión de proyectos y que han subido a SlideShare.

La verdad es que no sé si estoy realmente pecando de iluso pero me ha parecido que presenta ideas muy refrescantes. La propuesta sería comenzar con una base, que prácticamente vendría a sustituir a una pizarra con postits pero añadiendo alguna dimensión más. Las siguientes son algunas de las reglas, bastante simples por cierto:

- Bloques más grandes representan bugs o issues más complicados.


- A más cerca del frente, más prioridad.


- Las fichas llevan notas con pequeña explicación o referencia a la herramienta de gestión de incidencias.

- Las dependencias se representan colocando piezas unas enfrente de otras.

Durante los últimos meses he tenido la oportunidad de disfrutar de la transparencia que te proporciona el trabajar utilizando metodologías ágiles, y personalmente creo que utilizar este sistema sería también beneficioso ya que parece muy sencillo de gestionar y mantener, añade un toque divertido a la organización, y sobretodo ofrece una visión muy sencilla de los proyectos que todo el mundo puede entender, desde el programador más junior hasta el jefe pelo-pincho.

Eso sí, supongo que habría que montar una base bien grande de piezas para cuidar un poco la imagen final del proyecto y que no esté todo apelotonado...



... y lo más importante, ¿cómo evitas que algún gamberrete se ponga a jugar con tu lego?


:-)

Code reviews, ¿buena o mala idea?

Hace poco que en mi empresa un compañero se encargó de preparar un sistema de code reviews. Como era de esperar, ha sido algo bastante polémico dentro del seno de los desarrolladores. Esto me ha hecho pensar bastante sobre el tema.

Uno de los problemas más importantes de las empresas es controlar la calidad del código que se genera para satisfacer las necesidades funcionales. Esa es una de las razones por las que yo mismo recomendé el realizar revisiones de código. Innegablemente, las revisiones de código son necesarias. Uno puede argumentar que con realizar tests funcionales sería suficiente, pero lamentablemente que un código cumpla su cometido funcional no garantiza que cumpla su cometido no-funcional, es decir, no garantiza que sea escalable, mantenible, extensible, o incluso... legible.

Sin embargo, ¿hasta dónde se debe llegar con con las revisiones de código? Mi experiencia es que las revisiones de código demasiado estrictas pueden ser muy contraproducentes según como sea la estructura de desarrollo de una empresa. Es muy fácil que se vean como un "aquí vienen los arquitectos a hacer de policías y hacernos la vida mucho más difícil". Con las revisiones de código es muy, pero que muy fácil caer en el autoritarismo y afectar en la moral de los desarrolladores que verán limitada su capacidad de creación.

Algunos argumentarán que cortar la capacidad de creación de los programadores es algo bueno. Es la típica aproximación de factoría de software. Tener personas robotizadas programadas para hacer lo que se le ha dicho exactamente del modo que se le ha dicho. Bajo esta suposición, el establecer revisiones de código muy estrictas sería el mejor modo de garantizar la calidad. Seguramente lo sería, pero lamentablemente sería el peor modo de garantizar la continuidad del personal. Al cortar la creatividad, no sólo se le esta prohibiendo a los desarrolladores hacer lo que más les gusta, si no que además éstos perderán toda "enlace sentimental" con el código que han creado. No esperes que estos desarrolladores vuelvan atrás, o se queden un par de horas, o piensen en casa como mejorar un código que les han obligado a escribir.

El mejor sistema de code reviews será aquel que permita un equilibrio entre los deseos del arquitecto y las ambiciones del desarrollador. Hay una serie de puntos que pueden hacer llegar a este equilibrio:

• Utilizar herramientas de análisis estático de código: Herramientas como PMD o Findbugs ayudarán a encontrar errores de código básicos, sin tener que advertir a los programadores que han cometido errores. El estar continuamente advirtiendo peresonalmente a los desarrolladores de errores que han cometido es algo que puede ser incómodo, y en algunos casos causar problemas sociales ("ahí viene el listillo a decirme lo que ya sabía"). Para ello, nada mejor que introducir estas herramientas en la build y despreocuparse de los fallos triviales.
• Centrarse en los aspectos no funcionales: Las revisiones de código no deberían centrarse en si el código funciona, o no, ya que eso es algo que desvelarán los tests de integración.
• No olvidar el componente social de las revisiones: Este es un aspecto muy importante. Las revisiones no son un sistema para mostrar que el revisor sabe más, o tiene más autoridad que el revisado. Tampoco son un sistema para asegurarnos de que las cosas se han hecho como hemos ordenado. Es muy importante que las revisiones sean un mecanismo de aprendizaje mutuo. Si las cosas no se han hecho como se recomendaban, seguramente haya razones para ello, que en su caso pueden ser de peso; en caso contrario el revisor debe actuar como mentor y aconsejar, o incluso ayudar realizando pair programming si es necesario.
• Olvidar los aspectos superfluos: Muchas veces, las revisiones tienden a derivar hacia temas bastante superfluos como el "porque esta variable es protected en vez de privada", o "por qué este valor es estático", o "por qué utilizas un espaciado de 6 si nuestro estándar dice que hay que utilizar 4". La mayor parte de estas cosas son realmente superfluas. Algunas se detectan con análisis estático, otras se solucionan con un formateador de código, etc. El valor de las revisiones no reside en estas minucias, sino en detectar el impacto de los nuevos componentes en la arquitectura del sistema. ¿Es escalable? ¿Es fácilmente mantenible? ¿Lo podremos monitorizar? ¿Está haciendo auditoría? ¿Se ajusta a nuestro modelo de componentes? ¿Define interfaces como el resto de nuestros componentes? ¿Está haciendo buen uso de los frameworks? ¿Hay problemas de rendimiento, memory leaks, o faltas graves claramente visibles?
• Dar libertad al desarrollador: Al hilo del punto anterior, una vez revisados los aspectos no funcionales y el impacto en la arquitectura, sinceramente, queda poco por revisar. Darle libertad al desarrollador para que cree sus propios componentes es importante, incluso darle la libertad para mejorar sus creaciones (dentro de un órden) es muy valioso ya que crea vínculos morales entre el desarrollador y sus "criaturas". De hecho, es importante sentarse e interesarse por el cómo ha sido diseñado el componente, y realizar sugerencias en caso de que sea necesario. A fin de cuentas, ¡a los programadores nos encanta hablar de lo que programamos!

Resumiendo, code reviews si, pero con paciencia, calma, y desde un punto de vista didáctico. Todo el mundo puede aprender de las reviews, tanto revisores como revisados.

Dos documentos sobre software factories y costes de desarrollo

Tenía pendiente publicar un artículo sobre un documento que vi en el blog de Kybele Consulting y Javier Garzás me lo ha puesto hoy todavía más fácil.

La entrada que quería publicar era sobre la ponencia consideraciones económicas sobre la fabricación de software que Javier publicaba en el blog de su compañía hace unas semanas. Se trata de una presentación muy interesante y que analiza algo que muchas veces los técnicos nos olvidamos de pensar que es el coste real que puede tener el aplicar una refactorización, buena práctica o patrón para el negocio.



Hoy mismo, también se puede encontrar en su blog otro documento muy interesante. Es un mindmap de los principales factores a tener en cuenta a la hora de mejorar o implantar un departamento, equipo o software factory.

Ambos documentos muy interesantes.

Comunicando ideas con comics

De vez en cuando siempre te topas con algún artículo que supone un soplo de aire fresco a un tema tan tratado como son las metodologías de desarrollo.

En User Interface Engineering han publicado una entrevista con Kevin Cheng en la que explica como en algunos equipos de Yahoo utilizan comics para comunicar historias y casos de uso.

Parece que todo surgió a partir de un encuentro con Bill Buxton, Principal Researcher en Microsoft Research, después de reunirse con Kevin y su compañero Tom Chi, trazaron las ideas sobre lo que posteriormente pasarían a llevar a la práctica con el equipo de Yahoo! Local, que parece que estaba experimentando dificultades.



Según comenta Kevin en la entrevista, la experiencia fue todo un éxito y el feedback enormemente positivo; tanto que otros equipos y otros proyectos pasaron a utilizar esta técnica.

Antes del uso de comics los equipos tenían bastantes dificultades para seguir complejos documentos de requisitos. Según Bill, con los comics consiguen expresar de una manera muy sencilla y clara los diferentes casos de uso de la aplicacón. Es importante destacar que estos comics se centran en las interacciones del usuario con la aplicación, y no pretenden ser diagramas de bajo nivel.

Personalmente, me ha parecido una idea original, muy en línea con las metodologías ágiles. Parece tener realmente mucho sentidos cuando una historia se tiene que compartir, diseñar, especificar entre diferentes personas, departamentos, etc. Todos sabemos lo que pasa a veces con los documentos de requisitos cuando implican a mucha gente: alguien modifica algo aquí, otro añade algo allá, alguien no ve los cambios de la última versión y al final hemos perdido parte del significado.

Poner todo esto en unas cuantas viñetas es una de esas cosas que las piensas y dices: "vaya, esto realmente debe funcionar". Ahora bien, ¿están las compañías preparadas para adoptar una práctica así o es algo simplemente reservado para reductos de innovación como Yahoo? Eso ya es otra historia.

Por cierto, además de la presentación que he incrustado en esta entrada, también hay disponible un podcast con la entrevista.