Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: kanban

Avances en burn-down charts: la “burn-up-down” chart

Hacemos Scrumban y eso nos ha obligado a hacer alguna que otra cosa curiosa. Una de ellas consistía en tener dos gráficas el burn-down para nuestras historias de Scrum (las planificadas) y el burn-up para nuestras historias de Kanban (las no planificadas). Básicamente se trataba de poner un objetivo de historias planificadas y una especie de tope a las historias no planificadas… planificar el trabajo que te va a llegar de forma no planificada tiene algo de absurdo, pero se puede hacer. No hay que medir el pasado y esperar que el futuro se comporte. Tener dos gráficas resulta un poco incómodo, aunque no es un gran problema. Reservar ya desde el principio una parte de tu ancho de banda a Kanban denota que tenemos unos POs un poco “volubles”. Tampoco pasa nada.

En cualquier caso en la última vuelta de tuerca a nuestro sistema hemos decidido superponer ambas gráficas para así poder saber de un vistazo cómo va el Sprint independientemente de haya habido mucho o poco Kanban. Aquí os pongo un ejemplo de nuestra “burn-up-down chart”:

En este caso la línea azul señala el ritmo ideal de completado de US de Scrum del Sprint. En rojo vemos la realidad, como la parte de Scrum lleva un pequeño retraso; en amarillo el Kanban real, las historias no planificadas que se han ido terminando. De esta gráfica podemos obtener la siguiente conclusión, la primera semana a pesar de que se acumuló retraso entre las historias planificadas el equipo de desarrollo cumplió con su objetivo (ya que lo que faltó de Scrum se hizo de Kanban), la segunda semana la cosa fue peor.

Al final la manera de leer esta gráfica es sencilla.

  • Si las gráficas amarilla y roja se cortan antes de terminar el Sprint el equipo de desarrollo ha cumplido su objetivo.
  • Cuanto más suba la línea amarilla peor planificación se hizo.

Scrum, Kanban y la matriz de Eisenhower

Érase una vez un Scrum Master que controlaba el proceso Scrumban que un equipo seguía. ¿Le pitan a alguien los oídos?. Dicho de otro modo, para que no se diga que aquí sólo escribimos para los “talibanes agilistas” ;P.

Erase una vez un gestor de un equipo encargado de llevar a cabo tareas planificadas y no planificadas en un periodo de tiempo determinado y cíclico. No sé cual de las dos introducciones es peor.

Érase, también, una vez un Product Owner malvado que no hacía más que meter Kanban en el sprint, haciendo sufrir al Scrum Master y poniendo a prueba la velocidad del equipo. El Scrum Master le insistía al equipo para que no dejara abandonadas las tareas de Scrum, mantuviera una velocidad de Scrum aceptable y consiguiera los objetivos del sprint. Y en estas llegó la retrospectiva y el equipo le afeó al Scrum Master que priorizara el Scrum frente al Kanban, ya que todos son hijos de Dios (del Product Owner en este caso). Así que el Scrum Master se puso a pensar y sacó las siguientes moralejas además de escribir este post.

  • El equipo tiene razón, en teoría, el Kanban es tan válido como el Scrum. La suma de todo nos da la velocidad total del equipo y si los puntos totales al final del sprint son iguales o mayores que los planificados el equipo habrá cumplido con su papel.
  • El Scrum Master también tiene razón, en la práctica, el Product Owner siempre, salvo cambios grandes de requerimientos, espera que todo el Scrum esté acabado en la fecha final de sprint. Si el Scrum se termina, el Scrum Master habrá cumplido con su papel.
  • El hecho de no tener definidos claramente las prioridades del Kanban (FIRE, PRIO, ASAP) puede fomentar estos problemas. El Kanban en Frogtek entra directamente en la pila de producto del sprint y se empieza antes o después en función de lo arriba que entre en la columna. Es decir, es priorizado junto con lo demás (hasta ahí bien), pero luego cuando entra y navega por las diferentes fases no tiene ni más, ni menos prioridad que el resto de lo que está en desarrollo. De ahí que el Scrum Master en algún caso acabe defendiendo lo planificado y el programador quiera que todo se valore por igual, ambos defendiendo su trabajo. Pero ¿debe hacerse?.

