A morte lenta e dolorosa do Agile e do Jira
(ehandbook.com)"Como Agile deixou de ser Agile, chegou a hora de ele desaparecer junto com o Jira"
- Os ciclos de desenvolvimento de software estão ficando cada vez mais longos, as equipes técnicas cada vez maiores, a gestão de desenvolvimento exige cada vez mais aplicativos, há cada vez menos pessoas realmente programando e, em períodos cada vez mais curtos, há cada vez menos progresso entre checkpoints contínuos
- Onde foi que o Agile começou a dar errado?
- Agile é uma metodologia desenvolvida no início dos anos 2000 como alternativa aos processos pesados de desenvolvimento de software, centrados em documentação
- Porém, hoje o Agile está se deformando em uma metodologia complexa de gestão de projetos existente
O principal problema é o inchaço tecnológico (Tech Bloat)
- O principal motivo pelo qual muitas pessoas abandonam ou querem abandonar o Agile é o inchaço tecnológico
- O inchaço tecnológico é inimigo de toda empresa de tecnologia e também é um risco para empresas não tecnológicas que têm equipes de desenvolvimento internas ou terceirizadas
- O inchaço tecnológico é diferente de dívida técnica, mas acaba gerando dívida técnica
- Os sintomas do inchaço tecnológico são os seguintes:
- Conversar repetidamente com clientes, mas sem se tornar especialista no comportamento deles
- Avaliar e reavaliar constantemente prazos e datas de entrega
- Relutância extrema em iniciar o processo de desenvolvimento até que todos os detalhes estejam documentados
- Surge a motivação de começar pelas tarefas mais fáceis, e não pelas mais arriscadas
Os resultados confusos do inchaço tecnológico
- Aumento da documentação
- A documentação que acompanha o processo passa a rastrear não apenas o que foi desenvolvido e por quê, mas também "como" foi desenvolvido
- Esse "como" vira o foco das atualizações de status, levando a uma reavaliação constante de como a equipe está trabalhando
- A equipe passa mais tempo discutindo por que o trabalho não foi concluído do que efetivamente trabalhando
- Definição frequente de prazos
- Mais prazos são definidos em checkpoints mais frequentes, o que essencialmente gera microgestão em cada ponto de inflexão de um processo que é, por natureza, criativo
- Isso vai contra a produção de software de qualidade, porque tudo acaba sendo entregue dentro de um prazo fixo, independentemente de quão bem o trabalho foi executado
- A dúvida constante no processo de reavaliação
- Durante os períodos de reavaliação, a dúvida constante faz com que boas práticas não sejam consolidadas, desperdícios não sejam eliminados e economias de escala não sejam reconhecidas
- Microgestão do processo produtivo
- Quando cerca de 30% de uma funcionalidade inteira está pronta, ela já deixa de ser prioridade
- A organização entra em uma espiral de morte de produzir o que está no roadmap, independentemente de ele ainda definir ou não a construção de um produto bem-sucedido
- Resultado final
- O produto sofre sob o peso de demandas variadas e conflitantes dos clientes
- As funcionalidades frequentemente chegam tarde ao mercado e são entregues na forma e na ordem mais convenientes para a equipe técnica, e não na forma e na ordem mais adequadas ao mercado
- No fim, as equipes de vendas/marketing reagem, porque não sabem o que estão vendendo nem o que os clientes estão comprando
- Então a organização parte para uma grande limpeza
O mundo precisa de software leve que faça melhor o que importa, não de mais funcionalidades
- Isso não é uma ideia nova, mas é uma ideia da qual todas as metodologias acabam se afastando
- No fim, as pessoas começam a perguntar se o método Toyota é suficientemente Toyota para a Toyota, e isso se transforma em mais trabalho para criar mais trabalho
- O Agile agora virou um PMP com nome bonitinho, reuniões mais curtas e mais regras
- O problema não está na ideia do Agile, mas na execução e na falta de liderança para mantê-lo sob controle
- É um problema da gerência intermediária, focada mais em prazos do que em utilidade, mais em cortes do que em crescimento, mais em economia do que em progresso
A opinião do GN⁺
- O Agile, ao contrário de sua intenção original, está se tornando burocrático e formalista, e isso está contribuindo para desacelerar o desenvolvimento de software
- O inchaço tecnológico é um fator de risco ao qual se deve prestar atenção não só no Agile, mas em qualquer organização de tecnologia
- Documentação, definição de prazos e microgestão podem, ao contrário, reduzir qualidade e velocidade
- Como a essência do Agile está em foco no cliente, colaboração e flexibilidade, é preciso revisitar os princípios em vez de ficar preso à forma
- No desenvolvimento de software, o importante não é ter mais funcionalidades, mas implementar bem as funcionalidades centrais
- Como a cultura organizacional e a liderança determinam o sucesso ou fracasso do Agile, gestores de tecnologia devem prestar atenção a isso
- Parece ter chegado a hora de buscar novas metodologias além do Agile
17 comentários
Não consegui ver o original até o fim porque é um artigo pago, mas acho que seria bom lapidar um pouco mais a formulação da tradução.
“Como Agile deixou de ser agile, agora é hora de Agile desaparecer junto com o Jira”
=> “Como Agile parou de
being agile, agora é hora de Agile desaparecer junto com o Jira”Existe essa noção de usar Agile com maiúscula e agile com minúscula de forma distinta,
e também se pensa em
being agileedoing agilecomo conceitos ligados entre si, mas ainda assim separados.being agilebydoing agile.O motivo para adotar Agile é importante. Será que adotam para melhorar o desenvolvimento? É mais algo como: não aguento ver vocês aí de boa; vou ficar de olho para ver o quanto estão se esforçando. É com essa mentalidade que adotam. Então, claro, vira um inferno.
A essa altura, parece que vamos precisar de uma checklist de conformidade com Agile.
Antes mesmo da questão de ser Agile ou waterfall, se o ambiente — pessoas, cultura etc. — continuar igual, por mais inovadora que seja a metodologia de desenvolvimento adotada, o resultado inevitável é que tudo vire uma versão K-OOO.
Se quase não houver mudanças nos requisitos, do ponto de vista de quem desenvolve, waterfall realmente é um método bem confortável. Desde que realmente não haja mudanças nos requisitos...
O ágil à coreana nem passa por reavaliação.!
Cliente: acho que seria melhor ter o botão aqui nesta tela
Desenvolvedor: (vou ter que virar a noite, e ainda tem demanda nova)
Cliente: acho que tem que ter um botão em outra tela
Desenvolvedor: (alguém usa técnica de clonagem pra me ajudar) sim, haha..
Cliente: ainda não ficou pronto? Pelo cronograma, não era pra já estar tudo concluído?
Desenvolvedor: (me salva) sim..;;
Não há muitos casos de uso de Agile de forma verdadeiramente ágil e sustentável no longo prazo,
e parece que a maioria das organizações acaba convergindo para um trabalho em waterfall com prazos curtos.
O problema não é o Agile. O problema são as pessoas que o praticam. Não importa qual metodologia tragam: no fim, tudo depende de como quem a aplica trabalha com ela. Eu penso que Agile não é uma metodologia, mas algo mais próximo de uma mentalidade de fazer o produto evoluir em determinados ciclos. Quando se perde isso de vista e se faz planejamento e retrospectiva de forma cega, parece só perda de tempo.
Achei que isso só acontecia com o k-agile, mas era um fenômeno global.
Parece uma sensação de ficar batendo repetidamente na coisa errada... O critério deveria ser se está ou não de acordo com o Manifesto Ágil...
Até o Uncle Bob, que participou do Manifesto Ágil, entendeu esse problema cedo e publicou o livro Clean Agile em 2019 para corrigir o Agile mal aplicado, mas esse tipo de problema ainda continua. Pessoalmente, acho que isso acontece porque o Agile não tem diretrizes padrão e usa a expressão vaga “cultura”. Seria bom se fossem apresentadas diretrizes padrão mais concretas.
Acho que o autor provavelmente defenderia abandonar qualquer metodologia assim que ela se burocratizasse.
Concordo. Acho que está aumentando a quantidade de casos em que fazem Agile do jeito errado e depois dizem que o Agile está errado.
Ao mesmo tempo, também penso que, mesmo já tendo se passado bastante tempo desde que surgiu, parece inevitável que ainda seja difícil acumular boas práticas.
No fim das contas, voltamos ao que era antes?
Opinião do Hacker News
Problemas do Agile
Princípios do Manifesto Agile
Essência do Agile
Flexibilidade do Agile
Opiniões sobre o JIRA
Origem do Agile
O estado atual do Agile
Problemas do JIRA
Aplicação do Agile