20.5 años de XP y Agile (2020)

Artículo original ↗ Discusión en Hacker News ↗

Agile y Extreme Programming (XP) se revisitan aquí a través de más de 20 años de práctica, con desarrolladores que contrastan los beneficios genuinos —desarrollo iterativo, pruebas automatizadas, refactorización y colaboración más estrecha— con el agotamiento de la programación en pareja obligatoria y el dogma rígido del proceso. Muchos sostienen que, aunque ideas centrales como los bucles cortos de retroalimentación y CI/CD se han vuelto corrientes y valiosas, el “Agile con A mayúscula” ha sido cooptado por la burocracia, las industrias de certificación y los rituales de gestión que añaden sobrecarga sin mejorar los resultados. La pregunta central es si los métodos ágiles siguen ayudando a los equipos a entregar mejor software hoy, o si las prácticas flexibles y adaptadas al contexto han sustituido en silencio a sus marcos de marca.

Programación en pareja y prácticas de XP

  • Muchos encontraron agotadora, invasiva o incompatible con su estilo de trabajo la programación en pareja a tiempo completo; algunos dijeron que dejarían el trabajo antes que hacerlo de forma continua.
  • Otros informaron de máxima productividad y aprendizaje durante la programación en pareja intensa, especialmente en modo “profesor/alumno” o cuando había buena química.
  • Varios señalaron que la programación en pareja funciona mejor con una buena cultura y uso voluntario; el XP impuesto se considera arrogante o dogmático.
  • Se elogia a XP por dar una guía concreta sobre lo que deben hacer los programadores (tests, refactorización, diseño incremental) en lugar de solo el proceso alrededor de la codificación.

Agile, Scrum y usos indebidos

  • Queja común: Scrum y Agile a menudo se aplican de forma dogmática, usando “lo estás haciendo mal” para desviar críticas.
  • Muchos describen “rituales” (dailies, revisiones, sprints) seguidos mecánicamente sin objetivos claros, colaboración ni adaptación.
  • La interpretación errónea de los sprints como plazos fijos conduce a reservar margen, estimaciones a la baja y una sensación de lentitud.
  • Algunos argumentan que Agile en sí es sólido, pero ha sido cooptado por la burocracia y la consultoría; otros dicen que siempre trató de vender servicios y controlar a los desarrolladores.
  • Algunos ven Kanban como mejor alineado con el trabajo impulsado por interrupciones.

Pruebas, TDD y cobertura

  • Las pruebas unitarias, la refactorización y el diseño consciente de las pruebas se consideran ampliamente grandes ganancias a largo plazo.
  • Otros sostienen que las pruebas unitarias requieren mucho mantenimiento, a menudo son redundantes y son menos valiosas que las pruebas de extremo a extremo.
  • Debate sobre la “cobertura del 100%”: algunos la ven como un extremismo perjudicial; otros señalan que los textos de XP dicen explícitamente que no todos los métodos necesitan una prueba, y se centran en la confianza.
  • Preocupa que diseñar para la testabilidad pueda introducir puertas traseras, problemas de rendimiento o que el código de pruebas se filtre a producción.

Evolución de prácticas y herramientas

  • Muchas prácticas antes consideradas “radicales” (CI, compilaciones/pruebas automatizadas, refactorización, diseño incremental, control de código fuente) ahora son corrientes, en parte atribuidas a la ola más amplia de agile/XP.
  • Otros responden que esto ya existía antes en entornos “waterfall” o pre-agile; Agile no lo inventó, pero puede haber ayudado a extenderlo.

Industria Agile y dinámicas organizativas

  • Fuerte crítica al “teatro ágil”: proliferación de roles (coaches, scrum masters, product owners) sin eliminar los impedimentos reales.
  • Los desarrolladores se sienten sobrecargados por ceremonias, trabajo administrativo y responsabilidad por retrasos fuera de su control.
  • Algunos ven el fracaso de Agile como político: la burocracia adaptó el lenguaje mientras socavaba los principios, dando lugar a “WaterScrumFall” e implementaciones rígidas y nada ágiles.