Apostila - Módulo 3 - Bootcamp Engenheiro de Software Ágil

Prévia do material em texto

Técnicas e Práticas Ágeis de Desenvolvimento de 
Software 
 
 
Bootcamp Engenheiro de Software Ágil 
 
 
 
 
Antonio Almeida 
 
 
 
 
 
2021 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 2 de 32 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software 
Bootcamp Engenheiro de Software Ágil 
Antonio Almeida 
© Copyright do Instituto de Gestão e Tecnologia da Informação. 
Todos os direitos reservados. 
 
 
 
 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 3 de 32 
Sumário 
Capítulo 1. Técnicas de Estimativa Ágil ................................................................ 5 
O que é Estimativa de Software? ............................................................................ 5 
O que é Estimativa Ágil? ......................................................................................... 6 
Planning Game ................................................................................................... 7 
Planning Poker .................................................................................................... 9 
T-shirt Sizes ...................................................................................................... 11 
Capítulo 2. Gerência de Configuração de Software ............................................ 13 
O que é Gerência de Configuração de Software .................................................. 13 
Gestão de Mudanças ........................................................................................ 15 
Introdução ao Jira Software .............................................................................. 16 
Controle de Versão ........................................................................................... 16 
Introdução e Instalação do GIT ......................................................................... 16 
Integração com o GITHUB ................................................................................ 17 
Introdução e Instalação do Visual Studio Code ................................................ 17 
Integração Continua .......................................................................................... 18 
Introdução e Instalação do Jenkins ................................................................... 18 
Criação de Pipeline no Jenkins ......................................................................... 19 
Capitulo 3. Refatoração de Código .......................................................................... 20 
Bad Smells ............................................................................................................ 20 
Capitulo 4. Programação em Par ............................................................................. 21 
Capitulo 5. Aprovisionamento e Gerenciamento de Infraestrutura Ágil .................... 23 
Breve Introdução ao DevOps ................................................................................ 23 
História da Cloud .................................................................................................. 24 
Introdução à AWS ................................................................................................. 26 
Capítulo 6. Infraestrutura como código .................................................................... 27 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 4 de 32 
IaC ........................................................................................................................ 27 
Terraform .............................................................................................................. 28 
Referências.............. ................................................................................................ 31 
 
 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 5 de 32 
Capítulo 1. Técnicas de Estimativa Ágil 
A estimativa de tempo é um dos indicadores de software mais comumente 
usados, pois a partir desta dimensão, a carga de trabalho, o tempo e o custo 
necessários para o desenvolvimento do software podem ser definidos. 
A enorme demanda por software de alta qualidade e desenvolvimento 
oportuno, desde o planejamento, gerenciamento até a entrega e manutenção, mudou 
o processo de criação de software. Atualmente, as empresas que são incapazes de 
se adaptar a grandes quantidades de informações, tanto estratégica quanto 
operacionalmente, muitas vezes não conseguem concluir as tarefas no prazo, 
reduzem a qualidade do produto e frequentemente não têm um bom relacionamento 
com os clientes. Para Tavares, Carvalho e Castro (2004), estes podem ser alguns 
dos maiores desafios para as organizações que desenvolvem software. 
 Existem várias técnicas que podem ser usadas para uma estimativa ágil de 
tempo e esforço. Normalmente, a equipe conduzirá vários sprints para padronizar 
seus métodos de estimativa. Mas, uma vez definido, existem várias maneiras 
importantes de usá-lo. 
A estimativa de tempo torna-se necessária desde o início do projeto, 
passando pela fase de desenvolvimento e testes. Este cenário tem exigido a adoção 
de técnicas para estimar tempo e esforço das atividades que envolvem a criação de 
sistemas, planejando-se produtividade, previsão e priorização (LEISHMAN, 2008). 
O que é Estimativa de Software? 
Segundo Pressman (2006), estimativa pode ser considerada como a tentativa 
de determinar quanto dinheiro, esforço, recursos e tempo serão necessários para 
construir um sistema ou produto. O valor estimado é um valor aproximado obtido 
através de algum cálculo ou não, é realizado sobre algo e pode ser usado como 
informação. Mesmo estimativas incompletas ou incertas podem ser usadas, porque 
ao usar estimativas, o tamanho do erro (independentemente do tamanho) deve ser 
considerado 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 6 de 32 
Estimar o software nunca foi uma tarefa fácil porque, na maioria dos casos, 
as equipes usam apenas informações qualitativas para fazer previsões quantitativas. 
No entanto, a estimativa não precisa ser aleatória, pois existem técnicas disponíveis 
na literatura que podem ser utilizadas. 
Segundo Pressman (2006): “Apesar de estimar ser tanto arte como ciência, 
essa importante atividade não precisa ser conduzida de modo aleatório. Já existem 
técnicas úteis para estimativa de tempo e esforço”. Existem vários fatores que 
impedem os desenvolvedores de estimar o software corretamente: 
 Requisitos incompletos e muito subjetivos; 
 Os desenvolvedores não têm conhecimento das métricas de software 
aplicáveis às suas tarefas; 
 Um gerente de projeto que espera obter uma estimativa repentina sem dar 
tempo para uma análise de demanda; 
 A função, projeto ou produto é muito diferente do produto desenvolvido 
anteriormente, portanto não pode ser estimado por analogia. 
Estimativas incorretas podem afetar a entrega de várias maneiras: 
eventualmente resultando em cronogramas imprecisos (o tempo é muito curto ou 
muito longo, deixando a equipe ociosa), os projetos incorrem em mais custos e horas 
extras são necessárias para entregar no prazo acordado pelo cliente e muitos mais. 
 
