Diario de Programación

Veo que Scrum está dando fuerte. En nuestra empresa, aparte de nuestros intentos de hacer Scrum, hay otros departamentos que también lo están intentando. También conozco gente en otras empresas con las que colaboramos que están empezando a usarlo. Pero no solo es eso lo que me llama la atención ("frikis" los habemos en todos lados)

Por un lado, en la portada de nuestra intranet, que la empresa aprovecha para poner lo maravillosa que es, los proyectos que tiene y lo bien que va, apareció hace unos días un artículo en el que nuestra empresa y otra habían colaborado para la implantación de Scrum en los procesos de no sé qué.

Por otro, ha caído en mis manos (de forma completamente legal) una oferta técnica de otra empresa para el desarrollo de un sistema … y en él ponen que usarán redmine … y Scrum como metodología de desarrollo.

Todo esto tiene su parte buena … y su parte mala.

La parte buena es que Scrum está ganando la suficiente fama de ser una buena metodología de desarrollo como para que las empresas empiecen a considerarlo como algo bueno, que merece la pena intentar. Lo ponen en su propaganda, en sus ofertas, …

Lo malo es lo de siempre, que se acaba desvirtuando el fondo real que hay detrás de la metodología. Al convertirse en algo "bonito" para poner en papel, se pondrá "usamos Scrum" por sistema, se use bien, se use mal o no se use en absoluto. El cliente no conseguirá siempre los resultados esperados de esta metodología y acabará perdiendo su fama.

La verdad es que estoy un poco hasta las narices de las mentiras empresariales, "vende-motos" y palabras rimbombantes. Conseguir un premio a "la excelencia empresarial" es muy fácil, sea lo que sea eso, pero todos los curritos sabemos que lo que hay detrás es cualquier cosa menos "excelencia". La "garantía de calidad", sea lo que sea eso, tres cuartos de lo mismo. Tener la "certificación ISO no sé qué", sea lo que sea eso, igual. Y dentro de nada, ser "Scrum certified" será algo (sea lo que sea) que no sabremos que es, pero que pagando se consigue.

Siguiendo un poco con el post anterior, hace tiempo en Verlo para creerlo comenté un código real de una empresa con el que me había tropezado. En ese código había una clase (llamémosla Datos) con 16 atributos estáticos iguales (digamos, atributo1, atributo2, … atributo16). Pulsando un botón (uno por atributo) debía mostrarse en una ventana nueva algunas cosas relativa a uno de esos atributos. En el código había 16 clases Ventana, una por atributo, llamadas Ventana1, Ventana2…. Ventana16. La única diferencia en el código de esas clases, aparte del nombre, era que accedía a Datos.atributo1, Datos.atributo2 … Datos.atributo16

¿Qué habría pasado si hubieran usado TDD?

Supongamos que este mismo programador hubiera hecho este código usando TDD. ¿Qué habría pasado?. Pues lo evidente, habría 16 clases de test llamadas TestVentana1, TestVentana2, … TestVentana16.

Pero TDD no es sólo hacer test, es hacerlos antes. Bueno, supongamos que los ha hecho antes.

Y TDD tiene otro tercer paso, refactorizar para quitar todas las repeticiones posibles de código, incluso las menos evidentes. Bueno, no sé vosotros, pero yo, independientemente de usar o no TDD, me repatearía hacer copy-paste 16 veces de una misma clase y como ser vago a veces es una virtud, habría dado las vueltas necesarias para no hacer esto. Sin TDD se me ocurre simplemente meter los atributos en un array de 16 posiciones y en un método set() de la única clase VentanaUnica pasarle el índice de la posición que debe tratar. Es lo primero que se me ocurre, nada complejo, seguramente hay más y mejores soluciones.

Sin embargo, este desarrollador no lo ha hecho. ¿Por qué?. Se me ocurren cuatro posibles motivos:

1. Totalmente inexperto en java, un array es algo complejo de usar y lo del set() ni lo cree posible. Muchos programadores novatos tiene problemas para hacer que los atributos de una clase se vean en otra y por eso tienden a hacerlos estáticos (justo como ha hecho este señor).
2. No tiene cabeza para programar, por más vuelta que le ha dado, no se le ha ocurrido cómo evitar hacer las 16 clases.
3. Le importa tres pepinos. Para qué se va a complicar la vida si con 16 clicks de ratón (un copy y 15 pastes) lo arregla.
4. Todas las anteriores.

Bueno, pues con este panorama, ¿qué habría hecho al intentar refactorizar con TDD?

1. Ya tengo mi TestVentana1, así que hago mi Ventana1. Ahora mi TestVentana2 y hago mi Ventana2. ¡¡ Código repetido !!. ¡¡ Vamos a refactorizar !!: Imposible, java no permite hacerlo, si java no permite pasar el atributo de la clase Datos a la clase Ventana, Ventana1 y Ventana2 deben ser clases distintas. Y no te digo juntar los dos test en uno solo.
2. Buff, qué dolor de cabeza, no se me ocurre como puedo convertir dos clases distintas que manejan atributos distintos en una sola.
3. Jó, que rollo refactorizar ahora que me está funcionando, voy con los siguientes 14 pastes, que el copy ya lo tengo hecho.
4. Java no deja, no se me ocurre como hacerlo y voy a correr un montón si reaprovecho el copy para el resto de pastes.

Algo como Srcum tampoco evitaría estas cosas. En el sprint diario este señor diría "Ya tengo las ventanas de  los atributos" y todos felices. Bueno, con un poco de suerte, un día diría "tengo la Ventana1 del atributo1", al día siguiente "tengo la Ventana2 del atributo2" y alrededor del quinto día, quizás a alguien se le ponga la mosca detrás de la oreja y quiera ver qué está haciendo. De todas formas, no se tardan 16 días en hacer 15 pastes.

Una herramienta de análisis estático de código integrada en una herramienta de integración continua cantaría esto por la noche, suponiendo que cante cuando encuentra código repetido y, como hacemos nosotros, el compilado falla si no se cumple alguna métrica importante. Desgraciadamente, existe el @SuppressWarnings que la gente se acostumbra a poner por sistema, incluso antes de que cante la métrica (conozco al menos dos personas que lo hacen).

La programación en parejas también habría ayudado, salvo que la pareja de nuestro programador fuera el recién entrado al que le han asignado para que le enseñe.

Bueno, parece que últimamente las malas son las metodologías tradicionales y las buenas son las metodologías ágiles, pero a fin de cuentas, ambas son metodologías y las metodologías, en general, presentan sus problemas. ¿Por qué?. Este artículo de Joel on Software nos da la respuesta.

Un cocinero excepcional hace lo siguiente:

