Al final me he decidido a hacer un pequeño tablero Kanban usando Grails. ¿Por qué Grails?. Pues simplemente porque no lo conozco. ¿Por qué subirlo a github? Pues porque nunca he usado git.  Y la verdad es que me ha enganchado bastante todo esto. Llevo varios días en casa programando hasta la una o las dos de la madrugada. Para alguien como yo, acostumbrado a irse a la cama sobre las once, eso son horas realmente intempestivas. Y desde los viejos tiempos de la universidad que no me quedaba programando hasta esas horas.

¿Qué tal con Grails?

La verdad es que me ha decepcionado un poco. La primera impresión con las primeras pruebas fue muy buena, con poco tiempo y pocas líneas de código se pueden hacer muchas cosas. Pero resulta que uso Google Chrome como navegador y tengo de pantalla de inicio una en la que salen las páginas más visitadas. Pues bien, rápidamente la página que muestra las excepciones de mi aplicación se ha convertido en una de las más visitadas y es un poco deprimente.

Por un lado, groovy, el lenguaje de grails, no es fuertemente tipado, por lo que los IDE no dan un auto-completar demasiado completo, cosa imposible si en ningún sitio aparece el tipo de la variable. Esto hace que los errores de sintaxis al escribir nombres de métodos o atributos estén a la orden del día y no los descubres hasta que compilas, aparte de tener que navegar por el código para ver cómo era el nombre exacto.

Además, grails entiende/busca ciertos atributos en las clases para hacer cosas, como hasMany, allowedMethods, belongsTo, etc. Pues bien, nuevamente un error de sintaxis al escribir alguno de estos puede darte quebraderos de cabeza un rato. Compilar, compila, pero luego un tablero kanban no "hasmany" pegatinas dentro y te sale vacío.

La documentación de grails es bastante escasa. Si un tablero hasMany pegatinas, grails añade automáticamente de alguna forma el método tablero.removeFromPegatinas(). Pues bien, navegando por la documentación de grails no he encontrado ningún ejemplo de ese método, pero curiosamente, buscando en google, he llegado a un sitio de la documentación de grails donde sí pone el ejemplo (me hace la impresión de que es una documentación antigua que google encuentra, pero no está enlazada desde la documentación principal). Pues usas el ejemplo tal cual y no funciona, da errores de "deleted object would be re-saved by cascade". Buscando en los foros, veo que es un error que sale con frecuencia y no he visto en ningún foro que alguien dé una solución definitiva. Y lo peor no es que me dé ese error, porque si hago algo mal es normal que me de error, lo peor es que lo da de forma aleatoria en una misma ejecución. En una misma ejecución creo pegatinas, las borro, y unas las borra y otras falla, pero después de fallar, las vuelves a borrar y esta vez sí las borra … o no. Si grails tiene éxito y se usa, estoy seguro que algo estoy haciendo mal, pero desde luego, la documentación no ayuda a descubrirlo.

No todo es malo. Tiene muchísimas cosas que hacen el trabajo más rápido y más fácil. Por ejemplo, si una clase persistente en base de datos tiene los atributos nombre, apellidos y telefono, grails permite hacer consultas con métodos findAllByNombre(‘nombre’), o findAllByNombreAndApellido(‘nombre’, ‘apellido’) o findAllByNombreBetween(‘nombre1′,’nombre2′) y cualquier combinación larga y extraña que se te ocurra con los atributos de la clase, siguiendo ciertas reglas.

Seguiré jugando unos días con grails y la aplicacioncilla que estoy haciendo,

En una primera parte, comparan scrum con kanban en plan teórico. No explican scrum con detalle ni kanban, es algo que se da por supuesto, simplemente se centran en comparar qué cosas hace uno y qué cosas hace el otro.

En la segunda parte se cuenta una historia real en la que intentan implantar Scrum o Kanban en un departamento de una empresa real. Van explicando los problemas de ese departamento, analizando posibles soluciones, implantándolas y viendo las mejoras que se producen en el proceso. Para su caso concreto se deciden por Kanban y lo van adaptando hasta que se hace cómodo. El tablero Kanban se convierte en una herramienta importante para ver si hay problemas y si se solucionan.

La parte teórica de comparación es más o menos lo ya sabido y como comparación teórica está bien, hay algunos detalles que no tenía claros y se han quedado aclarados, sobre todo en la parte Kanban que quizás conozco menos o está menos documentada que Scrum.

La parte de implantación práctica no me ha gustado demasiado el cómo está escrita. Trata de explicar los problemas del departamento, las posibles soluciones, la implantación de la mismas y los resultados obtenidos, pero lo hace en muy pocas hojas y demasiado por encima para mi gusto. Al final de la lectura me ha quedado la impresión de … "¿ya está?" y de "kanban es maravilloso, fíjate como el departamento del que todo el mundo se quejaba en cuatro meses ha ganado el premio al más productivo".  Parece propaganda.