O que é Estimativa Ágil? 
Uma boa estimativa pode ser a base para um bom plano. Segundo Leishman 
(2008), existem três motivos para equipes ágeis estimarem: previsão, performance e 
priorização. Em outras palavras, preveja quanto tempo e esforço a equipe gastará, 
determine o ganho ou perda de desempenho no processo de desenvolvimento com 
base no histórico da equipe e relate o custo de implementação para que possam 
priorizar projetos que agreguem valor aos clientes. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 7 de 32 
A estimativa ágil visa atribuir fatores de custo a todas as transações na 
carteira. Essa ponderação de custo pode ser usada para medir a velocidade daequipe, tomar melhores decisões sobre a prioridade de recursos ou fazer previsões e 
roteiros. 
É desejável que tenha conhecimento prévio da técnica e uma visão macro do 
escopo do projeto, e quando possível uma base histórica onde seja possível consultar 
as estimativas em atividades semelhantes já finalizadas (SOMMERVILLE, 2003). 
Em muitos casos, existem problemas com o uso de estimativas. A primeira é 
organizar o rastreamento do tempo do aplicativo e comparar o tempo real aplicado à 
estória com o valor estimado. Mesmo que as estimativas sejam feitas em horas, é 
importante que a equipe avalie a entrega com base no compromisso e na capacidade 
de manter ou aumentar a velocidade, em vez de verificar as estimativas individuais. 
Em segundo lugar, quando os gerentes tentam usar estimativas para alocar 
recursos. Eles podem sugerir que uma pessoa da equipe pode fazer mais trabalho 
porque recebeu menos pontos em comparação com sprints anteriores. Essa lógica é 
seriamente falha, pois a equipe ágil não considerou a participação de todos os 
membros da equipe ao concluir o caso do usuário. Essa forma de gerenciamento de 
recursos é equivalente ao microgerenciamento, mas impede o sucesso de equipes 
ágeis, e equipes ágeis assumem compromissos honestos com base em equipes 
confiáveis. 
Planning Game 
No Planning Game, a equipe de desenvolvimento e a equipe do cliente 
planejam o software com eficácia. Nesta atividade, cada equipe tem um papel muito 
claro: a equipe do cliente é responsável por definir o escopo e a prioridade, e a equipe 
de desenvolvimento fornece as estimativas. 
Muitas vezes, é difícil concentrar a equipe apenas na função. Portanto, o 
coach da equipe de desenvolvimento deve alertar sobre possíveis desvios. É comum 
que os clientes esperem que a equipe de desenvolvimento faça estimativas. A frase 
"Eu quero essa funcionalidade pronta em tantos dias" é comum. Acontece que o 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 8 de 32 
cliente não possui o conhecimento técnico necessário para fornecer estimativas de 
desenvolvimento. 
Este é um ponto que deve estar sempre na cabeça da pessoa que está sendo 
coach naquele momento, ela deve guiar com segurança a sua equipe, por outro lado 
não deve aceitar tudo do cliente, para não prejudicar a credibilidade do projeto nas 
circunstâncias de atrasos constantes. Apenas colocar mais desenvolvedores no 
projeto, não significa que irão realizar muitas tarefas mais rapidamente. Com os 
papéis das duas equipes claros, é possível entender o que realmente está 
acontecendo no Planning Game. O cliente deve ter as estórias definidas, porque esta 
atividade é baseada nelas. 
Se uma estória for muito grande para ser iterada ou não puder ser estimada 
corretamente, isso significa que a story é muito complexa e deve ser dividida em 
stories menores. Por outro lado, se for muito pequena, deve ser adicionada a outras 
user stories para formar uma nova com o tamanho adequado. 
Normalmente, entende-se por adequadas, stories aquelas que podem ser 
desenvolvidas em dois ou até três dias de programação. A relação entre a função 
entregue e a função que o cliente requer para iteração é chamada de velocity 
(velocidade) da equipe de desenvolvimento. Neste cenário, o cliente deverá definir o 
escopo/atividades para a próxima iteração e então priorizar quais atividades deseja 
alcançar ao fim da iteração. Eles devem levar em consideração o seguinte princípio: 
devem primeiro, obter o que trará o maior retorno ou seja, mais valor para o negócio. 
Durante o processo de desenvolvimento, as perguntas dos desenvolvedores 
podem gerar novas stories. Além disso, podem existir requisitos muito técnicos como, 
a criação de uma nova tabela para o banco de dados, ou uma nova primary key que 
podem gerar tarefas de engenharia. Elas também devem ser levadas em 
consideração nas próximas iterações. 
Nas reuniões de planning game, essas informações também são passadas 
para o cliente: informações sobre o andamento da versão atual e quaisquer atrasos 
no andamento do desenvolvimento para que o cliente possa decidir quais recursos 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 9 de 32 
devem ser retidos para a próxima versão, ou para que os desenvolvedores possam 
fornecer novas estimativas para stories que ainda não foram implementadas. Este é 
um ponto importante: se você não pode entregar tudo prometido na data de entrega 
de cada iteração, você deve negociar com o cliente qual story deve ser usada para a 
próxima e não atrasar a data de entrega da iteração. 
Planning Poker 
O Planning Poker é uma técnica de avaliação que também se concentra em 
métodos ágeis, principalmente no Scrum. Grenning afirma que o Planning Poker ou, 
como também é comumente conhecido, Scrum Poker é a melhor ferramenta 
encontrada para se estimar tamanho de projetos em metodologias ágeis 
(GRENNING, 2002). 
Ele pode ser considerado uma combinação de três métodos de avaliação ágil 
menos usados: opinião de especialistas, analogia e desagregação. Inclui a obtenção 
de estimativas por meio de jogos de cartas. A ideia principal é permitir que todos os 
membros da equipe de desenvolvimento (programadores, testadores, designers, 
analistas, etc.) participem, expressem suas opiniões sobre a complexidade e levem 
em consideração o tempo e a energia gastos na pontuação da história e após chegar 
a um consenso. Cada membro tem doze cartas disponíveis para uso, e sua sequência 
de numeração é semelhante à sequência dos números de Fibonacci. A figura abaixo 
exemplifica um possível baralho para a utilização no Planning Poker, vale lembrar que 
existem vários outros tipos e que este é apenas uma representação de um deles. 
Figura 1 – Cartas de Planning Poker. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 10 de 32 
 
