BDD no ciclo de vida do projeto

BDDno Ciclo de Vida do ProjetoAnderson Casimiro

@duodraco

Agenda

Nossa nada mole vida

Quais são os Problemas

E qual seria a solução?

BDD

Ensaio sobre a prática

Considerações

Nossa nada mole vida

Como a área de negócio descreveu o mais novo projeto para a área de tecnologia

… que foi descrito assim pelo cliente

O Gerente de Projetos entendeu assim

… que o Arquiteto prontamente desenhou para todos

Aí o Desenvolvedor fez o projeto assim…

… que foi planejado para ser testado assim…

… e o pessoal de infraestrutura provisionou assim

O pessoal do Marketing começou a vender assim

… e o projeto foi entregue assim, só que algum tempo depois…

A documentação ficou assim…

A acabou custando mais ou menos isso

Quando na verdade, o cliente queria algo assim…

Quais são os problemas?

1.

Testes

Qualidade do Software é fundamental

2.

Documentação

Problemas sobre o Conhecimento do projeto comprometem sua evolução

3.

Conflito

Conflito sobre o entendimento do trabalho a ser feito prejudica o projeto

4.

Comunicação

Todas as áreas interessadas deveriam “falar a mesma língua”

E qual seria a solução?

1.

Ágil

Metodologias de trabalho focadas na entrega de valor e resposta a mudanças

2.

Lean

Entregas granulares garantem a Agilidade e permitem controle fino sobre a Qualidade

2.

Lean

Entregas granulares garantem a Agilidade e permitem controle fino sobre a Qualidade

3.

Processo

Com passo uniforme e conhecido, a expectativa é conhecida por todos os envolvidos

4.

Dialeto

A comunicação deve ser homogênea por toda a cadeia produtiva

Qual a resposta?

42

BDD

Processo Ágil e Lean usando um Dialeto Comum, baseado em BDD

BehaviorDrivenDevelopment

(…) é uma técnica de desenvolvimento Ágil que encoraja colaboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios num projeto de software.(…)

Os focos do BDD são a linguagem e as interações usadas no processo de desenvolvimento de software. Desenvolvedores usam sua língua nativa em combinação com a linguagem ubíqua, que lhes permite concentrar nas razões pelas quais o código deve ser criado, e não em detalhes técnicos, além de minimizar traduções entre a linguagem técnica na qual o código é escrito e outras linguagens de domínio, usuários, clientes, gerência do projeto, etc.

“

User Story+Cenários

Teste dos CenáriosDesenvolvimento

Roteiro de Testes Entrega

Gherkin

É uma linguagem legível para qualquer área com a qual descrevemos o comportamento do software sem detalhar

como este comportamento é implementado.

Funcionalidade: Sacar dinheiro do caixa eletrônico

Um usuário com uma conta no banco poderia sacar dinheiro do caixa.

Dado que el@ tem uma conta e um cartão válido, el@ poderia fazer a transação. O caixa eletrônico liberará a quantia de dinheiro solicitada, devolver o cartão e subtrair o valor do saque do montante da conta

Cenário: Cenário 1 Dado pré condições Quando ações/gatilhos Então resultados

Cenário: Cenário 2 ...

Cenário: Eric quer sacar dinheiro de sua conta pelo caixa eletrônico Dado que Eric tenha um cartão válido E seu saldo seja de $100 Quando ele inserir seu cartão E sacar $45 Então o caixa eletrônico deve liberar $45 E seu saldo deve ser agora de $55

Contexto: Um usuário saca dinheiro de um caixa eletrônico Dado que <Nome> tenha um cartão válido E seu saldo for <SaldoInicial> Quando ele inserir o cartão E saque $<ValorDoSaque> Então o caixa eletronico libera $<ValorDoSaque> E seu saldo deve ser de $<NovoSaldo>

Exemplos: | Nome | Saldo Inicial | ValorDoSaque | NovoSaldo| | Eric | 100 | 45 | 55 | | Pranav | 100 | 40 | 60 | | Ed | 1000 | 200 | 800 |

Ensaio sobre a prática

1.

Visão

Todos os envolvidos conhecem o projeto em linhas gerais. Toda a documentação começa aqui.

2.

Backlog

Formado por User Stories desde o gestor de tarefas. A descrição do Item deve ser feita já em Gherkin

3.

Desenvolvendo

Essa User Story é adicionada ao código do projeto, tornando-se dependência para a construção do mesmo

4.

Integrando

Para que a nova adição continue no fluxo, todas as User Stories devem ser testadas garantindo a integridade do projeto

5.

Testando

Os Testes de Aceitação, ou Homologação, devem considerar o conjunto de User Stories desenvolvidas

6.

Documentando

As User Stories prontas já constituem uma rica documentação, sem qualquer retrabalho

7.

Entregando e Validando

A entrega pode (e deve) ser validada baseando-se na documentação gerada.

Considerações

Com a linguagem uniforme por todo o Ciclo de Vida espera-se que os conflitos de compreensão sejam minimizados e/ou eliminados, com grande ganho de produtividade.

“

Gherkin

- Documentação- Testes- Compreensão- Comunicação- Validação

A cor do sangue é a mesma para todos

duodraco@gmail.comduodra.co

slideshare.net/duodraco