Aquí es cuando entra en juego la relación entre las tareas de Scrum, Kanban y la matriz de Eisenhower. Eisenhower se ve que era un tío muy organizado y las malas lenguas dicen que inventó el típico plano cartesiano con cuatro cuadrantes, con un eje señalando la importancia y otro la urgencia. Así tras analizar una tarea en un momento dado podía decidir qué hacer con ella:

  • Urgente e importante. Consejo de Eisenhower: ¡Hazla ya!. Consejo ágil: Normalmente esto es Scrum (en el peor de los casos esto entrará como Kanban de alta prioridad a mitad de sprint pero en ese caso es bastante fácil poner al Scrum Master y al equipo de acuerdo en lo importante que es sacarla la tarea cuanto antes adelante).
  • No urgente pero importante. Consejo de Eisenhower: Planifícala. Consejo ágil: Vuelve a analizarla en la siguiente ronda de planificación y métela como Scrum en el siguiente sprint cuando ya sea urgente e importante.
  • Urgente pero no importante. Consejo de Eisenhower: Delega. Consejo ágil: Normalmente esto es Kanban, ya que su urgencia suele salir a relucir a mitad de sprint y nunca tendrá la importancia suficiente para entrar como Scrum. Este tipo de tareas son las que crean conflicto a veces y las que acaban retrasando los sprints.
  • Ni urgente, ni importante. Consejo de Eisenhower: ¡A la basura!. Consejo ágil: si ves muchas de estas en tu tabla, cambia de Product Owner.

Simplificando un poco se podría asimilar Importante con Scrum y Urgente con Kanban. Es por eso que como Scrum Master creo que Scrum casi siempre debe ir por delante que Kanban. Siendo flexibles, claro. 🙂

Sprints fijos, entregables adaptables (I)

Cualquiera que nos haya seguido desde el inicio sabe que hemos cambiado de metodología varias veces. Unos lo llamarán Kaizen, otros lo llamarán “culo veo culo quiero”, otros lo llamarán “vagabundeos por la el mundo de la agilidad”. La cuestión es que empezamos con un SCRUM chapucero, evolucionamos a un Kanban de postal y ahora estamos con un ScrumBan del que nos podemos sentir bastante orgullosos.

El tamaño del sprint también ha sufrido alguna que otra modificación. Empezamos, como mandan los cánones, haciendo sprints de 2 semanas (casi tan difíciles de estimar como de implementar), el resultado, por novatos, fue tan malo que nuestra evolución por reacción nos llevo al lado contrario, “¿un sprint largo? ¡no!, mejor”, fuera sprints y viva el despliegue continuo. El despliegue continuo (también llamado bug continuo por aquellos tiempos), funcionó mientras teníamos una aplicación beta en un puñado de tiendas alrededor de nuestro apartamento de Bogotá. En cuanto nuestra red de tiendas y nuestra exigencia aumentó volvimos a los sprints, esta vez largos, de 2 meses, dada la gran dificultad para actualizar todas y cada una de las tiendas a mano y volvimos, por tanto, a Scrum pero con un toque de Kanban: Scrumban.

Pronto nos dimos cuenta de que el entorno real en el que se ejecutaba nuestra aplicación no era comparable al de nuestra oficina, ni a nada que pudiéramos reproducir en ella, así que seleccionamos una tienda como beta tester y decidimos instalarle antes las versiones que producíamos. Concretamente decidimos dividir nuestro sprint de dos meses en tres mini-sprints de 3 semanas e instalar la versión resultante de cada uno de esos mini-sprints en la tienda de nuestro compañero Boris para que él nos diera feedback temprano.

El resultado ha sido que las primeras historias que se implementan en el sprint no tienen que esperar dos meses para llegar a una tienda de verdad, sólo 3 semanas, de forma que detectamos los errores antes y los corregimos antes, además de que repartimos los tests exhaustivos pre-release durante todo el sprint en lugar de acumularlos todos al final y mantenemos la tensión (la buena, se entiende) del equipo de forma constante. No hemos, no obstante, modificado la estructura del sprint, que se planifica para dos meses, es decir, no hacemos planficación, demo y retrospectiva en cada uno de los mini-sprints, sino sólo en el sprint principal. Los mini-sprints nos marcan los hitos en los que es necesario alimentar a nuestro beta-tester para ir cazando errores complicados, (para los fáciles tenemos el TDD, los test de integración y demás) que de otra manera se macerarían durante unas cuantas semanas provocando una infección de las buenas al final del sprint.

