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

Fundamentos de Engenharia de Software
Analia Irigoyen
2020
Fundamentos
Engenharia de Software
Analia Irigoyen
© Copyright do Instituto de Gestão e Tecnologia da Informação.
Todos os direitos reservados.
Fundamentos de Engenharia de Software – Página 2 de 71

Sumário
Capítulo 1. Introdução à Engenharia de Software ................................................. 6
Cenário atual do Desenvolvimento de Software ................................................. 6
Definições clássicas de Engenharia de Software:............................................... 7
Tipos de aplicações ............................................................................................ 7
Capítulo 2. Ciclos de Desenvolvimento de Software ........................................... 10
Tipos de Ciclo de Vida .......................................................................................... 10
Sequencial (Cascata) ........................................................................................ 10
Iterativo (Incremental) ....................................................................................... 11
Ciclo de Vida – RAD ......................................................................................... 12
Ciclo de vida evolutivo ...................................................................................... 12
Ciclo de vida espiral .......................................................................................... 14
RUP - Rational Unified Process ........................................................................ 15
Capítulo 3. Metodologias Ágeis ........................................................................... 18
Contexto e motivação ........................................................................................... 18
Principais mitos ..................................................................................................... 19
Manifesto ágil - Valores e princípios ágeis ............................................................ 20
Scrum ................................................................................................................... 23
Times de Scrum ................................................................................................ 24
O fluxo do Scrum .................................................................................................. 25
Kanban ................................................................................................................. 26
Os papéis e características do Kanban............................................................. 27
O fluxo do Kanban ............................................................................................ 27
Planejamento .................................................................................................... 28
Autogerenciamento e execução ........................................................................ 30

Identificação de classes de serviços ................................................................. 32
Melhoria contínua.............................................................................................. 32
ScrumBAN ............................................................................................................ 33
Planejamento .................................................................................................... 34
Monitoração ...................................................................................................... 34
Melhoria contínua.............................................................................................. 34
XP ......................................................................................................................... 34
Os valores do XP .............................................................................................. 35
Capítulo 4. Principais ferramentas usadas para o ciclo de desenvolvimento de

software Ágil e DevOps ............................................................................................ 38
Azure DevOps....................................................................................................... 39
Jira ........................................................................................................................ 41
Capítulo 5. Introdução ao DevOps ...................................................................... 46
Overview de DevOps ............................................................................................ 47
CALMS ................................................................................................................. 48
DevOps – Primeira Maneira .............................................................................. 49
Infraestrutura como código (IaC)....................................................................... 50
IaaS, SaaS e PaaS ........................................................................................... 51
Vantagens do PaaS .......................................................................................... 52
Estratégia de Branching .................................................................................... 56
Categorias de liberação (Release) .................................................................... 57
Arquitetura de baixo risco ................................................................................. 59
DevOps - Segunda Maneira.................................................................................. 59
DevOps - Terceira Maneira ................................................................................... 62
Motivação .......................................................................................................... 63

A importância da Terceira Maneira ....................................................................... 65
A Terceira Maneira e o Profissional DevOps do tipo T-shaped ............................ 66
Conceitos da Arquitetura Lean.............................................................................. 68
Referências………. .................................................................................................. 70

Capítulo 1. Introdução à Engenharia de Software
A grande reflexão que fazemos quando pensamos em desenvolvimento de

software é: por que se leva tanto tempo para concluir um software?
Segundo o dicionário Aurélio, Engenharia de Software é:
“Arte de aplicar conhecimentos científicos e empíricos e certas

habilitações específicas à criação de estruturas, dispositivos e
processos que se utilizam para converter recursos naturais em
formas adequadas ao atendimento das necessidades humanas.”
Atualmente o termo Engenharia de Software é mais comumente usado para

referir-se a:
 Modelos de ciclo de vida.
 Métodos e ferramentas.
 Técnicas para estimativa de custos.
 Documentação.
 Técnicas para controle da qualidade.
Entretanto, o desenvolvimento de software é um problema de Engenharia.
 Busca-se:
‒ A criação de soluções econômicas para problemas práticos.
‒ Construir objetos a serviço da sociedade.
Cenário atual do Desenvolvimento de Software
Temos um cenário de desenvolvimento de software na maioria das

organizações, onde:

 Há uma pressão constante por parte do cliente pela entrega rápida.
 Cliente acha que em uma única reunião de 30 min já somos capazes de

desenvolver um software.
 Desenvolvedores são orientados à solução: desejam começar logo a

programar, sem ter um entendimento claro do que é necessário.
Definições clássicas de Engenharia de Software:
Pela IEEE Glossary of Software Terminology, enfoque sistemático para o

desenvolvimento, operação, manutenção e descontinuação do software.
Por Barry Boehm, “aplicação prática do conhecimento científico no projeto e

construção de programas e da documentação requerida para desenvolver, operar e
manter esses programas”.
Por Fritz Bauer, “criação é a utilização de sólidos princípios de engenharia, a

fim de obter softwares econômicos que sejam confiáveis e que trabalhem
eficientemente em máquinas reais”.
Tipos de aplicações
Os seguintes tipos de aplicações são os mais comuns na Engenharia de

Software:
Software de Sistema:
 Software que serve a outro software, hardware, processos, pessoas etc.
 Windows, Linux, Ios, Android e MACos.

Software de Aplicação:
 Programas isolados que resolvem uma necessidade específica do negócio.
 Suite Office, Jogos, Browsers, Banco de Dados etc.
Sistemas de Tempo Real:
 Sistema que deve responder com suficiente rapidez (milissegundos) ou o

ambiente ficará fora de controle.
 Ex.: ATMs (caixa eletrônico), orientação aérea, monitoração de pacientes e

