Engenharia de Software Moderna

Artigos Didáticos - Parte I

Processos & Requisitos

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides
1
Temas dos artigos
1. Squads
2. MVPs
3. Product Discovery
4. Design Thinking e Jobs to be Done
5. Shape Up

2
 Engenharia de Software Moderna

Organizando Times de Desenvolvimento de

Software em Squads

Prof. Marco Tulio Valente

https://engsoftmoderna.info/artigos/squads.html

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides
3
Time ágeis ou Squads
● Pequenos (“duas pizzas”)
● Multidisciplinares
● Autônomos
○ Auto-organizáveis
○ Mínimo de dependências para outros times
○ Responsabilidade fim-a-fim por uma funcionalidade
● Missão de longo prazo 4
Questões pendentes

1. Quais os tipos possíveis de times?

2. Como escalar esses times?

5
Problema #1: Tipos de squads
● Tipo principal de squad:
○ Squads de produto (90% dos squads)
○ Clientes de tais squad são usuários finais do sistema

6
Exemplo: squads de produto em um sistema de
comércio eletrônico
● Squad de Catálogo
● Squad de Pesquisa de Produtos
● Squad de Recomendação de Produtos
● Squad de Checkout
● Squad de Pagamento
● Squad de Entrega
● etc 7
Outros tipos de squads (~10%)
● Squads responsáveis por componentes
● Squads responsáveis por plataformas Clientes são
squads de
● Squads facilitadores de boas práticas produto

● Squads responsáveis por objetivos de

negócio

8
Exemplo de time de componente

Druid is a real-time analytics database designed

for fast slice and dice analytics on large datasets

https://blog.twitter.com/engineering/en_us/topics/infrastructure/2022/powering-real-time-data-analytics-with-druid-at-twitter
Exemplo de time de plataforma

The Twitter experimentation tool, Duck Duck Goose (DDG for

short), was first created in 2010.

https://blog.twitter.com/engineering/en_us/a/2015/twitter-experimentation-technical-overview
Carga cognitiva e Lei de Conway
● Carga cognitiva (“preocupações dos times”)
○ Times de plataforma e de boas práticas servem para
diminuir a carga cognitiva dos times de produto
● Lei Conway:
○ Arquitetura do software tende a “espelhar” a
organização dos times de software

11
Problema #2: Como escalar esses times?

Modelo
Spotify
(2012)

12
Vídeos sobre o Modelo Spotify
● https://youtu.be/Yvfz4HGtoPc
● https://youtu.be/vOt4BbWLWQw

13
Exemplo de tribo: Marketplace
● Suponha que nosso sistema anterior de comércio
eletrônico vai começar a aceitar vendas de terceiros
● Logo, podemos criar uma tribo “marketplace”
○ Com squads dedicados a “sellers” (vendedores externos)
○ Exemplos: squad para cadastro de sellers, squad para
pagamento de sellers, etc

14
Mais um exemplo de tribo: Logística
● Nosso sistema de comércio eletrônico continua crescendo
● Agora temos uma logística de entrega complexa, com
entregadores próprios, entregadores terceirizados, centros
de distribuição em mais de uma cidade, etc
● Logo, podemos criar uma tribo para cuidar de todos os
sistemas de logística e entrega de mercadorias

15
Exercícios

16
 Exercícios de V ou F
https://engsoftmoderna.info/exercicios/exvf.html#/cap/Squads

17
1. Descreva um problema de organizações baseadas em silos
funcionais, isto é, times separados de desenvolvedores,
administradores de BD, testadores, operação, designers, etc
2. Suponha uma organização que organiza seus squads em
componentes arquiteturais. Ou seja, ela possui squads que
implementam componentes front-end e outros squads que
implementam componentes back-end. Discorra sobre o principal
problema desse tipo de organização de squads.
3. Descreva uma desvantagem do Modelo Spotify.
4. Suponha uma empresa de entrega de comida online. Descreva
pelo menos três tribos que essa empresa poderia usar para
organizar seus squads. Basta descrever o objetivo de cada tribo. 18
 Engenharia de Software Moderna

