archivo

Archivos diarios: febrero 26, 2012

Lo primero, como he repetido en diversas ocasiones, agilidad es actitud y eso es una capa o un filtro por encima de cualquier metodología, lo que permite que tengamos la posibilidad de aplicar principios ágiles o al menos seguir una mentalidad ágil en cualquier proyecto (tener la posibilidad no quiere decir que le demos la vuelta al proyecto como a un calcetín, las reglas del juego son las que son, pero aún así, incluso en los procesos más cerrados siempre habrá una rendija a través de la cual podamos aplicar un enfoque o actitud ágil).

Ahora bien, los principios ágiles se llevan bien con enfoques iterativos e incrementales, por eso su instrumentación en metodologías siguen este tipo de ciclo de vida. Sin embargo, la simple aplicación de la misma no quiere decir que el desarrollo sea ágil ya que lo único que hace es fragmentar el proyecto en diferentes entregas. Si el enfoque no es ágil, la aplicación del ciclo de vida iterativo incremental tampoco lo será.

He escuchado lo mismo en muchos proyectos y lo peor de todo es que muchos de los que preguntaban eso habían sido los que pidieron que se hiciera de esa forma o los que habían autorizado y, por tanto, dado validez, a otros que fueron los que realizaron dicha solicitud.

Al final, salvo que se tenga bien atado de dónde procedieron las especificaciones, la cuerda se romperá por el lado más débil, el del desarrollador.

Es importante que el área funcional sepa de su responsabilidad en el proyecto y que las decisiones que tomen impactarán en positivo o en negativo en el balance del mismo tanto a nivel de calidad como a nivel económico.

Por otro lado, el equipo de proyecto debe tener constancia por escrito y a ser posible, firmada, por parte del área usuaria de la petición de trabajo realizada, así como de sus especificaciones.