Navegápolis nos refiere un muy interesante artículo de Bruno Collet: Limitations of Agile Software Development.
En él se describen y analizan algunas limitaciones percibidas en los modelos ágiles de desarrollo:
- Equipo de estrellas.
- Encaje con la cultura organizacional.
- Tamaño del equipo.
- Ubicación física del equipo.
- No hay apoyo de procesos.
Obviamente está en inglés, largo pero de fácil lectura. Vale la pena el esfuerzo.
Mi personalísima opinión –bastante en sintonía con el autor del artículo- es que ninguna metodología en estado puro (“de libro”) es aplicable en la vida real sin ajustes, y que por sobre cualquier otro criterio debe primar el pragmatismo, sin olvidar la precaución (no seguir las modas o novedades), y el gradualismo (las revoluciones son muy emocionantes, pero…)
Es importante recordar que el objetivo del desarrollo es crear software, por lo que la metodología es un medio que debe estar en línea con ese objetivo, no un fin en sí mismo.
La situación actual es siempre un punto de partida. Cada problema tiene origen en alguna debilidad del proceso, que de alguna manera permitió su aparición. Sobre esto escribía en Parches y soluciones:
[…] puede pensarse en un parche y una solución para cada problema […] El parche es la actividad que resuelve la situación puntual, mientras que la solución es un cambio en la metodología de trabajo o en el circuito administrativo dentro del equipo que torna imposible la situación que originó el error.
Siempre se parte de una realidad existente, no importa si es el primer proyecto independiente de dos amigos/socios o un proyecto de mantenimiento en una gran corporación. Durante la marcha (o en algún momento de evaluación) surgen dificultades, cuellos de botella, errores, omisiones o indefiniciones.
Son éstos problemas e ineficiencias concretas, nuestros problemas y nuestras ineficiencias las que se deben corregir. Y para ello está disponible no sólo la experiencia volcada en las metodologías ágiles sino en cualquier otra, incluso de diferentes ámbitos o industrias.
En resumen:
- pragmatismo. trabajar sobre lo concreto: problemas concretos, soluciones concretas.
- experiencia: referirse siempre a la experiencia. A la nuestra o a la ajena, pero no reinventar la rueda. Puede que un producto sea original, novedoso y único, pero créanme: los problemas en el proceso que lleva al desarrollo de ese producto no lo son. Antes de ponerse creativos es mejor hacer una búsqueda en google.
1 comentario:
Andres, me ha gustado el post; especialmente por el enfoque final orientado a las soluciones y no a los problemas. Yo creo que como tu dices no hay soluciones mágicas, pero lamentablemente también existen sectores que se apoyan sobre un fanatismo un tanto inútil defendiendo una única verdad como la solución para todos los problemas.
Saludos
Publicar un comentario