Así llevamos varios meses y varios meses nos quedan por delante. Hasta que llegue un momento en el que el ritmo de añadir funcionalidad a TiendaTek disminuya, la necesidad de nuevas versiones también y todos nuestros esfuerzos pasen a un entorno mucho más amigable y actualizable como es la web, entonces… ¿qué haremos?

Carta abierta a una historia de usuario

Estimada Historia de Usuario:

Empezamos mal. Tú y yo sabemos que de estimada nada de nada. Algo de cariño, cierta relación amor-odio, un respeto mutuo inquebrantable… eso sí. Pero de estimarte en Frogtek poco o nada.

Es posible que los gurús del agilismo no comprendan nuestra relación, demasiado liberal quizá, poco comprometida dirán. Me llamarán poco ortodoxo, hereje y hasta libertino. Pero es lo que hay, en Frogtek no te estimamos. Y no me refiero a tus tareas internas o a tus detalles más íntimos, me refiero en general, al objeto que centra la atención de cada uno de nuestros programadores cada día por un periodo indeterminado de entre media hora a cinco días.

Sé que te preguntas qué me has hecho, porqué cuando todas las empresas ágiles debaten interminablemente cual es la mejor manera de estimar una historia de usuario, yo te pago con el desprecio. Ellos te asignan puntos, te dedican tiempo, algunos hasta te compran ropa y tú disfrutas del momento orgullosa, coqueta, probándote las distintas tallas. Y yo nada, pasas discretamente por mi tabla, sin grandes entradas, sin protagonismo, sin que hablen los programadores demasiado de ti hasta que no te llevan al huerto. Aquí te pillo, aquí te mato. Y la salida es peor, si te visto no me acuerdo.  En el fondo no sé de qué te extrañas, todas sois similares y a largo plazo me parecéis todas idénticas. Además mis sprints son largos, así que es mejor para los dos mantener las distancias, es que no sólo sois todas iguales, es que encima sois muchas. Dirás que tengo miedo al compromiso, que para llevar dos años en esto de agilismo soy uno inmaduro, que soy caprichoso e infiel, que soy, en definitiva, un cerdo sólo interesado en coleccionar una historia de usuario tras otra, una muesca más en mi revólver… y algo de razón no te falta.

Hubo un tiempo en el que te estimé, lo sabes. Y no funcionó. Era una relación demasiado absorbente, suponía demasiada dedicación, horas y horas hablando de ti, alimentando tu ego cuando tan sólo habíamos empezado a conocernos y nada sabíamos el uno del otro… me agobié. Lo intenté y fue mal, te estimé y tú siempre te quejabas, te sentías, a veces, sobre-estimada, otras, las más, era todo lo contrario. Así que ya ves, para hacerlo mal, mejor no lo hacemos. Además en Aragón siempre hemos sido más de guiñote.

Ahora me va mejor. Soy más feliz y estoy centrado en lo que realmente me gusta. Os trato a todas por igual y al final del sprint he tenido tiempo para todas vosotras que esperáis desde el principio de cada sprint, para muchas otras que vienen sin avisar y para mi mismo, sin comerme la cabeza. Quizá algún día estime una historia de usuario, quizá algún día le vea el valor a una relación más estable, profunda y comprometida, pero de momento… esto es lo que hay.

Siempre podemos ser amigos.

Atentamente,  Frogtek.

Evolucionando hacia Scrumban

Creo que fue Heráclito el que dijo que “todo fluye”, bueno según Wikipedia dijo “En un río entramos y no entramos, pues somos y no somos”, mucho más poético y críptico… Pues bien, en Frogtek no sabemos si todo fluye o no, si somos o dejamos de ser, y de momento, lo de entrar en el río, dado que fuera (en Morillo) a la orilla del río Cinca, hay unos tres grados bajo cero, no nos lo planteamos. Lo que no ha dejado de cambiar desde que empezamos con los método Ágiles ha sido nuestra tabla de Kanban, ni nuestra forma de trabajar. Resumamos en unas lineas nuestros “vagabundeos” por este mundo de las metodologías ágiles.

