Async Manifesto – Será que o Agile está ultrapassado?

Outro dia meu amigo Edmundo mandou na lista dos desenvolvedores do QMágico:

http://asyncmanifesto.org/
Será que o Agile Manifesto já está ultrapassado?
Nós já seguimos muita coisa que esse manifesto está propondo.
O que acham?

Dei uma lida no manifesto, e isso me fez dar umas filosofadas a respeito.
Resolvi compartilhar minha resposta aqui no blog🙂

Concorda? Discorda? Mete a caneta nos comentários aí🙂

————————————————————————–

Bem legal. A idéia de diminuir a quantidade de reuniões é sempre bem vinda, principalmente entre nós programadores né🙂

Mas, tua pergunta me fez dar umas filosofadas, que acho legal comptilhar.

Será que o Agile Manifesto já está ultrapassado?

Vamos ver:

Agile:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Async:

1. Modern tools and flexible work environments over meetings and office hours
2. Flexibility in prioritization over detailed planning
3. Comprehensive documentation over tribal knowledge

À primeira vista parece que o Async é mais um complemento do que um substituto pro Agile.
Por exemplo, olhando Agile2 + Async3, temos:

Working software > comprehensive documentation > tribal knowledge.

Só que não.

Lendo com mais calma o Async, vc nota que o “comprehensive documentation” se refere a coisas diferentes nos dois manifestos! – No meu entendimento pelo menos:

No Agile, ele fala de documentação que vc entrega pro cliente. Que eu concordo que é realmente uma parada secundária.
No Async, ele se refere a documentação que a gente consome internamente (como a nossa página de componentes!!), que estamos começando a perceber que tem um valor enorme!

Mas beleza, até aí nenhum conflito tb.

Mas quando vc olha pra Agile1 x Async1, eles parecem opostos, conflitantes, sim:

Agile1: people+interactions (=meetings?) > tools
Async1: tools > meetings

Né?

Eu já tinha pensado um pouco sobre isso pra falar a verdade…
Cada vez mais eu acho que processos e ferramentas são importantes demais – e o jeito que o Agile fala deles não parece fazer justiça ao tamanho dessa importância. Então nesse ponto, o Async1 me parece ser mesmo uma correção válida em cima Agile, sim.

Duas coisas que eu tentaria falar diferente no Async:

1) Acho que não tem nada a ver falar que o Scrum é uma encarnação do Agile. Apesar dessa ser uma interpretação comum da nossa indústria.
Na real, uma cultura ágil tem muito mais a ver com ENGENHARIA (TDD, Refactoring, Refactoring, já falei Refactoring?, Integração contínua, Deploy contínuo, etc) do que com GESTÃO (Scrum, Daily meetings, etc).
Quem acha que é ágil pq usa Scrum, tá fazendo isso errado.

2) É perigoso dizer “Document everything”!
Não. Tudo não, po! É pra documentar só o que precisa.
Acontece que o que precisa é bem mais do que o normalmente se documenta.
Mas isso é muito menos que “tudo”.
Isso dá margem pra que gerentes sem noção demandem um monte de documentação inútil.

[ ]’s!

2 comentários em “Async Manifesto – Será que o Agile está ultrapassado?

  1. Individuals and interactions over processes and tools: Vejo isso como não ficar preso a ferramentas. Cada time tem sua realidade, e os processos e ferramentas devem se adaptar à essa realidade do time. Mas com certeza processos e ferramentas também são muito importantes.

    Não vejo tanto valor na documentação de código em si, a não ser o próprio teste, que quando bem feito, não se compara à nenhuma documentação. Além disso, os testes sempre estão mais atualizados que a documentação.
    Então, o que documentar?

    Para os programadores, considero que um README sempre atualizado é praticamente toda a documentação necessária. No slide 23 tem o que considero importante em um README https://speakerdeck.com/caike/como-pegar-um-trem-em-movimento, embora toda a apresentação seja excelente. Um bom teste a ser feito é colocar uma pessoa nova no projeto e deixar ela se virar pra fazer o setup. Se conseguir fazer tudo sozinho, a documentação está boa o suficiente. A única documentação que senti falta na apresentação do Caike é do glossário. Geralmente, a aplicação tem um vocabulário próprio que pode ser difícil alguém entender apenas lendo o código.

    Para o cliente, acredito que um roteiro de teste contendo o que foi desenvolvido na iteração seja o suficiente.

    A thoughtbot tem uma documentação completa de todo o processo, e é atualizada quase diariamente http://playbook.thoughtbot.com.

    Pra mim, o Agile se resume em: Feedback rápido e melhoria contínua baseada nesse feedback.

    Acho que escrevi um post🙂

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s