O que é – e também o que não é – um MVP?

Prof. Marco Tulio Valente

https://engsoftmoderna.info/artigos/mvp.html

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides
19
Conceito de MVPs: tremendo sucesso!

Lançado em 2011 20
MVP
● MVP = experimento para testar uma hipótese ou ideia
● Hipótese:
○ Minha ideia tem valor? Ela é útil?
○ Os clientes vão usá-la? Vão pagar por ela?
● Objetivo de um MVP: descobrir se sua hipótese é
verdadeira, de forma mais rápida e com o menor custo

21
Contexto de incerteza
● MVP é indicado para contextos de incerteza
● Não temos certeza se nossa ideia é viável
● Logo, ela pode falhar, mas que seja então:
○ Uma falha rápida
○ Uma falha com um prejuízo pequeno

22
Produto Mínimo
● "Se você não tiver vergonha do seu MVP, você demorou
demais para lançá-lo"
● Porém, alguns aspectos não podem ser negligenciados:
○ Legais
○ Privacidade e segurança
○ Desempenho
○ Disponibilidade
23
 Exemplo clássico: suponha que te
pediram para “implementar” um carro

24
1a versão

25
1a versão 2a versão

26
1a versão 2a versão 3a versão

27
4a versão

28
 …...

4a versão n-ésima versão

29
EasyTaxi: exemplo muito conhecido de MVP

30
Alguns Tipos de MVP
1. Landing page
2. Mágico de Oz
3. Concierge

31
MVP Landing Page
● Validação bem inicial, apenas para capturar “leads”
● Tipo mais simples e “menos poderoso” de MVP
● Anúncios no Google ou Facebook podem ser usados
para trazer tráfego para a página

32
MVP Mágico de Oz
● Backend manual (mas cliente não sabe disso)
● Exemplo: EasyTaxi

33
MVP Concierge
● Primeiro, significado do termo:
○ Profissional de um hotel que presta pequenos serviços
para os hóspedes
○ Exemplos: aluguel de carros, compra de passeios,
indicação de restaurantes, etc.

34
MVP Concierge
● Atendimento todo manual
● Sem nenhuma automação, nem no front, nem no backend
● Você se apresenta para o cliente e se oferece para
resolver o problema dele
● Exemplo: fretamento de transporte para alunos da UFMG
○ Reserva de passagens e pagamentos são feitos de
forma manual (ou via grupos do WhatsApp)
35
Algumas perguntas sobre MVPs

36
MVP pode ter código?
● Sim, desde que as funcionalidades sejam mínimas

37
Preciso me preocupar com qualidade de código?
● Normalmente, não.
● Ou seja, ainda não é o momento de ser preocupar com:
○ Testes automatizados
○ Integração contínua
○ Padrões de projeto
○ Refatorações

38
Quanto tempo leva para construir um 1o MVP?
● Claro, depende e varia muito.
● Mas tem que ser rápido
○ Uma semana ou então 10 dias
○ Talvez, duas semanas, no máximo

39
Usuários têm que pagar para usar o MVP?
● Sim, é importante exigir “comprometimento” dos usuários
● Maior elogio de um cliente: “informar o cartão de crédito”

40
MVP é apenas para startups?
● Não, MVPs é para testar ideias cuja viabilidade não é clara
● Exemplo:
○ UFMG pode estar enfrentando um problema X
○ Para resolvê-lo, pensamos em construir um sistema Y
○ Porém, não temos certeza de que Y vai dar certo

41
Duas confusões que são comuns

42
(1) MVP ≠ 1a versão de um produto

