Hola a todos, hace poco compartía con un compañero el cual trabajó durante mucho tiempo en cascada y ahora esta comenzando a trabajar con scrum y esta viéndose en unos retos bien importante, el cual me argumentaba que:
- en cascada los problemas no teníamos los problemas de deuda técnica que existen en ágil. En cascada siempre entregabamos...
no les niego que mi cara fue similar a esta.
Vamos primero a aclarar términos:
 |
| Ver más sobre deuda técnica en (1) |
- Nos comprometemos a una fecha y no la cumplimos
- Las pruebas las empezamos 2 o 3 meses después de la fecha de finalización del proyecto (si es que tenemos suerte)
- Nos quedamos en ciclos interminables de pruebas (4, 5 o hasta más) para poder entregar el sistema.
- El cliente nos acepta el producto después de dós o más ciclos de pruebas
- Salimos a producción muertos de miedo y estabilizando el sistema por más de 6 meses (muchas de las condiciones de aceptación de un producto en cascada dice cuando por 2 meses no aparezcan problemas en producción).
Estas disfuncionalidades son mayormente creadas por la pobre calidad técnica y lo que estamos tratando de hacer es entregar el proyecto con fuerza bruta.
¿Y en Agile como es?
La verdad es que, si tenemos excelencia técnica (buenas prácticas ágiles, buena ingeniería, buena arquitectura), esto no se presentará (o al menos se reducirá enormemente su impacto) y la imagen de arriba hará honor a lo que profesamos:- Entregamos software de valor frecuentemente
- Y la medida de progreso es software funcionando
- Solo se centra en el proceso scrum (o como sea que lo llamen) y no en las personas.
- Los equipos no mejoran sus prácticas técnicas.
- Los scrum masters solo se enfocan en mejorar la comunicación del equipo cuando hay muchos aspectos a mejorar.
- Las retrospectivas son las mismas hace 5 sprints.
- Los equipos no son retados técnicamente por el scrum master (ver más acá Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo).
- No se gestiona la deuda técnica.
- No hay una preocupación seria por parte del equipo de la excelencia técnica.
Algunos tweets
Para terminar quisiera compartirles algunos tweets relacionados con la deuda técnica y la excelencia técnica tanto en cascada como en ágil.— Jorge Hernán Abad L. (@jorge_abad) April 28, 2016
No monitorear, ni pagar la #DeudaTecnica cada sprint, es una característica del #BadAgile https://t.co/t8Ub2tCrKO#TechnicalDebt #Scrum— Jorge Hernán Abad L. (@jorge_abad) May 17, 2017
Otra Definición de #DeudaTecnica— Jorge Hernán Abad L. (@jorge_abad) February 2, 2017
Cuando terminas trabajando para el sistema y no el sistema para tí#technicalDebthttps://t.co/zO40WzAp3O
La deuda técnica creciente termina por agotar la velocidad del equipo #Scrum y ocasionando la generación de cero valor #Agile #TechnicalDebt— Jorge Hernán Abad L. (@jorge_abad) May 5, 2016
Cualquier intento de escalar #Scrum sin contar con Excelencia Técnica ni Gestión de la Deuda Técnica muy seguramente será un fracaso— Jorge Hernán Abad L. (@jorge_abad) July 24, 2017
#lesaAgilidad— Jorge Hernán Abad L. (@jorge_abad) April 25, 2017
Si como equipo no estas mirando, midiendo, controlando la deuda tecnica #techinicalDebt #agile #scrum #fail
La deuda técnica es curable si se diagnóstica a tiempo #techinicalDebt— Jorge Hernán Abad L. (@jorge_abad) May 20, 2016
3 ideas:— Jorge Hernán Abad L. (@jorge_abad) April 20, 2016
El sw con el tiempo se degrada
la deuda técnica debe ser identificada y gestionada
Sin excelencia técnica no hay agilidad
Haz buen software o alguien (talvez tu mismo) terminará pagando la deuda técnica de tu proyecto #agile #scrum pic.twitter.com/N7nykg2rH2— Jorge Hernán Abad L. (@jorge_abad) March 16, 2016
Hacer #Scrum sin gestionar la #DeudaTecnica es hacer problemas de forma iterativa, incremental y en ciclos cortoshttps://t.co/t8Ub2tkQme— Jorge Hernán Abad L. (@jorge_abad) June 21, 2017
Ya sea en cascada o en #Agile sino hay excelencia técnica se va directo al fracaso, eso es indistinto del método.— Jorge Hernán Abad L. (@jorge_abad) May 30, 2017
Comentarios, Aclaraciones, Notas y Referencias
- Presentación sobre deuda técnica (clic aquí)
- En proyectos más pequeños de tamaño (5 meses o menos) las disfunciones técnicas que tiene cascada para desarrollo de software no se evidencian tan fácilmente como en proyectos grandes, pues en últimas el mal código siempre generará impacto tipo de impacto en el tiempo, costo y satisfacción del cliente independiente del tamaño del proyecto (Gracias Luis Mulato @LuisMulato por el feeback y correciones respecto a este último punto y al post)