validadores de transporte público.
Software Científico e de Engenharia:
 Processamento de grandes cálculos (astronomia, biologia molecular,

vulcanologia etc.).
Software Embutido ou Embarcado:
 Reside dentro de um produto ou sistema (controle de aparelhos domésticos

(microondas, geladeira, cofres), automóveis (controle de combustíveis,
dashboard de avaliação dos sistemas automotivos etc.).
Aplicações Web:
 Dados são introduzidos remotamente.
 Interação com o computador através de terminais.
 Dados armazenados são rapidamente acessados.
Software de linha de produto:
 Software que provê capacidade específica a ser usada por muitos clientes.
 Editores de texto, planilhas eletrônicas, apresentação etc.

Software baseado em conhecimento (inteligência artificial):
 Aplicações que utilizam algoritmos para resolver problemas complexos, que

não são passíveis de computação ou análise direta, exigindo interpretação.
 Sistemas especialistas, processamento de padrões de imagem e voz, sistemas

de jogos inteligentes, redes neurais etc.
Computação Ubíqua:
 Tornar a interação pessoa-máquina invisível, ou seja, integrar a informática

com as ações e comportamentos naturais das pessoas.
Software Legado – Desenvolvidos há um longo tempo e algumas vezes:
 Têm projetos não extensíveis.
 Código complicado.
 Documentação pobre ou inexistente.
 Casos de testes não documentados.
 Histórico de modificações mal geridas.

Capítulo 2. Ciclos de Desenvolvimento de Software
O ciclo de vida de um projeto consiste em fases e atividades que são definidas

de acordo com o escopo, recursos e a natureza (características) do projeto, visando
oferecer maior controle gerencial.
A cada fase do ciclo de vida do projeto são gerados produtos de trabalho

necessários para o desenvolvimento das fases posteriores.
Essa organização em fases permite planejar o projeto, incluindo os marcos

importantes para controle do projeto. Os marcos do projeto precisam ser previamente
definidos ao se realizar o planejamento do projeto.
É possível adotar as técnicas de fast-tracking e collision, sem afetar os ciclos

de vida. A técnica fast-tracking permite que atividades sejam iniciadas antes de outra,
mesmo tendo dependências, desde que o risco seja tratado. A técnica collision
permite que mais pessoas sejam alocadas em uma determinada tarefa para garantir
a data de entrega, desde que o risco seja tratado.
A seguir foram detalhados os ciclos de vida mais comuns.
Tipos de Ciclo de Vida
Sequencial (Cascata)
Neste ciclo ocorre uma abordagem sequencial ao decorrer do projeto, ou seja,

as fases do ciclo de desenvolvimento são executadas em uma sequência ordenada.
Desta forma, a passagem para determinada atividade exige como critério a finalização
da atividade imediatamente anterior.
Um dos pontos fortes do modelo sequencial está na ênfase dada a uma

abordagem disciplinada e na recomendação de que todos os produtos de cada fase
sejam formalmente revisados.
Normalmente, as fases deste modelo de ciclo de vida são:

 Iniciação (Não iterativo).
 Planejamento (Não iterativo).
 Análise dos Requisitos (Não iterativo).
 Encerramento do Planejamento e Requisitos (Não iterativo).
 Desenvolvimento (Não iterativo).
 Entrega (Não iterativo).
Iterativo (Incremental)
Neste ciclo, a construção do produto ocorre em pequenos passos (iterações),

que evoluem para o produto final.
A abordagem prevê a organização em fases que possuem objetivos distintos.

Em cada fase são realizadas atividades em uma ordem sequencial.
Para cada fase ocorrerão tipicamente múltiplas iterações. O número de

iterações pode variar, dependendo dos requisitos especiais do projeto. Normalmente,
a fase de “Iniciação” e a fase de “Planejamento” possuem uma única iteração.
Normalmente, as fases deste modelo de ciclo de vida são:
 Iniciação (não iterativo).
 Planejamento (iterativo).
 Análise dos requisitos (iterativo).
 Encerramento do planejamento e requisitos (iterativo).
 Desenvolvimento (iterativo).
 Entrega (iterativo).

Ciclo de Vida – RAD
O ciclo de vida Desenvolvimento Rápido de Aplicações (Rapid Application

Development) tem como objetivos: a adaptação de “alta velocidade” do modelo
Cascata e exige requisitos bem compreendidos e escopo fechado.
Características deste ciclo de vida:
 Sistema plenamente funcional entre 60 e 90 dias.
 Incremental (ciclos curtos).
 Baseado em componentes.
 Modularidade (equipes distintas).
 Requisitos precisam estar bem definidos e o escopo deve ser restrito.
As principais desvantagens:
 Requer recursos humanos suficientes para criar um número adequado de

equipes.
 Requer um comprometimento entre desenvolvedores e clientes, para que as

atividades possam ser realizadas rapidamente e o sistema seja concluído em
um tempo abreviado. Se o comprometimento for abandonado por qualquer
uma das partes, o projeto falhará.
 Não é apropriado quando os riscos são grandes.
Ciclo de vida evolutivo
Os ciclos de vida do tipo “evolutivo” têm as seguintes características:
 Software evolui com o tempo e o uso das versões iniciais.
 Também é um modelo Iterativo.

 Requisitos são parcialmente definidos e depois são refinados.
 Desenvolve-se uma versão parcial que atinge requisitos conhecidos.
 A partir do conhecimento adquirido com o uso, evolui-se o produto
Estes ciclos de vida têm os seguintes problemas:
 Cliente não sabe que o software que ele vê não considerou, durante o
desenvolvimento, a qualidade global e a manutenibilidade a longo prazo. Força
a utilização do protótipo como produto final.
 Desenvolvedor frequentemente faz uma implementação comprometida, com o

objetivo de produzir rapidamente um protótipo. Depois de um tempo ele se
familiariza com essas escolhas.
É importante ressaltar que apesar dos problemas, existem alguns

comentários importantes:
 Ainda que possam ocorrer problemas, prototipação é um modo de vida

eficiente.
 Deve-se definir as regras do jogo logo no início
 O cliente e o desenvolvedor devem ambos concordar que o protótipo seja

construído para servir como um mecanismo a fim de definir os requisitos

Ciclo de vida espiral
Os ciclos de vida do tipo “espiral” têm as seguintes características:
 Combina a iteração da Prototipagem com aspectos do Cascata.
 Software desenvolvido em versões evolucionárias.
 Primeiras versões (ciclos) podem ser modelo de papel, seguindo um protótipo

etc.
 Modelo guiado por riscos.
 Abordagem cíclica.
 Aumentar incrementalmente o grau de definição e implementação de um

sistema, enquanto seu grau de risco diminui.
 Marcos de ancoragem: ajudam a estabelecer quando um ciclo é completado

em torno da espiral e fornecem marcos de decisão antes do projeto de software
prosseguir. Ex.: objetivos do ciclo de vida, arquitetura do ciclo de vida,
capacidade inicial de operação.
 Garantir o comprometimento dos interessados.
 Usa uma abordagem que capacita o desenvolvedor e o cliente a entender e

reagir aos riscos em cada etapa evolutiva.
 Pode ser difícil convencer os clientes que uma abordagem “evolutiva” é

controlável.
 Exige considerável experiência na determinação de riscos e depende dessa

experiência para ter sucesso.

RUP - Rational Unified Process
Os ciclos de vida do tipo “RUP” têm as seguintes características:
 Processo de desenvolvimento de SW criado e mantido pela Rational/IBM.
 Baseado no ciclo de vida em espiral (refinamentos sucessivos).
 Baseada em disciplinas:
‒ Tarefas.
‒ Responsabilidades.
 Guia para a utilização de UML:
‒ Desenvolvimento dirigido por casos de uso.
 Processo configurável (customizável).
 Avaliação contínua dos riscos do projeto.
 Geração de produtos interdependentes em todas as interações.
 Desenvolvimento iterativo-incremental:
‒ Iteração:
 Conjunto de atividades de modelagem de negócios, requisitos,

análise e projeto, implementação, teste e implantação, em várias
proporções, dependendo do local em que ela está localizada no
ciclo de desenvolvimento.
‒ Disciplina:
 Conjunto de atividades relacionadas a uma 'área de interesse'

importante em todo o projeto.
‒ Papéis:

 O comportamento e as responsabilidades de um indivíduo ou de
um conjunto de indivíduos.
As fases estão definidas de acordo com a figura abaixo:
A tabela abaixo detalha as principais saídas de cada fase:

Vantagens deste ciclo:
 Design inicial contém falhas.
 Descoberta tardia de defeitos de design tem grande impacto.
 Todos os projetos têm riscos.
 Quanto mais cedo analisar os riscos mais chance de mitigar.

Capítulo 3. Metodologias Ágeis
Contexto e motivação
Com o aumento da maturidade organizacional em desenvolvimento de

processos e a busca pela alta competitividade e qualidade, as organizações estão
cada vez mais adotando abordagens ágeis com o principal objetivo de aumentar o
valor de negócio para a organização. Atualmente, as organizações não têm tempo a
perder com projetos de escopo fechado que duram mais de 6 meses.
Neste sentido, muitas dúvidas surgem no mercado a respeito dos modelos

ágeis, dentre elas:
 É possível usar uma combinação de modelos tradicionais (PMBOK, por

exemplo) e agilidade?
 As duas abordagens são compatíveis (tradicional e ágil) ou complementares?.
Entendendo que os modelos tradicionais de gestão e os métodos ágeis têm

o mesmo objetivo: o sucesso do projeto, como adaptar as práticas ágeis ao contexto
organizacional? Qual abordagem ágil é a melhor para minha empresa?
Iniciaremos com um histórico das metodologias ágeis que surgiram

inicialmente na área de TI (Tecnologia da Informação) e hoje são amplamente
utilizados por outros domínios, como oficinas mecânicas, hospitais, comércios,
advogados e até para o uso pessoal.
1. Anos 90: apareceram algumas metodologias ágeis, tais como XP (Kent Beck
e Ron Jeffries), 5 valores, 14 princípios e TDD, Scrum (Sutherland, Schwaber,
Beedle), Crystal (AlistairCockBurn) e Lean (manufatura).
2. A partir do ano 2000: existe ampla divulgação do Scrum e algumas

experiências são relatadas.
3. Em 2001: divulgação do Agile Manifesto e a criação da Agile Alliance.

4. Em 2008: modelos tradicionais de referências como CMMI, MPS.BR e
PMBOK, lançam guias para utilização dos seus modelos com práticas ágeis.
5. A partir de 2010: aparecem relatos de empresas essencialmente ágeis, que

obtiveram com sucesso certificações de modelos tradicionais, como CMMi,
MPS.BR e ISO.
Principais mitos
Existem alguns mitos relacionados a agilidade que ao longo dos anos foram
desmistificados e/ou esclarecidos, são eles:
 Ambientes ágeis são ad hoc, caóticos e indisciplinados.
 Agilidade significa nenhuma documentação.
 Processos ágeis são imaturos e não são rigorosamente seguidos.
 Não funcionam para equipes geograficamente distribuídas.
 Não funcionam com equipes grandes.
 Não funcionam em empresas que não são de software.
Neste sentido, é um mito não adotar uma gestão ágil e adotar um processo
sem documentação. Se existem documentos que devem ser gerados eles devem ser
previstos como tarefas e sua revisão nos critérios de “done”. Os valores e princípios
da agilidade se remetem a agregar valor ao cliente; se para o cliente estes
documentos são importantes, eles serão gerados.
Os ambientes ágeis, por promoverem um senso comum e espírito de equipe,

costumam ser bem mais silenciosos e disciplinados que as equipes tradicionais.
Alguns times possuem regras claras quanto ao uso de celular e conversas paralelas
fixadas no quadro.

Normalmente, equipes ágeis são mais maduras e, por isso, sabem da
importância que deve ser dada as cerimônias e aos indicadores e acompanhamento
do projeto.
Equipes geograficamente distribuídas e/ou grandes são um desafio para

qualquer tipo de abordagem, seja ela tradicional ou ágil. Existem técnicas de
facilitação e/ou coaching que estão sendo amplamente usadas em projetos que
facilitam o team building e encurtam distâncias.
Os congressos ágeis possuem trilhas específicas para áreas que não são de
TI comentarem e relatarem suas experiências, é possível notar a presença de
médicos, advogados e até empresas de seguros nestas trilhas.
Manifesto ágil - Valores e princípios ágeis
O manifesto ágil divulgado a partir do ano 2000, é amplamente discutido e

utilizado pelos agilistas. É simples, direto e claro. Abaixo na sua íntegra:
 Indivíduos e interações mais que processos e ferramentas.
 Trabalhar no software mais que documentação abrangente.
 Colaboração do cliente mais que negociação contratual.
 Responder às mudanças mais que seguir um plano.
Existem interpretações a respeito deste manifesto, onde traduzem o advérbio

de intensidade “mais que” por não ter. O manifesto estabelece uma priorização a
respeito de questões comuns em projetos, inserindo um pensamento de colaboração,
simplificação e ação. Nesta linha, os princípios ágeis, listados abaixo, detalham este
pensamento. Estes princípios podem ser resumidos em (aprendizado, feedback e
desenvolvimento iterativo):
1. Nossa maior prioridade é satisfazer o cliente por meio da entrega cedo e

frequente de software com valor.

O foco no desenvolvimento do produto ou serviço está em prover entregas de
valor ao cliente, ou seja, a preocupação maior está na satisfação do cliente. Mudar
sempre que necessário, seja o escopo e/ou o planejamento realizado anteriormente,
é prioritário, já que entregar algo de valor é mais importante que seguir um
planejamento inicial.
2. Mudanças de requisitos são bem-vindas, mesmo em fases tardias do

desenvolvimento. Os processos Ágeis utilizam a mudança em favor da
vantagem competitiva para o cliente.
Aceitar a mudança como algo que sempre vai existir e se preparar para lidar
com ela é fundamental. Quando definimos ciclos curtos de feedback, permite-se essa
evolução do conhecimento da equipe e do cliente. Um processo de mudança
burocrático desencoraja e muitas vezes impede uma mudança que é extremamente
necessária para o sucesso do projeto.
3. Entregar software em funcionamento com frequência, desde a cada duas

semanas até a cada dois meses, com uma preferência por prazos mais curtos.
Entregar de forma frequente partes do produto e/ou serviço, que tenham valor
para o usuário e/ou cliente. Assim é possível dar um feedback rápido ao cliente,
reduzindo diversos riscos do projeto (sejam eles de escopo, prazo ou tecnologia).
Esse princípio se opõe a realizar poucas ou, no limite, uma entrega de valor única,
apenas ao final do projeto (o ciclo de vida cascata tradicional).
4. As pessoas do negócio e os desenvolvedores devem trabalhar em conjunto

diariamente, ao longo do projeto.
O trabalho em equipe e a constante comunicação é motivada e incentivada a

ser frequente, objetiva e diária. Esse princípio se opõe a falta de comunicação entre
usuários e o time, entre o próprio time e entre o time e seus líderes. Pessoas não
trabalham de forma obscura e individual.
5. Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o

suporte que precisam e confie neles para realizarem o trabalho.

Dar valor as pessoas e a necessidade de motivação diária com o aumento da
visibilidade e das regras do jogo. Confiança é a chave de um trabalho em equipe.
6. O método mais eficiente e efetivo de se transmitir informação para e entre uma

equipe de desenvolvimento é a conversa face a face.
A melhor forma de comunicação entre membros do time que desenvolve o

produto e/ou serviço, e entre esse time e o mundo externo, é a comunicação face a
face. É possível a utilização de ferramentas e técnicas de team building para construir
algo bem próximo a sinergia existente no face-face.
7. Software em funcionamento é a principal medida de progresso.
Ter o principal objetivo de gerar produto ou serviço que possui algum valor ao
cliente, do que algo que não vai ser utilizado. A documentação deve ser útil e com o
objetivo de aumentar o valor agregado ao cliente traduzido em partes de produtos
e/ou serviços.
8. Os processos Ágeis promovem o desenvolvimento sustentável. Os

patrocinadores, desenvolvedores e usuários devem ser capazes de manter
indefinidamente um ritmo constante.
Deve ser definido um ritmo constante e sustentável para o trabalho do time,

que desenvolve o produto e/ou serviço, o que se torna possível quando esse ritmo é
apoiado por toda a cadeia, incluindo a alta direção e os clientes. Horas extras trazem
desmotivação e falta de qualidade de vida, o que prejudica a produtividade e
consequentemente o alcance dos objetivos do projeto.
9. A atenção contínua à excelência técnica e a um bom projeto aumentam a

agilidade.
A preocupação com a qualidade deve ser única e constante. A qualidade deve

ser mais prioritária que o prazo e a produtividade.
10. Simplicidade, a arte de se maximizar a quantidade de trabalho não feito, é

essencial.

Evita-se o desperdício no desenvolvimento do produto e/ou serviço ao não se
realizar trabalho que não é necessário. Elaborar documentação útil que vai ser
utilizada e planejar com os detalhes que se conhece são os objetivos deste princípio.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes que se

auto-organizam.
Equipes com maior autonomia e auto-organizadas são mais eficientes.

Equipes que não estão esperando um comando têm a responsabilidade e liberdade
de decidir qual a melhor forma de realizar esse trabalho.
12. Em intervalos de tempo regulares, a equipe reflete sobre como se tornar mais
efetiva e então refina e ajusta seu comportamento de acordo.
Para se tornar cada vez mais efetiva, a equipe regularmente inspeciona suas
formas de trabalho e adapta quando oportunidades de melhoria são identificadas,
promovendo a melhoria incremental contínua.
Nesta unidade vamos tentar desvendar aos poucos a sopa de letrinhas ágil
que já invadiu o mercado e tem sido cada vez mais difundida e utilizada para gestão
de projetos. Quem nunca ouviu falar de algumas destas siglas? Scrum, Kanban e
ScrumBAN.
Scrum
É um processo iterativo e incremental para o desenvolvimento de qualquer

produto e gerenciamento de qualquer projeto.
O Scrum resumidamente tem como características:
 Não é metodologia.
 É um framework.
 É adaptável.

 Promete alta qualidade.
 Promete alta produtividade.
 É atitude!
O Scrum tem como pilares:
 Transparência – Tudo que afeta o resultado final deve ser visível para aqueles
que gerenciam os resultados.
 Inspeção – O processo deve ser inspecionado com uma frequência suficiente

para identificar variações inaceitáveis. É importante ressaltar que inspeções
demais podem atrapalhar dependendo do contexto.
 Adaptação – O processo deve ser inspecionado com uma frequência suficiente

para identificar variações inaceitáveis.
O Scrum é baseado em:
 Times de Scrum (Papéis) – Product Owner (PO), Scrum Master (SM) e Team
(Time).
 Time-Boxes (Eventos) – As cerimônias devem ter um time-box de no máximo

4 horas (no caso de planejamento de sprints de 4 semanas).
 Artefatos – Os artefatos User Story, Task Board, Product e Sprint Backlog e

BurnDown Chart, são utilizados ao longo de todo o ciclo do Scrum.
 Regras – As regras como critérios de done, aceitação e regras de time são

estabelecidas e seguidas ao longo do ciclo Scrum (seja de 2 ou 4 semanas).
Times de Scrum
O Product Owner tem o papel de garantir o ROI, conhecer as necessidades

do cliente, manter os itens do backlog atualizados e priorizados, aceitar ou rejeitar o

que foi produzido, ter alta participação no início e no fim do sprint, gerenciar os
requisitos e planejar entregas (releases), além de estar disponível para esclarecer
dúvidas. Já o Scrum Master tem responsabilidade de remover os impedimentos do
time, garantir o uso do Scrum, proteger o time de interferências externas, ensinar a
maximização do valor agregado, melhorar o dia a dia dos membros do time, combater
a ilusão do comando-controle, priorizar os impedimentos e removê-los e facilitar as
reuniões. Finalmente, o time deve ser multidisciplinar, autogerenciado, produzir com
qualidade e valor para o cliente e ter no máximo nove integrantes — comprometidos,
comunicativos e responsáveis pelo alcance do objetivo e resolução de conflitos.
O fluxo do Scrum
O Fluxo do Scrum (Figura 1) é caracterizado por ciclos regulares de 2 ou 4

semanas no máximo, chamados Sprints. O ciclo de vida pode ser considerado
evolutivo (o conhecimento sobre os requisitos evolui à medida que os incrementos
vão sendo executados).
Os requisitos a serem produzidos em um projeto são mantidos em uma lista

nomeada Product Backlog. No início de cada Sprint, faz-se um Sprint Planning
Meeting 1 e 2, ou seja, uma reunião de planejamento na qual o Product Owner prioriza
os itens que estão no Product Backlog (Sprint Planning 1) e a equipe define e estima
as tarefas, que ela será capaz de implementar durante o Sprint que está iniciando. As
tarefas alocadas em um Sprint são incluídas, então, no Sprint Backlog.
Diariamente, ao longo da Sprint, a equipe faz uma breve reunião

(normalmente de manhã) chamada Daily Scrum. O objetivo desta reunião é tornar
visível o andamento das tarefas e identificar impedimentos e priorizar o trabalho do
dia que se inicia.
Ao final de um Sprint, a equipe apresenta o que foi produzido ao Product

Owner em uma cerimônia chamada de Sprint Review Meeting. Finalmente, faz-se
uma Sprint Retrospective, onde são discutidos os pontos de melhoria e ações para a

próxima Sprint (melhoria contínua). Em seguida, a equipe parte para o planejamento
do próximo Sprint e então reinicia-se o ciclo.
Figura 1 – O Fluxo do Scrum.
Kanban
Da mesma forma que o Scrum, a abordagem Kanban também tem seus mitos
e verdades, sendo eles:
 O Kanban e Scrum são opostos, na verdade, o Scrum usa um quadro Kanban

com as opções To-Do , Doing e Done. Logo a utilização das duas abordagens
já acontece e pode ser maximizada com a utilização de outros conceitos do
Kanban.
 O Kanban é vítima da Lei de Parkinson (o trabalho se expande) – É uma

preocupação válida, mas como estamos sempre medindo (cycle time,

feedback curto, entregas contínuas), o foco no controle é mantido, evitando
que o time seja improdutivo.
 Não existe o time box – Não existe esta exigência, mas deve ser utilizado
sempre que o fluxo for otimizado.
 Não existe estimativa – Não existe esta exigência, mas deve ser utilizada
sempre que apropriado e fizer sentido.
 O Kanban substitui outras metodologias (Kanban, Crystal, XP, FDD) – O

Kanban pode ser utilizado com todas estas tecnologias e não substitui o
Scrum, por exemplo.
Os papéis e características do Kanban
 Não existem papéis definidos, defina os seus papéis.
 Respeite o processo atual, seus papéis, responsabilidades e cargos.
 O Kanban utiliza o conceito Kaizen (melhoria contínua).
 Mude devagar e sempre.
O fluxo do Kanban
O Fluxo no Kanban (Figura 2) deve: mapear todo o fluxo de trabalho para

realizar a entrega de um serviço ou projeto – ciclo de vida, mapear a cadeia de valor,
focar no “todo”, gerar transparência e possibilitar a identificação de desperdícios.

Figura 2 – O fluxo do Kanban.
Fonte: site da AdaptWorks
Planejamento
No fluxo do Kanban, é importante limitar o trabalho em progresso e

estabelecer em cada raia o WIP (Work in Progress), o Lead Time – Desde a chegada
do cartão até a entrega e o Tempo de Ciclo, desde a seleção do cartão até a entrega
(Figura 3).
Na definição do WIP, quanto menor o número maior a motivação do sistema

puxado. O sistema “puxado” define que a equipe deve terminar mais do que começar,
ou seja, realizar as tarefas que estão mais perto do lado direito do que do lado
esquerdo. Na ordem de prioridade de cima para baixo, o desconforto é dado por
impedimento de mover para frente os cartões. Para que tenhamos mais trabalhos
finalizados, os cartões devem ser quebrados em tarefas menores, de no máximo 8
horas.

Figura 3 – Representação do WIP ( Work in Profress) no Fluxo do Kanban.
Antes de iniciar a utilização do Kanban, deve ser estabelecida uma política

de qualidade, o Poka Yoke (Pocá ioquê) – a automação de fluxos e regras,
estabelecer padrões e checklists antes de completar as tarefas e prever a análise de
cada defeito quando este ocorre (stop the line – conceito lean para prevenir novos
defeitos) (Figura 4). É imprescindível que seja obtido o comprometimento com a
política e melhoria contínua do processo, todos devem conhecer e se conscientizar
da importância da qualidade no fluxo.
Figura 4 – Representação da política de qualidade e checklists.

Autogerenciamento e execução
Durante a execução do fluxo no Kanban, devem ser ajustadas as cadências

(sequência, ritmo e sucessão regular), os custos associados a entregas de um
produto ou serviço e os custos de espera (espera da aprovação, planejamento,
qualidade, verificação por exemplo). Estes custos de espera prejudicam o feedback
e o conceito do sistema “puxado”.
O Fluxo deve ser medido através de indicadores como: Diagrama de Fluxo

Cumulativo (DFC), Tempo de Ciclo, Índice de Defeitos e Itens Bloqueados.
O Diagrama de Fluxo Cumulativo (Figura 5) deve ser interpretado das formas

abaixo:
 Se a distância entre duas linhas em progresso aumentar, é um sinal de gargalo.
 Se a linha de backlog estiver mais inclinada que a linha do “Done” significa que
está entrando mais coisas que podemos entregar.
É possível utilizar o DFC para medir tempo médio de ciclo e a quantidade de

itens na fila.
Figura 5 – Diagrama de Fluxo Cumulativo (DFC).
Ao analisar o Tempo de Ciclo individual, devem ser feitas os seguintes

questionamentos: “os números indicam consistência?”, “como está a tendência?”, ”É

possível analisar Outliers ?”, “a data de entrega está aceitável (90% entregues em 1
semana)?”.
Já com relação ao indicador “Índice de defeito”, devemos fazer os seguintes

questionamentos (Figura 6): “por que o número de novos defeitos tem aumentado?”
e “como o índice alto de defeitos afetou o tempo do ciclo?”. É importante definir metas
para o índice de defeitos, considerando os objetivos estratégicos e objetivos
estabelecidos ou não em contrato com os clientes.
Figura 6 – Gráfico de taxa de defeitos.
Os itens bloqueantes, sua média, devem ser observados ao longo do tempo.

Podem ser analisados outliers e a causa de médias maiores do que estabelecido na
meta.
Diariamente deve ser revista a priorização dos cartões, considerando o custo

do atraso (a maior prioridade deve ser o item com mais alto item de atraso ou mais
complexo). Além disso, o item mais prioritário deve estar mais acima no quadro. É
importante também levar em consideração itens de: maior risco e incerteza,
necessidades básicas (infraestrutura), tamanho equilibrado, tipo de estória
equilibrado e dependências.

Identificação de classes de serviços
Ao definir os cartões deve existir uma em definir os tipos de trabalho, tais

como: histórias, defeitos, relatórios manuais, tarefas de suporte e instalação. Uma
outra definição tão importante quanto são as classes de serviço, que podem ser
agrupadas em:
 Classe Padrão: defeitos cosméticos e estórias.
 Classe Prioritária: defeitos críticos e estórias de alta prioridade.
 Classe de Prazo Fixo: estórias com prioridade se o prazo estiver próximo.
 Classe Urgente: defeito impeditivos que rompem limites do wip .
O fluxo deve ser gerenciado com o chamado filtro de decisões Agile, seguindo
no mínimo estes questionamentos: “Estamos obtendo progresso?”, “Estamos
encorajando a cultura baseada em confiança?”, “Estamos tratando o WIP como risco
e não como um ativo?”.
Também deve se gerenciar o fluxo com o chamado filtro de decisões Lean,

seguindo no mínimo estes direcionamentos: o valor é mais importante que o fluxo, o
fluxo é mais importante que eliminação de desperdícios, elimine desperdícios para
melhorar a eficiência, alivie gargalos e introduza os buffers. É importante estabelecer
SLAs considerando a base histórica, e deixar bem visível para que todos possam
conhecer e se comprometer.
Após realizar essas análises, a equipe deve planejar entregas, otimizar o fluxo
e experimentar sempre.
Melhoria contínua
Sempre que necessário a equipe deve fazer melhoria contínua no fluxo e nas
regras: mude, experimente, ajuste os WIPS, ajuste o quadro e aumente a visibilidade.

ScrumBAN
A utilização das duas abordagens juntas está cada vez mais sendo adotado
pelo mercado. É possível perceber que ao adotar o ScrumBAN, os progressos andam
mais rápidos. Alguns autores classificam o Kanban como sendo uma evolução e o
Scrum como uma evolução, mais ainda é possível identificar as seguintes vantagens:
o aumento da qualidade, a inserção das inspeções, a inclusão da análise de causas
de problemas/defeitos e a diminuição do desperdício.
A Figura 7 exemplifica graficamente as principais diferenças entre o Scrum,

Kanban e o ScrumBAN .
Figura 7 – As três abordagens ágeis e suas características.
Fonte: https://agilewheel.com/tag/scrumban.

Planejamento
Para efetuar um planejamento usando a abordagem ScrumBan, realize os

seguintes itens: use os papéis do Scrum, planeje considerando que mudanças fazem
parte do escopo, defina regras de sistema puxado, planeje pequenas iterações de
planejamento (todos os dias) e crie outros papéis.
Além destas preocupações, são boas práticas desta abordagem: aumentar o

quadro, incluir raias de atividades e buffer, não indicar o nome das pessoas nos
cartões, utilizar o limite o Backlog (WIP) e usar as regras de priorização.
Monitoração
Durante as reuniões diárias, além dos questionamentos do Scrum, inclua as

seguintes análises: ache os bloqueadores do fluxo, analise os WIPs, crie o Diagrama
de Fluxo Cumulativo e analise suas tendências, utilize métricas de Tempo de Ciclo e
re-priorize. Além disso, faça reuniões do tipo Short Kaizen: Stop the line, follow-up e
planning.
Melhoria contínua
No final de cada ciclo Scrum (sprint), faça a retrospectiva e as Reviews, se

necessário. Inclua nas Reviews a análise das causas dos defeitos. A análise das
causas dos defeitos pode também ser feita ao longo do Sprint.
XP
De acordo com o Livro Jornada Ágil e Digital (MUNIZ, ANTONIO e

IRIGOYEN, ANALIA):
“O XP foi criado em 1997 por Beck, Ward, Cunningham e Jeffries em

um contexto empresarial (e não acadêmico). O método consiste,
resumidamente, em codificar com menor ênfase nos processos

formais de desenvolvimento e com maior ênfase na engenharia ágil
de software, além de valorizar a automatização de testes e ser
flexível para mudanças de requisitos, valorizando o feedback do
usuário e a qualidade do código. O objetivo principal do XP é a
criação de software de alta qualidade, eliminando desperdícios e
orientado a pessoas (WILDT et al., 2015). É composto por um
conjunto reduzido de práticas de desenvolvimento que se organizam
em torno de quatro valores básicos inter-relacionados: feedback,
comunicação, simplicidade e coragem.”
Os valores do XP
Comunicação:
 Usa-se o melhor meio possível para comunicação, formal ou não.
 Preferência à comunicação mais ágil
 Telefonema é melhor do que e-mail.
 Presença física é melhor do que remota.
 Utiliza a comunicação com as respostas mais rápidas possíveis.
Simplicidade:
 Incentivo a práticas que reduzam a complexidade do sistema.
 Solução deve ser sempre a mais simples para se alcançar os objetivos

esperados:
‒ Tecnologias, design, algoritmos e técnicas mais simples.
 Design, processo e código podem ser simplificados a qualquer momento.
 Não pensar em iterações futuras.

Feedback:
 Feedback sobre qualidade do código.
 Testes de unidade, programação em pares e posse coletiva.
 Feedback sobre estado do desenvolvimento.
 estórias do usuário final, integração contínua e jogo do planejamento.
 Permite maior agilidade.
 Erros detectados e corrigidos imediatamente.
 Requisitos e prazos reavaliados mais cedo.
 Permite estimativas mais precisas
 Maior segurança e menos riscos para investidores.
Coragem:
Práticas do XP aumentam a confiança do programador para:
 Melhorar o design de código que está funcionando para torná-lo mais simples.
 Jogar fora o código desnecessário.
 Investir tempo no desenvolvimento de testes.
 Mexer no design em estágio avançado do projeto.
 Pedir ajudar aos que sabem mais.
 Dizer ao cliente que um requisito não vai ser implementado no prazo

prometido.
 Abandonar processos formais e fazer design e documentação em forma de

código.

As principais práticas de codificação definidas pelo XP são:
 Revisão permanente do código.
 Testes automatizados e frequentes.
 Participação do usuário final.
 Refatoramento contínuo.
 Integração contínua.
 Planejamento, design e redesign a qualquer hora.

Capítulo 4. Principais ferramentas usadas para o ciclo de desenvolvimento de
software Ágil e DevOps
Á área de engenharia de software tem buscado, nas últimas décadas,

ferramentas que apoiem e acelerem a tarefa de desenvolvimento de software. Um
ponto importante a ser considerado é que, no cenário atual, o software está cada vez
mais complexo e altamente integrado. Atualmente, os softwares corporativos
comumente se integram com diversas outras plataformas internas e externas de
software. Para lidar com essa complexidade, torna-se obrigatória a utilização de
ferramentas de automação e de apoio ao ganho da produtividade no planejamento,
construção do software e implantação do software.
Em 2017 (Little & Herschmann), a partir da consolidação das práticas de

Devops no mercado corporativo, o Gartner reconsiderou novamente a classificação,
chegando à conclusão que apenas uma ferramenta isolada não é suficiente para
incorporar todas as práticas do Devops. Assim, chegou-se a uma extensão da
classificação de ALM:
 Devops Toolchain: para engenharia de software, um toolchain é um conjunto

de ferramentas encadeadas cujo resultado de uma ferramenta se torna entrada
para a execução de outra ferramenta. Pela definição, não existe estritamente
a necessidade dessa execução sequencial. Como nenhuma ferramenta
consegue encadear todas as práticas, deve ser considerado em qual (is) fase
(s) do Devops é abordado por determinada ferramenta.
Algumas das ferramentas mais utilizadas para gerenciar o ciclo de vida do

software Agile e DevOps, são o Jira e o Azure DevOps. O Trello também é muito
usado, mas não possui todas as características importantes para o ciclo DevOps, a
saber:
 Create: armazenamento de repositórios de código, integração contínua e

configuração de máquinas.
 Plan: definição de tarefas, planejamento e monitoramento de tarefas com uma

visão ágil do processo.

 Monitor: monitoramento das aplicações englobando infraestrutura,
gerenciamento e análise de APIs e gerenciamento de logs.
 Configuração: configuração automática de infraestrutura (Infrastructure as

Code).
 Release: criação de pipelines de release, implantação e orquestração das

releases.
 Preprod: orquestração de ambientes de produção.
 Verify: automação de testes, análise estática de código, ambientes virtuais de

testes e práticas de DevSecOps.
Azure DevOps
O Azure Devops é um produto desenvolvido pela Microsoft para ser uma

ferramenta que atenda todo o ciclo de vida de desenvolvimento, desde o
planejamento ágil das demandas, o desenvolvimento do software e a implantação
automática. Possui integração com diversas ferramentas do mercado através de plug-
ins existentes no marketplace do Azure Devops. Alguns plug-ins são desenvolvidos
pela Microsoft e outros são fornecidos por terceiros, como o plug-in implantação de
artefatos de software gerados pelo Azure Devops e publicados na nuvem AWS. Essa
integração foi desenvolvida pela AWS e disponibilizada no marketplace do Azure
Devops (Marketplace, 2020).
Em linhas gerais, o produto inclui como principais características:
 Ferramentas ágeis cobrindo metodologias de projetos como Scrum/Kaban.
 Gestão e controle de tarefas.
 Repositórios Git/TFVC para controle de código-fonte.
 Pipelines de Build/Release para integração contínua/implantação contínua.

 Arquitetura de agentes distribuídos para build e implantação do código.
 Tarefas para implantação de qualquer tipo de plataforma de software.
 Dashboards customizáveis.
 Módulo Analtyics com geração de diversas visões dos dados integrados a

ferramenta de BI da Microsoft.
A tabela abaixo descreve as partes desta solução:
Ambiente de desenvolvimento integrado, que permite a

utilização de conceitos ágeis, integração contínua e
práticas de DevOps. Possui criação de itens de trabalho,
bugs, requisitos, tarefas etc. Possui quadros e priorização
de tarefas. Quadros e métricas ágeis (planejamento de
sprint, Kanban board etc.). Repositórios GIT ilimitados.
Azure DevOps
Integração com IDEs (Eclipse, Visual Studio, Android
(antigo Visual
Studio etc.). Integração contínua e implantação.
Studio Team
Gerenciamento de pacotes. Testes exploratórios.
Services -
VSTS)
https://azure.microsoft.com/pt-
br/services/devops/compare-features/
https://azure.microsoft.com/pt-
br/pricing/details/devops/azure-devops-services/
Ferramenta de gerenciamento de testes integrados,

incluindo planejamento, execução e monitoração dos
Test Manager
testes. Definição de critérios de aceitação e métricas de
qualidade.

https://marketplace.visualstudio.com/items?
itemName=ms.vss-testmanager-web
Solução de chat e reuniões on-line com recursos para

hospedar áudio, vídeo e webconferências, e conversar
Microsoft com qualquer pessoa dentro ou fora da organização.
Teams
https://products.office.com/pt-br/compare-all-microsoft-
office-products?tab=2
Wiki do Azure DevOps.

Wiki
Jira
A solução ALM Jira é da empresa Atlassian. O relatório do Gartner identificou

as seguintes observações com relação ao ALM da Atlassian:
 Adequado para projetos ágeis e tradicionais.
 Adequado para empresas que não precisam de muitas funcionalidades em

nível de portfólio.
 Existem parceiros Atlassian oficiais brasileiros, que podem fornecer suporte e

instalação das ferramentas.
 Foco em gerenciamento de tarefas, gerenciamento de defeitos e colaboração.
 Investimento pesado em integração de funcionalidades.
 Instalação on-premises ou nuvem. Algumas funcionalidades são exclusivas

para on-premises.
 Grande base de clientes.
 Simples de adotar e altamente flexível e customizável.

 Mais de 2000 addons no Marketplace oficial da Atlassian.
 Ferramentas de colaboração como Hipchat, Confluence e Trello (adquirido

pela Atlassian em 2017).
 Bom suporte ao Git e integração contínua com o uso do Bitbucket, permitem

que empresas implementem práticas do DevOps com a Atlassian.
 Licenças e política de preços pouco flexível.
 Complexo de configurar os fluxos de trabalho e relatórios nas ferramentas.
 Linguagem própria permite filtros e customizações (JIRA Query Language)
 Atualização de versão on-premises é difícil.
Esta ferramenta atende às seguintes necessidades:
 Gestão de Requisitos.
 Gestão de Testes.
 Gestão de Documentos.
 Gestão de Tarefas.
 Gestão de Fatos técnicos.
 Gestão de Mudanças.
 Gestão de Configuração.
 Geração de Relatórios.
 Geração de Relatórios de Progresso.
 Gestão do Ciclo de Vida de Configuração da Ferramenta.

A tabela abaixo descreve cada uma das partes desta solução.
Viabiliza a execução e gerenciamento do projeto utilizando

de metodologia Ágil (Scrum ou Kanban). Onde o gestor ou
chefe de desenvolvimento pode criar e acompanhar, em
forma de mapa, o andamento das atividades da equipe.
Permite que a equipe faça envio do código para o software
Atlassian Jira
de versionamento Atlassian Bitbucket, além de manter a
Software (Server
equipe sincronizada com as atividades de cada um.
License).
Ademais, o gestor pode marcar as atividades que tem
interesse em monitorar o andamento e receber e-mails sobre
mudanças do estado do mapa, quando é alterado alguma
atividade que está ocorrendo concomitantemente no projeto.
https://br.atlassian.com/software/jira/pricing
Software que mantém toda base de conhecimento e

documentação dos projetos, ou de atividades do suporte
Atlassian
técnico das equipes, em um único local de fácil localização
Confluence
e atualização, integrado com todas as ferramentas da
(Server License).
Atlassian.
https://br.atlassian.com/software/confluence/pricing
Software para controle de versionamento local, totalmente

integrado com os projetos de desenvolvimento no Atlassian
Jira, onde podemos comentar dentro do código fonte
Atlassian informando sobre alguma mudança ou melhoramento,
Bitbucket (Server acompanhamento do gestor sobre novos envios de código
License). para o repositório do projeto e visualização do andamento da
equipe de desenvolvimento. Mudanças no código são
notificadas em tempo real por e-mail para o gestor do projeto
e da equipe.

https://br.atlassian.com/software/bitbucket/pricing?tab=clou
d
Controla a construção dos softwares, além de manter a

integridade dele, garantindo à equipe de desenvolvimento
que o software está disponível para execução e que todas
as funcionalidades deles estão dentro da normalidade. O
Atlassian Bamboo Bamboo é integrado com o sistema de controle de chamadas
(Server License). Atlassian Jira e com o envio de código comentado, além de
estar de acordo com a plataforma de teste de construção da
aplicação.
https://br.atlassian.com/software/bamboo/pricing
Autentica em um único ponto todos os softwares

relacionados acima, ademais, podemos melhorar a
administração e centralizar todas as aplicações atuais em
Atlassian Crowd um único ponto e utilizando o sistema de autenticação de
(Server License). usuários atual, além de possuir um melhor controle das
permissões de todos os usuários.
https://www.atlassian.com/software/crowd/pricing
Mantém toda a equipe informada e atualizada do estado do

Projeto, de mudanças de escopo ou planejamento, e ajuda
a prever com precisão qualquer alteração no ambiente de
Atlassian Jira
Portfólio (Server trabalho da equipe. Geralmente esses ambientes mudam
constantemente e, por meio de um poderoso agendador de
License).
recursos, podemos adaptar a equipe para novas mudanças.
https://www.atlassian.com/software/jira/portfolio/pricing

Ferramenta de gestão de solicitações de demandas de
serviços de TI. Possui templates pré-configurados de
Atlassian Jira processos aos processos de gestão de serviços de TI.
Service Desk
Integrado ao Jira Software.
https://br.atlassian.com/software/jira/service-desk/pricing
Alguns plugin utilizados no Jira e seus principais objetivos:
 Xray para gestão de testes.
 Confluence (parte da suíte Atlassian) para gestão de conteúdo.
 Rmsis para gestão de requisitos.
 Xporter para geração de relatórios em PDF e suíte office.
 Structure para gestão de portfólio.

Capítulo 5. Introdução ao DevOps
Nos últimos anos, o valor agregado de garantir a qualidade do produto ao

longo do ciclo de vida do projeto (as famosas atividades de remoção de defeitos) é
primordial para o alcance da qualidade e da redução de desperdícios, necessária para
entregar nossas features ou releases no tempo adequado ao negócio.
Muitas organizações pensam que a qualidade tem custo alto e bloqueia a

entrega para o cliente. Estes discursos podem ser rebatidos de diversas formas, mas
os principais são: “O custo do retrabalho é muito maior do que fazer certo de primeira”;
“A qualidade e revisões de código evitam que erros ocorram lá na frente, que o custo
de remoção de defeito é sempre muito maior”.
Ultimamente estamos percebendo que o mundo mudou, e como o próprio

Gartner declarou no seu último relatório, as tarefas repetitivas serão feitas por
serviços inteligentes, as empresas terão em seu quadro de funcionários os decisores
e os especialistas em algoritmos.
Só sobreviverão as empresas que souberem escolher tecnologias,

abordagens e processos que absorvam as constantes mudanças, onde a informação
parece transformar a cada segundo e um erro pode se transformar em negócios e
milhões perdidos.
Como então conseguimos alta qualidade em um prazo competitivo? O

triângulo de prazo, escopo e qualidade, tão conhecido por todos, parece fazer cada
vez mais sentido nos dias atuais. Temos que reduzir o prazo e não abrir mão da
qualidade. O que nos sobra para aumentar a qualidade do produto é priorizar o
escopo, cuidar das pessoas e automatizar o máximo possível; com o apoio de
ferramentas especializadas, as tarefas repetitivas e/ou essenciais.
Estes três pilares (Pessoas, Ferramentas e Cultura) estão no DevOps: deriva

da junção das palavras “desenvolvimento” e “operações”, como sendo uma prática de
engenharia de software que possui o intuito de unificar o desenvolvimento e a
operação de software, através da transparência e colaboração entre pessoas.

Overview de DevOps
O objetivo do DevOps, conforme a Figura 8, é tornar os processos mais

simples, integrar desenvolvedores e profissionais de infraestruturas, unir as equipes
e aumentar as entregas aos clientes, agregando velocidade e qualidade a elas.
Figura 8 – Overview do DevOps.
A harmonização das duas equipes e um conglomerado de ferramentas e

tecnologias, permitem às equipes criar uma cultura de colaboração para fugir dos
desperdícios e impedimentos, automatizando processos repetitivos.
O termo DevOps vem da junção das palavras em inglês Development e

Operations, que significam “desenvolvimento” e “operações”, respectivamente. É uma
prática de construção de softwares que buscam, portanto, unir essas duas áreas,
automatizando os processos operacionais em todas as fases da engenharia do
software.

Conforme Pressman (2011), qualquer processo de software pode ser
aplicado a agilidade, seja o processo projetado da forma que a equipe do projeto
possa adaptar tarefas e melhorar, guiar o planejamento e reduzir tudo, com exceção
do trabalho mais essencial, mantendo a simplicidade e enfatizando a estratégia da
entrega incremental.
O desafio de implementar DevOps não é somente selecionar uma tecnologia,

mas motivar o setor de tecnologia a se reinventar nos termos de mudança cultural,
mudar o mindset com apoio motivacional das equipes envolvidas, com respostas
claras e comprometimento de todos.
Como afirma Dweck (2017), mindset é uma palavra inglesa que significa
“pensamento”, “atitude mental”, “moldes mentais”. A forma de pensar, a mente, está
organizada como o pensamento se organiza e encara as situações da vivência diária.
A palavra ágil faz sentido ao que se é eficaz e rápido, diligente, trabalhador, aquele
que acha solução rápida, que consegue se resolver com facilidade.
A fim de ajudar na implantação do DevOps, existe um princípio chamado de

“O Princípio das Três Maneiras”. Vamos falar superficialmente deles apenas para
embasamento do que está por vir adiante nesta apostila. Para mais detalhes neste
assunto, sugerimos fortemente a leitura do livro Jornada Colaborativa DevOps
(MUNIZ, 2019), onde cada maneira deste princípio é abordada profundamente.
CALMS
O termo CALMS foi criado se baseando nas seguintes palavras: Colaboração,

Automação, Lean, Medição e Compartilhamento. É frequentemente usado para
realização de uma análise da organização e, em paralelo, sua utilização em diversas
aplicações. A estrutura do CALMS abrange todas as partes interessadas no DevOps,
incluindo negócios, operações, qualidade, segurança, equipes de desenvolvimento
etc., e coletivamente realizam a entrega, implantação e integração dos processos
automatizados que fazem sentido para os clientes.

Segundo o livro Jornada Devops, o acrônimo CALMS é muito conhecido para
representar a cultura DevOps. Foi criado em 2010 como CAMS por John Willis e
Damon Edwards. Posteriormente, esse termo foi aperfeiçoado por Jez Humble, com
a inclusão do L para destacar a importância do Lean para melhoria contínua e
processos enxutos.
Como será que devemos aplicar CALMS nas organizações? Existem algumas
maneiras aos quais o CALMS pode ser aplicado ao DevOps para empresas,
pensando na melhora ou na mudança estrutural, visando a melhoria de práticas
DevOps ou até mesmo sua implantação.
 Cultura: integrando as equipes, melhorando a comunicação e relacionamento.

Sem segregação.
 Automação: automatização de processos manuais.
 Lean: produção em lotes pequenos com grande valor para o cliente.
 Medição: monitoramento, melhoria e telemetria para análise dos andamentos

dos processos.
 Sharing: boa comunicação, feedback, relacionamento entre a equipe e o

cliente.
DevOps – Primeira Maneira
A primeira maneira tem como objetivo acelerar o fluxo do Desenvolvimento

(esquerda) para Operações e Clientes (direita), como mostra a Figura 9 abaixo.

Figura 9 – Primeira Maneira.
Fonte: adaptado de (MUNIZ, 2019).
Aqui, o objetivo está na entrega rápida de valor para o cliente, levando em

consideração toda organização e não em departamentos apartados. Desde a
concepção até o valor ser entregue ao cliente. E como alcançar esse objetivo?
Através de feedback rápido. O quanto antes termos um feedback, seja negativo ou
positivo, melhor! Aqui listamos alguns princípios e práticas que ajudam a alcançar
esse objetivo, como:
 Limitar o trabalho em execução (WIP - Work in Progress):
‒ Com essa prática é possível focar no que realmente importa, garantindo

assim mais qualidade, pois o time está mais focado em uma única
tarefa/projeto, do que em diversas(os).
 Tornar o trabalho visível.
Infraestrutura como código (IaC).
 Código e configurações dentro do controle de versão.
 Criação automatizada e sob demanda (self-service) em todos os ambientes,

evitando trabalho manual.

 Todos os estágios do fluxo de valor com ambientes iguais ou semelhantes ao
de produção.
 Infraestrutura imutável: foco em recriar todo o ambiente de produção de forma

rápida, em vez de realizar alterações.
IaaS, SaaS e PaaS
 IaaS é a mais simples:
‒ Oferece infraestrutura de TI automatizada e escalonável –

armazenamento, hospedagem e redes – de seus próprios servidores
globais, cobrando apenas pelo o que o usuário consome.
‒ Não precisa adquirir licença de software ou servidores e alocar recursos

conforme a necessidade.
‒ Dominado pela Amazon (AWS – 38% do mercado), Microsoft (18%),

Google (9%) e Alibaba (6%).
 PaaS é mais difícil de ser definido:
‒ Oferece os conceitos básicos de IaaS.
‒ Além disso, oferecem ferramentas e recursos para desenvolver e

gerenciar aplicativos com segurança, sem precisar se preocupar com a
infraestrutura: Sistema Operacional, Compilação testes.
‒ Exemplo: Os servidores que hospedam sites são exemplos de PaaS.
‒ A solução Azure para desenvolvimento de software: Azure DevOps +

Azure Services.
 SaaS é mais fácil:

‒ O Software como Serviço (SaaS) é o local onde um software é
hospedado por terceiros e pode ser acessado pela web, geralmente
bastando um login.
‒ Plano de assinatura e utiliza os programas necessários para os

negócios.
‒ É interessante para o uso de aplicativos específicos.
Apps/aplicativos Ferramentas de Sistemas Servidores e Segurança Construção/planta

hospedados desenvolvimento, operacionais armazenamento /firewalls física do datacenter
gerenciamento de de rede
banco de dados,
análise de negócios
Fonte: https://azure.microsoft.com/.
Vantagens do PaaS
 Ao fornecer infraestrutura como serviço, PaaS oferece as mesmas vantagens

que o IaaS. Seus recursos adicionais – middleware, ferramentas de
desenvolvimento e outras ferramentas de negócios – dão ainda mais
vantagens.
 Reduza o tempo de codificação. As ferramentas de desenvolvimento PaaS

podem reduzir o tempo levado para codificar novos aplicativos com
componentes de aplicativos pré-codificados inseridos na plataforma, como
fluxo de trabalho, serviços de diretório, recursos de segurança, pesquisa etc.

 Adicione funcionalidades de desenvolvimento sem adicionar
funcionários. Componentes da Plataforma como Serviço dão à sua equipe de
desenvolvimento novas funcionalidades sem precisar adicionar funcionários
com as habilidades necessárias.
 Desenvolvimento simplificado para diversas plataformas, incluindo

móveis. Alguns provedores fornecem opções de desenvolvimento para
diversas plataformas, como computadores, dispositivos móveis e
navegadores, tornando aplicativos de plataforma cruzada mais rápidos e fáceis
de serem desenvolvidos.
 Use ferramentas sofisticadas de forma acessível. Um modelo pago conforme

o uso, permite que pessoas ou organizações usem software de
desenvolvimento sofisticado e ferramentas de análise e business intelligence
que não poderiam comprar por completo.
 Suporte a equipes de desenvolvimento distribuído geograficamente. Como o

ambiente de desenvolvimento é acessado pela Internet, equipes de
desenvolvimento podem trabalhar em conjunto em problemas, mesmo quando
os membros da equipe estiverem em locais remotos.
 Gerencie com eficácia o ciclo de vida do aplicativo. PaaS fornece todas as

funcionalidades que você precisa para dar suporte ao ciclo de vida
completo do aplicativo Web: compilação, teste, implantação, gerenciamento e
atualização, no mesmo ambiente integrado.
Serverless
 Ainda existem servidores apesar do nome. 
 O desenvolvedor não se preocupa em configurar os outros aspectos de infra

onde a sua aplicação vai rodar.
 Podem ser divididos em: Backend as a Service (BaaS) e Function as a Service

(FaaS).

 Você paga pelo uso (cada vez que a função é executada).
 Frameworks Serverless.
Os principais frameworks do mercado são:
1) Serverless é um framework web e open-source – Node.js.
‒ Incialmente era destinado exclusivamente para a criação de aplicações

