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.

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

9. Pensando...
Classe Aluno

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

20. Domain-Driven Design

21. -Driven DesignDomain

22. Negócio Complexo

23. Negócio Complexo Pessoas

24. Negócio Complexo
Pessoas
Problema Real

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!

29. UbíquaLínguagem
(Ubiquitous Language)

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

116. Tantos problemas...
Estou #chateado

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

132. Ajude seus companheiros

133. Comemorem o sucesso do Sprint

134. TODOS ENVOLVIDOS DEVEM PARTICIPAR.
=== NÃO É OPCIONAL ===

138. Dúvidas?

139. Obrigado
Eduardo Bregaida
eduardo.bregaida@sciensa.com