O documento discute práticas ágeis e testes de aceitação, enfatizando: (1) a importância de entregas frequentes com feedback contínuo através de sprints curtos; (2) o valor da modelagem orientada a teste e da colaboração entre times para validar hipóteses sobre requisitos; (3) como testes de aceitação em todo o ciclo de vida do produto agregam valor e aproximam o produto das necessidades do cliente.

2. KLEITOR
Entusiasta da Vida,
Qualidade,
Colaborativos,
Ágil,
Teste e
Testes Ágeis.
2
kleitor.franklint@gmail.com
br.linkedin.com/in/kfranklint
99416-0873

3. 3
Um overview do Universo Ágil e de como
todo o time pode melhorar e agregar valor
ao produto com práticas ágeis e testes de
aceitação.

4. 4
Repensando o saber.
Essencialmente todos os modelos estão errados,
mas alguns são úteis!!
George E. P. Box

5. 5
Insanidade é fazer a mesma coisa repetidamente e esperar resultados
diferentes.
Definição de insanidade por Albert Einstein
Repensando o fazer

6. 6
Repensando que o time todo pode tornar o produto
melhor usando testes de aceitação e práticas ágeis!!
Repensando o que, mesmo?

7. 7
Como capturar e modelar requisitos?
-Use práticas Ágeis
-Faça Testes de aceitação
-Use pequenas fatias em pequenos
ciclos
-Use Histórias (User stories)
-Use técnicas exploratórias
Done=capturado+modelado+aceito+orientado a valor

8. 8
Quantas bolas há e de quais cores?
1 minuto. Valendo!!!

9. 9
Quantas bolas há aqui e quais as cores?
10 segundos. Valendo!!!

10. 10
Menores fatias de software ( requisitos )
são identificadas mais rápido, com
menos esforço e
com menos ambiguidade
Ágil=Pequenos intervalos +
pequenas fatias

11. 11
Teste de aceitação pra quê?
Modelando um carro muito, muito veloz!!!

12. 12
Teste de aceitação pra quê?
Modelando um carro
muito veloz!!!
Esse carro vai de 0 a 60 em 50s. Está rápido pra você?
Não?! Me dê um teste! Qual a velocidade ideal?
E agora, está rápido o suficiente?
Mas, ao chegar a 60 ele para!
E agora, está rápido o suficiente?
Não?! Me dê um teste! Qual a velocidade máxima?
E agora, está rápido o suficiente?

13. Fluxo do processo Ágil
13
Synchronizing Software Testing with Agile Requirements Practices , Jean McAuliffe, Dean Leffingwell
Aceitação
Pequenosintervalos
Pequenasfatias
Aprendizagem

14. 14
Gestão Ágil de Projetos
Era uma vez…
Então … tem essa etapa, aquela etapa…. e bem aqui entram as
práticas ágeis.
ÁGIL É UM ESTADO DE MENTE, NÃO UMA
METODOLOGIA DE PROJETO

15. O que é “Ágil”, Afinal?
 Agil não é metodologia, mas praticas úteis,
principalmente comportamentais
 Agil é adaptativo ao invés de prescritivo
 Agil é orientado a pessoas ao invés de orientado
a processo.
 Maximiza o valor do negócio com processos e
documentação right-sized, just-enough, e just-
in-time
15

16. 16
 Capacidade de rapidamente priorizar o uso de recursos quando
requisitos, tecnologia e conhecimento mudam com o objetivo de
lucrar em um mundo empresarial global turbulento
 Uma resposta muito rápida às mudanças súbitas de mercado e
ameaças emergentes através de interação intensiva com o cliente
com base em: http://davidfrico.com/rico14n.pdf, Lean & Agile Enterprise Frameworks
O que é “Ágil”, Afinal?

17. Resultado para empresas
Empresas ágeis crescem suas
receitas 37% mais rápido do que
outras organizações e tem lucros
mais elevados de 30%
Pulse Report:
71% dos entrevistados disseram que o trabalho ágil lhes deu respostas
mais rápidas às mudanças de condições de mercado
90% dos entrevistados
(CEOs e CIOs)
classificaram a agilidade
organizacional como vital
para o sucesso

