Principios detrás del Manifiesto Lento
Seguimos estos principios:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega de software sin fallos, incluso si tarda más. La prisa es enemiga de la confianza — un sistema que no se rompe vale más que diez lanzamientos llenos de parches. Si el plazo se aprieta, elimina el plazo, no la calidad.
Los cambios en los requisitos deben evaluarse con cuidado, incluso cuando surgen tarde. Los procesos lentos prefieren la estabilidad a la reactividad, buscando previsibilidad tanto para el cliente como para el equipo. Y si el cambio es realmente solo “cambiar el color del botón”, deja que el cliente lo elija en el sistema.
Entregar software funcional en ciclos largos y bien planificados, de unos meses a un año, con preferencia por la escala temporal que permita calidad. Quien entrega demasiado rápido suele entregar demasiado mal.
La gente de negocio y los desarrolladores deben trabajar de forma asíncrona y documentada, evitando reuniones constantes que disipan el foco y alargan los plazos. Si se puede resolver por email, no programes una reunión. Si se puede resolver por documento, no envíes email. Si se puede resolver con café, manda café.
Construye proyectos en torno a equipos estables y procesos bien definidos. Dales el entorno que necesitan y confía en la planificación — no en la improvisación. Un equipo rotativo es como un equipo donde nadie sabe dónde está el código, y todos culpan al anterior.
El método más eficiente y eficaz de transmitir información a y dentro de un equipo de desarrollo es a través de documentación clara y duradera, no de conversaciones que se evaporan. La documentación existe. Slack no.
El software sin errores es la medida principal de progreso. Funcionar no es suficiente — tiene que funcionar bien. Si el usuario tiene que hacer clic tres veces donde bastaba una, algo salió mal.
Los procesos lentos promueven el desarrollo sostenible. Patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante indefinidamente — sin sprints exhaustivos, sin burnout. Si alguien necesita bebidas energéticas para programar, el proceso está mal.
La atención continua a la arquitectura y al diseño a largo plazo aumenta la estabilidad. La refactorización preventiva es mejor que la corrección reactiva. El código legacy no es legacy — es la base que nadie quiere reformar.
Simplicidad — el arte de maximizar la previsibilidad y minimizar el retrabajo — es esencial. Menos novedad, más madurez. Si el framework tiene más características de las que usas, quizá no lo necesitas.
Las mejores arquitecturas, requisitos y diseños emergen de equipos experimentados y bien integrados, no de grupos rotativos que se disuelven al final de cada sprint. El conocimiento acumulado vale más que la documentación dispersa.
En intervalos regulares y espaciados, el equipo reflexiona sobre cómo volverse más eficaz — y luego refina y ajusta su comportamiento despacio y con criterio. El cambio de proceso también merece estabilidad. Si funciona, no lo toques. Si no funciona, espera un poco antes de tocarlo.