archivo

Archivos diarios: noviembre 13, 2011

La incertidumbre inherente a los proyectos de desarrollo de software requiere que el proceso de desarrollo pueda responder de manera ágil y flexible ante ella. De lo contrario estamos abocados a desarrollos que no se adaptarán a las expectativas del usuario o que para acercarse a las mismas requieran un sobrecoste importante, así como un incumplimiento de los plazos.

¿Qué estoy exagerando? Hace poco os puse los datos publicados por el Cutter Consortium, en el que quedaba patente que la crisis del software sigue sin superarse.

Barry Boehm, uno de los mayores expertos a nivel mundial en estimación de costes software y en la aplicación de estrategias de gestión económica en los proyectos de desarrollo de software, lo manifiesta de manera patente en la siguiente reflexión (traducción libre): “Será importante tener en cuenta a la hora de organizar proyectos en el futuro contar con la agilidad suficiente como para ser capaz de adaptarse a la aparición de nuevas fuentes adicionales de cambios imprevisibles”.

Cuando se va a afrontar un proyecto de desarrollo de software es necesario realizar una estimación del coste necesario para su desarrollo basándonos para ello en el alcance conocido del proyecto y de todas aquellas variables que podamos anticipar (tipo de cliente, tipo de usuarios, experiencia en otros trabajos anteriores con ese cliente, con esos usuarios, con esa tecnología, con ese tipo de proceso de negocio, la metodología a aplicar, los umbrales de calidad esperados, etc…).

Cuantos más datos conozcamos mejor, pero en la mayoría de los casos estaremos lejos de saber lo suficiente como para que la incertidumbre entre lo estimado y lo real sea residual.

En cualquier caso es necesario estimar (y analizar riesgos) porque te determina un marco y lo mismo se determina que lo más recomendable es no seguir con el proyecto. Pocos proyectos conozco, aunque los hay, donde el dinero no es un problema.

Ahora bien, la estimación debe tener en cuenta un aspecto esencial y es que conforme vayamos avanzando en el proceso de desarrollo se tendrán que ir realizando ajustes sobre el producto, fruto del feedback del usuario y sobre el alcance final, de ahí la necesidad de priorizar los requisitos del usuario, ya que de quedarnos sin presupuesto, lo más importante debe estar desarrollado y ajustado a las expectativas del usuario.

Otro aspecto a valorar es que además de esa estimación inicial, lo más razonable es realizar estimaciones parciales sobre cada incremento del software (enfocándolo a un esquema iterativo incremental) y cada una de esas valoraciones será cada vez más exacta, ya que el conocimiento del sistema y su contexto será cada vez mayor, además de definirse entregas con un tamaño moderado para adaptarse a unos ciclos de evolución del sistema cortos (un mes, dos meses, etc…).

Todo lo comentado en este artículo lo resume perfectamente Jim Highsmith en la siguiente reflexión: “Convertirse en ágil significa aceptar la incertidumbre sobre el futuro como una forma de tratar con el futuro. Cualquier esfuerzo de un proyecto de desarrollo debería ser el resultado de un equilibrio entre la anticipación (planificación sobre la base de lo que sabemos ahora) y adaptación (en respuesta a lo que aprendemos con el tiempo)”.

Pocas reflexiones pueden describir mejor en pocas palabras la realidad evolutiva del software que la realizó Jeff Sutherland, creador junto a Ken Schwaber de la metodología Scrum: “Los usuarios no saben lo que quieren hasta que lo ven y siempre se reservan el derecho a cambiar de opinión”.

Es cierto que hay técnicas que ayudan a afinar en los requisitos, como son los prototipos, pero por muy bien que estén hechos, hasta que no lo utilizan (voy más allá del hecho de que lo vean) no terminan de dar las indicaciones necesarias para que el producto satisfaga sus expectativas.

Esto nos lleva a un enfoque iterativo incremental en el desarrollo de software, como modelo de referencia para ajustarnos a esta realidad.