Manifiesto ágil, un buen punto de partida

Principios del Manifiesto Ágil

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5. 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.
6. 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.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Mi historia

¿Sentido común?
Pues no parece tan común. La experiencia me ha enseñado que estos puntos son poco considerados por los directores de empresas, los gestores de informática y los informáticos.

Yo me encontré con estos principios cuando se hicieron comentarios poco positivos sobre la metodología que estuvimos utilizando durante 8 años.
Al principio, la resistencia fue de los informáticos. Tras 8 años de orgullo y satisfación del trabajo bien hecho, vinieron otros informáticos con la misma resistencia del principio.

Observaciones relevantes.

1. Todos los usuarios tenían un grado de satisfacción con el proyecto extraordinario
2. Las viejas dudas resucitadas tras varios años de éxito, fueron realizadas por informáticos sin experiencia en construir sistemas.
3. La valoración del proyecto y el departamento cuando me pusieron a cargo del mismo, era muy mala.

Curiosamente, al mismo tiempo que se pusieron peros, se hizo una encuesta de 360 grados sobre todos los departamentos de la empresa.

Me informaron de la sorprendente ("escandalosa" fue el término exacto) valoración de nuestro departamento por su elevadísima puntuación.

No puedo culpar mucho a otros compañeros informáticos por no ser capaces de valorar una forma diferente de hacer las cosas, a las ortodoxas de los libros. De hecho, ese era el argumento más repetido, "lo dicen los libros".

Y lo entiendo porque yo estudié con esos libros, y tuve que desaprender unas cuantas cosas.

Saqué matrícula de honor en una asignatura con un título parecido a… desarrollo, configuración y mantenimiento de sistemas informáticos.
Esta asignatura tenía un enorme libro llamado Análisis y diseño detallado de aplicaciones informáticas de gestión
Este libro contaba los secretos de la organización

• Metodologías, valoración, control de calidad, etc…, etc… de sistemas informáticos.
• Un libro y asignatura demasiado ambiciosos.
• Desarrollo en cascada, en espiral, incremental, orientado a objetos, remolino, pinball…
• Metodologías MERISE, SSADM, MÉTRICA…
• Planificación de proyectos, GRANT, PERT, costes, plazos…
• Análisis, toma de requisitos, descomposición funcional, entidad/relación…
• MÉTRICA 2.1 (uffff)
• Valoración estimación esfuerzo con SLIM, COCOMO (ufff)
• Pruebas, calidad, verificación, gestión configuración, mantenimiento, herramientas CASE
• …

Sí, por aquel entonces estaba muy de moda hablar de herramientas CASE y como cambiarían en el futuro el desarrollo del software. Ya nadie recuerda el CASE

Cuando me tocó liderar el equipo y el proyecto, busqué mis libros, los repasé y empecé a pensar un plan para organizarnos y trabajar.

No me llevó mucho tiempo decidir que de todo aquello, tan sólo utilizaría algunas cuestiones puntuales. Si quería utilizar más, la consecuencia sería que antes de conseguir algo, terminaríamos con la paciencia que quedaba a alguno (realmente a uno, mi jefe, un gran tipo y enorme jefe y líder, nada fácil de encontrar un espécimen semejante).

Un poco de esto, un poco de aquello y el resto... a pensar, a buscar entre el sentido común.

Y el resultado fue proponer unos principios de trabajo muy semejantes al manifiesto ágil (sin conocerlos, de hecho en aquella época no habían sido redactados).

Cualquier cosa que planteásemos, debía ser compatible con dichas ideas.

Tuve un año y medio de durísimo trabajo y luego... todo era tan fácil, todo funcionaba solo, todo funcionaba fenomenal, los usuarios/clientes encantados, mis compañeros, encantados y orgullosos. El paraíso.

Mis compañeros, a pesar de las dudas y algo de resistencia inicial, pasaron a ser más eficaces que yo en esto y en el diseño distribuido.

Antes de que me diera tiempo a pensar cómo debíamos hacer algo, mis compañeros me daban la respuesta que yo buscaba. Eso fue una grata sorpresa. No es que nos entendiéramos, no es que el modelo poco ortodoxo triunfó, no es que mis compañeros lo entendieran, es que ya era su modelo y eran más eficaces que yo (¿qué más se podía pedir?).

Así que cuando vinieron auditores y nuevos informáticos a revisar todo en la empresa, y estos dijeron "no es lo que ponen los libros..." los entendí muy bien.

Yo estudié con los mismos libros. Yo me creí las mismas cosas.

No podía concebir que algo tan bueno, tan eficaz, con tanto sentido común y con lo que alcanzamos tanto éxito, no existiera ya. Así que busqué en internet y encontré el manifiesto ágil y las metodologías ágiles.

Encontré incluso libros. Me documenté todo lo que pude, con internet y libros, para poder explicar que sí hay libros que apoyan nuestro sistema y tener argumentos elegantes para defenderlo.

"no es lo que dicen los libros" ya era fácil de contrarrestar, pero explicar el modelo... tiene otras dificultades (aunque dejo este punto para desarrollar otro día, matizo que la mayor dificultad no es intrínseca al modelo concreto).

En otro momento hablaré de otras cuestiones relacionadas con esta historia, como "el papel o el powerpoint todo lo soporta", o la "disonancia cognitiva", o "si funciona, pa que lo tocas", o "pregúntale a los usuarios/clientes" cuando quieras saber si un proceso informático está siendo efectivo y otros puntos del manifiesto ágil.