Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: scrum (página 2 de 2)

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.

Waterfall vs SCRUM vs Kanban (II)

[Leer Waterfall vs SCRUM vs Kanban (I)]

Fue así como descubrimos SCRUM, una metodología ágil que implementa de una u otra manera los 4 principios fundamentales del Agile Manifesto, a saber:

  1. Que aunque los procesos y las herramientas son importantes, lo son más los individuos y sus interacciones.
  2. Que aunque la documentación exhaustiva está muy bien, es mucho mejor tener prototipos que funcionan.
  3. Que aunque negociar un contrato con el cliente es vital, es mejor aún que el cliente se involucre contigo en el proyecto.
  4. Y que aunque saber seguir un plan es una estupenda habilidad, más importante es saber cambiar dicho plan a tiempo.

SCRUM define distintos roles para las distintas personas que participan en un proyecto, no voy a entrar en detalles ya que existe multitud de literatura al respecto. Simplemente saber que existe el rol de Product Owner (en adelante PO) que es la persona que, en estrecho contacto con el cliente, define las pequeñas piezas de funcionalidad que se le van añadiendo poco a poco al producto. También se define el rol del Team (equipo de desarrolladores) que son los programadores de la cosa y el del SCRUM Master, que viene a ser el encargado de que todo el proceso que define SCRUM, el ritual periódico por el que hay que pasar inexorablemente, se lleve a la práctica como Dios manda. ¿Ritual?, ¿qué ritual?. Pues principalmente uno muy sencillo, el que sigue:

  • Como nos resulta imposible saber con antelación qué es lo que quiere el cliente dividimos el tiempo en pequeños periodos (Sprints, típicamente de entre 2 y 4 semanas) sobre los que creemos tener suficiente visibilidad. Es decir, “no tengo ni idea de cómo va a evolucionar mi producto dentro de 6 meses pero sí creo saber que mi cliente quiere ver tales características funcionando dentro de 2 semanas”… Esto tiene que ver con los puntos 3 y 4 del Manifiesto Ágil (involucrar al cliente y gestionar el cambio).
  • El PO, por lo tanto, estudia con el cliente la funcionalidad que les gustaría tener disponible en la próxima versión de la aplicación. Y luego participa en la reunión de planificación de principio de Sprint en la que, junto con el Equipo de Desarrollo, se clarifica qué hay que hacer y se decide quién hará qué y cuánto tiempo costará. Punto 1, sobre las personas y las interacciones.
  • Durante todo el Sprint el Equipo de Desarrollo lleva a cabo reuniones diarias para intercambiar información. De nuevo reforzando el punto 1 del Manifiesto.
  • Cuando se acaba el Sprint se hace una reunión de Revisión y Demo en la que el PO muestra al cliente, o los desarrolladores al PO (depende) la nueva versión del producto con las mejoras de las últimas dos semanas ya listas. Punto 2, mejor un prototipo que un infumable tocho de documentación obsoleta.
  • El ritual termina con la reunión de Retrospectiva, donde el Equipo de Desarrollo junto con SCRUM Master y POs revisan el proceso y proponen mejoras para el siguiente Sprint.

Y vuelta a empezar. Hay normas extras, peculiaridades, cosas divertidas y complicaciones sobre las que se podría profundizar mucho, pero básicamente esto es SCRUM.

En nuestro caso la cosa empezó bastante “de andar por casa”. El PO era PO y SCRUM Master a la vez, los programadores no hacían Stand-ups… Cowboy-SCRUM como bien dice Pablo. Pero bueno, la intención es lo que cuenta, durante un tiempo al menos.

Con la nueva oficina la cosa mejoró, al menos el equipo técnico ya se veía las caras. Stand-ups, Sprint Plannings, Sprint Reviews, Sprint Retrospectives… toda una plétora de reuniones salpicaba nuestro calendario. Mucha diversión mientras a la vez tratábamos de montar un entorno de desarrollo decente con pre-producción, producción, repositorios de código, branches… la juerga padre vamos. El típico momento en el que a los novatos emprendedores les empiezan a crecer los enanos y se dan cuenta de que ser profesional es difícil, muy difícil y complejo, muy complejo.

Lo que veis más arriba era nuestro día a día por aquellos tiempos. Habíamos conseguido ya tener un proceso automático que compilaba todos los días a las 15:00 CET (a primera hora de la mañana de nuestros POs en USA y Colombia) una versión de preproducción. Al final del Sprint sacábamos dos versiones de producción, una el viernes después del Review del jueves y otra el domingo con las US (User Stories, pequeños fragmentos de funcionalidad) que nuestro programador exiliado en Santiago de Compostela hacía los fines de semana. Resultado: habíamos dado nuestro primer paso hacia un concepto que desconocíamos, la Integración Continua… y nos salían bugs por todos lados. Fue por eso que empezamos también a interesarnos por cosas como el TDD y las pruebas unitarias automáticas y nos empezáramos a preocupar de que la frase “pues en mi emulador funciona” se oyera cada vez menos.

En lo que respecta a SCRUM dimos un paso de adelante contratando el servicio AgileBuddy una página web que te permite gestionar distintos proyectos con sus respectivos Backlogs (el conjunto de funcionalidades a programar), los Sprint Backlogs (cosas a programar durante el Sprint), etc, etc. Se trata de una útil herramienta para gestionar tus proyectos usando esta metodología. Lo mejor, que te dota de un marco de trabajo donde tienes todo mucho más controlado y que te calcula automáticamente las métricas de tus proyectos (Burndown chart y demás). Lo peor, que a veces no es fácil entender la forma que tienen estas herramientas de calcular sus métricas y también que quizá entraba en demasiado detalle y era necesario desglosar tareas, imputar horas de forma no siempre tan fácil o intuitiva como nos gustaría.

No fue AgileBuddy, no obstante, la razón por la apenas 4 meses después decidimos cambiar al Kanban. ¿Cambiamos por las razones adecuadas?, ¿fue un cambio precipitado?, ¿estábamos haciendo suficientemente bien SCRUM?… Todo eso y mucho más, en el próximo capítulo.

Waterfall vs SCRUM vs Kanban (I)

Ha llegado la hora de profundizar un poquito más en la pequeña historia de Frogtek.

Cuando a finales de 2008 se empezó el desarrollo de un primer prototipo la situación era la siguiente. Un CEO que vivía en Nueva York, que quería crear una herramienta en un teléfono móvil para ayudar a los tenderos de países emergentes (México, Colombia) a llevar la contabilidad y un par de programadores en Huesca y Zaragoza (España) que en sus ratos libres aprendían a programar para Android. Interesante panorama, y no porque CEO y programadores estuvieran deslocalizados o Android fuera una plataforma en pañales, ni nada por el estilo… si no porque la probabilidad de que el bueno de David diseñara algo remotamente útil para un comerciante de Bogotá y lo especificara sin ambigüedad para su desarrollo en España era exactamente igual a cero. Sin embargo, se intentó. Ahí va una de waterfall…

Waterfall (o cascada) es la metodología clásica industrial que define distintas fases secuenciales a la hora de implementar un producto. Simplificándolo mucho sería algo así como:

  1. Planificación y análisis
  2. Diseño
  3. Implementación
  4. Test

Qué fácil ¿no?. Pues no. ¿Y por qué no?. Pues como diría nuestro amigo Medinilla:

porque el software no es un tornillo“.

Parece una afirmación de perogrullo y doy fe de que esgrimida delante de cualquier grupo de estudiantes de ingeniería provoca una media sonrisa que bien puede venir a querer decir “cada día traen a tipos más raros a dar charlas” o “eso lo he entendido”, una de dos. Para los más curiosos: el software no es un tornillo porque, y que no se me enfade ningún ferretero (seguro que el mundo de los tornillos es también complejo y está lleno de magia y pasión), los tornillos son “fáciles”. Cuando uno dice “tornillo” todo el mundo piensa en algo más o menos parecido y si además le añades las palabras “cabeza plana”, “4 mm de sección”, “paso de rosca de 1 mm”, “dextrógiro”, “de latón”… seríamos incluso capaces de construir tornillos idénticos de forma totalmente independiente (el que sepa como diablos se hace un tornillo, claro, que no es mi caso). Lo curioso es que, si bien todos parecemos estar más o menos de acuerdo en que “el software no es un tornillo”, intentemos aplicar el mismo método de fabricación para un tornillo que para… pongamos… ¿Facebook?.  😉

