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.
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 )
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
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.
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
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
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
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
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)
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
Editor's Notes
- 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)
-Citar “O mítico homem-mês” de Frederick Brooks (1975) ao falar da adição de novos recursos ao projeto
- 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!!
TDD é trabalho de preguiçoso. Citar frase sobre preguiçosos do Bill Gates
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)
- RESOLVIDO O PROBLEMA TÉCNICO. MAS E O PROBLEMA DE COMUNICAÇÃO???
- YAGNI (You Ain’t Gonna Need It)
- FALAR SOBRE DOCUMENTAÇÃO ANTIGA (UML, ETC) VS DOCUMENTAÇÃO VIVA
- Evitar agile pq já traz uma carga de conceitos/pré-conceitos em cima.
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
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
- Documentação viva faz os problemas mais corriqueiros irem embora.