Fonte: DevMedia. 
Para começar, podemos dizer que valores maiores que 20 são considerados 
altos, outra opção é elaborar mais a história e dividi-la em partes menores para reduzir 
sua complexidade. Recomenda-se que, no final do Planning Poker, a estória iterativa 
possa ter um certo valor no intervalo de 1/2 a 13. No entanto, é necessário evitar outro 
problema que é, deixar que as estórias se tornarem muito pequenas, pois isso 
provavelmente tornará a equipe vítima do micro gerenciamento (KNIBERG, 2009). 
Algumas cartas do Planning Poker podem conter fins especiais. A carta "0" 
(zero) significa que a estória acabou ou é pequena demais e pode ser resolvida em 
alguns minutos. A carta com “?” (pergunta) indica que o participante não possui o 
conhecimento adequado para estimar o esforço necessário para a estória. 
Durante o Planning Poker, as rodadas devem ser feitas com base nesses 
valores para obter uma estimativa da estória. No Scrum, essa função é de 
responsabilidade do Scrum Master. Por sua vez, Product Owner será responsável por 
explicar as estórias, o que é muito importante para eliminar possíveis dúvidas. 
Segundo CTIC-UFPA (2011) e Cohn (2005), a equipe Scrum deve seguir as 
seguintes etapas ao avaliar a estória: 
 Pontuar a estória que mais se aproxima do valor “3” (três). 
https://www.devmedia.com.br/planning-poker-e-ideal-day-tecnicas-de-abordagem-de-estimativa-agil/31220
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 11 de 32 
 O Product Owner descreve para a equipe Scrum a estória e fornece 
informações a respeito do seu valor de negócio. A seguir, o facilitador vai 
perguntar o esforço necessário para concluir a estória aos membros da equipe. 
 Cada membro da equipe deve pensar a respeito do tempo e esforço necessário 
para se implementar a estória lida. Então, devem escolher uma carta no 
baralho correspondente ao valor desta estimativa e coloca-a virada para baixo. 
 Em seguida devem revelar as cartas escolhidas simultaneamente. 
 Todos avaliam os resultadose verificam se houve convergência entre as cartas 
mostradas. 
 Caso contrário, o Scrum Master solicita aos membros, que mostraram o menor 
e o maior valor estimado, que expliquem o motivo que os levaram a tal 
estimativa. Então, uma nova rodada é realizada até que as estimativas de 
esforço cheguem a uma convergência. 
 A estimativa final da estória será o valor que tiver maior ocorrência ou a média 
entre as estimativas informadas. Então começa uma nova rodada com a leitura 
da próxima estória pelo Product Owner. O processo se repete até que tenha 
sido concluída a estimativa das estórias dos itens do Product Backlog. 
As pesquisas de Fonseca (2008) mostram que ao usar essa técnica para 
atribuir pontuações, a eficiência da estimativa ponto a estória é melhorada. O autor 
acredita que o maior problema com a tecnologia não estruturada, é que as pessoas 
com personalidades mais fortes e pessoas que dizem ter um melhor entendimento da 
estória irão influenciar os outros participantes. 
 
T-shirt Sizes 
Uma forma de nos permitir desenvolver é medir nossas ações atuais para 
fornecer melhorias futuras. Em uma equipe ágil, uma das muitas maneiras de medir 
a carga de trabalho da equipe é usar o método T-shirt Sizes. Este método serve 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 12 de 32 
apenas para classificar o tamanho da demanda (como estória, atividades técnicas, 
UX, etc.) como P, M ou G, por exemplo. Onde, P - representa a necessidade de usar 
uma pequena quantidade de tempo, M - representa a demanda por horas médias de 
uso, G - indica a necessidade de gastar muito tempo. 
No entanto, antes de categorizar os requisitos em um período de tempo, é 
necessário que a equipe Scrum quantifique o número de horas que cada categoria 
representa. Exemplos de horas de classificação são P - significa 2 horas de trabalho, 
M - significa 4 horas de trabalho necessárias, G - significa 8 horas de trabalho 
necessárias. O tamanho e a carga horária devem ser definidos pela equipe e podem 
variar no dia a dia, o que importa é a clareza da classificação do público entre as 
equipes. 
A classificação pode ser diferente, incluindo novas medidas, PP - significa 
que o tempo necessário é inferior ao da categoria P, GG - indica a necessidade de 
usar mais tempo do que a classificação G. 
Nesta técnica, os membros do time também irão utilizar cartas de baralho, 
semelhantemente ao Planning Poker, mas ao invés das cartas terem os números da 
sequência de Fibonacci, elas terão os tamanhos propostos anteriormente. 
O fluxo segue o mesmo do Planning Poker. Após a descrição da estória a ser 
estimada, as pessoas membras do time já com as cartas do baralho em mãos, irão 
escolher o valor que acreditam ser necessário para a execução daquela estória e, 
caso haja divergência, as pessoas que estimaram para mais ou para menos, irão 
explicar seus motivos para que, novamente, seja feita outra rodada de estimativas até 
que se chegue a um senso comum. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 13 de 32 
Capítulo 2. Gerência de Configuração de Software 
Os sistemas de software estão em constante evolução. A manutenção de 
software, ou seja, a modificação de artefatos existentes, consome 75% do custo total 
do seu ciclo de vida. Devido às mudanças nos requisitos funcionais, regras de 
negócios e redesenho do aplicativo, cerca de 20% de todo o trabalho de manutenção 
é usado para corrigir erros de implementação e os 80% restantes são usados para 
ajustar o software. 
 
O que é Gerência de Configuração de Software 
Gerência de Configuração de Software é um conjunto de atividades de 
suporte que podem absorver mudanças inerentes ao desenvolvimento de software de 
maneira ordenada e manter a integridade e estabilidade durante o desenvolvimento 
do projeto. É uma disciplina que controla e informa as inúmeras correções, extensões 
e adaptações aplicadas no ciclo de vida do software para garantir um processo de 
desenvolvimento e evolução sistemático e rastreável, o que é essencial quando as 
equipes geralmente trabalham juntas em artefatos comuns. 
Desde o planejamento e levantamento de requisitos até a construção e 
entrega do produto, o uso de sistemas de gerenciamento de configuração é essencial 
para controlar os artefatos gerados e modificados por diferentes recursos. 
As atividades do GCS (Gerência de Configuração de Software) ou SCM do 
inglês, Software Configuration Management. As ferramentas de suporte 
correspondentes são: controlar e rastrear mudanças (controle de mudanças) e 
documentar a evolução do projeto (controle de versão), além da implementação mais 
recentemente da disciplina IC (integração contínua). 
 
 
Figura 2 – GCS. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 14 de 32 
 
