archivo

Archivos diarios: julio 1, 2011

Un amigo me comentó hace poco que efectivamente los principios y metodologías ágiles establecen un marco de trabajo y un proceso de ingeniería del software que sientan unas bases para la entrega de un software de calidad, entendiéndose en este caso como la consecución de un producto que satisfaga las necesidades y expectativas del usuario, pero que tenía serias de que pudiese solucionar el ajuste al presupuesto (sobre todo) y plan de proyecto establecido.

Los principios y metodologías ágiles como bien indicaba mi amigo son instrumentos y los mismos por sí solo no garantizan nada. Es lógico pensar que con las mejores herramientas se trabaja mejor y se pueden obtener mejores resultados de una manera más eficiente. Sin embargo, lo que se obtiene al final es el resultado de la aplicación de las mismas por personas (ya pertenezcan al equipo de desarrollo, al área usuaria o a los responsables técnicos del cliente) en un proyecto concreto. Si las personas fallan, los instrumentos no pueden solucionar por sí solo nada, tal vez pueden hacer que el estropicio sea menor, pero poco más.

Por ese motivo en el desarrollo de software lo más importante son las personas, todo lo demás puede ser más o menos importante, pero viene después.

Partiendo de esa base, la aplicación de estrategias ágiles ni garantiza nada, ni produce milagros.

Si un proyecto tiene un presupuesto y/o plazos que no se ajustan a la realidad del objeto del trabajo y/o de las expectativas del usuario da igual que el equipo de proyecto sea el mejor, que estén motivados y que la metodología sea la más apropiada al proyecto, ya que lo más probable es que no se consigan los resultados que se esperan a nivel de calidad, presupuesto o plazos.

Los que nos dedicamos al desarrollo de software no estamos para hacer milagros sino que estamos para intentar hacer nuestra labor de la mejor manera posible y para ello se requiere un equilibrio entre lo que se pide, se espera, se tarda y lo que cuesta.

Lo anterior es complejo, sobre todo porque la estimación de esfuerzo a alto nivel de un proyecto (no de tareas concretas) puede fallar y a partir de ahí, lo más probable es que fallen también los plazos.

Para estimar un proyecto que se va a desarrollar siguiendo estrategias ágiles soy de la opinión que hay valorar el proyecto en primer lugar sin tener en cuenta el feedback del usuario en cada iteración y sobre esa estimación inicial aplicar un factor de ajuste, teniendo en cuenta la complejidad funcional y técnica del proyecto, así como las características de los usuarios que van a intervenir.

Por tanto, aplicando ese método el coste que debe salir será superior que el de si se realizase el cálculo teniendo en cuenta una metodología en clásica o en cascada, ya que mientras en esta segunda los costes de mantenimiento se aplican después, en las metodologías ágiles se pueden realizar mantenimientos desde la primera entrega, por lo que hay que tenerlos en cuenta en el propio coste del proyecto.

Con respecto a los plazos es importante conocer las expectativas del usuario en ese sentido y desde el primer momento darle a conocer lo factible o no que resultan sus deseos y que la estrategia a seguir será establecer una priorización de sus requisitos, para que cuando la fecha límite llegue, se tenga construido lo más importante.

Como decía al principio, todo esto son ideas, consideraciones, herramientas y estrategias, que como fundamento teórico para la realización de un proyecto pueden estar bien (o no estar de acuerdo con ellas), sin embargo, al final, lo realmente decisivo son las personas.