Para times distribuídos que trabalham com microsserviços, a análise efetiva pode ser feita mapeando features em épicos para manter a visão do todo, mapeando dependências entre histórias para evitar bloqueios, e definindo critérios de aceitação nos níveis de épicos e histórias para identificar problemas de integração de forma antecipada.

1. B e m - v i n d o s
ANÁLISE EFETIVA DE
MICROSSERVIÇOS EM 3 PASSOS
Taíse Dias da Silva

2. BACKGROUND
2
Testes de software
20092006
Ciência da Computação, UFPE
Metodologias ágeis
Web services
2013
Times distribuídos
Microsserviços
2014
Análise de
Microsserviços em
times distribuídos

3. FALAREMOS SOBRE
3
Análise
Microsserviços
Contexto & Desafios
3 passos para análise

4. 4
ANÁLISE

5. Fonte: The Agile Samurai: How Agile Masters Deliver Great Software. Rasmusson, Jonathan.
O QUE É FAZER ANÁLISE?
5
“Deixa que a gente se preocupa
com os detalhes.”
Conta com
a gente pra
fazermos nossa
tarefa de casa,
pra toda e cada
iteração!
Ajudar a definir histórias do usuário
Fazer a análise detalhada
Garantir que fizemos nosso
trabalho
Sei o que
quero, mas como
descrevo isso?
Fazer web site
3 meses
Artefatos de análise

