Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

Metodologías hasta en la sopa

Juanjo Navarro

Cada año aparecen multitud de metodologías prometiendo solucionar la crisis del software. ¿Qué se puede esperar de todos estos métodos? ¿Cumplen lo prometido?

por Juanjo Navarro, 13 junio 05

Nuestra especialidad es muy dada a metodologías. Parece que no es posible que pase un año sin que aparezcan diez nuevas metodologías revolucionarias que vienen a solucionar de un plumazo la famosa crisis del software.

Lo cierto es que sólo tenemos que acercarnos a cualquier congreso de informática, darnos una vuelta por foros sobre el tema, leer unos cuantos sitios, para oír hablar maravillas sobre mil y una metodologías. Sus gurús, verdaderos monjes de la nueva religión nos hablarán sobre los aumentos exponenciales de productividad que su sistema proporciona, nos presentarán estudios comparativos donde se demuestra que en el proyecto X, en la empresa Y, en el que su metodología se aplicó de forma experimental, se consiguió completar un gran proyecto en el tiempo planificado, cosa extrañísima en el desarrollo de software, e incluso en menos tiempo del planificado (!!)

Aun aceptando que el método científico en estos casos de estudio brilla por su ausencia, que la mayoría de informáticos jamás hemos oído hablar de grupos de control, de métricas de productividad y demás parafernalia científica básica. Aun aceptando que los informáticos, desesperados por conseguir mejores resultados, nos convertimos fácilmente en creyentes y dejamos de lado las reglas más básicas del sano escepticismo. Aun aceptando todo esto, digo, no deja de resultar curioso el germen de realidad, de aumento real de productividad que hay detrás de dichos estudios.

¿Todas funcionan?

Lo cierto es que si hablamos con los participantes en dichos proyectos de prueba todos parecen encantados con los mismos. Programadores, jefes de proyecto, usuarios, clientes, todos parecen convencidos de las bondades de la metodología, de lo positivo que resultó para su proyecto, de que disminuyó el tiempo de desarrollo y aumentó la satisfacción general y la facilidad de uso.

¿Cómo puede ser esto así? Entiéndaseme, no digo que no haya una cierta metodología que no haya proporcionado realmente estos beneficios. Pero ¿todas las metodologías? Unos sistemas abogan por aumentar la documentación, otros dicen que hay que aligerar de papeles el proyecto. Unas metodologías hablan de oficinas privadas y silencio para los programadores para aumentar su productividad, otras dicen que todo el trabajo hay que hacerlo en parejas y que todos los programadores deben estar juntos en una misma habitación para aumentar el jolgorio creativo. En fin, cada metodología, cada gurú, es completamente distinta a las otra. Y sin embargo todas ellas nos prometen un aumento de la productividad. ¿Cómo es esto posible?

El Efecto Hawthorne

Entre 1927 y 1932 se realizó un estudio en la Hawthorne Plant de la Western Electric Company en Cicero, Illinois. En este estudio se investigó el efecto que producían en la productividad los cambios ambientales introducidos por los investigadores. Los investigadores comprobaban que aumentando el nivel de intensidad luminosa en la planta, se aumentaba la productividad. La sorpresa fue cuando se disminuyo la intensidad luminosa y se comprobó que la productividad también aumentaba. Prácticamente se podía cambiar cualquier aspecto de la metodología de trabajo de la planta y la productividad aumentaba.

¿Cómo podía ser esto? La mayor conclusión de dicho estudio es que a los trabajadores les agradaba la atención recibida durante el estudio y se esforzaban por rendir más. Otra conclusión equivalente es que la novedad introducida por el nuevo sistema saca a los trabajadores de su letargo metodológico, que a la gente le gusta la novedad y le aburre hacer las cosas siempre igual.

A esto se le ha venido a denominar el Efecto Hawthorne.

¿No será este efecto lo que nos proporciona mejoras en todas y cada una de las nuevas metodologías? Esto parecería consistente con el resultado a largo plazo de estos sistemas, que son rápidamente olvidados y no parecen obtener tan buenos resultados cuando se convierten en la norma de trabajo.

El libro Peopleware, uno de los libros sobre gestión de proyectos más influyente en nuestro campo, ya nos advierte de este efecto y nos avisa de cómo podemos aprovecharlo a nuestro favor: Empresas como Fujitsu han convertido la novedad en norma y en todos sus proyectos introducen algún aspecto experimental para evitar el tedio de los trabajadores.

