En el mundo de la ingeniería cuando llevamos a cabo un proyecto es fundamental desarrollarlo mediante una metodología de trabajo que nos permita controlar en todo momento su grado de avance, desviaciones en el coste previsto. En los proyectos más tradicionales se han venido utilizando multitud de metodologías diferentes durante el último siglo, pero con un común denominador, pertenecen a las llamadas metodologías en cascada. Las metodologías en cascada ejecutan el proyecto de un modo estrictamente lineal definiendo los siguientes pasos: Idea, Análisis, Diseño, Desarrollo y Test, hasta la obtención del producto final. Desgraciadamente las particularidades del desarrollo de software no las hacen las más adecuadas para este mundo. Un proyecto de SoftWare desarrollado con una metodología en cascada puede acabar en un…:
“Hiciste lo que te pedí…., pero no lo que quería”
Ya desde la década de los 50 empezaron a proliferar metodologías de trabajo con una filosofía diferente, el avance iterativo. En el 2001, una serie de profesionales reconocidos del mundillo intentaron poner un poco de orden en todo esto mediante la publicación del “Manifiesto Ágil”, un breve documento en el que se recogían las características que tienen que tener una metodología de trabajo para ser Ágil. ¿Cuáles son estos puntos?- Las PERSONAS son más importantes que los PROCESOS: Son las personas las que ejecutan un proyecto. Un procedimiento excesivamente documentado no conseguirá un producto de calidad si no lo ejecutan las personas adecuadas.
- El SOFTWARE FUNCIONAL es más importante que la DOCUMENTACIÓN: Debemos enfocar la mayor parte de los recursos en trabajos que aporten valor añadido al producto, y esto es un software que funciona y no un exceso de documentación sobre un producto inacabado o no funcional.
- La COLABORACIÓN CON EL CLIENTE es más importante que el CONTRATO: Quizá éste sea el punto más difícil de implementar. El objetivo es la satisfacción del cliente y ésta no se puede conseguir sin involucrarlo de lleno en la ejecución del proyecto y haciéndole partícipe de las decisiones. Un contrato flexible y negociado durante el desarrollo traerá muchos beneficios al resultado final.
- La RESPUESTA AL CAMBIO es más importante que la PLANIFICACIÓN: Los proyectos de software tienen una característica fundamental que los diferencia de un proyecto de, por ejemplo, obra civil y es el ecosistema cambiante y en constante evolución en el que se mueven. Una planificación exhaustiva al inicio del proyecto no tiene sentido desde la certeza de que las herramientas con las que programo, los dispositivos en los que se ejecutará el resultado y lo más probable, que los requisitos del propio cliente, cambien durante la ejecución del proyecto. Un equipo preparado para el cambio es lo ideal frente a una planificación que a ciencia cierta no se cumplirá desde la segunda semana.
- El ambiente de trabajo cobra una importancia vital. ¿Os suena lo de unos párrafos más arriba de que las personas son lo más importante? Los equipos tienen que ser colaborativos y en cierto modo autogestionados. Para ello, tienen que estar motivados.
- Hay que introducir un sistema de reconocimiento de méritos y tratar los errores como un punto positivo (no asociados a un castigo), una oportunidad para mejorar de cara al siguiente proyecto.
- Es necesaria una interacción entre el equipo de desarrollo y las áreas de negocio. La mejor manera de involucrar a un equipo en un proyecto y que se responsabilice de sus éxitos y sus fracasos es que forme parte de él, lo entienda y esté en contacto directo con el cliente, que es el que marca los requisitos. Entender por qué son éstos y no otros puede ser muy beneficios.