Sin embargo, si leemos entre líneas (o, al menos, no nos quedamos en los detalles), sí sacamos la conclusión de lo que es Kanban en el fondo. Y en el fondo kanban es detectar los problemas, encararlos y solucionarlos. El tablero kanban ayuda a detectar si hay o no problemas, viendo si las pegatinas se apilan en alguna columna o van fluyendo de principio a fin sin aglomeraciones. Y el tablero kanban ayuda a ver si la solución que hemos puesto al problema es efectiva o no, viendo si las pegatinas se desatascan o no. Lo realmente importante de toda esta filosofía es "ten claro tu objetivo, detecta los problemas para conseguirlo, afróntalos y solucionalos". En el libro, el uso del tablero kanban no es más que la herramienta, lo importante es que detectaron porqué no funcionaba bien el departamento, consiguieron mejorar su forma de trabajo, involucrar a la gerencia para que ayudara a solucionar problemas y mejoraron sus resultados. Todo un reto.

Empezamos antes de verano a intentar hacer Scrum, pero el tema se fue relajando, principalmente debido a que estabamos en fases finales de proyecto y no se podía planificar a una semana vista qué incidencias se iban a encontrar durante las pruebas ni cuánto se iba a tardar en resolverlas. Entonces pensé que quizás en estas fases es mejor pasarse a algo como Kanban, pero quizás por pereza mía no llegamos a formalizarlo.

¿Y en qué ha quedado el tema entonces?

Pues básicamente tenemos la lista de tareas en curso de nuestro grupo. No lo hacemos con un tablero de post-it estilo Scrum o Kanban, sino que inicialmente era un pequeño documento de word con la lista. Todos los días nos reunimos unos minutos y comentamos estas tareas, cuáles están acabadas, su estado de avance, qué problemas hay con ellas y añadimos, si alguien puede abordarlas, más. Como digo, inicialmente era un word que todos los días imprimíamos y luego yo modificaba con lo que se había hablado en la reunión. Este word al final se ha cambiado por una herramienta web de tareas: taskfreak. muy sencilla y cómoda de usar que nos permite tener nuestra lista de tareas en curso siempre actualizada y accesible a todos.

¿Pegas?

Pues los jefes de proyecto no participan demasiado. Ellos nos van poniendo tareas/incidencias en redmine, por correo o de palabra. Yo las aparco y las ordeno en función de la insistencia del jefe de proyecto en cada tarea y de las fechas de hitos. Luego las voy metiendo en nuestra lista de tareas en curso según se van terminando las existentes. Con este mecanismo, nos falta todo eso que pregonan las metodologías ágiles de realimentación frecuente, no ya del cliente, sino del jefe de proyecto.

¿Ventajas?

Las de la reunion diaria. Todos tenemos más claro qué vamos a hacer ese día, somos conscientes y ayudamos al otro cuando tiene problemas y yo, como resposable del grupo, estoy viendo que las cosas se hacen más rápido y con menos errores.

Seguramente cosas como Scrum son maravillosas si se llevan bien y tienen muchísimas más ventajas, pero aunque no se consiga el 100% de sus beneficios, simplemente aplicando algunas de sus reglas (reunión diaria en este caso y lista de tareas priorizada, aunque sea por mí), se obtiene una mejora importante frente a no hacer nada, el cada uno a su bola, las tareas sin priorizar y cada uno elige la que le apetece en ese momento.

Esto me recuerda la famosa regla del 80-20. Quizás con el 20% de las prácticas de Scrum se consigue el 80% de los beneficios. Posiblemente sea exagerado, pero con lo poquito que hacemos he notado una mejora importante en nuestra forma de trabajo.

Mi siguiente reto, una vez establecida la constumbre de la reunión diaria que ya hacemos cómodamente, es elegir alguna otra de las prácticas de Scrum y tratar de implantarla hasta que se convierta en costumbre. Quizás la retrospectiva una o dos veces por semana (no tenemos todavía los sprints, seguimos rematando proyectos).

En Kanban la idea es centrarse en tareas concretas, bajo demanda y no abordar demasiadas cosas a la vez. En la primera columna del tablero están todas las tareas a hacer. El responsable del proyecto pasa las que considera más importantes a la columna "selected" con una restricción: nunca puede tener en esa columna más de dos tareas (el 2 que aparece debajo de selected).

Los desarrolladores, en su columna "Develop", pueden tener un máximo de dos tareas. La columna se subdivide en dos: las que están haciendo en ese momento "Ongoing" y las que ya han acabado "Done". No puede nter más de 2 tareas en la columna "Develop".

Los de pruebas "Deploy", sólo pueden tener una tarea. Una vez probada, se pasa a la columna "Live", que es definitivamente acabada.