Ahora bien, el Chef Desnudo no sigue ningún apestoso Manual de Operaciones. No mide nada. Mientras esta cocinando, usted ve un frenesí de comida sacudida y siendo arrojada por aquí y allá. "Simplemente pondremos una pizca extra de romero por acá, que no lo arruinara, y le daremos una buena sacudida", dice el. "Amásenlo así. Perfecto. Solo espárzanlo por todos lados." (Si, de verdad se ve como si simplemente lo esparciera por todos lados.

es decir, una persona brillante (cocinero en este caso), no necesita seguir ninguna metodología ni medir nada para obtener un producto genial. ¿Por qué las metodologías?. Pues porque gente brillante hay poca y del resto hay un montón. Para conseguir que el resto de la gente haga un buen producto, la persona brillante escribe una serie de reglas para que la gente del montón sea capaz de hacer lo mismo que él … y eso no funciona. Si se hace, se tienen "Big Macs". El resumen del proceso es el que indica Joel on Software en el mismo artículo

1. Algunas cosas requieren de talento para hacerse realmente bien.
2. Es difícil tener talento a la medida.
3. Una forma en que la gente intenta igualar el talento es haciendo que el talentoso cree las reglas para que los menos talentosos las sigan.
4. La calidad del producto resultante es muy baja. 

¿Y qué pasa con el software?. Pues más o menos lo mismo. Unas personas geniales escribieron unas metodologías para hacer buen software, sean las tradicionales, sea Scrum, sea TDD y el resto de los mortales tratamos de seguirlas. ¿Y qué pasa?. Pues cosas como esta

• "Scrum no nos gusta por la reunión diaria de 90 minutos" http://www.dosideas.com/noticias/metodologias/917-scrum-diario-efectivo.html
• "Hacer TDD mal es más costoso que no hacerlo" http://geeks.ms/blogs/lontivero/archive/2009/09/28/unit-tests-contras-de-implementar-test-unitarios.aspx
• etc, etc.

Total, que para hacer bien Scrum o hacer bien TDD o cualquier otra de las metodologías ágiles hay que hacer un cambio importante de mentalidad, ser bueno en muchas materias incluido como programador, tener mucho sentido común, etc, etc.

Y digo yo… la persona que cumple todo eso y puede hacer realmente bien TDD/Scrum/metodologías ágiles… ¿necesita realmente hacer todo eso?. Estoy totalmente convencido que un programador genial es totalmente capaz de hacer un muy buen software sin preocuparse en absoluto por ninguna metodología concreta, sino siguiendo simplemente su intuición. Y estoy convencido que el resto de los mortales estamos predestinados a hacer mal software directamente o hacer mal software después de haber seguido deficientemente una metodología ágil.

A pesar de todo, es mejor seguir una metodología que ninguna. Imagina en el McDonalds si cada uno se hace los BigMac de cualquier manera. Pero aunque lo he dicho muchas veces, me reitero. Si se quiere un buen software que destaque, el punto más importante a tener en cuenta es elegir a los mejores programadores.

He leído "Kanban y Scrum – Obteniendo lo mejor de ambos" que te puedes descargar en el post del enlace, hacia el final, en cristiano.

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

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

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

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

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

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

¿Y en qué ha quedado el tema entonces?

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

¿Pegas?

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

¿Ventajas?

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

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

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

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

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

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

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

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

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

Pongámonos en situación. Supongamos un grupo de dos desarrolladores que tienen que hacer dos tareas. Las tareas no tienen nada que ver la una con la otra, incluso son de proyectos distintos. Lo único que tienen en común es que tienen que estar para ayer, es decir, el tiempo para que estén acabadas es demasiado corto y es muy probable que se llegue por los pelos o no se llegue.

Ante esta situación tenemos dos soluciones:

1. Solución tradicional, estándar, típica y la más habitual. Cada desarrollador se pone con una tarea y hasta donde lleguen. Esto da tranquilidad aparente, puesto que ambas tareas están haciéndose y se acabarán o no dependiendo de si los desarrolladores se acordaron de traerse el gorro de dormir a la empresa.
2. Solución ágil, moderna y a la moda. Los dos desarrolladores se ponen juntos a hacer una de las tareas. Cuando la acaban, se ponen con la otra. Desde luego, parece muy arriesgado y a algún jefe se le pueden poner los pelos de punta – ¡¡ Pero !! ..  ¿cómo?¿no estais haciendo nada de la tarea B? -

Supuestamente la solución ágil es la correcta, pero eso sólo es cierto si dos desarrolladores trabajando juntos avanzan el doble de rápido que uno solo. Pero no queda ahí la cosa. Si la solución ágil es la correcta, es porque es mejor que la solución tradicional. Eso quiere decir que dos desarrolladores juntos deberían trabajar más del doble de rápido que si trabaja uno solo.

¿Y es esto cierto? ¿dos desarrolladores juntos trabajan más del doble de rápido que uno solo?. Si tú eres uno de los desarrolladores y es a tí al que van a caer los capones si las tareas no están acabadas a tiempo, ¿te atreverías a desarrollar una en conjunto con tu compañero y abandonar temporalmente la segunda? Y si tú eres el jefe de esos dos desarrolladores y es a tí al que caen los capones ¿les animarías a trabajar juntos en una tarea dejando abandonada temporalmente la otra? ¿Y a mitad del tiempo límite darías el tipo cuando tengas que decir -La tarea B no está porque ni siquiera la hemos empezado-?

Decisión difícil que requiere valor.

Este comentario de ilcavero al post Se nos va relajando Scrum… y los siguientes comentarios me han dado bastante sobre lo que reflexionar, si Scrum es o no adecuado para nuestro caso.

Nuestros sistemas llevan muchísimos equipos hardware de distinta índole (GPS, Receptores de radio, Grabadores digitales, etc, etc) que nuestro software debe controlar. Algunos de esos equipos se compran, pero otros se fabrican en otros departamentos de nuestra empresa. Además, todo el montaje de esos equipos en los armarios correspondientes, con su cableado entre ellos y con los ordenadores, es también cosa de otro departamento más de la empresa. De hecho, los costes de los equipos, de los armarios y su montaje son mayores que los del software que hacemos nosotros.

Dichos equipos y montaje no suele estar completa hasta fases finales del proyecto, de hecho, los plazos de entrega se miden más por el tiempo que se puede tardar en comprar/fabricar los equipos y montarlos que en lo que se va a tardar en hacer el software, que se supone que es menos. Por ello, no podemos probar en condiciones reales nuestro software hasta casi el final del proyecto.

Y esa es la duda que plantea ilcavero sobre si es adecuado o no usar Scrum en estas condiciones. Nosotros (los del software), al principio del proyecto podemos pensar en un sprint de un mes (por ejemplo), una serie de historias de usuario y hacer el sprint. Pero no podemos garantizar que esas historias de usuario están completas sin pruebas con los equipos reales que todavía no están disponibles. Nuestra única opción para hacer una prueba del software es hacer simuladores de los equipos. Esto hace que el producto "entregado" al final de cada Sprint no sea el producto real.

Por ello y siendo consciente del asunto, al elegir Scrum, tuve en cuenta que no se probarían los sprint en el sistema real. La condición de "historia terminada y funcionando" debería relajarse un poco y ser "historia probada y funcionando con simuladores, pendiente de prueba real en cuanto haya equipo".

Y de esta forma, aunque se pierden parte de las ventajas de Scrum relativas a entregas frecuentes, si nos aporta el resto de ventajas:

• La reunión diaria hace que tengamos más sensación de equipo. Anteriormente, cada desarrollador se dedicaba a su tema y trabajaba aislado de los demás, salvo que su código tuviera comunicación con el código de otro. Aunque no llevamos mucho tiempo con Scrum y no lo estamos haciendo bien, algunos desarrolladores empezaban a coger tareas que no eran suyas, símplemente para ayudar a un compañero o porque creían que ellos podían hacerlo mejor o más rápido que el compañero novato.
• La demo al final del Sprint no es como debiera ser, pero sí se llama a la gente (jefes de proyecto principalmente y otros desarrolladores de otros grupos que tengan que hacer algo parecido). Todos son conscientes de que hay cosas "simuladas" y que habrá que depurar al final, con equipos reales.
• La retrospectiva ayuda a mejorar la forma de trabajo, independientemente de que el producto de la demo sea real o no.

Las pegas, hay dos importantes:

• La fase final del proyecto (en la que estamos ahora en uno de ellos), puede durar uno o dos meses en los que el código está prácticamente hecho al 100%, pero no probado con todos los equipos reales. Esta parte de integración es muy compleja de llevar con Scrum (al menos, no se me ocurre como), ya que los errores no son conocidos y sabes que vas a dedicar el día a probar y corregir lo que vayas encontrando. Imposible hacer un sprint-planning, demos o incluso en el día a día, contar que vas a hacer ese día. Nuestro "Scrum" actual es sin sprints y se basa símplemente en reunirse a diario, contarnos los bugs encontrados y corregidos el día anterior, los encontrados y no corregidos, así cómo que problemas tenemos con las pruebas.
• Esta fase absorbe el 100% del tiempo (es la fase final del proyecto que está a punto de cumplir hito) y las pruebas son lentas, ya que no sólo es el software el que tiene fallos, también hay cables mal hechos o equipos con bugs en su firmaware. Cualquier prueba necesita gente de varios departamentos. En un post anterior comentaba que estaba de Scrum master de dos equipos de scrum simultáneamente. Pues bien, uno de esos equipos es el que está integrando ahora … y el otro se ha quedado sin Scrum master.

En cualquier caso, otro punto importante a tener en cuenta es que hay muchos post en muchos blogs en los que se critica a los que dicen "Nosotros no podemos aplicar Scrum". Las condiciones no son las ideales, pero es cuestión de intentarlo y estoy convencido de que si logramos sacarlo adelante, aunque sea con pegas, vamos a mejorar nuestra forma de trabajo. Todo es cuestión de insistir y para eso están las retrospectivas al final del sprint, para ver cómo mejorar.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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