sábado, julio 29, 2017

Noticia Falsa: En cascada no existía deuda técnica




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)
La verdad parece que se nos olvida que en proyectos construidos en cascada de más de 6 meses (2) pasan las siguientes disfuncionalidades respecto a la parte técnica:
  1. Nos comprometemos a una fecha y no la cumplimos
  2. Las pruebas las empezamos 2 o 3 meses después de la fecha de finalización del proyecto (si es que tenemos suerte)
  3. Nos quedamos en ciclos interminables de pruebas (4, 5 o  hasta más) para poder entregar el sistema.
  4. El cliente nos acepta el producto después de dós o más ciclos de pruebas
  5. 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
Pero la realidad no es así, los equipos en general caen en "Agilidad Cosmética" que tiene como síntomas:
  • 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.
Y debido a la entrega frecuente hace que la pésima calidad del software evidencie más rápido nuestras falencias técnicas como equipo de desarrollo.

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.

























Comentarios, Aclaraciones, Notas y Referencias

  1. Presentación sobre deuda técnica (clic aquí)
  2. 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)

No hay comentarios.:

Publicar un comentario