Incrementos

É bastante comum as pessoas reclamarem que a empresa que trabalha não é ágil. Da mesma forma é bastante comum culparem os gerentes, coordenadores, diretores, o cara que cuida dos processos e etc… Algumas pessoas lutam com muito afinco por mudanças e as vezes conseguem adotar uma ou outra prática do Scrum ou até contratam um treinamento. A questão é que na maioria das vezes o que vai impedir o sucesso da adoção Agile na empresa não é o seu gerente, nem seus gerentes de projeto e nem o cara que cuida dos processos: o que impede a adoção Agile na maioria das equipes que tenho contato é a falta de conhecimento de boas práticas de engenharia.

Como já havia citado aqui, design incremental é uma das práticas de engenharia que poucas equipes dominam. Poucas equipes sabem exatamente o que é um incremento. Um dos conceitos do Scrum que é bem pouco comentado e que costumo dar bastante enfoque no meu treinamento é exatamente a definição do pedaço de funcionalidade potencialmente implantável. O próprio Ken Schwaber disse no Gathering que somente 20% das equipes conseguem entregar algo potencialmente implantável ao final da iteração. Inclusive, essa é a motivação dele ter fundado a Scrum.org após sua saída da controversa Scrum Alliance.

Quando dizemos que estamos entregando algo potencialmente implantável isso nos leva a uma visão que poucas equipes Scrum tem: no andar das iterações é o cliente que decide a hora que ele quer ir para a produção, e seu software deve permitir isso. Tudo aquilo que você “incrementou” deve ser capaz de resolver algum problema de negócio sem depender de grandes investimentos em preparação de ambientes ou “Sprints de estabilização”. O que você incrementa além de atender a sua definição de PRONTO deve ser sólido, refatorável, bem arquitetado e durar para sempre. O software criado deve ser um ativo, que coloca dinheiro no bolso de alguém.

Quanto eu estou pareando com alguém ou trabalhando num incremento eu vejo algumas características na realização desse trabalho. Basicamente um incremento é:

– Documentado e especificado (usando BDD, TDD ou outros documentos)
– Analisado (parte do ciclo TDD, refactorings)
– Sólido (incremente com boas práticas OO)
– Coberto por testes (incrementos futuros não quebram o atual)
– Integrado Continuamente (há outros na equipe incrementando)
– Potencialmente Implantável (o cliente decide quando vai pro ar)

A prática dos Baby Steps

Um fato que é bastante interessante é a velocidade dos times ágeis: é um mito achar que times ágeis programam numa correria desatada e que agilistas trabalham num ritmo barulhento, frenético e alucinado. Muitas pessoas que tem contato com uma equipe ágil pela primeira vez pode até estranhar a calma, seriedade e tranquilidade que cerca esses times ágeis. Por incrível que isso possa aparecer, times realmente ágeis “aparentam” ser lentos. É comum ver eles mais pensando do que digitando. Porém, cada passo de bebê que eles dão são passos firmes, determinados, bem pensados e principalmente na direção correta. Numa equipe ágil a cada 2 ou 3 horas vários passos pequenos foram dados e cada incremento agrega valor para o projeto.

Chega ser ridículo quando vou conversar com certos empresários e eles dizem: “- Aqui já somos ágeis… é uma correria do cacete aqui!”

Mentalidade Cascateira do Programador

O maior motivador deste artigo é a minha experiência depois de ter ministrado algumas vezes o nosso novo treinamento Domain-Driven Design. Neste treinamento as atividades práticas são orientadas a testes, e tenho visto que alguns alunos penam para completar os exercícios mesmo quando nós já fornecemos os testes automatizados escritos.

Exemplo: Temos um caso de uso com 4 testes falhando para os alunos implementarem em uma hora. São 4 testes de integração, então, basta fazer cada teste passar em 15 minutos que a solucão está completa. Muitos não conseguem fazer isso, e a maior razão é não conhecer sobre Design Incremental. Eles olham aqueles testes falhando e entram em pânico. Saem cuspindo código sem rodar os testes querendo fazer todos eles passarem ao mesmo tempo. Nos últimos 5 minutos da atividade prática ainda está tudo RED e falham miseravelmente. Simplesmente não lhes parece natural fazer o primeiro teste passar, depois o segundo, depois o terceiro e assim sucessivamente. Eles não pensam em passos de bebê e nem em incrementos. Essa minha experiência é bastante relevante para a questão, e define a mentalidade cascateira:

O cascateiro é aquele desenvolvedor que espera que algo milagroso acontecerá nos últimos instantes do prazo, e tudo aquilo que não funciona passará a funcionar, seja por sorte ou intervenção divina.

Essa definição é essencialmente válida mesmo para quem diz que usa ciclos iterativos. Ciclos iterativos não necessariamente são Ágeis, pois se sua equipe ainda sofre para que tudo que foi implementado funcione ao final da iteração você ainda tem mentalidade cascateira, e precisa melhorar suas práticas de teste e integração contínua.

Você que é desenvolvedor pode fazer uma auto-avaliação prática. Acesse meu Github e baixe o projeto exemplo do treinamento Domain-Driven. Em seguida, acesse a classe CadastrarHospedeTest e tente fazer com que estes testes passem num prazo de uma hora. Pegue como exemplo a classe CadastrarQuartoTest. Depois, responda as perguntas:

1. Você conseguiu implementar em uma hora?
2. Quantas vezes aproximadamente você rodou os testes?
3. Você conseguiu fazer os testes passarem um por um?
4. De 0 a 10, como você avalia a confiabilidade do seu código?

Como eu sempre digo: Colar post-its na parede todo mundo quer, mas escrever testes automatizados ninguém quer.