43
MVP é um experimento (logo, pode falhar)
● Ou seja:
○ Se existe um mercado certo
○ Se o cliente já te contratou e vai te pagar
○ Se você tem competência para desenvolver
○ Se o cliente sabe muito bem o que quer
○ Logo, não existe risco e não precisamos de MVP
● Se já sabemos que vai dar certo, não é um experimento 44
MVP vs Desenvolvimento Ágil
● Mesmo não tendo um MVP, você pode ter:
○ Desenvolvimento iterativo e incremental
○ Com feedbacks dos usuários, após cada sprint
● Diferença: o risco de ter que jogar fora o resultado de um
sprint é muito baixo

45
(2) Pivô ≠ restart

46
Tipos de pivô
● Zoom-in: uma feature específica vira um novo produto
● Zoom-out: MVP vira uma feature de um produto maior
● Segmento de clientes: por exemplo, atletas amadores
para atletas profissionais

47
Tipos de pivô
● Aplicação para plataforma: por exemplo, de uma loja
online para um sistema de hospedagem de lojas online
● Modelo de negócios: por exemplo, muitos clientes com
margem pequena para poucos clientes com margem alta;
ou de freemium com anúncios para assinaturas (SaaS)
● Canal de distribuição: por exemplo, de anúncios para
venda direta por meio de vendedores
● Tecnologia: por exemplo, de iOS para Android. 48
Conclusão
● Duas estratégias para validar ideias: MVPs e entrevistas
● Vantagens de MVPs
○ Usuários não sabem o que querem
○ Usuários mentem, normalmente para te agradar
○ “Se eu tivesse perguntado para os usuários o que eles
queriam, a resposta seria um cavalo mais rápido”
● Nada impede uma estratégia que combine MVPs e
entrevistas 49
Exercícios

50
1. Qual a diferença entre um MVP e uma pesquisa de mercado?

2. Nos seus primeiros dez anos de vida, a Netflix era uma empresa que
entregava DVDs fisicamente pelo correio, já tendo nessa época centenas
de milhares de assinantes. Então, em 2007, a empresa migrou para o
serviço de streaming, tal qual usamos hoje. Você classificaria essa
mudança como um pivô? Sim ou não? Justifique sua resposta.

3. Suponha que você planeja abrir uma empresa para entrega de comida
pela Internet, em BH, e pretende, portanto, concorrer com empresas
estabelecidas e conhecidas do ramo. A criação de um MVP seria
recomendada nesse contexto? Sim ou Não? Justifique sua resposta.

4. Descreva um tipo de domínio (ou aplicação) para o qual é mais difícil e

desafiador criar um MVP. Justifique sua resposta.
 Engenharia de Software Moderna

Product Discovery: Uma Breve Introdução

Prof. Marco Tulio Valente

https://engsoftmoderna.info/artigos/product-discovery.html

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides
52
Perguntas não respondidas por Scrum (clássico)?
● Como organizar e escalar os times?
○ Resposta: Modelo Spotify
● Como começar quando o grau de incerteza é alto?
○ Resposta: MVPs
● Como gerenciar o fluxo de demandas de features?
○ Resposta: atividades de product discovery (aula de hoje)

53
Existem dois tipos de empresas de software
● Empresas de projeto
● Empresas de produto

54
Empresas de projeto
● Consultorias, agências, fábricas de software
● Trabalham para um cliente, com um contrato
● Cliente sabe o que quer… Daí o nome Product Owner
● Desenvolvem sistemas internos de tais clientes
● Desenvolvimento tem início, meio e fim
● Workshops de inception, histórias de usuários, etc
● Cenário típico das décadas de 1990 e 2000 55
Empresas de produto
● Empresas dirigidas por software (nasceram digitais)
● Principal produto: um software
● Desenvolvimento perpétuo: nunca termina…
● Ficaram populares nos últimos 10-20 anos.

