A ideia desse material é mostrar como o processo de previsibilidade, planejamento e estimativa que estamos acostumados a fazer, seja pelas buzzwords ou simplesmente pelo que ouvimos falar está totalmente desalinhado com o conhecimento base em métodos ágeis e como voltar as origens faz com que tenhamos sucesso.
Como base desse material, estou utilizando duas fontes fidedignas, que são Jeff Sutherland (criador do Scrum e o livro Scrum - A arte de fazer o dobro do trabalho pela metade do tempo) e Robert C. Martin (Uncle bob), e no caso do Bob Martin, to usando duas referências literárias (Agil Estimating and Planning & Clean Agile - Back to Basis).
Nesses quase dez anos trabalhando com "métodos ágeis" (o que não quer dizer que algum lugar que passei chegasse a 50% das práticas supostas), um do maiores desafios é justamente quando falamos de estimativas e previsibilidade das coisas e nesse sentido, sempre somos pegos de surpresa para responder "Quando isso tudo vai ficar pronto?" e claro que a resposta vem imediata, dotada do senso de incerteza com uma dose de coragem, que tem base na mais profunda mentira, misturada com a km do vento ao soprar ao norte, e assim se resulta numa previsão "tosca" que nunca será cumprida, os stakeholders passarão a não confiar na equipe de desenvolvimento, o clima de incerteza é instaurado, o turnover aumenta junto com a pressão e assim seguimos fazendo aquilo que achamos correto fazer, ou em outras palavras, uma tremenda bagunça.
Quando vamos ao Google buscar o termo metologias ágeis, hora ou outra vamos nos deparar com o Manifesto para Desenvolvimento Ágil de Software e claro que sabemos do que se trata não é mesmo:
- 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
Mas com base nisso, a boa parte dos times de engenharia, quando passam pelo onboarding da empresa, não passam pelo processo de entendimento sobre o que eu chamo de "filosofia ágil", ou seja, entender a história por trás do manifesto, entender os quatro grandes tópicos e o que cada um deles representam, ler algo sobre ao menos algum dos integrantes que lá estavam,como por exemplo, Kent Beck (Extreming Programming), Jeff Sutherland (Criador do Scrum), Bob Martin (Clean Code, Clean Agile, Clean Coder, etc), Andy Hunt & Dave Thomas (Pragmatic Programming), Martin Fowler (TDD), Brian Marrik (The Craft of Software Testing), provavelmente você que está lendo sequer sabe quem são certo? E claramente quando acessamos o site do Manifesto Ágil, olhamos apenas para os quatro valores, ignorando a lista daqueles que estavam lá definindo isso. Dado isso, segue a lista para que possamos ao menos dar um Google em cada um deles para ao menos conhecer o motivo pelo qual cada um deles eram considerados os maiores especialistas na época:
- Kent Beck
- Mike Beedle
- Arie van Bennekum
- Alistair Cockburn
- Ward Cunningham
- Martin Fowler
- James Grenning
- Jim Highsmith
- Andrew Hunt
- Ron Jeffries
- Jon Kern
- Brian Marick
- Robert C. Martin
- Steve Mellor
- Ken Schwaber
- Jeff Sutherland
- Dave Thomas
Sei que é meio complicado lembrar dos nomes de quem estava lá, mas somos os primeiros a criticar quando vem um Product Manager cheio de documentação e comunicação por email e lá dizemos "Indivíduos e interações mais que processos e ferramentas" ou "Software em funcionamento mais que documentação abrangente", mas sequer sabemos o que de fato foi pensado e por quem foi pensado. Por trás da filosofia ágil se encontra o uso da técnica do TDD e simplesmente continuamos a dizer que isso não funciona, sendo que o próprio Kent Beck estava lá colaborando no dia do manifesto e que entraram em um acordo que para ser ágil seria necessário a prática de TDD também, assim como técnicas de entrega contínua e indo um pouco além, quando falamos em métodos ágeis, ao lembrar dos valores, chegamos também de forma macro a valores do Extreme Programming (Comunicação, Simplicidade, Feedback, Coragem e Respeito) também criado por Kent Beck e ainda persistimos em dizer que XP não funciona e olha só que legal, o primeiro valor do manifesto ágil foi idealizado pelo próprio Kent Beck e não tem nada a ver com o que costumeiramente pensamos sobre mandar uma mensagem no slack pro product owner é pior que ir lá falar com ele, pelo contrário, tem a ver literalmente com a comunicação efetiva e feedback contínuo com a própria equipe de engenharia (o livro Clean Agile do Robert "Uncle Bob" Martin fala sobre isso).
Quando chegamos ao estado caótico, optamos por olhar para o mercado atrás de gurus que supostamente resolveriam os problemas que sabemos como resolver, mas temos demasiado ego inflado pra assumir que o que fazemos é uma verdadeira porcaria não é mesmo?
Antes de chegar numa solução, que tem por base voltar para o "básico" do Agile, vamos entender o que de fato nos leva ao desespero: