Tempos atrás, como ouvinte em uma reunião sobre métodos ágeis, vivenciei a frase que, para mim, traduz a realidade ágil do país.
Um potencial cliente, incentivado pelo seu gerente de TI, nos procurou para entender o que era SCRUM. E após explicar as atividades de sua empresa, calmamente nos desafia:
– Por favor, me convençam por que devo usar esse tal de SCRUM ou métodos ágeis!
Afff… Somos os tais “gurus da agilidade”, lutamos para aproximar as áreas de negócio das áreas de desenvolvimento de software, entendemos que essa prática agrega valor real a qualquer negócio. Mas convencer…. Ah, convencer! Quantos nos solicitam serem convencidos!
Ouvi um suspiro profundo e um discurso convicto (eu que conheço o tom de voz, o sabia, também entediado), um “Adaptworker” contaria a história da agilidade no mundo e no Brasil, até os benefícios de se iniciar essa aproximação de áreas, pela disciplina de entregas frequentes de valor, pelo SCRUM.
E eu paralelizei o raciocínio, comecei, em minha mente, a pensar em BDD. Ou seja, viajei.
“Como seria simples e lógico colocar em histórias de usuários e fazê-las testáveis, convencer aquele empresário, sobre os benefícios da agilidade para TODA a empresa dele.
Segundo confirmamos na Wikipédia: Behavior Driven Development (BDD ou ainda uma tradução Desenvolvimento Guiado por Comportamento) é uma técnica de desenvolvimento Ágil que encoraja a colaboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios num projeto de software. Foi originalmente concebido em 2003, por Dan North como uma resposta à Test Driven Development (Desenvolvimento Guiado por Testes), e tem se expandido bastante nos últimos anos.
Mas na minha mente eu criava o meta-BDD, onde o desenvolvimento e as influências de comportamento dos indivíduos que compõe aquela empresa seriam orientados a mudanças pela implantação do BDD na área de construção do software, produto chave da empresa.
O BDD me diz que, em uma linguagem que os idealizadores de um produto entendem, facilmente eu posso criar testes de comportamento de uma unidade deste produto, e um conjunto de testes interligados garantem a qualidade do software produzido.
Teste de unidade garante a qualidade de um produto de software inteiro?
Resposta objetiva: Não. Mesmo porque BDD não é sobre teste de unidade, é sobre comportamento. E como desenhar software orientado por um comportamento esperado?
Precisamos aprender sobre as vantagens de praticar BDD.
Testar é a parte óbvia. E óbvio é o benefício de “refatorar” o código no sentido de deixá-lo funcional, com assertividade e clareza, código limpo e simples. E refatoramentos podem ser feitos com segurança, pois os testes detectarão falhas.
BDD é inteligível para um leigo.
Aumenta a integração entre o idealizador do produto, os testadores e os desenvolvedores, pois todos falam a mesma língua.
Mesmo quando testadores e desenvolvedores são de equipes diferentes, eles podem trabalhar juntos para definir o design do que vai ser feito. Valorizando o Pair Programming.
Escrever User Stories é uma ótima forma de fazer isto, pois pode ser feito com a ajuda do usuário ou pelo menos validada com o usuário que vai entender o que está escrito.
BDD nos ensina mais sobre histórias de usuários e User Stories servem como Test Case, Código do teste automatizado e Design, tudo junto.
Do ponto de vista de desenvolvedores vemos:
– O código gerado tem menor acoplamento e maior coesão;
– O código gerado tem uma maior qualidade por ter alta porcentagem de cobertura de teste;
– É possível saber, claramente, quando uma tarefa foi concluída, pois o teste correspondente estará passando;
– Testes de regressão automatizados existem sem nenhum esforço adicional;
– A maior parte dos bugs é encontrada mais cedo, o que torna mais barato corrigí-los;
E observando todas essas vantagens, ‘re-concluo’ que TODO COMPORTAMENTO dos envolvidos e comprometidos no desenvolvimento deste produto será afetado.
Chegamos ao meta-BDD – paradigmas serão quebrados, agilidade será praticada, valores serão questionados e processos serão alterados.
E aterrissando na reunião com cliente – lembram? – ouço:
– Então SCRUM não é apenas sobre software, pode ser utilizado para influenciar a minha empresa inteira?
E eu quase gritei: “Isso!!! Estamos falando além do SCRUM, estamos falando sobre meta-BDD, que nasce no desenvolvimento de software ágil e irradia para todos.”
O cliente estava convencido e feliz com o novo horizonte! Eu apenas sorri.
