Mar 17

La parte olvidada de las metodologías ágiles

Cuando se habla de metodologías ágiles y quizás porque en el fondo somos programadores y no gestores, siempre se habla de cosas como la reunión diaria, las entregas frecuentes, los tableros Scrum, los test automáticos, etc, etc. Sin embargo, hay otro punto realmente importante y del que no se suele hablar, la intervención directa del cliente a lo largo de todo el proceso.

Afortunadamente, he tenido oportunidad de practicar con este último punto y ahí va la experiencia. Pongámonos primero en contexto

El proyecto es un proyecto pequeño para lo que estamos acostumbrados, un solo desarrollador, yo mismo, durante algo más de seis meses y con la suerte de poder dedicarme al 100% al proyecto (cosas de la crisis, no hay demasiado trabajo). Hay también un jefe de proyecto, pero su única gestión es básicamente el tema económico y alguna reunión o charla esporádica con los "jefes" del cliente. El proyecto es un proyecto Web, en el que sólo hay software implicado, el servidor está desde el principio en las instalaciones del cliente, con su dominio público en internet y al que tengo acceso de administración con una VPN (red privada virtual)

En este contexto, tengo contacto diario y directo, por teléfono y email, con los usuarios finales del proyecto, los que van a estar usando esa web día a día, así que pensé que es una situación ideal para metodologías ágiles. Al ser yo el único desarrollador y estar el cliente en otra ciudad a más de 400 km de distancia, todo eso de las "demos" y reuniones al estilo Scrum no me parecía adecuado, así que  opté por una opción más al estilo Kanban. Me di de alta en https://kanbanflow.com , hice un tablero con cuatro columnas : to-do, in-progress, verification y done, copié los requisitos iniciales en la columna to-do y le mostré el tablero a los clientes, así como una explicación del funcionamiento general de Kanban y metodologías ágiles, en lo que a ellos les afecta. Les pareció una idea estupenda y es lo que estamos usando.

Ellos ordenaron y matienen ordenada la columna de "to-do", además de añadir más tareas cuando les viene en gana, en el orden en que quieren que se desarrolle. Yo siempre saco la primera tarea de arriba del todo y la muevo a la columna "in-progress", teniendo como máximo 3 tareas simultáneas en desarrollo. Cuando termino de probarla en mi entorno de pruebas y la subo al servidor, la muevo a "en verficacion" y ellos, tras probarla, la mueven a "done" o la devuelven a la primera columna con más cosas que quieren o bugs que han encontrado. En fin, nada que no sepamos ya del funcionamiento de un tablero Kanban.

¿Y cuales son las consecuencias de todo esto?. Pues bien, como nada es blanco ni negro, hay cosas buenas y otras no tan buenas. Empecemos con las primeras.

Lo mejor de todo es que el cliente está encantado. No es solo que me lo digan cuando les pregunto, es también el "feedback" que me da nuestro jefe de proyecto cuando habla con ellos o lo que yo mismo oigo a los clientes hablar entre ellos cuando nos hemos reunido cara a cara.

Lo primero que les gusta, por supuesto, es que el producto, aparte de no tener grandes fallos, cumple exactamente lo que necesitan, como no puede ser de otra forma, puesto que los mismos usuarios finales lo ven evolucionar día a día y deciden sobre lo que se debe hacer y cómo. Y lo segundo que les encanta es la excelente gestión de sus peticiones (mérito de un mecanismo como Kanban), ellos tienen total control sobre lo que piden y cuándo se aborda, así como total visibilidad de lo que se está haciendo y lo que tarda en hacerse. Ninguna de sus tareas lleva un tiempo estimado de más de 3 ó 4 días, pero la mayoría son de 1 ó 2 días, por lo que ven progresos de forma continua. Si alguna tarea lleva mucho más, hablo con ellos y tratamos de partirla, creando una tarea más pequeña con lo que realmente es importante para ellos y otras con lo menos importante y que puedan poner más abajo en la lista.

Y ahora viene la parte no tan buena. Aunque se deja claro al principio que pueden añadir, modificar y ordenar tareas a su gusto, también se deja claro que el proyecto tiene una fecha de terminación y que toda modificación que hagan o tarea que añadan, no debería afectar a esa fecha, sino simplemente hacer más probable, si no seguro, que las tareas al final de la columna to-do se queden sin hacer. Esto, por supuesto es algo que no les gusta oir. Pero eso no es lo peor, porque la ventaja de controlar el desarrollo día a día les convence frente a la posibilidad de que alguna tarea poco importante para ellos se quede sin hacer y de alguna forma, lo aceptan. Lo peor es que en el día a día se "emocionan" con las tareas que se van realizando y tienden a no acabarse nunca. Cuando terminas una tarea y ellos la prueban, se les ocurren mejoras que inmediamente hacen que la tarea vuelva a la columna "to-do", con añadidos para hacer y, normalmente, al principio para que se aborde inmediatamente. Hay que estar continuamente pidiéndoles verificación, como sutil indirecta de que nos estamos eternizando en los detalles, de si están seguros que ese nuevo añadido es más prioritario que las siguientes tareas en la lista.

