Embed Size (px)
Citation preview
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
