SlideShare uma empresa Scribd logo
1 de 44
Testes automatizados e 
especificação por exemplo 
Unindo TI e negócio através do BDD
Quem sou eu? 
• Bruno “Codeman” Bemfica 
• Trabalho com TI há 12 anos. 
• CEO/Fundador da Sonne Tech 
• Membro fundador do PyTchê 
• Já passei por empresas como Groupon, Peixe 
Urbano e Grupo Pão de Açúcar 
• Desenvolvo em Python, C# e no que mais der na 
telha (desde que não seja PHP) 
• Gosto muito de felinos
Um pouco de história 
• Até a década de 90, modelos dominantes: 
– PMI + Waterfall (1970 – Winston Royce) 
– RUP (Rational) 
– XGH (eXtreme Go Horse )
Um pouco de história 
Waterfall RUP
Estatísticas de projetos de software 
(fonte: Gartner Group)
Causas dos problemas 
• Desenvolver software é fácil como caminhar 
sobre a água 
• Toda a documentação do projeto costuma ser 
feita no começo 
• Orçamentos fechados dependem de 
estimativas precisas 
• Estimativas dependem de critérios bem 
definidos
Causas dos problemas 
• “Uma estimativa é um palpite. Não há 
comprometimento implicado. Nenhuma 
promessa foi feita. Perder uma estimativa 
não é desonra de forma alguma. O motivo 
pelo qual fazemos estimativas é por que não 
sabemos quanto tempo algo levará.” 
MARTIN, Robert C. - O Codificador limpo.
Causas dos problemas 
• Mudança de requisitos == Mudança de prazos 
• Falta de contato com o cliente == Dúvidas 
• Mudanças de requisitos + falta de contato 
com cliente == retrabalho 
• Adição de novos recursos ao projeto
Frequência de uso das funcionalidades de um software 
(Fonte: Standish Group)
Consequências dos problemas 
• Retrabalhoˆ3 
• Ciclos de desenvolvimento cada vez maiores 
• Pressão por entrega: 
– Código ruim e POG 
– Impossibilidade de refactoring 
– Poucos ou nenhum teste
Enquanto isso, no desenvolvimento…
Resultado
Enquanto isso, no desenvolvimento…
PMI/Waterfall e RUP 
• RUP é um modelo atrasado de 
desenvolvimento de software que não cabe 
mais no cenário atual 
• Waterfall é inútil e PMI é um excelente 
método de gestão… Para qualquer coisa que 
não seja software.
Como mostramos ao cliente
Como é de verdade
Problemas chave 
• Metodologias ineficientes de gestão 
• Problemas de comunicação business – devs 
• Más práticas de código derivadas dos 
problemas anteriores
Uma luz no fim do túnel
Manifesto ágil 
• Criado em 2001, com 17 signatários 
• Processos adaptativos 
• Prioriza entregas e não documentações 
• Prioriza colaborações 
• Responde rápido a mudanças (ciclos curtos) 
• Gerou N variações (XP, Scrum, FDD, ASD, etc) 
• Preza por boas práticas de programação
Kanban
TDD 
• “Criado” por Kent Beck em 2003 
• Código que testa código 
• Diminui (mas não exclui) testes manuais 
• Uso de stubs e mocks facilita o foco no que 
interessa
Testes automatizados e TDD
STOP!
Vantagens do TDD 
• Reduz intervalo entre inserção e correção de 
bug 
• Reduz tempo gasto em debugging 
• Induz ao refactoring de código 
• Força a uma melhor escrita de código e 
arquitetura
Desvantagens do TDD 
• Difícil de vender 
• Difícil de começar a usar (mudar o 
pensamento) 
• Atingir o estado da arte leva tempo 
• Não testa regra de negócio x especificação
Problemas anteriores 
• Gestão engessada e focada em papel, não em 
interações e pessoas: √ 
• Código ruim, oriundo de pressa e 
impossibilidade de melhorias em virtude de 
pressão externa:√ 
• Comunicação entre a equipe: ?
Especificação por exemplo/BDD 
• Criado também em 2003, por Dan North, como uma 
“resposta” ao TDD 
• Foco maior em negócio do que o TDD 
• Utiliza linguagem ubíqua para que programadores e 
humanos se entendam 
• Testes (d)escritos pela equipe de negócios 
• Foco em entrada de usuários (ex: telas) e no que realmente 
é importante a quem usa o sistema (princípio YAGNI)
Problemas em se mudar o jeito de 
fazer software 
• Pessoas não gostam de mudanças 
• Mudanças levam tempo 
• Mudanças tem custos, muitas vezes bem alto$ 
• No mundo corporativo, ninguém tem amigos
Histórias de usuários 
• Eu, enquanto <papel no sistema>, preciso 
<objetivo>. Para tal, devo <funcionalidade> 
• Pilar fundamental: Critérios de aceitação
Exemplo 
• Funcionalidade: Eu, enquanto analista de crédito, preciso checar se 
um cliente está com o nome limpo antes de liberar um empréstimo. 
Para tal, preciso inserir que o sistema me avise sobre a situação 
financeira do cliente ao digitar o CPF dele no cadastro 
• Cenário: Cliente com nome limpo 
– Dado um cliente com CPF 789.456.123-00 
– Quando o CPF dele não estiver na lista do SPC ou Serasa 
– Então o sistema deve liberar a aprovação de crédito 
• Cenário: Cliente com nome sujo 
– Dado um cliente com CPF 123.456.789-00 
– Quando o CPF dele estiver na lista do SPC ou Serasa 
– Então o sistema deve me avisar e impedir a aprovação de crédito
STOP!
Ganhos 
• Testes de funcionalidade, requisitos funcionais e 
especificação se tornam a mesma coisa. 
• Documentação centralizada junto ao projeto, tornam-se 
uma coisa só 
• Documentação direta e reta, sem rodeios 
• Documentação é sempre atualizada junto ao projeto 
• Velocidade de entrega aumenta
Dicas para iniciar o processo 
• Evite o nome “ágil/agile” 
• Comece automatizando os testes 
exploratórios/funcionais (ensine Selenium aos 
testers) 
• Tenha em mente que a queda de 
produtividade nos primeiros meses é 
completamente normal
Dicas para iniciar o processo 
• Derivar o escopo dos objetivos 
• Olhar o micro, sem esquecer o macro 
• Especificação deve ser colaborativa (PO + equipe) 
• Validar frequentemente e automatizar a especificação 
(documentação viva) 
• Comece pelas telas (entrada de usuário – YAGNI) 
• Certifique-se de ter apoio da gestão
Dicas para lidar com pessoas reativas 
• Comece implementando uma prática que aumente a 
qualidade e ganhe tempo 
• Cuidado para não se queimar por desorganização 
alheia 
• Venda o processo como algo que diminui o TTM 
• Cuidado com os bumerangues 
• Agile tem documentação sim
Filosofia de vida 
“Qualidade é sobre estar tão preparado para o 
comum que quando o incomum aparece, temos 
tempo para atacá-lo” – ADZIK, Gojko 
“Não existe problema técnico. Todos os 
problemas são de natureza humana” – 
WEISSMANN, Henrique Lobo 
(www.itexto.com.br)
Obrigado! 
• Twitter: @ubuntroll 
• Site: www.brunobemfica.net 
• Email: brunobemfica@gmail.com 
• PS: Não usem PHP!
Perguntas? Comentários? 
Xingamentos? 
• Ligue para o nosso sac: 0800-BDD 
• Código mostrado na palestra: 
https://github.com/BrunoCodeman/PalestraT 
estes
Bibliografia 
• Specification By Example – Gojko Adzik 
• Bridging the Communication Gap – Gojko Adzik 
• ATDD By Example – Markus Gärtner 
• Desenvolvimento Guiado por Testes – Kent Beck 
• Desenvolvimento de Software com Scrum – Mike Cohn 
• O Codificador Limpo – Robert C. Martin

