En un post reciente Tony 'Bulldozer' se pregunta si el paradigma ágil realmente es aplicable en sistemas complejos
En mi opinión, teóricamente si, pero es cierto que en la práctica la mayoría de los proyectos planteados iterativamente van perdiendo la coherencia y la vinculación entre requisitos / funcionalidades / artefactos / etc.
Creo que es un problema de base la generalización del mito que si hacemos un proyecto con "Scrum" o "Kanban" o lo que sea, no es necesario documentación técnica, ni especificaciones precisas, etc.
La cuestión es que si una vez realizadas 2 o 3 iteraciones la gestión se lleva al nivel de micro-tareas se pierde la visión global y poco a poco la supuesta ventaja de un sistema ágil deja de serlo.. ya que al perderse de vista la visión de conjunto el conocimiento se disgrega y cada desarrollador empieza a tomar decisiones arquitectónicas sobre la marcha y hasta se pierden las prácticas estándar de desarrollo
Esto tiene además el agravante de que en cada sprint no se incluyen tareas no funcionales para esta consolidación del diseño y la implementación , la típica respuesta al programador de "es que no hay horas" cuando reclama tiempo para arreglar algo, con lo que al final tenemos un sistema monolítico, mal diseñado y prematuramente en crisis.. ante lo cual se plantea si evolucionarlo o refactorizarlo
Hay que insistir en que un sistema ágil no es un sistema low cost, de hecho tiene que tener un nivel de calidad superior para ser ágil en la entrega y sostenible en el tiempo
Pero, fundamentalmente el problema está en que el mito del desarrollo ágil en el que la arquitectura se hace sola y el diseño se hace entre todos, la figura de la arquitectura y del arquitecto se obvia.
Si el sistema es complejo y/o lleva acumulada mucha inversión en tiempo y recursos, no es fácil su reencauzamiento, sobre todo porque el origen del problema no es técnico sino de tener la suficiente cultura y organización para la realización efectiva de proyectos.
Cuando la carencia de la arquitectura es patente y que el mito de la arquitectura emergente que surge sin una organización y una dedicación se desmorona, suele cometerse un nuevo error:
La misión consiste en contratar los servicios de un arquitecto, "el gurú", para lo cual se define una job description que más que un trabajo es una wish list.
El arquitecto debe hacer de interlocutor con usuarios, prospectar todas las tecnologías, definir y actualizar las arquitecturas, metodologías, realizar las auditorías de calidad y además formar a los desarrolladores y solucionar incidencias fantasma.
Vamos de mito en mito.. tan sólo por enumerar tus deseos no es suficiente para hacer que se hagan realidad.
Como comentaba en la entrada anterior, un arquitecto puede tener muchos roles, pero es una figura transversal que necesita del resto de la organización para poder realizar sus funciones.
No hay comentarios:
Publicar un comentario