Archive for September, 2009

Jugar a mejorar

Estaba leyendo un artículo publicado por Xavi Albaladejo en su ProyectosAgiles.org sobre un juego de simulación para enseñar Scrum y me ha venido la idea de hacer un pequeño recopilatorio de artículos que he ido leyendo en los últimos meses y que puede servir para aquellos que queráis venir al Agile Open Spain 2009 con algo visto y, quién sabe, con algo incluso probado.

Empezaré por recomendar una introducción de Scrum en 10 minutos (realmente 7:59). Lo siento, está en inglés, pero merece la pena. Sería genial que algún voluntario le pusiera subtítulos en español, ¿verdad? ;-)

Lógicamente, luego os recomendaría leer la explicación un poco más extensa que hace Xavi en ProyectosAgiles.org. Simplemente pulsad en la pestaña “Qué es Scrum”, pero no os quedéis en leer sólo esa página, profundizad en los hipervínculos a medida que vayáis aumentando vuestro interés. Merece la pena.

Si os ha picado la curiosidad, hace unos meses Xavi Albaladejo, Xavier Quesada y un servidor grabamos un podcast para JavaHispano, donde no hablamos exactamente de Scrum, pero sí hacemos un repaso bastante completo a los fundamentos ágiles en general, que lógicamente son compartidos por Scrum. Creo que merece la pena también, modestia aparte, que echéis un vistazo a la presentación que hice no hace mucho titulada “Los principios ágiles” y que hace un recorrido del Manifiesto Ágil y sus Principios. He adjuntado también mis notas porque sin ellas os podéis quedar un poco perplejos.

Radiadores de información

La vida de un equipo que hace Scrum está muy vinculada al tablón donde se publica la información que produce el propio equipo de manera completamente transparente, entre otras cosas para evitar interferencias por parte de los gestores con la típica preguntita impertinente “¡Qué, chaval! ¿Cómo lo llevas?” (que en realidad quiere decir “¿te falta mucho para acabar?”). Por eso os recomendaría también visitar el blog titulado “Visual Management” (desgraciadamente en inglés) donde Xavier Quesada nos enseña cómo mejorar la gestión del proyecto mediante un mejor uso de los elementos visuales que empleamos para “radiar la información” (es decir, las pizarras, los post-its, etc) y nuestra relación con ellos. Por ejemplo, podemos elegir un tipo de rotulador u otro para escribir en nuestros post-its. Si escribimos con un “boli medio gastado” y con una letra garabateada, estaremos disminuyendo la eficacia de nuestro tablón. Estoy seguro de que si muchos le pedís a Xavier que traduzca su blog, él estará encantado. No en vano es el primer CSC (Certified Scrum Coach) de habla hispana.

Pero si nos quedamos sólo con el tablón, los post-its, las pizarras y las reuniones diarias, probablemente nos estaremos quedando en la parte más cercana al folklore.

Historias de usuario

El trabajo en Scrum se reparte en forma de historias de usuario, que se estiman y priorizan para formar parte de una pila de producto (o “product backlog” en inglés). La mejor referencia para este tema es, sin duda, esta presentación de Mike Cohn, aunque preferiría que os leyérais su libro “User Stories Applied” porque es excelente (y cortito). En cualquier caso, creo que también os podría valer este artículo en español del compañero de Viçenc García.

A mi, todo este tema de las historias de usuario me parece básico, porque si no escribimos bien lo que queremos hacer, ¿cómo vamos a poder hacerlo después? Por eso me interesa tanto todo lo relacionado con las pruebas de aceptación, que algunos preferimos llamar “especificaciones ejecutables” para hacer más énfasis en el hecho de que se escriben antes y no después de la construcción del software. Pero esto ya quedaría fuera de lo que es Scrum (estrictamente hablando).

Si ya habéis llegado hasta aquí, creo que estaréis en la mejor de las disposiciones para aprovechar al máximo el curso gratuito de “Introducción a Scrum” que ofrecieron hace ya unos meses Agustín Yagüe y Juan Gutiérrez en las instalaciones que Autentia nos prestó.

Literatura (en español)