Tras darnos cuenta enseguida de que Waterfall no nos servía para Frogtek, empezamos queriendo implementar Scrum, y con toda nuestra buena voluntad tratamos de adquirir todos y cada uno de los artefactos que Scrum define. Nos surgieron varios problemas, a saber, reuniones interminables de planificación, estimaciones poco afortunadas, cliente ausente… Lo del cliente merece una explicación, nosotros creamos software para pequeños tenderos en países emergentes, hay millones de ellos pero nunca se van a involucrar real y profundamente en un proceso de diseño como el nuestro (suficiente trabajo y problemas tienen), además nuestro potencial cliente no era uno sólo de ellos o un grupo de tenderos, si no los tenderos del mundo en general, casi nada. El resultado es que David, el CEO, hacía de PO, diseñaba las funcionalidades en función del feed-back informal que recibía en sus visitas por las calles de Bogotá y las empaquetaba en Sprints para que nosotros programáramos.

Pronto nos dimos cuenta que necesitábamos algo más flexible, las reuniones de planificación no es que fueran muy útiles (3 horas de reunión es la receta perfecta para el aburrimiento), no entendíamos bien los datos, burn-down charts, que nos proporcionaba nuestra excesivamente completa herraminenta AgileBuddy, no dábamos ni una con las estimaciones y sobretodo el feed-back recibido por los tenderos no era ni formal, ni periódico, ni definitivo, por lo que las prioridades cambiaban rápido, incluso demasiado para Scrum. Así que Kanban nos pareció más adecuado: implementemos sobre la marcha lo que el PO decida que necesitamos en cada momento y saquemos 10 ó 20 versiones de pre-producción al día (gracias a Dios, bueno y a Julio, por la Integración Continua y HUDSON) y versiones de producción bajo demanda. Perfecto cuando tienes 5 tiendas. Además puedes diferenciar entre US y Bugs, medir la velocidad semanal.

El problema surge cuando en lugar de 5 tiendas alrededor de nuestro apartamento de Bogotá tenemos 25, 30 o más repartidas por toda la ciudad. Y qué ciudad. Moverse de una tienda a otra puede costar cerca de dos horas en algunos casos, la conexión para que los tenderos puedan actualizarse automáticamente TiendaTek (como hacemos en segundos en España) funciona de pena. En resumen aunque la tecnología esté preparada para escalar sin problemas, los temas operativos a pie de calle son un verdadero reto, y cada vez que sacábamos una nueva versión era un dolor de cabeza considerable, primero por lo costoso del despliegue y segundo porque aparecían bugs que nos complicaban todo más si cabe.

Así que se acabó el aquí te pillo aquí te mato (fue bonito mientras duró) y empezamos a plantearnos evolucionar poco a poco hacia Scrum de nuevo. Básicamente retomamos los Sprints de entre 1 y 2 meses, ya no era viable hacer versiones del software del teléfono cada 2 semanas, nos olvidamos de herramientas personalizadas online y recuperamos las reuniones de planificación, aunque seguimos sin estimar de manera propiamente dicha (ya hablaremos de esto pronto), sin embargo la manera que tiene Kanban de tratar con la gestión de Bugs nos seguía gustando… Y en estas apareció Medinilla, su presentación de Scrumban en la Agile Open Spain y casi nos “corren a gorrazos” porque el pobre Pedro definió lo que hacíamos en Frogtek en una de las sesiones como “Kanban puro“. Puro, el que nos metieron.

La consecuencia fue una magnífica reunión de retrospectiva donde dimos unos cuantos pasos adelante y entre los más importantes, el pomodoro síncrono (¡que funciona!) y migrar a un Scrumban más académico. O “lo que es lo mismo” una nueva versión de nuestra tabla, con dos filas (por proyecto, aunque esto realmente da igual) una para las US de Scrum (las que hemos planificado para el Sprint), la superior, otra para los Bugs (los errores que surgen sin previo aviso) y US de Kanban (las que no estaban planificadas, pero surgen por urgencias de todo tipo o mala planificación), la inferior.

Esto nos permite medir nuestra velocidad de Scrum, nuestra velocidad de Kanban “bueno” y la de Kanban “malo“. O lo que es lo mismo, si definimos:

  • [VS], velocidad Scrum
  • [VK+], velocidad Kanban bueno
  • [VK-], velocidad Kanban malo
  • [VT] = [VS] + [VK+] + [VK-]

podemos saber cosas como:

  • El nivel de trabajo máximo al que nos podemos comprometer en un momento dado, [VS] + [VK+]
  • El nivel de trabajo medio que sacamos normalmente adelante, [VS].
  • La tasa de fallos que tenemos, [VK-] / [VT].
  • El “focus factor”, o cómo de enfocados estamos, [VS] / ([VS] + [VK+])

Con un buen equipo de programadores [VK-] debería ser pequeño, con un buen PO y Scrum/Kanban Manager (y un buen cliente, por pedir que no quede) [VK+] debería ser pequeño y por lo tanto el Focus Factor grande cercano al 100%. El objetivo, acercarse al Nirvana de cualquier start-up, “hacemos lo que estaba previsto hacer y a la primera lo hacemos bien“. Si ya encima te pudieras asegurar de que la US en cuestión era lo que quería el cliente y la va usar realmente…

Al final del proceso y si cuentas las US y Bugs que se terminan cada semana te sale una gráfica como la siguiente*.

* En la gráfica a parte de ver los puntos de Scrum (en azul y morado), los de Kanban bueno (en amarillo y naranja) y los de Kanban malo (en rojo) tenemos una diferenciación más: entre US que aportan nueva funcionalidad al usuario y US de infraestructura que que no aportan directamente pero son necesarias para optimizar o como base tecnológica para hacer luego alguna otra cosa. Tuvimos que meter esa diferenciación para controlar el trabajo en las “catacumbas” de nuestros productos, ya que a veces pasar la escoba es necesario y hasta divertido, pero no tenemos que olvidar que nuestra prioridad es el cliente y que “lo mejor es enemigo de lo bueno“.

El curso de SCRUM en Walqa: ¿un éxito? no… dos!

Esto lleva un tiempo un poco parado, es cierto, pero no es que lo hayamos abandonado, es que tenemos mucho trabajo y a veces encontrar tiempo para ordenar las ideas y escribir un post resulta complicado. Hoy, sin embargo, me he decidido a romper este silencio por algo que pasó ayer.

Resulta que estábamos en pleno TPV, dando cuenta del menú de Walqa y viendo un video más gracioso que científico (bueno para gustos colores) cuando unas 20 personas irrumpieron en nuestra oficina porque querían ver nuestra tabla de Kanban. ¿Una manada de groupies de Frogtek?. No. ¿La gente del Agile Open Spain venían a flagelarnos porque tenemos más de un Product Owner?. Tampoco… menos mal. Mucho mejor, era la segunda tanda de gente del Curso de SCRUM que Teresa Oliver estaba dando en Walqa.

Da mucho gusto que te tomen como modelo para este tipo de cosas. Nosotros ni somos perfectamente ágiles según los estándares del “Agilismo puro”, ni pretendemos serlo, ni seguramente conseguiríamos serlo aunque lo intentáramos. Hemos avanzado muchísimo desde que empezamos y estamos encantados de contar lo que hemos aprendido por el camino, y de aprender muchas otras cosas más. Ójala pronto empecemos a ver alguna otra tabla más por Walqa, será señal de que estamos en el camino correcto.

También da mucho gusto saber que las iniciales dudas de si habría al menos 10 personas para hacer un curso de ese estilo en Walqa han sido ampliamente superadas con casi 4o personas… y eso que me consta de 3 ó 4 amiguetes que hubieran querido asistir y no han podido, lástima porque hubieran podido aportar cosas importantes ya que son gente que sabe mucho de tecnología y de proyectos. Bueno, al grano, parece que hay masa crítica así que pronto llegará el momento de mover más la cosa empezando por… ¿un curso de TDD?.

Y por cierto… aprovecho para arrojar el guante para que alguno de mis compañeros que estuvo en la Agile Open Spain 2010 se anime a contar lo que allí vimos, aprendimos y cómo nos dieron algún que otro revolcón… y voy a romper una lanza por Jose, Linares y Pedro que se atrevieron a hablar de Frogtek delante de gurús de la talla de Medinilla & company.

Curso de SCRUM en Walqa

Los próximos días 3 y 4 de noviembre se va a realizar un taller de introducción al SCRUM y algo de Kanban en Walqa. Será impartido por Teresa Oliver de Pragmatic, serán dos sesiones de 7 horas cada una y tiene un precio muy competitivo: 150€  más IVA por persona.

