O documento discute o uso do Behavior Driven Development (BDD) para melhorar a comunicação e o valor entregue aos clientes em projetos de desenvolvimento de software. O BDD promove a colaboração entre todos os participantes do projeto, utilizando uma linguagem unificada que facilita a descrição de funcionalidades, critérios de aceite e cenários. Um projeto real é apresentado como exemplo, destacando os benefícios e desafios da implementação do BDD, como melhor entendimento das demandas e engajamento da equipe.

1. Utilizando BDD para melhorar a
comunicação e entregar valor aos clientes

2. Allan Rett
Ferreira
• Ciência da Computação;
• Pós Engenharia Software e Banco de dados;
• MBA Gerenciamento de Projetos;
• Analista de sistemas.
Guilherme
Azevedo Cardozo
• Ciência da Computação;
• Pós Engenharia de Software;
• MBA em Gestão de Processos de Negócios – BPM;
• MBA Gerenciamento de Projetos;
• Especialista em processos;
• Instrutor / Professor;
• Grupo de pesquisa na UFSC;
• Analista de Processos e Qualidade.
allan.rett@gmail.com
/in/allan-ferreira
guilhermecardozo@gmail.com
/in/guilherme-azevedo-cardozo

3. Cenário Atual

4. Somente eu posso fazer!

5. Documentação

7. ... e no final

9. DINÂMICA - O MEU PRODUTO!!
1. Pegue uma folha tamanho A4.
2. Dobre o lado maior ao meio.
3. Com a folha ainda dobrada, repita o processo 2, dobrando
novamente o lado maior ao meio;
4. Corte o canto que contiver as duas dobras, medindo um
centímetro em cada lado;
5. Mantenha o formato obtido, repita o processo 3 e
novamente, o processo 4;
6. Desdobre a folha e verifique o produto acabado.

10. REFLEXÃO
Comunicação
Requisitos
Compreensão
Recursos
Prazos

11. Como é possível resolver???

12. O que é o BDD
• Behavior Driven Development – Desenvolvimento orientado a
comportamento
• É uma técnica de desenvolvimento ágil que estimula a COLABORAÇÃO entre os
participantes do projeto, desenvolvedores, gestores do projeto, pessoas de
qualidade, pessoas não técnicas e de negócios.
• Evolução do TDD
• Linguagem natural e unificada para cliente e time de desenvolvimento
• Foco no COMPORTAMENTO do sistema
• Documentação que vira teste e código

13. Composição do BDD
User Stories
Features
Critérios de Aceite
Cenários
Funcionalidades que serão desenvolvidas
Exemplo:
Cadastrar Usuário
Emitir relatório
Executar integração

14. Critérios de Aceite
Cenários
User Stories Descrições simples que descrevem uma funcionalidade
Promover um dialogo, uma conversa
Resultado – É o que o ator
espera que aconteça ao realizar
a ação. Também pode ser visto
como justificativa
Como um
<PAPEL>
eu
posso/gostaria/devo
<FUNÇÃO>
para/de <RESULTADO para o
NEGÓCIO>
Papel – O proprietário da User
Story. De forma simplista é o
interessado naquela
funcionalidade
Ação/Função – É o que o ator
quer fazer. Utilizando aquela
ação ele espera alcançar um
objetivo dentro do sistema

15. Critérios de Aceite
Cenários
Os Critérios de Aceite são representados por uma
lista de itens de negócio que expressam formas de
usar a funcionalidade implementada em uma
História.
O objetivo dessa lista é validar se a Feature foi
implementada de acordo com o que o analista / cliente
deseja.
Exemplo:
Somente colaboradores que informaram o CPF podem ser cadastrados

16. Cenários
Os cenários descrevem as ações que serão aferidas
e testadas. Eles devem conter passos lógicos e
simples de como obter um resultado específico a
partir de uma sequência de ações.
Dado que – São as pré-condições para
executar o cenário
Quando – O que eu quero realizar, passos do
cenário
Então – É o resultado esperado pela
execução do cenário

17. Dada uma condição
Quando algo
acontecer
Então o resultado será X
e nada além de X
GHERKIN

19. Boas práticas....

20. MAS, ISSO É POSSÍVEL?

21. Projeto REAL
Projeto de aproximadamente 13 mil horas
Todo back-end do projeto foi feito utilizando o BDD
Primeiro projeto de BDD da Softplan
Projeto não tinha especificação de negócio
Equipe de 8 pessoas
2 Analistas
4 Implementadores
1Testador
1 Arquiteto

22. Papéis no BDD
Analista de Negócio
Levantamento das necessidades e funcionalidades
Levantamento das regras de negócio
Escrita das User Stories
Documentação do comportamento
Validação do comportamento
Levantamento dos cenários de teste
Validação de escrita/qualidade
Analista de Teste
Documentação do comportamento
Validação do comportamento
Levantamento dos cenários de teste
Validação de escrita/qualidade
Analista
Implementador
Implementa as features do BDD
Validação do comportamento

24. Resultados do Projeto
Nenhum erro de negócio
Dentro do Prazo
Dentro do Custo
Entrega com Qualidade – Somente 2 erros de Front-end
Desenvolvimento técnico e de negócio da Equipe
Maior engajamento da Equipe

25. Benefícios
Melhor entendimento da demanda, sem dúvidas do que deve ser feito
Pequenas reuniões (feature review) para validação das features
Melhora a comunicação entre todos participantes do projeto
Definição do comportamento do sistema, por meio de exemplos reais
Para o analista de negócio é uma VALIDAÇÃO de toda a análise, pois ajuda o
analista a verificar furos de negócio e furos na sua especificação
Medição do progresso do projeto através das features implementadas

26. Dificuldades
Produtividade
Curva de aprendizado (em média 2 semanas)
Falta/Dificuldade na padronização da escrita - Gera retrabalho
As regras de negócio não ficam explicitas nos cenários do BDD
Difícil Rastreabilidade
Falta de ferramentas mais adequadas para escrita
ALTO custo para desenvolvimento, principalmente no front-end
NÃO substituiu a documentação “formal” do cliente

27. FERRAMENTAS

28. Pickles
http://www.picklesdoc.com/

29. Acompanhamento

30. O BDD nos
permitiu este
final!!!

31. SEJA UM
www.softplan.com.br
facebook.com/softplanonline
linkedin.com/softplan
@softplan
SOFTPLAYER!

32. Contatos:
allan.rett@gmail.com
/in/allan-ferreira
guilhermecardozo@gmail.com
/in/guilherme-azevedo-cardozo