Fonte: https://blog.pronus.io/posts/o-que-eh-gerencia-de-configuracao-de-software/. 
1. Controle de Acompanhamento de Mudanças 
As mudanças aparecerão ao longo do processo de desenvolvimento e devem 
ser registradas, avaliadas e agrupadas de acordo com sua prioridade. Conforme o 
desenvolvimento avança, você pode rastrear o status da solicitação de mudança até 
que ela seja implementada, ou não, e a versão de produção seja lançada. 
Existem várias ferramentas para realizar essas operações. Como, BitBucket, 
Bugzilla, Jira, Phabricator, Redmine e Trac. 
2. Registro da Evolução do Projeto 
Cada vez que uma solicitação de mudança é implementada, aumenta o 
desenvolvimento do projeto que deve ser registrado no histórico. Este incremento 
corresponde a uma configuração. 
O controle de versão tem outras responsabilidades importantes: permite a 
edição simultânea de arquivos e a criação de variantes no projeto. O controle de 
versão é a parte principal do GCS. É o elo universal entre o controle de mudanças e 
a integração do projeto. Algumas boas ferramentas de controle de versão são: Git e 
Mercurial. 
 
3. Verificação da Integridade do Sistema 
https://blog.pronus.io/posts/o-que-eh-gerencia-de-configuracao-de-software/
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 15 de 32 
O objetivo da integração é verificar o sucesso do sistema de construção do 
projeto registrado a partir da configuração. A integração é feita por meio de scripts, 
que podem executar automaticamente a construção, teste e coleta de indicadores de 
qualidade. Cada vez que uma nova configuração é registrada, o controle de versão e 
os scripts de gatilho vêm com ferramentas de integração contínua. 
Exemplos de ferramentas de integração contínua: BuildBot, CicleCI, Azure 
DevOps, CodeShip, Concourse, Drone.io, Jenkins, etc. 
4. GCS na Engenharia de Software 
O gerenciamento de configuração de software é a base de outras áreas da 
engenharia de software: portanto, parece ser um requisito de implementação no nível 
inicial de vários modelos de maturidade do processo de desenvolvimento (como 
CMMI-DEV, SPICE e MPS –Br). 
Do ponto de vista da ferramenta, a divisão entre as regiões não é muito clara. 
As ferramentas de controle de mudanças e integração contínua fornecem mais 
funções do que o GCS requer, e houve progresso no gerenciamento de projetos, 
testes e qualidade. 
5. Fluxo de Trabalho 
A solicitação de mudança é registrada no controle de mudanças. O 
desenvolvedor será, então, responsável por executar a solicitação e registrar a 
configuração resultante no controle de versão, o que acionará a integração contínua 
para a execução do build e teste automatizado, e coletará indicadores de qualidade 
do código. Os resultados serão apresentados a toda a equipe imediatamente e, caso 
haja problemas, eles deverão tomar as providências necessárias. 
 
 
Gestão de Mudanças 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 16 de 32 
O objetivo do gerenciamento de mudanças é garantir que os métodos e 
procedimentos padronizadosmais apropriados sejam usados para lidar com todas as 
mudanças com eficiência e rapidez. O objetivo é controlar a infraestrutura de TI para 
minimizar o impacto de qualquer incidente. As mudanças na infraestrutura de TI 
podem aparecer passivamente em resposta a questões ou solicitações externas, 
como mudanças legislativas. Por outro lado, buscar maior eficiência e eficácia em 
uma organização pode ser uma ação proativa. 
Introdução ao Jira Software 
Jira Software é parte de uma série de produtos projetados para ajudar vários 
tipos de equipes a gerenciar seu trabalho. Jira foi inicialmente desenvolvido como um 
rastreador de bug e projeto. Hoje, o Jira é uma ferramenta de gerenciamento 
poderosa adequada para todos os tipos de casos de uso, desde casos de teste e 
gerenciamento de requisitos até o desenvolvimento ágil de software. 
Controle de Versão 
Um sistema de controle de versão é uma ferramenta de software que pode 
ajudar as equipes de software a gerenciar mudanças no código-fonte ao longo do 
tempo. O software de controle de versão pode rastrear todas as alterações de código 
em um tipo especial de banco de dados. Se um erro for cometido, o desenvolvedor 
pode voltar no tempo e comparar a versão anterior do código para ajudar a corrigir o 
erro, enquanto reduz os danos a todos os membros da equipe. 
Introdução e Instalação do GIT 
O sistema de controle de versão moderno mais usado no mundo hoje é o Git. 
Git é um projeto de código aberto maduro e gerenciado ativamente. Foi desenvolvido 
em 2005 por Linus Torvalds, o famoso criador do kernel do sistema operacional Linux. 
Um número impressionante de projetos de software depende do Git para controle de 
versão, incluindo projetos comerciais e de código aberto. Os desenvolvedores que 
trabalharam com o Git estão bem representados no pool de talentos de 
desenvolvimento de software disponível e normalmente trabalham bem em uma 
ampla variedade de sistemas operacionais, ambientes de desenvolvimento integrado 
e editores de código fonte. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 17 de 32 
Dentro de uma arquitetura distribuída, Git é um exemplo de DVCS - 
Distributed Version Control System. Ao invés de ter um único local para o histórico 
completo da versão do software, como é comum em sistemas de controle de versão 
anteriormente populares como CVS ou Subversion (também conhecido como SVN), 
no Git, a cópia de trabalho de cada desenvolvedor em código também é um repositório 
que pode conter o histórico completo de todas as alterações. 
Além de ser distribuído, o Git foi projetado para ter alto desempenho, 
segurança e flexibilidade, esses ingredientes misturados caíram nas graças das mais 
diversas comunidades de desenvolvimento. 
Integração com o GITHUB 
GitHub é um sistema de gerenciamento de projeto e versão de código, bem 
como uma plataforma de mídia social desenvolvida para programadores. Mas para 
que é usado o GitHub? Entre outras coisas, você pode trabalhar em projetos 
colaborativos com desenvolvedores em todo o mundo, planejar seus projetos e 
acompanhar o trabalho. 
O GitHub também é um dos maiores repositórios de trabalho colaborativo on-
line do mundo. Atualmente, ele conta com mais de 36 milhões de usuários ativos que 
contribuem para negócios ou projetos pessoais. Hoje, o GitHub é o lar de mais de 100 
milhões de projetos, alguns dos quais são conhecidos em todo o mundo. Dentre eles 
podemos citar, WordPress, Atom, Electron e muitos outros. 
O GitHub também oferece suporte ao recurso de organização frequentemente 
usado por pessoas que desejam uma escala maior para seus projetos. Geralmente, 
o recurso é usado por empresas existentes como Google, Microsoft e WordPress. Em 
quatro de junho de 2018, a Microsoft anunciou a compra do GitHub por 7,5 bilhões de 
dólares. Esta notícia deixou a comunidade receosa com as possíveis mudanças nas 
políticas de utilização da ferramenta, mas, até então, não se tem grandes 
reclamações das alterações implementadas pela Microsoft. 
Introdução e Instalação do Visual Studio Code 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 18 de 32 
O Visual Studio Code ou apenas VSCode, é um editor de código-fonte 
desenvolvido pela Microsoft para Windows, Linux e macOS. Inclui suporte para 
depuração, controle de versão de código com Git integrado, realce de sintaxe, 
autocompletar de código inteligente, fragmentos de código e até mesmo a refatoração 
de código. Também é personalizável, permitindo aos usuários alterar o tema, as 
teclas de atalho e as preferências do editor. 
Além de ser totalmente gratuito, ainda no segundo semestre do ano de 
lançamento, durante o evento Connect, a editora de código fonte foi anunciada como 
open source, tendo o seu código disponibilizado no GitHub, o que permite à 
comunidade técnica uma ativa contribuição para o seu desenvolvimento e facilidade 
na criação de extensões e novos recursos. 
As extensões são poderosas funcionalidades que deixam esse editor de 
código com as atribuições necessárias para conseguir trabalhar nas mais diversas 
tecnologias e linguagens existentes até então. 
Integração Contínua 
A integração contínua é uma prática comum na criação de software, e os 
desenvolvedores geralmente combinam suas alterações de código em um repositório 
central. Depois disso, se executa a build e o teste. Em geral, integração contínua se 
refere ao estágio de criação ou integração do processo de lançamento do programa, 
além de iniciar componentes de automação (por exemplo, builds e testes 
automatizados) e componentes culturais, como práticas de DevOps. O principal 
objetivo da integração contínua é encontrar e explorar bugs mais rapidamente, 
melhorar a qualidade do programa e reduzir o tempo necessário para verificar e lançar 
novas atualizações de software em produção. 
 