Animo a todos los que nos siguen a apuntarse, nosotros mandaremos a dos ingenieros que seguro que aprenderán cosas interesantes y también podrán enriquecer el debate con nuestra experiencia.

Para inscribirse, poneos en contacto con Beatriz Lorente de Walqa en blorente (at) ptwalqa (.) com antes del miércoles día 20 a las 14:00.

Frogtek Kanban Boards

En Frogtek tenemos dos tablas de kanban distintas en paralelo, una para los Product Owners y otra para el equipo de Tecnología. Primero nació la de Tecnología, como una manera fácil y visual de controlar el trabajo, lo que queda pendiente, lo que está ya acabado o lo que está siendo programado en este momento. El proceso de desarrollo es lo suficientemente “complicado” (tampoco mucho) como para que sean necesarias varias columnas, pero ¿por qué necesitamos también una tabla de kanban para el proceso de diseño de una user story por parte de los Product Owners?. Principalmente, y esto es lo único que voy a contar al respecto antes de centrarme en la tabla de Tecnología, porque el proceso de definición de user stories se ha ido complicando conforme añadíamos técnicas como el Usability Testing y demás y ahora requiere de varias iteraciones antes de que una user story quede archivada y por lo tanto disponible para ir al Backlog de Tecnología, es decir, a la fase de producción.

La tabla virtual de los Product Owners.

Moraleja: las tablas de Kanban son muy útiles incluso si lo que quieres organizar son las tareas del hogar, no es algo reservado a programadores o ingenieros.

La tabla virtual de tecnología.

Nuestra tabla real de tecnología (ver foto abajo) tiene una fila por proyecto y 6 columnas de las cuales forman parte del proceso estrictamente 4, las dos de los extremos no son más que los recipientes de donde salen las user stories y en donde acaban al final.

La tabla real de Tecnología

Son las siguientes:

  1. Backlog: aquí el Product Owner almacena las user stories que ya han pasado por todo el proceso de diseño (en la otra tabla) y están listas para ser empezadas cuando lo considere necesario, es una especie de almacén (los programadores no miran mucho dentro). También almacenamos bugs que cualquiera detecta y que no son muy urgentes, de esta forma el Product Owner puede evaluarlos, descartarlos o priorizarlos según su criterio.
  2. Development – User Interface: de alimentar esta columna se encargan tanto el Product Owner como la diseñadora gráfica. La idea es la siguiente, cuando una user story del backlog está lista (es decir, tiene una descripción exhaustiva y una lista de tests de aceptación) si requiere antes de su programación de la creación de recursos gráficos (iconos, imágenes…) entonces es la diseñadora gráfica la que la arrastra a esta columna (a la parte izquierda) y no la coloca en la derecha (que indica que la user story está lista para pasar a la siguiente fase) hasta que no ha creado todos los recursos y los ha adjuntado para que los usen los programadores. Si la user story, por el contrario, no necesita nada gráfico el Product Owner la mueve directamente a la parte derecha de la columna en espera de que un desarrollador la escoja. Sea como fuere, en este punto todas las user stories tendrán una descripción detallada, una lista de test de aceptación y si lo requiere ciertos archivos adjuntos con los recursos gráficos necesarios. En esta columna también aparecen de vez en cuando bugs urgentes (aquellos que alguien detecta y que hay que resolver enseguida).
  3. Development – Code: Esta columna es responsabilidad de los programadores, cuando uno de ellos se libera acude a la columna Development – User Interface y toma la user story que esté más arriba de entre las de la parte de la derecha. La user story (el post-it en realidad) se mueve a la parte izquierda de esta tercera columna y quedará allí hasta que el programador considere que ha terminado su trabajo. ¿Y eso que quiere decir?. Pues hasta que ha probado, en un entorno lo más real posible, que lo que ha programado cumple todos y cada uno de los test de aceptación diseñados por el Product Owner (amén de los tests unitarios propios y ajenos entre otras cosas). Entonces hace “commit” (o comitea en castellano antiguo) y cruza los dedos para que todo funcione y no haya “momento cerdito” (en ese momento la build se compila en el servidor y los test unitarios se ejecutan, así como los funcionales y los aleatorios… así que es como para echarse a temblar, lo del cerdito lo explicaremos en otro post dentro de poco). Si todo va bien es momento de mover la user story a la parte derecha de la columna donde esperará a que otro desarrollador inicie el proceso de revisión. Por cierto, IMPORTANTE,  esta columna es la única a la que aplicamos WIP (limitación del Work In Progress) y normalmente lo limitamos al número de programadores en el proyecto menos uno. De esta forma no podemos tener dentro de la columna más user stories que programadores en el proyecto menos uno. Lo que hace que, a veces, cuando alguien acaba su tarea se vea obligado a revisar alguna de las user stories que otros hayan acabado para vaciar la columna o a hacer pair programming.
  4. Quality – Review: el proceso de revisión es doble, primero por parte de un desarrollador, que no haya participado en la programación de la user story, y luego por parte de nuestro responsable de QA, Julio. Consiste en utilizando la herramienta Review Board revisar que todo el código y ver que el código es consistente en estilo y con un diseño eficiente. Si hay algún tipo de comentario, el programador original deberá modificar el código y volver a pasar pruebas manuales y automáticas. Al final del proceso y si todo va bien la user story acaba en la parte derecha de la columna esperando a que el responsable de calidad la testee.
  5. Quality – Test: ya estamos llegando al final del proceso. Aquí es donde las cosas se ponen más interesantes ya que Julio se dedica a comprobar que todos y cada uno de los test de aceptación definidos por los Product Owners se han satisfecho. Si encuentra algún error, la user story vuelve directamente a la columna 3 (Development – Code) y el momento cerdito es acogido con regocijo por toda la oficina (menos aquel a quien se le aplica). Esto es un poco como esas casillas del juego de la oca que te mandaban 20 casillas atrás… hay que volver a empezar y arreglar lo que no funciona. Cuando los tests se pasan correctamente la user story se deja en la parte derecha de la columna esperando a que el Product Owner que es quien debe dar al final el visto bueno la archive definitivamente.
  6. Archive: cuando una user story está en la parte derecha de la columna Quality Test es señal de que el trabajo está listo para que el Product Owner lo pruebe. Si comprueba que todos los tests de aceptación se pasan directamente puede mover la tarea a esta sexta columna donde quedará para siempre. Si hay algún error entonces la tarea vuelve a la tercera columna, todo vuelve a comenzar y el “momento cerdito” planea sobre nuestro querido Tester.

