Desarrollo de software. La dificultad de salir del enfoque clásico

Esto de la gestión visual del flujo de trabajo, los daily scrum, los sprints, las retrospectivas, la programación por pares, etc… son vistos por muchos como un juego y no les culpo, yo también lo veía así cuando los árboles del enfoque clásico y su infinidad de problemas me impedían ver el bosque.

Y si quienes tienen que aplicarlas lo ven como un juego difícilmente van a funcionar. Este es uno de los principales problemas que tiene la aplicación de prácticas de estrategias o metodologías ágiles en los proyectos de desarrollo de software.

Quienes están acostumbrados a trabajar con enfoques clásicos con una orientación a producir entregables formales (sirvan o no) y a tener el proyecto clasificado en etapas diferenciadas y especializadas les va a resultar complicado ver esas prácticas como algo serio:

1) Durante años se les ha grabado a fuego que ingeniería de software es lo que ellos hacen (o que la forma de trabajar correcta es esa) y que cualquier cosa que salga de ahí no lo es.

2) También, durante años, se les ha dado el mensaje que el éxito en los proyectos de desarrollo de software está en los procesos y no en las personas. Por tanto, un enfoque en el que lo importante son precisamente las personas y su interacción y en donde las necesidades del producto predominan sobre el proceso, choca, porque se está abriendo la puerta a procesos abiertos en los que las prácticas, estrategias y herramientas se eligen en función de lo que el proyecto requiere (que no es incompatible con intentar armonizar un núcleo reducido de las mismas en diferentes proyectos) y porque no se van a trabajar con especificaciones cerradas sino que van a estar abiertas con el objeto de proporcionar al producto un mayor valor a través del feedback del área usuaria.

Sin embargo, si se echa un poco la vista atrás y vemos los resultados obtenidos en los proyectos en los que se ha trabajado con enfoques clásicos nos daremos cuenta de manera sencilla que algo falla porque el desgaste personal, el esfuerzo real y la inversión realizada en los proyectos no se corresponde con los resultados obtenidos. Sin embargo pese a esa evidencia muchos, muchísimos, siguen sin explorar otras alternativas, en unos casos porque piensan que el desarrollo de software es así, en otros porque no terminan de considerar tan negativos esos resultados y otros muchos que pese a que están convencidos de que esta dinámica de trabajo falla no consiguen sacar tiempo (o tener voluntad) para estudiar o formarse en otros enfoques de desarrollo de software.

También está el caso de quien quiere pero que no encuentra la oportunidad de poner en marcha estas estrategias, en estas situaciones digo lo de siempre, la agilidad es cuestión de actitud y eso está por encima de las circunstancias en las que tengas que trabajar en el proyecto. Lo mejor es tener la posibilidad de poder experimentar (con cabeza, siempre con cabeza y pensando en lo mejor para el proyecto) pero no siempre vamos a tener la oportunidad de ser nosotros quiénes elijan las condiciones en las que se va a realizar el proyecto.

También está el caso de quien quiere pero no se atreve, entiendo el temor, pero es importante darse cuenta de que los cambios deben hacerse de manera paulatina y que, por tanto, no se trata de introducir numerosas prácticas nuevas sino de ir haciéndolo poco a poco, hasta llegar a entenderlas bien. El primer paso lógico es la adopción de un enfoque iterativo incremental y empezar a crecer a partir de ahí.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: