Muchas personas consideran que desarrollar software con Agile les permite ser más rápidos. Ser ágil tiene una parte de rapidez y una gran parte de flexibilidad. Flexibilidad en los planes, en tu futuro, en la toma de decisiones. ¿En qué te basas para tomar decisiones en tus equipos de software?
Si estudiamos Agile veremos que uno de sus valores es “software funcionando por encima de documentación exhaustiva”. A esto le podemos sumar uno de sus principios “software funcionando es la principal medida de progreso”. Pero… ¿Eso lo hacemos todos verdad? ¿Quién no ha medido el número de pantallas finalizadas para calcular el avance? Por ejemplo, si tengo que hacer un formulario dividido en 10 pantallas y hemos desarrollado 5, entonces diremos que estamos al 50%.
¡Llega la fecha!
Todo es maravilloso, medimos el software terminado, somos flexibles con nuestro cliente y aceptamos cambios. Parece que todo va bien hasta que llega (música de terror) ¡La fecha! Un día hay que entregar, y entonces aparecen problemas al hacer la integración de nuestras pantallas que fueron finalizadas en entornos no productivos. Las incidencias se disparan, el cliente se impacienta, los cambios no paran de llegar y los sobreesfuerzos aparecen ¡Todos vamos a morir!
Aquí tengo una mala noticia, cuando llega esta situación, poco se puede hacer. Agile no dice nada de la integración, no dice nada de que pactases un web service con un tercero que no ha cumplido ni dice nada sobre el cabreo de tu cliente porque no llegas. Incluso añadimos otro problema más. Una vez que hemos sobrevivido a la subida, realizado esfuerzos, calmado al cliente… ¡el usuario final rechaza nuestro software!
¿Qué está ocurriendo?
No paramos de leer artículos sobre las bondades de Agile y sin embargo, no nos está funcionando. Quizás, debamos madurar mejor qué significa ser ágil o volver al modelo en cascada (aunque esto no lo recomiendo). Cuando hablamos de software funcionando hablamos de un software que el usuario final pueda tener en sus manos. Un software probado, testado, revisado por compañeros, exprimido en pruebas de rendimiento, con la seguridad demandada, integrado con otros sistemas…. y si puede ser en un entorno productivo. Hacer todo esto es un esfuerzo bestial, por eso nos gusta dejarlo para el final, para hacer todas estas tareas con todo nuestro software. El problema de dejarlo todo para el final es que tenemos mucha incertidumbre sobre lo que nos vamos a encontrar. Por eso es esencial la entrega por Sprint, la entrega en cada Sprint nos permite despejar variables y además testear contra el mercado lo que el usuario quiere. Si el usuario nos dice que no le gusta, podremos pivotar para darle software que valore.
No nos olvidemos del software funcionando como medida de progreso. Si tengo 5 pantallas de 10 pero no están listas para un usuario final, realmente nuestro progreso es 0%. Poner otro porcentaje es engañarnos y chocarnos con la realidad cuando hagamos la subida. Esto se conoce como la regla 0-100 donde o está terminado (100%) o no se contabiliza (0%). Es muy dura la regla, pero trata de incentivar la finalización de cosas por encima de una gran cantidad de software. Cómo leí hace poco “es mejor tener 30 tareas done que 50 doing.
El incremento
En Scrum esto se aterriza con varios conceptos. Uno de ellos es el artefacto “incremento”. Es curioso que este artefacto puede ser la clave del éxito, sin embargo, es el gran olvidado porque la gente confunde artefacto con una herramienta software (por eso no nos olvidamos del Product Backlog y del Sprint Backlog).
El incremento representa la suma de todos los elementos de nuestro Product Backlog que hemos finalizado y el valor que representan cada uno de ellos. Estos elementos deben estar “terminados” y esto es una de las claves de Scrum. Cuando decimos que algo está terminado decimos listo para ser usado por el usuario final. Tal y como decíamos, si ya hemos resuelto la subida nos quitamos incertidumbre.
El concepto “terminado” siempre se entrecomilla porque depende de nuestro contexto. El concepto finalizado por tanto es abierto, y precisamente por eso es esencial que los Scrum Teams dispongan de la Definition of Done (DoD). La DoD representa todo lo que tiene que cumplir cada elemento del Product Backlog para estar finalizado y listo para subir a producción.
¿Qué incluye un buen Definition of Done?
Algunos ejemplos de equipos que hemos visto:
- Que cumpla los Criterios de Aceptación
- Que se integre con otras partes
- Pruebas unitarias, integradas, regresivas, de seguridad o cualquier otro tipo.
- Revisión por un compañero o por varios a nivel funcional.
- Revisión del código por un compañero.
- Revisión por parte del Product Owner.
- Estar desplegado en un entorno concreto.
- Incluso hay quien incluye el “estar desplegado en un entorno productivo”.
La Definition of Done marca la diferencia entre los equipos que hacen software iterativo de los que además es incremental. Los elementos que cumplen esta definición son los que se contabilizan de cara a un posible seguimiento y son los que se inspeccionan en la Sprint Review. Si además, forzamos a que las subidas se hagan de manera contínua o en periodos muy cortos de tiempo obtenemos otro de los mejores beneficios de Scrum: el feedback.
Scrum no te garantiza el éxito, pero desde luego, si tienes información de tus usuarios seguro que aumentas tus opciones de acertar. Cuando esperamos muchos meses para una subida aumentamos el riesgo de estar equivocándonos. Por eso Scrum le está funcionando a muchos equipos, porque actúan con un input constante de lo que sus potenciales clientes quieren y eso les ayuda a aportarles valor de verdad que haga que triunfe su software.
Todo esto es lo que conocemos como “mentalidad de Producto” y es la clave del cambio cultural que necesitan las organizaciones que quieren triunfar en el mundo digital. Uno de los últimos motivos es que, como dice Jurgen Appelo en el libro Management 3.0 “una vez que introducimos un nuevo software a nuestros usuarios, estos cambian y sus exigencias también, por lo que siempre tendremos que estar reinventándonos”.