Algunos comentarios:

No diferenciamos entre user stories y bugs, salvo por el color del post-its, eso es importante. Los tratamos igual. Un bug normalmente no tendrá test de aceptación, archivos gráficos adjuntos pero si una descripción detallada. Cuando los errores se identifican durante la fase de testeo, no se genera un bug, sino que se rechaza la user story. Si se detectan después, sí y, en ese caso, su destino será: el backlog si no son urgentes, la parte derecha de la columna de Dev – User Interface si lo son o la parte izquierda de la columna de Dev – Code si son críticos. El triaje lo realiza normalmente o el responsable de QA, el Kanban Master o el Product Owner si está disponible (nótese la diferencia horaria, 6-7 horas, entre POs y programadores).

¿Cómo es posible que el tester pueda testear “instantáneamente” cada una de las user stories tras el commit?. Gracias al sistema de integración continua del que ya hemos hablado en varios posts. Cada commit genera una nueva versión de pre-producción que nos sirve para testear lo último que se ha terminado. No hay más que seleccionar buscar actualizaciones en nuestra aplicación y el “upgrade” es automático.

En los pantallazos correspondientes a nuestra tabla virtual (que en el fondo es la oficial, porque es la única que compartimos toda la empresa) no hay lado derecho o izquierdo de las columnas. Simplemente cuando una user story está lista le ponemos un reborde verde.

Si os fijáis en las imágenes que hemos adjuntado la tabla real no tiene columna “Archive” esto es así porque realmente hemos encontrado una utilidad mucho mejor para las user stories (los post-its) terminadas que coger polvo o ir a la caja de reciclar. Lo contaremos en nuestro próximo capítulo junto con lo del “momento cerdito”.

Waterfall vs SCRUM vs Kanban (III)

[Leer Waterfall vs SCRUM vs Kanban (II)]