Pero volvamos al caso de Frogtek. Nuestro intento de crear un documento de requisitos para TiendaTek (nuestra caja registradora inteligente para teléfonos móviles) vía Waterfall-Cowboy (¡gracias por la corrección Pablo!) reunía todos los ingredientes para un fracaso sin paliativos…

  1. Sistema complejo de describir, ¿alguien ha intentado describir en un word y sin ambigüedad ninguna Facebook?, pues una caja registradora no es mucho más fácil.
  2. Producto final desconocido, como toda start-up que se precie de serlo una cosa es la idea original y otra lo que alguien acabe comprándote.
  3. Cliente remoto, ya no es que cambie de idea, es que ni siquiera es único, son millones, en países exóticos y lejanos y con prácticas y problemas que ni aquí, ni en Estados Unidos podemos entender.

… así que el análisis en cuestión no pasó de la versión 0.9. Enseguida, cansados de actualizar un documento infumable que siempre estaba obsoleto decidimos (o más bien David “el devora blogs” decidió) que tenía que haber una manera mejor de hacer las cosas. Una manera que no se basara en intentar adivinar qué necesita un cliente que desconoces, y que no planificara el trabajo de varios meses en base a dicha esotérica “adivinación” (interesante temática para un post, por cierto). Se trataba principalmente de no trabajar en balde… nos gusta programar, pero no tanto.

To be continued…

Aforismos ágiles

“Los product manager sois una especie en extinción. Reciclaos. La naturaleza no da avisos a las especies que se van a extinguir, así que dadme las gracias”

Ángel Medinilla – CAS2010

Iterando el Daily Scrum

Dentro de los cánones de Scrum, una de las reuniones ineludibles que intentamos mantener en Frogtek es el Daily Scrum (también llamado Standup meeting o Daily Standup). Aquí van algunas de las características de esta reunión:

  • Standup: debe realizarse de pie. El motivo de esto es no alargar la reunión demasiado (no debería durar más de 15 minutos).
  • Daily: debe realizarse cada día, preferiblemente a la misma hora y en el mismo lugar.
  • En él, cada miembro del equipo debe responder a tres preguntas:
    • ¿Qué hice ayer?
    • ¿Qué voy a hacer hoy?
    • ¿Qué problemas he encontrado?
  • Asisten todos los cerdos. Las gallinas son bienvenidas, pero sólo para escuchar. Si no entiendes de qué va esto, lee el siguiente artículo.

El objetivo de esta reunión es que todos los integrantes del equipo tengan una idea de en qué esta trabajando cada uno del resto de integrantes, al mismo tiempo que permite ir conociendo lo que se ha ido conseguiendo cada día. En nuestro caso, esta reunión la realizamos a primera hora de la mañana, para que cada uno pueda planificar en consecuencia lo que va a realizar durante el día.

Pero no quisimos quedarnos ahí. Con el objetivo de seguir mejorando el proceso, en la empresa hemos ido iterando sobre el concepto de Daily Scrum, de forma que hemos añadido varios cambios al respecto:

  • Compartir las estimaciones: durante la reunión, debemos compartir con el resto del equipo las estimaciones que hemos dado a nuestras User Stories. Kanban no prescribe la estimación de las tareas, pero dentro de Frogtek creímos conveniente el hacernos unos maestros de la estimación, con el fin de organizar nuestras tareas de manera más eficiente. El compartirlas nos permite que puedan ser puestas en común (muy al estilo de Scrum con las conocidas cartas).
  • Daily Scrum en inglés: llevábamos un tiempo pensando cómo podíamos fomentar el uso del inglés en la empresa, cuando dimos con la solución: durante el daily scrum sólo se puede hablar en inglés. Con esta medida, conseguimos también que el daily scrum no se alargara ni entrara en divagaciones eternas. Curiosamente, también se redujeron los improperios y palabras malsonantes (true story).
  • Añadir una cuarta pregunta. Además de las clásicas “qué hice ayer” , “qué haré hoy” y “qué problemas he encontrado”, creímos conveniente añadir “cómo voy a intentar arreglar el problema”. Esto nos da una perspectiva de cúal va a ser el mejor acercamiento para solucionar un escollo. Y no nos olvidemos tampoco de compartir con el resto del equipo el “cómo conseguí arreglar el problema”. Los errores se repiten y lo que funcionó en el pasado a alguien es bastante probable que me funcione a mí o me ponga en la pista de la solución.

Seguro que seguimos pensando cómo poder mejorar nuestro daily scrum. Pero eso lo veremos en la siguiente iteración…

¡Hola Mundo!

