No sé si recordarás el capítulo 200 de los Simpsons (9ª temporada). En este capítulo, Homer acaba de Concejal de basuras y se gasta todo el presupuesto para dar un buen servicio pero durante un corto tiempo. El capítulo comienza con una escena muy graciosa: en ella, aparece el cubo de la basura lleno y tienen la norma de que el que haga que rebose, debe tirarla. Para evitarlo, los Simpsons van colocando los desechos como si fuera un juego de Jenga, incluso pegando con imanes de la nevera o con chinchetas. Finalmente, Homer acaba por tirar el cubo y debe ser quien saque la basura.
Esta escena es una metáfora sobre la calidad del software. Muchas veces recibimos un código que está hecho una basura y tenemos que arreglarlo sin romper nada de lo que nos encontramos. Si tiramos el cubo, tendremos que volver a recogerlo y por tanto, dejar el código para que no falle (aunque sea con chinchetas).
De hecho, cuando la basura huele y el código es caro de sostener, se decide empezar de nuevo la aplicación. Por ejemplo, actualmente estoy acompañando a un equipo para construir un producto que sustituye por tercera vez a la misma aplicación, y esto me ha ocurrido varias veces a lo largo de mi carrera.
¿Esto quién te lo ha hecho?
Muchas veces cuando recibimos un código que ha hecho un tercero decimos la típica frase de fontanero “¿Quién te ha hecho esto?”. Como si los programadores previos hubiera hecho un código muy malo. Es curioso, porque con el nivel alto de rotación que hay en el mercado, muchos de esos programadores acabarán en tu empresa tarde o temprano.
Me gustaría dar un dato sacado de mi experiencia. He conocido muy pocos programadores que hagan las cosas mal queriendo, sin embargo, he visto a muchos desarrolladores hacer las cosas mal por la presión de la organización. Así que, la próxima vez que recibas un código que sea de baja calidad, haz la siguiente reflexión: “cuidado con esta empresa”.
Triángulo de hierro los desarrolladores quieren calidad
El triángulo de hierro es famoso. Para los que lo desconozcan: en los proyectos software, tratamos de equilibrar el alcance (features), con el tiempo y el coste. Si todas estos parámetros se equilibran, entonces la calidad se mantiene.
Una vez, explicando el triángulo, debatimos sobre los diferentes parámetros, y llegamos a la siguiente conclusión:
- Para nuestro cliente, lo más importante es el alcance en fecha (tiempo).
- Para nuestro comercial, lo más importante es el coste, ya que controlarlo nos da el beneficio.
- Y para los desarrolladores, lo más importante en la calidad.
¿Quién tiene razón?
En el mundo tradicional es el Jefe de Proyectos el que vela porque todo se cumpla, y gestiona las expectativas asociadas en los cuatro parámetros del proyecto. Sin embargo… ¿Qué papel tiene el Scrum Master en un Scrum Team? Quizás, sea la persona que tiene que velar porque todos los puntos de vista se encuentren y estén cómodos. Equilibrar los parámetros es duro, a veces imposible. De hecho, en muchos equipos es la calidad la que sufre. Ahora bien, tampoco podemos pretender una calidad total, es muy costosa. Sin embargo, sin un nivel elevado de calidad, es difícil sostener la entrega de valor.
La calidad a corto plazo no es productiva
Tobias Mayer, autor de Por Un Scrum Popular, reflexionaba que la calidad a corto plazo no es productiva. Cuando el éxito de nuestro equipo se mida por la entrega en fecha y tengamos poco código, la calidad pasa a ser poco relevante.
Sin embargo, en un modelo de producto cuyo objetivo es dar servicio, la calidad sí es relevante. Si no prestamos atención a la calidad, los costes de mantener el producto y la capacidad de entregar se verán afectados al tener que estar arreglando la aplicación o resolviendo incidencias. Además, probar manualmente una aplicación grande nos llevará mucho tiempo, lo que retrasará el tiempo de entrega. A todo esto, tenemos que sumar que nuestra aplicación dará un mal servicio al estar plagada de fallos.
Frases que han matado la calidad del software
Para mí, hay tres frases que han matado el desarrollo software históricamente. Vamos a repasarlas.
La primera frase es “siempre va a haber incidencias”, como una manera de justificar que los equipos tengan fallos en sus productos. No podemos aspirar a una calidad total con cero incidencias, eso es cierto. Sin embargo, justificar la poca atención de los equipos a la calidad provoca que tengamos muchas aplicaciones prestando un servicio pésimo que desespera a los usuarios. Los equipos con altos niveles de calidad tienen un número bajo de incidencias.
La segunda es “si al final tenemos tiempo hacemos test”. Con esta frase, tratamos de explicar que nos centraremos en el alcance, que es lo que ha pedido el cliente, y una vez finalizado, prestaremos atención a la calidad de nuestro producto. Sin embargo, la experiencia nos demuestra que nunca hay tiempo para la calidad. El cliente acaba por solicitar cambios al recibir las primeras funcionalidades, y esto es debido a que las necesidades cambian o aparecen nuevas. El resultado es que llegamos a una fecha sin test de ningún tipo, que acaba por generar incidencias y un mal servicio a los usuarios.
Por último, la frase más utilizada: “en la fase dos lo arreglamos”. En muchos equipos, corremos para acabar un primer entregable en fecha, y dejamos la calidad para la siguiente fase o contrato con el cliente. Sin embargo, cuando la fase 1 ha ido mal, y hemos tenido que echar horas extra para “llegar”, nos costará cambiar de estrategia en la fase 2. El problema de fondo es la cultura de relacionar el éxito con la entrega en fecha, y no con la calidad del servicio que se presta. De hecho, si nos quejamos por el número de incidencias que generamos, alguien nos recordará la primera frase “siempre va a haber incidencias”.
“Me da vergüenza ser el arquitecto de esta aplicación”
Y así es como acabamos haciendo productos mediocres, dando mal servicio y con desarrolladores que sufren por tener que hacer chapuzas. Hace unos años, hicimos una aplicación corriendo y con poco margen de decisión. El arquitecto era uno de los más top de la empresa, y le pidieron que acompañara al equipo para terminar el proyecto. Cuando acabamos, a pesar de estar en fecha, el arquitecto nos dijo en una reunión “me da vergüenza decir que he sido el arquitecto de esta aplicación”. El motivo era simple, puestos a hacer software, hagamos buen software, ¡pero no le dejaron!
Y tú… ¿Prestas atención a la calidad de software?