Estemos pues atentos a lo que cada sistema es capaz de aportar en nuestro trabajo diario, practiquemos un escepticismo creativo con dichos sistemas, aplicando aquello que realmente nos va a ayudar en nuestra tarea y dejando de lado las recetas milagrosas. Y no nos olvidemos de disfrutar en nuestro trabajo. El aburrimiento en el trabajo del programador es lo que realmente disminuye la productividad. Algunas pequeñas novedades introducidas en cada proyecto pueden hacer más por este que cualquier metodología existente.

Comentarios
1 Oscar
14 junio 2005, 07:48

No puedo estar más de acuerdo. Uno se siente motivado cuando esta haciendo algo novedoso, algo que sirva para futuras ocasiones, algo que nos rete y no caiga en la rutina.

Las metodologías son comos los entornos de programación: pueden ser bonitos, con muchas utilidades que nos facilitan el trabajo, pero al final el desarrollador siempre hace lo mismo, es decir, programar, y es esto lo que realmente se debe tener en cuenta para saber donde hay que motivarle.
2 Jose Ramón
14 junio 2005, 08:09

Me parece muy buena la conclusión de introducir situaciones novedosas en cada proyecto que animen a los desarrolladores.
Estas modificaciones metodológicas deberían paliar aquellos aspectos en los que se note que la metodología se ha vuelto más pesada y aburrida para la gente del proyecto.
Pero no hay que olvidar que la motivación se debe a muchos factores más que influyen. El experimento de Hawthorne realmente no es un símil de cambiar la metodología de desarrollo (puesto que seguían haciendo lo mismo de la misma manera), si no de cambiar los factores ambientales, y, sobre todo, del sentimiento de apoyo por parte de la dirección.
3 Sergio Montoro Ten
14 junio 2005, 15:47

En consultoría, existe otra metodología tan importante (si nó más) que la técnica.
Es la metodología de presentación de ofertas comerciales.

De poco sirve tener un procedimiento de desarrollo eficiente, ordenado y militar si el cliente te caza por todas partes con argumentos sobre cosas que deberían estar hachas.

¿Alguien ha visto alguna vez a un gerente de una gran consultora en acción?
Tienen un tema metodológico recurrente: el comercial nunca habla del proyecto o la metodología; sólo habla de la oferta, y de si esto o aquello estaba o no en la oferta.

Por otra parte, creo que la metodología técnica es tanto más importante cuanto menor es la capacitación de los recursos humanos empleados.
La metodología en un programador experimentado va más o menos incluída dentro de su cabeza; a un novato hay que proporcionársela desde fuera.
4 Juanjo Navarro
15 junio 2005, 10:53

Sergio, lo que ocurre es que en mi opinión las mejores formas de imbuir metodología a un novato es mediante la formación y el mentoring por parte de programadores experimentados.

Si a un novato le damos un tocho de 200 páginas y le decimos “esa es LA METODOLOGÍA, síguela al pie de la letra”, realmente no conseguimos que aprenda porque hace las cosas a ciegas. Además ni siquiera hará las cosas bien, porque cada proyecto es distinto y la idiosincrasia del actual seguro que no estaba prevista cuando se escribió el tocho.

Saludos.
5 elmaska
15 junio 2005, 19:04

Yo personalmente valoro mucho CUALQUIER metodología. No creo que el escepticismo deba venir del método sino de la aplicación del mismo. Cualquier método es bueno siempre que se utilice (añadiría la palabra bien) puesto que ese es el primer paso de un modelo de mejora evolutiva. Lo que desde luego no funciona es “intentar” implantar una metodología y cuando esta “falla” (e.d. no se produce el milagro) se pega un bandazo y se pasa a otro “remedio curativo”. Cuando una metodología no ha funcionado quizá el problema no es la receta sino los cocineros (y que conste que digo cocineros y no los pinches que bastante tienen con lo que tienen para que encima se les cargue la responsabilidad de no entender la receta). A mi entender las metodologías no se pueden adoptar como el que cambia de estilo de peinado, sino que requieren formación previa y contínua de los equipos, aporte de motivación por parte de los líderes (lo siento, uso esta palabra pero realmente no me gusta), recursos y sobre todo, una mentalización profunda de lo que se pretende conseguir cuando se adopta un método.