Libros sobre Scrum (y agilismo en general) hay muchos, pero en español hay muchos menos. Yo me atrevo a recomendaros la lectura de dos (elegid vosotros mismos):

Formación

Y si queréis más, podéis ir echando un vistazo al calendario de cursos de Scrum que desde Agile Spain tratamos de mantener actualizado. Si quieres ofrecerte como voluntario para ser tú el que lo mantenga actualizado… no tienes más que ofrecerte. :-) O mejor aún, puedes intentar arrancar un grupo local de Agile Spain. Hay uno en Barcelona y otro en Madrid. Para esto no tienes más que buscarte un lugar donde hacer la primera reunión (tu oficina, la oficina de un amigo, un bar, una escuela… cualquier sitio es bueno para empezar) y avisar por todos los medios que se te ocurran (tienes la lista de correo de Agile Spain a tu entera disposición y a todos nosotros para echarte una mano). Lo demás depende de lo que se os vaya ocurriendo y las ganas que tengáis.

<publicidad>
Yo estoy estudiando seriamente dedicarme a dar formación y coaching ágil en breve, aunque tengo cierto reparo al leer comentarios en contra de los que desgastan el término ágil para su aprovechamiento mercantil. Sea como sea, si alguien está interesado, que se ponga en contacto conmigo y quizás sirva para decidirme definitivamente.
</publicidad>

Por supuesto, tenéis las listas de Agile Spain (la comunidad ágil española) y Ágiles (la comunidad ágil latinoamericana) para cualquier duda o sugerencia que se os ocurra.

Corolario

En cualquier caso, implementar Scrum no os va a garantizar nada más que, si tenéis éxito o fracaso, lo sabréis cuanto antes. Pero no va a reemplazar el que tengáis que tener unas buenas prácticas de ingeniería y una actitud profesional frente al trabajo. Si tenéis inútiles y vagos en vuestros equipos, Scrum sólo os ayudará a identificar que tenéis este problema (ni siquiera os permitirá identificar quién es el más inutil y vago del equipo). Eso sí, si conseguís armar un equipo con ganas de mejorar y capaces de adoptar una alta dosis de autodisciplina, con un poco de paciencia veréis que podréis ir mejorando en las prácticas de ingeniería y, finalmente, consiguiendo éxitos para vuestros clientes, es decir, también para vosotros. Citando a  Alfredo Casado en un hilo de la lista de Agile Spain: “sin excelencia técnica no hay agilismo, sólo post-it pegados por las paredes”.

Como habréis podido comprobar, la mayoría de los recursos que he ido citando en este resumen tiene un cierto tono informal. Incluso los cursos y talleres incluyen juegos (como el que me servía de excusa para arrancar el artículo). Y no es casualidad. Desde el primer momento el agilismo ha estado relacionado con la idea de cambiar la forma de ver el lugar de trabajo como un sitio donde se va a sufrir por otro donde, a cambio de hacernos responsables de nuestro trabajo, nos lo podemos pasar bien.

Nos vemos en el Agile Open Spain 2009. No olvides tu cámara. ;-)

[La foto es una reliquia familiar (aclaro que de alguien que yo no conozco en absoluto) y representa a un grupo de chavales jugando a la pelota. Me pareció que destilaba una cierta ternura y por eso la elegí.]

Tags: , , , ,

Cuidado, soy un tipo peligroso

Mientras estoy terminando el artículo sobre Scrum que dentro de un ratito publicaré, me he topado, gracias a un amigo en twitter, con este otro artículo que, por una parte me ha parecido muy acertado, sobre todo recordando que los métodos ágiles no son balas de plata, es decir, que no siempre son la mejor solución. Pero por otra parte me ha hecho plantearme si es correcta la imagen que transmito de mí mismo al declararme “evangelizador agilista” (“agile evangelist” si echáis un vistazo a mi perfil en LinkedIn).

Después de pensarlo bien y echar mano de mi ejemplar de “Fearless Change”, he llegado a la conclusión de que sí, de que es correcta. Es más, es la que quiero tener en este momento. Porque tengo una pasión y me gustaría poder transmitirla. Esta pasión es el desarrollo de software.

