20 anos de Agile: a rebelião fracassada
(simplethread.com)<p>- Agora, 20 anos após a publicação do Agile Manifesto (Manifesto Ágil), há dois fatos claramente evidentes<br />
1. Venceu na hora de dar nome: ninguém quer ser chamado de non-Agile<br />
2. Na execução do Agile, ficou muito aquém das ideias revolucionárias de seus fundadores<br />
- “Todo mundo diz que faz Agile, mas quase ninguém é ágil de verdade.” Como chegamos a essa situação?<br />
<br />
[ Whence The Manifesto : como o manifesto começou ]<br />
- Em fevereiro de 2001, um grupo de 17 especialistas em software se reuniu em um resort de esqui em Utah<br />
- Após alguns dias de discussão, redigiram em conjunto o "Agile Software Development Manifesto"<br />
<br />
- O ponto importante é que eles eram "Practitioners (profissionais da prática)". Não eram PMs, CTOs ou VPs de Engenharia. Eram desenvolvedores, programadores, cientistas e engenheiros. Continuavam escrevendo código e colaborando com stakeholders para resolver problemas naquela época. Isso é realmente importante.<br />
- Outro ponto é que o Agile Manifesto não surgiu do nada. Vários deles já tinham metodologias que haviam criado ou estavam promovendo. <br />
→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Pragmatic Programming <br />
<br />
- Todos no grupo tinham ampla experiência em desenvolvimento de software e buscavam uma alternativa ao processo pesado, guiado por documentação, que dominava o mercado naquele momento.<br />
- O núcleo do manifesto é a explicação de quatro valores<br />
<br />
"Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazê-lo. Por meio desse trabalho, passamos a valorizar:<br />
- indivíduos e interações mais que processos e ferramentas<br />
- software em funcionamento mais que documentação abrangente<br />
- colaboração com o cliente mais que negociação de contratos<br />
- responder a mudanças mais que seguir um plano<br />
Ou seja, embora haja valor nos itens à esquerda, valorizamos mais os itens à direita."<br />
<br />
[ A New Hope : uma nova esperança ]<br />
- Visto da perspectiva de 2021, é fácil tratar práticas modernas de desenvolvimento de software como algo óbvio, mas em 2001 essas ideias eram extremamente radicais.<br />
- Começar a desenvolver software antes de levantar todos os requisitos e avaliar todas as funcionalidades? Loucura!<br />
- Um ponto importante que vem sendo esquecido é que, no começo, o Agile era abertamente e combativamente anti-management.<br />
<br />
- Por exemplo, Ken Schwaber, cofundador do Scrum, defendia eliminar todos os gerentes de projeto; não apenas tirá-los dos projetos, mas acabar com a própria profissão no setor.<br />
<br />
"Descobrimos que o papel do gerente de projeto é contraproducente em trabalhos complexos e criativos. <br />
O pensamento do gerente de projeto, expresso no plano do projeto, <br />
em vez de reunir a inteligência de todos para resolver o problema da melhor forma, <br />
limita a criatividade e a inteligência de todos ao que está escrito no plano."<br />
<br />
- O scrum master quase não tinha autoridade e nem direito a voto nas questões. Era um servant leader*, protegia o time e removia impedimentos, mas não gerenciava a equipe. <br />
→ servant leader: líder que serve sua equipe, ajuda em seu crescimento e desenvolvimento, constrói confiança entre líder e liderados e faz com que contribuam por conta própria para os objetivos da organização <br />
- No XP também existiam originalmente os papéis de Tracker e Coach, que funcionavam de forma semelhante. <br />
<br />
- Alistair Cockburn, criador do Crystal e da arquitetura Hexagonal, disse recentemente o seguinte em uma thread no Twitter <br />
"O Scrum fechou um acordo extraordinário em território hostil:<br />
- os executivos podiam mudar de direção 12 vezes por ano, do jeito que quisessem, após cada sprint<br />
- o time ganhava um mês inteiro de silêncio absoluto, sem interrupções nem mudanças de direção, para fazer trabalho pesado de reflexão e execução <br />
- o time podia declarar, no Bid (para definir prioridades), o que conseguiria e o que não conseguiria fazer naquele mês, sem interferência da gerência<br />
- nenhum executivo jamais fez acordo melhor que esse<br />
- nenhum time de desenvolvimento jamais fez acordo melhor que esse<br />
"<br />
(Nota do tradutor: essa thread começou com a pergunta "de onde veio a ideia de que times Scrum precisam concluir 100% de todos os itens atribuídos ao sprint? Isso não faz sentido." Recomendo ver a thread original inteira.)<br />
<br />
- Sou scrum master certificado e trabalho em times Agile há mais de 15 anos, além de ter lido muitos livros populares da área, mas nunca tinha visto a ideia do Scrum explicada de forma tão clara e concisa. <br />
- O Scrum foi criado para funcionar em ambientes hostis. É um acordo entre desenvolvedores, que precisam de tempo para pensar e explorar, e gestores coercitivos.<br />
<br />
[ The Empire Strikes Back : o império contra-ataca ]<br />
- Em certo sentido, o Agile foi um movimento trabalhista de base. Começou com os praticantes e chegou até a gestão. Como isso conseguiu dar certo?<br />
- Em parte, porque o número de desenvolvedores cresceu e o valor que entregavam aos negócios aumentou<br />
- Mas o motivo maior era que o modelo tradicional de desenvolvimento waterfall não estava funcionando<br />
- À medida que o software ficava mais complexo, o ritmo dos negócios acelerava e os usuários se tornavam mais exigentes, tornou-se impossível planejar tudo antecipadamente.<br />
- Aceitar o desenvolvimento iterativo era lógico, mas para os gestores acostumados a planejar tudo, era um pouco assustador. <br />
<br />
- Em meados dos anos 2000, a gestão ainda não havia realmente comprado a ideia. <br />
- Então surgiu a conversa: "vamos tentar essa ideia maluca de que os engenheiros vivem falando. Já não vamos cumprir o prazo mesmo; quanto pior pode ficar?"<br />
- Mas, surpreendentemente, começou a funcionar. Os times ficaram um pouco retraídos no início (e mais lentos), mas aos poucos descobriram quais padrões funcionavam para cada equipe e começaram a ganhar velocidade.<br />
- Depois de alguns sprints, perceberam o poder de priorizar software funcionando, colaboração, inspeção e adaptação, em vez de todo o resto.<br />
<br />
- Em cerca de 5 anos, o Agile passou de algo de que se tinha ouvido falar para algo com que todos ainda não estavam familiarizados. <br />
- Em 2005, Agile e TDD eram verdadeiros diferenciais <br />
- Em 2010, os times modernos de software já faziam Agile de alguma forma.<br />
- Pelo menos no mercado de consultoria, era uma bolha. As grandes empresas sempre se moviam mais devagar, claro.<br />
<br />
"Nós conseguimos! Nós vencemos! Vamos todos comemorar"<br />
Esse é o fim da história, e você já pode fechar a aba do navegador.<br />
<br />
"Winning was easy, young man. Governing’s harder."<br />
"Vencer foi fácil, jovem. Governar é mais difícil." <br />
→ George Washington, como retratado em Hamilton (o musical)<br />
<br />
- Infelizmente, como em muitas revoluções, a história do Agile não se desenrolou da forma como seus fundadores imaginaram.<br />
→ Descobriu-se que priorizar "indivíduos e interações" é um conceito difícil de vender. É muito mais fácil vender processos e ferramentas.<br />
(Nota do tradutor: aqui, Sell não significa exatamente vender, mas convencer os outros, então foi mantido.)<br />
→ Descobriu-se que "software em funcionamento" é mais difícil de produzir do que planos irreais e muita documentação.<br />
→ "Colaboração com o cliente" exige confiança e vulnerabilidade, mas isso nem sempre existe nos negócios.<br />
→ "Responder a mudanças" frequentemente perdeu espaço para executivos mais focados em fazer planejamento de longo prazo e manter controle.<br />
<br />
"Descobriu-se que, quando o Agile não é bem executado, ele frequentemente parece caos"<br />
<br />
- Mas isso não significa que esses quatro valores estejam errados<br />
- Significa que tudo isso exige algum esforço para funcionar direito e coragem para aceitar que software é, por natureza, confuso e bagunçado. <br />
- É preciso entender e acreditar que, se continuarmos aprendendo, nos adaptando, melhorando e lançando, acabaremos chegando a um lugar muito melhor que a cascata, muito mais honesto, realista e produtivo.<br />
<br />
"O movimento ágil não é anti-metodologia. <br />
Na verdade, muitos de nós queremos restaurar a credibilidade da palavra 'metodologia'. Queremos restaurar o equilíbrio. <br />
Aceitamos modelagem, mas não para enfiar diagramas em um depósito empoeirado da empresa. <br />
Aceitamos documentação, mas não centenas de páginas que não são mantidas e quase nunca são usadas. <br />
Fazemos planos, mas reconhecemos os limites dos planos em ambientes turbulentos. <br />
Quem rotula apoiadores de XP, Scrum ou outras metodologias ágeis como 'hackers' simplesmente desconhece a definição original de 'metodologia' e de 'hacker'."<br />
- Jim Highsmith, History: The Agile Manifesto<br />
<br />
- Esses são pontos importantes. Ainda fazemos planos e documentação, e precisamos ser rigorosos com Agile. Trata-se de equilíbrio.<br />
- Porém, se sua organização está tendo dificuldades na transição para Agile e caiu no caos, quando alguém oferece um bote salva-vidas na forma de certificações, processos e ferramentas, é natural pular nele.<br />
- A gestão entende muito melhor processos e ferramentas do que "times auto-organizados". <br />
<br />
[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One (o retorno) ]<br />
- Aqui minha estrutura de três atos desmorona um pouco. Porque não vemos rebeldes corajosos retornando sem usar o nome Agile<br />
(Nota do tradutor: fazendo alusão aos títulos de Star Wars, o sentido é que não surgiu algo diferente que substituísse o Agile.)<br />
<br />
- Ferramentas vendidas por vendors, consultores de processo e especialistas frequentemente prometem coisas que jamais poderão entregar.<br />
- Foi assim que acabamos criando SAFe (Scaled Agile Framework for Enterprise), Scaled Scrum e outras versões corporativas de Agile<br />
- Esses frameworks não foram criados com má intenção e, provavelmente, têm algum valor no contexto adequado.<br />
- Mas eu não os chamaria de Agile<br />
- Quando se tenta escalar uma metodologia focada em indivíduos e interações, problemas inevitavelmente surgem e os valores originais da metodologia são prejudicados.<br />
<br />
- Um texto famoso escrito em 2018 por Ron Jeffries, signatário do Manifesto Ágil e cofundador do XP<br />
<br />
"Desenvolvedores deveriam abandonar Agile.<br />
Quando as ideias de 'Agile' não são aplicadas corretamente, isso leva a mais interferência sobre os desenvolvedores, menos tempo para trabalhar, mais pressão e exigências de 'andar mais rápido'. Isso não é bom para os desenvolvedores e, no fim das contas, também não é bom para a empresa. Quando 'Agile' não é feito corretamente, com frequência surgem muito mais defeitos e um progresso mais lento do que seria realmente possível. Muitas vezes, bons desenvolvedores acabam deixando essas empresas e, como resultado, elas se tornam menos eficientes do que eram antes de adotar 'Agile'."<br />
<br />
- Outro texto famoso, escrito em 2014 por Dave Thomas, outro signatário e cofundador de Pragmatic Programming <br />
<br />
"Agile morreu. (Vida longa à agilidade)<br />
A palavra 'Agile' foi subvertida a um ponto em que praticamente perdeu o significado e, no caso da comunidade ágil, tornou-se em grande parte um lugar onde consultores e vendors vendem serviços e produtos. À medida que o Manifesto se popularizou, a palavra Agile virou um ímã para tudo aquilo que tinha algo a defender, horas para faturar ou produtos para vender — tornou-se um termo de marketing. <br />
<br />
Por isso, acho que já é hora de aposentar a palavra 'Agile'."<br />
<br />
[ Retro : retorno ao passado ]<br />
- O mais triste é ver jovens desenvolvedores desprezando Agile e pensando nele como uma ferramenta para gestores extraírem promessas irreais e incentivarem desenvolvedores a trabalhar horas absurdas.<br />
- O único Agile que eles conhecem é um mecanismo de controle imposto sobre eles, e não uma ferramenta de empoderamento que antes era acolhida com entusiasmo.<br />
- Ainda assim, espero que iniciar uma discussão sobre a história e a visão original ajude a lembrar como devemos seguir em frente. <br />
<br />
- Apesar disso, a boa notícia é que os princípios do Agile Manifesto continuam tão sábios e relevantes hoje quanto eram há 20 anos. E até pessoas tidas como apóstatas, como Jeffries e Thomas, ainda pensam assim.<br />
<br />
- No texto citado acima, Jeffries diz o seguinte <br />
"No entanto, os valores e princípios do Manifesto for Agile Software Development ainda oferecem, para mim, a melhor forma de construir software que conheço e, com base em minha longa e variada experiência, eu seguiria esses valores e princípios em organizações maiores, independentemente da metodologia usada."<br />
<br />
- Concordo com essa opinião<br />
- Falar de Agile hoje não é algo cool nem descolado. Agile é entediante. <br />
"Todo mundo já faz Agile, né?"<br />
- Agora é o momento perfeito para olhar para trás, para estes últimos 20 anos, e fazer algumas perguntas a si mesmo <br />
→ O que deu certo?<br />
→ O que deu errado?<br />
→ O que você gostaria de fazer diferente da próxima vez?<br />
- Nos próximos meses, o plano é revisitar os 12 princípios originais do Agile, contextualizar seu significado original e considerar seu valor no ambiente atual de desenvolvimento de software <br />
<br />
"Minha esperança é que, estudando os princípios fundadores, possamos aprender com o passado e, como diz Dave Thomas, mesmo que abandonemos 'Agile', possamos preservar a 'Agility'."</p>
3 comentários