Mais conteúdo relacionado

Mais procurados

Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Neubio Ferreira
 
Scrum in a nutshell - business perspective
Scrum in a nutshell - business perspectiveScrum in a nutshell - business perspective
Scrum in a nutshell - business perspective
Marcos Alves
 

Mais procurados (20)

Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
 
Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)
 
Greenbar - Testes automatizados na sua empresa
Greenbar - Testes automatizados na sua empresaGreenbar - Testes automatizados na sua empresa
Greenbar - Testes automatizados na sua empresa
 
Metricas (e previsões) acionáveis de projeto
Metricas (e previsões) acionáveis de projetoMetricas (e previsões) acionáveis de projeto
Metricas (e previsões) acionáveis de projeto
 
Modelagem Ágil
Modelagem ÁgilModelagem Ágil
Modelagem Ágil
 
Gerando Resultados com Scrum: Scrum in a nutshell
Gerando Resultados com Scrum: Scrum in a nutshellGerando Resultados com Scrum: Scrum in a nutshell
Gerando Resultados com Scrum: Scrum in a nutshell
 
eXtreme Programming (xp)
eXtreme Programming (xp)eXtreme Programming (xp)
eXtreme Programming (xp)
 
Fundamentos Gestão de Escopo e Qualidade
Fundamentos Gestão de Escopo e QualidadeFundamentos Gestão de Escopo e Qualidade
Fundamentos Gestão de Escopo e Qualidade
 
