archivo

Archivos diarios: mayo 18, 2011

Kent Beck realizó la siguiente cita: “El optimismo es un riesgo laboral de la programación; el feedback es el tratamiento”.

La utilización de metodologías orientadas a la predecibilidad, como por ejemplo, las metodologías de corte clásico, dan, por regla general, malos resultados, haciendo realidad las premisas que caracterizan a la crisis del software.

Predecibilidad y optimismo van de la mano, pero la realidad demuestra que las especificaciones iniciales de un proyecto cambian, en unos casos más, en otros menos y en otros te desmonta medio proyecto (y gracias).

La utilización de metodologías ágiles, basadas en soluciones iterativas e incrementales ofrecen la posibilidad de ir adaptando el proyecto a esos cambios, ya que en sus propios procedimientos está contemplado el hecho de que los sistemas que se desarrollan requieren de manera sistemática el feedback del área usuaria.

Hace unos días un compañero me enseño un portal web que había sacado una organización y que desde el tiempo en que empezaron a realizar el desarrollo hasta que lo pusieron en producción tardaron menos de 72 horas.

Cierto es que el sitio web era muy sencillo (aunque profesional), pero no se trata de que sea más complejo o no, sino de si una organización es lo suficientemente ágil para hacer algo así si la circunstancia lo demanda, es decir, si los procedimientos (y la capacidad del personal) ofrecen esta posibilidad.

Es importante tener procedimientos y una cultura de organización, siempre los he defendido, pero habría que plantearse la calidad de los mismos si realmente en caso de que haga falta, no son lo suficientemente ágiles para permitir desarrollos e implantaciones en tan corto espacio de tiempo (no necesariamente menos de 72 horas, pero sí en un tiempo reducido).

Agilidad y adaptación van cogidos de la mano. La primera surgió como consecuencia de la segunda con el objeto de dar una respuesta al problema de la crisis del software.

Se entiende la adaptación como el hecho de que el proyecto de desarrollo de software debe ir evolucionando conforme se va construyendo con el objetivo de que cada vez el producto se aproxime cada vez más a su finalidad verificando las expectativas del usuario. Esto se consigue ajustando el desarrollo al feedback del usuario y a las contingencias que han podido ocurrir.

Sin embargo la adaptación debe ir más allá de eso y llegar a cualquier aspecto del proyecto. Uno de ellos es la metodología, todas no sirven para todos los proyectos, incluso para casos similares lo mismo es la organización para la que se desarrolla la que hace que las circunstancias sean diferentes.

No es cuestión exclusivamente de cambiar de una metodología a otra, lo mismo puede bastar con hacer ajustes dentro de la misma. Si una metodología es rígida hay que pensar si realmente merece la pena ser aplicada, salvo que el cliente lo exija (y a tu empresa le convenga aceptarlo) y/o el proyecto sea tan especial que necesariamente se requiera trabajar de esa manera.