Saltos, estadios y barreras

Si bien no debemos caer en el error común de considerar que las soluciones de administración para el desarrollo de software son únicas y que solo aquellas que cumplen con un parámetro y otro deben ser consideradas como validas, en ambos caminos, ya sea el de la agilidad como el de la procedural o típicamente más estática, se pueden encontrar errores conceptuales desde su aplicación.

Por supuesto, estos errores suelen salir a la luz cuando contrastamos las técnicas y analizamos cada una desde la perspectiva de la otra.

Este es el caso donde contrastaremos los procesos formales desde el punto de vista de la agilidad, y como, en algunos casos, al intentar ser lo más formal posible se incurren en problemas que no son visibles fácilmente.

Si consideramos que se suele aplicar la formalidad en procesos de desarrollo de software mediante la aplicación de experiencias de las administraciones aplicadas en los procesos industriales, de cintas de producción, entenderemos que el pensamiento de aplicación en el proceso de desarrollo de software suele reducirse a intentar simular esta realidad, donde cada tarea deberá pasar por saltos o estadios de control, donde cada punto de control deberá dar el visto bueno para que la siguiente máquina productiva pueda continuar con su labor de creación. Por supuesto, esto podría tener mucho sentido en diferentes ambientes de desarrollo, incluso algo que puede venírsenos a la mente es la idea del desarrollo en cascada, pero así como podría solucionar algunos problemas durante el proceso de desarrollo, también incorpora otros problemas que pasan imperceptibles, incluso aceptados como una condición normal y profesional del proceso.

Por otra parte, los marcos de trabajo ágiles tratan de palear este problema desde la raíz, desde la concepción de la idea de trabajo en grupo. Si hablamos de Scrum, sabremos que este nos implora por la creación de un equipo interdisciplinario que, en conjunto, como equipo, atacará la situación, el problema a resolver. Como tal, todas las partes del proceso anteriormente nombrado, o un poco de cada una, estará incluida en el equipo. Desde el desarrollador hasta el tester o representante de la calidad final del producto. Por tal motivo, todas las partes están conscientes de la evolución del proyecto de forma constante, pujando para que este cumpla con los objetivos, no solo del cliente, si no que, además, de la empresa.

Pensemos que muchas empresas, al haber implementado procesos considerados formales se verán en la necesidad de que para cumplir con los formatos internos previamente establecidos, mantendrán algunas de las prácticas al estilo línea de producción en vez de asumir la necesidad del trabajo en equipo real. Sumado a esto, cada salto o etapa posee en muchos casos poder de veto por sobre la anterior, así, un producto no podrá seguir al siguiente estadio si el equipo de verificación no lo aprueba, y el mismo no podrá salir al mercado si el equipo que asegura la calidad no lo aprueba. El problema de esto radica en que cada salto no tiene conciencia directa por sobre el anterior, incluso solo ve y analiza el producto en el momento que a ellos les tocase accionar sobre el producto, por lo que, el poder de veto o rechazo se podría estar aplicando en el momento menos indicado. Imaginemos un producto listo para salir al mercado, donde solo necesita la aprobación del último estadio, el salto final. Este equipo entra en acción, y toma recién, en ese momento, contacto con el producto, al no haber participado durante el proceso de construcción encuentra diversas fallas, no estructurales, no funcionales, simplemente fallas sobre formalismos de la estructura rígida planteada en la empresa, y veta la salida hasta que estos elementos sean corregidos.

En el caso anterior, si el representante del equipo con poder de veto hubiese estado presente en todo el proceso de desarrollo del producto, estas fallas podrían haberse encontrado con anticipación, y no hubieran explotado en el momento final, momento, por supuesto, menos indicado. Por esto, debemos entender que la conformación de un equipo multidisciplinario es vital para que la producción sea ágil y dinámica, que puedan detectarse los problemas de forma temprana y no cuando el tiempo se ha terminado. En todo caso, este concepto no es exclusivo de la agilidad, simplemente es cuestión de dejar de aplicar modelos industriales prestados y plantear otros que se apliquen al desarrollo de software.



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