Hay otro detalle, no sé si bueno o malo, y es el "pequeño estrés" que causa este método al desarrollador (yo). Al ver ellos el progreso día a día y ser tareas de tan poco tiempo estimado (1, 2, 3 días), "canta" mucho si un día me distraigo con cualquier cosa. Si tengo alguna reunión ajena al proyecto, si acabo de volver de vacaciones y tengo el típico día perezoso que te pasas "güeveando" en internet o con el email … Se ve agravado por el hecho de que para tener mejor visibilidad de cómo va el proyecto, llevamos un pequeño excel compartido que se actualiza todos los Viernes, en él aparecen las tareas, el tiempo que yo estimo para cada una de ellas en días y sumando esos días, la fecha prevista de terminación de cada una de ellas … y por tanto la fecha prevista de terminación del proyecto si se hacen todas las tareas. Si una tarea se complica más de lo previsto, ya me causa un pequeño "estrés" actualizar el excel y ver cómo la fecha de finalización se va alargando a la vista de todos. Pero me causa mucho más "estrés" si encima ese retraso va causado por la típica pereza que todos tenemos algún día que otro.

Puedo asegurar que nunca he trabajado tanto y tan seguido como en este proyecto, en parte por el "estrés" que me causa perder el tiempo, en parte por tener en todo momento perfectamente claro qué es lo que tengo que hacer y cómo. Ojo, no he echado ni una sola hora de más, es simplemente que apenas pierdo el tiempo a lo largo del horario laboral tratando de que el flujo de tareas de "to-do" a "done" sea lo más fluído posible.

Ahora nos estamos acercando a la fecha prevista de finalización, por supuesto, con requisitos iniciales que el cliente no ha considerado importantes al final de la lista to-do y totalmente fuera de plazo, pero con otros requisitos que han añadido sobre la marcha y que han considerado más importantes hechos a su gusto, con el cliente bastante contento en general. Veremos qué tal va el cierre final ….

Sep 29

Metodologías ágiles y entregas frecuentes.

En la metodologías ágiles, Scrum por ejemplo, es típico que se hable de entregas al cliente frecuentes, con algo que les sea útil y donde puedan ir viendo los progresos. Últimamente, estoy pensando si eso es o no posible en todos los proyectos. ¿Por qué? Porque en el proyecto que estoy ahora es claramente posible y así lo estoy haciendo, pero eso me ha hecho darme cuenta que en los proyectos anteriores no solo no es tan fácil, sino que posiblemente es poco menos que imposible.

Los proyectos en los que ando actualmente, ya casi desde hace dos años, son proyectos web. Y cada proyecto lleva dos o como mucho tres desarrolladores y se hacen en unos meses, menos de un año, cada uno de ellos. En estas condiciones es fácil hacer entregas frecuentes. Tu proyecto solo lleva software y está público en internet. Así que haces un pequeño desarrollo de un par de semanas, aunque sólo sea el login, o la página principal con un poco de funcionalidad, la subes al servidor, se lo dices al cliente y ellos prueban y dan su opinión. Y repites el proceso cada 15 días o así añadiendo cada vez un poco más de funcionalidad, siguiendo las indicaciones de tu cliente.

¿Y cómo eran los proyectos de antes?. Pues bien, el proyecto más gordo en el que estaba metido era un proyecto en el que había varios departamentos implicados, de software, de hardware, de montaje (hierros, tornillos y cables), etc, etc. En unos camiones suministrados por el ciiente (unos 10 camiones), se montan varios equipos hardware, unos comprados como GPSs, estaciones solaris, PCs con Windows, receptores de radio, .. otros diseñados y fabricados específicamente para el proyecto, bien a otras empresas, bien a otro departamento, como radiogoniómetros o exploradores de frecuencia, … y se hace mucho, pero que mucho software, para controlar todo eso y presentar datos decentes a los usuarios en cada camión. Desgraciadamente, en semejante entorno, el software es lo que menos se nota. Por mucho software en varios lenguajes (Ada, Java y C++ sobre Windows y Solaris) que lleve el sistema, siempre llama más la atención 10 camiones, repletitos de equipos en su interior y con varias antenas gigantes en su exterior.

¿Cómo hacer entregas frecuentes y funcionales al cliente en este entorno?. Teniendo en cuenta que el hardware tarda lo que tarda en llegar, que los camiones no se nos entregan hasta que hay suficiente hardware como para empezar el montaje físico y que la mayor parte importante del software no se puede integrar hasta que están los equipos físicos…. la única opción es hacer simuladores de todo y hacer "demos" más o menos frecuentemente, que el cliente vea la interfaz de usuario, la pinta que tiene, qué datos va a presentar y cómo, como se va a manejar, …. pero todo con datos simulados. Y cuando llega el tiempo de integrar realmente con los equipos hardware verdaderos y ver cómo los ejecutables que corren en los diferentes camiones se comunican entre ellos, os aseguro que es un verdadero infierno, cualquier bug puede ser debido a cualquier cosa, desde un cable mal conectado, pasando por un equipo que no funciona correctamente hasta, por supuesto, un bug en el software.

¿Y cómo haces test automáticos de todo esto? Sí, se pueden hacer test automáticos de las "chorradas", como que si un usuario introduce mal su password no se le deja entrar en el sistema, típico ejemplo de cualquier manual ágil, pero no se puede probar de forma automática y fácilmente que si dos radiogoniómetros en camiones distintos detectan un emisor de radio y se triangula su posición, aparece dibujado en el mapa de  un tercer camión (de hecho, tiene que aparecer dibujado en el mapa de todos los demás camiones). Un test automático de todo esto, eliminado el hardware y sustituyéndolo por simuladores, implica arrancar al menos tres ejecutables (uno por camión), más los simuladores si son ejecutables sueltos ya que simulan un equipo hardware, y verficar que en un mapa (o en la base de datos que hay detrás del mapa) aparece el emisor de radio detectado en la posición correcta.

Estoy mucho más de acuerdo con la filosofía ágil que con la tradicional, pero no existe la llave inglesa universal que vale para todo tipo de tuercas y  tornillos simultáneamente. Si es posible aplicarla, adelante, y si no es posible, hay que hacer lo que se pueda intentando conseguir lo mejor de ella.

Jul 03

Ventajas de la reunión diaria

Daily ScrumComo no todo es blanco o negro, las metodologías ágiles tienen también muchas cosas buenas. Una de las más sencillas de implementar y con la que conseguir mejoras son las reuniones diarias. Intentamos ya en varias ocasiones hacer Scrum y Kanban, incluso TDD y varias más de las metodologías/prácticas ágiles. Aunque seguimos en el intento, la reunión diaria es la más fácil de seguir y de la que obtener ventajas rápidamente.

La hora teórica de entrada es las 8:00. Habitualmente la gente suele ir llegando sobre las 8:30 y lo primero que hago es ir a tomar café con mi amiguete y luego revisar el correo, el Hudson y el Taskfreak. Imprimo este último y con él, sobre las 9:00 hacemos nuestra reunión de 10/15 minutos. Antes éramos cuatro en la reunión, ahora sólo somos tres.

La reunión la hacemos sentados. Las buenas costumbres aconsejan hacerla de pie para que la gente esté incómoda y la reunión no se prolongue más de la cuenta, pero con el tiempo hemos conseguido no tener ese problema, rara vez dura más de 10 minutos y nos permitimos hacerla sentados.

¿Qué mejoras hemos conseguido con la reunión diaria?

Sensación de grupo

La primera y más importante es la sensación real de la gente de formar parte de un grupo. En nuestro caso concreto, si lo de contar "qué hicimos", "qué vamos a hacer" y "qué problemas tenemos" nos lleva realmente cinco minutos (sólo somos tres), solemos permitirnos unos cinco minutos más de reunión para "cotilleos": comentar como van las pruebas de un proyecto, qué tal le va a uno que está desplazado en la India, los planes del jefe de mover a cierta persona a otro proyecto, etc, etc. Todo esto, además de reforzar la sensación de equipo de trabajo, también refuerza algo los lazos de compañerismo.

Dije que antes eramos cuatro y ahora somos tres. ¿Qué pasó con el cuarto?. Simplemente que le propusieron pasarse a algo más adecuado a su perfil (administrador en vez de programador) y depender de otra persona que no era yo. Pero cuando se lo propusieron, dijo que no quería cambiar del todo, se sentía muy integrado en nuestro grupo y no quería perder eso.

