Redescubriendo el Agilismo

Creación: 19-09-2010

Índice de contenidos

1.Introducción
2. Agilismo extremo
2.1. Historias de usuario, estimación en función del valor de negocio e independencia de historias y tareas
2.2. La importancia del refuerzo visual
2.3. Distintos asuntos distintas pilas
2.4. La higiene del entorno
2.5. TDD e Integración Continua, y otras buenas prácticas
2.6. Separación de dominios
2.7. Foco
2.8. Presión constante / ritmo sostenible.
2.9. Métricas
2.10.
Desviación del diseño
3. Conclusiones
4. Sobre el autor

1. Introducción

La semana pasada tuve la suerte de pasarla en Valencia con Xavi Gost y su magnífico equipo: Joan, Konz, Kike y Sylar.

Antes de seguir quiero aprovechar para dar mil gracias a Luis y toda la gente de KFB por invitarme a su casa y dejarnos hacer este «experimento»!!! Sin ellos no hubiera sido posible!!!

También quiero avisaro que gracias a el esfuerzo de todos estos chicos ya está en marcha beCode() (http://www.becodemyfriend.com/).

Allí me he integrado en el equipo, me he quitado “mis galones” y he trabajando como cualquier otro. Me he puesto a las órdenes de Xavi para aprender técnicas de gestión ágil y programación de un gran Maestro; exprimiendo al máximo cada palabra, gesto, o mirada de Xavi y cada uno de los miembros del equipo (santa paciencia la de Xavi que no se cómo no me ha lanzado por la ventana en más de una ocasión por cuestionar y preguntar cada línea de código que escribíamos).

Por lo pronto puedo decir que ha sido una semana muy intensa donde se han cumplido con creces mis objetivos. Y aunque mucha gente me decía que estaba loco por dedicar mis vacaciones a hacer «eso», les puedo decir que me lo he pasado genial y que hacía tiempo que no disfrutaba tanto.

Todo esto me ha enriquecido mucho porque normalmente estoy acostumbrado a ver entornos mucho peores que el mío (parte de nuestro trabajo en Autentia es la capacitación de equipos), así que salir de mi Dojo para poder ir al de otro maestro y hablar de igual a igual, compartiendo nuestro Kung-fu, a sido una auténtica gozada que me ha permitido ver formas distintas de hacer las cosas.

En este tutorial vamos a ver un poco su forma de hacer “agile”.

2. Agilismo extremo

Xavi y su equipo no hacen agilismo al uso, tipo Scrum o cualquier metodología conocida; pero puedo decir que posiblemente son el equipo más ágil con el que me he encontrado nunca. Ellos han ido refinando el proceso hasta conseguir un proceso ágil extremo.

2.1. Historias de usuario, estimación en función del valor de negocio e independencia de historias y tareas

Cabe destacar el especial hincapié de Xavi a la hora de priorizar las historias en función, única y exclusivamente, del valor de negocio. Rechazando y condenando totalmente la idea de historias o tareas dependientes.

Cada historia tiene que aportar un valor de negocio en si misma, y por lo tanto se debe poder implementar completamente al margen de cualquier otra historia.

Durante la semana hemos demostrado que esto es perfectamente posible, aunque a veces nos auto imponemos barreras mentales que nos hacen creer lo contrario.

Para hacer la demostración hemos cogido dos historias concretas de usuario, una desde la perspectiva de un tipo de usuario y otra desde la perspectiva de un tipo de usuario totalmente distinto, de forma que ambas historias trabajaban sobre aspectos totalmente
distintos. Las hemos implementado las dos completamente, son perfectamente funcionales y no ha hecho falta hacer gestión de usuarios o administración de tablas o … tantas otras cosas que muchas veces nos parecen totalmente imprescindibles para tener algo funcionando.

Otro experimento que hemos hecho para demostrar que las tareas se pueden implementar en cualquier orden a sido poner las tareas en el tablón dadas la vuelta, de forma que no veíamos el texto de la tarea. Las cogíamos al azar y la realizábamos sin saber la que vendría después. Este experimento ha sido otro éxito, y además bastante divertido, sobre todo cuando un día empezamos a sacar tareas que decían “Sigue Jugando !!!”, jejeje una pequeña broma que nos gastó Konz.

Pero las cosas no son gratis, es decir, para conseguir historias y tareas que se puedan hacer en cualquier orden hay que tener muy en cuanta el cómo las escribimos. Aquí Xavi ha demostrado tener una sensibilidad especial.

Además cuando se va a abordar una historia se hace una sesión de diseño con todo el equipo donde se ve que es lo que se pretende conseguir. No es nada formal y se trabaja sobre una pizarra, pero todo el equipo tiene que entender perfectamente que es lo que
significa esa historia.

2.2. La importancia del refuerzo visual

En este punto podemos comentar como usan los colores para representar distintas cosas, y en general como se intentan apoyar en refuerzos visuales o acciones físicas.

Con las acciones físicas se consigue automatizar ciertos procesos y convertirlos en un hábito, y con la información visual se consigue que de un solo golpe de vista se obtenga información.

Por ejemplo las tarjetas rosas son las historias, las amarillas la tareas planificadas, las verdes las tareas que han salido durante el desarrollo después de la planificación (normalmente por una mala planificación porque son cosas que no se habían tenido en cuenta en un principio). Las moradas son defectos, cosas que no están bien
terminadas, diseños que se pueden mejorar, detalles pendientes, … Las rojas son bugs, una cosa curiosa que tienen las rojas es que si aparece una (en toda la semana no apareció ninguna) todo el equipo se para para resolverla.

Otro tema interesante en cuanto al refuerzo visual y que además ayuda a hacer equipo es poner las fotos de los miembros en un panel e ir dándoles “medallas” por cosas bien hechas y cosas no tan bien hechas. Por ejemplo medalla por ser el que más a roto la integración continua, o medalla por no romper nunca la integración continua, al mejor copiloto, al desarrollador del sprint, … Esto anima el ambiente y se consigue más diversión y “pique” sano; además de que volvemos a la idea de que de un solo golpe de vista se consigue ver los puntos fuertes y débiles del equipo.

2.3. Distintos asuntos distintas pilas

Hemos comentado que los defectos los apuntan con tarjetas moradas, pero ¿dónde los apuntan? Esta pregunta es bastante habitual en los grupos que trabajan con Scrum ya que, como no aportan valor de negocio, no se deberían apuntar en el backlog.

El equipo de Xavi lo que hace es sacar los defectos a otra pila, pero esta es más al estilo Kanban, donde se van acumulando y se les da salida poco a poco, pero no interfieren la pila de producto.

Más adelante veremos cuando se les da salida a estas tarjetas.

2.4. La higiene del entorno

Con esto Xavi se refiere a las herramientas que usamos para desempeñar nuestro trabajo. En su caso voy a poner un ejemplo muy concreto para que veáis a que me refiero.

Ellos desarrollan habitualmente con Eclipse, ya sea para hacer PHP o Java, y también usan Subversion como repositorio de código. Es bien sabido por todos que existen varios plugins de Eclipse para trabajar con Subversion, sin embargo ellos tienen prácticamente prohibido su uso, haciendo las sincronizaciones con el repositorio con otra herramienta diferente (en este caso con el SmartSVN).

Muchos podréis pensar que esto es una tontería y una pérdida de tiempo, pero tiene un objetivo bien claro: hacer que seamos conscientes del proceso. Muchas veces cuando las cosas están tan “integradas” nos olvidamos de lo que implica hacer un commit,
simplemente damos a un botón y se produce una “automagia”, como ellos las suelen llamar. Pero hay que tener muy en cuenta que hay que revisar los cambios, que hay que hacer merge, que nos tenemos que actualizar el código de los compañeros, que hay que hacer commits atómicos, …

El hecho de forzarnos a cambiar de herramienta hace que nuestro cerebro se encuentre ante un nuevo contexto, de forma que es más fácil evitar el despiste, ya que estamos centrados en una tarea concreta.

Otro ejemplo podrían ser usar el plugin de Maven para lanzar el Jetty y tener un despliegue de la aplicación, en vez de usar el propio Eclipse para lanzar el Tomcat o el Jetty. De esta forma conseguimos en primer lugar que en cuanto un desarrollador se baja el código del repositorio puede desplegar y probar evitando pérdida de tiempo por tener que configurar el entorno. Y en segundo lugar se consigue probar el war tal cual lo vamos a distribuir, nuevamente evitando “automagias” del Eclipse a la hora de hacer los despliegues.

2.5. TDD e Integración Continua, y otras buenas prácticas

Durante toda la semana se utilizó TDD e Integración Continua, como no podía ser de otra forma ya que no entendemos el desarrollo de calidad sin, al menos, estás dos prácticas.

También se hizo programación por parejas y commits atómicos.

Lo bueno de los commits atómicos es que de forma constante se están subiendo pequeños cambios al repositorio (al menos uno por tarea). Hay un Hudson que continuamente está compilando y pasando todas la pruebas, y además todo el equipo se actualiza cada poco
tiempo (al menos una vez antes de hacer su propio commit).

De esta forma se consigue detectar problemas de forma temprana. Si alguien rompe algo se sabrá en cuestión de minutos.

2.6. Separación de dominios

La única decisión de arquitectura que se tomó antes de empezar fue hacer SOAUI. Para ello decidimos separar totalmente la presentación del negocio, de tal forma que toda la presentación se desarrolló exclusivamente con HTML y Javascript, y la parte de
negocio con Java. La comunicación entre ambas capas era mediante servicios REST y objetos JSON.

De esta forma hicimos dos grupos, los expertos en la vista y los expertos en el dominio (más que nada porque entre que soy medio daltónico y que el Javascript lo tengo bastante olvidado, hubiera sido un desastre si me toca hacer tareas de la capa de presentación 😛 ).

Esta separación fue todo un éxito porque cada grupo podía trabajar en lo suyo sin depender de la otra capa. Si era necesario se mockeaban los servicios, y luego se hacia una integración. Como el contrato lo definíamos al empezar la historia, la integración era trivial.

Una ventaja de esta forma de trabajo es que ahora sería sencillísimo hacer una interfaz para iPhone o Android o en general cualquier otro dispositivo o sistema, ya que todo trabaja en función de los servicios REST.

Otra cosa donde se tuvo especial cuidado fue en la separación de dominios dentro de la parte Java. De hecho cada dominio se diseñó para que sus datos pudieran estar en esquemas distintos de base de datos, forzando a no tener relaciones de integridad referencial entre tablas de distintos dominios. Es decir, de verdad queríamos hacer SOA 😉

Para relacionar entidades de distintos dominios se usaban soft-links en base a las claves naturales de las entidades y nunca a través de las claves sintéticas de la base de datos.

En general todo el desarrollo se hizo en base a las claves naturales.

2.7. Foco

Un problema común en equipos de Scrum es que como en el tablón están todas las historias y todas las tareas, los miembros tienden a coger tareas de historias menos prioritarias, aunque todavía queden tareas de la historia anterior. Al fin y al cabo las tarjetas están ahí, la tentación es fuerte y nosotros débiles.

Para solucionar este problema el equipo de Xavi sólo saca al panel una tarjeta de historia cada vez. De forma que la visibilidad del equipo es de esa única historia.

Con esto se consigue forzar al equipo a trabajar en esa historia, consiguiendo que todo el equipo tenga el foco en solucionar ese problema y no otro.

Para reforzar más aun la idea de centrar el foco en la tarea que se está haciendo, todo el equipo trabaja en pomodoros de 30 minutos. Un sólo pomodoro para dominarlos a todos 😉

Así el equipo está enfocado, cada uno en su tarea, durante el mismo periodo de tiempo. Esto evita interrupciones entre los miembros, que pueden romper el ritmo de trabajo de los compañeros.

En este punto también hicimos un juego divertido: Xavi y yo hicimos de Product Owner, es decir conocíamos toda la aplicación.
Sin embargo al resto del equipo no les contamos nada, de forma que su visibilidad era únicamente la historia que estaban resolviendo. Las historias se hicieron satisfactoriamente, y con esto demostramos que el equipo no tiene, necesariamente, porque conocer toda la problemática de negocio. Aunque en este aspecto pienso que mientras más conocimiento tenga el equipo sobre el problema, mejor podrá resolverlo.

2.8. Presión constante / ritmo sostenible.

El hecho de trabajar todos a la vez dentro del mismo pomodoro crea una sensación constante de presión y un ritmo constante y sostenible muy sano. Y digo sano porque no hay estrés, no hay prisa (si algo tarda 8 pomodoros, pues que los tarde, que esto no es una carrera), pero se crea un clima de concentración muy bueno.

Sí es verdad que al principio es un poco chocante, o por lo menos a mi me pasó, ya que siempre había usado la técnica del pomodoro como una herramienta de gestión del tiempo personal, pero nunca como un mecanismo para gestionar el tiempo del equipo.

¿Y qué pasa si acabo la tarea antes de que se acabe el pomodoro? Es en este caso cuando el tiempo restante del pomodoro se emplea para ir quitando defectos de la pila de defectos. Una vez acabe el pomodoro, y vayamos a empezar el siguiente, volveremos a seleccionar una tarea. Sólo cuando ya no queden tareas pendientes, si quedan defectos, se podrán coger estos al empezar un pomodoro. Es decir una historia no está terminada hasta que se han hecho todas sus tareas y eliminado todos sus defectos.

2.9. Métricas

Todas las métricas se toman en base a los pomodoros. Se estima de forma rápida estilo planning poker, pero haciéndolo con una sola mano, de forma que los dedos que saques son la estimación en pomodoros. Si la tarea es muy gande sacan el puño cerrado y da pie a pensar en que otras tareas se podría dividir la tarea actual.

Luego en el día a día se van a apuntando los pomodoros reales que se van haciendo (simplemente se pone un punto gordo en la tarjeta). Y al final de la semana se hacer el recuento de pomodoros por tarea, pomodoros por persona, se saca la media, la desviación,
se pintan gráficas, …

Con esto quiero recordar que hacer ágil no es anarquía ni mucho menos. Hay que medir el proceso ya que es la única forma de saber si mejoramos. Y hasta un equipo como este que hace agilismo extremo toma métricas de absolutamente todo (pomodoros, historias, tarjetas, defectos, errores, …)

2.10. Desviación del diseño

En este equipo no existe el “daily meeting”, lo que ellos hacen es el “pomodor meeting”. Es decir después de cada pomodoro hacen una pequeña reunión, normalmente de unos cinco minutos, donde ven posibles problemas, desviación en el diseño, tareas completas, tareas emergentes, defectos, …

Una de las principales ventajas de los procesos ágiles es que permiten detectar los problemas de forma temprana. Con estos “pomodor meetings” se consigue detectar problemas en el diseño de forma muy temprana, cuando todavía es muy sencillo cambiar decisiones.

3. Conclusiones

Seguro que me estoy dejando muchas cosas por el camino, pero han sido tantas que es difícil plasmarlas en un único documento.

Lo que está claro es que Scrum no es más que un sabor de “agile”, y que hay multitud de sabores, seguramente todos buenos. Dependerá de mi tipo de cliente, de mi tipo de proyecto, y de mi equipo.

Lo que está claro es que procesos como Scrum no son más que técnicas de gestión, que si no acompañamos con algo más, como buenas prácticas, XP, o “artesanía” en general, se quedarán bastante cojas. Con la ventaja de que, como los métodos de gestión ágil funcionan, nos ayudarán a descubrir rápidamente que desarrollamos software de mala calidad: muchos defectos, retrasos, no se cumplen las espectativas del cliente, …

En resumen, la experiencia a sido totalmente positiva, y os recomiendo que si tenéis alguna vez la oportunidad de integraros en el equipo de trabajo de otra empresa, no lo dudéis y lo hagáis, ya que podrán hacerlo mejor o peor, estaréis de acuerdo o no, pero seguro que veis otros puntos de vista, y eso siempre es enriquecedor.

4. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»

http://www.autentia.com