Al Igual que en el mundo de la moda, en gestión, desarrollo o ingeniería del software nosotros también tenemos nuestras tendencias. Cómo no. Aunque nuestras modas no cambien tan rápidamente, y duren algunos años más, igualmente, cuando se impone una tendencia en el mundo del desarrollo software todos quieren seguirla y ser asociados con ella. Y si actualmente hay una moda en ingeniería del software es la de lo ágil. Se impone la fiebre ágil. Apuesta por lo ágil. El agile lifesytle.
Como sucedió con anteriores modas en ingeniería del software, cuando lo ágil apareció lo usaban sólo algunas personas, unos pocos, pero con los años se ha extendió a todas las áreas de la ingeniería del software. Nadie quiere decir que su área de trabajo o investigación no es ágil, eso sería no estar a la moda. Muchas veces simplemente se aplica la regla aquella que dice que una práctica de ingeniería software tradicional se vuelve a poner de moda si le añadimos un apellido de moda, como es hoy el “apellido” ágil, y así hoy podemos encontrar lo ágil prácticamente en cualquier área tradicional de la ingeniería del software, algunos ejemplos:
– Modelado Ágil de BBDD.
– Ágil MDD
– Ágil y CMMI
– Ágil e ISO 9000
– Ágil y software embebido
– Agile Testing y Pruebas ágiles
– Arquitectura ágil
– Estimación ágil
– Métricas ágiles
– Mantenimiento ágil
– Requisitos ágiles
– Gestión de riesgos ágil
– Gestión de configuración ágil
– Calidad software ágil
– Negocios ágiles
– …
– x + agile
En el pasado ya tuvimos otras modas. Aunque en la actualidad se vean más retro. Como en su día se llevaba lo “relacional”. O tiempo después se impuso lo “orientado a objetos», que también combinó con todo. La tendencia UML. U otras modas menores, más de complementos, como la moda de los patrones. Normalmente suele suceder así con toda buena práctica. Cuando aparece casi nadie la usa, para pasar a ser usada por todos en todos sitios, hasta incluso pasarse usándola (véanse los casos de estudio que narran como durante la moda de los patrones algunos proyectos quedaban bloqueados por el sobre exceso de patrones aplicados), para posteriormente saber usarse en su justa medida.
Y en este sentido es curioso recordar como en el pasado ya importantes autores hablaban de este efecto en ingeniería software. Como bien cuenta este antiguo, en tiempos famoso, párrafo de Meyer:
“My long search had not been in vain. It had led me to a full appreciation of the UML, this admirable self-feeding machine, devoted from A to Z to the creation of a new market, free of any of the difficulties associated with the unpleasant business of software development: UML books! UML courses! Courses on the books! Books on the courses! Books on the books! Introductory courses to prepare for the advanced courses! Courses for those who teach the courses! Revisions! UML journals! Conferences!” (Meyer, 1997)
—
NOTA DEL AUTOR PREVIA A LOS COMENTARIOS QUE PUEDA DESENCADENAR ESTE POST: Como el autor ha comentado en este blog en varias ocasiones, las prácticas ágiles le parecen muy buenas prácticas (hasta el punto de aplicarlas y recomendarlas en numerosos proyectos software), pero también cree, por su experiencia, que el ágil para todo, por defecto y siempre cuanto más mejor puede llegar a ser contraproducente en algunos proyectos y empresas. Antes de aplicar cualquier práctica (ágil o no) en una empresa hay que planificar minuciosamente su incorporación, estudiar su idoneidad en el proyecto concreto, su alineamiento con el negocio y con el equipo, y esto no es trivial
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Pingback: Bitacoras.com
Efectivamente, los que llevamos (para bien o para mal…) ya algunos añios en esto, no podemos estar más de acuerdo con el transfondo de este post.
Toda tendencia sigue la misma curva de la moda: los «adopters», esos visionarios que la ven primero y la adoptan rápidamente, los «seguidores» que, en masa, siguen esa moda como si fuera lo único que hay, como si nunca hubiera existida nada mejor antes y todo lo anterior fuera despreciable. Tras esta fase se produce la saturación y vienen los «detractores» que acaban con el ciclo de esa moda. Y eso es así en todas las disciplinas (ropa, complementos, cochs, ingenieria del software, et.) porque es algo inherente al ser humano.
En cualquier caso, como muy bien acaba diciendo (de otra forma) Javier, los fundamentalismos siempre son nocivos, malos. Antes de aplicar una metodología o técnica, hay que hacer un buen análisis de contexto y planificar y elegir bien cómo y con qué herramientas trabajar. Nunca una misma metodología, técnica o herramienta es bueno para todo… NO EXISTEN (y nunca existirán) LAS PANACEAS
Vaya por mi parte una pequeña aportación acerca de las metodologías ágiles. En primer lugar quiero dejar claro que yo me considero un gran admirador de las metodologías ágiles.
Pero hay que empezar diciendo una cosa que ha de quedar muy clara. Todo esto tiene truco, y es un truco muy similar al que se da por ejemplo en las instituciones de enseñanza de gran prestigio (se trata de un ejemplo un poco forzado) ¿Como funciona una institución de enseñanza de élite? Pues en muchos casos relativamente sencillo: atraen a buenos estudiantes, les dan pautas de trabajo de muy alto nivel, unos objetivos muy claros (y muy exigentes normalmente) y a partir de ahí todo depende del buen hacer de los señores estudiantes.
Las metodologías ágiles se basan en las misma filosofía. Reglas de trabajo sencillas, marcar objetivos muy claros y el resto se delega en el buen hacer de los desarrolladores. Tomemos el ejemplo de Scrum: Se ocupa de cosas como tratar de definir una lista de funcionalidades estimadas en esfuerzo y priorizadas (pila de producto). Desarrollo de las funcionalidades y planificación de las mismas (sprints y pilas de sprint). Seguimiento del desarrollo del proyecto (tableros kanban, reuniones diarias de 10 minutos, y diagramas de burndown). Y especificación de alto nivel de las funcionalidades (historias de usuario). Quizá como elemento más novedoso la reflexión sobre la calidad del trabajo realizado por el equipo y el establecimiento de pautas particulares de mejora (retrospectivas).
Y poco más, como mucho podemos complementarlo con XP (Extreme Programming) que da pautas bastante interesantes en el día a día del desarrollo de software (realización de tests automáticos, pair programming…). Pero comparado con las metodologías tradicionales se podría decir que las metodologías ágiles dejan un inmenso hueco que ha de cubrir el buen hacer de los profesionales implicados en el desarrollo.
La forma de trabajar de un equipo de desarrollo ágil tiene más en común con el trabajo en un taller de artesanos que con la forma de trabajo de una gran empresa de ingeniería tal como se enfoca en muchos casos actualmente (con excepciones, véase el caso de Toyota y filosofía Lean). De hecho muchos de los miembros de las comunidades de desarrollo ágil adoptan para sí mismos la denominación de artesanos del software. Hay de hecho un «ala radical» dentro del movimiento del software ágil que se denomina artesanía del software (software craftmanship) y que lleva aún más lejos los principios del software ágil. Compárese el manifiesto de Software Craftmanship aquí con el manifiesto ágil más conocido aquí.
Y todo esto como puede afectar a grandes organizaciones de de desarrollo de software. Pues esa es una pregunta con muchos matices. ¿Qué pasaría si el presidente de McDonalds hablara con Ferrán Adriá acerca de tratar de construir un negocio de franquicias de restaurantes tipo El Bulli? Puede que esta pregunta arranque alguna carcajada pero creo que es más profunda de lo que parece, hay muchos detalles. Y si por algo se caracteriza el mundo del desarrollo del software es porque los detalles importan y mucho.
Abdominazer Agile, Crecepelos Ágil… Qué estará por venir?
Bromas aparte, he de decir que como todo, lo ágil tiene sus interpretaciones y es necesario aplicar lo que mejor nos viene en cada caso. Yo mismo, para la gestión de mi equipo de trabajo aplico prácticas de SCRUM con Sprints, reuniones diarias, etc. Pero es cierto que el poner algo de moda y aplicarlo a todo sin tener las debidas consideraciones, puede llevar a malas prácticas que arrastramos desde hace años y que supongan la desaparición de dicha moda. Os dejo como ejemplo esta reflexión Lo que mató al Cascada puede matar al Ágil