para o AWS Lambda, a plataforma da Amazon Web Services de
serverless cloud computing.
‒ Agora está compatibilizado com outros fornecedores de Cloud:

Microsoft Azure, IBM BlueMix, Google Cloud, Oracle Cloud, entre
outros.
‒ Cuidado: ao usar não se esqueça de que é diferente de um

desenvolvimento para Cloud Tradicional.
2) Up também é um framework open source.
‒ Não tem funcionalidades.
‒ Adapta seu código para rodar na arquitetura serverless.
‒ Cuidado: seu código não poderá utilizar as funcionalidades especiais

dos provedores serverless.
Quando você está usando FaaS, compartilha o tempo de execução com

outras pessoas. Por exemplo: quando sua “função” é escrita em JavaScript, esta parte
do código será executada no mesmo servidor node.js que as “funções” de outros
usuários deste FaaS (isso pode ser diferente para alguns fornecedores). Ao usar o
BaaS, você compartilha o mesmo BaaS.

Fonte: https://specify.io/concepts/serverless-baas-faas.

Fonte: Livro Jornada DevOps (MUNIZ et al., 2019).
Devemos priorizar os testes unitários por terem a execução mais rápida do

que os testes de aceite e integração. Além de economizar tempo, outro grande
benefício é que os desenvolvedores recebem feedback de imediato no teste unitário
e fica mais eficiente a correção na origem.
Estratégia de Branching