18. Mundo Ágil e produtividade
Amostras de mais de 8.000 projetos mostrou que equipes ágeis são,
em média, 25% mais produtivas do que seus pares da indústria.
http://www.deltamatrix.com/why-are-agile-teams-25-more-productive
18

19. Métodos Ágeis populares
19
 Dynamic System Development Method (Dane Faulkner)  XP (Kent Beck)
 Adaptive Software Development (Jim Highsmith)  Lean Software Development (Mary Poppendieck)
 Crystal (Alistair Cockburn)  Feature Driven Development (Jeff DeLuca)
 Scrum (Ken Schwaber)  Agile Rational Unified Process (RUP)
 Rapid Software Testing (James Bach)

20. 20
Gestão ágil de projetos
http://blog.procademysoftware.com/agile-project-management/
Por que pequenas fatias?

21. 21
Praticas Ágeis +Teste de aceitação, pra quê?
Reduzir incertezas= exemplo+comunicação+colaboração+
pequenos ciclos+aceitação
Conhecer o requisito não é suficiente para saber o que
construir. O cliente precisar criar alguns testes.
Entregas sem tempo precisam ser melhores que aquelas
com prazo longo.

22. 22
Que testes de aceitação?
Qualquer um que envolva o cliente e envolvidos
Lista de requisitos, histórias, Casos de
Uso, Diagramas, Paper prototype,
Sistema...
E a eficácia
para o
cliente e
time?

23. 23
-Da concepção a pós-entrega
-Orientado a Contexto
-Descritivo e adaptativo
-Resultados orientados a Valor
-Oportunidade de enriquecer de descobrir novos requisitos
-Multidmensional: múltiplas faces, múltiplos times
Valoração pelo teste de aceitação

24. Ciclo de vida de projeto orientado a Alice
Ciclo de vida orientado à incerteza
Requisitos de
negócios
Requisitos
funcionais
desenvolvimento Entrega
Suposições Hipóteses Experimentos Validação
24
Modelagem Orientada a teste
Pra quê?
Teste: da concepção a pós-entrega
Todo o Time

25. 25
Sprints
Ágeis

26. Valoração e entrega
26
O problema de sprints grandes com
pouco feedback

27. Valoração e entrega
Representando a incerteza
27
Requisitos são suposições no começo do projeto
Mas, artefatos precisam ser escritos

28. Valoração e entrega
Problema: sprint grande+pouco feedback
28
Ciclo de vida orientado à incerteza
Suposições Hipóteses Experimentos Validação
Analista especifica:
UC, histórias, etc
Testadores e desenvolvedores enriquecem,
validam e descobrem novos requisitos
Analista aplica teste de
aceitação com o cliente
?
Entrega Entrega
Entrega

29. Menos útil: sprint grande+pouco feedback
29
-Produto com pouco valor agregado
-Parte do time com o cronograma em dia e produto baseado fortemente em
suposição
-Parte do time realizando enorme esforço para agregar valor ao produto
-Alto custo pouco ROI: Inconsistências e retrabalho
-Pontos de dor: Falta de perspectivas, monotonia, etc.

30. Vamos fazer melhor?
Sprint pequeno + muito feedback
Lembra dos grãos? Lembra do Carro?
30
Suposições Hipóteses Experimentos Validação
Clientes, analistas, testadores e desenvolvedores
escrevem, enriquecem, validam e descobrem novos requisitos
Entrega contínua + integração continua
Teste de aceitação+comunicação+colaboração

31. Mais útil: sprint pequeno+muito feedback
31
-Melhor qualidade do que é produzido: capacidade humana de
produzir bem com menos pontos de dor.
-Mais fácil de alinhar escopo ( implementação, correção)
-Menos erros repetidos multiplicados, analise mais inteligente
da produtividade do desenvolvedor.
-Minimizam riscos

32. Mais útil: sprint pequeno+muito feedback
32
-Produto com muito valor agregado
-Cronograma inteligente=colaboração+comunicação+distribuição
de esforço;
-Produto orientado a teste de aceitação
-Melhor ROI: custo x benefício
- O time valida entre si e com o cliente.

33. No sprint
33
-Defina o escopo pequeno
-Defina por histórias, features,
fluxos de evento (UC)
-Fale sobre riscos