He descubierto que hay formas mejores de desarrollar software y me gustaría que fueran las que se usaran mayoritariamente en las empresas de desarrollo de software de nuestro país. No quiero parecer un “talibán”, alguien que dogmáticamente, sin reflexión alguna, trata de imponer su criterio a todos los demás. Por eso no me autodenomino “Emperador de lo ágil” ni nada por el estilo. Y es que no creo que tener una pasión sea malo, ni tratar de que los demás compartan tu pasión (sin imponerla ni ponerse muy “pesao”) sea malo. Así que creo que, aunque es cierto que hay que empezar a tener cuidado con los que recién llegan a aprovecharse de la marca “agile” y de los que quizás han creado marcas a partir de estos conceptos para “monetizarlos”, también creo que no debemos descartar directamente a aquellos que te tratan de mostrar su pasión simplemente porque se ha convertido en una “buzzword”.

Bueno, lo dejo que no me quiero poner “pesao”. :-)

[La foto es una obra de Warhol que está expuesta en el MOMA de Nueva York y que representa una infinidad de latas de sopa de una misma marca, con lo que no es fácil distinguir una sopa de otra. ¿Moraleja o simplemente arte?]

Tags: , ,

El fin del verano


El fin del verano llegó. Ya estamos de vuelta en el cole, se acabaron las vacaciones, la playa, también se acaba el calorcito, las terracitas… Igual que con el principio de año, las listas de propósitos de enmienda proliferan. En mi caso, mi periodo sabático se ha acabado y comienza un periodo diferente: el de salir del desempleo. Para mi particular inicio de curso tenía algunas tareas e incluso asignaturas pendientes. Con vuestro permiso voy a hacer un recuento público del estado de las mismas.

Mi caja de herramientas

Hace algo más de un año me dije que tenía que mejorar mis conocimientos teóricos y prácticos en varios aspectos de la Ingeniería del Software (concretamente SOA y DDD), montarme un ecosistema software (con su control de versiones, su integración continua, su wiki y todo) y añadir a mi caja de herramientas algunos frameworks, herramientas y lenguajes a los que hacía tiempo que les tenía ganas (concretamente Wicket y Spring 2.5, con sus anotaciones y todo, un DVD con herramientas de IBM que sigue en la estantería aún sin abrir, y Ruby y Groovy).

Bueno, SOA salió de la ecuación bastante rápido. Demasiadas cosas y ya se sabe: “el que mucho abarca, poco aprieta”. Aunque pude asistir a una charla que dió Udi Dahan en Madrid gracias a iMeta y que, además de aclararme un montón de dudas, me enseñó cómo hacer “SOA de verdad”, con servicios realmente autónomos. En cuanto a DDD, sigo ahí peleándome con el calendario y mis obligaciones diarias, pero algún día conseguiré tener mi ejemplo “end-to-end” para poder explicar esto de los repositorios, la “ignorancia de la persitencia” y todo eso que cuando lo lees resulta tan elemental pero a la vez tan difícil de traducir en líneas de código. Incluso creé en su momento un googlegroup, pero me temo que no le estoy dedicando tiempo ninguno y pido disculpas por ello.

El ecosistema software está funcionando en mi portátil a pleno rendimiento: Hudson, Subversion, Dokuwiki, Maven, Eclipse. ¿Se me olvida algo? ¡Ah! ¡Sí! Sonar. Aunque éste lo tengo un poco aparcado… Me quedan en el tintero afinar cosas como tener una buena estructura para los builds con Maven y las pruebas de integración y funcionales, probar cómo va eso de Git, probar el Testability Explorer de Misko Hevery (que por cierto tiene un blog sobre testing muy recomendable).

