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:

1. 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.
2. 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.
3. 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

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.

Estas limitaciones técnicas postergan una entrega por días, aunque la solución pueda ser escrita en código rápidamente, validarla manualmente alarga el ciclo.

¿Qué hacer?

El conseguir una forma de trabajo, que permita varios deploys al día, requiere de una disciplina constante en el equipo. Si te identificaste con algunas de las razones que describí, hay dos cosas que debes buscar desarrollar en tus equipos: autonomía y excelencia técnica.

• Autonomía, para que el equipo pueda tomar todas las decisiones y autoorganizarse de la mejor manera.
• Excelencia técnica, para aprovechar todas las ventajas de la tecnología en su propia forma de trabajo.

¡Con gusto te apoyo! Dime de qué manera podemos colaborar.

¡Nos vemos en la siguiente entrega!

Sígueme en redes

• Facebook: @SoftwareEngineeringCoach
• Twitter: @EdgarTeamCoach
• LinkedIn: https://www.linkedin.com/in/edgarfernandezr/