Bom galera, hoje vou falar um pouco sobre o BDD no Scrum e como estou utilizando em projetos aqui na Sciensa.

Minha experiência como desenvolvedor Java utilizando BDD para meus testes comportamentais do sistema vem me dando uma luz. As formas como levantávamos as histórias com o P.O. eram muitas vezes massiva e acabava por faltar itens importantes para o projeto.
O BDD facilitou ao saber em detalhes o que deveria ser feito, seus cenários e o que era esperado.
Um único “documento” consistente tanto para o P.O. quanto para o time. Não seria perfeito?
Foi assim que o BDD surgiu dentro dos projetos no qual trabalho e até hoje é uma poderosa ferramenta que utilizamos e que se mostra um diferencial dentro dos projetos da empresa.
Mas o que é o BDD?

Behavior-Driven Development ou Desenvolvimento Orientado por Comportamento:
- Foco do comportamento que o sistema deve ter;
- Visa um desenvolvimento focado em testes;
- Usa uma linguagem comum (como a Ubiquitous Language do DDD);
- Beneficia tanto o P.O. do projeto quanto o time;
- Comporta diversos cenários;
- Possui aspectos do DDD e conceitos fundamentais do TDD.
Ou seja, as narrativas são as histórias com seus devidos cenários, exemplos:
- Narrativa/História: Cadastro Alunos
- Para meu sistema de gerenciamento do Aeroclube
- Eu, como funcionário da secretaria
- Desejo poder realizar cadastros de novos alunos no sistema
Exemplo:
Cenário I: Cadastro de Aluno
- Dado que um funcionário selecione a opção Cadastrar Aluno
- Quando clicar no menu
- Então deverá ser aberta a tela com os dados para efetuar o cadastro do aluno e os botões Salvar e Cancelar.
Utilizando das palavras chaves (em negrito) o P.O. vai criando as histórias que ele precisa com seus cenários, pontos positivos desta ação:2
- Cliente vai vendo a cada cenário a complexidade do sistema que ele tem em mente;
- Cliente vai evoluindo o próprio sistema e criando ou removendo funcionalidades;
- Time durante a planning tem uma visão mais clara do que pode ser desenvolvido;
- Erros de compreensão e interpretação são eliminados;
- Requisitos funcionais e não funcionais se tornam comportamentos funcionais e critérios de aceite;
- Vocabulário comum a todos;
- Equipe entende como os comportamentos estarão relacionados entre si;
- Agilizam as reuniões de Daily, Review e Planning.
Nosso dia a dia
Na Sciensa, toda vez que um membro da equipe ou um cliente entra, passamos um treinamento sobre SCRUM e BDD. Um mentor fica um tempo auxiliando o cliente a escrever os BDDs até que o mesmo já caminhe sozinho. Estes BDDs além de servir como histórias ainda servem para montagem de testes no Frontend e no Backend com Yadda e Cucumber no caso de um tester no time, ou o próprio cliente utiliza o mesmo para validar a entrega do time.
Os BDDs nos fornecem um documento único e poderoso para o P.O., Testers, Programadores com uma linguagem simples e objetiva.
Referências:
BREGAIDA, Eduardo. DDD+BDD+TDD+SCRUM. Disponível em http://slides.com/eduardobregaida/deck#/ – Acesso em 01 de dezembro de 2017
BREGAIDA, Eduardo. Do estudo ao sucesso – Passos para sua conquista. Disponível em: https://pt.slideshare.net/eduardo.bregaida/ – Acesso em 01 de dezembro de 2017
BREGAIDA, Eduardo. Scrum – Passos e Desafios. Disponível em: http://javawora.blogspot.com.br/search/label/Scrum – Acesso em 01 de dezembro de 2017
MALIK, Zia. Value of Behavior-Driven Development for Backlog Refinement in Scrum. Disponível em: http://www.scrumalliance.org/articles/500-value-of-behaviordriven-development-for-backlog-refinement-in-scrum – Acesso em 01 de dezembro de 2017
Sensacional! Creio que é por este caminho que devemos ir.
Não só desenvolvedores, mas TODO MUNDO que trabalha com PRODUTOS tem muito a ganhar com esse mindset.
Documentação em massa com milhões de páginas que só burocratiza e dificulta a evolução do produto devem morrer para dar lugar a esse tipo de abordagem: informações concisas que une de verdade todos envolvidos no produto falando a “mesma lingua”.
Matando de vez o problema da “torre de babel” que temos a décadas.
Parabéns pelo artigo!!!