Porque você precisa de uma estratégia de QA e precisa disso AGORA!
Porque você precisa de uma estratégia de QA e precisa disso AGORA!Porque você precisa de uma estratégia de QA e precisa disso AGORA!
Porque você precisa de uma estratégia de QA e precisa disso AGORA!
 
Scrum in a nutshell - business perspective
Scrum in a nutshell - business perspectiveScrum in a nutshell - business perspective
Scrum in a nutshell - business perspective
 
eXtreme Programming (XP)
eXtreme Programming (XP)eXtreme Programming (XP)
eXtreme Programming (XP)
 
SETIC Scrum & XP
SETIC Scrum & XPSETIC Scrum & XP
SETIC Scrum & XP
 
Extreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia ÁgilExtreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia Ágil
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Gerenciamento Ágil de Projetos com Scrum
Gerenciamento Ágil de Projetos com ScrumGerenciamento Ágil de Projetos com Scrum
Gerenciamento Ágil de Projetos com Scrum
 
Over engineering
Over engineeringOver engineering
Over engineering
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Introdução ao design de teste de software
Introdução ao design de teste de softwareIntrodução ao design de teste de software
Introdução ao design de teste de software
 

Semelhante a Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD

Modelagem dos Processos de Negócio para a Definição de Requisitos de Sistemas
Modelagem dos Processos de Negócio para a Definição de Requisitos de SistemasModelagem dos Processos de Negócio para a Definição de Requisitos de Sistemas
Modelagem dos Processos de Negócio para a Definição de Requisitos de Sistemas
Impacta Eventos
 
Gestão de Projetos de TI em Empresas
Gestão de Projetos de TI em EmpresasGestão de Projetos de TI em Empresas
Gestão de Projetos de TI em Empresas
Camilo Almendra
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
Roberto Brandini
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
Achiles Camilo
 

Semelhante a Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD (20)

SCRUM.pptx
SCRUM.pptxSCRUM.pptx
SCRUM.pptx
 
Minicurso: Uma Introdução ao Desenvolvimento de Software Lean
Minicurso: Uma Introdução ao Desenvolvimento de Software LeanMinicurso: Uma Introdução ao Desenvolvimento de Software Lean
Minicurso: Uma Introdução ao Desenvolvimento de Software Lean
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
Oficina de Metodologias Ágeis
Oficina de Metodologias ÁgeisOficina de Metodologias Ágeis
Oficina de Metodologias Ágeis
 
Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014
Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014
Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Modelagem dos Processos de Negócio para a Definição de Requisitos de Sistemas
Modelagem dos Processos de Negócio para a Definição de Requisitos de SistemasModelagem dos Processos de Negócio para a Definição de Requisitos de Sistemas
Modelagem dos Processos de Negócio para a Definição de Requisitos de Sistemas
 
