Ágil: el mayor problema ideológico en TI

imagen

En 2001, un grupo de tecnólogos y programadores que compartieron teorías no triviales sobre cómo se debe gestionar el desarrollo de software se reunieron en la estación de esquí de Snowbird para escribir algunos de estos conceptos por escrito. Así nació el Manifiesto Ágil : un documento engañosamente simple diseñado para redefinir el dogma del desarrollo de software. El desarrollo de software de estilo ágil se ha convertido en un nuevo estándar en la organización del trabajo de los programadores en una organización. Empresas como Facebook , Amazon , Apple , Google y Netflix han desarrollado sus procesos de desarrollo interno de acuerdo con las disposiciones básicas de este manifiesto. Dada la magnitud de Agile y su resonancia pública entre los proponentes, es fácil ver que Agile es la más influyente de todas las interpretaciones formalizadas del desarrollo de software. Sin embargo, Agile es una ideología. El sistema normativo de valores y creencias, casi hasta el punto de absorberse en el negocio del desarrollo de software. Por lo tanto, la industria del software ofrece una oportunidad interesante para evaluar cómo los objetivos nominales de una determinada ideología son consistentes con su implementación en la práctica.

En esencia, Agile fue un motín contra el dominio corporativo en el desarrollo de software. Por primera vez, se reconoció que el desarrollo de software es un proceso complejo y a menudo misterioso que debe protegerse de la burocratización corporativa. Cambio, reinvención, flexibilidad, dinamismo: estos son los hilos rojos que pasan por el manifiesto Ágil. Probaron ser infinitamente atractivos: según un estudio global , aproximadamente el 97% de todas las organizaciones de una forma u otra practican los principios de Agile. Gracias a esta distribución generalizada, Agile ha logrado una nominalización total en la teoría de la gestión del desarrollo de software: hoy, el término "ágil" se refiere a la ideología, los métodos de trabajo e incluso los sistemas utilizados para desarrollar software en una organización moderna. Agile incluso se extiende más allá de los equipos de programadores y se practica cada vez más en otros equipos responsables de, por ejemplo, las finanzas o la gestión de recursos humanos. Ágil, interpretado como una teoría universal de gestión, ha demostrado ser extremadamente accesible y popular, a pesar de la escasez de evidencia empírica de su efectividad y utilidad.

Curiosamente, el manifiesto Agile no intenta articular ningún método de trabajo específico, reglas, procesos, sistemas o estructuras que ayuden a desarrollar software de estilo Agile. Esto no es sorprendente: después de todo, el manifiesto Ágil nunca afirmó tener una descripción detallada de cómo lograr los objetivos de este manifiesto. Un desenfoque tan claro no disminuyó la popularidad de Agile: de hecho, el rápido crecimiento de la demanda de métodos y herramientas Agile específicos condujo al surgimiento de una metaindustria basada en recursos Agile. Este interés estimuló la introducción de Agile, la penetración en nuevas industrias de la ideología de Agile y sus derivados. Las metodologías ágiles más claramente definidas (por ejemplo, Scrum y Kanban, es decir, descripciones detalladas de los procesos que deben seguirse para implementar los principios del manifiesto ágil) y plataformas de software especializadas específicamente diseñadas para apoyar el desarrollo ágil demostraron ser muy distintas. La compañía tecnológica australiana Atlassian vende una gama de productos diseñados para soportar procesos de desarrollo de software de estilo ágil; De particular interés son Confluence y Jira, que de hecho se han convertido en estándares de la industria. Para aquellos que no son cocinados en la comunidad tecnológica, estos productos parecen bastante misteriosos. Varios artículos explicativos aparecieron antes de que Atlassian apareciera en las listas NASDAQ inmediatamente después. Los artículos tenían la intención de explicar qué vende exactamente Atlassian y por qué la compañía ha logrado una capitalización de mercado tan alta.

Al igual que los productos de software Atlassian, el vocabulario que describe los procesos ágiles y los métodos de trabajo diario también se ha vuelto cada vez más impenetrable para los no iniciados. Los profesionales ágiles hablan sobre sprints, tableros Kanban, diagramas de tareas, velocidades, historias de usuarios, epopeyas y retrospectivas: el significado de todas estas palabras a menudo cambia según el contexto, y estos términos pueden estar afiliados a una o más metodologías ágiles claramente definidas. No es de extrañar que, a medida que la metodología Agile se vuelve más compleja, hay una creciente cohorte de consultores especialistas que ayudan a dar sentido a todo esto. Bain & Company tiene aproximadamente 1,000 profesionales ágiles a su disposición. Este es quizás el indicador más confiable que muestra cuán rentable se ha vuelto la industria de consultoría ágil. Sin embargo, si el manifiesto Ágil es tan simple como parece a primera vista, ¿por qué hay tantos consultores? ¿Qué tan tangiblemente afectan los servicios de alguno de ellos a la calidad y efectividad del trabajo en una empresa de tecnología típica?

A pesar del vocabulario, las herramientas especializadas y una gran cantidad de recursos disponibles para cualquier persona que quiera practicar el desarrollo de software de estilo ágil en su empresa, a menudo es difícil rastrear con qué precisión se implementa Agile en la práctica, es decir, coincide con el espíritu y la letra registrada por los autores en el manifiesto Ágil El manifiesto ágil se hace intencional e inevitablemente abstracto. Quizás esto condujo a una distorsión gradual de la metodología Agile y, como consecuencia, de toda la cultura de gestión en la industria del software como tal. Algo colosal se construyó sobre bases aparentemente simples, un mecanismo que decepcionó extremadamente a quienes sentaron las bases para su primera iteración. Además, debido a la larga popularidad de Agile, los especialistas que no tienen una calificación Agile formal comenzaron a perder la competencia frente a colegas que supuestamente están versados ​​profesionalmente en Agile. Muchos bonos de carrera esperan a aquellos que afirman comprender el dispositivo Agilr y saber cómo usarlo. Tal realidad estimula el conformismo y ahoga cualquier intento de dudar del dominio de Agile o de plantear una pregunta sobre su efectividad.

Andy Hunt, uno de los autores fundadores del manifiesto Agile, se queja de que debido a la formulación abstracta del Manifiesto original, han aparecido y difundido reglas interminables que se usan fuera de contexto y supuestamente forman la base del desarrollo de estilo Agile. Con el tiempo, tales reglas se codifican en forma de metodologías especializadas que deben seguirse sin pensar, mientras se olvidan las pautas originales del Manifiesto. En otras palabras, la ideología ágil ha resultado extremadamente difícil de estudiar, aprender y practicar. Por lo tanto, algunos personajes se basan en reglas o heurísticas rígidamente definidas que se pasan como Ágiles, y luego continúan reemplazando estas reglas (a menudo fuera de contexto) con prácticas Ágiles que son consistentes con los objetivos del Manifiesto. En la mayoría de las organizaciones, no se produce un refinamiento gradual del proceso de desarrollo; en cambio, los gerentes caen en error, creyendo que el proceso no permite cambios, rechazan la mejora paso a paso del producto y se esfuerzan por arrancar tres aspectos de los desarrolladores, operando en su mayoría con cánones tomados del techo y rígidamente arreglados. Las organizaciones que no obtienen ningún beneficio real de Agile (y hay muchas de ellas) naturalmente gravitan hacia el monitoreo de la implementación de un determinado proceso Agile, mientras ignoran los resultados más difusos pero más importantes del proceso, es decir, la entrega de software viable.

El apogeo de Scrum y Kanban es, en el mejor de los casos, un intento de formalizar y difundir la ideología ágil. En el peor de los casos, todas estas metodologías no son más que una burocracia adicional, que genera nuevas reglas y métricas irrazonables que los desarrolladores deben seguir. Todo esto se impone por razones que a menudo no están completamente respaldadas empíricamente. Los gerentes, consultores, desarrolladores e incluso organizaciones enteras mediocres prosperan en tales circunstancias: se hace más fácil enfocarse en las reglas nominales de ideología, y gradualmente resulta ser más prioritario que lograr objetivos reales. Básicamente, en la industria del desarrollo de software hay una manía con la medición de la "contribución" y el "retorno" de Agile a nivel de empleados individuales. Tal manía ha llevado a descuidar la ética ágil original, un cambio en las prioridades para recopilar estadísticas para cada empleado individual, mientras que de hecho es necesario mejorar gradualmente los procesos a nivel de toda la organización.

La mayor ironía de esta degeneración es que la filosofía ágil original fue diseñada para liberar al programador promedio de la tiranía de la microgestión y la supervisión burocrática innecesaria. En cambio, la esencia misma de esta ideología en su forma actual ya es difícil de reconocer para quienes la crearon. En términos más generales, el destino de Agile como metodología de software es un amargo ejemplo de cómo una ideología lacónica y abstracta se distorsiona y distorsiona gradualmente a medida que crece su influencia, y se hacen más y más intentos para ponerla en práctica.

Source: https://habr.com/ru/post/448668/


All Articles