Introdução e Instalação do Jenkins 
Jenkins é um servidor de automação de jobs, de código-fonte aberto e 
gratuito. Ele ajuda a automatizar as partes de design, teste e implantação do 
desenvolvimento de um software e permite a implantação de forma automatizada. É 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 19 de 32 
um sistema baseado em servidor que roda em contêineres de servlet como o Apache 
Tomcat. 
Ele se originou a partir de outra solução bem conhecida, o Hudson, que era 
originalmente uma ferramenta de código aberto, até ser comprada pela Oracle em 
2010. 
Neste ponto, alguns programadores da equipe concordaram em ir para a 
Oracle para dar continuidade ao projeto, mas em 2011 outros programadores 
decidiram pegar um caminho diferente e desenvolver a ferramenta de forma open 
source, usando então o nome Jenkins. 
Criação de Pipeline no Jenkins 
A palavra pipeline não possui uma tradução literal, mas pode se entender que 
uma pipeline é, de forma bem simplificada, uma sequência de passos que deve ser 
dada de maneira ordenada para alcançar um resultado esperado. 
No Jenkins, existem algumas formas possíveis de criação de Jobs, e o mais 
utilizado atualmente são os Pipeline Jobs. 
Através dos Pipeline Jobs, é possível configurar a sequência de passos que 
uma build deve ter, utilizando se apenas uma estrutura baseada em JSON e a partir 
disso poder integrar com outras ferramentas, como GitHub para obtenção da última 
versão do código fonte. 
Outra funcionalidade importante, na criação de Pipeline Jobs no Jenkins é a 
utilização de plugins. Através dos plugins, é possível integrar com mais ferramentas 
além do GitHub, pode se utilizar desses plugins para integrar com Slack, SonarQube, 
Junit, dentre muitas outras mais. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 20 de 32 
Capítulo 3. Refatoração de Código 
Refatoração é o processo de mudar o código-fonte do software de uma forma 
tal que não mude seu comportamento externo, com o único objetivo de melhorarsua 
estrutura interna. Ele é usado para manter um software bem projetado, mesmo com 
o passar do tempo e com as mudanças que ele sofre ao longo do seu ciclo de vida. 
Durante o processo de desenvolvimento de software, mais especificamente 
na fase de codificação, é comum que uma equipe de desenvolvedores cuide do 
trabalho de escrever o código, o que significa que várias pessoas irão escrever e 
compartilhar o código entre si até que o software seja concluído. 
Quanto maior for a equipe, menos contato entre os desenvolvedores e maior 
a probabilidade de pequenos erros, como: código repetitivo, classes nos pacotes 
errados, métodos nas classes erradas e outros erros que podem alterar a estrutura 
interna do software, deixando o mesmo um pouco caótico e muito confuso. 
 
