Entregas demasiado lentas: las razones por las que tu tiempo de desarrollo es muy largo

Ingeniería de Software de Élite

En las cinco red flags de las organizaciones de software, que les detiene para lograr resultados de élite, tenemos el tiempo de desarrollo muy largo; esto es, la incapacidad del equipo para entregar software funcionando en intervalos cortos, regulares y frecuentes. Algunas empresas se distinguen por su innovación, la cual notamos porque brindan funciones nuevas en sus productos constantemente. Hablamos de compañías como Amazon, Netflix o Facebook (ahora, Meta), quienes crearon una forma de trabajo capaz de hacer varios deploys al día, completamente funcionales. Amazon lo hace a una tasa de 30,000 al día; Netflix, 500 y Facebook 2 veces diariamente. ¿La tuya es capaz de hacer esto? Tal vez te encuentras en la circunstancia normal de muchas organizaciones: solo hacen una o dos entregas (deploys funcionales) AL AÑO. ¿Cuáles son las razones de esto? Te presento las más importantes. Pasan muchos días entre el fin de un ciclo (sprint) y el inicio del siguiente Los frameworks de la filosofía ágil, basados en ciclos, son muy populares. Estos recomiendan dividir el trabajo en ciclos cortos (sprints), en los que se produce un MVP listo para ser utilizado. La idea es que, después de cerrar uno, inmediatamente comenzar el siguiente, incorporando las nuevas User Stories y la retroalimentación del anterior. Muchos equipos dejan pasar días, o semanas, entre el fin de un ciclo y el inicio del siguiente. Las causas suelen ser: Realmente no entregaron un MVP sino un producto a testing; el equipo de QA ha regresado la entrega con muchos reportes de defectos para reparar. No hay autonomía en el equipo para tomar decisiones. Si el responsable de autorizar o dar visto bueno a la planificación está ausente, el trabajo se detiene. Proceso burocrático. Se requieren muchos pasos para lograr el visto bueno de inicio; por ejemplo, que los requerimientos sean definidos, priorizados y aprobados por varias personas. Tiempos muertos entre silos funcionales Si tu equipo está organizado en grupos especialistas (analistas, desarrolladores, testers, etc.), verás que las personas tienen picos de ocupación y desocupación. Esto es porque el trabajo está avanzando linealmente, pero necesita de que todo esté terminado para poder pasar al siguiente grupo; éste tiene que esperar, hacer su parte y enviarla al siguiente, que también está a la expectativa. Mientras están desocupados, quizás están haciendo otras labores (capacitarse, arreglar defectos, entre otros), pero el progreso del sprint no está avanzando más rápidamente. Burnout Imagen: Macrovector para Freepik Un equipo cansado es improductivo. Algunos señalan que una noche sin dormir (o poco sueño) reduce la efectividad de un Ingeniero en 20%; dos consecutivas la reducen 80%. La creencia de que trabajar más horas hará que el resultado sea más rápido es contraproducente. Muchos Project Managers y Gerentes insistirán en prolongar las jornadas de trabajo para acelerar el desarrollo, pero con esto solamente lograrán que el equipo se queme. En esta circunstancia, por más horas que acumulen, no podrán producir un buen resultado y la cantidad de defectos y problemas crecerá exponencialmente. Pobres técnicas de ingeniería para validar la solución A lo largo de mi carrera, he observado que una limitante para las entregas continuas es la carencia de técnicas ingenieriles: Los desarrolladores no saben cómo probar un módulo si otro, u otros, no están terminados. Por esto, deciden usar un enfoque en Cascada para completar todas las partes y poder probar. El equipo no sabe cómo automatizar las pruebas. Los procesos son manuales y replicar una prueba toma mucho tiempo, sobre todo si falla. El proceso de instalación de cualquier cambio, actualización o ambiente es completamente manual. Literalmente, copian y pegan archivos de una computadora a otra en lugar de tener scripts o software que haga el deploy por ellos.