O documento descreve a abordagem de Desenvolvimento Orientado a Comportamento (BDD) adotada em um projeto da Softplan, incluindo os papéis, benefícios, desafios e evolução do uso de BDD na empresa. O projeto usou BDD para documentar e desenvolver todo o back-end com sucesso dentro do prazo e orçamento. Isso melhorou a comunicação entre times e validou os requisitos de negócio.

2. Agenda
Cenário Atual
O que é o BDD
Composição do BDD
Projeto Real da Softplan
Papéis no BDD
Benefícios
Dificuldades
Ferramentas
Acompanhamento do projeto
Evolução do BDD na Softplan

3. Cenário Atual

4. Somente eu
posso fazer!

5. Documentação

6. Valida ai!

7. e no final...

8. Como é possível melhorar?
BDD

9. O que é o BDD
Behavior Driven Development – Desenvolvimento orientado ao
comportamento
É uma técnica de desenvolvimento ágil que estimula a
COLABORAÇÃO e COMUNICAÇÃO entre os participantes do
projeto: cliente, DEVs, gestores, QAs, pessoas não técnicas e de
negócios
Linguagem natural
Foco no COMPORTAMENTO do Sistema
Documentação única entre os participantes do projeto

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

11. Descrições simples de uma funcionalidade
Promover um diálogo, 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 interessado na funcionalidade
Ação/Função – É o que o ator quer fazer.
Utilizando aquela ação ele espera alcançar um
objetivo dentro do sistema
User Stories

12. Critérios de Aceite
Exemplo:
Somente colaboradores que informaram o CPF podem ser cadastrados
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
US.
O objetivo dessa lista é validar se a Feature foi implementada de
acordo com o que o analista/cliente deseja.

13. 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

14. GHERKIN

17. Mas isso funciona???

18. Projeto na Softplan
Projeto de aproximadamente 13 mil horas
Todo back-end foi desenvolvido apoiado pelo BDD
Primeiro projeto de BDD da Softplan
Projeto estratégico para a empresa
Projeto não tinha especificação de negócio
Equipe de 8 pessoas
2 Analistas de Negócio
4 DEVs
1 Testador
1 Arquiteto

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

21. 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

22. 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 da 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

23. Dificuldades
Produtividade
Curva de aprendizado (em média 2 semanas)
Falta/Dificuldade na padronização da escrita - Gera retrabalho
Difícil Rastreabilidade
Falta de ferramentas mais adequadas para escrita
ALTO custo para desenvolvimento, principalmente no front-end

24. FERRAMENTAS

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

27. Acompanhamento

28. O BDD nos
permitiu este
final!!!

29. Evolução do BDD na Softplan
Comportamentos de APIs do sistema são desenvolvidos com apoio do BDD
Mantém a qualidade do código a cada geração de versão
User Stories e critérios de aceite descritos e planejados em ferramentas internas
Melhora da integração de novas pessoas ao negócio e ao sistema
Investimento em novas demandas
Utilizado como documentação junto com protótipos

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

34. Obrigado!
allan.rett@gmail.com
/in/allan-ferreira
Contatos:
allanrett