Con tanta empresa intentando, repito, intentando, que otra cosa es lograrlo, implantar modelos basados en aquello que entendemos como ágil, existen una colección de frases hechas y debates que se repiten en multitud de lugares. Una de esas frases, y debates, es si la agilidad es hacer las cosas más rápido (evitaré usar la palabra velocidad para no confundirnos con la métrica que típicamente hace uso de los puntos historia).
No te puedes imaginar la de veces que lo he escuchado, la frase más el debate posterior entre aquellos que ven “agilidad = a más rápido” y los que dicen que no, que no, que eso es que no has entendido qué es ágil, “que ágil no es hacer las cosas más rápido”.
Este debate de si agilidad es igual a más rápido o no, me recuerda al debate de ¿Qué significa “saber programar”? ¿Entendemos todos lo mismo?, en el que hablábamos de que lo primero que habría que saber es qué significa para ti saber programar, aquí la traslación sería “qué significa para ti rápido”.
Este debate puede tener tantas lecturas como interpretaciones de “rápido” tenga cada uno en la cabeza. Creo entender que por “rápido” todos tenemos en la cabeza “obtener un resultado” en el menor tiempo posible, pero…
“Más rápido”, pero… más rápido que ¿qué?
Y para complicar más el debate, “agilidad es hacerlo más rápido…”, más rápido que… ¿qué?, ¿Entendemos que estamos hablando de más rápido que el tradicional proceso basado en el ciclo de vida en cascada? o ¿entendemos que hablamos de más rápido que el tradicional «codifica – prueba y saca algo ya»? Porque la cosa puede cambiar mucho.
Si por rápido estás pensando en sacar una versión en un periodo de tiempo menor que en cascada, efectivamente, haciendo lo ágil eres más rápido que haciéndolo en cascada, ya que sacas versiones antes, en iteraciones menores, Sprints o similar, obviamente con menos funcionalidad que la “gran entrega final del cascada”, pero con la idea de poder adaptarlas una vez que se enfrentan a la realidad.
Pero siguiendo un proceso ágil no vas a ser tan rápido como el modelo “codifica – prueba y saca algo ya como sea”, ya que un proceso ágil buscará una sostenibilidad y constancia en el tiempo, en lo que refiere al ratio de entrega de valor, lo que implica dedicar explícitamente tiempo en cada iteración para controlar la Deuda Técnica.
A corto plazo un proceso ágil será menos rápido que un “codifica – prueba y saca algo ya”, pero a medio plazo un modelo ágil es más rápido que un “codifica – prueba y saca algo ya como sea”. El caso del cascada puede ser aún peor: nadie garantiza control de deuda técnica ni que la gran entrega final valga al usuario.
Esto se entiende bastante bien si conoces el eufemismo de la deuda técnica, hacer las cosas mal es más rápido a corto plazo, pero condiciona el futuro. Para este punto, mejor te dejo dos post: Yo que tú vigilaría la deuda técnica (y sus intereses) que puedes estar pagando durante mucho tiempo y La deuda técnica. Todo el mundo debería saber que la mala calidad software al final se paga
“Más rápido”, pero… más rápido haciendo ¿qué?
En un modelo ágil las entregas son más frecuentes, tienes entregas más rápido (entendiendo rápido como “en un tiempo menor”). Y con control de deuda técnica, no olvidemos que el ciclo de vida ágil no sólo es incremental, también es iterativo, el ciclo de vida iterativo e incremental y el riesgo de olvidarse del iterativo y quedarse solo con el incremental.
Pero, obviamente, cada entrega tiene menos funcionalidad que la súper gran entrega que se ha planificado como resultado del cascada. Pero la súper entrega final del cascada puede tener un alto número de requisitos o necesidades que nadie finalmente quería y en agilidad esto no debería pasarte.
—
¿Más rápido? Depende. A corto plazo nada es más rápido que sacar algo de cualquier manera. El problema vendrá un tiempo después, cuando el número de prácticas destructivas sea tal que nos haga ser lentos para siempre (software walking dead)… ¿te suena de algo?
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Buena entrada Javier, me ha hecho gracia el modelo “codifica – prueba y saca algo ya como sea”, aunque lo veo demasiado optimista, creo que es más común el “codifica y saca algo ya como sea”, sin lo de probar (como mucho puede que incluya depurar, que no es lo mismo).
Es un tema que da para mucho. La respuesta corta es que la agilidad te puede ayudar a ser mucho más rápido. Si ese es realmente tu objetivo. Si entendemos la agilidad como un conjunto de métodos para desarrollar mejor (manifiesto) y no sólo como la metodología X.
Cuando pasas de un entorno donde no haces testing automatizado (ya no digo tdd que sería lo ideal), no haces ic o incluso no tienes control de versiones, a uno donde tienes y dominas estas prácticas, eres muchísimo más rápido.
También decir que hacer las cosas mal no necesariamente es hacerlas más rápido. Muchas veces lo que ocurre es que el equipo no sabe hacerlas bien de primeras (falta de capacidad o experiencia), así que las hace mal. Al hacerlas mal, puede aprender a hacerlas bien o al menos mejor. Pero le van a dejar borrar lo que hizo mal y volver a hacerlo mejor?
A veces no te queda otra, las has hecho mal y no funciona como debería. Te toca hacerlas bien. Otras, sobrevives a base de parches.
Al final todo depende del contexto, igual que con el Testing 😉
La deuda técnica es un buen modelo para entenderlo, deuda técnica a corto plazo acelera pero luego acaba frenando.