tdc-2022-poa-quem-tem-medo-low-code.pdf
tdc-2022-poa-quem-tem-medo-low-code.pdftdc-2022-poa-quem-tem-medo-low-code.pdf
tdc-2022-poa-quem-tem-medo-low-code.pdf
 
Desenvolvimento ágil com Scrum e TFS 11 - Microsoft TechDay Sorocaba 2012
Desenvolvimento ágil com Scrum e TFS 11 - Microsoft TechDay Sorocaba 2012Desenvolvimento ágil com Scrum e TFS 11 - Microsoft TechDay Sorocaba 2012
Desenvolvimento ágil com Scrum e TFS 11 - Microsoft TechDay Sorocaba 2012
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
 
Gestão de Projetos de TI em Empresas
Gestão de Projetos de TI em EmpresasGestão de Projetos de TI em Empresas
Gestão de Projetos de TI em Empresas
 
DDD + BDD + TDD + Scrum
DDD + BDD + TDD + ScrumDDD + BDD + TDD + Scrum
DDD + BDD + TDD + Scrum
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
 
Netshoes metodologia
Netshoes metodologiaNetshoes metodologia
Netshoes metodologia
 
Implementing lean software development
Implementing lean software developmentImplementing lean software development
Implementing lean software development
 
Netshoes metodologia
Netshoes metodologiaNetshoes metodologia
Netshoes metodologia
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
 
Aula 1 introducao
Aula 1   introducaoAula 1   introducao
Aula 1 introducao
 
Utilizando BDD com Specflow e Selenium para testes Web MSP Tech Day Curitiba
Utilizando BDD com Specflow e Selenium para testes Web MSP Tech Day CuritibaUtilizando BDD com Specflow e Selenium para testes Web MSP Tech Day Curitiba
Utilizando BDD com Specflow e Selenium para testes Web MSP Tech Day Curitiba
 
