Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: scrum (página 1 de 2)

Charla de Ángel Medinilla en Walqa: el biopic

El pasado lunes día 12 de noviembre tuvimos el honor de recibir a Ángel Medinilla (@angel_m) en el parque tecnológico Walqa (aprovechando su décimo aniversario) para que diera una charla sobre Agile en la empresa. Para el que no lo conozca, Ángel es un coach y consultor agile que lleva ya un tiempo recorriéndose el mundo asesorando a empresas sobre agilismo y contando su experiencia al respecto.

Como no me gustan mucho las notas de prensa en las que se fusila todo lo que dice el conferenciante, voy a escribir acerca de qué reflexiones he inferido tras asistir a su charla. Lo cual nos lleva al siguiente disclaimer…

DISCLAIMER: los siguientes puntos no están firmados por el propio Medinilla, son solo reflexiones obtenidas por mi parte. Al igual que con los biopics (películas basadas en la vida de alguien famoso), cualquier parecido con la realidad puede no ser cierto 😀

  • Las empresas de hoy en día son hijas de las cadenas de montaje y nietas del ejército de Roma. Estamos trabajando en compañías herederas de las ideas de Taylor y Ford (muchas de ellas incluso tienen residuos de las primeras grandes empresas: los ejércitos) y con ello, arrastrando conceptos empresariales basados en paradigmas del pasado, que pueden funcionar para una cadena de montaje, pero no para compañías basadas en el conocimiento. Suele circular por internet una anécdota graciosa: “¿Por qué los reactores de los cohetes de la NASA tienen la anchura de dos culos de caballo?… Pues bien, todo se debe a que los reactores han de ser trasladados hasta Cabo Cañaveral por tren, el ancho de las vías del tren se tomó en función del tamaño de los coches, y el coche en función del tamaño de la carretera, que es un legado del imperio romano, el cual quiso que la carretera tuviese el tamaño de dos caballos, para así permitir la circulación de carros.” Basándonos en esta anécdota, se me ocurre un paralelismo igual de gracioso: ¿Por qué algunos desarrolladores de software van a trabajar con traje y fichan nada más entrar?
  • No hay que ser esclavos de los estándares. Principalmente porque los estándares deberían revisarse continuamente. Siguiendo la filosofía lean, deberíamos usar estándares para asegurarnos de que todos estamos haciendo lo mismo. Intentar algo más complejo que eso solo va a conseguir que tengamos un sistema anquilosado difícil de renovar.
  • Muchos managers son sargentos chusqueros y deberían ser entrenadores. Donde las empresas basadas en los paradigmas de Taylor y Ford necesitaban de un supervisor que controlara la productividad de sus trabajadores, las empresas del conocimiento de hoy en día necesitan de líderes que sepan motivar y potenciar las capacidades de un equipo. Lo que llamaríamos en inglés un enabler, alguien que pueda conseguir que su equipo dé lo mejor de sí mismo.
  • Mejor que intentar ser agile es entender por qué queremos ser agile. Al igual que en el ejemplo del cargo cult, el hecho de poner post-its en la oficina para indicar las tareas (al estilo de las oficinas con sala de relax con el guitar hero porque Google la tiene) no va a hacer que nuestra empresa mejore. Tenemos que entender qué motivaciones tiene agile para poder comprender por qué queremos usar agile (¡o incluso si realmente queremos usarlo!)
  • Agile no es un paracaídas ni la pluma de Dumbo. No nos engañemos: la mera implantación de Agile no va a conseguir que hagamos software de calidad, ni que ingresemos más dinero, o que nuestros competidores vayan a la ruina. Es simplemente una metodología de desarrollo de proyectos mucho más orientada al cambio y a la mejora continua. Podemos migrar una empresa a agile, pero esto no va a  otorgarnos capacidad de mejora, entrega o adaptación. Estas capacidades son los requisitos para el camino Agile, no las recompensas.
  • Tenemos que ser escépticos respecto a Agile. Las metodologías ágiles representan un camino, una serie de filosofías que pueden ser de utilidad para las empresas. Pero no tiene por qué ser buenas para TU empresa. Como decía Henrik Kniberg, Scrum es una herramienta, puedes usarla como te plazca. Cada empresa es un mundo y como tal, es muy difícil que Agile te dé una solución personalizada. Eso sí, si modificas Scrum a tu antojo, luego no vayas diciendo por ahí que Scrum no te ha funcionado 😀

Slides de la charla en http://www.slideshare.net/proyectalis/agilidad-empresarial

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.

Carlos Ble Tour 2011: Primera parada Frogtek