56
Requisitos vs Hipóteses
Requisitos
● Funcionalidades “obrigatórias”
● Cliente tem certeza de que o sistema deverá ter essa
funcionalidade
● Faz mais sentido em projetos de software
● Atividade: especificação de requisitos
● Responsável: analista de requisitos (Waterfall) ou PO
(Scrum)
58
Hipóteses
● Muitas vezes, o cliente não sabe bem o que quer
● Mais comum em empresas de produto (milhões de clientes)
● Nestes casos, o termo requisito não faz muito sentido
● Por isso, costuma-se usar o termo de hipótese
● Hipótese: achamos que o sistema deveria ter essa
funcionalidade, mas não temos certeza
● Atividade: Product Discovery
● Responsável: Product Manager (PM) 59
Product Discovery
● Atividades realizadas com o objetivo de descobrir o que de
fato deve ser implementado.
● Dada uma hipótese, descobrir se ela é:
○ Verdadeira ⇒ vai para o backlog do produto
○ Falsa ⇒ descartada e não perdemos mais tempo

60
Product Discovery
● Objetivo: validar hipóteses
● Como?
○ Entrevistas com usuários
○ Design Thinking
○ Design Sprints
○ Jobs to be Done
○ MVPs
61
Comparando com Waterfall e Scrum
● Waterfall: analista de requisitos levanta o que os clientes
querem
● Scrum: PO define e prioriza as histórias; fica disponível
para explicá-las
● Discovery:
○ Não temos total certeza (“requisitos”)
○ Mas temos hipóteses, que precisam ser validadas
62
Problemas evitados com Product Discovery
1. Times e PO perderem o controle do backlog
2. Sistemas lotados de features, de pouco valor e uso

63
Como “plugar” Product Discovery em
Scrum e Kanban
 Negócio Dual Track Scrum
Ideias, problemas, hipóteses
Discovery
tempo
histórias de usuários

Backlog do
Produto

backlog do sprint
Delivery

sprint
funcionalidades

Clientes
 Quadro do upstream

Ideias Análise Validação Backlog

Upstream
Kanban
Trabalho sendo
preparado

Backlog
Quadro do downstream

Especifi- Implemen-
Backlog Revisão
Downstream cação tação

Kanban
Trabalho em andamento
Exercícios

67
1. Qual problema pode ocorrer quando se adota Scrum ou
Kanban de forma tradicional e que atividades de discovery
podem ajudar a resolver?

2. Além de ter sido feita com a mãe do entrevistador, qual o

principal problema com a seguinte entrevista? (próxima página)

3. Descreva três perguntas mais importantes que o

entrevistador deveria ter feito na entrevista anterior.
Son: Mom, mom, I have an idea for a business — can I run it by you?
Mom: Of course, dear.
Son: You like your iPad, right? You use it a lot?
Mom: Yes.
Son: So would you ever buy an app which was like a cookbook for your iPad?
Mom: Hmmm.
Son: And it only costs $40 — that’s cheaper than those hardcovers on your shelf.
Mom: Well...
Son: And you can share recipes with your friends, and there’s an iPhone app which is your
shopping list. And videos of that celebrity chef you love.
Mom: Oh, well yes honey, that sounds amazing. And you’re right, $40 is a good deal. Will it
have pictures of the recipes?
Son: Yes, definitely. Thanks mom — love you! Fonte: The Mom Test: How to talk to customers
& learn if your business is a good idea
 Engenharia de Software Moderna

Design Thinking: Principais Conceitos e

Atividades

Prof. Marco Tulio Valente

https://engsoftmoderna.info/artigos/design-thinking.html

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides
70
Motivação
● Temos que resolver um problema complexo e desafiador
○ Não temos uma ideia clara de como resolvê-lo…
○ Não temos ideia de como seria um possível MVP
○ Pode ser que a solução não inclua um software

71
Exemplos de Problemas
1. Universidade: como aumentar a participação dos alunos
nas aulas online?
2. Editora: como aumentar o faturamento?
3. Hospital: como melhorar o atendimento dos pacientes?
4. Hotel: como aumentar a ocupação nos finais de semana?

