O slideshow foi denunciado.

BDD no ciclo de vida do projeto

343 visualizações

Publicada em

Analisando o Ciclo de Vida de projetos de software identificamos claramente problemas causados basicamente pela comunicação deficiente no levantamento de funcionalidades do projeto e que atravessam todo o projeto, acarretando principalmente na qualidade do projeto.
O BDD, somado a algumas técnicas, pode eliminar esses problemas com simplicidade.

Palestra apresentada na trilha Arquitetura PHP no TDC 2017.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

BDD no ciclo de vida do projeto

  1. 1. BDD no Ciclo de Vida do ProjetoAnderson Casimiro @duodraco
  2. 2. Agenda Nossa nada mole vida Quais são os Problemas E qual seria a solução? BDD Ensaio sobre a prática Considerações
  3. 3. Nossa nada mole vida
  4. 4. Como a área de negócio descreveu o mais novo projeto para a área de tecnologia
  5. 5. … que foi descrito assim pelo cliente
  6. 6. O Gerente de Projetos entendeu assim
  7. 7. … que o Arquiteto prontamente desenhou para todos
  8. 8. Aí o Desenvolvedor fez o projeto assim…
  9. 9. … que foi planejado para ser testado assim…
  10. 10. … e o pessoal de infraestrutura provisionou assim
  11. 11. O pessoal do Marketing começou a vender assim
  12. 12. … e o projeto foi entregue assim, só que algum tempo depois…
  13. 13. A documentação ficou assim…
  14. 14. A acabou custando mais ou menos isso
  15. 15. Quando na verdade, o cliente queria algo assim…
  16. 16. Quais são os problemas?
  17. 17. 1. Testes Qualidade do Software é fundamental
  18. 18. 2. Documentação Problemas sobre o Conhecimento do projeto comprometem sua evolução
  19. 19. 3. Conflito Conflito sobre o entendimento do trabalho a ser feito prejudica o projeto
  20. 20. 4. Comunicação Todas as áreas interessadas deveriam “falar a mesma língua”
  21. 21. E qual seria a solução?
  22. 22. 1. Ágil Metodologias de trabalho focadas na entrega de valor e resposta a mudanças
  23. 23. 2. Lean Entregas granulares garantem a Agilidade e permitem controle fino sobre a Qualidade
  24. 24. 2. Lean Entregas granulares garantem a Agilidade e permitem controle fino sobre a Qualidade
  25. 25. 3. Processo Com passo uniforme e conhecido, a expectativa é conhecida por todos os envolvidos
  26. 26. 4. Dialeto A comunicação deve ser homogênea por toda a cadeia produtiva
  27. 27. Qual a resposta? 42 BDD Processo Ágil e Lean usando um Dialeto Comum, baseado em BDD
  28. 28. Behavior Driven Development
  29. 29. (…) é 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. “
  30. 30. User Story +Cenários Teste dos Cenários Desenvolvimento Roteiro de Testes Entrega
  31. 31. Gherkin É uma linguagem legível para qualquer área com a qual descrevemos o comportamento do software sem detalhar como este comportamento é implementado.
  32. 32. 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 ...
  33. 33. 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
  34. 34. 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 |
  35. 35. Ensaio sobre a prática
  36. 36. 1. Visão Todos os envolvidos conhecem o projeto em linhas gerais. Toda a documentação começa aqui.
  37. 37. 2. Backlog Formado por User Stories desde o gestor de tarefas. A descrição do Item deve ser feita já em Gherkin
  38. 38. 3. Desenvolvendo Essa User Story é adicionada ao código do projeto, tornando-se dependência para a construção do mesmo
  39. 39. 4. Integrando Para que a nova adição continue no fluxo, todas as User Stories devem ser testadas garantindo a integridade do projeto
  40. 40. 5. Testando Os Testes de Aceitação, ou Homologação, devem considerar o conjunto de User Stories desenvolvidas
  41. 41. 6. Documentando As User Stories prontas já constituem uma rica documentação, sem qualquer retrabalho
  42. 42. 7. Entregando e Validando A entrega pode (e deve) ser validada baseando-se na documentação gerada.
  43. 43. Considerações
  44. 44. 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. “
  45. 45. Gherkin - Documentação - Testes - Compreensão - Comunicação - Validação
  46. 46. A cor do sangue é a mesma para todos
  47. 47. duodraco@gmail.com duodra.co slideshare.net/duodraco

×