Categorias de liberação (Release)
É importante que o time planeje a release ou a implantação de um pacote, e

defina, junto com a operação, formas de reversão do deploy em caso de algum
problema detectado. Alguns exemplos de reversão são: release canário (implantar a
versão anterior) ou alternância de recursos/feature toggle (incluir na aplicação uma
função de ligar/desligar a funcionalidade sem precisar voltar a versão anterior à
implantação). Em caso de maturidade em testes automatizados com alta cobertura, é
possível seguir com o Fix Forward, consertar o código imediatamente e implantar
seguindo as regras da pipeline para entrega contínua.
Podem ser de duas formas:
 Baseado no Ambiente:
Há dois ou mais ambientes e apenas um fica ativo para os clientes (Ex.:

balanceadores) - Azul verde (Blue-green) e Canário (Canary).
Figura 10 – Release Azul Verde e Canário.

 Baseado no aplicativo:
‒ Novas funcionalidades de forma seletiva, usando configurações simples

(não precisa fazer deploy).
‒ Alternância de recursos (Feature toogles) e Lançamento escuro.
Alternância de Recursos:
 Habilita e desabilita recursos da aplicação de acordo com critérios definidos

(Ex.: funcionário, localidade).
 Usa instrução condicional através de parâmetro ou configuração, sem

necessidade de deploy.
 Permite o lançamento escuro:
‒ Implantação de recursos na produção, para avaliar resultados sem

usuário perceber.

Arquitetura de baixo risco
Figura 11 – Vantagens e desvantagens de cada tipo de arquitetura.
DevOps - Segunda Maneira
Como mostra na Figura 12 abaixo, a segunda maneira tem como objetivo o

rápido feedback em todos os estágios do fluxo de um produto. Quanto mais rápido o
feedback, mais rápido sabemos se acertamos e erramos, e mais rápido ainda
podemos ajustar problemas e erros. Trazer o conhecimento e o aprendizado de
segurança, desenvolvimento da operação e qualidade encontrado por telemetria,
experiência do cliente, criação de ambiente de forma automatizada e rápida, vão ser
insumos fundamentais para que o fluxo seja cada vez mais contínuo e automatizado.

Figura 12 – Segunda Maneira.
Aqui listamos e detalhamos um pouco mais, alguns princípios e práticas que

ajudam alcançar esse objetivo, como:
 Telemetria: a telemetria se apoia principalmente na análise do risco de

liberação de versões com o feedback de eventos, métricas e registros em toda
a cadeia do fluxo. Monitoramento proativo, onde são detectadas
vulnerabilidades em diversos ambientes como feedback para o
desenvolvimento. É importante que tenhamos o conceito telemetria self-
service, ou seja, indicadores disponíveis para todos os envolvidos no fluxo:
democratizando este tipo de feedback. O framework de monitoramento possui
métricas de diversos tipos: aplicativo, atividades de negócio e sistema
operacional.
 Visão clara do fluxo e o trabalho diário de desenvolvedores e operação, juntos,

