O documento discute as vantagens do desenvolvimento guiado por testes (TDD) e especificação por exemplo (BDD) para melhorar a comunicação entre times de negócios e desenvolvimento e produzir software de melhor qualidade. Aborda também desafios na adoção dessas práticas e dicas para iniciar o processo com foco em entregas frequentes e valor para o usuário final.

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)

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…

14. Resultado

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

24. Kanban

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

27. Testes automatizados e TDD

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