Bad Smells 
Bad Smells (mau cheiros), é uma situação em que a estrutura do programa 
pode ser melhorada pela refatoração. Quando Martin Fowler estava escrevendo a 
primeira edição do livro (Refactoring, improving the design of existing code), ele foi 
visitar Kent Beck na sua casa em Zurick e naquela época Kent Beck começou a falar 
sobre os problemas de códigos como coisas relacionadas a odores. Martin Fowler 
imaginou que seu amigo poderia estar sendo influenciado pelos odores das fraldas 
da sua filha recém-nascida. Nesse momento, eles descreveram a ideia de quando 
deveria ser necessário refatorar, chamando isso de Bad Smells. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 21 de 32 
Capítulo 4. Programação em Par 
A programação em par é uma técnica ágil de desenvolvimento de software 
na qual dois programadores trabalham juntos em uma estação de trabalho. Um, o 
"controlador", escreve o código enquanto o outro, chamado de "observador", analisa 
cada linha de código. Os dois programadores frequentemente trocam de funções. 
A programação em pares é uma das práticas mais conhecidas e controversas 
usadas por aqueles que abraçam a programação extrema ou no inglês, extreme 
programming. 
À primeira vista, a programação em pares parece ser uma prática fadada ao 
fracasso e ao desperdício. Afinal, embora possa haver alguns benefícios, sentimos 
que consumirá mais recursos ou aumentará o tempo de desenvolvimento. No entanto, 
não é exatamente isso o que está acontecendo. 
A programação em par nos ajuda a manter o foco, afinal, há alguém sentado 
ao nosso lado que está interessado em resolver o problema. Mesmo se tentarmos, 
certamente evitaremos fazer qualquer coisa além de concentrar nossas energias na 
solução do problema em questão. 
Existem estudos que comprovam as vantagens da programação em par, 
desde que praticada corretamente. Abaixo, serão informados alguns aspectos que 
não devem ser aplicados quando se utiliza esta prática, os quais são: 
 Monopolização da estação de trabalho; 
 Divagar sobre discussões filosóficas; 
 Não fazer pausas para evitar o burn out; 
 Parear sempre com as mesmas pessoas; 
 Não estar disposto a aprender; 
 Não estar disposto a ensinar; 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 22 de 32 
 Faltar com empatia; 
 Dentre outras atitudes que aconselha-se não praticar quando estiver em uma 
cerimônia de programação em par. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 23 de 32 
Capítulo 5. Aprovisionamento e Gerenciamento de Infraestrutura Ágil 
O conceito “agile” nasceu na área de desenvolvimento de software por estar 
mais próximo da área de negócios que sempre pede novos recursos para atender à 
demanda do mercado. 
Para atender a área de negócios que sempre quer novidades, a área de 
desenvolvimento de software foi aprimorada para isso. Por outro lado, a área de 
operações de TI deseja o mínimo de mudança possível na infraestrutura, pois cada 
nova mudança no ambiente de produção cria um novo ponto de instabilidade e na 
maioria das vezes difícil de identificar. Se o desenvolvimento de software é ágil para 
atender à demanda de negócios, a infraestrutura também deve ser. 
Métodos ágeis têm levado a área de desenvolvimento de software a evoluir 
muito, por meio da utilização de iterações de forma incremental, juntamente com 
testes, sejam eles de unidade ou não, pipelines através de continuous integration e 
muitas outras práticas, garantindo entregas contínuas com qualidade. Da mesma 
forma que esse processo tem sido fundamental para essa área, é essencial 
estabelecer padrões que simplifiquem sua infraestrutura e permitam o 
desenvolvimento do SysAdmin para a era do DevOps. 
 
Breve Introdução ao DevOps 
DevOps é uma abordagem de design, automação e cultura de plataforma que 
visa agregar mais valor aos negócios e aumentar sua capacidade de responder às 
mudanças por meio da entrega de serviço rápida e de alta qualidade. Tudo isso é 
possível fornecendo serviços de TI rápidos e iterativos. Adotar o DevOps significa 
uma grande mudança de mindset, através da utilização de ferramentas, mas acima 
de tudo isso, uma mudança de cultura de trabalho. 
A palavra DevOps vem da combinação dos termos desenvolvimento e 
operações. No entanto, representa um conjunto de ideias e práticas que vão além do 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 24 de 32 
significado desses dois termos. DevOps cobre segurança, métodos de trabalho 
colaborativos, análise de dados e muitas outras práticas e conceitos. 
As práticas de DevOps descrevem abordagens que ajudam a acelerar os 
processos necessários para levar uma ideia do desenvolvimento à implementação 
em um ambiente de produção onde ela é capaz de gerar valor para o usuário. 
Essas ideias podem ser um novo recurso de software, uma solicitação de 
aprimoramento ou uma correção de bug, entre outros. Essas abordagens requerem 
comunicação frequente entre as equipes de desenvolvimento e operações, trabalho 
colaborativo e empatia com outros membros da equipe. 
Escalabilidade e implantação flexíveis também são necessárias. Com o 
DevOps, você pode conservar recursos por meio de autoatendimento e automação. 
Os desenvolvedores, que normalmente escrevem código em um ambiente de 
desenvolvimento integrado padrão, trabalham em conjunto com a equipe de 
operações de TI para ajudar a construir, testar e lançar aplicações mais rapidamente, 
sem comprometer a confiabilidade. 
Obviamente, isso significa mudanças de código mais frequentes e uso mais 
dinâmico da infraestrutura. As estratégias tradicionais de gestão não respondem a 
esse tipo de demanda. Mudanças são sempre necessárias para se alcançar as 
vantagens competitivas. 
 
