José María Celemín, EFRONJosé María Celemín, Ingeniero de Software de Efron Consulting

Las metodologías de desarrollo software han ido evolucionando para adaptarse mejor a las necesidades de los clientes. El método en cascada, más rígido y secuencial, ha ido dejando paso, desde mediados de la década de los 90 del pasado siglo, a modelos más cíclicos y colaborativos, involucrando en el diseño a equipos multidisciplinares en los que tienen cabida tanto técnicos como usuarios finales.

Uno de los grandes retos de las metodologías ágiles es involucrar y hacer partícipes a los propios usuarios finales en las etapas de diseño. De la implicación que estos tengan dependerá en gran medida, el éxito o el fracaso del propio proyecto.

Esta implicación requiere un mayor esfuerzo pero, por otro lado, supone acercar más las expectativas de los usuarios al resultado final. Además, aumenta la aceptación por parte de los clientes al haber participado activamente en el diseño.

Las metodologías ágiles proponen sustituir el modelo secuencial de: Análisis – Diseño – Desarrollo – Pruebas – Implantación, por sucesivas iteraciones en las que estas etapas se repiten una y otra vez.

Al inicio se contempla una etapa de análisis preliminar donde se identifican los requisitos de alto nivel. Esta etapa da como resultado una documentación y unos alcances que se irán revisando en cada iteración.

A la hora de planificar, un parámetro a tener en cuenta en estas metodologías es el tiempo de duración de la iteración. La duración recomendada suele ser de 30 días pero esta dependerá de la conveniencia del proyecto y de la cantidad de requerimientos a incluir. También es importante mantener una regularidad evitando por ejemplo que unas veces las iteraciones duren dos meses y otras 15 días.

Por hacer una analogía, el modelo secuencial (waterfall) de desarrollo de software, puede asemejarse al proceso de construcción de una casa, donde el comprador posee un terreno y pide al arquitecto que le realice un diseño, en base a unas especificaciones concretas. Al cabo de un tiempo el arquitecto presenta un diseño en unos planos, o incluso una maqueta 3D del proyecto. Comprador y arquitecto acuerdan construir la casa y al cabo de seis meses se le entregan las llaves. Puede ser que la casa se ajuste a las expectativas del comprador con lo cual habríamos cerrado el proceso.

Pero, ¿qué pasa si el resultado final no se parece o difiere a la idea que el comprador se había hecho?  Esta forma de trabajar no nos dejaría mucho margen de maniobra puesto que el coste de realizar cambios, una vez finalizada la estructura, es enorme.

Las metodologías ágiles proponen una forma de trabajar incremental y colaborativa que se puede asemejar a la de una persona que decide encargar un retrato a un pintor. Pintor y cliente hablan de cuál ha de ser escenario, la postura, el atuendo, etc… El cliente acude frecuentemente al taller del pintor para posar y ver la evolución del retrato, el pintor va dando pinceladas al lienzo, algunas no son del agrado del cliente, por lo que tiene que ir rectificando hasta conseguir que el retrato sea de su gusto.

Este ejemplo nos ofrece una idea de lo que las metodologías ágiles proponen: tratar de aproximarnos con el menor riesgo posible a un resultado final satisfactorio y paliar la incertidumbre que generan los continuos cambios. Las organizaciones deben de adaptarse a los cambios que no son tenidos en cuenta en los análisis iniciales; puede parecer un proceso artesanal o de aproximación, pero el porcentaje de fracasos disminuye considerablemente con la implantación de estas metodologías.

Por otro lado, si bien es cierto que el manifiesto ágil aboga por huir de documentos largos y superfluos, también deja claro que la documentación debe de ser clara y concisa. En ningún caso la documentación es un paso opcional o prescindible. Hay que documentar de manera ágil, pero, a fin de cuentas, documentar.

No existe una metodología definitiva a la hora de llevar a cabo un proyecto. En función de la empresa, del cliente o del tipo de proyecto, será más conveniente utilizar una u otra. Además, debemos tener muy claro el esfuerzo inicial que supone, tanto por parte de la empresa como por el equipo y el cliente, acometerla con éxito.