Uma introdução à Especificação por meio de Exemplos. Segue conteúdo do livro Specification By Example, Gojko Adzic, Manning, 2011.

1. Especificação por
meio de exemplos
UMA INTRODUÇÃO
Fábio Nogueira de Lucena

2. Referência

Specification By Example:
How successful teams deliver the right software
Gojko Adzic, Manning, 2011
http://specificationbyexample.com/

3. Créditos para o autor e sua obra

Specification By Example:
How successful teams deliver the right software
Gojko Adzic, Manning, 2011
Frases, citações e excertos obtidos
deste livro.

4. Aviso
 As
informações aqui contidas são
uma interpretação do conteúdo do
livro indicado no slide anterior.
 Consulte o original para detalhes.

5. Esteja alerta!

Tecnologias são propostas e criadas continuamente para resolver
problemas. Duas questões surgem:
A estratégia realmente contribui?
 O problema resolvido é parecido
com o meu?


6. Orientações

Conhecimento de cerca de 50 projetos.

Alguns pequenos, outros envolvendo equipes espalhadas por
diversos continentes.

Processos executados: XP, Scrum, Kanban e similares.

Outros nomes


Behavior-Driven Development


Testes de aceitação ágil
Specification by Example, ...
Apresentado por meio de padrões

7. Tradicionalmente, ...
Desenvolver software exige extensas
especificações funcionais e longas fases de
testes.
O que não é compatível com liberações
semanais.

8. O que precisamos?

Evitar especificação “exagerada”

Documentação confiável que explica o que o sistema
faz

Verificar de forma eficiente se o sistema faz o que a
especificação diz.

Manter documentação relevante e confiável com o
mínimo de custo de manutenção.
Especificação por meio de exemplos é
uma estratégia dirigida para atingir estes objetivos.

10. “Ao revelar os padrões de processos
empregados por equipes de sucesso,
eu espero ajudar outros a implementar
estas ideias deliberadamente.”
Gojko Adzic
Specification By Example
Manning, 2011.

11. Padrões de processos

Derivar escopo de objetivos

Especificar de forma colaborativa

Ilustrar usando exemplos

Refinar a especificação

Automatizar a validação sem alterar especificações

Validar frequentemente

Evoluir o sistema de documentação

12. Derivar escopo de objetivos

13. Domínio da solução
Derivar escopo de objetivos
Domínio do problema

14. Derivar escopo de objetivos
(contexto)

Escopo é solução para problema do domínio.

Escopo é um meio de se atingir um objetivo de negócio.

Muitos esperam a definição do escopo pelo cliente, product owner
ou usuário antes de iniciar a implementação.

Tudo que ocorre antes da implementação é geralmente ignorado
pela equipe de desenvolvimento.

Após a especificação, desenvolvedores implementam a solução.

15. Derivar escopo de objetivos

Se clientes definem o escopo, então o projeto não se beneficia do
conhecimento das pessoas na equipe de desenvolvimento.

O software fará o que o cliente pediu, mas não necessariamente o
que precisava.

16. ESCOPO
O Código de Trânsito Brasileiro foi alterado
(Lei nº 11.910 de 18 de março de 2009)
“Art. 105. São equipamentos obrigatórios dos veículos,
entre outros a serem estabelecidos pelo CONTRAN: (...)
VII - equipamento suplementar de retenção –
air bag frontal para o condutor e o passageiro do banco dianteiro. (...)
CONTRAN, Resolução no. 312, instituiu a obrigatoriedade do sistema
antitravamento das rodas (freio ABS).

17. OBJETIVO
Segurança

18. ESCOPO
“Eu quero um carro com vido elétrico, ... Sério?
OBJETIVO
Ah, conforto.

19. RESUMO
Posso indicar o carro com as características, mas como
especialista em automóveis, se eu conhecesse o real
objetivo, possivelmente seria mais útil, efetivo, ...

20. Derivar escopo de objetivos
„Em vez de “cegamente” aceitar
requisitos como a solução para um
problema desconhecido, equipes de
sucesso derivam escopo de objetivos.’
Gojko Adzic