Un día de Enero de 2010 recibí un correo de David titulado “Hacia Scrum-ban” con un archivo adjunto muy interesante. Se trataba del libro “Kanban and SCRUM: how to make the most of both” un libro muy ameno y fácil de leer que explica las principales características del sistema Kanban. Se trata de un sistema muy poco restrictivo que apenas impone obligaciones y que se puede usar en combinación con algunas de las cosas más interesantes de SCRUM. No me voy a parar a explicar Kanban, el libro lo hace mucho mejor por si solo y no cuesta leerlo más de hora o así. Pero sí me gustaría contar en qué cambió nuestra forma de trabajar.

Para empezar eliminamos las reuniones de planificación, dichas reuniones (que nosotros hacíamos por skype) se habían convertido en eternas conversaciones en las que explicábamos una a una las US incluidas en el Sprint y tratábamos de estimarlas. Estimar se nos daba realmente mal, apenas conseguíamos sacar adelante la mitad de lo previsto cada dos semanas (el optimismo del developer es un tema que tarde o temprano habrá que tocar en este blog), aunque seguramente poco a poco podríamos haber ido mejorando. La idea con Kanban es que no hay Sprints y el flujo de users stories entre Product Owner y programador es continuo. ¡Mucho mejor!, así nos podemos centrar en intentar aumentar nuestra velocidad, es decir reducir el tiempo que nos cuesta desarrollar una user story (el lead time). La idea del flujo continuo hace Kanban muy apropiado para sistemas de mantenimiento en los que los bugs llegan de manera inopinada, sin seguir un patrón fijo y el primer programador que se libera de trabajo se hace cargo de ellos. Nuestro caso no era exactamente ése (aunque los bugs iban llegando) pero el hecho de tener, para nuestra aplicación de contabilidad en el móvil, un cliente tan informal como “los comerciantes más humildes de países emergentes” hacía que el goteo de requerimientos y cambios fuera constante y difícilmente encorsetable en forma de Sprints.

Lo siguiente fue crear nuestras propias tablas de Kanban (la real, en la oficina y la virtual en la web ya los POs están en las Américas), una experiencia entretenida (post-its, gomets, cinta aislante, tijeras, una pared grande…) que además al final nos permitió en la parte virtual abandonar AgileBuddy (demasiado complejo y cuyas métricas no acabábamos de entender) y usar en cambio una herramienta mucho más visual, sencilla e intuitiva, como AgileZen. Lo malo es que hay que asegurarse de mantener sincronizadas las dos tablas, pero nos encargamos de ello todos los días justo antes del stand-up meeting. Este tipo de tablas también se pueden usar para SCRUM, nada lo impide, pero en Kanban son imprescindibles porque permiten que todo el mundo sepa lo que está haciendo el resto a la vez que es fácil chequear/limitar el Work In Progress (WIP) que es la clave de todo sistema Kanban.

A todo esto, nada de este cambio hubiera sido posible si a la vez no hubiéramos implementado un sistema de integración continua con el que obtener una nueva versión suficientemente fiable de nuestro producto con cada commit de una nueva user story. Pasamos de un sistema en el que cada dos semanas había que hacer un complicado paso a producción (pero que aún se podía hacer manualmente) a un flujo continuo de nuevas versiones creadas automáticamente en pre-producción y que al final tenían la misma calidad que las de producción del sistema anterior. Julio puede dar más detalles de cómo funciona todo eso y cómo usamos HUDSON & company para este tipo de cosas, pero podemos decir que tenemos la parte de pre-producción totalmente automatizada y ahora hacemos los pasos a producción tanto en teléfono o en la web bajo demanda y con mucha más seguridad de que las cosas van a ir bien.

El resultado de este cambio fue altamente satisfactorio ya que esta nueva manera de trabajar se adaptaba mucho mejor a nuestras necesidades. Esto no quiere decir que SCRUM no valiera, ya que incluso tenemos que reconocer que aún estábamos al principio de la curva de aprendizaje de SCRUM y hacíamos cosas mal. Ahora también… nos pasamos del WIP de vez en cuando, no hacemos todas las retrospectivas que deberíamos, definimos user stories un poco desiguales (de vez en cuando se nos escapa alguna interminable “looser story”) pero bueno… nadie dijo que esto fuera a ser fácil y, de hecho, si echamos la vista atrás, creo que podemos estar satisfechos de nuestro recorrido. Además no descartamos recuperar los Sprints de SCRUM para según que proyectos y clientes más apropiados, ni evolucionar a cualquier otra cosa que nos parezca mejor o más apropiada en cualquier momento.