BDD - A técnica que facilita entregar software que REALMENTE atende o negócio

1. Behavior Driven Development
Marcelo Neves

2. BDD é sobre testes?

3. BDD junta os dois mundos

4. Princípios do BDD
1. O suficiente é o suficiente
2. Entregar valor para as partes interessadas
3. Tudo é comportamento

5. BDD TDD Foco no negócio Foco no design do código

6. Descrevemos o comportamento do sistema
com cenários de critérios de aceite, mas
quando vamos implementar seus detalhes e
testar o como ele implementa essa
funcionalidade, usamos TDD.
BDD & TDD

7. Que problemas BDD resolve?

8. As pessoas do negócio enxergam
claramente o que será construído.

9. O Gme de desenvolvimento entendem as
necessidades do negócio que devem ser
atendidas.

10. As pessoas do negócio entendem os
desafios técnicos na implementação dos
requisitos elicitados.

11. Elementos Chave

12. Meta de Negócio

13. Uma meta de negócio é a
força direcionadora do
projeto.

14. Muitas funcionalidades são sinônimo
de alto valor entregue?

15. Mapas de Impacto
Para explorar hipóteses uKlizamos mapas de
impacto que nos ajudam a visualmente
idenKficar o porquê, quem, como e quais
problemas estamos nos confrontando.

16. Exemplo de mapa
mental

18. Por que?
• Por que estamos fazendo isso?
• Quais são os objeKvos de negócio que estamos
tentando alcançar?
• É o objeKvo que estamos tentando alcançar.
• Geralmente o objeKvo está na cabeça das partes
interessadas sêniores.
• Geralmente quando comunicado é feito
vagamente.

19. Por que?
• Saber o porquê é a chave para tomar boas
decisões sobre escopo, custo e etc.
• Colocar o porquê como a ideia central do
mapa de impacto garante que todos sabem o
que estão realmente fazendo.
• Responder ao porquê permite que partes
interessadas alinhem expectaKvas.

20. Por que?
• Metas de negócios não são sobre contruir
produtos de soXware.
• Metas de negócios explicam porque algo é úKl.
• Metas de negócios apresentam o problema que
será resolvido.
• Metas de negócios não falam da solução.
• Exemplo: aumentar o faturamento em 6%.

22. Quem?
• Primeiro nível do mapa de impacto.
• Quem pode produzir o efeito desejado?
• Quem pode ser um obstáculo?
• Quem é o usuário da solução?
• Quem será impactado posKvamente e
negaKvamente?

24. Como?
• É o segundo nível do mapa de impacto.
• Como devem os atores mudar seu
comportamento?
• Como os atores podem nos ajudar a alcançar a
meta de negócio?
• Como os atores podem obstruir o sucesso da
iniciaKva?
• Esses são os impactos que estamos tentando
criar.

26. O Que?
• É o terceiro nível do mapa de impacto.
• Somente depois de entender a meta do negócio,
quem é afetado e como será feito, é que
podemos falar de ecopo.
• O que podemos fazer para suportar os impactos
exigidos?
• Esses são os entregáveis, funcionalidades e
aKvidades organizacionais.

28. Mapa de Impacto – Passo a passo
1. Preparação
1. Definir metas de negócios
2. Definir métricas
3. Planejar primeiro marco

29. Mapa de Impacto – Passo a passo
2. Mapeamento
1. Desenhar ideia central
2. IdenKficar os atores
3. IdenKficar os impactos
4. IdenKficar os entregáveis

30. Mapa de Impacto – Passo a passo
3. Refinamento
1. Achar alternaKvas
2. IdenKficar prioridades
3. Ganhar ou aprender

31. Entendimento das necessidades através de exemplos

32. Exemplo:
Todo cliente deve apresentar sua idenGficação
para comprar um linha telefônica.

33. Exemplo:
Considerando a nova determinação da Anatel,
com o objeGvo de evitar problemas de
segurança, todo cliente deve apresentar sua
idenGficação para comprar um linha
telefônica.

34. Design orientado ao usuário

35. Foco no comportamento dos usuários
Não é apenas discuKr o comportamento das
pessoas, mas sim levar em consideração seus
comportamentos sob o ponto de vista delas.

36. Linguagem Ubíqua

37. BDD foca em eliminar problemas de
comunicação através de uma conversação
baseada em exemplos.

38. Dado que <pré-condições para que ocorram a
ação do interesse do cenário>
Quando <eventos que devem ocorrer para que
o cenário seja executado>
Então <expectaKvas a respeito dos resultados
em função da execução dos eventos do
cenário>

39. Exemplo:
Dado que o cliente tenha feito uma compra
superior a R$ 1.000,00
Quando o cliente devolver o produto
Então ele deve ser ressarcido em R$ 1.000,00

40. BDD & SCRUM
Menos erros de compreensão e interpretação das histórias de usuário.
Requisitos funcionais e requisitos não funcionais são agora comportamentos
funcionais do soXware e critérios de aceitação.
Formato de comunicação comum a todos envolvidos, facilitando a compreensão
por parte de todos.
Todos ficam cientes dos comportamentos serão aceitos pelos usuários com
antecedência.
O Kme entende como os comportamentos são relacionados, evitando confusão.
Reuniões de planejamento, revisão e diárias mais eficazes.

41. É um grande erro achar que a escrita desses
cenários deve ser feito apenas por uma única
pessoa.

42. Você conhece os Três Amigos?
Parte interessada do negócio
Desenvolvedor
Testador

44. O cliente deve escrever os cenários.

45. O cliente e o gestor não gostam de testes.

46. Não transforme tudo em testes.

47. Evite no BDD os detalhes de implementação.
Foque no “O quê” e não no “Como”.

48. Marcelo Neves
marcelo@anelox.com
• +20 anos de experiência
• Palestra e ensina
• Faz análise de negócios
• Lidera projetos
• Escreve
• Preside o Capítulo Rio de Janeiro do
InsKtuto Internacional de Análise de
Negócios
• Escreveu o BABOK v3