De lo primero que he visto en el libro de ingeniería del software ágil ha sido el manifiesto por el desarrollo ágil de software, donde estos son sus principios:
- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
- Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
- Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
- Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
- El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
- El software funcionando es la medida principal de progreso.
- Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
- La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
- La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
- A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Pero con los que no estoy de acuerdo con todos. Me explico:
Los puntos uno y tres son lógicos: es bueno que se entregue al cliente software. Y, además, rápido. De hecho es lo mejor para que se vea que el desarrollo avanza.
El punto dos, el de los requisitos es más peliagudo: los requisitos pueden cambiar, pero no la base principal del software, es decir, cierta funcionalidad puede variar, pero no se puede cambiar de aplicación de un momento para otro (y de eso hay mucho).
El equipo debe estar unido y motivado, pero eso se consigue de dos formas: o que el jefe de proyecto sea un buen jefe de proyecto (todavía no he conocido a ninguno), o tener equipos autogestionados sin jefe de proyecto (como en algunas metodologías ágiles). Quizás este sea el punto más complicado de cumplir.
Eso de que la comunicación “cara a cara” (punto seis) siempre es la mejor… disiento. Está bien para etapas tempranas, donde se está decidiendo el principio de la aplicación, las tecnologías, etc. Pero cuando ya ha pasado bastante tiempo de desarrollo, lo mejor es usar herramientas de comunicación, como el simple correo electrónico o pizarras compartidas. Y esto es porque así queda registrado todo lo que se comenta, mientras que con el “cara a cara” se pierde la mitad de la información.
Como dicen en el libro, el diseño de la aplicación es el propio código fuente (la construcción la hace el compilador, no el programador), por eso, como dice el punto siete, el software funcional es la mejor medida de avance.
Los últimos puntos también son algo lógico, pero también algo muy complicado de cumplir: la excelencia, es decir, tener a buenos desarrolladores, utilizar metodologías ágiles y, sobre todo, simplicidad.
Este manifiesto está bien, sobre todo para la época en que fue escrito, allá por 2001 (9 años en informática es una eternidad), cuando la Ingeniería del Software se tomaba como cualquier otra ingeniería siguiendo procesos tayloristas. Incluso hoy en día todavía seguimos esos procesos aún sabiendo que en la mayoría de los casos no funcionan (¿conocéis algún proyecto informático grande —por ejemplo de alguna administración pública— que haya terminado en plazos y sin salirse del presupuesto? Yo no.), por eso recomiendo seguir estos principios para el desarrollo de software aunque con algunas excepciones, pero no estas, sino las que vosotros hayáis deducido de vuestra experiencia.
.
