Estimación de software y metodologías ágiles (II)

Algunas consideraciones sobre las estimaciones y las metodologías ágiles


Estimación de software y metodologías ágiles (II)

En el anterior artículo de esta serie hablamos del ciclo de vida en cascada , de las dificultades de gestionar un proyecto utilizando esta metodología y los problemas iniciales que nos encontrábamos para estimar correctamente un proyecto atendiendo a parámetros como pueden ser los puntos de función .

Esbozamos un escenario bastante negativo al que nos enfrentamos con relativa frecuencia: gestionar una serie de requisitos, en su mayor parte difusos, preparar un plan de acción y presupuestarlo.

Para ello podemos utilizar una serie de métodos formales como CMMI , COCOMO o SPICE que nos definen todos los procesos necesarios no sólo para generar una estimación si no también para la propia gestión del proyecto una vez iniciado.

Aparte de su dificultad, el gran problema de estas metodologías es precisamente el tiempo necesario para obtener resultados concretos. En la mayor parte de las ocasiones, si siguiéramos todos los pasos precisos para finalizar el análisis del proyecto posiblemente acabaríamos consumiendo el tiempo total del proyecto o la paciencia del cliente (lo que ocurra antes).

Como respuesta a los métodos formales, en el año 2.001 se firma a propuesta de Kent Beck (el creador de Extreme Programming ) lo que se conoce como 'el manifiesto ágil '. A la firma se suman el propio Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.

El manifiesto completo se puede leer en esta dirección , pero lo que normalmente se resalta son estos párrafos:

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

  • A los individuos y su interacción, por encima de los procesos y las herramientas.
  • El software que funciona, por encima de la documentación exhaustiva.
  • La colaboración con el cliente, por encima de la negociación contractual.
  • La respuesta al cambio, por encima del seguimiento de un plan.

La llegada de las metodologías ágiles supuso una ruptura total con respecto a los procesos formales. Se empezaron a escuchar cosas como 'el análisis ha muerto ', Internet se pobló de fotos de programadores trabajando en la circunstancias más extrañas (la cima de una montaña, sobre una tabla de surf o durante un salto en paracaídas) para resaltar los conceptos de agilidad y la disputa entre métodos formales y ágiles se hizo cada vez más enconada (de hecho los ecos de esa batalla aún continúan).

En defensa de los métodos formales, Kent Beck reconoció años más tarde que la idea era hacerse oír, que continuaba siendo necesario un cierto trabajo de análisis pero que era importante que los programadores conociesen otros métodos de trabajo.

Hoy por hoy, las metodologías ágiles como XP o SCRUMM cuentan con una base de seguidores realmente considerable y se aplican en las empresas más variopintas, por otra parte, conceptos como pruebas unitarias, refactorización o prototipado han saltado de las metodologías ágiles a prácticamente todos los desarrollos.

No voy a extenderme sobre los conceptos de las metodologías ágiles , en la web podemos encontrar infinidad de artículos y tutoriales sobre el tema, nos centraremos en cómo acometen estas metodologías la estimación.

En primer lugar las metodologías ágiles son sobre todo metodologías de gestión de proyecto centradas en el desarrollo. Esto quiere decir que es el propio equipo de desarrollo junto con el cliente quien estudia los requisitos, las prioridades y el tiempo estimado para su desarrollo.

El ciclo de vida del proyecto se convierte así en un proceso iterativo, similar al ciclo de vida en espiral , que en períodos de tiempo muy cortos de entre una semana y un mes implementa y pone en producción una aplicación que el cliente puede utilizar inmediatamente.

Así, partiendo de una idea general de la aplicación se divide en módulos que se van implementando según las necesidades del cliente, no según criterios informáticos.

Por ejemplo, imaginemos una aplicación de gestión de una empresa de venta: lo más importante para el cliente es que se puedan realizar pedidos, así que el equipo de desarrollo decide que en su primera iteración (digamos, la primera semana), se va a crear una aplicación que permita introducir e imprimir un pedido. Aún no habrá gestión de productos, ni usuarios, ni clientes, será una aplicación muy simple con la que los usuarios pueden comenzar a trabajar.

Al comenzar la segunda iteración el equipo se reúne de nuevo para decidir cuales son las tareas más importantes y necesarias para el cliente que se pueden acometer durante esa semana. Puede decidir que lo más importante es el mantenimiento de productos o puede que considere imprescindible facturar los pedidos introducidos. Lo único importante es que sea prioritario para el cliente y que al final de la iteración el equipo de desarrollo asegure que va a existir una aplicación completa en producción.

Poco a poco, según pasen las iteraciones la aplicación irá creciendo, el equipo aprenderá cómo trabaja el cliente (es decir, su lenguage de dominio ) y éste tendrá siempre en producción una aplicación en uso y no una promesa. Además el equipo adquirirá confianza y experiencia que redundará en mejores estimaciones.

Por supuesto, no todo será un camino de rosas, habrá iteraciones en las que tengamos que utilizar parte del tiempo en solucionar deudas técnicas o errores pero a cambio tendremos una aplicación probada en el mejor entorno posible, es decir, en el usuario final.

La estimación, como hemos visto, se reduce a las estimaciones iniciales de la semana. Únicamente debemos saber si las metas que nos hemos impuesto para esa iteración son posibles, no hay una planificación a largo plazo con una miriada de requisitos si no una planificación reducida que podemos controlar sin apenas esfuerzo.

Al tener un ciclo de vida inicialmente corto, basado en las especificaciones reales del cliente y con un tiempo de espera mínimo entre el desarrollo y la puesta en producción, se reducen también los errores de definición existentes en el modelo en cascada donde los errores que se hayan introducido en el análisis puede que no se localicen hasta la fase de desarrollo cuando ya es demasiado tarde y tenemos poca capacidad de reacción. Además se reduce el peligro de parálisis por análisis producido cuando intentamos gestionar por completo los requisitos de la aplicación al principio del proceso.

La gestión del ciclo de vida del proyecto también se reduce. Podemos utilizar gráficos que nos indiquen el número de requisitos terminados con respecto al total o el número de errores aparecidos y solucionados que nos darán una idea general de donde estamos sin requerir excesivos esfuerzos.

La mayor dificultad de las estimaciones ágiles vienen precisamente por su falta de estimación. Al ser un proceso iterativo no se puede dar al cliente una estimación inicial fiable ni, por tanto, un presupuesto final. Normalmente este tipo de proyectos se gestionan con contratos de tiempo variable, en el que se fija un equipo de desarrollo y un tiempo de trabajo mínimo para una serie de requisitos o un número de iteraciones y se va ampliando el contrato según se obtienen resultados.

Páginas relacionadas