História da Cloud 
Acredita-se que, em 1957, John McCarthy, o inventor da linguagem LISP, 
delineou o conceito atual de computação em nuvem. Claro, ele não conseguia 
imaginar como seria a internet ou mesmo o potencial da computação e 
armazenamento remotos, mas sua ideia de que a computação poderia ser vista como 
um serviço público no futuro estava notoriamente à frente de seu tempo. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 25 de 32 
Na década de 1970, a IBM lançou o primeiro sistema identificado como uma 
máquina virtual que permitia que a computação fosse compartilhada para trabalho 
simultâneo - a primeira forma comercial de compartilhamento de tempo. Nas duas 
décadas seguintes, a Internet como a conhecemos começou a se desenvolver e a 
combinação desses dois conceitos se tornou cada vez mais próxima. 
O termo nuvem não é novo na Internet, embora seja muito difícil definir a 
origem de seu uso específico. Alguns sugerem que a nuvem já era um símbolo 
popular que definia a Internet muito antes de seu novo significado, enquanto outros 
acreditam que a ideia de armazenamento abundante e rapidamente acessível 
inspirou o uso de um símbolo universal de leveza e de pureza. 
Qualquer que seja o significado real, o ponto é que o termo Cloud Computing, 
como a conhecemos, foi usadopela primeira vez em 1997 pelo professor Ramnath 
Chellappa. Desta vez, todo o conceito estava lá: uma estrutura de servidores 
conectados à Internet que poderia armazenar dados e fornecer poder de computação 
remotamente para seus clientes. 
Desde então, a nuvem se tornou um dos tópicos mais comentados pelos 
profissionais de TI em todo o mundo. O ambiente corporativo acabou sendo a área 
onde a nuvem causou e vem causando as mudanças mais profundas. 
Isso vem acontecendo desde 2006, quando a Amazon lançou o Elastic 
Compute Cloud, EC2 e abriu os Amazon Web Services (AWS). Desde então, Cloud 
Computing se tornou uma opção verdadeiramente viável para empresas de todos os 
tamanhos. Pouco depois, em 2009, o Google Apps se tornou o primeiro grande 
serviço de aplicativo baseado em nuvem e os conceitos de IaaS e SaaS estavam 
prontos para dominar o mercado. 
Hoje, a nuvem está presente em nossas vidas em vários níveis: desde o 
armazenamento de nossos arquivos pessoais no celular até as operações e 
infraestruturas de grandes empresas. 
 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 26 de 32 
Introdução à AWS 
Amazon Web Services, também conhecido como AWS, é uma plataforma 
para serviços de computação em nuvem, que constituem uma plataforma de 
computação em nuvem oferecida pela amazon.com. É o mais abrangente do mundo 
e oferece mais de 175 serviços de data center em todo o mundo. 
Milhões de clientes, incluindo as startups de crescimento mais rápido, 
grandes corporações e as maiores agências governamentais, usam a AWS para 
cortar custos, se tornarem mais ágil e inovar com mais rapidez. 
A AWS oferece muito mais serviços - e mais funcionalidade com esses 
serviços - do que qualquer outro provedor de nuvem: de tecnologias de infraestrutura, 
como computação, armazenamento e bancos de dados, a tecnologias emergentes, 
como aprendizado de máquina e inteligência artificial, obtenção de dados, análise e 
internet das coisas (IOT). Isso torna mais rápido, fácil e barato mover as aplicações 
para a nuvem e, a partir disto, criar uma grande gama de possibilidades no 
desenvolvimento de recursos de software e infraestrutura de hardware. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 27 de 32 
Capítulo 6. Infraestrutura como código 
Infrastructure as Code (IaC), ou Infraestrutura como Código, é uma 
metodologia de automação de infraestrutura de TI usada principalmente para que as 
equipes de DevOps possam gerenciar e provisionar infraestrutura por meio de código 
de uma forma automatizado, em vez de ter que o fazer através do acesso físico ao 
hardware ou mesmo através de portais ou ferramentas de configuração. 
Este método, que pode ser aplicado a recursos físicos, virtuais ou em nuvem, 
pode ser usado de forma extremamente estratégica no planejamento de recursos de 
tecnologia. Em suma, a abordagem IaC nada mais é do que fornecer uma 
infraestrutura ágil com codificação simples e objetiva, sem as múltiplas etapas e 
processos envolvidos na preparação de um ambiente, sem perder o controle, a 
segurança, qualidade e disponibilidade. 
Isso se deve, em grande parte, ao fato de que o uso de "código" para 
desenvolvedores de software significa que, em vez de administradores de sistema, 
um desenvolvedor pode fornecer e gerenciar os recursos de tecnologia das 
operações de tudo o que estão criando. 
 
IaC 
IaC é a sigla para Infrastructure as Code, que significa Infraestrutura como 
Código. Por muito tempo, era comum os processos serem monitorados manualmente, 
o que consumia muito tempo da equipe de Infraestrutura. 
Em geral, a IaC torna mais fácil gerenciar o ambiente operacional, já que você 
apenas desenvolve o código e ele fará o restante das operações necessárias para 
aplicar as alterações. A IaC é particularmente útil em ambientes DevOps para 
gerenciar vários recursos e processos. 
Em um momento em que não é incomum para uma empresa implantar 
centenas de aplicativos em produção todos os dias, e quando a infraestrutura está 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 28 de 32 
em constante crescimento, encolhendo e expandindo em resposta às demandas de 
desenvolvedores e usuários. 
É importante para uma empresa automatizar a infraestrutura para controlar 
custos, reduzir riscos e responder rapidamente às novas oportunidades de negócios 
e ameaças competitivas. 
Também é uma prática de DevOps essencial para um ciclo de vida de entrega 
de software. Ela permite que as equipes criem versões da infraestrutura da mesma 
forma que o código fonte da versão e rastreiem essas versões para evitar 
inconsistências entre os ambientes de TI que podem levar a sérios problemas durante 
a implantação. 
Existem vários benefícios como acelerar significativamente o processo de 
implantação de infraestrutura para desenvolvimento, teste e produção. Em IaC 
codifica-se tudo para automatizar o provisionamento da infraestrutura existente, que 
de outra forma poderia passar por processos demorados. Com uma consistência mais 
aperfeiçoada, a IaC evita desvios, proporcionando sempre o mesmo ambiente, 
simplifica o provisionamento e garantindo a estruturação da infraestrutura. Ela pode 
acelerar, com segurança, as fases do ciclo de vida do software que exigem o 
aprovisionamento de infraestrutura. 
O maior desafio para qualquer organização que adota IaC é, sem dúvida, 
mudar a cultura e a curva de aprendizado. Acredita-se que, em última análise, os 
benefícios da infraestrutura como código valem a pena. 
 
