Lean Software Engineering - como desenvolver seu MVP

Prévia do material em texto

Lean Software Engineering
como desenvolver seu MVP
Paulo Caroli and Alexandre Corrêa Barbosa
This book is for sale at http://leanpub.com/leanengineering
This version was published on 2020-05-17
This is a Leanpub book. Leanpub empowers authors and
publishers with the Lean Publishing process. Lean Publishing is
the act of publishing an in-progress ebook using lightweight tools
and many iterations to get reader feedback, pivot until you have
the right book and build traction once you do.
© 2019 - 2020 Paulo Caroli and Alexandre Corrêa Barbosa
http://leanpub.com/leanengineering
http://leanpub.com/
http://leanpub.com/manifesto
Contents
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Mindmap . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Eu sou um Dev . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Eu sou um facilitador . . . . . . . . . . . . . . . . . . . . . . iv
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Preparando as Fundações do
Produto . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Arquitetura Mínima Viável . . . . . . . . . . . . . . . . . 2
Atividades para definição dos Requisitos Cross-Funcionais 7
MVA e arquitetura Evolutiva . . . . . . . . . . . . . . . . 10
Preparando para entregar con-
tinuamente . . . . . . . . . . . . . . . . . . . . . . . 12
Crie o Pipeline inicial de Entrega Contínua . . . . . . . . . 13
Pipeline de Entrega Contínua . . . . . . . . . . . . . . . . 13
Prepare o Ambiente de Desenvolvimento . . . . . . . . . 16
Comece com um Controle de Versão . . . . . . . . . . . . 16
Utilize um Trunk único . . . . . . . . . . . . . . . . . . . 18
Modele a Infraestrutura como Código . . . . . . . . . . . 19
CONTENTS
Entenda Entrega Contínua . . . . . . . . . . . . . . . . . 20
Evolua o Pipeline inicial . . . . . . . . . . . . . . . . . . . 22
Integre continuamente . . . . . . . . . . . . . . . . . . . . . 24
Automatize os Testes automatizados (introduzir TDD) . 25
Sobre TDD . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Testes unitários . . . . . . . . . . . . . . . . . . . . . . . . 25
Testes funcionais . . . . . . . . . . . . . . . . . . . . . . . 26
Automatize a Análise estática de código . . . . . . . . . . 26
ArchUnit (princípios de evolutionary architecture) . . . 26
Deploy não precisa ser Release . . . . . . . . . . . . . . . . 27
Feature Toggle . . . . . . . . . . . . . . . . . . . . . . . . 28
Defina um feature toggle . . . . . . . . . . . . . . . . . . 29
Toggles de longa duração . . . . . . . . . . . . . . . . . . 29
Restrinja o acesso via toggle . . . . . . . . . . . . . . . . 30
Squad de produto . . . . . . . . . . . . . . . . 32
Lean Inception, produto e a equipe . . . . . . . . . . . . . . 33
Objetivos do Squad de Produto . . . . . . . . . . . . . . . . 36
Desenvolvimento Iterativo . . . . . . . . . . . . . . . . . . . 37
Sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A Sprint Zero . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Atividades da Sprint 0 . . . . . . . . . . . . . . . . . . . . . . 41
Tarefas de set-up . . . . . . . . . . . . . . . . . . . . . . . 41
Atividade: Moscou . . . . . . . . . . . . . . . . . . . . . . 42
Atividade Votação Mais / Menos . . . . . . . . . . . . . . 43
Atividade: Quem/O que/Quando . . . . . . . . . . . . . . 44
Path to Production . . . . . . . . . . . . . . . . . . . . . . 45
CONTENTS
MinimumViableArchitecture (MVA)
46
Arquitetura Mínima Viável (MVA) . . . . . . . . . . . . . . 47
Micro-serviços de Domínio . . . . . . . . . . . . . . . . . 48
Registro de Decisão de Arquitetura . . . . . . . . . . . . . . 49
Compartimentalização . . . . . . . . . . . . . . . . . . . . . 50
Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Métricas acionáveis . . . . . . . . . . . . . . . . . . . . . 52
Dados para Métrica . . . . . . . . . . . . . . . . . . . . . 53
Analisando os resultados . . . . . . . . . . . . . . . . . . 53
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
DRAFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
MVP como início do empreendimento . . . . . . . . . . . 55
Small batches . . . . . . . . . . . . . . . . . . . . . . . . . 55
Entrega Contínua . . . . . . . . . . . . . . . . . . . . . . . 57
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Sobre Alexandre Corrêa Barbosa . . . . . . . . . . . . . . . 59
Sobre Paulo Caroli . . . . . . . . . . . . . . . . . . . . . . . . 60
Sobre a Editora Caroli . . . . . . . . . . . . . . . . . . . . . . 61
WIP (Writing In Progress) . . . . . . . . . . . . . . . . . . 61
Disclaimer
Estamos tratando esse E-Book como um MVP. Se já tem algo
minimamente viável para passar a ideia, o conceito, então está
disponível.
Por isso neste E-Book você vai encontrar erros de ortografia,
imagens em versões iniciais, e texto por escrever.
Mas como um bom MVP, estamos muito interessados no seu
feedback.
Abraços,
Paulo Caroli e Alexandre Barbosa
Mindmap
Segue um mindmap de assuntos que queremos tratar no livro:
Disclaimer ii
Eu sou um Dev
Eu, Alexandre, sou um desenvolvedor. Adoro participar da Lean
Inception. Mas após discutir e planejar o MVP e suas funcional-
idades, eu quero ir logo para a minha estação de trabalho. Eu
quero começar a implementar todas as ideias maravilhosas que
conversamos na Lean Inception.
Essa empolgação é excelente, mas neste momento, preciso res-
pirar fundo. Preciso segurar a minha ansiedade em codar essas
funcionalidades; É necessário fazer algo essencial, mas que, para
muitas pessoas, não é tão excitante: Preciso criar o pipeline e a
infraestrutura para o desenvolvimento do MVP.
O pipeline é a estrutura inicial que leva o código da minha máquina
até o MVP nas mãos dos meus clientes.
Mas esse pipeline deve ser Lean. Afinal de contas, no mundo atual,
não podemos demorar a entregar valor e validar nossas ideias.a
Nesse livro você encontra práticas que chamamos de Lean Engi-
neering. Práticas para a construção desse pipeline e o ferramental
para te ajudar a efetivamente criar e operar seu MVP.
Eu sou um facilitador
Eu, Paulo Caroli, sou um facilitador de Lean Inception. Adoro fa-
cilitar uma Lean Inception. Adoro ver o grupo de pessoas alinhado
sobre o MVP a construir.
Mas não saio completamente satisfeito da mesma. A minha satis-
fação está no sucesso da equipe. E, para tanto, há mais do que a
Lean Inception.
Por exemplo, a excelência técnica sobre como construir oMVP. Não
estou falando sobre o que construir, ou sobre que processo utilizar.
Mas sim das práticas de engenharia que suportam este estilo – Lean
– de criação e evolução de produtos digitais.
Esse livro é para as pessoas interessadas nas práticas de engenharia
que suportam este estilo – Lean – de criação e evolução de produtos
digitais.
Eu era um desenvolvedor e trabalho muna empresa com excelentes
desenvolvedores, dentre eles, o Alexandre – um dos desenvolve-
dores mais experientes do Brasil. Trabalhamos juntos em alguns
projetos, e agora, estamos juntos na criação e evolução deste e-book.
Introdução
Lean Engineering é formado por uma série de práticas e técnicas
que nós utilizamos para criar e manter um MVP. Após a realização
da Lean Inception, a equipe tem em mãos uma série de requisitos
descrevendo o que deve ser o produto.
O livro Lean Inception descreve como alinhar um grupo de pessoas
sobre o MVP. Este eBook é para os desenvolvedores, para os engen-
heiros de software, para as pessoas que criam as funcionalidades
dos produtos digitais. Mas não é para todos.
Esse livro é para as desenvolvedoras que criam funcionalidades
para o MVP. Desenvolvedoras que trabalham no estilo Lean, desen-
volvedoras que seguem o estilo Lean StartUp, desenvolvedoras que
participam de Lean Inceptions, que entendem o conceito de MVP
e que buscam as melhores técnicas da engenharia de software para
encantar os clientes e o negócio.
Preparando as
Fundações do
Produto
Acabou a semanada inception enxuta, e agora o time está alinhado
sobre o que deseja alcançar com o MVP, e quais as primeiras
funcionalidades que serão criadas. A motivação e a energia de
todas está em alta, e como pessoas desenvolvedoras queremos
rapidamente começar a programar. No entanto, as funcionalidades
do MVP ainda estão descritas em alto nível. Neste momento, é
importante que a equipe de desenvolvimento invista ainda algum
tempo para definir as fundações técnicas que facilitarão o desen-
volvimento iterativo e sustentável do produto.
Arquitetura Mínima Viável
Uma ideia não tão incomum em desenvolvimento de software é
a de que ao desenvolver um MVP não é necessário planejar sua
arquitetura. No entanto, é importante notar que, independente-
mente de planejar ou não, seu sistema sempre terá uma arquitetura:
a diferença é que quando se permite que a arquitetura surja ao
acaso, aumentamos o risco de termos um sistema que não atende às
necessidades das nossas clientes, e seja difícil de manter e evoluir.
3
O que é Arquitetura neste contexto?
Arquitetura é um termo usado extensivamente e que possui
muitas interpretações em nossa área. Não iremos tentar definí-
la neste livro (outras pessoas mais competentes já o fizeram
- recomendamos a leitura dos volumes 1 e 2 do Software
Architeture for Developers), mas vamos esclarecer o que
entendemos como resultado do processo da definição de uma
arquitetura. O resultado mais importante é a criação de uma
visão para o time de desenvolvimento de como construir
o produto, definida: * pela estrututa que será utilizados no
código (camadas, MVC, arquitetura clean, cebola, portas e
adaptadores, entre outros); * pelas tecnologias base (linguagens
e frameworks utilizados, por exemplo) * pela arquitetura de
componentes do sistema (monolito, SOA, microsserviços, etc)
* infraestrutura padrão (nuvem, on premise, virtualização,
mecanismo de deployment, etc) Estas definições permitirão
que o time de desenvolvimento compartilhe uma mesma visão
de sistema, permitindo que as funcionalidades sejam desen-
volvidas de forma consistente, e de forma a mitigar o risco de
não atender às diferentes necessidades do produto.
https://leanpub.com/b/software-architecture
Por outro lado, a experiência dos tempos do desenvolvimento
em cascata em que se perde semanas ou meses planejando cada
detalhe da arquitetura do sistema - o famoso Big Design Up Front
- é algo que se mostra tão ou mais prejudicial quanto nenhum
planejamento. O que você precisa é encontrar o meio termo, que
definimos como arquitetura mínima viável (MVA)¹.
¹https://www.infoq.com/news/2014/11/minimum-viable-architecture/
https://leanpub.com/b/software-architecture
https://leanpub.com/b/software-architecture
https://leanpub.com/b/software-architecture
https://www.infoq.com/news/2014/11/minimum-viable-architecture/
https://www.infoq.com/news/2014/11/minimum-viable-architecture/
4
MVA é o ponto de equilíbrio entre nenhum planejamento e muito planejamento
Um primeiro passo para definirmos a arquitetura mínima viável do
seu produto é identificar os principais fatores externos que serão
especialmente importantes nos primeiros momentos de vida do seu
MVP. Estes fatores externos são também conhecidos como req-
uisito cross-funcionais, requisitos não funcionais, entre outros
termos. Abaixo, pode-se visualizar alguns exemplos:
acessibilidade auditoria consistência
custo disponibilidade escalabilidade
fatores
regulatórios
integridade performance
privacidade rastreabilidade resiliência
reusabilidade segurança sustentabilidade
tolerância a falhas testabilidade usabilidade
A lista anterior é só uma pequena amostra de diferentes fatores que
podem impactar o desenho da arquitetura do produto. É importante
observar, que muitos destes fatores muitas vezes competem entre
si. Um exemplo clássico é o par Segurança e Usabilidade. Esta com-
petição torna necessária não somente a identificação dos requisitos
cross-funcionais importantes para o MVA, mas também a prior-
ização. Isto permite entendermos qual fator é mais importante, no
momento que tivermos que lidar com os conflitos entre diferentes
requisitos.
É importante ressaltar que para começarmos a pensar no MVA,
devemos focar no que é importante para o MVP. É comum trazer
preocupações que provavelmente serão importantes no futuro, ou
5
itens que se imagina ser simples de se resolver agora - por exemplo,
internacionalização; em geral, oMVP será testado inicialmente com
clientes que compartilham o mesmo idioma, mas se o produto for
bem sucedido, certamente será oferecido em outros idiomas. Um
conjunto de perguntas que podem ajudar sua equipe a focar no que
é importante para o MVP:
• Quantos usuários utilizarão o sistema no lançamento inicial?
Nos primeiros 6 meses? Após um ano?
• Os usuários iniciais serão internos, externos, ou ambos?
• Quantas transações por segundo esperamos no lançamento?
Nos primeiros 6 meses? Após um ano?
• Como os usuários começarão a utilizar o sistema?
• Qual o nível de segurança e auditabilidade exigido no lança-
mento? Dentro de 6 meses? Após um ano?
Há diversas outras perguntas para guiar a discussão. Estas pergun-
tas ajudam a equipe a definir os requisitos básicos para lançar no
mercado. Embora não entre no mérito de definir uma arquitetura
completa e perfeita para o produto final, isto é diferente de ignorar
a definição de uma boa arquitetura. O foco é no quanto de inves-
timento é necessário para lançar e, em seguida, definir um plano
para evoluir a arquitetura conforme o número de usuários aumenta
e requisitos são adicionados.
Tentar construir o sistema perfeito raramente é a abordagem cor-
reta. Vamos dizer que a resposta do dono do produto para estas
perguntas sejam as seguintes:
• Haverá apenas cinco usuários internos nos primeiros três
meses. Seis meses a partir de agora os nossos dois primeiros
clientes externos estarão usando os sistemas em modo piloto.
Um ano a partir de agora lançaremos o sistema para todos os
clientes.
6
• No lançamento haverá uma quantidade trivial de transações.
Daqui a seis meses o tráfego será moderado. No próximo ano,
o tráfego será extremo.
• Inicialmente, adicionaremos usuários ao sistema através de
uma interface. No futuro, os clientes terão gestão de ID self-
service. Espero que isto aconteça em um ano a partir de agora.
• Nós só precisamos de segurança mínima para a primeira ver-
são. Para o piloto, precisamos de segurança e audit completos.
Com base nessas respostas, muita discussão e definição pode ser
adiada para após o lançamento da primeira versão. Por que gastar
tempo na estratégia de cache agora, quando não vemos a necessi-
dade no horizonte de um ano? Nós podemos colocar fora diversas
tarefas de gerenciamento de ID para mais tarde também. Deve-se
evitar discussões imediatas sobre requisitos que só virão no futuro,
de forma que seja implementado apenas o estritamente necessário
da melhor forma possível. É por isso que o MVA é tão importante.
Esta abordagem depende da disciplina e confiança entre o dono
do produto e da equipe de desenvolvimento, para garantir que
ambas obtenham os resultados desejados: o produto é entregue
rapidamente com um sistema bem arquitetado e com pouca dívida
técnica.
Em se tratando do desenvolvimento de um MVP, dois fatores
que certamente devem ser levados em consideração são velocidade
de desenvolvimento e evolucionabilidade, uma vez que desejamos
aprender rapidamente com as clientes, e também adaptar rapida-
mente o produto de acordo com os aprendizados.
7
Atividades para definição dos
Requisitos Cross-Funcionais
Dentro-Fora do MVA
Dentro-Fora é um jogo para crianças pequenas, bem simples, que
consiste em primeiro desenhar um círculo grande no chão (tipi-
camente com um giz no pátio das escolas), depois posicionar as
crianças em volta dele, e então, dar o comando “DENTRO” ou
“FORA”, para que as crianças pulem (e aprendam o que é dentro
e fora).
A atividade Dentro-Fora do MVA é similar a atividade infantil,
entretanto seu objetivo verificar cada RCF, decidindose este deve
estar dentro ou fora do círculo. A diferença é que o círculo repre-
senta a MVA, que somente cabe cinco cartões RCF. Desta formaos
participantes terão de priorizá-los.
exemplo de resultado – Dentro-Fora do MVA
Passo a Passo da atividade
1. Escreve ou imprima os RCF mais relevantes para o MVA em
post-its
8
2. Desenhe um círculo de tamanha pequeno (que somente caiba
cinco cartões de RCF)
3. Coloque todos cartões RCF ao redor do círculo.
4. Como um ponteiro de um relógio, comece nas 0 hs (seguindo
no sentido horário – 1,2,3…) e leia o cartão de RCF e decida
se este é muito importante a ponto de colocá-lo dentro do
círculo. Se colocar dentro do círculo, respeite o limite de
somente ter 5 cartões dentro do círculo. Se alcançar o limite,
converse em grupo sobre qual cartão deve sair do círculo.
5. Faça duas voltas no “relógio” para verificar se todos estão de
acordo com os cinco RCF finalistas dentro do círculo.
Trade-offs dos RCF
Trade-off é uma troca em que você desprioriza algo para conseguir
outro que deseja ainda mais. Uma MVA reflete decisões da equipe
em relação a trade-offs dos requisitos cross funcionais (RCF).
A atividade Trade-offs dos RCF ajuda na construção e documen-
tação de um entendimento comum sobre os trade-offs dos RCF
para o momento atual. Muitas decisões e conversas são baseadas
em visões individuais e premissas entre escolhas. Alguns exemplos:
o que tem um valor maior neste momento da arquitetura do MVP:
a segurança ou a facilidade de usar? E quanto a escalabilidade e
segurança? E escalabilidade e facilidade de usar? Esta atividade
promove uma conversa aberta e colaborativa sobre os trade offs.
Trade-offs mais esclarecidos evitam desentendimentos e ajudam na
rápida tomada de decisões, essenciais para a *Lean Engineering”.
9
exemplo de resultado – trade offs do produto enxuto
Passo a Passo da atividade
1. Descreva os RCF mais relevantes para o MVA em post-its
(exemplo: segurança, usabilidade, escalabilidade).
2. Coloque os RCF no quadro branco ou flipchart como títulos
de linhas. Em seguida, desenhe uma linha horizontal para
cada RCF.
3. Desenhe linhas verticais (o mesmo número de linhas horizon-
tais). Escreva “+” (mais importante) em cima da linha mais à
esquerda e “-“ (menos importante) em cima da linha mais à
direita.
4. Peça aos participantes para marcar suas iniciais em vários
post-its e colocar um post-it por linha. A restrição: cada
coluna deve ter um post-it com suas iniciais (por exemplo,
apenas uma das categorias vai ser marcada como mais im-
portante).
5. Equalize os trade-offs. Com um post-it de cor diferente (uma
tira de post-it de outra cor na foto ilustrativa), faça amarcação
10
devida para cada categoria, de mais a menos importante. Esta
marcação será relativamente fácil, já que considera os post-its
com os votos de todos.
outro exemplo de resultado – trade offs de RCF
MVA e arquitetura Evolutiva
No livro Building Evolutionary Architectures ² os autores sugerem
um novo fator a ser considerado: a *Evolucionabilidade. Podemos
entender evolucionabilidade como a característica da arquitetura
do produto, que corresponde a quão fácil ou difícil é implementar
mudanças sem degradar os outros requisitos cross-funcionais.
A evolucionabilidade é uma qualidade relacionada aomédio e longo
prazo da arquitetura, que compete com preocupações de curto
²KUA, Patrick; PARSONS, Rebecca; FORD, Neal. Building Evolutionary Architectures.
O’Reilly Media, Inc. 2017.
11
prazo.
Se o objetivo doMVP é validar uma hipótese omais rápido possível,
não é necessário se preocupar com a evolucionabilidade. O melhor
a se fazer é focar em uma arquitetura mínima, que permita validar a
hipótese. Uma vez validada a hipótese, o código e a arquitetura em
questão deve ser convertido de aspectos de validação (da hipótese)
para aspectos de evolução.
O código de umMVP validado é a base para a evolução do produto,
então temos que tratar a evolucionabilidade da arquitetura inicial.
Ou seja, do ponto de vista da arquitetura de software, a MVA deve
prover o mínimo necessário para o código de validação da hipótese,
bem como o mínimo para a evolucionabilidade do produto.
Preparando para
entregar
continuamente
Crie o Pipeline inicial de
Entrega Contínua
Software funcionando é a medida primária de pro-
gresso³
A frase acima é um dos doze princípios definidos no Manifesto
Ágil, e define de forma muito clara um dos principais objetivos das
desenvolvedoras: colocar software em produção. Ou seja, validar
e testar uma funcionalidade na sua máquina, ou em um ambiente
intermediário (como QA, staging ou homologação) não é suficiente
para considerarmos a tarefa ou história pronta. Para estar finalizado
de fato, o código desenvolvido tem que estar no ambiente de
produção.
Você busca entregar histórias e tarefas diariamente, portanto pre-
cisa de uma forma eficiente de realizar o deploy no ambiente de
produção. Por isso, você precisa, começar com um Pipeline de
Entrega Contínua.
Pipeline de Entrega Contínua
O Pipeline de Entrega Contínua é composto pelos processos au-
tomatizados responsáveis por disponibilizar o software que de-
senvolvemos nas mãos das usuárias. Note-se aqui a ênfase em
automação. Quanto maior a quantidade de intervenções humanas
neste processo, menor a repetibilidade deste processo, e em conse-
quência menor sua confiabilidade.
³Princípios por trás do Manifesto Ágil
https://agilemanifesto.org/iso/ptbr/principles.html
Crie o Pipeline inicial de Entrega Contínua 14
Este processo será exercitado milhares de vezes durante a vida do
seu produto. Quando completo e evoluído, este terá vários módulos
e linhas de código para iniciar processos e sub-processos. Mas no
início de tudo, na primeira linha de código do seu software, o
Pipeline de Entrega Contínua será bem simples.
Dado a sua importância e sua simplicidade (no início), o Pipeline
de Entrega Contínua deve ser o primeiro entregável da equipe de
desenvolvimento.
O Pipeline deve apresentar uma versão funcional, antes mesmo da
criação do código funcional da primeira funcionalidade. Seguindo
um estilo Lean, o pipeline evolui num processo incremental, acom-
panhando o desenvolvimento incremental do produto de software.
Segue uma ilustração de uma ideia mais concreta sobre o que
compõe uma Pipeline de Entrega Contínua:
Exemplo de Pipeline de Entrega Contínua
O seu pipeline inicial deve ser simples, com passos que posterior-
mente serão automatizados ou incluídos. Você deve decidir se todos
testes iniciais serão automatizados, ou se alguns serão manuais.
Você deve postergar a criação de alguns testes de segurança e
performance. Você, provavelmente, vai postergar algum passo,
Crie o Pipeline inicial de Entrega Contínua 15
alguma automação que coloca o release em produção, e usar algo
manual ou semi-automatizado.
Neste momento inicial, você não precisa definir exatamente como
será o pipeline completo. Todos os detalhes e decisões irão surgir
de acordo com a evolução do software.
Para começar, foque no essencial, no pipeline mínimo que disponi-
biliza o software no ambiente onde os seus usuários podem usá-lo.
Portanto, comece com o seguinte pipeline:
Pipeline inicial
Note no pipeline inicial que o último passo é oDeploy em Ambiente
de Produção. Todavia, no exemplo anterior o ultimo passo era
Release. Mais adiante compartilharemos sobre a diferença entre
deploy e release, mas neste momento não faremos distinção entre
estes passos.
Nosso objetivo agora é implantar automaticamente nosso produto
em ambiente de produção, o ambiente onde os primeiros usuários
poderão acessar o produto. Provavelmente as primeiras pessoas não
serão os usuarios finais, mas a equipe de desenvolvimento, ou um
grupo selecionado de poucas pessoas.
Talvez este “ambiente de produção” ainda não esteja ainda disponível
Crie o Pipeline inicial de Entrega Contínua 16
fora da rede de sua organização. Este ambiente irá evoluir como
todo seu produto.
Prepare o Ambiente de
Desenvolvimento
Ao iniciar o desenvolvimento deum produto de software é fun-
damental ter um ambiente de desenvolvimento estável e de fácil
acesso a todos os desenvolvedores.
Nos tempos onde hardware e licenças de software eram muito
caras era comum se utilizar um ambiente de desenvolvimento
compartilhado. Esse ambiente normalmente era instável, já que as
modificações de um desenvolvedor podiam afetar o trabalho de
outro desenvolvedor.
Hoje em dia, com a utilização de máquinas virtuais ou containers e
uso de software open source, é muito fácil para um desenvolvedor
ter em suamáquina de trabalho tudo que é necessário para executar
um produto. Isso permite que seja mais fácil a criação de local de
desenvolvimento.
Para facilitar a criação destes ambientes de desenvolvimento locais
é importante fazer o uso de ferramentas de automação para que,
com a execução de um simples comando, um novo desenvolvedor
na equipe possa ter seu ambiente de desenvolvimento pronto em
alguns minutos.
Comece com um Controle de Versão
Sua equipe tem mais de uma pessoa desenvolvedora? Se sim, então
comece com um Controle de Versão no seu pipeline. Essa é a
forma mais simples de compartilhar e intregar o que todas pessoas
Crie o Pipeline inicial de Entrega Contínua 17
estão criando, de forma contínua - em outras palavras, garantir a
Integração Contínua do software.
Alias, mesmo que você esteja trabalhando sozinha, utilizar um
sistema de controle de versão é tão simples e fácil, que não faz
sentido deixar para adicioná-lo depois. Ele provê outros benefícios,
como backup – ter uma cópia além da que existe na sua máquina–
e manter um registro histórico das mudanças.
Nos capítulos a seguir você vai acompanhar a evolução de um
código exemplo via um sistema de Controle de Versão, onde incre-
mentamos o pipeline, num passo a passo, enquanto compartilhamos
cada tópico abordado no livro, tais como Trunk-based development,
Feature branching, Gitflow, etc.
Terraform
1 variable "heroku_email" {
2 type = string
3 }
4
5 variable "heroku_api_key" {
6 type = string
7 }
8
9 provider "heroku" {
10 version = "~>2.1"
11 email = "${var.heroku_email}"
12 api_key = "${var.heroku_api_key}"
13 }
14
15 resource "heroku_app" "leb-webapp" {
16 name = "leb-webapp"
17 region = "us"
18 }
19
20 resource "heroku_build" "leb-webapp-build" {
21 app = "leb-webapp"
Crie o Pipeline inicial de Entrega Contínua 18
22 buildpacks = ["https://github.com/heroku/heroku-buildpa\
23 ck-static"]
24
25 source = {
26 path = "../frontend"
27 }
28 }
Desta forma, antes de qualquer coisa, crie o repositório do seu
projeto no seu sistema de preferência. Recomendamos que você leia
este livro enquanto escreve e evolui seu código exemplo, de forma
Lean. Relembramos que este livro é para desenvolvedores. Por isso
assumidos que, por mais que você goste de ler um bom livro, você
prefere escrever código.
Utilize um Trunk único
O Trunk based development⁴ é uma prática onde todos os dese-
volvidores fazem os commits em um único branch, o trunk, e não
são utilizadas outras branches para desenvolvimento.
Esta prática surgiu como uma resposta aos problemas encontrados
na utilização de feature branches. Um dos grandes problemas da
utilização de feature branches é a divergência dos códigos nas
branches, causando grande problemas de integração perto das
releases.
A útilização do trunk único em combinação com a integração
contínua, permite que o código no trunk esteja sempre estável,
facilitando pequenas entregas.
⁴http://paulhammant.com/2013/04/05/what-is-trunk-based-development/
http://paulhammant.com/2013/04/05/what-is-trunk-based-development/
http://paulhammant.com/2013/04/05/what-is-trunk-based-development/
Crie o Pipeline inicial de Entrega Contínua 19
Modele a Infraestrutura como
Código
Modele a infraestrutura como se fosse código, de modo que sua ab-
stração, design, implementação e deploy ocorra da mesma maneira
que utilizamos quando desenvolvendo aplicações. Assim, trabalha-
se com esse código utilizando as mesmas ferramentas e práticas que
são utilizadas em projetos modernos de software.
O código que modela, builda e gerencia a infraestrutura é sub-
metido ao sistema de controle de versão juntamente com o código
da aplicação, tornando o setup controlado e repetível. A mudança
de pensamento é que a infraestrutura deve ser redeployavel a partir
do código; um código que deve ser desenvolvido utilizando as
metodologias já estabelecidas em anos em que a indústria amadure-
ceu.
Para atingir o objetivo de ter a infraestrutura como código, algumas
práticas são recomendadas. A primeira delas é definir toda a
infrasestrutura em arquivos de configuração executáveis, seja em
shell scripts, Chef, Puppet, ou qualquer que seja a ferramenta.
Ninguém deve entrar em um servidor de aplicação e fazer ajustes
manualmente. Este comportamento leva à um servidor instável,
gerando riscos. Com arquivos de configuração, qualquer membro
da equipe pode reproduzir o ambiente de produção, inclusive
quando está desenvolvendo. Outro benefício é a possibilidade de
updates rápidos, já que o provisionamento se torna automatizado,
ao invés de manual.
Havendo arquivos de configuração, estes devem ser mantidos em
um sistema de controle de versão. Toda e qualquer mudança
deixará um rastro, quer permite verificar como era a infraestrutura
da aplicação em um dado momento do tempo. Também deve-se
testar estes arquivos de configuração, preferentemente de forma
automatizada e como parte do sistema de integração contínua da
aplicação. Em um cenário ideal, é possível realizar entrega contínua
Crie o Pipeline inicial de Entrega Contínua 20
de mudanças de infraestrutura. Tal qual deve ser feito com código
de aplicação, a infraestrutura deve ser entregue incrementalmente
e frequentemente.
Entenda Entrega Contínua
Jez Humble e David Farley, em 2010, publicaram o livroContinuous
Delivery ⁵. Neste livro, os autores elaboram sobre um processo de
entrega rápido e de baixo custo, permitindo a criação incremental
de produtos de software. Eles definem Continuous Delivery (em
português, Entrega Contínua) como uma disciplina de desenvolvi-
mento de software que promove entregas mais rápidas e commaior
frequência.
Segundo os autores, realizar o deploy de um software é muito
mais que instalar um artefato em alguma máquina, seja como um
arquivo executável, ou um pacote em um servidor de aplicação. Eles
dividem a implantação de software em três partes:
1. Provisionar e gerenciar o ambiente no qual a aplicação irá
rodar (configuração de hardware, software, infraestrutura, e
serviços externos).
2. Instalar a versão correta da aplicação.
3. Configurar a aplicação, incluindo qualquer dado ou estado
necessário. ⁶ (p. 25)
Para permitir a entrega frequente de novas funcionalidades é
necessário um alto nível de automação. Além de muitas vezes ser
mais rápido do que fazer manualmente, a automação permite que
se crie um processo repetível, ou seja, todo vez que o processo for
executado com as mesmas entradas vai obter as mesmas saídas.
⁵HUMBLE, Jez and FARLEY, David. Continuous Delivery: Reliable Software Releases
through Build, Test, and Deployment Automation, Addison-Wesley, 2010.
⁶HUMBLE, Jez and FARLEY, David. Continuous Delivery: Reliable Software Releases
through Build, Test, and Deployment Automation, Addison-Wesley, 2010.
Crie o Pipeline inicial de Entrega Contínua 21
Provisione o Ambiente de Produção
Há uma série de opções quando se trata de definir a infraestrutura
dos produtos digitais:
1. so o ambiente pode ter seu próprio conjunto de máquinas
físicas, ou
2. se podemos utilizar um provedor de infraestrutura como
serviço (IaaS) como AWS ou Azure, ou
3. se podemos usar um provedor de plataformas como serviço
(PaaS) como Heroku ou Dokku, ou
4. se podemos usar uma combinação dos três.
Qualquer que seja seu caso, voce deve gerir a sua infraestrutura
através de scripts, de forma que possam ser executados de forma
automatizada, ou semi-automatizada (para versões iniciais do seu
pipeline).
Desta forma, a toda e qualquerparte da sua infraestrutura é
definida através de código, utilizando ferramentas tais como scripts
shell, Puppet, Chef, Ansible, Terraform, entre outras. Este código,
como qualquer outro, deve estar no Controle de Versão, e toda
e qualquer mudança na infraestrutura deve ser feita através de
mudanças no código.
aqui vamos adicionar um script exemplo para provi-
sionar um ambiente de produção
Instale a aplicação no Ambiente de
Produção
Após definir e provisionar a infraestrutura básica do Ambiente de
Produção, o próximo passo é instalar a aplicação no ambiente de
Crie o Pipeline inicial de Entrega Contínua 22
produção. Para tanto, voce deve gerar um artefato adequado para
sua infraestrutura (pacote debian/rpm, imagem docker, arquivo
zip, etc) e implantá-lo. Novamente, este passo ser um realizado
via um script. Desta forma, ele pode ser automatizado ou semi-
automatizado, onde a única interação humana seja apertar um
botão (ou digitar um comando) para ser iniciado. Scripts shell são
uma escolha bastante comum.
aqui vamos adicionar um script exemplo para instalar
uma aplicação (“Hello World”) no ambiente de pro-
dução
Configure a aplicação
Uma vez que a aplicação esteja instalada no ambiente de produção,
você deve configurar a mesma. Mais uma vez, realize esta tarefa a
partir de script com código e dados, de forma que tal código esteja
no controle de versão e possa ser executado, automaticamente ou
semi-automaticamente.
aqui vamos adicionar um script exemplo para con-
figurar a aplicação (passando o parâmetro “Hello
World”) no ambiente de produção
Evolua o Pipeline inicial
Finalizado nosso pipeline inicial, temos a habilidade de desenvolver
código e disponibilizá-lo rapidamente às pessoas que irão utilizar
nosso produto. Isso é ótimo, mas no estágio atual adiciona um
risco alto de disponibilizarmos algum defeito. Isto porque estamos
confiando totalmente que a pessoa que irá realizar o deploy à partir
Crie o Pipeline inicial de Entrega Contínua 23
da sua máquina, testou o produto manualmente em sua máquina
- os problemas podem surgir porque os ambientes são totalmente
diferentes, ou porque esquecemos de testar alguma coisa (todo
processo manual é propenso a erros).
Para mitigar este risco vamos evoluir nosso pipeline inicial, adicio-
nando a ele a capacidade de Integração Contínua.
Integre continuamente
Os computadores realizam tarefas repetitivas: as pessoas re-
solvem problemas!
A Integração Contínua⁷ é uma prática de desenvolvimento onde o
código é integrado continuamente, ou seja, todos os desenvolve-
dores fazem commit das suas modificações várias vezes ao dia
em um repositório de desenvolvimento compartilhado e esse novo
código integrado passa por algumas verificações para garantir a
integração com o código já existente no repositório.
O grande benefício da integração contínua é que o código está
sempre integrado e com um bom nível de confiança que as novas
mudanças não quebraram nenhuma funcionalidade existente. Este
nível de confiança vai depender das verificações que são feitas no
código.
Para este processo de verificação existem diversas ferramentas que
auxiliam na orquestração deste de forma automatizada, os chama-
dos servidores de integração contínua. Além destas ferramentas,
existem diversas ferramentas que fazem as verificações em si e são
executadas pelo servidor de integração contínua.
Alguns exemplos de verificações executadas para validar a inte-
gração do código são:
• Compilação
• Análise estática de código
• Execução de testes unitários automatizados
⁷http://www.martinfowler.com/articles/continuousIntegration.html
http://www.martinfowler.com/articles/continuousIntegration.html
http://www.martinfowler.com/articles/continuousIntegration.html
Integre continuamente 25
• Execução de testes funcionais automatizados
Este processo nos ajuda a Construir qualidade no produto, elimi-
nando a necessidade de extensas atividades de verificação manuais
no final do processo, através da detecção de problemas o mais
próximo possível do momento do desenvolvimento, facilitando a
resolução do problema, e reduzindo o custo do mesmo. É muito
mais simples corrigir um defeito detectado minutos ou horas após
termos finalizado a codificação, do que dias ou semanas depois,
quando alguém encontra o problema em produção. Além disso,
um bug em produção pode ter um alto custo, dependendo do
impacto aos usuários - financeiro, imagem, satisfção - enquanto que
o custo é praticamente zero se o erro for detectado antes de ir para
produção.
Automatize os Testes
automatizados (introduzir TDD)
Sobre TDD
Testes unitários
aqui vamos adicionar um código exemplo de teste
unitário
Integre continuamente 26
Testes funcionais
aqui vamos adicionar um código exemplo de teste
funcional
Automatize a Análise estática de
código
• equipe, legibilidade de código
aqui vamos adicionar um código para Análise estática
de código
ArchUnit (princípios de evolutionary
architecture)
Deploy não precisa ser
Release
Até o momento toda e qualquer mudança que adicionamos, uma
vez que passam por nosso pipeline de integração e entrega contínua
são imediatamente visualizadas pelas usuárias de nosso sistema.
Isto não é ideal por uma série de razões:
1. Se estivermos desenvolvendo uma funcionalidade mais com-
plexa, que demore dias ou mesmo semanas para ficar pronta,
evitaremos integrar as mudanças (seja mantendo o código em
nossa máquina, ou criando uma branch), aumentando o risco
de sofrimento ao mergear tantas mudanças de uma vez só.
2. Enquanto temos algumas dezenas de usuários, talvez seja ok
introduzir uma modificação que introduza um defeito. No
entanto, quando tivermos milhões de usuários, isto certa-
mente passa a não ser aceitável. A resposta tradicional a este
problema é a criação de processos de homologação (em geral
manual), difíceis de gerenciar e que atrasam a disponibilidade
de uma nova feature.
Aqui introduzimos os conceitos de Deploy e Release:
• Deploy: implantação da versão de um software em um dado
ambiente, sendo uma decisão explicitamente técnica
• Release: processo de tornar uma funcionalidade disponível
aos usuários, sendo uma decisão de negócio
O ponto principal para entendermos a separação destes dois con-
ceitos é: podemos fazer o deploy do código de uma nova funcional-
idade sem necessariamente torná-la disponível aos usuários. Para
tanto, utilizamos feature toggles.
Deploy não precisa ser Release 28
Feature Toggle
Uma Feature Toggle (ou feature flag) é um padrão que permite
controlar a ativação de uma porção de código. Em sua forma mais
simples, pode ser apenas binário, indicando que um trecho está
ativo ou inativo. Mas ela também pode ser dinâmica, recebendo
parâmetros (como usuário, região de acesso, entre outros) para
decidir se está ativo ou não. Talvez você já tenha se deparado com
esta forma dinâmica, quando utilizou algum mecanismo de autor-
ização que controla se uma funcionalidade está disponível para um
usuário baseado em suas credenciais, por exemplo. Um outro uso
interessante de feature toggles dinâmicas é a implementação de
testes A/B.
A capacidade de integrar uma porção de código que sabemos não
será exercitado, nos dá a oportunidade de integrar partes de código
de uma funcionalidade que ainda não está completa. Isto é extrema-
mente útil para uma boa prática de Integração Contínua ⁸, pois
permite que integremos nossas modificações com uma frequência
maior. Com uma maior frequência de integração, a quantidade
de modificações que adicionamos em cada deploy é menor, o que
reduz o risco de introduzir defeitos.
De qualquer forma, uma certeza que temos é que eventualmente
introduziremos defeitos em nosso software. Na eventualidade de
detectarmos um problema após um deploy, fica mais fácil iden-
tificar a causa quando a quantidade de mudanças introduzidas é
pequena. Se o defeito surge após a ativação de uma feature toggle,
é muito provável que tenha sido causado pelo código associado à
funcionalidade ativada. Além de nos ajudar a identificar a causa doproblema, podemos rapidamente desligar a funcionalidade, e assim
nos recuperarmos da falha, e dar tempo (e tranquilidade) para que
a equipe de engenharia encontre a causa, conserte o problema, e
então redisponibilize a funcionalidade para nossas clientes.
⁸Continuous Integration
https://continuousdelivery.com/foundations/continuous-integration/
Deploy não precisa ser Release 29
Defina um feature toggle
aqui vamos adicionar um exemplo de feature toggle
para mostrar o (“Hello World”) no ambiente de pro-
dução
Toggles de longa duração
Esta capacidade das feature toggles de nos auxiliarem em cenários
de falhas é extremamente poderoso. A partir disto, podemos utilizar
este padrão de uma forma mais permanente, com o intuito de mit-
igarmos riscos. Surge aqui o conceito de toggles de longa duração.
Considere o cenário apresentado anteriormente, com um processo
critico que era executado por um sistema de terceiro. Neste caso,
haviam vários fornecedores que proviam a execução deste processo.
Como forma de mitigar o risco de impactar nossas usuárias em
função de um eventual problema ou indisponibilidade do fornece-
dor, mantemos uma toggle (e contratos com mais de um fornece-
dor), que nos permitia configurar dinamicamente a porcentagem de
processos que seriam atendidos por um ou outro fornecedor. Caso
um fornecedor esteja tendo problemas, podíamos desviar a carga
para o outro e vice-versa, até que tudo seja reestabelecido. Um outro
exemplo do uso de toggles de longa duração é sobre funcionalidades
não críticas: imagine um e-commerce que esteja recebendo uma
carga acima do esperado, e começa a degradar por conta disso;
podemos desligar o sistema de recomendação, por exemplo, para
diminuir o tempo de carregamento da página para nossas clientes.
[Link para referências de Graceful Degradation and Netflix lower
quality fallbacks]
Deploy não precisa ser Release 30
Este padrão permite um melhor processo de Entrega Contínua.
Imagine um aplicativomóvel, por exemplo, onde várias equipes dis-
tintas estão trabalhando em diferentes funcionalidades ao mesmo
tempo. Geralmente, por conta dos processos de aprovação das
lojas, não é viável gerar uma release do aplicativo a cada commit.
Desta forma, em geral uma nova release é gerada com várias
mudanças ao mesmo tempo, de vários times diferentes. Se um time
introduz um defeito, este acaba segurando a geração de uma nova
versão do aplicativo, impedindo que as demais alterações sejam
disponibilizadas para as usuárias. Se este defeito estiver protegido
por uma feature toggle, basta desligá-la e criar a nova versão.
Restrinja o acesso via toggle
Outro forma interessante de se utilizar feature toggles, é para
restringir o acesso a uma funcionalidade para um conjunto de
usuárias. Com isto, podemos criar mecanismos de rollout que vão
liberando uma funcionalidade aos poucos (por exemplo, primeiro
com 1% da base de clientes, depois para 5%, 10% … até atingirmos
toda a base). Com isto, podemos validar a funcionalidade aos
poucos, detectando problemas comum conjunto menor de pessoas,
reduzindo o impacto. Esta capacidade é útil para “prototiparmos em
produção”. Ao invés de validar uma idéia, design ou mudança com
protótipos não funcionais, com simulações de uso em pesquisas com
usuárias, podemos implementar uma ideia simples, disponibilizar
para um conjunto específico de pessoas, e capturar os feedbacks
para iterarmos sobre a solução. E podemos fazer isto com mais de
uma ideia ao mesmo tempo - o chamado A/B testing.
aqui vamos adicionar um exemplo de como restringir
o acesso via toggle
Para mais detalhes, sugerimos a leitura do artigo de Pete Hodgson
Deploy não precisa ser Release 31
sobre o tema ⁹.
⁹Feature Toggles (aka Feature Flags)
https://www.martinfowler.com/articles/feature-toggles.html
Squad de produto
Lean Inception, produto
e a equipe
No workshop Lean Inception, a equipe trabalhou junta para enten-
der os objetivos do produto, os principais usuários, e o desafio téc-
nico. Além disto, a equipe criou o sequenciador de funcionalidades,
o qual organiza e planeja entregas do produto a partir do MVP.
Tipicamente, times utilizando o sequenciador de funcionalidades
irão deslumbrar e evolução do produto via uma sequência deMVPs,
validando cada novo aspecto e interação do produto com seus
usuários.
Segue um exemplo de um sequenciador, do livro Lean Inception ¹⁰.
¹⁰CAROLI, Paulo. Lean Inception: Como alinhar pessoas e construir o produto certo. Editora
Caroli, 2018.
Lean Inception, produto e a equipe 34
MVP e suas funcionalidades
Embora seja uma ferramenta eficiente para descrever e alinhar
visualmente o mapa de evolução do produto, o sequenciador por
si só não resultará em entregas de sucesso.
Independente de excelentes planos, se a equipe não estiver muito
coesa e trabalhando efetivamente como um time, a execução do
plano fica comprometida.
Para tanto, sugerimos fortemente que o time técnico que participa
da Lean Inception do produto seja o mesmo time envolvido na sua
implementação, caracterizando assim a Squad de produto.
Lean Inception, produto e a equipe 35
Uma Squad de produto é formada por um grupo multi-funcional
e multi-disciplinar de pessoas que são coletivamente responsáveis
para a entrega emanutenção de um produto. Normalmente, a squad
do produto desempenha um papel crucial dentro da organização: a
equipe é responsável pela implementação da estratégia, evolução,
definição das funcionalidades, criação e manutenção do produto.
Objetivos do Squad de
Produto
É importante destacar que o produto desenvolvido a partir do
MVP é apenas uma versão inicial. Desta forma, o(s) sistema(s) que
desenvolveremos para validar o conjunto de hipóteses sobre o negó-
cio que definimos na Lean Inception, será modificado conforme
vamos aprendendo com as pessoas que experimentarão o produto,
e novas hipótese sejam criadas. E dentro do ambiente competitivo
que vivemos, esta evolução deve ser rápida: novas hipóteses devem
ser testadas e ajustadas em dias ou semanas, ao invés de meses ou
anos.
Como bem descreve o autor de Lean Inception¹¹ “… oMVP promove
uma criação evolutiva. Logo, a arquitetura, bem como o ferramen-
tal de construção do produto, deve permitir a evolução gradal e
contínua”.
A partir disto, podemos entender que a Squad de Produto tem três
objetivos principais:
1. Validar as hipóteses de negócio
2. Desenvolver sistemas que sejam facilmente modificáveis
3. Definir uma estrutura de desenvolvimento e entrega ágil
¹¹CAROLI, Paulo. Lean Inception: Como alinhar pessoas e construir o produto certo. Editora
Caroli, 2018.
Desenvolvimento
Iterativo
Acabou a semana da inception enxuta, e agora o time tem o
entendimento sobre o MVP e está alinhado sobre qual são as
primeiras features a serem criadas.
As features e o MVP estão em alto nível, mostrando claramente o
que tem ser feito, entretanto sem os detalhes sobre como isso vai ser
feito. O time agora precisa aprofundar nos detalhes de como serão
criadas essas features.
Para tanto o time deve utilizar de algumas dentre várias técnicas
que auxiliam nesse entendimento mais detalhado. Histórias do
usuário, prototipação rápida, desenvolvimento baseado em com-
portamento (BDD) e testes de aceitação são exemplos de algumas
das técnicas para ajudar com o detalhamento das features.
Usando algumas dessas técnicas o time estará aprofundando sobre a
forma com a qual as features serão criadas. Entretanto, aprofundar
não é complicar! Fique muito atento para não estar adicionando
alguma técnica de detalhamento que estará complicando e distan-
ciando o entendimento em relação as features e o MVP.
Ao primeiro sinal de que alguém está trabalhando em algo que não
está vinculado ao MVP, pare e reavalie. Provavelmente estamos
complicando algo desnecessariamente.
Mantenha sempre o canvas MVP próximo ao time. Sempre que
alguém explicar alguma tarefa ou algo que esteja fazendo, aponte
para o canvas MVP. Pergunte como tal tarefa está relacionada com
o MVP.
Uma boa resposta ajuda todos a entenderem como tal tarefaestá
aprofundando sobre o que está sendo feito para o MVP. Uma
Desenvolvimento Iterativo 38
resposta confusa pode ser um bom indicador de um complicador.
Cuidado, aprofundar não é complicar!
.
Sprint 0
A Sprint Zero
Para times usando a metodologia Scrum, é comum o termo Sprint
Zero. Apesar de não começarmos a contar do zero (contamos 1, 2,
3…), times Scrum comumente se referem a primeira sprint como
Sprint Zero, sendo essa a Sprint dedicada a atividades de set-up, as
quais não contemplam tarefas diretamente relacionadas a criação
de funcionalidades do produto.
Independente de utilizar Scrum ou outra metodologia para o geren-
ciamento e acompanhamento da criação do produto, sugerimos
utilizar este conceito de dedicar um tempo inicial (uma ou duas
semanas) para realizar as tarefas iniciais preparatórias para o
ambiente de trabalho.
Atividades da Sprint 0
Este capítulo compartilha uma sequência de atividades para lev-
antar as tarefas para o mínimo necessário de set-up para começar
o trabalho. O número de tarefas levantadas vai variar de time para
time. O perigo de levantar muitas tarefas, é que levaria muito tempo
até começar o trabalho nas funcionalidades do MVP, gerando,
assim, ansiedade para todos que esperam o MVP.
Portanto, consideramos a combinação da ideia de Sprint Zero com
as tarefas de set-up, para deixar claro a todos que o time não vai
trabalhar em funcionalidades do MVP neste curto período inicial.
E da mesma forma que o time pede por esse período inicial para set-
up, ele se compromete a trabalhar efetivamente nas funcionalidades
do MVP após esse Sprint Zero.
Ou seja, depois do zero, o time vai começar a contar; sejam semanas
ou sprints (para quem utilizar Scrum). E assim que começar a
contar, estará trabalhando efetivamente nas tão esperadas fun-
cionalidades do MVP.
Tarefas de set-up
Para dar início a criação do produto precisamos de definições
básicas sobre o ambiente de trabalho e sobre as normas de interação
entre as pessoas. Para tanto, precisamos buscar o alinhamento e
definição das mesmas.
Na mesma linha de pensamento que utilizamos para a definição
de MVP, precisamos definir o mínimo necessário em relação ao
ferramental e ao ambiente de trabalho para que possamos começar
a construir o produto. Reunindo todos membros do time em uma
Atividades da Sprint 0 42
sala, realizamos um workshop de duração média de duas horas,
onde são realizadas a seguinte sequência com três atividades:
Moscou, Votação Mais / Menos e Quem/O que/Quando, atividades
detalhadas em Fun Retrospectives¹².
Atividade: Moscou
AatividadeMoscou auxilia na conversa de alinhamento sobre o que
é essencial para começarmos, em relação ao que pode vir depois.
Passo a passo da atividade
1. Divida o canvas em três sessões: precisa ter (Must Have),
deveria ter (Should Have) e poderia ter (Could Have). O nome
da atividade é Moscou pois lembra, em Inglês, MustShould-
Could, ou, cortando algumas letras, MuShCou.
2. Selecione três cores de post-it explique a categoria de cada cor.
Por exemplo: amarelo para comunicação, verde para pipeline
de entrega contínua, e rosa para ambiente de desenvolvi-
mento.
3. Distribua post-its coloridos e canetas a todos participantes.
4. Peça que cada participante escreva no post it (usando a cor de
acordo com a categorização adequada) o que ele acredita ser
importante para o time.
5. Peça aos participantes que coloque os posts no canvas comum
de acordo com o seu entendimento em relação ao que precisa,
deveria, ou poderia ser feito.
As duas atividades a seguir complementam a atividade Moscou
para buscar o alinhamento do time para o iniciar a criação do
produto. Sugerimos fortemente descartar os posts da sessão de
poderia ter. Relembramos que o objetivo principal é buscar o
¹²http://www.funretrospectives.com
http://www.funretrospectives.com/
http://www.funretrospectives.com/
Atividades da Sprint 0 43
mínimo de alinhamento para dar início a criação do produto.
Portanto, o time deve focar sua atenção para a sessão deveria ter, ou,
em outras palavras, o que é essencial para começarmos a trabalhar
efetivamente.
Atividade Votação Mais / Menos
Esta atividade permite aos participantes serem mais claros sobre
concordâncias e discordâncias sobre os itens levantados. É tipica-
mente usada para focar a conversa nos itens que mais interessam
ao grupo.
Passo a passo da atividade
1. Instrua os participantes sobre as regras de votação:
• Cada participante tem direito a votar 5 “+” e 3 “–” (cada
voto será representado por uma marca de “+” ou “–” no
post-it.
• Os participantes podem colocar mais de um voto em um
cartão.
• (+) representa sua concordância com uma anotação e
você quer falar sobre ela.
• (–) representa sua discordância com a anotação e você
quer falar sobre ela.
“Por favor, vote nos itens que você quer discutir. Os itens com mais
votos serão selecionados primeiro.”
Atividades da Sprint 0 44
Votação Mais Menos
Atividade: Quem/O que/Quando
A atividade Quem/O que/Quando ajuda a definir comprometi-
mento e ações de acompanhamento para os itens levantados. A
partir desta atividade, os “próximos passos” ou “itens de ação”
estarão claramente definidos e visíveis para o time.
Passo a passo da atividade
1. Crie uma estrutura de tabela que tenha como títulos de coluna
QUEM / O QUE / QUANDO.
2. Peça para os participantes selecionarem (da atividade ante-
rior) ou escreverem um passo concreto com o qual possam
se comprometer. Estes deve ser tanto (1) passos que eles deve
seguir; ou (2) passos nos quais acreditam bastante.
3. Cada passo concreto selecionado formará uma linha na tabela
Quem/O que/Quando. Peça para os participantes para:
• Colocar o post-it com o passo na coluna O QUE;
• Escrever seus nomes na coluna QUEM;
• Definir QUANDO o item estará feito.
Atividades da Sprint 0 45
Quem/O que/Quando nas colunas da tabela
Ao focar a discussão no formato Quem/O quê/Quando, você pode
conectar pessoas a ações claras que elas definiram e com as quais
se comprometeram. Ela permite aos participantes serem claros
em relação a seu comprometimento e responsabilidades, tornando
visível para todo o grupo QUEM vai fazer O QUE e QUANDO.
Esta atividade é inspirada na matriz Quem/O que/Quando no livro
Game Storming¹³.
Path to Production
<colocar foto da atividade e escrever mais >
Iremos pensar em nosso Caminho para a Produção de ponta a
ponta, considerando vários aspectos, como arquitetura, qualidade
e entrega contínua de software.
¹³http://gamestorming.com/
http://gamestorming.com/
http://gamestorming.com/
Minimum Viable
Architecture (MVA)
Arquitetura Mínima
Viável (MVA)
O MVP permite que a equipe de possa entregar um produto nas
mãos de usuários rapidamente, a um baixo custo. Quanto mais cedo
o produto for utilizado, mais se pode aprender com os usuários
para melhorá-lo. A melhor maneira de aprender e evoluir é ouvir
de usuários que utilizam o software, não de pessoas olhando para
uma folha de papel em branco tentando visualizar como um sistema
deve funcionar.
Um dos desafios que a abordagem MVP apresenta é de que ela
pode levar à falta de uma arquitetura. Quando construindo um
produto do zero, a pressa para entregá-lo pode vir ao custo de uma
arquitetura sustentável. Deve haver balanço entre velocidade de
entrega e qualidade. É necessária uma arquitetura mínima viável
(MVA)¹⁴. <Este link está quebrado - o domínio não existe mais>
Então, como definimos qual o MVA? Recomendamos realizar per-
guntas como estas:
• Quantos usuários utilizarão o sistema no lançamento inicial?
Nos primeiros 6 meses? Dentro de um ano?
• Os usuários iniciais serão internos, externos, ou ambos?
• Quantas transações por segundo esperamos no lançamento?
Nos primeiros 6 meses? Dentro de um ano?
• Como os usuários começarão a utilizar o sistema?
• Qual o nível de segurança e auditabilidade exigido no lança-
mento? Dentro de 6 meses? Dentro de um ano?
¹⁴http://www.kavistechnology.com/blog/minimal-viable-architecture/
http://www.kavistechnology.com/blog/minimal-viable-architecture/http://www.kavistechnology.com/blog/minimal-viable-architecture/
http://www.kavistechnology.com/blog/minimal-viable-architecture/
Arquitetura Mínima Viável (MVA) 48
Micro-serviços de Domínio
A abordagem de micro-serviços é um estilo de desenvolvimento no
qual uma aplicação é composta de uma série de pequenos serviços,
cada um rodando em seu próprio processo e se comunicando
através de mecanismos leves (geralmente uma API HTTP). Estes
serviços são construídos em torno de requisitos de negócio, e
devem ser capazes de ir à produção independentemente e de forma
automatizada.
Uma abordagem para definir o escopo de um micro-serviço é anal-
isar qual a funcionalidade de negócio que ele se propõe a disponibi-
lizar, e como este serviço se relaciona com outros. Mapeamento de
contexto é uma ferramenta em Domain Driven Design que auxilia
na identificação de diferentes contextos e seus limites. Um contexto
encapsula os detalhes daquele domínio, como omodelo e os dados, e
define os pontos de integração com outros contextos. Desta forma,
há uma relação direta em DDD e mapeamento de contexto com
a definição de micro-serviços, que devem possuir interfaces bem
definidas e se limitarem à uma certa quantidade de funcionalidades
de negócio.
Embora micro-serviços adicionem complexidade operacional para
serem mantidos, eles provêm uma arquitetura forte e flexível, na
qual diferentes contextos têm limites bem definidos e podem ser
implementados da maneira como for mais adequado (com quais
tecnologias e estratégias forem apropriadas).
Registro de Decisão de
Arquitetura
Trabalhar com o MVA significa que a arquitetura é evolutiva, por
isso, é muito importante registrar as decisões que serão realizadas
ao longo do percurso. Isso ajuda para que as pessoas entendam o
momento e o motivo de cada decisão.
Os Registros de Decisão de Arquitetura — em inglês, Architeture
Decision Records – são uma técnica para capturar decisões impor-
tantes de arquitetura, juntamente com seu contexto e consequên-
cias.
Recomendamos armazenar esses Registros de Decisão de Arquite-
tura juntamente com o código, no repositório. Desta forma, eles
fornecem um registro que permanece sincronizado com o estado
do código e arquitetura.
Segue um exemplo de Registro de Decisão de Arquitetura quando
adicionamos AAA no nosso pipeline.
<adicionar exemplo de Registro de Decisão de Arquitetura>
Compartimentalização
Quando construindo MVPs, o ideal é otimizar para aprendizado, ao
invés de puramente velocidade de entrega. Com isto em mente, a
palavra “falha” passa a ter outro significado.
um navio petroleiro
Um experimento resultará em algo. Quando considerando uma
hipótese ou uma feature, geralmente se pensa positivamente, e isto
é ok. Porém, é importante organizar a arquitetura do produto de
forma que a equipe seja capaz de lidar com “falhas” localizadas
sendo um resultado possível. A falha é uma oportunidade de
aprendizado. Ela é necessária, mas exige preparação.
Compartimentalização 51
tanques de óleo de um navio petroleiro - visão lateral
tanques de óleo de um navio petroleiro - visão superior
Embora sejam grandes, tanques de óleo são costruídos com diversos
compartimentos menores de óleo. Caso um compartimento tenha
um problema, o navio não afunda. Este design protege o navio
inteiro de uma falha localizada em um tanque de óleo.
É desta maneira que o MVP e as features devem ser arquitetadas.
O produto deve estar preparado para experimentação de novas fea-
tures, ao mesmo tempo em que se mantém estável conforme novas
features (compartimentos) estão sendo trabalhadas. Experimentos
são importantes para validar novos aprendizados, mas não devem
colocar o produto em risco.
.
Métricas
Métricas acionáveis
O livro Lean Startup, de Eric Ries, junto com o conceito de MVP,
introduziu também o conceito de métricas acionáveis, aqueles
dados que nos ajudam a tomar decisões. Mas, infelizmente, muitas
organizações coletam métricas de vaidade, aqueles dados coletados
para nos fazer sentir bem, mas que não nos ajudam com as decisões
difíceis sobre qual ação tomar.
No livro Lean Analytics, Alistair Croll e Benjamin Yoskovitz afir-
mam: “Se você coleta dados sobre os quais não pode agir, então você
está usando uma métrica de vaidade”. Uma métrica efetiva deve te
ajudar a tomar decisões, a agir! Se você está trabalhando com MVP
você está buscando dados para ajudar com o processo decisório, de
forma a decidir suas próximas ações.
No livro “How toMeasureAnything”, Douglas Hubbard recomenda
a seguinte técnica para decidir que métrica usar:
1. Defina o resultado que busca através de exemplos
2. Identifique como esse resultado pode ser observado
3. Projete a medição do resultado
Coletar dados geralmente não é um problema. A maior dificuldade
é coletar os dados acionáveis, de forma a apoiar o processo decisório
e não se perder em meio a tanta informação e possibilidades.
To be continued…
Métricas 53
Dados para Métrica
<tbd: revisar e colocar links>
Ao trabalhar com MVP estamos decididos a trabalhar com dados
reais. Nossas decisões sobre a evoluçao do produto são baseadas
em dados reais, os dados sobre a utilização do nosso produto.
A análise inicial e a decisão sobre o que construir foi muito
importante, mas agora é o momento de colocar os pingos nos “i”s.
Ou seja, vamos coletar dados.
Para isso e necessário a utilização de alguma (ou algumas) ferra-
mentas para a coleta de dados. Alguns exemplos: Mixpanel, Kiss
metrics, e Keen IO.
Toda e qualquer interação com o produto deve fornecer dados para
serem analizados. Escolha a ferramenta adequada e coloque-a em
uso. Aceite que você não sabe exatamente o que vai acontecer. Por
isso voce deve coletar esses dados.
O primeiro passo é preparar o produto para coletar os dados
acionáveis. Depois você vai analizá-los para melhor decidir a
evolução do seu produto.
Analisando os resultados
<tbd: texto e exemplo de análise de dados>
Conclusão
.
DRAFT
Segue abaixo texto ainda solto, em WIP – writing in progress—que
será refatorado, restruturado e adicionado ao eBook.
MVP como início do
empreendimento
O Produto Mínimo Viável é o conjunto mínimo de funcionalidades
que precisamos disponibilizar aos potenciais usuários para validar
as nossas hipóteses. Este pensamento surge a partir de uma visão
simplificada sobre o que é o MVP. Mas MVP é o início do desen-
volvimento de um produto.
O desenvolvimento de um produto é muito maior do que somente o
desenvolvimento de suas funcionalidades; desenvolver um produto
é desenvolver um empreendimento.
Mesmo em uma empresa com diversos produtos, podemos entender
cada produto como uma pequena startup. Segundo Eric Ries, no seu
livro Lean StartUp: “A comprehensive theory of entrepreneurship
should address all the functions of an early-stage venture: vision
and concept, product development, marketing and sales, scaling
up, partnerships and distribution, and structure and organizational
design.”
Small batches
Small batches - small batches siginifica um experimento de cada
vez; quantidade de trabalho que se move de um estágio para o outro
DRAFT 56
Precisamos criar uma estrutura de desenvolvimento que permita
tabalharmos com pequenos lotes, de forma não burocrática. Pre-
cisamos criar uma estrutura de desenvolvimento que permita um
fluxo rápido da esquerda para a direita (the first way) e um fluxo de
feedback constante e rápido da direita para a esquerda (the second
way).
Desta forma, a primeira preocupação deve ser criar a fundação
mínima de nosso empreendimento: o pipeline de entrega contínua.
O primeiro passo é automatizar o deploy de nossa aplicação.
A working software application can be usefully decom-
posed into four components: executable code, config-
uration, host environment and data. If any of them
changes, it can lead to a change in the behavior of the
application. [^ContinuousDelivery] (p.13)
Geralmente, se você está desenvolvendo seu produto em uma orga-
nização consolidada, certamente não hámuitas dúvidas sobre como
empacotar e implantar suaaplicação - basta utilizar os padrões já
utilizados.
** NOTA IMPORTANTE ** Já tive a experiência de ajudar
algumas organizações estabelecidas a iniciar suas jornadas
no mindset e práticas de desenvolvimento Lean de produtos.
Em geral, definíamos um novo produto para exercitar, e
a empolgação sempre era bastante grande. Neste momento,
surgia o desejo de tentar resolver todos os problemas
da organização. Em muitos casos, os conceitos de Entrega
Contínua e Integração Contínua não eram utilizados. Surgia
então a ideia de fazer tudo diferente no novo produto -
por exemplo, usar cloud numa organização que não fazia isso
antes. Neste momento, é muito importante refletir sobre o
objetivo principal - entregar os objetivos de negócio do
produto, ou modernizar a infra da organização. Trabalhar
nos dois objetivos ao mesmo tempo pode aumentar o lead time
DRAFT 57
dos mesmos. Talvez seja mais interessante separar ambos em
iniciativas separadas - desenvolver o novo produto com o
máximo da infra atual, e escolher um produto já estabelecido
da organização para migrar para a cloud por exemplo. Não
infle o escopo do seu produto a não ser que seja essencial
para o sucesso do mesmo.
No entanto, é possível que você esteja desenvolvendo o primeiro
produto da sua nova empresa. Se for este o caso, você terá que
tomar algumas decisões: #### Plataforma como Serviço (PaaS)
Plataformas como Serviço
• Qual infra utilizar? OnPremise? IaaS? PaaS?
• Como empacotar? docker? Pacotes debian, rpm? outros?
** DEVEMOS FALARUMPOUCOSOBREASVANTAGENS, DESVAN-
TAGENS E OPÇÕES DE CADAUMADESTAS ALTERNATIVAS??
**
Independente de qual opção escolher, uma coisa é certa: Toda a
configuração de sua infraestrutura deve estar noControle de Versão,
e ser automatizada. Hoje em dia há uma série de ferramentas que
nos auxiliam nesta tarefa: * Ansible * Puppet * Chef * Terraform
** Servidores Fênix
Entrega Contínua
Existem cinco princípios fundamentais: * Build Quality In * Work
in Small Batches * Computers perform repetitive tasks: people
solve problems * Relentlessly pursue continuous improvements *
Everyone is responsible
Referências
Todas as referências citadas neste livro estão nesta lista de referên-
cias, que segue a ordem conforme aparecem no texto.
CAROLI, Paulo. Lean inception: como alinhar pessoas e construir
o produto certo. Editora Caroli; 1ª edição, 2018.
Principles behind theAgileManifesto (2001) , Disponível em http://agilemanifesto.org/principles.html,
Acesso em 2 de setembro de 2018.
RIES, Eric. The Lean Startup: How Today’s Entrepreneurs Use
Continuous Innovation to Create Radically Successful Businesses.
Crown Publishing (1st Edition), 2011.
HUMBLE, Jez and FARLEY, David. Continuous Delivery: Reliable
Software Releases through Build, Test, and Deployment Automa-
tion, Addison-Wesley, 2010.
Sobre Alexandre Corrêa
Barbosa
Alexandre C. Barbosa teve sua primeira experiência profissional
como desenvolvedor em 1999. Formado em Engenharia de Com-
putação pela Unicamp, Alexandre trabalha atualmente como En-
genheiro de Software no Nubank, e antes foi Consultor de De-
senvolvimento Principal pela ThroughtWorks Brasil, onde atuou
de 2012 a 2019 (e teve o prazer de trabalhar com Caroli). Teve a
oportunidade de trabalhar em diferentes domínios: bionformática,
financeiro, varejo, educação, saúde, entre outros; trabalhou também
com diferentes plataformas e tecnologias, atendendo clientes no
Brasil e EUA.
É apaixonado pela busca constante da excelência técnica, e acredita
que o mindset Lean é uma poderosa ferramenta nesta busca.
Alexandre Corrêa Barbosa
Sobre Paulo Caroli
Consultor principal da Thoughtworks Brasil e cofundador da Ag-
ileBrazil, Paulo Caroli possui mais de vinte anos de experiência em
gestão e desenvolvimento de software, com passagem em varias
corporações no Brasil, Índia e EUA . Em 2000, conheceu o Extreme
Programming e, desde então, tem mantido seu foco em processos e
práticas de gestão e desenvolvimento ágil. Ingressou na Thought-
Works em 2006 e ocupou os cargas de agile coach, treinador, e
Gerente de Projetos. Possui os títulos de Bacharel em Ciência da
Computação e MS em Engenharia de Software, ambos da PUC -
Rio. Autor dos Livros ” Direto Ao Ponto; Criando Produtos de forma
enxuta” , e “Fun Retrospectives; activities and ideas formaking agile
retrospectives more engaging”.
Paulo Caroli
Acompanhe Paulo Caroli no seu site e nas redes sociais:
Sobre a Editora Caroli
Para leitores e autores que buscam e compartilham conhecimento
de forma ágil, a Editora Caroli é uma editora-butique – todos os
livros são escritos, lidos, editados e/ou revisados por Paulo Caroli,
que auxilia na produção, divulgação e distribuição de livros e e-
books. Diferentemente das editoras tradicionais, a Editora Caroli dá
acesso ao conhecimento na sua essência, disponibilizando o texto
das novas obras via e-books gratuitos, além de apoiar eventos e
entidades de ensino, presenteando-os com livros impressos.
Em www.caroli.org você encontra este e outros conteúdos de qual-
idade. Aproveite, pois os livros e e-books emWIP estão disponíveis
gratuitamente.
WIP (Writing In Progress)
A Editora Caroli apresenta uma nova proposta de trabalho, aprox-
imando autores dos seus leitores desde o início da geração do
conteúdo. Por que esperar o autor terminar de escrever para ver
se o conteúdo é bom? No mundo atual, isso não faz mais sentido.
Por isso, a Editora Caroli promove o compartilhamento (gratuito
sempre que possível) do WIP por meio dos formatos e-book (pdf,
mobi e epub). Dessa forma, leitores têm acesso rápido a novas ideias
e podem fazer parte da evolução da obra. Para os autores, é uma
forma efetiva de feedback e motivação para a geração de conteúdo.
	Table of Contents
	Disclaimer
	Mindmap
	Eu sou um Dev
	Eu sou um facilitador
	Introdução
	Preparando as Fundações do Produto
	Arquitetura Mínima Viável
	Atividades para definição dos Requisitos Cross-Funcionais
	MVA e arquitetura Evolutiva
	Preparando para entregar continuamente
	Crie o Pipeline inicial de Entrega Contínua
	Pipeline de Entrega Contínua
	Prepare o Ambiente de Desenvolvimento
	Comece com um Controle de Versão
	Utilize um Trunk único
	Modele a Infraestrutura como Código
	Entenda Entrega Contínua
	Evolua o Pipeline inicial
	Integre continuamente
	Automatize os Testes automatizados (introduzir TDD)
	Sobre TDD
	Testes unitários
	Testes funcionais
	Automatize a Análise estática de código
	ArchUnit (princípios de evolutionary architecture)
	Deploy não precisa ser Release
	Feature Toggle
	Defina um feature toggle
	Toggles de longa duração
	Restrinja o acesso via toggle
	Squad de produto
	Lean Inception, produto e a equipe
	Objetivos do Squad de Produto
	Desenvolvimento Iterativo
	Sprint 0
	A Sprint Zero
	Atividades da Sprint 0
	Tarefas de set-up
	Atividade: Moscou
	Atividade Votação Mais / Menos
	Atividade: Quem/O que/Quando
	Path to Production
	Minimum Viable Architecture (MVA)
	Arquitetura Mínima Viável (MVA)
	Micro-serviços de Domínio
	Registro de Decisão de Arquitetura
	Compartimentalização
	Métricas
	Métricas acionáveis
	Dados para Métrica
	Analisando os resultados
	Conclusão
	DRAFT
	MVP como início do empreendimento
	Small batches
	Entrega Contínua
	Referências
	Sobre Alexandre Corrêa Barbosa
	Sobre Paulo Caroli
	Sobre a Editora Caroli
	WIP (Writing In Progress)