Princípios por trás do Manifesto Lento
Nós seguimos estes princípios:
Nossa maior prioridade é satisfazer o cliente através da entrega de software sem falhas, mesmo que demore. A pressa é inimiga da confiança — um sistema que não quebra vale mais que dez lançamentos cheios de patches. Se o prazo apertar, apague o prazo, não a qualidade.
Mudanças nos requisitos devem ser avaliadas com cuidado, mesmo quando surgem tardiamente. Processos lentos preferem a estabilidade à reatividade, visando previsibilidade para o cliente e para a equipe. E se a mudança forreally merely “muda a cor do botão”, mande o cliente escolher no sistema.
Entregar software funcionando em ciclos longos e bem planejados, de alguns meses a um ano, com preferência à escala de tempo que permita qualidade. Quem entrega rápido demais costuma entregar errado demais.
Pessoas de negócio e desenvolvedores devem trabalhar de forma assíncrona e documentada, evitando reuniões constantes que dissipam o foco e alongam o prazo. Se pode ser resolvido por e-mail, não marque reunião. Se pode ser resolvido por documento, não mande e-mail. Se pode ser resolvido por café, mande café.
Construa projetos em torno de equipes estáveis e processos bem definidos. Dê a elas o ambiente necessário e confie no planejamento — não no improviso. Equipe rotativa é como um time em que ninguém sabe onde está o código, e todo mundo culpa o anterior.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de documentação clara e duradoura, não de conversas que evaporam. Documentação existe. Slack não.
Software sem bug é a medida primária de progresso. Funcionar não é suficiente — tem que funcionar certo. Se o usuário precisa clicar três vezes onde bastava uma, algo deu errado.
Os processos lentos promovem desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente — sem sprints exaustivos, sem burnout. Se alguém precisa de energético para programar, o processo está errado.
Contínua atenção à arquitetura e ao design a longo prazo aumenta a estabilidade. Refatoração preventiva é melhor que correção reativa. Código legado não é legado — é a base que ninguém quer reformar.
Simplicidade — a arte de maximizar a previsibilidade e minimizar o retrabalho — é essencial. Menos novidade, mais maturidade. Se o framework tem mais features do que você usa, talvez você não precise dele.
As melhores arquiteturas, requisitos e designs emergem de equipes experientes e bem integradas, não de grupos rotativos que se dissolvem ao fim de cada sprint. Conhecimento acumulado vale mais que documentação dispersa.
Em intervalos regulares e espaçados, a equipe reflete sobre como se tornar mais eficaz — e então refina e ajusta seu comportamento devagar e com critério. Mudança de processo também merece estabilidade. Se funciona, não mexa. Se não funciona, espere um pouco antes de mexer.