Dia desses eu tava pistolando no twitter e postei a bobeirinha abaixo. Como prometido, vou elaborar melhor e corrigir algumas falhas de argumentação da thread.
Metodologias Ágeis
— graciano codes (@wtfgraciano) May 20, 2020
vocês não estão prontos pra essa conversa https://t.co/4BdUK81Ap4
O modelo Cascata (waterfall) é um tanto quanto demonizado pelos autointitulados evangelistas do método ágil. A sua definição, que originalmente não tinha esse nome, é seguir estritamente em ordem os passos:
- Requerimento
- Projeto
- Implementação
- Integração
- Teste e depuração (verificação)
- Manutenção de software
Era um exercício teórico de modelo de produção, quase ninguém segue isso à risca. Sendo um tanto injusto e levando muitos evangelistas ao pé da letra, Waterfall se torna, na prática, uma definição tautológica: tudo que não é ágil é cascata (alerta de trocadilho). Consequentemente, o que chamam de características “inerentes a Waterfall” criticadas pelos evangelistas não podem ser inerentes. Porque “não é ágil” não é o suficiente para ser cascata. É uma categorização que induz ao erro. O fato dos métodos ágeis serem iterativos não dão a estes o status de floquinho de neve especial, os raros que usam iterações e repetições para testar as coisas. Esta característica não é algo exclusivo nem mesmo no campo do desenvolvimento de software.
Daí também se pode avaliar a utilidade de um modelo que poderia ser chamado de cascata. Dou dois exemplos
- Software de avião. O código só vai para “produção” depois de uns dois anos. E de fato “errar cedo” com iterações não é uma opção porque errar não é uma opção ao cuidar da vida das pessoas.
- Entregas em lotes não caem na definição restrita de Waterfall. Cada lote é uma cascata. Inclusive todo MVP é como se fosse um primeiro lote. Praticamente inexistentes são os softwares feitos em duas semanas que servem pra alguma coisa. Exceções que provam a regra que me vêm à cabeça são o git e o javascript.
Em ambos os casos o problema de não ter feedback (evangelistas adoram termos em inglês) rápido do cliente não existe. Não ser ágil não significa que o cliente esteja proibido de acessar uma versão controlada ou um beta ou algo do gênero.
Mas chega de cascata por enquanto, vamos para os métodos ágeis. O “Kanban” é simplesmente uma técnica do toyotismo, não é algo novo. Não é uma ideia genial de um engenheiro de software. Só é aplicado na nossa realidade com a categorização de método ágil. Já que Kanban é toyotismo, Fordismo poderia ser visto como cascata, talvez? De fato há a característica da subordinação a um gerente, algo que é proposto que seja despriorizado nos métodos ágeis. Há uma venda das ideias dos métodos ágeis com promessas do manifesto de melhorar a vida do trabalhador, assim como há no toyotismo. Ideias de autonomia e individualismo. Como se não ter um gerente fizesse alguma diferença radical na vida do trabalhador assalariado. O nome disso é ideologia. Vamos ao manifesto, ele cabe num tweet:
- Indivíduos e interações mais que processos e ferramentas
- Software em funcionamento mais que documentação abrangente
- Colaboração com o cliente mais que negociação de contratos
- Responder a mudanças mais que seguir um plano
O “mais que” deveria ser “mais importante do que”, na minha visão. Ou deveriam estar contextualizados melhor… enfim, esta é a tradução original, um tanto confusa. De qualquer forma, são modos de produção que não dialogam com o trabalhador que está na ponta do processo. Não apenas o Kanban é toyotismo, mas toda a metodologia ágil é apenas a aplicação deste modo de produção na área de TI. No toyotismo não há estoque, assim como na ideia de entrega contínua do software. Colocar 100% da produção sob demanda é uma escolha da cadeia de produção que só têm consequências positivas para os de cima.
Os primeiros três itens do manifesto são uma maneira neoliberal de descrever o que esta ideologia julga como um ambiente saudável de trabalho. Já o último é só outro jeito de dizer “move fast and break things” e bem, pergunta pro tio Zuck do facebook o que ele acha disso agora.
Um outro aspecto toyotista é a atitude PAREM AS MÁQUINAS de quando tem um bug. Este desespero quase nunca é necessário. Muitos bugs são detectados com um tempo considerável de vida após sua publicação em produção e muito provavelmente ninguém está morrendo (a não ser no caso do avião, por exemplo). Responder a mudança como prioridade é uma maneira de disciplinar e sugar as pessoas.
Eu particularmente prefiro o “waterfall” de seis semanas do basecamp (https://basecamp.com/shapeup), que não coloca a resposta a mudança como mais importante que ter um plano. Mas ainda não tive a oportunidade de trabalhar dessa maneira por um tempo prolongado. Não acho que exista um modo de produção ideal no atual mundo capitalista. Ele precisa nascer de uma proposta democrática nos locais de trabalho.