72
Design Thinking
● Abordagem muito conhecida para solução de problemas
● Não apenas por meio de software
● Inspirada em técnicas usadas por designers (desde 1960)
● Promessa: gerar soluções criativas e inovadoras
● Condução sempre por equipes multidisciplinares

73
Principais Atividades
● Inspiração
● Ideação
● Implementação

74
Inspiração
● Antes de mais nada é importante entender o problema
● Como?
○ Visitar os locais
○ Entrevistar usuários
○ Observar usuários (estudos etnográficos)
○ No limite, se passar por um usuário
● Menor ênfase a questionários e pesquisas de mercado 75
Inspiração: algumas técnicas
1. Observar e conversar com usuários extremos
2. Reframing: reformular o problema

https://hbr.org/2017/01/are-you-solving-the-right-problems 76
Ideação
● Atividade de geração e teste de ideias
● Pensamento divergente e convergente

77
Ideação: Prototipação
● Protótipos (mesmo que de baixa fidelidade)
● Storyboards

78
Implementação
● Após decidir por um protótipo “vencedor”, parte-se para a
sua implementação
● No caso de software, pode ser ainda um MVP

79
Comentário Final
● Design Thinking é um processo aberto e criativo
● Atividades não são sequenciais:
○ Pode-se voltar para uma atividade anterior
○ Repetir o ciclo
● Atividades não tem duração pré-estabelecida
● Equipe não tem tamanho e participantes pré-estabelecidos

80
 Design Sprint

https://engsoftmoderna.info/cap3.html#construindo-o-primeiro-mvp

81
Design Sprint
● “Design Thinking” com regras muito claras
● Time-box: uma semana (2a a 6a feira)
● Equipe: multidisciplinar
○ 7 pessoas, incluindo um tomador de decisões

82
 Design Sprint

https://www.thesprintbook.com/the-design-sprint
83
 Engenharia de Software Moderna

Jobs to be Done (JTBD) Aplicado a Produtos de

Software

Prof. Marco Tulio Valente

https://engsoftmoderna.info/artigos/jobs-to-be-done.html

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides
84
Jobs to be Done (JTBD)
● Teoria que explica porque clientes compram um produto
● Clayton Christensen e colegas (2005)

85
JTBD: Ideia Central
● Contratação não é explicada pelas funcionalidades de um
produto ou software
● Mas sim pelos “trabalhos” que clientes precisam realizar
● “Trabalhos”: demandas, necessidades, anseios, etc

86
JTBD: Ideia Central

87
Perguntas importantes em JTBD
● Por que os clientes contratam nossos produtos?
● Em quais circunstâncias?
● Quais os problemas eles querem resolver?
● Qual o progresso eles querem alcançar?

88
Exemplo: Milk-shakes matinais
● McDonalds vendiam muitos milk-shakes no início da manhã
● Entrevistas ⇒ clientes trabalhavam em outra cidade
○ “Contratavam” os milk-shakes para o seguinte “trabalho”:
tornar a viagem menos tediosa
● Como evoluir o produto milk-shake?
○ Drive-through, suporte para viagem, etc.

89
Exemplo: iPod (2001)

job to be done

91
Exercícios

92
1. Descreva um problema que possa se beneficiar do uso de
Design Thinking (DT) ou de Design Sprint.

2. Sabe-se que software pode ser desenvolvido como um

projeto ou como um produto. Em qual cenário DT ou JTBD
melhor se aplica: projeto ou produto? Justifique sua resposta.

3. Descreva (a) uma característica comum entre JTBD e DT;

(b) o principal conceito novo que JTBD introduz quando
comparado a DT.
 Engenharia de Software Moderna

Shape Up: Uma Possível Alternativa a Scrum?

Prof. Marco Tulio Valente

https://engsoftmoderna.info/artigos/shape-up.html

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides
94
Motivação
● Scrum e XP foram propostos na década de 90
● Conceitos como Modelo Spotify, MVPs, Product discovery
resolvem “problemas específicos” de tais métodos
● Perguntas:
○ Existe algum método ou processo mais novo?
○ O que virá “depois” de métodos ágeis?