todos são responsáveis pela melhoria contínua e condução proativa de
verificações.
 Gemba: ir e ver com os seus próprios olhos o que está acontecendo para
propor melhorias e/ou ajustes. Por exemplo: se o problema é na utilização do
aplicativo do cliente, gere empatia e vá até o cliente para entender qual é a
dificuldade real.

 Corda de Andon: sempre que um problema é detectado ao longo do fluxo,
todos se juntam para resolver o problema.
 Plantão 24x7 compartilhado: mesmo que tenhamos uma boa cobertura de

testes automatizados, isso não garante zero erros em produção. Mesmo que
vejamos somente a sustentação envolvida quando acontece a implantação em
produção, é importante que todos os participantes do fluxo de valor
compartilhem as responsabilidades para resolver os incidentes em produção.
Esta prática gera empatia e aprendizado.
 Listas de revisão de segurança (SRE Google): uma prática bastante popular e

implementada pela Google e o papel do SRE é o seu checklist de revisão de
segurança (LRR: Launch Readiness Review e o HRR: Handoff Readiness
Review), onde se avalia a prontidão de um software que foi implantado em
produção, para ser direcionada à equipe de sustentação/manutenção.
 Testes A/B: os testes A/B podem ser aplicados através de formulários,

pesquisas, entrevistas ou qualquer outro meio que permita coletar os dados de
feedback do cliente sobre uma funcionalidade ou futura funcionalidade de um
aplicativo. O Teste A/B é bastante útil quando desejamos experimentar novos
recursos e tomar decisões com base em fatos e dados.
 Desenvolvimento por hipóteses: o uso de hipóteses é bastante importante para