21. Derivar escopo de objetivos

Inicia-se com objetivo de negócio do cliente.

Todos colaboram para definir o escopo que atinge o objetivo.

A equipe trabalha com os usuários do negócio na determinação
da solução.

Aqueles do negócio concentram-se no objetivo de uma
característica desejável e no valor que esperam extrair dela.

A equipe então sugere uma solução que é mais barata, mais
rápida, ...

22. Especificar de forma
colaborativa

23. Em vez de contar com uma única pessoa
para obter as especificações corretamente,
equipes de sucesso colaboram com entendidos no
negócio para especificar a solução.

24. Cria uma
“propriedade compartilhada”
das especificações, tornando a
equipe mais engajada.

25. Ilustrar usando exemplos

26. Em vez de esperar pelo registro preciso de
especificações em uma linguagem de programação
durante a implementação, equipes de sucesso
ilustram especificações usando exemplos.

27. Equipe trabalha com especialistas do negócio
para identificar “exemplos chave” que
descrevem a funcionalidade esperada.
Desenvolvedores sugerem exemplos que
ilustram casos “problemáticos”.
Todos têm uma compreensão compartilhada
do que precisa ser produzido.

28. Exemplos chave servem como alvo para
desenvolvedores e como critério de avaliação
objetivo para checar se o desenvolvimento
está concluído.
Se os exemplos são fáceis de entender,
então podem ser empregados como
requisitos detalhados e não ambíguos.

29. Refinar a especificação

30. Especialistas no negócio tendem a pensar
da perspectiva da interface com o usuário.
Detalhar como algo deve ser feito é em
vez do que é exigido é um desperdício.

31. Muitos detalhes tornam exemplos difíceis
de comunicar e compreender.

32. Equipes de sucesso, ao
refinar a especificação,
removem informações “não essenciais”
e criam um contexto preciso e concreto
para o desenvolvimento e testes.

33. Equipes de sucesso especificam
o que é suposto que o software
faça, em vez de como ele faz.
Cucumber (exemplo)
Especificação com
exemplos é uma
especificação de
trabalho, é um teste de
aceitação, é um teste
funcional.

34. Automatizar a validação
sem alterar especificações

35. Verificação rápida é essencial para o desenvolvimento
de software em iterações curtas.
Ou seja, é preciso tornar o processo de validação
barato e eficiente.
Solução óbvia: automação.

36. Automação sim, mas como?
Rhino Mocks
Especificações
automatizadas
tecnicamente
são inacessíveis aos
especialistas do negócio.

37. Várias versões
Versão desenvolvedor
Versão mais legível
Sincronização???!!!

38. Equipes de sucesso não correm o risco de
“tradução entre formatos”.
Exemplos chave que são
compreensíveis e
acessíveis a toda a
equipe tornam-se
especificações
executáveis.
Cucumber (exemplo)

39. Se é preciso alterar, então há um único lugar.
Única fonte
Consumida por
desenvolvedores,
responsáveis por testes,
especialistas no domínio,
e outros.

40. Fitnesse
Wiki

41. Concordion

42. Concordion

43. Cucumber

44. specFlow

45. codeeffects
http://rule.codeeffects.com/

46. OpenRules

47. Validar frequentemente

48. Um suporte eficiente de
software exige sabermos o
quê ele faz e o porquê.
Em muitos casos, a única forma
de fazer isto é recorrer ao
código ou encontrar alguém
que possa fazer para nós.

49. Código é, frequentemente, a única coisa em que
podemos confiar; muita documentação é
desatualizada antes do término do projeto.
Desenvolvedores são oráculos de conhecimento
e gargalos de informação.

50. Evoluir o sistema de
documentação

51. Ao longo do tempo, mudanças ocorrem e
provocam atualizações na
“documentação viva”.

52. Créditos para o autor e sua obra
(agradecimentos finais)

Specification By Example:
How successful teams deliver the right software
Gojko Adzic, Manning, 2011
Frases, citações e excertos obtidos
deste livro.