Terraform 
Terraform é uma ferramenta de aprovisionamento de infraestrutura de código 
aberto, criada pela HashiCorp, que nos permite definir nossa infraestrutura como 
código (IaC), usando uma linguagem simples e declarativa a Hashicorp Configuration 
Languague, também conhecida como HCL. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 29 de 32 
Com o Terraform, é possível gerenciar infraestruturas entre vários provedores 
de nuvem, sejam eles públicos ou até mesmo privados. 
Na versão 0.10, ele foi dividido em vários “plugins” baixados de acordo com 
a necessidade de seu código. Cada um permite a integração com um provedor 
diferente, tem suas próprias propriedades em recursos e varia ligeiramente na 
sintaxe. 
O formato de arquivo esperado pelo terraform é .tf. Ao contrário de outras 
ferramentas IaC, não há necessidade de se preocupar com a estrutura do arquivo, 
que difere de não organizar seu código, pois o terraform irá compilar todos os arquivos 
.tf no diretório atual e suas subpastas, antes de executá-lo. 
Com ele, podemos criar uma única máquina em serviços de nuvem como 
instâncias EC2 (Elastic Compute Cloud) na AWS (Amazon Web Services) que a 
ferramenta suporta, ou também podemos criar várias máquinas e, assim, criar todo o 
data center, e sempre configurar com poucas linhas de código e poucos arquivos. 
Outra característica importante da ferramenta é o plano de execução. Sempre 
podemos verificar a ordem de execução de uma infraestrutura para ver os passos que 
o terraform realizará para atingir o estado descrito nos arquivos de configuração. 
Para entender melhor o fluxo de criação da infraestrutura a partir da utilização 
do Terraform, serão apresentados a seguir os seus principais comandos e suas 
respectivas funcionalidades. 
 terraform init: é responsável por iniciar a pasta de trabalho e fazer o download 
de todos os plugins necessários para trabalhar com os providers especificados 
no arquivos de configuração .tf. 
 terraform plan: exibirá o plano de execução que será aplicado à infraestrutura. 
 terraform apply: este comando irá criar ou até mesmo atualizar ou destruir os 
recursos no provedor de cloud. 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 30 de 32 
 terraform destroy: deve ser utilizado com cautela, pois ele é o responsável por 
destruiros recursos existentes no provedor, ou provedores, que estiverem 
especificados no arquivo .tf, portanto, antes de utilizar o “terraform destroy” 
espera-se que a pessoa esteja segura da sua correta utilização. 
Existem muitos outros comandos existentes na ferramenta, mas os 
apresentados anteriormente são os principais e, a partir deles, será possível que o 
time consiga aprovisionar os seus primeiros recursos na cloud. 
 
 
 
 
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 31 de 32 
Referências 
BRIKMAN, Yevgeniy. Terraform: Up and running. O’Reilly Media Inc, 2017. 
CHACON, Scott; STRAUB, Ben. Pro Git. Apress, 2014. 
COHN, Mike. Agile Estimating and Planning. Prentice Hall, 2005. 
CTIC-UFPA. Procedimentos do Planning Poker, versão 1.3. Centro de Tecnologia da 
Informação e Comunicação da Universidade Federal do Pará, 2011. 
FERREIRA, Felix Soares; POCIVI, Viviane Carla Batista. Gestão Ágil de Projetos: 
Método para estimativa em projeto de software para fábrica de software acadêmica. 
In: Revista Ada Lovelace, v. 1, 2017. p. 05-17. Disponível em: 
<http://45.4.96.34/index.php/adalovelace/article/view/4120/2532>. Acesso em: 22 
dez. 2020. 
FONSECA, da S. W. D. Ferramenta para apoio à estimativa baseada em Planning 
Poker utilizando a metodologia Scrum. UFPE – Recife, 2008. Disponível em: 
<https://www.cin.ufpe.br/~tg/2012-1/dwas.pdf>. Acesso em: 22 dez. 2020. 
FOWLER, Martin. Refactoring, Improving the design of the existing code. Pearson 
Education Inc, 2019. 
GRENNING, J. Planning Poker or How to avoid analysis paralysis while release 
planning. 2002. 
KNIBERG, H.; SKARIN, M. Kanban and Scrum – Making the most of both. Estados 
Unidos da América, 2009. Disponível em: 
<https://www.infoq.com/br/minibooks/kanban-scrum-minibook/>. Acesso em: 22 dez. 
2020. 
LEISHMAN, C. The 3 Ps of Estimation: Why we estimate in Agile projects. Medium, 
2008. Disponível em: <https://medium.com/@cleishm/the-3-ps-of-estimation-
aee352cf9b16#.7sa58argz,Agosto>. Acesso em: 22 dez. 2020. 
http://45.4.96.34/index.php/adalovelace/article/view/4120/2532
https://www.cin.ufpe.br/~tg/2012-1/dwas.pdf
https://www.infoq.com/br/minibooks/kanban-scrum-minibook/
https://medium.com/@cleishm/the-3-ps-of-estimation-aee352cf9b16#.7sa58argz,Agosto
https://medium.com/@cleishm/the-3-ps-of-estimation-aee352cf9b16#.7sa58argz,Agosto
 
 
Técnicas e Práticas Ágeis de Desenvolvimento de Software – Página 32 de 32 
MARTIN, Robert C. Agile Software Development, Principles, Patterns and Practices. 
Pearson, 2014. 
MORRIS, Kief. Infrastructure as Code, Managing Servers in the Cloud. O’Reilly Media 
Inc, 2016. 
PRESSMAN, R.S. Engenharia de software. 6. ed. São Paulo: Mcgraw-hill, 2006. 
SOMMERVILLE, I. Engenharia de software. 6° ed. Tradução Maurício de Andrade. 
São Paulo: Ed Addison-Wesley, 2003. 
SUTHERLAND, Jeff. Scrum: A arte de fazer o dobro do trabalho na metade do tempo. 
São Paulo: Sextante, 2019.