confirmar se novas funcionalidades serão realmente adotadas pelos clientes.
 Revisão de código: uma das formas mais comuns de revisão de código é o Pull
Request, onde o desenvolvedor solicita revisão de forma colaborativa após
concluir mudança no código, esse processo é muito usado no GitHub.

DevOps - Terceira Maneira
A terceira maneira tem como objetivo principal criar uma cultura de confiança
para que seja possível errar e aprender com os erros. É importante correr riscos para
potencializar um aprendizado contínuo. A terceira maneira é fundamental para que a
cultura DevOps esteja presente e sempre acesa nos times. Sem ela, a cultura de
automação e colaboração vai se enfraquecendo ao longo do tempo. Temos que nos
habituar e, consequentemente, habituar os times em que trabalhamos a melhorar
continuamente até a perfeição. Como a perfeição não existe, a melhoria contínua não
terá fim.
Figura 13 – Terceira Maneira.
Conforme figura acima, alguns dos principais princípios e práticas da terceira

maneira são:
 Aprendizado com falhas: o foco é desenvolver aprendizado contínuo nas

equipes e evitar a cultura de culpa e punição. A Netflix criou um processo de
injeção de falhas chamado Chaos Monkey, que aumenta a resiliência (MUNIZ,
2019).
 Cultura justa: existem algumas importantes dicas para promover esta cultura
justa, são elas: nunca nomear ou envergonhar quem é o culpado da falha;

incentivar quem compartilha problemas do sistema; criar confiança para que a
equipe aprenda com problemas; lições aprendidas sem culpa e injeção
controlada de falhas em produção.
 Reunião post-mortem: após a solução de incidentes, o objetivo é entender e

divulgar ações que deram certo, ações que podem ser aprimoradas, erros e
medidas para evitar recorrência. É muito importante publicar e divulgar o
resultado da reunião.
 Dias de Jogos: esse conceito vem da engenharia da resiliência, cujo objetivo

é criar exercícios programados para aumentar a resiliência através da injeção
de falhas de grande escala em sistemas críticos.
 Divulgar e compartilhar aprendizados (descobertas) entre os times: empresas

de alto desempenho obtém os mesmos resultados (ou melhores), refinando as
operações diárias, introduzindo tensão continuamente para aumentar o
desempenho e, assim, gerando mais resiliência nos seus sistemas.
Motivação
Segundo o Livro Jornada Ágil e Digital (MUNIZ; IRIGOYEN, 2020), em 1970,

Paul McLean (1990), psiquiatra e neurocientista americano, apresentou uma teoria
chamada: Teoria do Cérebro Trino, que mostra pela primeira vez nosso cérebro como
uma estrutura dividida em 3 (três) partes distintas: Neocórtex, Sistema Límbico e
Cérebro Reptiliano (Figura 14).

Figura 14 – Representação do Cérebro Trino.
Fonte: Livro Jornada Ágil e Digital (MUNIZ; IRIGOYEN, 2019).
O sistema Neocórtex tem como principal responsabilidade o raciocínio lógico

e, por isso, somos capazes de ler, escrever e nos comunicar.
O sistema límbico, que é conhecido como cérebro emocional, é o responsável

por nossas emoções, pelo aprendizado, pela memória e pelo nosso comportamento
social.
Como é possível observar pela figura, o nosso sistema reptiliano é o primeiro

a agir, é o nosso instinto, quando estamos em alguma situação de perigo ou sob
pressão, nossa primeira reação é a defensiva: agir sem pensar somente para nos
defender.
Isso significa que, pela nossa natureza humana e por primeira reação:
 Somos, por natureza, avessos às mudanças.
 Aprendizado gera desconforto no início, sair da zona de conforto é sempre um

desafio.
 O seu cérebro vai criar mil razões para impedi-lo de mudar os hábitos.

 A sensação de prazer ao conseguir melhorar, com fatos e dados, não tem
preço: pare, reflita e mude; use mais o límbico e o néocortex para “treinar” o
cérebro a aprender.
A importância da Terceira Maneira
Para que seja possível criar aprendizado e implantar o loop de feedback

contínuo, as práticas da Terceira Maneira são imprescindíveis para a manutenção da
colaboração e da automação. Sem tempo para melhoria contínua e aprendizado, os
times acabam não evoluindo na primeira e na segunda maneira.
Para que este aprendizado seja possível, precisamos correr riscos, ter uma
cultura justa e buscar fatos e dados para tomar qualquer tipo de decisão.
Para que possamos correr riscos, aprender e não ativar nosso lado
“reptiliano”, precisamos de segurança psicológica. Conforme ilustrado na Figura 15,
para que o aprendizado aconteça, segurança psicológica e responsabilidades
precisam andar juntos.
Figura 15 – Aprendizado x Segurança Psicológica.
Fonte: https://www.youtube.com/watch?v=LhoLuui9gX8: e Building a psychologically

safe workplace | Amy Edmondson | TEDxHGSE.

Segundo Muniz e Irigoyen, no Livro Jornada Ágil e Digital (2020), os
indivíduos podem estar inseridos em quatro zonas:
 Zona de Conforto: o funcionário está com o nível de Segurança Psicológica

excelente, porém sua motivação e responsabilidade deixam a desejar, o
tornando assim um trabalhador raso.
 Zona de Apatia: os níveis de segurança psicológica estão baixos, a

responsabilidade e motivação estão aquém do desejável, tornando assim o
indivíduo triste, desmotivado e sem ânimo para inovar e desenvolver suas
atividades.
 Zona de Ansiedade: o indivíduo possui bastante motivação e

