Entrevistamos a Raúl Fernández, Director de Operaciones de LedaMC, que explica cómo la agilidad en el desarrollo de software no funciona a base de magia
Raúl Fernández, Director de Operaciones de LedaMC
2021 ha sido un año bastante anómalo, aunque mejor que el 2020. Sin volver a la COVID-19 ¿Qué enseñanza destacaría de este año?
La primera palabra que me viene a la mente es “resiliencia”, probablemente porque está tan de moda que la escuchamos de continuo, pero creo que la enseñanza más destacable de 2021 ha sido la de “verificar, no creer”. Voy a explicarme un poco mejor.
A nivel global todos hemos tenido que aprender a comprobar qué era lo que mejor funcionaba, lo que mejor hacíamos para potenciarlo y a la vez detectar lo que no era tan bueno para mejorarlo.
El teletrabajo de toda la plantilla parecía una locura, pero verificamos que funcionaba y en tiempo récord.
Las prácticas ágiles como Scrum, justo antes de la pandemia, parecían que eran la panacea para todas las compañías, pero ya han salido multitud de voces en contra de algunas de ellas. Estas voces promueven la verificación para asegurar que nos dan los beneficios que prometen antes de creérnoslas a pies juntillas como si de una religión se tratara. Cómo por ejemplo la iniciativa de Agile 2.
¿La agilidad en el desarrollo de software no sirve? ¿Todo el mundo está equivocado?
Vayamos por partes. La agilidad como cualquier tendencia o práctica puede implementarse de forma correcta o de forma errónea. Asistimos cada día a desastres de su implementación que luego se matizan o se tapan. Digamos que para algunos es el mismo perro con distinto collar.
Parece como si todo el mundo al escuchar Agilidad o Transformación Digital se lanzaran de cabeza tras ellas, como si de unas palabras mágicas se tratara, unas palabras que impidieran fallar hagas lo que hagas.
Sólo pensemos por un momento. Reflexionemos sobre las personas de cada organización, no todo el mundo es igual, incluso, sin existir mala intención la gente puede interpretar de forma errónea lo que hace y equivocarse. Eso es lo que debemos evitar, debemos verificar que todo va como debe ir y ayudar a mejorar a quienes no lo estén haciendo. Y, quien no quiera mejorar no tiene cabida.
¿En qué consiste esa iniciativa que ha mencionado: Agile 2 ¿Cómo podemos comprobar que nuestro desarrollo de software nos entrega lo que esperamos de él?
Agile 2 pone en entredicho muchas de las aseveraciones de la agilidad hasta la fecha, pone en duda al equipo, pone en duda al liderazgo compartido y pone en duda a Scrum.
No lo hace desde una perspectiva negacionista, sino desde la perspectiva del método científico: debemos utilizar aquello que mejor funciona, aquello que hemos comprobado que funciona mejor, aquello que hemos verificado.
Hay varias formas de verificarlo. Por ejemplo, la Comisión Europea propone hacerlo a través de la cantidad de producto software, y así lo indica en varias de sus tenders de desarrollo de software.
Dando un poco más de detalle, lo que hace es medir el valor que entregan los equipos de desarrollo de software como cantidad de producto software, es decir cantidad de funcionalidad que negocio puede utilizar con ese software. Es la definición más objetiva de valor que podemos encontrar. A través de esa definición podemos establecer comparativas con el esfuerzo y/o el precio que cuesta desarrollarlo. Nuestros clientes, muchos de los cuales están en el IBEX-35, también utilizan estos métodos.
Entonces, ¿podríamos afirmar que sólo focalizándonos solo en que nos entreguen cada vez una mayor cantidad de producto software sería suficiente? ¿No habría que tener en cuenta la calidad?
Muy buena pregunta. De hecho, esa es la clave, tener una visión de 360 grados. Nuestra propuesta cuando hablamos con un cliente es siempre pensar en más de una variable porque, si nos fijamos sólo en una, las conclusiones pueden ser erróneas. Déjame que lo explique con un caso real.
Un cliente de Retail contactó con nosotros para realizar un benchmarking de sus desarrollos en tres tecnologías diferentes. Querían mejorar su time-to-market que no terminaba de acortarse. Realizamos un benchmarking de eficiencia y calidad. En el primero, obtuvimos como resultado que su productividad era mejor que la de mercado, pero en el segundo obtuvimos que esta eficiencia implicaba que las pruebas que realizaban eran mucho menores a las realizadas por la media del mercado y, por tanto, no detectaban el número de errores suficientes. Esto, que puede parecer bueno, lo que fomentaba era el traslado de los errores a las fases finales del desarrollo dilatando el time-to-market y el coste de su corrección.
Gracias a la revisión de 360 grados logramos detectarlo y verificamos que parte del eslabón es la que falla.
¿Un deseo para 2022?
Que no nos dejemos llevar por modas, sino que verifiquemos que es lo que funciona realmente en nuestro caso. Eso nos dará los beneficios que realmente esperamos y necesitamos para prosperar en 2022.