Palestra scrum
Palestra scrumPalestra scrum
Palestra scrum
 

Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD

  • 1. Testes automatizados e especificação por exemplo Unindo TI e negócio através do BDD
  • 2. Quem sou eu? • Bruno “Codeman” Bemfica • Trabalho com TI há 12 anos. • CEO/Fundador da Sonne Tech • Membro fundador do PyTchê • Já passei por empresas como Groupon, Peixe Urbano e Grupo Pão de Açúcar • Desenvolvo em Python, C# e no que mais der na telha (desde que não seja PHP) • Gosto muito de felinos
  • 3. Um pouco de história • Até a década de 90, modelos dominantes: – PMI + Waterfall (1970 – Winston Royce) – RUP (Rational) – XGH (eXtreme Go Horse )
  • 4. Um pouco de história Waterfall RUP
  • 5. Estatísticas de projetos de software (fonte: Gartner Group)
  • 6.
  • 7. Causas dos problemas • Desenvolver software é fácil como caminhar sobre a água • Toda a documentação do projeto costuma ser feita no começo • Orçamentos fechados dependem de estimativas precisas • Estimativas dependem de critérios bem definidos
  • 8. Causas dos problemas • “Uma estimativa é um palpite. Não há comprometimento implicado. Nenhuma promessa foi feita. Perder uma estimativa não é desonra de forma alguma. O motivo pelo qual fazemos estimativas é por que não sabemos quanto tempo algo levará.” MARTIN, Robert C. - O Codificador limpo.
  • 9. Causas dos problemas • Mudança de requisitos == Mudança de prazos • Falta de contato com o cliente == Dúvidas • Mudanças de requisitos + falta de contato com cliente == retrabalho • Adição de novos recursos ao projeto
  • 10. Frequência de uso das funcionalidades de um software (Fonte: Standish Group)
  • 11. Consequências dos problemas • Retrabalhoˆ3 • Ciclos de desenvolvimento cada vez maiores • Pressão por entrega: – Código ruim e POG – Impossibilidade de refactoring – Poucos ou nenhum teste
  • 12. Enquanto isso, no desenvolvimento…
  • 13.
  • 15. Enquanto isso, no desenvolvimento…
  • 16. PMI/Waterfall e RUP • RUP é um modelo atrasado de desenvolvimento de software que não cabe mais no cenário atual • Waterfall é inútil e PMI é um excelente método de gestão… Para qualquer coisa que não seja software.
  • 17. Como mostramos ao cliente
  • 18. Como é de verdade
  • 19. Problemas chave • Metodologias ineficientes de gestão • Problemas de comunicação business – devs • Más práticas de código derivadas dos problemas anteriores
  • 20. Uma luz no fim do túnel
  • 21. Manifesto ágil • Criado em 2001, com 17 signatários • Processos adaptativos • Prioriza entregas e não documentações • Prioriza colaborações • Responde rápido a mudanças (ciclos curtos) • Gerou N variações (XP, Scrum, FDD, ASD, etc) • Preza por boas práticas de programação
  • 22.
  • 23.
  • 25.
  • 26. TDD • “Criado” por Kent Beck em 2003 • Código que testa código • Diminui (mas não exclui) testes manuais • Uso de stubs e mocks facilita o foco no que interessa
  • 28. STOP!
  • 29. Vantagens do TDD • Reduz intervalo entre inserção e correção de bug • Reduz tempo gasto em debugging • Induz ao refactoring de código • Força a uma melhor escrita de código e arquitetura
  • 30. Desvantagens do TDD • Difícil de vender • Difícil de começar a usar (mudar o pensamento) • Atingir o estado da arte leva tempo • Não testa regra de negócio x especificação
  • 31. Problemas anteriores • Gestão engessada e focada em papel, não em interações e pessoas: √ • Código ruim, oriundo de pressa e impossibilidade de melhorias em virtude de pressão externa:√ • Comunicação entre a equipe: ?
  • 32. Especificação por exemplo/BDD • Criado também em 2003, por Dan North, como uma “resposta” ao TDD • Foco maior em negócio do que o TDD • Utiliza linguagem ubíqua para que programadores e humanos se entendam • Testes (d)escritos pela equipe de negócios • Foco em entrada de usuários (ex: telas) e no que realmente é importante a quem usa o sistema (princípio YAGNI)
  • 33. Problemas em se mudar o jeito de fazer software • Pessoas não gostam de mudanças • Mudanças levam tempo • Mudanças tem custos, muitas vezes bem alto$ • No mundo corporativo, ninguém tem amigos
  • 34. Histórias de usuários • Eu, enquanto <papel no sistema>, preciso <objetivo>. Para tal, devo <funcionalidade> • Pilar fundamental: Critérios de aceitação
  • 35. Exemplo • Funcionalidade: Eu, enquanto analista de crédito, preciso checar se um cliente está com o nome limpo antes de liberar um empréstimo. Para tal, preciso inserir que o sistema me avise sobre a situação financeira do cliente ao digitar o CPF dele no cadastro • Cenário: Cliente com nome limpo – Dado um cliente com CPF 789.456.123-00 – Quando o CPF dele não estiver na lista do SPC ou Serasa – Então o sistema deve liberar a aprovação de crédito • Cenário: Cliente com nome sujo – Dado um cliente com CPF 123.456.789-00 – Quando o CPF dele estiver na lista do SPC ou Serasa – Então o sistema deve me avisar e impedir a aprovação de crédito
  • 36. STOP!
  • 37. Ganhos • Testes de funcionalidade, requisitos funcionais e especificação se tornam a mesma coisa. • Documentação centralizada junto ao projeto, tornam-se uma coisa só • Documentação direta e reta, sem rodeios • Documentação é sempre atualizada junto ao projeto • Velocidade de entrega aumenta
  • 38. Dicas para iniciar o processo • Evite o nome “ágil/agile” • Comece automatizando os testes exploratórios/funcionais (ensine Selenium aos testers) • Tenha em mente que a queda de produtividade nos primeiros meses é completamente normal
  • 39. Dicas para iniciar o processo • Derivar o escopo dos objetivos • Olhar o micro, sem esquecer o macro • Especificação deve ser colaborativa (PO + equipe) • Validar frequentemente e automatizar a especificação (documentação viva) • Comece pelas telas (entrada de usuário – YAGNI) • Certifique-se de ter apoio da gestão
  • 40. Dicas para lidar com pessoas reativas • Comece implementando uma prática que aumente a qualidade e ganhe tempo • Cuidado para não se queimar por desorganização alheia • Venda o processo como algo que diminui o TTM • Cuidado com os bumerangues • Agile tem documentação sim
  • 41. Filosofia de vida “Qualidade é sobre estar tão preparado para o comum que quando o incomum aparece, temos tempo para atacá-lo” – ADZIK, Gojko “Não existe problema técnico. Todos os problemas são de natureza humana” – WEISSMANN, Henrique Lobo (www.itexto.com.br)
  • 42. Obrigado! • Twitter: @ubuntroll • Site: www.brunobemfica.net • Email: brunobemfica@gmail.com • PS: Não usem PHP!
  • 43. Perguntas? Comentários? Xingamentos? • Ligue para o nosso sac: 0800-BDD • Código mostrado na palestra: https://github.com/BrunoCodeman/PalestraT estes
  • 44. Bibliografia • Specification By Example – Gojko Adzik • Bridging the Communication Gap – Gojko Adzik • ATDD By Example – Markus Gärtner • Desenvolvimento Guiado por Testes – Kent Beck • Desenvolvimento de Software com Scrum – Mike Cohn • O Codificador Limpo – Robert C. Martin

