Traducido por Jorge Ferrer
Revisado por Miguel Figueroa-Calix

Una de las frustraciones en el campo del desarrollo de software es la dificultad para elegir entre diferentes técnicas y herramientas. Es habitual que cuando alguien propone alguna técnica o herramienta se le pidan 'datos objetivos' de que su propuesta es mejor que las alternativas. Esta es una petición que puede entenderse, pero que al final está abocada a no tener respuesta. Para empezar porque no podemos medir la productividad (ver CannotMeasureProductivity).

Así que ante la carencia de 'datos objetivos' habitualmente empleamos evidencias anecdóticas. De hecho mi carrera tiene como objetivo difundir ideas basadas en el análisis de evidencias anecdóticas. A pesar de su inferioridad con respecto a los fenómenos medidos objetivamente no es muy sabio ignorarlas. Después de todo, ¿de qué otra manera podemos aprender? Es cierto que aprendemos mucho de nuestras propias experiencias, pero cuando otros nos cuentan las suyas también nos proporcionan mucha información.

Esta es la razón por la que me entusiasma ver que la gente informa de sus experiencias, incluso si son particulares y no están basadas en medidas exactas. En estos casos, los lectores entienden estas limitaciones y se quedarán con aquellas lecciones que puedan aplicar en sus propias circunstancias.

Si en un proyecto se están haciendo iteraciones cortas, se usan historias de usuario y medimos nuestra velocidad, eso significa que somos ágiles y tenemos el éxito asegurado ¿verdad?

La respuesta es NO

Más o menos, con esta reflexión comienza Allistair Cockburn su artículo Are iteration hazardous to your project. En él analiza como la tendencia a hacer las iteraciones más y más cortas puede llegar a ser perjudicial si se olvida que el objetivo final es proporcionar valor al cliente en cada una de ellas.

Me ha parecido una artículo muy interesante, sobre todo ahora que los procesos ágiles son más y más conocidos y corremos el riesgo de creernos que por usar varios o muchos de sus conceptos (pero ignorando sus principios) los proyectos van a tener más éxito.

Este artículo es bastante antiguo, del 2004, pero me ha parecido interesante publicarlo, aunque muchos ya lo conocereis.
En él Jim Highsmith responde a las objeciones a los métodos ágiles de un grupo de ejecutivos de grandes multinacionales.

Junto con el anuncio de la liberación de uno de sus últimos productos, Microsoft en boca de David Treadwell ha explicado que están promoviendo el uso interno de SCRUM y de ciertas prácticas de XP como la programación por parejas. Esta es la forma elegida por varios de sus equipos de desarrollo para lograr entregar software de calidad a tiempo y en sintonía con los requisitos de los usuarios.

Lo cierto es que otras grandes empresas están introduciendo métodos ágiles entre sus prácticas de desarrollo. Google incluye conocimiento de las mismas como deseable para los que soliciten trabajo en ella. Por otro lado en un reciente congreso de SCRUM (SCRUM Gathering 2005) Pete Deemer explicaba la introducción de SCRUM en Yahoo (resumen del evento). En este mismo resumen se menciona a otras empresas como Sun, Siemens, State Farm, IBM y Federal Reserve Bank.

Esta tendencia puede animar a empresas más pequeñas a introducir SCRUM o XP entre sus prácticas de desarrollo, pero esperemos que no lo hagan como una moda. Es necesario conocer bien estas metodologías para decidir si son las más apropiadas p