Fue realmente una sorpresa esta objeción. Cuando estaba en nuestro grupo tendía a distraerse de las tareas de programación para dedicarse más a instalar tarjetas de red, configurar routers, instalar software, etc, se le veía claramente que le iba más eso que programar. Le propuse el cambio a mi jefa y ella me dio la razón, pensó que esta persona podía disfrutar más de su trabajo en el grupo de administradores y le propuso el cambio. Y la objeción fue imprevista, efectivamente, dijo que le gustaba más instalar cosas que hacer software, pero que no quería cambiar por sentirse muy integrado en nuestro grupo. Así que el cambio fue gradual, pasó a realizar tareas de administrador poco a poco y siguió acudiendo a nuestras reuniones para hacer su parte de trabajo de programador. Al final la realidad se impuso y realizar dos papeles distintos es imposible, así que dejó cogiendo cada vez más trabajo de administrador y menos de programador y dejó de acudir a las reuniones de forma natural.

De hecho, los tres que quedamos estamos a punto de trabajar en cosas totalmente distintas (tres proyectos distintos, con tres jefes de proyecto distintos y temáticas totalmente distintas). Pero de común acuerdo hemos decidido seguir haciendo las reuniones porque a fin de cuentas el software es software, los problemas son similares y si alguien tiene un problema y lo cuenta a los que ya considera sus compañeros, enseguida se prestan a ayudarle a resolverlo.

Enfocarse en las tareas concretas del día a día

El tener nuestra lista de tareas y decir a primera hora de la mañana "hoy voy a hacer esto" hace que el resto del día tengas claro qué vas a hacer. Supongo que hay algunos que no necesitan este tipo de cosas, pero yo soy de los que tiende a saltar de una cosa a otra. "Comprometerme" con el grupo a que ese día voy a hacer determinada cosa (aunque ninguno de ellos dependa de que yo lo haga), me pone una pequeña traba a distraerme. Me daría vergüenza al día siguiente decir "no he hecho esta tarea porque he estado mirando el correo, navegando por internet, mirando otra vez el correo, un café, probando una herramienta que me he encontrado …."

Así que lo dicho, decir en público "hoy voy a hacer esto", de alguna forma te obliga a centrarte en hacer exactamente eso.

Saber dónde se va el tiempo e incentivo a la mejora

A pesar de todo, en muchas ocasiones, al día siguiente acabas diciendo "No he terminado la tarea que dije ayer" y cuando llegas a la parte de los problemas que has tenido para acabarla dices "me han llamado a una reunión de tres horas", "Se han llevado un ordenador del laboratorio que hacía puerta de enlace de la red del laboratorio y me he quedado sin conexión con los equipos", "me han pedido hacer esto de otro proyecto", etc, etc, etc.

Algunas cosas son inevitables, pero al menos eres consciente de dónde se pierde el tiempo, ya que tienes que decirlo claramente a tus compañeros. Pero cuando esas pérdidas de tiempo tienen arreglo, enseguida "canta" que perdemos el tiempo por algo que hacemos mal y que se puede arreglar/mejorar. Justo lo que pregona Scrum. Aunque en nuestro caso ha quedado un poco fuera la figura de Scrum Master, siempre alguno del grupo coge como tarea mejorar eso que dificulta el trabajo.

Aprovechar la capacidad de los mejores

Y aunque los mejores del grupo o con más capacidad posiblemente no necesiten estas reuniones para centrarse en lo que tienen que hacer o para mejorar su propio proceso de trabajo, no todos tienen esa capacidad.

En estas reuniones las personas de más capacidad se hacen también conscientes de los problemas de los demás, no sólo de los suyos propios. Son capaces incluso de ver posibles mejoras en donde la otra persona ni siquiera ha detectado un problema. De esta forma, todos se benefician de los mejores aunque no vayan específicamente a preguntarle por un problema concreto.

Y los mejores tampoco son infalibles, muchas veces alguien no tan bueno es capaz da una idea o propone algo que se le había escapado

Resumiendo

Resumiendo, que estamos encantados con nuestra reunión diaria y que aunque tiene pinta que el grupo se disgrega (cada uno a su proyecto), por unanimidad queremos seguir haciéndola. Quizás el tiempo nos diga que carece totalmente de sentido… o quizás no.

Y aunque se puede ver claramente que no hacemos una reunión diaria al puro estilo Scrum (no la hacemos de pie, no hay tablero aunque sí lista de tareas, no ha scrum master propiamente dicho), la mejora es apreciable por todos.

May 10

Lo importante es la gente

Leyendo este post Potencia tu equipo (4) Evita jerarquías y especialistas, no me he podido resistir a hacer mis propias reflexiones al respecto, basadas en lo que he ido viendo durante muchos años de hacer software, viendo como los grupos y departamentos se hacen y deshacen para tratar de mejorar las carencias de la organización anterior.

Mi idea final es que no hay organización buena o mala, sino gente buena o mala. Las cosas no son blancas ni negras, cada organización tiene sus ventajas e inconvenientes, puede ser mejor o peor según para qué, pero al final funciona bien o no dependiendo de la gente que la integra.

Los grupos de especialistas tienen la ventaja de que acaban desarrollando su parte de código muy rápido, puesto que se la conocen perfectamente, y que de forma natural hacen sus propias librerías, ya que ellos mejor que nadie son capaces de ver qué cosas necesitan reutilizar siempre tal cual, cuales pueden reutilizar con algo de configuración y cuales cambian constantemente de un proyecto a otro. Y esta es la pega que he visto cuando se hacen grupos multi-disciplinares. Esos grupos tienden a trabajar aislados y no realizan tantas librerías comunes. Distintas partes de un mismo proyecto tienden a no parecerse unas a otras ni en la manera de funcionar, ni en aspecto visual, ni el estilo del código. Siempre acaban perdiendo bastante tiempo rehaciendo y uniformizando todo más adelante. Al final puedes ver un ejemplo real de falta de uniformidad.

Pero el trabajo por grupos multi-disciplinares tiene una ventaja enorme de la que carecen los grupos de especialistas. Al haber un grupo responsable de una funcionalidad, hay un grupo que se preocupa de que esa funcionalidad vaya bien totalmente. Cualquier bug que aparezca tiene un claro responsable (el grupo) y se suele corregir rápido. En los grupos de especialistas la integración puede/suele ser un infierno. No hay un responsable claro de la funcionalidad y cada grupo se limita a ver que su parte funciona y soltar "el marrón" a otro de los grupos. El resultado es que los bugs tardan mucho en corregirse y es fácil llegar a peleas entre miembros de distintos grupos o incluso grupo contra grupo.

Con todo esto quiero decir que las cosas no son ni blancas ni negras. Cada forma de trabajo tiene sus ventajas e inconvenientes y que debemos estar muy pendientes de los inconvenientes para no dar al traste con el proyecto.

Y lo más importante, la gente. No debes caer en el tópico de que si hacemos una estructura jerarquizada no va a funcionar porque el jefe será un torpe, pero si hacemos un grupo auto-gestionado va a funcionar todo de maravilla porque todos son guays. Cada uno es como es. El usar metodologías ágiles no hace que nadie sea más "guay". Ni hacer un grupo jerarquizado hace que el jefe sea torpe. He visto grupos jerarquizados funcionar estupendamente porque el jefe es capaz de tener a la gente contenta, dejarles las decisiones técnicas que no controla y haciéndoles rendir a tope (en su horario normal). Quizás no es lo habitual, pero tampoco son más habituales los grupos scrum que realmente funcionan como scrum que los que no lo hacen. Como digo, es cuestión de la gente (sea jefe o scrum master).

Da igual qué tipo de organización elijas, funcionará o no dependiendo de la capacidad y predisposición de la gente que haya en ellas. Un grupo jerarquizado funcionará muy bien si el jefe es competente. Los grupos de especialistas funcionarán muy bien si hay "buen rollo" entre ellos a la hora de integrar. Los grupos multi-disciplinares funcionaran muy bien si hay buen rollo entre ellos a la hora de uniformizar las cosas.

Y quiero poner un ejemplo real de falta de uniformidad al hacer las cosas distintos grupos sin comunicación fluida entre ellos. Una ventana con cuatro botones juntos, cada botón hace una cosa distinta y cada botón realizado por un grupo distinto. Lo único común que tienen esos botones es que realizan una consulta a base de datos y muestran una ventana de resultados. ¿Cual fue el resultado real?

  1. botón 1. Si no hay resultados en bd, no hace nada.
  2. botón 2. Si no hay resultados en bd, saca una ventana de aviso indicándolo.
  3. boton 3. Si no hay resultados en bd, saca la lista de resultados vacía.
  4. botón 4. Si no hay resultados en bd, saca una ventana de aviso indicándolo y la lista vacía.

Me habría gustado que hubiera un quinto botón y un quinto grupo, para ver por dónde salían.

Jul 03

Se nos va relajando Scrum…. por decirlo suavemente.

 

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

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

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

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