Notas do Editor

  1. - Royce em 1970 formalizou o waterfall como exemplo a NÃO ser seguido - RUP é engessado e faz com que algumas pessoas tenham mais trabalho que as outras em algumas fases (empresas perdem dinheiro pagando funcionários ociosos)
  2. -Citar “O mítico homem-mês” de Frederick Brooks (1975) ao falar da adição de novos recursos ao projeto
  3. - FALAR SOBRE OS PAPÉIS NO SCRUM (SCRUM MASTER, PO E ENGENHEIROS) – DIZER QUE NÃO É REGRA ESSAS RULES - RESOLVIDO O PROBLEMA DE GESTÃO, PROCESSOS ADAPTATIVOS!!
  4. TDD é trabalho de preguiçoso. Citar frase sobre preguiçosos do Bill Gates
  5. Falar sobre google (Se precisa mudar o código quando o teste quebra, o teste é bom. Se precisa mudar o teste sem mudar o código, ele é ruim)
  6. - RESOLVIDO O PROBLEMA TÉCNICO. MAS E O PROBLEMA DE COMUNICAÇÃO???
  7. - YAGNI (You Ain’t Gonna Need It)
  8. - FALAR SOBRE DOCUMENTAÇÃO ANTIGA (UML, ETC) VS DOCUMENTAÇÃO VIVA
  9. - Evitar agile pq já traz uma carga de conceitos/pré-conceitos em cima.
  10. E.P.E == Especificação Por Exemplos – Deriving Scope é processo chave, pois objetivos são mensuráveis Especificação colaborativa: Nem sempre o cliente tem a solução pro problema e qdo tem, nem sempre é a melhor. Ele não sabe fazer software Não esquecer o macro pra não sair viajando e perder tempo em coisas inúteis em especificação Apoio da gestão: Chefia sabendo do processo e pagando pra ver
  11. DICA: Prática não técnica (especificar as histórias de usuário do jeito que foi mostrado, por exemplo) TTM: Time to Market Bumerangues: Histórias que vão e voltam do backlog por muito tempo (PO vai se proteger dizendo que a culpa é do processo, não da especificação ruim) Documentação: Agile pode usar diagramas UML, especialmente o de domínio
  12. - Documentação viva faz os problemas mais corriqueiros irem embora.