Friday, January 2, 2009

Setenta balcones y ninguna estadística

Estoy deprimido. Me siento triste, desengañado, defraudado. Supongo que es lo lógico cuando uno se creía un tipo lindo, alto, atlético y carilindo y se encuentra con la imagen que el espejo devuelve. Pero, ahora que lo pienso, lo que me ocurre es peor: siento la desdicha de haberme sentido parte de un grupo (profesional, en este caso) superior a otro y comprobar con amargura que no es así.

Siempre creí que las ciencias blandas deberían copiar varias cosas de las ciencias 'duras' (me cuesta decir ciencias blandas y ciencias duras y no decir ciencias y pseudociencias o protociencias) y eliminar sus fallas más notorias: proposiciones no verificables, especulaciones que confunden plausibilidad con certeza, palabrerío confuso y poco definido, mucha hermenéutica y poca experimentación y cosas así. Y por supuesto, siempre creí que mi actividad en la informática me ponía más cerca de las ciencias duras (o ciencias, a secas, aunque yo sea un tecnólogo y no un científico).


Sigo convencido de lo que digo en la primera frase del párrafo de arriba, pero dudo mucho de la segunda, esa que me pone a mí del lado de los buenos.


Pienso que hay mucho valor en las metodologías ágiles. Pero últimamente he notado que nuestras discusiones tienden a parecerse a las discusiones de los ... ejem... científicos sociales: mucha elucubración sobre los resultados de determinadas prácticas, alguna que otra anécdota, pero ni una sola estadística.


Vi las encuestas de Scott Ambler. No están del todo mal, pero tienen unos cuantos problemas metodológicos que no permitirían considerarlas estudios concluyentes: el primero es que se anuncian desde su columna dedicada al desarrollo ágil o en las listas de desarrollo ágil (lo que habla de un sesgo en la elección de quienes responden).


Eso, sumado a que no se le pide a la gente que definan 'éxito', que expliquen la forma de medir la productividad ni la calidad, sumado al sesgo en la elección de quienes responden, no veo como se pueda pensar que se ha evitado razonablemente el sesgo de confirmación.


De hecho, la pregunta "como afectó la adopción de metodologías ágiles a la productividad/calidad/costos" deja mucho lugar para una variante del sesgo de autoservicio (perdón, no se me ocurre una traducción mejor) : las metodologías ágiles siempre pueden llevarse el crédito por lo bueno y ser inocentes por lo malo que puede ser atribuido a problemas del entorno. O incluso, podría ocurrir lo contrario, si los sentimientos de quien responden son negativos hacia el enfoque ágil. Creo que una mejor redacción sería "como resultó la productividad, medida en (X), de los grupos que aplicaban enfoques ágiles frente a los que no los aplicaban?" donde, por supuesto, hay que encontrar alguna manera cuantitativa de medir la (X).


Y por último, deja a librado al sano arbitrio de quienes responden decidir si están siguiendo prácticas ágiles. Resumiendo, la encuesta puede dar ideas intuitivas de hacia donde vamos, pero dista de ser concluyente. Y no encontré otra cosa.


Aún así, yo encuentro que en mis evaluaciones en abstracto y en las anécdotas que puedo recoger, las metodologías ágiles son un buen enfoque allí donde se pueden aplicar. El problema es que, pese a todo, no hay evidencia concluyente. O al menos, no la conozco. Si alguien la conoce, me alegraría el día.

5 comments:

AcP said...

"...siempre creí que mi actividad en la informática me ponía más cerca de las ciencias duras..."

No me quedó claro lo de "actividad en la informática"... y es gracioso, porque depende cómo entienda eso cambia un poco el artículo. Así que a preguntar, que se acaba el mundo:

¿Qué parte de la actividad? ¿Programar? ¿Para un proyecto? ¿Científico, comercial? ¿Optimizar algoritmos? ¿Gestionar? ¿Controlar?

Improbable said...

Programar, aunque lamentablemente ya lo hago poco, sin dudas es un aspecto de mi actividad que siempre he visto cercano a las ciencias ( a la matemática en particulr, dejemos de lado la discusión epistemológica más formal para ver si la podemos considerar ciencia )

Incluso la gestión puede beneficiarse de un poco de investigación operativa.

Y otro punto es cuando me veo involucrado en proyectos de análisis tecnológico de aplicaciones existentes, ahí los conceptos de investigación operativa y matemáticos ayudan : por ejemplo, los sistemas se modelan bastante bien utilizando teoría de colas (el uso de teoría de colas para analizar la performance de un sistema bien podría ser tema para un futuro post)

fav said...

Creo que hay otros sesgos más difíciles de sortear, más cercanos a los que encuentran los sociólogos. Por ejemplo ¿se pueden meter en la misma bolsa BASE-1, y los otros proyectos que menciona Cockburn, con proyectos XP bajo lean development y proyectos que siguen scrum a rajatabla? Conozco gente que se certificó con Schwaber o Sutherland y en la práctica utiliza una base de Scrum, algo de XP y, tal vez, un poco de RUP (sazonar con software dojos a gusto). Creo que todos utilizan algo de metodologías ágiles, si no metí la pata, pero se me ocurren difícilmente "comparables". Digo, podés usar ScrumWorks y no hacer Scrum y viceversa.
Por otro lado, está el tema de la escalabilidad, no es lo mismo un proyecto dentro de una software factory de IBM, EDS, etc. (con "cultura de la empresa", directivas, historia, etc.) que un proyecto ad hoc para implementar un software de uso interno.
Creo que McConnell va por un mejor camino. El objetivo es llevar adelante el proyecto lo mejor posible, evitando los problemas conocidos. Se da que las metodologías ágiles ayudan en muchos, pero puede que creen nuevos y/o sean contraproducentes en otros. Y, otra vez, depende de situaciones particulares.
Como dice Ian Gorton: «I suspect this approach works mainly because everyone prefers muffins and espresso to writing specifications».

Improbable said...

Fav, exactamente eso es lo que quería decir: el trabajo de determinación de las categorías (con criterios de demarcación bien establecidos) es un requisito. Que yo diga que porque estoy haciendo scrum soy exitoso no significa que sea exitoso, ni que este haciendo scrum ni que sea exitoso porque esté haciendo scrum.
Gracias por los links, desconocía la mayoría. Muy interesantes

fav said...

Habrás leído The Whole Enchilada, Flaccid Scrum y las referencias de Adopting The Whole Enchilada. Si no, creo que aportan otro grano de arena.