Respecto al efecto Hawkthorne, como han comentado algunos ya, no es una cuestión de cambio de metodología sino de las condiciones ambientales. Esto hila un poco con el tema de la motivación. Si a los equipos se les demuestra cierto grado de atención positiva, reaccionarán de forma positiva, pero eso es independiente de la metodolodía, al menos en el ámbito que aquí estamos discutiendo, puesto que existe un concepto amplio de metodología de desarrollo que a mi me gusta mencionar y es la gestión de equipos/proyectos en la cual si que se deben de tener en cuenta factores no ligados específicamente con el desarrollo informático (creo que ya he mencionado algunos más arriba).
6 Sergio Montoro Ten
21 junio 2005, 11:03

Respecto de #4 mi argumento era que es menos malo seguir una metodología a ciegas que no seguir ninguna en absoluto.

Pondré un ejemplo, el clásico código:

for (i=0; i
7 Sergio Montoro Ten
21 junio 2005, 11:05

Esto… creo que encontré un bug en el bicho este: si pones un angulito ampersand lt se te corta el mensaje.
8 Alberto Molpeceres
30 junio 2005, 19:19

No sé, dicho con cariño, Juanjo, últimamente se nota en tus post un poco de quemazón con la profesión, eh!! ;-).

Sobre el tema en cuestión. Para mi el problema principal de las metodologías es que no se tiene en cuenta a las personas. Simplemente alguién escoje y “intenta que se aplique”, sin tener en cuenta nada más. Quizás el éxito de todas estas metodologías simplemente viene de que ESE grupo de trabajo concreto se ha encontrado muy cómodo trabajando así (en grupo o solos, escribiendo UML o picando código sin pensar, de forma jerárquica o “caótica” porque todos eran “cracks”).

Gran parte del problema del software puede venir porque no se consiguen crear dinámicas de trabajo en grupo suficientemente buenas. Las rotación en los equipos (por razones que requerirían otro hilo) es demasiado grande, con lo que sólo nos queda el nmétodo de “la elección a dedo”, que a veces sale bien y otras no.

Simplemente mi opinión, tan buena y mala como cualquier otra.
9 Juanjo Navarro
1 julio 2005, 10:06

Alberto, ¿yo quemado? No, en serio, realmente no estoy quemado. Es solo que cuando uno pasa por un proceso de certificación ISO 9000 pierde la poca fe que pueda tener en las metodologías.

Sobre esto escribió Joel en su día, comparando las metodologías (en realidad las grandes consultoras, pero yo lo extrapolo) con un restaurante de comida rápida, donde todo se hace de acuerdo al libro de instrucciones, frente a un restaurante de comida de calidad donde las cosas las hace un buen chef, improvisando de acuerdo a la temporada y a las materias primas: Las Big Macs contra El Chef Desnudo
10 Alberto Molpeceres
3 julio 2005, 09:13

Bueno Juanjo, me alegro.

En fin, un poco de humor que resume el tema del gran Dilbert…

http://www.dilbert.com/comics/dilbert/archive/dilbert-20050702.html
11 TrickyDicky
3 julio 2005, 13:53

Una traducción de este artículo puede encontrarse en http://zenitservices.com/PlanetaCodigo/Jul2005/DrowningInMethodologies.html
12 david
8 julio 2005, 12:35

En mi opinion las metodologias se adoptan progresivamente. Cualquier intento de implanatar una metodologia de golpe resultara en una forma de proceder forzada, no repetible y por lo tanto poco representativa del rendimiento que un grupo pueda alcanzar usandola.

Por eso me parecen sospechoso hablar de “experimento” con una metodologia. Creo que mas que medir los efectos de adoptar la metodologia, lo que se mide al final son los efectos del experimento.

Como he dicho antes, creo que una metodologia se adopta progresivamente, añadiendo elementos poco a poco, permitiendo que se incorporen a la manera trabajar de las personas de forma natural. Solo con un periodo largo de adopcion (y no hablo de formacion, hablo de adopcion en la practica) se podra considerar que las personas trabajen segun la metodologia y se podra intentar medir los efectos de usarla. (Y digo intentar porque tras este tiempo sera dificil aislar los efectos de cualquiera de las multiples variables que hayan cambiado)
13 CONCEPCIÓN DE LA LUZ LÓPEZ ESCOBAR
23 febrero 2006, 03:35

ME PUEDES AUXILIAR SOBRE LA MEDICIÓN DEL PERSONAL DEL DEPARTAMENTO DE COCINA


Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.