¿Por qué elegí Scrum?

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.