95
 Processo de
desenvolvimento da
BaseCamp (2019)

https://basecamp.com/shapeup 96
Três Fases
● Shaping
● Ciclos (~ sprints)
● Cool down

97
Shaping
● Especificação leve de requisitos e projeto (design)
● Resultado: pitch
○ Problema
○ Esboço da solução (sketches ou protótipos de telas)
○ Rabbit holes (soluções para possíveis impasses)

98
Pitches: Solução de meio termo
● Mais detalhados do que histórias de usuários
● Menos detalhados que especificações tradicionais de requisitos

99
Observação
● Em Shape Up, um pitch é um documento simplificado de
especificação de requisitos
● Não tem nada a ver com o uso de pitch como sinônimo de
uma descrição rápida de uma ideia; às vezes, chamados
também de “elevator pitch”

100
Exemplos de Pitches

101
Exemplo de Pitch
Shaping (cont.)
● Quem são os "shapers"?
○ Gerentes sêniores de produto
○ No caso da Basecamp: 4 pessoas
● Processo de escrita:
○ Assíncrono (trilha paralela de shaping)
○ Reunião final, síncrona, para decidir os pitches do
próximo ciclo
104
Ciclos
● Duração: 6 semanas
○ Mais longos do que sprints de Scrum
○ Embora possam existir ciclos de duas semanas
● Não existe prorrogação na duração de um ciclo

105
Times
● Tamanho: 2 devs + 1 designer
○ Menores que os times Scrum
● Autonomia:
○ Implementar pitches (pitch = projeto; e não tarefas)
○ Definir horários de trabalho, reuniões, daily, etc

106
Cool Down
● Duração: 2 semanas
● Tempo para os devs "respirarem"
○ Corrigir bugs
○ Refactorings
○ Pagar dívida técnica
○ Estudar nova tecnologia, etc
● Lembram slacks em XP 107
Exemplo mais real de shaping

108
Motivação: refactoring-aware code reviews

https://github.com/rodrigo-brito/refactoring-aware-diff 109
Problema
● Implementar uma ferramenta que permita realizar
refactoring-aware code reviews em programas Go
● Precisamos detectar refactorings X, Y, Z, etc em Go
● RefDiff: ferramenta para detectar refactorings em commits
● Problema: RefDiff não funciona com Go!

110
Solução (design simplificado)
● Parser dos arquivos modificados em commit
● Usar parser XYZ
● Criar Code Structure Tree (CST); veja documentação
● Implementar call graph
● Acrescentar informações de call graph na CST

111
Solução (arquitetura)

Rodrigo Brito, Marco Tulio Valente. RefDiff4Go: Detecting Refactorings in Go. SBCARS 2020 112
Solução (exemplos)

Rodrigo Brito, Marco Tulio Valente. RefDiff4Go: Detecting Refactorings in Go. SBCARS 2020 113
Rabbit Holes
● Implementação de um call graph não é trivial
● Usar uma implementação simples:
○ Análise sintática bem simples
○ Sem considerar polimorfismo, interfaces, etc
○ Restrita aos arquivos modificados no commit

114
 shaping ⇨ pitch

pitch = problema + solução + rabbit holes

simplificado

115
Exercícios

116
1. Qual a diferença entre a fase de shaping e o planejamento
do sprint (sprint planning) em Scrum?

2. Qual a principal característica que torna Shape Up um

método adequado para times remotos?

3. Pense em um pitch para um determinado problema ou

sistema. (a) Explique brevemente o seu pitch; (b) Descreva
brevemente um “rabbit hole” que deveria ser documentado
neste pitch.
 Engenharia de Software Moderna

Estudo de Caso: Exemplo de um Squad para

Implementação do PIX em um Banco X

Prof. Marco Tulio Valente

https://engsoftmoderna.info, @engsoftmoderna

