En un artículo de Yourdon (sí, el de la programación estructurada y otras aportaciones a la orientación a objetos) sobre actitudes y reacciones frente a técnicas de productividad en programación, escrito, ojo, quédate con este dato, en 1975, hace 40 años, trata, entre otras técnicas, el caso de los “walkthrough”, que, por si no te sonaba, es el antiguo nombre que se le daba a las “peer reviews”, revisión en grupo o por otra persona de partes de la aplicación, normalmente código, si bien puede aplicarse a cualquier trabajo intelectual.
El concepto de “walkthrough” cae bajo los llamados enfoques de trabajo en equipo «sin egos», como le llamaba Weinberg, el de “The Psychology of Computer Programming” (1971), y que hoy es una más de esas ideas recuperadas por el mundo ágil, normalmente bajo otros nombres, como pair review, Mob Programming o la práctica de la “Propiedad Colectiva del Código» (Collective Code Ownership) de Extreme Programming (a la que ya le dediqué un post).
El “walkthrough”, decía Yourdon en el 75, “es considerado un tanto radical, ya que sugiere que todo el equipo debe revisar el código desarrollado por cada uno de sus miembros, con el objetivo de encontrar errores y asegurar que el código cumple con estándares de programación razonables”. 40 años después, este mismo año 2015, en uno de los proyectos en que andamos metidos lanzamos la idea de que el código, y cualquier desarrollo intelectual, debe ser compartido y la reacción, típica, sigue siendo de “-qué fuerte”, de “-que novedoso” o incluso de “-eso aquí es imposible”.
Volviendo a Yourdon, decía él en su artículo, que en su experiencia, “el programador medio nunca ha participado en este tipo de prácticas“. Y que, para la mayoría, “es algo inaudito”, y que incluso llegaron a decirle que leer el código de otro es como «leer su correo personal. Simplemente no se hace». “Hemos visto problemas de ego terribles, situaciones en las que los programadores no se hablan durante una semana después de un walkthrough”.
Pero las objeciones a que el código sea revisado, visto, por cualquiera, siendo propiedad de todo el equipo, no sólo de quien lo desarrolló, no vienen solo de los programadores, la otra gran fuente de objeciones viene de “los jefes”. Aunque las prácticas de “código compartido” han sido usadas desde hace años, pongamos más de 40, y, en alguna de sus formas, son típicas en equipos de alto rendimiento. Hay multitud de factores que apoyan la práctica, como que se reparte el conocimiento, se disminuyen los errores, aumenta la productividad, etc.
“La mayor parte de las objeciones a los “walkthrough” han venido de los gerentes que sienten que es una pérdida de tiempo, o que sienten que los programadores jóvenes no podrían aportar ideas útiles”, decía Yourdon, año 75.
Terminaba el artículo de Yourdon diciendo que después de explicarlo, la mayoría de los programadores ven el valor de los enfoques «sin ego», y la mayoría están de acuerdo con ellos. Y que el principal problema con el enfoque es que la mayoría de los programadores nunca han tenido ninguna experiencia o práctica de trabajo con estas «terapias de grupo».
En el fondo, hay cosas que no cambian mucho con los años.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023