Cuando cualquiera se queda sin trabajo porque los límites de las columnas le impiden coger alguna o añadir más, deben intentar ayudar a los del tapón. Es el ejemplo, hacia la mitad del comic, en que un grupo de desarrolladores no pueden coger una nueva tarea puesto que hay un taón en la parte de pruebas. Su misión es ir a ayudar en las pruebas. Incluso el jefe, cuando ve el atasco, intenta ayudar como puede (llevando más café).

La verdad es que es una metodología bastante interesante para fases finales de proyecto, donde básicamente lo que hay son bugs, modficaciones y pequeños añadidos.

Hace tiempo comenté que se nos iba relajando Scrum y que quizás Kanban nos fuera mejor. El motivo era que el Scrum se nos hacía muy difícil en las condiciones actuales de nuestros proyectos: fases finales, con el código prácticamente acabado a falta de corregir bugs, integrar con hardware, probar, etc. Estimar cuánto vas a tardar en arreglar un bug es muy difícil y estimar cuántos bugs vas a encontrar en las pruebas peor, por lo que planificar sprints se nos hacía poco menos que imposible.

Sin embargo, hay muchos artículos que critican a los que dicen "Nosotros no podemos aplicar Scrum" o "En nuestros proyectos no se puede aplicar Scrum", así que la decisión de cambiar de Scrum a otra cosa me dejaba mal sabor de boca. Me daba la impresión de que era más un problema de incapacidad e inexperiencia nuestra que un problema real con Scrum.

Pero el otro día leí un artículo en Dos Ideas: Iterar primero, fluir después. La idea básica que exponen es que en las fase de desarrollo del proyecto se puede usar algo como Scrum, cuando el código está sin hacer, cuando se debe hacer un seguimiento de cómo se va, cuando se puede hacer un listado de historias de usuario, estimarlas y hacerlas. Pero en las fases finales, cuando ya casi todo está hecho y sólo queda corregir errores o hacer mejoras/cambios, Kanban puede ser mas adecuado. Hay que priorizar esos bugs/cambios e ir haciéndolos. Cada vez que se termina uno, se coge el siguiente. No se planifica nada y las cosas están cuando estén.

La verdad es que esa idea me gusta mucho. Aunque quizás mi opinión es muy subjetiva, porque justo esa idea es la que me quita el remordimiento de conciencia de no poder haber aplicado Scrum y apoya mi idea de pasarnos a Kanban dadas nuestras circunstancias. Creo que merece la pena intentarlo.

Así que a la vuelta de vacaciones (por eso escribo poco estos días), cogeré a mi grupo de tres personas con seis proyectos faltos de tiempo a cuestas y les haré la propuesta, a ver qué opinan.

Hace tiempo empezamos a intentar hacer Scrum un grupo de cuatro para atender seis proyectos, con sprints de una semana. Los sprints tan cortos eran necesarios para poder reorganizar el product backlog mezclado con historias de varios proyectos y poder cambiar de unos proyectos a otros en función de sus prioridades. Pero esos sprints tan cortos nos hacían perder mucho tiempo, ya que organizar todos los viernes una o dos demos, era demasiado para enseñar un pequeño incremento de funcionalidad.

Así que intentamos aproximarnos a algo más como Kanban. Teníamos nuestras historias, nuestras reuniones diarias, nuestras tareas, planificación por poker, pero no haciamos las demos.

Y ya no queda ni eso. Uno de los proyectos ha entrado en sus fases finales, así que estamos los cuatro liados con ese proyecto. Nuestro trabajo día a día consiste en probar, encontrar incidencias y corregirlas. Nuestro product backlog es "probar tal tema y corregir". Planificar eso es complejo, una incidencia nunca se sabe cuánto se puede tardar en corregir y menos una semana antes, cuando todavía no la has encontrado.

Así que nada, consideraremos este periodo como un descanso de Scrum, seguiremos con nuestras reuniones diarias (han gustado a todos los miembros del equipo) y a la vuelta de vacaciones retomaremos el Scrum/Kanban.

Llevamos aproximadamente tres sprints de una semana con el grupo de tres desarrolladores que participan en seis proyectos simultáneamente. La verdad es que scrum se aprende en diez minutos, pero me da la impresión de que se puede tardar toda una vida en aplicarlo correctamente.

Nuestro primer sprint fue más o menos bien, seguimos casi todo lo de Scrum a rajatabla y hasta donde pudimos, pero sprint tras sprint, la cosa se va convirtiendo en rutina y las prácticas de Scrum se van relajando. Aquí van los problemillas que vamos teniendo y los porqués.

Uno de los problemas gordos es la tendencia de los programadores a coger las tareas/historias de usuario de los proyectos en los que tradicionalmente están asignados, o de las funcionalidades que tradicionalmente conocen mejor. Esto no es demasiado grave, pero tiene dos pegas importantes:

• Los daily scrum son más un cotilleo que un intercambio de información útil. Cada uno trabaja en lo suyo y cuenta a los demás qué está haciendo, pero a los demás realmente no les afecta. Escuchan por cortesía o por curiosidad, pero no va más allá de eso.
• El que termina su historia de usuario de su proyecto/funcionalidad, tiende a coger otra tarea de su proyecto/funcionalidad que no está planificada. Podría coger alguna de las de los demás, pero el cambio de contexto es muy fuerte: debe actualizar de CVS el otro proyecto, ponerse al día e implementar algo que no conoce. Al ser los sprint tan cortos, de una semana, esto suele suceder el Miércoles o el Jueves, por lo que para un día no le merece la pena ese cambio de contexto.

Sí, es cierto que no deberían tener un proyecto/funcionalidad asignada (y de hecho no lo tienen, pueden coger libremente lo que quieran), pero la inercia de años de trabajo es muy grande para cambiarla en unas pocas semanas. Supongo que no se conseguirá plenamente hasta que se vayan cerrando los proyectos actuales y se comiencen los nuevos.

Otro problema gordo es la corta duración de los sprint. Elegimos esa duración para poder cambiar de semana en semana de un proyecto a otro (recordad, tres desarrolladores, seis proyectos), para poder atender sus necesidades y que ninguno se sienta desatendido mucho tiempo. Haciendo sprints de una semana, podemos decirle a un jefe de proyecto…. "¿puedes esperar a que hagamos eso que nos pides la semana que viene?" y no suele haber pegas. Si le dices, "¿puedes esperar un mes?", pondrá el grito en el cielo.

Pero los sprint tan cortos tienen la pega de organizar demos para ver muy poca funcionalidad implementada. Si para cada semana cogemos un par de proyectos y un par de historias por proyecto y no acabamos alguna de las historias… queda un demo muy pobre. Así que la demo del segundo sprint no la hicimos (había poca funcionalidad nueva que enseñar, ya que casi todo fue un paquete de corrección de bugs).

Con este grupo concreto estoy pensando en algo como Kanban. Por lo que he leido, viene a ser como Scrum, pero sin los sprint fijos cada cierto tiempo. Se hacen las historias de usuario, se sigue llevando el juego de post-it y se van acabando por prioridades, midiendo tiempos. La diferencia es que no hay sprint fijo, por lo que las historias tampoco son fijas. Se pueden ir cogiendo historias sobre la marcha y desarrollándolas, dejando la demo para cuando se considere adecuado. La única limitación es que no puede haber simultáneamente más de X historias haciéndose, más de Y tareas haciéndose, etc.

En cualquier caso, independientemente de lo bien o mal que hagamos Scrum, sí se han notado mejoras muy importantes en el trabajo y paso a enumerar algunas.

• Por un lado, yo, como responsable oficial del grupo y gracias al daily scrum, estoy muchísimo más al tanto de lo que están haciendo en cada momento. Eso hace que no me desespere tanto cuando las cosas parece que tardan, ya que vivo los problemas día a día y sé los motivos de la tardanza. Y también hace que yo curre más, ya que al ser consciente de esos problemas, intento solucionarlos lo antes posible…. ¡¡ Incluso me he puesto a codificar más en serio !!. Antes también codificaba algo, pero picoteando de aquí y de allí, en lo que más me apetecía en cada momento. Ahora lo hago centrado en ayudar a alguien con lo suyo y conseguir que una historia de usuario se termine.
• Por otro lado, aunque cada desarrollador tiende a lo suyo, es consciente de las tareas y problemas de los demás, por lo que siempre tienden más a ayudarse por iniciativa propia. Antes la ayuda se daba sólo si alguien te la pedía y según el momento de la petición, podía ser molesto. Ahora se ofrecen voluntariamente para ayudar, más que nada, porque son conscientes de que pueden ayudar si a ellos les cuesta menos realizar esa tarea.
• Los proyectos van avanzando y hay más visibilidad de ello. Todos somos conscientes de las historias que se van terminando y sabemos qué cosas están o no hechas en cada proyecto y hasta qué punto están hechas. Antes alguien cogía una funcionalidad, se ponía a implementarla y un par de meses después decía "ya tá". Y estaba o no estaba, según lo hábil que fuera ese desarrollador concreto desarrollando y probando. Ahora sabemos día a día qué cosas están y si están bien o todavía con fallos.

Resumiendo, Scrum se aprende en cinco minutos, es muy difícil de hacer correctamente, pero se obtienen importantes beneficios incluso no haciéndolo bien al 100%. Hay más sensación de equipo y la gente trabaja más centrada en unos objetivos concretos.