Intentaba resolver este tema desde el principio, pero luego me di cuenta que había algo más detrás. Veamos el escenario completo. ¿Qué estamos asumiendo del desarrollo tradicional? Creo que todos llegamos a esta discusión pensando en equipos de 100 ingenieros, 500 ingenieros, incluso 2000 ingenieros trabajando con desarrollo tradicional, y que por lo tanto el desarrollo tradicional funciona de manera probada en cuanto a poder escalar. Pero primero respondamos esta pregunta: "¿Qué tan bien escala el desarrollo tradicional?".
Para responder a este pregunta primero deberemos definir el término "escalar". Una buena definición es que al agregar nuevos recursos, ocurrirá un incremento lineal en la salida efectiva, si casi ninguna disminución de la eficiencia. Para el software, la salida y la eficiencia se traducen en nueva funcionalidad y en productividad. Esto significa que si tenemos un equipo de 50 ingenieros y añadimos 50 ingenieros más obtendremos el doble de la salida. ¿Pero cuándo fue la última vez que vieron ocurrir eso? ¿Lo vieron ocurrir alguna vez? En mi experiencia, después de hablar con cientos de organizaciones que usaban un desarrollo tradicional de software, al agregar nuevos recursos cae la productividad y por lo tanto la salida no tiene un incremento lineal. De hecho, en muchos casos la salida disminuye al agregar más recursos.
¿Qué hacés para "escalar" tu organización de desarrollo? ¿Actualizás meticulosamente los Gantt y las estimaciones? ¿Planificás montones de reuniones? ¿Pasás mucho tiempo asegurándote que los requerimientos y los diseños sean los adecuados? ¿Reservás el 30% de desarrollo para testing (y arreglo de errores)?
En mi experiencia, después de hablar con cientos de organizaciones, la respuesta a la pregunta "¿Qué tan bien escala el proceso de desarrollo tradicional?" es un "No muy bien". Hace rato que sufrimos este problema, en gran medida porque aunque teníamos el problema, las causas raíces eran dificil de encontrar, y más aún solucionar.
El punto es que si estás implementando Ágil en una organización grande, no te desalientes cuando encuentres problemas para escalar. Los problemas siempre estuvieron ahí, sólo que no eran obvios. Ahora, en vez de preguntarnos porqué las cosas no están funcionando como esperábamos al final de un proyecto, podemos darnos cuenta de problemas concretos, como por ejemplo que nuestra organización no tiene una política para coordinar los cambios en las API que usan múltiples equipos. Como Ágil expone estos problemas, podemos comenzar a tomar medidas para resolver y así crear un proceso de desarrollo más escalable, que también forma parte del desarrollo Ágil.
Original: DosIdeas
No hay comentarios.:
Publicar un comentario