Tensión, gestión de proyectos y resistencia de materiales

Un patrón que, a lo largo de mi experiencia como desarrollador se repite, es que alguien ajeno al equipo de desarrollo, generalmente alguien con cierto nivel dentro de la empresa, y con no demasiados conocimientos sobre desarrollo de software o gestión de proyectos de software, no pierda oportunidad de dejar patente que el equipo de desarrollo tiene que mantener ‘la tensión’.

Siempre parece que, desde fuera de los equipos de desarrollo, se percibe que los desarolladores de software no ponemos suficiente interés en que el proyectos progrese. Siempre se duda de la profesionalidad de lo desarrolladores y quizás, desde un punto de vista general, nos lo hemos ganado a pulso.

Sin embargo desde dentro de los equipos de desarrollo lo que se suele percibir es una presión hueca, solo de palabra y no acompañada de acciones que ayuden al equipo a progresar.

Varias metodologías modernas de desarrollo abordan esta cuestión. MSF utiliza los ‘advocacy groups ‘ y los equipos entre iguales para construir un entorno que permita que el proyecto avance de una manera sana. En Scrum el Sprint Retrospective Meeting y la gestión que el Scrum Master realiza sobre los impedimenetos, trata de asegurar que se actua sobre aquellas cuestiones que entorpecen el progreso del proyectos. Inclluso la gestión clásica del riesgo de los proyectos sigue este enfoque, aunque de una manera menos explicita.

Si bien parece claro y esta totalmente asumido en las metodologías modernas de desarrollo, que es mucho más efectivo el enfoque de eliminar impedimentos o riesgos que el enfoque de ‘introducir tensión’, es evidente que los proyectos necesitan de cierta tensión para lograr una ‘velocidad de crucero’ que asegure que el proyecto avanza de manera continua, enfocada y sotenible.

Steve McConnell en su libro Rapid Development (Pag. 600) muestra un gráfico, basado en numerosos estudios, que deja pantente que si no hay cierta tensión en la planificación, la motivación de los desarrolladores no alcanza su punto optimo . Tambien deja patente que pasado cierto punto de tensión en la planificación la motivación del equipo cae en picado. Esta demostrado que la motivación del equipo de desarrollo es un factor de vital influencia sobre exito de un proyecto, quizás incluso el factor más influyente, según mucho autores.Es peligroso adentrarse en los terrenos de la tensión excesiva en la planificación, si el desarrollador no siente como posible la planificación ni siquiera intentará cumplirla. Scrum maneja extraordinariamente esta situación, puesto que es el propio equipo el que establece su compromiso con la planificación decidiendo libremente que parte de Product Baclog aborda. En MSF esta decisión la toma, al principio de cada iteración, el jefe de proyecto, pero siempre debe tener en cuenta la opinión del resto del equipo y los datos de los ocurrido en anteriores iteraciones.

En mis tiempos de estudiante de Ing. Tec. Industrial Mecánica, una asignatura que me gustaba especialmente era Resistencia de Materiales. Las principales tensiones que podian aparecer en un cuerpo solido eran la tracción y la compresión. Simplificando el tema, un elemento estructural se sometia a compresíón cuando se ejercia presión en sus extremos y a tracción cuando se tiraba de ellos. Las estructuras de acero responden mucho mejor a la tracción que a la compresión. Pensad en lo dificil que es romper un clavo tirando de sus extremos con unos alicates, por fino que el clavo sea, y sin embargo lo facil que es doblarlo.

Siguiendo con el simil, hay dos maneras de intruduccir la necesaria tensión en los equipos de desarrollo: Por tracción, liderando el equipo en su avanze, motivándolo, ayudandolo y eliminando los obstaculos que surgan en su camino o por compresión, realizando una planificación lo más comprimida posible, y tratando de que lo único que importe sea su cumplimiento olvidando otros parémtros vitales para el exito de todo proyecto: calidad y motivación del equipo. Como las estructuras de acero, los equipos de desarrollo responden mucho mejor a la tracción que la compresión. Si una estructura de acero recibe compresión de intensidad y duración excesivas se colapsa, lo mismo ocurre con los equipos de software. Los ingenieros de estructurass se encargan de que las estructuras de acero no trabajen bajo compresión, los jefes de proyecto deben hacer los mismo con sus equipos de desarrollo.