En cuanto a Wicket, he hecho mis pinitos, pero tengo que explotarlo aún más. Desde luego, lo que tengo claro es que antes muerto que JSF. :) Spring 2.5 está más o menos dominado: no era tan complicado. Y mi relación con Ruby-Rails y Groovy-Grails es un poco rara. No termino de creer en ninguno de los dos, pero aun así este verano he estado insistiendo a mi sobrino Nico para que aprendiera, le instalé el Aptana y le ayudé a refactorizar alguno de sus ejemplos de Ruby (el pobre no había llegado al capítulo de las subrutinas y yo dándole caña, ¡es que no tengo corazón!). El día 3 voy al curso que Escuela de Groovy organiza junto a JavaHispano. Este verano he estado jugando (no me atrevo a decir más) con Eclipse y un plugin bastante apañado, pero sigo sin “pillarle el puntillo”. No sé, debe ser que me pilla un poco viejo o que he perdido el gusto por programar…

Para no perder la práctica he estado entrenando un poco, pero claro, nada serio. Quizás lo más interesante fue el ejercicio del libro de Refactoring. Por cierto, me estoy haciendo (a ratos, porque no consigo tener la continuidad ni la serenidad de espíritu necesarios) un codekata que me está resultando bastante interesante.

De todos modos, hay temas que han salido de mi caja de herramientas (por lo menos por una buena temporada) como OSGi o JAX-WS.

Concordion

¡Ay! Mira que tengo ganas de poner lineas de código mías en Concordion. Incluso tengo un “issue” asignado desde hace la tira… pero de veras que no consigo sacar el tiempo necesario para programar. Ni pomodoros ni nada. Eso sí, conseguí mavenizarlo y que las “releases” se publiquen automáticamente en el Repositorio Central de Maven.

Tengo a medias un taller sobre especificaciones ejecutables que quiero armar usando Concordion, pero una vez más… “el que mucho abarca poco aprieta”.

Agile Spain

Realmente éste ha sido y es mi gran caballo de batalla. En principio mi interés consistía en formarme “formalmente” en esto del agilismo. Así que me apunté a un curso de Scrum de dos días que no tenía mala pinta y que no era “fu*ing expensive” como los CSM. Además lo daba un andaluz, como yo. Mala suerte. Me nació el pequeño en medio del curso. Por suerte, Ángel es un tipo muy amable y comprensivo y me dejó repetir el curso (desde el principio, je, je).

