DDD + BDD + TDD + Scrum
4 gostaram2,911 visualizações
Brian, dono de um aeroclube, quer um sistema de gerenciamento para o seu negócio. Ele pede ajuda a Bregaida, que sugere utilizar DDD, BDD, TDD e Scrum para desenvolver o sistema de forma ágil e iterativa, garantindo que atenda às necessidades do domínio do aeroclube. Bregaida explica os principais conceitos e práticas desses frameworks para desenvolvimento de software.
DDD + BDD + TDD + Scrum
- 1. DDD + BDD + TDD Eduardo Bregaida eduardo.bregaida@sciensa.com & SCRUM
- 2. Brian, o dono de um importante Aeroclube da cidade teve uma ideia em um momento de inspiração.
- 3. Eu poderia fazer um sistema para meu aeroclube e otimizar meu tempo.
- 4. Mas como? Vou chamar meu amigo Bregaida para resolver isso
- 5. Seguinte Bregaida quero um sistema que faça todo gerenciamento do meu Aeroclube
- 6. Quero todos os Cadastros Relatórios, Notas e Faltas e valores pagos...
- 8. Pensando...
- 10. Pensando... Classe Aluno Aluno extends Pessoa
- 11. Pensando... Classe Aluno Aluno extends Pessoa Relatorio em IReport
- 12. Pensando... Classe Aluno Aluno extends Pessoa Relatorio em IReport Java com Spring...
- 13. Pensando... Classe Aluno Aluno extends Pessoa Relatorio em IReport Java com Spring Maven
- 14. Pensando... Classe Aluno Aluno extends Pessoa Relatorio em IReport Java com Spring Maven JQuery
- 15. Pensando... Classe Aluno Aluno extends Pessoa Relatorio em IReport Java com Spring Maven JQuery Contas a Pagar e Receber
- 16. Pensando... Classe Aluno Aluno extends Pessoa Relatorio em IReport Java com Spring Maven JQuery Contas a Pagar e Receber Você já tem um Web Server ou um Web Container para sua aplicação?
- 17. ...
- 18. Mas que Bodega é essa que você está falando?
- 19. Eu não estou entendendo nada, eu só queria um sisteminha fácil...
- 22. Negócio Complexo
- 25. Negócio Complexo Pessoas Problema Real Linguagem de Negócio
- 26. Negócio Complexo Pessoas Domain Problema Real Linguagem de Negócio
- 27. Conversa Sobre o Para criar um domínio sistema
- 28. Conversa Sobre o Para criar um domínio sistema Precisamos falar a mesma língua!
- 30. Tenho um curso onde cada aluno é preparado para se tornar um piloto em uma determinada categoria.
- 31. Um Aluno tem Nome, CPF, RG, Endereço, Telefone, código ANAC que é a identificação deste aluno
- 33. Ele terá uma Categoria que pode ser: Piloto Privado ou Piloto Comercial
- 35. Poderei buscar o aluno por nome ou por CPF ou ainda pelo código ANAC
- 37. Com esse repositório parece que ficou mais fácil, dá para saber todos os alunos da mesma categoria?
- 44. Como implementar o repositório?
- 47. Nossa esqueci, quero que liste todos alunos de uma categoria.
- 51. -Driven Design Voltado (driven) totalmente ao problema a ser resolvido (domain) Ubiquitous Language Funciona muito bem com Agile Modelos ricos (não anêmicos) Nomes importam! Domain
- 52. Não importa a tecnologia. O que importa é o domain.
- 53. BDD
- 54. O que é BDD?
- 55. O que é BDD? • Foca no comportamento do sistema; • Visando desenvolvimento voltado a testes; • Usam uma linguagem comum como visto no DDD; • Beneficia os desenvolvedores e os usuários de negócio; • Comporta vários cenários; • Não apenas o que uma determinada função deve fazer; • Possui aspectos do DDD e conceitos fundamentais do TDD.
- 56. Como fazer? • Narrativa/Estória: (Nome) • Para ( Valor ao Negócio) • Eu, como (Papel) • Desejo poder realizar (Funcionalidade) • Story: … • In order to … • As a … • I want to …
- 57. Exemplo • Narrativa/Estória: Cadastrar Alunos • Para meu sistema de gerenciamento do Aeroclube • Eu, como funcionário da secretaria • Desejo poder realizar cadastros de novos alunos no sistema
- 58. O que mais? • Cenários: (Nome) • Dado que (Estado inicial do sistema) • Quando (Ação a ser realizada) • Então (O que deve fazer após a ação) • Scenario: … • Given a … • And … • When … • Then … Mais?
- 59. Exemplo • Cenário I: Cadastro de Aluno • Dado que um funcionário selecione a opção Cadastrar Aluno • Quando clicar no menu • Então deverá ser aberta a tela com os dados para efetuar o cadastro do aluno e os botões Salvar e Cancelar.
- 61. O que é TDD ou Test Driven Development? • É uma técnica de desenvolvimento de software baseada em um ciclo curto de repetições; • Escrevendo seus testes antes de escrever o código de produção; • Ao escrever primeiro os testes: • Garantimos uma boa qualidade no código (mínimo de sujeira e códigos esquecidos que nunca serão utilizados); • Garantimos o funcionamento do que está sendo implementado; • Não precisamos saber tudo de uma vez, conforme eu desenvolvo um teste, crio e implemento as classes que serão utilizadas.
- 62. TDD - Test Driven Development • Escreva um teste que falhe; • Faça-o passar da maneira mais simples possível; • Refatore o código. • É conhecido como Ciclo Vermelho-Verde-Refatora (Red-Green- Refactor). Mas é muito fácil
- 65. It's Amazing
- 66. Mas como vou saber o andamento do meu sistema?
- 67. Com SCRUM
- 68. Mais Coisa???
- 69. Existem dois tipos de Processos: • Processos Definidos • Processos Empíricos
- 70. Processos Definidos São aqueles que determinam o que deve ser feito, quando e como. Quem já trabalhou com o “início e fim do projeto” sabe que a utilização de um processo definido não garante o sucesso.
- 71. Processos Empíricos São aqueles que não se conheçam todas as variáveis de entrada para que possa estabelecer um processo repetível. O Scrum, parte do princípio que nem todas as características do produto são conhecidas na análise e que provavelmente os requisitos mudarão com o passar do tempo.
- 72. Exemplo do dia a dia É como dirigir um carro, nunca se traça um destino em que a chegada é em linha reta, sempre há pequenas correções até seu destino.
- 73. Conclusão Processos empíricos baseados em inspeção e adaptação devem ser utilizados sempre que os processos definidos não forem adequados devido a complexidade do projeto.
- 74. O que é SCRUM? Processo de desenvolvimento iterativo e incremental que pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa; Criado por Jeff Sutherland e Ken Schwaber na década de 90;
- 75. O P.O. O Scrum Master O Time Papéis no SCRUM
- 76. Product Owner (P.O.) • Responsável por garantir o Retorno sobre o Investimento (ROI) • Conhece as necessidades do que precisa ser feito • Define os itens do Product Backlog • Prioriza os itens na Sprint Planning Meeting
- 77. Scrum Master • Garante o uso da Metodologia • É um líder e um facilitador • Precisa tirar da frente qualquer impedimento
- 78. Time • Função do SCRUM Team é ser auto-gerenciado • Define as metas dos Sprints • Produz com qualidade e valor para o P.O.
- 79. Fases do Scrum • Product Backlog • Sprint Planning Meeting • Planning Poker • Daily Scrum • Sprint Review Meeting • Sprint Retrospective
- 80. Product Backlog • Lista com as funcionalidades para o produto • O conteúdo é definido pelo P. O. • Não necessita estar completo • Com o tempo o Product Backlog cresce ou diminui dependendo do que o P.O. necessita;
- 81. Sprint Planning Meeting • Reunião com o P.O., Scrum Master e Scrum Team • P.O. descreve as funcionalidades • A equipe questiona • No final é gerado o Sprint Backlog • Scrum Team e o P.O. definirão o objetivo
- 82. Planning Poker • Estimar o esforço das funcionalidades • Números menores mais simples • Números maiores são mais complexos • Coringas: • Café - 15 minutos para uma pausa • ? - Não foi entendido alguma funcionalidade falada
- 83. O Sprint • Funcionalidades escolhidas na Sprint Planning Meeting na Coluna À Fazer • É definido um prazo para o Sprint (2 ou 4 semanas) • O prazo é mantido até o final do projeto • Considera-se finalizado com Sucesso: • Quando todas as tarefas estiverem na Coluna Finalizado • Finalizado com falha: • Quando o tempo estourar (2 semanas por exemplo) e/ou funcionalidades mal implementadas e sem qualidade
- 84. Quadro KANBAN • No quadro é colocado o andamento do Sprint • Os Post its são importantes • Se coloridos facilitam a visualização • Também serve para saber o que está fazendo • Evitem Softwares para o KANBAN
- 86. Daily Scrum • Reunião em Pé de 15 minutos • Deverá ser respondida apenas 3 perguntas: • O que você fez ontem? • O que você fará hoje? • Há algum impedimento no seu caminho? • É uma reunião focada • Não é para resolver problemas
- 87. Burndown Chart
- 88. Sprint Retrospective • Ocorre ao final do Sprint • Utilizado para identificar o que funcionou bem • Também é utilizado para verificar o que poderia ser melhorado • E quais ações serão tomadas para melhorá-lo
- 89. Sprint Review Meeting • No final de cada Sprint Retrospective é feito um Sprint Review Meeting • É mostrado o que foi alcançado no Sprint • Nesta reunião estará o P.O., Scrum Team e Scrum Master • O mais importante é que o objetivo esteja realizado
- 90. WOWWWW Então a cada 2 semanas terei um pedaço do meu sistema?
- 91. E eu ainda vou poder alterar o escopo quando precisar no meu Backlog
- 92. E depois que acabar uma Sprint?
- 93. Depois começa tudo outra vez até o término do projeto
- 94. É a solução PERFEITA para meus problemas
- 95. Mais ou menos, temos que tomar alguns cuidados com os problemas mais comuns
- 101. Síndrome do Gótico Ou Síndrome do Depressivo
- 102. Síndrome do Emo Ou Síndrome do Chorão
- 103. Síndrome do Melhor do Mundo
- 109. Contrato Errado
- 110. Pausa nos problemas para uma Estória Bacon com Ovos
- 111. Chickens no Projeto
- 113. SCRUMbut
- 117. Acalme-se Brian, há esperança
- 118. A equipe deve estar SEMPRE unida
- 119. Garanta PIGs no seu projeto
- 123. Livre-se das más influências no Projeto
- 127. Incentive o profissional a não desistir
- 128. Nunca responda por ele
- 129. Faça o profissional vir com um problema e uma solução
- 130. Force diálogos entre os membros
- 131. Seja Humilde
- 133. Comemorem o sucesso do Sprint
- 134. TODOS ENVOLVIDOS DEVEM PARTICIPAR. === NÃO É OPCIONAL ===
- 138. Dúvidas?