20 anos de Manifesto Ágil

Picture of Thiago Brant

Thiago Brant

Management 3.0

De 11 a 13 de fevereiro de 2001, no resort de esqui The Lodge at Snowbird nas montanhas Wasatch de Utah, dezessete pessoas se encontraram para conversar, esquiar, relaxar e tentar encontrar um terreno comum – e, claro, para comer. O que surgiu foi o Manifesto Ágil de ‘Desenvolvimento de Software’. Representantes da Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e outros simpáticos à necessidade de uma alternativa aos processos de desenvolvimento de software pesados orientados por documentação convocados.

Exatamente 20 anos atrás nascia o saudoso Manifesto Ágil! Por muito tempo eu considerava que ser ágil era seguir o que constava no Manifesto Ágil. Confesso que até funcionou, mas hoje já percebo, como muitos, esse manifesto como um documento histórico. Muito relevante, mas que deve ser observado como o início de um movimento que hoje vai muito mais além do desenvolvimento de software (ou do “Software em funcionamento”). Sabemos agora que o importante é valor na mão do cliente, do usuário final.

Mas ainda sim os valores continuam relevantes, talvez com alguma adaptação.

Indivíduos e interações mais que processos e ferramentas

Processos e ferramentas são algo imprescindível em um ambiente ágil. Precisamos ter quase que uma obsessão por otimizá-los o tempo todo. Mas o que fica aqui é: eles não podem passar por cima dos indíviduos, e serem mais valorizados do que suas interações.

Software em funcionamento mais que documentação abrangente

Aqui já comentei sobre focarmos mais em valor do que software em si (do que vale um software funcionando perfeitamente, mas sem valor para o usuário?). Mas nunca, NUNCA mesmo diga que ágil não tem documentação. O que precisamos buscar é uma documentação também de valor, que tenha uso. Eu costumo lembrar do BDD sempre que falo desse valor, uma maneira viva de documentar código!

Colaboração com o cliente mais que negociação de contratos

Tenho visto que o tema dos “contratos ágeis” ainda não emplacou totalmente, mas observo muitos avanços. Nossos contratos não podem escravizar os clientes e engessar os processos. Eles precisam ser firmados de forma a gerar colaboração e relações ganha-ganha. E claro gente, não estamos falando do fim dos contratos, mas de contratos mais inteligentes.

Responder a mudanças mais que seguir um plano

“No ágil não planejamos”. O que eu acho dessa informação? Sinceramente: bullshit. Precisamos planejar sim! Só que temos que focar no planejamento mínimo, o mínimo suficiente para gerar foco e alinhamento. Já parou para olhar a daily como uma cerimônia de planejamento?

Slide do Management 3.0 sobre o Manifesto Ágil

E interessante citar a daily, algo típico do Scrum. O scrum é ágil? Você pode ver que entre os signiatários do Manifesto estão Jeff Sutherland e Ken Schwaber, criadores do Scrum. Sim, o Scrum foi criado antes do Manifesto Ágil. Ele é de 1995, enquanto o manifesto saiu em 2001. Por isso muitas coisas do manifesto tem relação com o Scrum, pois já eram práticas usadas nesse framework (lembra do “Estamos descobrindo maneiras melhores de desenvolver software…“? Pois é!).

E como eu digo, não se engane! Usar Scrum não é sinônimo de ser ágil. Existe muito time Scrum que não é nada ágil, e ontem até tive uma conversa sobre cenários em que força-se tanto a implantação do Scrum, que acaba-se criando um time menos ágil do que antes do Scrum. Curioso, né? Pense nisso! Agilidade é um modo de pensar, e não frameworks e ferramentas.

Por fim, termino relembrando que o Manifesto Ágil não são só os famosos e manjados 4 valores. Ele também descreve 12 princípios, que são muito importantes na agilidade, e não podem ser ignorados:

  1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
  2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
  3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
  4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
  5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
  6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
  7. Software funcionando é a medida primária de progresso.
  8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
  9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
  10. Simplicidade–a arte de maximizar a quantidade de trabalho não realizado–é essencial.
  11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
  12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Dá pra conversar longamente sobre esses princípios, mas vou focar em alguns pontos que acho que vale destacar:

  • Software em funcionamento é a medida de progresso tem um conceito implícito aí, que é o de pronto. Na agilidade não existe essa de quase pronto, 50% pronto, falta 10%. Ou é pronto, ou não é. Medimos progresso por itens prontos, e não por coisas parcialmente prontas.
  • Ritmo constante e sustentável não quer dizer que na agilidade não tem hora extra. É claro que tem! Se um time precisar fazer alguma hora extra para deixar algo pronto, faça! O que não podemos fazer é tornar isso uma rotina (aí sim, deixa mesmo de ser sustentável)
  • Construa projetos em torno de indivíduos motivados: olha o link com nosso querido Management 3.0!
  • E olha lá para o princípio 3. Dá pra entender a partir dele os sprints do Scrum não?

Aí a reflexão que fica, 20 anos depois, acaba sendo “ainda faz sentido? não está obsoleto?”. Minha opinião? Ainda faz MUITO sentido, ainda mais sentido! Estude o manifesto ágil, entenda o que está por trás dele, veja tudo que os seus signatários trabalharam e fizeram chegar nesse manifesto. Esse é um documento histórico sim! E todo agilista deveria tê-lo em um quadrinho em seu escritório, ou em um boardzinho do Miro, não é não?

8 fundamentos da agilidade pelo Management 3.0

Você já viu o que o Management 3.0 tem pra dizer sobre tudo isso? Nos workshops de Management 3.0 da Agilers você encontra todo o conteúdo desenvolvido por essa brand, que aborda, entre outras coisas, o “Desenvolvimento Ágil de Produtos”, que aparece em nosso workshop “Crescendo a Estrutura e Melhorando Tudo” e “Agilidade para Recursos Humanos”.

Referências:

Cookies

Utilizamos cookies para personalizar o seu conteúdo e melhorar sua experiência com a Agilers. 

Saiba mais sobre os cookies em nossa Política de Cookies

Abrir bate-papo
💬 Precisa de ajuda?
Agilers
Olá 👋
Podemos ajudá-lo?