responsabilidade, quer inovar e implantar novas práticas. No entanto, a
segurança psicológica do ambiente de trabalho dele é bastante negativa,
tornando o funcionário ansioso e sem força para realizar tudo o que realmente
deseja.
 Zona de Aprendizado: é considerada o melhor cenário, visto que o indivíduo

se sente seguro, feliz, capaz de inovar. Consegue arriscar sabendo que caso
aconteça qualquer problema ele não será criticado, humilhado e ridicularizado
no seu ambiente de trabalho, porque as falhas serão vistas como
oportunidades de aprendizado e assim desenvolver cada vez mais o seu
trabalho.
Antes de iniciar a implementação das práticas da terceira maneira, se

assegure que a organização em que você trabalha tenha um ambiente propício para
a aprendizagem.
A Terceira Maneira e o Profissional DevOps do tipo T-shaped
Além da Terceira Maneira impulsionar as organizações a terem ambientes

seguros e uma cultura justa, essas práticas permitem que o profissional DevOps
envolvido nelas, se tornem profissionais do tipo “T-Shaped”.

Andy Boynton e William Bole destacaram, em artigo da Forbes em 2011, que
não há nada de errado em ser um profissional em forma de I, desde que você também
possa ser um T em algum sentido significativo. A maioria dos profissionais tem uma
área de especialização, porém é mais provável que enriqueçam suas ideias se
tiverem um pé fora de seu mundo habitual.
Como é esperado atualmente que os profissionais tenham

pensamento disruptivo e foco em experimentação e adaptação, a
jornada Ágil e Digital depende de profissionais generalistas, que
estejam dispostos a pensar e agir fora de seus próprios silos com
conhecimento profundo e habilidades ampliadas. (MUNIZ, 2019).
As práticas de aprendizagem multidisciplinares da terceira maneira tornam

cada vez mais o profissional DevOps especialista-generalista. Conhecendo e tendo
experiência em diversas áreas e se especializando nas áreas onde se identificam
mais.
Alvin Toffler, em uma das suas frases mais conhecidas, diz que “os
analfabetos do futuro não serão os que não sabem ler ou escrever, mas os que não
sabem aprender, desaprender e reaprender”. Não é difícil entender que criar uma
cultura de experimentação e aprendizado é imprescindível para qualquer empresa.

Uma das formas de estimular este aprendizado é utilizando os erros que
ocorrem de uma forma mais frequente, para gerar um aprendizado e ter uma cultura
livre de culpa, multiplicando conhecimentos e aprendizados continuamente.
Todas estas formas serão detalhadas nos próximos capítulos: Exército de

Macacos Símios, Reunião post-mortem, Dias de Jogos e Descobertas.
Conceitos da Arquitetura Lean
Conforme Caroli (2019) a Engenharia Lean aborda cinco principais

conceitos:
 Arquitetura Mínima Viável.
 Implantação contínua.
 Iteração 0 (zero).
 Squad de produto.
 As três maneiras.
Os conceitos já existentes na engenharia de software e no DevOps são

consolidados neste mapa mental criado pelos autores.

Figura 16 – Engenharia Lean.
Fonte: mapa mental dos autores Paulo Caroli e Alexandre Barbosa (2019).
Mais detalhadamente o primeiro conceito de Arquitetura Mínima Viável

engloba conceitos importantes descritos por Martin Fowler, em Sacrificial Architecture

Referências
KIM, Gene et al. The DevOps Handbook: how to create world-class agility, reliability,
and security in technology organizations.Portland: IT Revolution Press, 2016.
DWECK, C. S. Mindset: the new psychology of success. Londres: Robinson, 2017.
PRESSMAN, R. S. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill, 2011.
MUNIZ, Antonio et al. Jornada DevOps. Editora Brasport, 2019.
MUNIZ, Antonio; IRIGOYEN, Analia. Jornada Ágil e Digital. Editora Brasport, 2019.
EDMONDSON, Amy C. Strategies for Learning from Failure. Harvard Business

Review, 2011.
EDMONDSON, Amy C. The Competitive Imperative of Learning. Harvard Business

Review, 2008.
PRESSMAN, R. Engenharia de Software – Uma abordagem profissional, 7. ed.

Artmed.
SOMMERVILLE, I. Engenharia de Software. 6. ed. Edição Pearson, 2007.
BOEG, Jesper. Kanban em 10 passos: otimizando o fluxo de trabalho em sistemas

de entrega de software. InfoQ Brasil.
FOGGETTI, Cristiano. Gestão Ágil de Projetos. São Paulo: Education do Brasil, 2014.
SCHWABER, Ken; SUTHERLAND, Jeff. Scrum Guide. 2017.
BECK, Kent. Extreme Programming Explained: embrace change. Upper Saddle River:
Addison-Wesley Professional, 1999.
BECK, Kent; FOWLER, Martin. Planning extreme programming. Upper Saddle River:
Addison-Wesley Professional, 2000.
JEFFRIES, Ron; ANDERSON, Ann; HENDRICKSON, Chet. Extreme programming

installed. Upper Saddle River: Addison-Wesley Professional, 2000.
TELES, Vinícius Manhães. Extreme Programming: aprenda como encantar seus
usuários desenvolvendo software com agilidade e alta qualidade. São Paulo: Novatec,
2004.
TELES, Vinícius Manhães. Um Estudo de Caso da Adoção das Práticas e Valores
do Extreme Programming. Rio de Janeiro: UFRJ/IM. Dissertação (Mestrado em
Informática), 2005.
WILDT, Daniel et al. eXtreme Programming: práticas para o dia a dia no
desenvolvimento ágil de software. São Paulo: Casa do Código, 2015.
CAROLI, Paulo, BARBOSA, Alexandre Corrêa. Lean Software Engineering: como

desenvolver seu MVP.
BARBOSA, Alexandre Corrêa; CAROLI, Paulo. Lean Software Engineering como

desenvolver seu MVP. 2020. Disponível em: <https://leanpub.com/leanengineering>.
Acesso em: 19 de nov. 2020.
IRIGOYEN, Analia. Scrum: conheça a metodologia ágil muito eficaz no

desenvolvimento de software. 2017. Disponível em:
<https://promovesolucoes.com/scrum-conheca-a-metodologia-agil-muito-eficaz-no-
desenvolvimento-de-software/>. Acesso em: 19 de nov. 2020.
Referências RUP
_ https://www.ibm.com/br/shop/trainings/
_ https://www.ibm.com/products/software
_ https://www.public.dhe.ibm.com//software/pdf/br/RUPDS.pdf

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

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

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

Enviado por

Direitos autorais:

Formatos disponíveis

Fundamentos de Engenharia de Software

Fundamentos de Engenharia de Software – Página 2 de 71

Capítulo 1. Introdução à Engenharia de Software ................................................. 6

Cenário atual do Desenvolvimento de Software ................................................. 6

Definições clássicas de Engenharia de Software:............................................... 7

Tipos de aplicações ............................................................................................ 7

Capítulo 2. Ciclos de Desenvolvimento de Software ........................................... 10

Tipos de Ciclo de Vida .......................................................................................... 10

Sequencial (Cascata) ........................................................................................ 10

Iterativo (Incremental) ....................................................................................... 11

Ciclo de Vida – RAD ......................................................................................... 12

Ciclo de vida evolutivo ...................................................................................... 12

Ciclo de vida espiral .......................................................................................... 14

RUP - Rational Unified Process ........................................................................ 15

Capítulo 3. Metodologias Ágeis ........................................................................... 18

Contexto e motivação ........................................................................................... 18

Principais mitos ..................................................................................................... 19

Manifesto ágil - Valores e princípios ágeis ............................................................ 20

Times de Scrum ................................................................................................ 24

O fluxo do Scrum .................................................................................................. 25

Os papéis e características do Kanban............................................................. 27

O fluxo do Kanban ............................................................................................ 27

Autogerenciamento e execução ........................................................................ 30

Fundamentos de Engenharia de Software – Página 3 de 71

Capítulo 4. Principais ferramentas usadas para o ciclo de desenvolvimento de

Capítulo 5. Introdução ao DevOps ...................................................................... 46

Overview de DevOps ............................................................................................ 47

DevOps – Primeira Maneira .............................................................................. 49

Infraestrutura como código (IaC)....................................................................... 50

IaaS, SaaS e PaaS ........................................................................................... 51

Vantagens do PaaS .......................................................................................... 52

Estratégia de Branching .................................................................................... 56

Categorias de liberação (Release) .................................................................... 57

Arquitetura de baixo risco ................................................................................. 59

DevOps - Segunda Maneira.................................................................................. 59

DevOps - Terceira Maneira ................................................................................... 62

Fundamentos de Engenharia de Software – Página 4 de 71

A Terceira Maneira e o Profissional DevOps do tipo T-shaped ............................ 66

Conceitos da Arquitetura Lean.............................................................................. 68

Fundamentos de Engenharia de Software – Página 5 de 71

A grande reflexão que fazemos quando pensamos em desenvolvimento de

Segundo o dicionário Aurélio, Engenharia de Software é:

“Arte de aplicar conhecimentos científicos e empíricos e certas

Atualmente o termo Engenharia de Software é mais comumente usado para

 Modelos de ciclo de vida.

 Técnicas para estimativa de custos.

 Técnicas para controle da qualidade.

Entretanto, o desenvolvimento de software é um problema de Engenharia.

‒ A criação de soluções econômicas para problemas práticos.

‒ Construir objetos a serviço da sociedade.

Cenário atual do Desenvolvimento de Software

Temos um cenário de desenvolvimento de software na maioria das

Fundamentos de Engenharia de Software – Página 6 de 71

 Cliente acha que em uma única reunião de 30 min já somos capazes de

 Desenvolvedores são orientados à solução: desejam começar logo a

Definições clássicas de Engenharia de Software:

Pela IEEE Glossary of Software Terminology, enfoque sistemático para o

Por Barry Boehm, “aplicação prática do conhecimento científico no projeto e

Por Fritz Bauer, “criação é a utilização de sólidos princípios de engenharia, a

Os seguintes tipos de aplicações são os mais comuns na Engenharia de

 Software que serve a outro software, hardware, processos, pessoas etc.

 Windows, Linux, Ios, Android e MACos.

Fundamentos de Engenharia de Software – Página 7 de 71