Pues sí. A principios de diciembre Carlos Ble anunció una gran iniciativa, se ofrecía a trabajar un par de días en distintas empresas que le pillaran a mano simplemente a cambio de los gastos de manutención y parte del viaje. Por aquel entonces ya estábamos en contacto con él por que en Frogtek teníamos la ilusión de que Walqa acogiera su curso de TDD, así que nos faltó tiempo para ofrecernos a ser la primera parada de un viaje que seguro va a ser muy provechoso para las empresas que visite y para él. Es un win-win claro (sin tecnología de Redmon de por medio). Para Carlos tiene que ser muy enriquecedor visitar distintas empresas, con distintos productos, distintas metodologías, problemas y personas. Para las empresas es una gran oportunidad de someterse al escrutinio de alguien externo con gran conocimiento de la tecnología y el eXtreme Programming. Fuimos los más rápidos, así que aunque el curso de TDD al final no se llevó a cabo en Walqa, sino en Zaragoza, al acabar Carlos tomó rumbo al norte y recaló en nuestras oficinas por un par de días que se nos hicieron realmente cortos.

El proceso empezó el mismo miércoles por la noche cenando en el Café del Arte una pizza que estaba muy buena pero que era muy difícil de cortar. Hablamos largo y tendido sobre Frogtek y MavenCharts, las fases por las que habíamos pasado, los logros y dificultades que había encontrado por el camino. Me temo que monopolicé un poco la conversación, el problema es que cuando me pongo a contar la historia de Frogtek puedo estar horas y horas y además quería aprovechar los dos días siguientes a tope y para ello tenía que ponerle al día de demasiadas cosas. Mucha información en muy poco tiempo, me temo. 🙂

El jueves empezó la movida. Primero ponte a explicar la tabla de Kanban y date, enseguida, cuenta de que hemos ido complicando las cosas poco a poco, hasta el punto de que explicar el funcionamiento de una simple tabla deja de ser algo trivial. El tiempo dirá si las sucesivas evoluciones de nuestra metodología han sido para bien o hemos complicado demasiado el proceso. De momento estamos bastante satisfechos. Después tuvimos nuestro stand-up (un poco tarde, me costó 1€ que pagué bien a gusto). Decidimos, en honor de nuestro invitado, que no íbamos a hacer nada especial por su visita así que le obsequiamos con nuestro habitual spanglish. Mr. Ble aguantó el tipo (y la risa) sin problemas así que al final del stand-up accedimos a rellenar un pequeño formulario de preguntas que pretendía chequear la “salud” de nuestro grupo y nuestras expectativas ante su visita.

Lo siguiente fue hablar sobre nuestro sistema de integración continua basado en HUDSON y que Carlos le echara un primer vistazo a la realidad de nuestras baterías de tests. Mucho test de integración pero poco unitario, también algunos funcionales pero todos mezclados y poco ágiles. Es difícil hacer TDD si los tests unitarios tardan varios minutos en pasar. Diagnóstico: grandes dosis de buena voluntad pero mucho por mejorar.

Carlos y Alberto peleándose con el GAE

El resto del jueves y viernes tocaba Pair Programming. Primero Javier Linares y nuestro proyecto para Android TiendaTek, luego Alberto Gualis y los tests de lado de servidor en Python y sobre Google App Engine. Tanto Javi como Alberto pueden dar su propia opinión pero sin duda fueron unas horas muy provechosas durante las que pudimos entender como evolucionar nuestra arquitectura y discriminar y organizar nuestros tests para hacer un TDD realmente útil y no “de postal”.

También hubo tiempo para revisar el código de Linares y Carlos el viernes por la mañana.

Al filo de las 3 de la tarde del viernes acabamos la sesión con una retrospectiva que nos reveló distintas cosas:

  • Que dos días escasos habían sido muy cortos para todo lo que nos hubiera gustado aprovechar.
  • Que podríamos mejorar nuestro nivel de calidad pidiéndole a alguien externo pero cercano que usara nuestro producto (¿quizá la tienda de ultramarinos de Cuarte?, ¿la cafetería de Walqa ;)?…)
  • Que nuestra manera de trabajar podría verse beneficiada del uso de repositorios de código distribuidos (nuestro objetivo de migrar a GIT o similar es como el arco iris, que por mucho que camines hacia él nunca lo alcanzas).
  • Que Eclipse es lento para el TDD.
  • Que deberíamos hacer alguna retrospectiva de código (algo parecido hacemos con nuestra reunión mensual de “Nuestros mejores bugs“, pero no tenemos muchos reparos en ignorar la reunión a poco trabajo que tengamos).
  • Que intentáramos desligar funcionalidad transversal para integrarlo en librerías (estamos en proceso ya que Android solo hace muy poco lo permite).
  • Que el código que nunca falla es el que no existe (por eso yo nunca creo bugs).
  • Y que habláramos y habláramos y habláramos… la (buena) comunicación es siempre la base para que algo funcione (bien).

Y de ahí disparados al Dojo… pero eso será otra historia.


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”.

Antiguas entradas