6. O que? Por quê? Pra quem?
HISTÓRIA DO USUÁRIO
6
Como palestrante do MTC que não mora
em BH
Eu quero listar nome, preço e localização
de hotéis de BH disponíveis em 18 de
junho
Para que eu possa escolher um hotel
perto do local do evento
I
N
V
E
S
T
Independente
Negociável
Valiosa
Estimável
Pequena (small)
Testável
Interface com o usuário (HTML, CSS)
Camada do meio (C#, Java, Python)
Camada de dados (Oracle, SQL Server)
Fonte: The Agile Samurai: How Agile Masters Deliver Great Software. Rasmusson, Jonathan.

7. BACKLOG
▫︎Conjunto das histórias para features do produto
▫︎Geralmente com épicos que agrupam histórias de
mesma área do domínio
▫︎Exemplo de épico: cadastro de cliente
▫︎Cadastro manual: nome, email, etc.
▫︎Cadastro via facebook
7

8. E quando as histórias são
implementadas por microsserviços?
8

9. 9
MICROSSERVIÇOS

10. O QUE SÃO MICROSSERVIÇOS?
10
Arquitetura monolítica: várias features
em um único executável
Arquitetura de microsserviços: conjunto
de serviços, cada um sendo um executável
e responsável por uma feature
Problemas:
-Implantação de uma feature requer
implantação de todas
-Difícil de manter a modularização
-Escalar horizontalmente requer mais
infra
Soluções:
-Implantação de uma feature
independente de outras
-Comunicação simples, protege
módulos
-Escalar horizontalmente requer
menos infra

11. BOAS PRÁTICAS
▫︎Testes automatizados em todos os níveis
▫︎Unitários, integração, contratos, jornadas de usuários
▫︎Integração contínua
▫︎Implantação automatizada
▫︎Monitoração
▫︎Times cuidando de feature
▫︎Times mantendo os microsserviços independentes
11

12. Mas e quando não se consegue adotar
todas as boas práticas?
12

13. 13
CONTEXTO &
DESAFIOS

14. ORGANIZAÇÃO DOS TIMES
14
Versus
Produto'B'
Web$Service$A$
Produto'A'
Web$Service$B$
Portal$
Web$Service$C$ Web$Service$D$
Time'4'Time'3'
Aplicação$$$$$Cliente$
Time'2'
Time'1'
Produto'B'
Web$Service$A$
Produto'A'
Web$Service$B$
Portal$
Web$Service$C$ Web$Service$D$
Time'4'Time'3'
Aplicação$$$$$Cliente$
Time'2'Time'1'

15. ORGANIZAÇÃO DO BACKLOG
15
Produto'B'
Web$Service$A$
Produto'A'
Web$Service$B$
Portal$
Web$Service$C$ Web$Service$D$
Backlog'4'Backlog'3'
Aplicação$$$$$Cliente$
Backlog'2'
Backlog'1'
Produto'B'
Web$Service$A$
Produto'A'
Web$Service$B$
Portal$
Web$Service$C$ Web$Service$D$
Backlog'4'Backlog'3'
Aplicação$$$$$Cliente$
Backlog'2'Backlog'1'
Versus

16. V
DESAFIOS
▫︎Quando times perdem a visão do todo
▫︎Escopo das histórias delimitado por endpoints
▫︎Pode perder o benefício das características INVEST
16
I
T
dependentes das histórias do cliente
endpoints podem ser são features incompletas
usuários não testam endpoints

17. DESAFIOS
▫︎Quando times ficam bloqueados por dependência em
histórias de outros times
▫︎Difícil de alinhar prioridades entre times
▫︎Time do cliente dependendo do time de serviços
▫︎Velocidades por histórias em vez de por features
podem dar uma falsa visão de progresso
17

18. DESAFIOS
▫︎Quando demora pra surgirem problemas de integrações
▫︎mau funcionamento do produto
▫︎pode atrasar ou abortar entregas
18

19. TIMES DISTRIBUÍDOS
19
▫︎Escalando desafios

20. Como conseguir fazer uma análise
efetiva nesse contexto?
20

21. 21
3 PASSOS PARA ANÁLISE

22. 3 PASSOS PARA ANÁLISE
1. Mapear features em épicos
2. Mapear dependências entre histórias do épico
3. Definir critérios de aceitação para integrações
22

23. 1. MAPEAR FEATURES EM ÉPICOS
▫︎Problema: falta de visão do todo
▫︎Solução: tratar épico como cidadão de primeira classe
▫︎O que? Por quê? Pra quem?
▫︎Usar épico na priorização e velocidade
23
[ÉPICO] Visualizar margem de lucro
Como planejador de compras
Eu preciso saber qual a margem de
lucro do meu plano de compras
Para que eu possa tomar decisões
de planejamento de acordo com
meu orçamento

24. ▫︎Problema: bloqueios por conta de dependências
▫︎Solução: colaborar para identificar quais as capacidades
que cada serviço precisa ter
▫︎Identificar as possíveis dependências entre elas para
que o usuário consiga atingir seu objetivo
▫︎Usar como base a arquitetura definida pelos times
para a feature
▫︎Priorização baseada nas dependências
2. MAPEAR DEPENDÊNCIAS ENTRE HISTÓRIAS DO ÉPICO
24

25. EXEMPLO
25
[ÉPICO] Visualizar margem de lucro
Como planejador de inventário
Eu preciso saber qual a margem de
lucro do meu plano de compras
Para que eu possa tomar decisões
de planejamento de acordo com
meu orçamento
[Custo] Listar
custo do
produto
[Plano] Calcular
margem de
lucro
[Preço] Listar
preço do
produto
Objetivo do
ponto de vista
do usuário
Histórias de
serviços para
atingir o objetivo

26. 3. DEFINIR CRITÉRIOS DE ACEITAÇÃO PARA INTEGRAÇÕES
▫︎Problema: integração causa mau funcionamento dos
produtos e possíveis atrasos de entrega
▫︎Usar jornadas de usuário pra definir critérios de
aceitação no nível de épico
▫︎Considerar os produtos impactados
▫︎Definir critérios de aceitação pros serviços com foco em
regras de negócio, independente de interface
▫︎Feedback mais rápido sobre os problemas de integração
26

27. EXEMPLO: CRITÉRIO DE ACEITAÇÃO PRO ÉPICO
27
[ÉPICO] Visualizar margem de lucro
Como planejador de inventário
Eu preciso saber qual a margem de
lucro do meu plano de compras
Para que eu possa tomar decisões
de planejamento de acordo com
meu orçamento
Jornada passando por múltiplos
produtos
1. Usuário do produto de gerenciar custo
define o custo do produto
2. Usuário do produto de gerenciar
preços define o preço do produto
3. Planejador acessa produto de plano de
compras do produto e visualiza a
margem de lucro
Teste de sistemas, de ponta a ponta, entre diferentes produtos. Lento pra ser
executado, mas de alto valor de negócio. Deve cobrir jornadas de mais alto nível.

28. EXEMPLO: CRITÉRIO DE ACEITAÇÃO PRAS HISTÓRIAS
28
Serviço que
gerencia
custo
[Custo] Listar custo do produto
Dado que camisas regatas brancas
pro verão de 2016 custa 2 dólares
Quando eu listo custo de camisa
regata branca do verão de 2016
Então vejo que o custo é 2 dólares
[Preço] Listar preço do produto
Dado que camisas regatas brancas
pro verão de 2016 valem 20 dólares
Quando eu listo preço de camisa
regata branca do verão de 2016
Então vejo que o preço é 20 dólares
Serviço que
gerencia
preço
Serviço que
gerencia
plano
[Lucro] Calcular margem de lucro
Dado que camisas regatas brancas
pro verão de 2016 custam 2 dólares
e valem 20 dólares
Quando eu visualizo a margem de
lucro do meu plano de compras
Então vejo a margem é de 18 dólares

29. 29
RESUMO

30. RESUMO
Para o contexto em que:
▫︎times distribuídos não são organizados por features
▫︎cuidam de serviços que são utilizados por múltiplos produtos
▫︎não conseguem usar todas as boas práticas pra se trabalhar
com microsserviços
A análise dos microsserviços podem ser feita como segue:
▫︎mapeando features em épicos para os times não perderem a
visão do todo
▫︎mapeando dependências entre histórias de um mesmo épico
pra que um time não fique bloqueado
▫︎planejando critérios de aceitação nos níveis de épicos e
histórias para não agir apenas reativamente aos problemas de
integração
30

31. Perguntas?
OBRIGADA
@taisedias
github.com/taisedias
linkedin.com/in/taisedias

32. REFERÊNCIAS
▫︎The Agile Samurai: How Agile Masters Deliver Great
Software. Rasmusson, Jonathan.
▫︎Microservices. Martin Fowler.
▫︎MicroservicePrerequisites. Martin Fowler.
▫︎Micro service trade offs. Martin Fowler.
▫︎Enterprise Integration Using REST. Martin Fowler.
32