Archivo

Archivos diarios: diciembre 26, 2011

Quien piense que la simple aplicación de metodologías ágiles convierte a tu proyecto, a tu equipo, al resto de stakeholders o a ti mismo en ágil es un error porque ser ágil cuestión de actitud y no el resultado de aplicar una metodología.

La metodología es un instrumento, pero saber tocar en él las notas musicales no te hace un buen músico. Es cierto que con experiencia y práctica todo es posible, sin embargo, para ser realmente efectivo en algo tienes que creer en lo que haces y a ser posible entender sus fundamentos.

Aplicar metodologías ágiles sin entender su origen, sin entender por qué resulta más efectiva en la mayoría de los proyectos que otro tipo de metodologías, es andar a ciegas, independientemente del resultado de tus proyectos. Tan a ciegas como todos aquellos que nos formamos en el ámbito del desarrollo en cascada y pensábamos que no había nada más allá del horizonte.

Un claro síntoma de que un código ha sido desarrollado por personal que todavía necesita más experiencia y cualificación es la existencia de clases que concentran gran parte de funcionalidad del sistema, de manera que el sistema pivota alrededor de las mismas (generalmente una de ellas).

Estas clases presentarán como mínimo una baja cohesión, tendrán una complejidad ciclomática superior a la media del resto de clases y probablemente mostrarán también un alto acoplamiento.

Las metodologías ágiles no tienen como objetivo obtener un producto software que satisfaga las expectativas del usuario mediante un procedimiento continuo de prueba y error.

Iterar no es eso, iterar es la intención de acercarnos cada vez más a una solución mediante el desarrollo de funcionalidades seleccionadas, definidas y ejecutadas con sentido y que si no terminan, una vez implementadas, de cumplir las previsiones que se tenían sobre ella, se tratan de mejorar (o incluso cambiar completamente) en la próxima o próximas evoluciones del producto a través del feedback del usuario.

Por tanto, no es disparar a ciegas, sino pensando bien qué es lo que se quiere hacer. De lo contrario, el esfuerzo necesario para desarrollar el producto sería excesivo en relación al presupuesto y recursos con los que probablemente contemos.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.196 seguidores