Licença CC-BY; permite copiar, distribuir, adaptar etc; porém, créditos devem ser dados ao autor dos slides
118
Motivação: PIX no Banco X
● Banco Central regulamentou o PIX
● Então, o banco X quer permitir esse tipo de transferência
● Isso ficará a cargo do squad (time) de serviços de transferência
● Esse squad já cuida dos demais tipos de transferência (entre
contas, TED, DOC, etc)

Importante: esse exemplo e o banco X são hipotéticos; algumas

simplificações também foram realizadas, para fins didáticos 119
Squad de Transferências (hipotético)
● 1 Project Owner (PO)
● 1 Scrum Master (SM)
● 1 UI/UX Designer
● 1 dev de frontend Web
● 1 dev mobile
● 2 devs de backend

120
Product Owner (ou Product Manager)
● Deve estudar e entender os requisitos do Banco Central...
● Para isso, pode contar com o apoio das áreas de negócio do
banco (analistas financeiros, bancários, etc)
● Deve explicar para o time como o PIX funciona e “o que” tem
que ser implementado; deve também explicar o cronograma do
projeto; pois existe uma data para o PIX entrar no ar
● Deve propor e escrever as principais histórias de usuários (e
também definir seus testes de aceitação)
● Deve tirar dúvidas que surgirem durante os sprints 121
UI/UX Designer
● Deve entender bem os requisitos do PIX
● Entrevistar e conversar com usuários
● Criar um protótipo de UI (usando mockups, wireframe, etc) e
ferramentas como Figma
● Testar esse protótipo com usuários do banco

122
Frontend Devs e Mobile Devs
● Vão implementar a interface projetada pelo UI/UX designer
● Usando frameworks como React, React Native, Flutter, etc
● Podem também sugerir e participar de testes com usuários,
junto com o UI/UX designers
● Implementar testes automatizados (E2E), usando cypress etc

123
Backend devs
● Vão implementar a “lógica” do PIX no banco X
● Incluindo regras de negócio, persistência em bancos de dados,
protocolos de comunicação com o Bacen e outros bancos.
● Devem pensar também em requisitos não-funcionais, como
segurança, privacidade, disponibilidade, desempenho, etc.
● Implementar testes de unidade e de integração

124
Scrum Master (ou Agile Master/Coach)
● Acompanhar a implementação do PIX e ajudar o time a seguir
o processo de desenvolvimento do banco
● Organizar e facilitar os eventos de um sprint, tais como
reuniões de planejamento, reuniões diárias, revisão e
retrospectiva
● Atuar como “líder servidor” ajudando o time a remover
impedimentos não-técnicos que vão surgir durante a
implementação
125
Como começar de fato?

126
Workshop de Inception (ou de “Discovery”)
● Participantes: todos os membros do time e alguns outros
stakeholders importantes do projeto
● Em um projeto dessa complexidade, pode durar alguns dias
● Definir os objetivos e cronograma do projeto
● Definir principais tarefas e histórias de usuário
● Identificar e mapear eventuais riscos e obstáculos
● Criar primeira versão do backlog do produto
● Definir objetivos dos primeiros sprints 127
Outras Preocupações
● Infraestrutura / DevOps:
○ Onde o serviço vai rodar? Na nuvem? Local (on-premises)?
○ Temos infraestrutura adequada? Precisamos provisionar?
○ Essas decisões ficam a cargo de um time de infraestrutura
● Qualidade / QA (“Quality Assurance”)
○ Algumas empresas possuem profissionais para QA
○ Ajudam PO a escrever testes de aceitação; e executam tais
testes e validações ao final dos sprints 128
Exercícios
1. Defina três histórias de usuários do projeto PIX no banco X
2. Suponha que o projeto PIX no Banco X foi concluído com
sucesso. Meses depois, o Banco Central baixou a seguinte
regra: transferências via PIX entre 20:00 e 06:00 são limitadas
a R$ 1.000,00. Qual seria o papel de cada membro do time na
implementação dessa nova regra? Descreva de forma
simplificada.

129