¿Quién nos iba a decir cuando hace menos de un año nos apuntamos a esta aventura que es Frogtek la cantidad de cosas interesantes que íbamos a aprender en tan poco tiempo?. Nadie fue capaz de prevenirnos sobre cuánto iba a cambiar nuestra forma de trabajar y lo enriquecedor que iba a ser el principio del camino a recorrer (porque esto no ha hecho más que empezar). Era toda una apuesta. Salir, en alguno de los casos, de debajo del ala de grandes empresas tan rígidas, como cómodas para montar una empresa pequeña entre todos, desde cero, sin corsés, sin ideas predefinidas… y sin red. Y en ello estamos.

En menos de un año y liderados por un CEO, David, de energía inagotable, e inversamente proporcional a su aversión al cambio (que es nula), hemos construido un grandísimo equipo técnico, flexible, motivado, con ganas de aprender y de enseñar. Se comenzó trabajando los fines de semana, dando forma a un prototipo cuya especificación estaba siempre obsoleta (waterfall,  :$  sí, todo el mundo tiene un pasado oscuro que esconder). Seguimos con un rudimentario SCRUM mucho más apropiado para lidiar con un producto final que desconocíamos a priori (las start-ups ya se sabe… siempre buscando) y unos clientes, los pequeños comerciantes en países emergentes (¡ahí es nada!) tan remotos, como desconocidos. Por aquel entonces, verano del 2009, llegó el momento de la decisión, de tirarse a la piscina, mudarse a una oficina y dedicarse al 100% a Frogtek. La oficina y una empresa de verdad trajo también un SCRUM más “de verdad”, herramientas como el AgileBuddy y nuevos compañeros de viaje. Más adelante nuestra escasa fortuna estimando, reuniones de planificación interminables y la naturaleza demasiado informal de nuestros clientes finales (no es posible tener al tendero medio latinoamericano una vez cada dos semanas en el sprint review) hizo que nos pasáramos al ScrumBan y decoráramos nuestra ya de por sí bonita oficina con una más preciosa aún tabla de Kanban y post-its de todos los colores que hacen las delicias de nuestro programador daltónico, responsable a su vez de nuestros primeros pinitos con el TDD (¡gracias a Carlos Blé!). Buscamos entonces un Tester y encontramos un Responsable de QA y él (junto con el resto) nos ha dado Integración Continua, Test Automáticos, métricas…

En marzo de 2010 empezábamos a tener un departamento de Tecnología en condiciones con un proceso cogido con alfileres pero que apuntaba maneras. Y llegó el momento de conocernos con el resto de la empresa. Aparte de nosotros, había una persona en Nueva York, dos en Bogotá y otra en México DF… y daba la casualidad de que aunque hablábamos diariamente vía skype, ninguno los doce había visto en persona al resto de los “Frogtekeros”. Nos juntamos todos en Huesca la última semana de marzo y durante esos días pasó algo curioso. Les pedimos a los desarrolladores que hicieran una presentación para mostrar cómo era su día a día y en lugar de Power Point van y nos salen con esto…

… supongo que es el tipo de cosas que hace un equipo cuando tiene libertad y está motivado. El vídeo fue un éxito de crítica y público y un poco la semilla para crear este blog. Semilla que germinó en idea tras la sobredosis de entusiasmo y agilismo (menudo palabro) que tres de nosotros tuvimos la suerte de recibir en la CAS 2010. Escuchar a los gurús de las metodologías ágiles y conocer las historias de éxito y de fracaso de distintas empresas nos hizo pensar que también nosotros teníamos algo que contar: nuestra humilde historia, las pequeñas grandes cosas que hemos aprendido y las incontables que nos quedan por aprender.

Este blog surge como nuestro primer “FrogtekLabs”, en él vamos a hablar de nuestro trabajo, de nuestra evolución, de nuestros cambios en definitiva, porque no hacemos más que cambiar. De métodos ágiles, de palabros en japonés, de Android, de Google App Engine, de cualquier cosa que nos interese… Somos ocho, así que no esperes consistencia, espera estilos muy distintos, distintas frecuencias, posts de gestión, de programación pura y dura, de TDD, sobre cómo usar SONAR o configurar Eclipse. Ni siquiera esperes que no nos llevemos la contraria alguna vez. Espera también errores y ayúdanos a corregirlos.

Nos declaramos fans de Ángel Medinilla (¡tenemos su autógrafo!) y de Rodrigo Corral. Somos maqueros y linuxeros y alguno hay que aún echa de menos Windows. No estamos en Silicon Valley, sino entre Huesca y Zaragoza, pero no renunciamos a trabajar como Google. Y por encima de todas las cosas… queremos pasarlo bien. ¡Que empiece la fiesta!.

Recientes entradas