El 7 de junio de 2008 creé la lista de correo “heredando” el nombre de una comunidad que había ido languideciendo en los últimos años, pero no hubo nadie más hasta el 21 de julio que se añadió Juan Gutiérrez desde Finlandia. Pasaron algunos meses hasta que Jorge Uriarte y Xavier Quesada propuesieron la refundación y ahora somos 230 en la lista (aunque seguro que hay más gente que la lee y no está suscrito, pero los Googlegroups no dejan poner Google Analytics :( ) e incluso vamos a organizar el primer Agile Open en España, con 150 asistentes y una lista de espera que nos lleva hasta los 233 que hay ahora mismo. Pero es que además, para primavera queremos organizar algo aún más grande, como ensayo para una conferencia a nivel internacional. El día 2 nos han invitado a una reunión en red.es para ver de qué manera podemos colaborar. !A mi se me ocurren muchas ideas! Y también estoy en contacto con Agoranews (los que están haciendo la cobertura audiovisual del SIMO). Ojalá de unos o de otros podamos conseguir que se graben algunas o todas las sesiones del Agile Open, pero queda poco tiempo así que no sé. ¡Pero apretaré para el evento que haremos en primavera!

Buff, pero éste no era mi objetivo cuando empecé con esto de Agile Spain. Yo sólo quería hacer que los que hacían agilismo en España “salieran del armario”, de esa manera, pícaro yo, sabría a quién enviar mi CV. Pero la cosa se ha salido un poco de madre y me han invitado a grabar un par de podcasts (uno para JavaHispano y otro para 32minutos). Pero el colmo ha resultado cuando desde la Tenerife LanParty 2009 me han invitado a dar una charla sobre esto del agilismo. Y encima han quedado muy contentos y todo. Total, que resulta que cuando escribes en Google “agilismo” salgo en casi todos los primeros resultados. Vamos, que casi sin haberlo querido estoy bien posicionado.

Viendo que esto parecía que me abría una oportunidad profesional interesante, decidí explorarla este verano. Para ello he empezado a trabajar en un estudio de mercado sobre “agile coaching” en España. Quiero aprovechar el Agile Open para pasar una encuesta a los asistentes y así poder sacar conclusiones un poco más científicas que simplemente una sensación. Luego dejaré el estudio a dominio público porque para mi ya será suficiente y, quién sabe, quizás ayude a otros a decidirse por un camino similar.

He hablado con varios emprendedores y freelancers (con Ángel, con Abel, con Leo, con Xavi) y todos me dicen que adelante, sin miedo. Pero yo soy un “cagao” y tengo muchas reticencias. ¿De verdad se vive mejor como autónomo? Mi madre, hace muchos, muchos años, era propietaria de una tienda de ultramarinos (que antiguo suena eso) y estaba esclavizada por su trabajo. Por cuenta ajena, al menos tienes un horario (que tienes derecho a respetar). Pero claro, conociéndome, ese argumento suena a “excusa barata”.

Así que, claro, ahora me surge una pregunta: ¿Y ahora qué? ¡Ah! ¡Sí! Pues decidir si preparo el CV y lo subo a Jobsket o, por el contrario, preparo un porfolio de servicios y me hago freelance “porlagloriademimadre”.

Tags: , , , , ,

La invasión de las métricas mutantes

El escéptico Abel Muiño, Manuel Recena y otros más de la lista de Ecosistemas Software son unos “adictos” a Sonar, de modo que no me ha quedado más remedio que evaluarlo. Con una conexión más o menos decente a Internet seguro que se instala bien y rápido, las instrucciones son muy sencillas. El problema que he tenido es que cuando la conexión a Internet falla, la cosa se complica porque hay muchos jar que descargar… Pero bueno, el proceso es bastate robusto. Requiere de una base de datos: yo he elegido MySQL, pero pueden ser otras.

Para el que no lo sepa, Sonar es una herramienta que sirve para recolectar métricas de muy diversa índole y mostrarlas juntas. Por ejemplo, recopila los tests (maven’s surefire), la cobertura de los mismos (Cobertura), análisis estático (PMD), acomodación a reglas de estilo (checkstyle), etc. Además, elabora históricos, con lo que podemos ver la evolución y todo… Se puede jugar con él durante horas para ver todas las métricas, hipervinculadas con el código, con los tests, etc. Muy chulo.

Examinar un “dashboard” de Sonar es, sin embargo, un tanto agobiante. Mucha información. En mi opinión: demasiada. Ya lo hemos discutido varias veces en la lista de “agile-spain” y en “foro-agiles”, pero mi postura sigue siendo la misma: mejor pocas métricas pero que ayuden que muchas pero que despisten. El objetivo fundamental de un equipo de desarrollo es, desde un punto de vista agilista, claro, entregar valor al cliente al final de cada iteración y de manera sostenible en forma de software que funciona. Y esto es relativamente fácil de medir: cuánto incremento de valor hay en cada iteración. Lo ideal sería medirlo en euros, pero quizás algo complicado… mejor en puntos de historias de usuario.

De todos modos, Sonar es una herramienta que, convenientemente afinada, puede ser de gran, gran ayuda para los perfiles responsables de mejorar la calidad interna de los proyectos. Con Sonar se pueden preparar sesiones de revisión de código muy productivas. En cualquier caso, ésta es una discusión muy rica.

Tags: ,

Evaluación del desempeño ágil

Recientemente he leido una discusión muy interesante en foro-agiles titulada “Planning Poker vs Incentivos por productividad” y que luego pasó a llamarse “Evaluación del desempeño”. He llegado tarde a la discusión pero me ha salido un post tan largo que creo que merecía la pena sacarlo al blog.

Siento llegar algo tarde a esta discusión tan interesante. Quería compartir con ustedes mis experiencias.

En una empresa donde trabajábamos por objetivos, el Director del Departamento elaboró una lista de objetivos individuales y otros de equipo. Por ejemplo, un objetivo individual consistía en alcanzar una serie de capacitaciones internas, basadas en diversos criterios: recibir formación, impartir formación, asumir responsabilidades a nivel departamental, etc. Un objetivo de equipo podía ser conseguir una serie de éxitos en las entregas (resultado de una encuesta al cliente -interno-).

Muchos de estos objetivos se podían medir de manera totalmente objetiva, otros no. Por ejemplo, detalles como la implicación con los resultados del equipo, la aportación de soluciones, la colaboración con los demás, etc. Para esto no es posible tener una métrica y teníamos para ello informes que redactaban los jefes de equipo (rol que hacía de SM y además tenía autoridad jerárquica sobre el resto del equipo).

La última palabra la tenía siempre el Director del Departamento, que es quien realizaba las evaluaciones personalmente. (Era un departamento pequeño). Había una serie de escalones de cumplimiento de objetivos que, dependiendo de tu posición en el Departamento, debías cumplir. No llegar a los objetivos en una serie de trimestres seguidos era motivo de despido. (Previamente había “programas de recuperación” para aquellos que hubieran “suspendido” una o dos veces).

A primera vista parece un esquema que debería haber funcionado muy bien. Pero no. No funcionó PARA NADA. ¿Por qué? Buena pregunta. Creo que aún estamos preguntándonos por qué. :-)