34. 34
Entregue algo de valor a cada semana
Seja Engajado, seja positivo, seja profissional
Use o modelo 3C: card, conversation, confirmation
Sprints Ágeis: Projeto

35. 35
-Use técnicas de estimativas mais adaptativas:
planning poker, risk poker, T shirt size, etc
-Envolva o time na estimativa
-Lembre: às vezes o rápido atropela o Ágil.
Prática Ágil: Projeto

36. 36
-Feedback = agilidade+ user centered
-Reuniões eficazes
-Retrospectivas e lições aprendidas
-Fale sobre riscos em todos os sprints
-Explore muito e explore sempre!!!
Sprints Ágeis: comunicação
Mapa e transferência de conhecimento

37. 37
Revisando as práticas ágeis...
Até agora propomos juntos...
-Ciclos pequenos
-Entrega continua
-Integração continua
-Comunicação+colaboração
-Cliente Satisfeito e Time realizado

38. 38
Teste de
Aceitação

39. “O objetivo dos testes é agregar valor o mais cedo possível ao produto”.
Modelagem projetando, modelagem executando
Modelar comportamento do cliente..E SE..
39
Teste para quê, mesmo?

40. 40
Alguns pontos de vista
-Não!!! só depois do produto pronto
-Aceitação do cliente como base, seja ele qual for;
-Só como pré-entrega do produto é subutilizar a inteligência produtiva da empresa:
muito gasto pouco ROI
-No Ágil é executado em todo o ciclo de vida do produto
-Aproxima o produto da necessidade do cliente no teste de aceitação final ( UAT )
-Agrega muito valor ao produto
Teste de aceitação

41. 41
Testes de aceitação: como é feito?
-Escrever ( desenhar) pequenos, múltiplos pedaços
e dimensões de um requisito;
-Explorar essas “features”
-Ter o aceite do cliente
-Feedbacks de pequenos ciclos

42. 42
feedback = agilidade+ user centered
Teste de aceitação: comunicação
Eu sei o que eu disse,
mas já faz seis meses
... E eles construiram de acordo com a espec.. Ao invés do que o cliente queria

43. 43
Histórias ( um de vários modelos)
Teste de aceitação: comunicação

44. 44
Histórias
Use um Painel: Gestão À vista
É palpável e gratificante pro cliente ver sua
satisfação expressa

45. 45
Histórias
Use um Painel: Gestão À vista
Perfeitas para o time todo
-Ótimas com o cliente
-Padrão de comunicação para o time
-Geram Casos de Uso
-Podem decompor casos de Uso

46. 46
Histórias. Mas não só!
Perfeitas para o time todo
-Podem se transformar em código para o
desenvolvedor
-Podem ser padrão para time de teste
-Instrumentação para UX

47. 47
Histórias. Mas não só!
Perfeitas para gestão
-Avaliar cronograma e produtividade: completude, aprovação
-Visualiza múltiplas dimensões do Software
-Feedback rápido do cliente
-Análise de produtividade para desenvolvimento: completude e
aceitação x bugs

48. 48
Você faz parte!
Discussões de requisitos
Quem sabe fará parte
Apresentação de um produto
VC ficou de fora!
Analise de artefatos
Quando realizar?Teste de aceitação

49. Software perfeito e outras ilusões
49
Explore!!!!
... O cliente é da área,
então fica mais fácil
Meu cliente esqueceu de
me dizer...

50. 50
Quem precisa de Exploratórios?
Não é “Testa Aeh”

51. 51
Quem precisa de Exploratórios?
De debugadores a analistas de
requisitos

52. 52
Quando explorar?
Você faz parte!
Discussões de requisitos
Quem sabe fará parte
Apresentação de um produto
VC ficou de fora!
Analise de artefatos

53. 53
Revisando as práticas ágeis...
Neste fim de bate-papo
propomos juntos...
-Testes de Aceitação
-Explorar requisitos
-Integração continua
-Comunicação+colaboração
-Cliente Satisfeito e Time realizado

54. POSSO COLABORAR COM
MAIS RESPOSTAS?
54
kleitor.franklint@gmail.com
br.linkedin.com/in/kfranklint
92 99416-0873