Mi opinión (creo que alguien lo dijo ya antes) es que poner incentivos individuales hace que las personas se enfoquen en ellos mismos y se olviden a veces de los demás. ¿Saben que ocurría en la práctica? Que algunos individuos comenzaron a hacer trampa: por ejemplo, los que debían revisar código (por turno rotatorio) preguntaban qué código podían revisar y así siempre se entregaba código “bueno”. Digamos que “los bomberos no se pisaban la manguera entre ellos”. No se estaba favoreciendo a los buenos y honestos profesionales sino a los que sabían jugar con esas reglas del juego.

¿Cómo se podría haber evitado esto? Lógicamente, sin generalizar porque cada organización es un mundo, creo que los incentivos basados en métricas no son malos pero sí perversos. Son fáciles de implementar porque no obligan a nadie a tomar decisiones (son “objetivos”) pero llevan fácilmente a los individuos a enfocarse en cumplir con las métricas. Incluso a veces puede llevar a desenfocar tanto que los individuos dejen de mejorar todo lo que pueden y mejoren sólo lo justito para cumplir con la métrica. En consecuencia, yo no eliminaría radicalmente este tipo de incentivos “objetivables” o “guiados por métricas” y los reduciría a uno o dos en cada período de evaluación, con un espíritu básicamente pedagógico, tratando de mostrar a los escépticos (siempre los hay) que al aplicar ciertas prácticas se consiguen mejoras en la calidad del proyecto. Por ejemplo, una métrica de este tipo puede ser el número de builds rotos. El equipo (o incluso el individuo) que consiga mantener el build sin romper durante todo el período habrá conseguido no sólo mejorar sus métricas (y el consiguiente incentivo) sino que habrá adquirido unas costumbres saludables para el proyecto y para ellos mismos. Otra métrica para esto podría ser la velocidad del equipo. Incrementar de manera sostenible la velocidad del equipo es bueno para todos, sobre todo si es sostenible (porque si no estaríamos favoreciendo la generación de deuda técnica).

Por otro lado, los incentivos que no son “objetivables” son los más difíciles de implementar porque requieren que alguien “se moje” y diga quién se lo merece y quién no. En el caso de los objetivos de equipo es fácil. Delegamos esta responsabilidad en el cliente (si hacemos Scrum sería el PO). Nosotros eso ya lo teníamos con la encuesta de satisfacción, pero no tenía suficiente peso.

En cuanto a los incentivos individuales subjetivos, no creo que haya nadie mejor que tu jefe para esto. Eso sí, tu jefe debe ser alguien que te vea trabajar día a día (no de oídas, sino en las trincheras). El problema de esto es que requiere de jefes maduros y dispuestos a asumir esta responsabilidad. No todo el mundo puede y/o quiere hacerlo. Lo que nos lleva a… ¿cómo incentivar a los que incentivan? Dilema más conocido como “¿quién le pone el cascabel al gato?” :-)

¿Tenéis vosotros experiencias con este tema? ¿Os parece relevante o creéis que “la gente debe venir motivada de casa”? ¿Esto es cosa de “la gente de Recursos Humanos”?

Tags: