Apostila Módulo 1 Bootcamp Engenheiro de Software Ágil

Prévia do material em texto

Fundamentos de Engenharia de Software 
 
 
 
 
Analia Irigoyen 
 
 
 
 
 
2020 
 
 
Fundamentos de Engenharia de Software – Página 2 de 71 
 
 
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 3 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 
 
 
Fundamentos de Engenharia de Software – Página 4 de 71 
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 
 
 
Fundamentos de Engenharia de Software – Página 5 de 71 
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 
 
 
 
 
 
Fundamentos de Engenharia de Software – Página 6 de 71 
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: 
 
 
Fundamentos de Engenharia de Software – Página 7 de 71 
 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 logoa 
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. 
 
 
 
Fundamentos de Engenharia de Software – Página 8 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 9 de 71 
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. 
 
 
 
 
Fundamentos de Engenharia de Software – Página 10 de 71 
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: 
 
 
Fundamentos de Engenharia de Software – Página 11 de 71 
 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). 
 
 
Fundamentos de Engenharia de Software – Página 12 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 13 de 71 
 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 
 
 
Fundamentos de Engenharia de Software – Página 14 de71 
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. 
 
 
 
Fundamentos de Engenharia de Software – Página 15 de 71 
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: 
 
 
Fundamentos de Engenharia de Software – Página 16 de 71 
 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: 
 
 
 
 
Fundamentos de Engenharia de Software – Página 17 de 71 
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. 
 
 
 
Fundamentos de Engenharia de Software – Página 18 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 19 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 20 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 21 de 71 
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 tardiasdo 
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. 
 
 
Fundamentos de Engenharia de Software – Página 22 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 23 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 24 de 71 
 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 
 
 
Fundamentos de Engenharia de Software – Página 25 de 71 
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 tarefase 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 
 
 
Fundamentos de Engenharia de Software – Página 26 de 71 
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, 
 
 
Fundamentos de Engenharia de Software – Página 27 de 71 
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. 
 
 
 
 
 
Fundamentos de Engenharia de Software – Página 28 de 71 
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. 
 
 
 
 
Fundamentos de Engenharia de Software – Página 29 de 71 
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. 
 
 
 
Fundamentos de Engenharia de Software – Página 30 de 71 
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?”, ”É 
 
 
Fundamentos de Engenharia de Software – Página 31 de 71 
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. 
 
 
 
Fundamentos de Engenharia de Software – Página 32 de 71 
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. 
 
 
 
Fundamentos de Engenharia de Software – Página 33 de 71 
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. 
 
 
https://agilewheel.com/tag/scrumban
 
 
Fundamentos de Engenharia de Software – Página 34 de 71 
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 
 
 
Fundamentos de Engenharia de Software – Página 35 de 71 
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. 
 
 
 
Fundamentos de Engenharia de Software – Página 36 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 37 de 71 
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. 
 
 
 
 
 
 
Fundamentos de Engenharia de Software – Página 38 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 39 de 71 
 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. 
 
 
Fundamentos de Engenharia de Software – Página 40 de 71 
 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: 
Azure DevOps 
(antigo Visual 
Studio Team 
Services - 
VSTS) 
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. 
Integração com IDEs (Eclipse, Visual Studio, Android 
Studio etc.). Integração contínua e implantação. 
Gerenciamento de pacotes. Testes exploratórios. 
 
https://azure.microsoft.com/pt-
br/services/devops/compare-features/ 
https://azure.microsoft.com/pt-
br/pricing/details/devops/azure-devops-services/ 
Test Manager 
Ferramenta de gerenciamento de testes integrados, 
incluindo planejamento, execução e monitoração dos 
testes. Definição de critérios de aceitação e métricas de 
qualidade. 
https://azure.microsoft.com/pt-br/services/devops/compare-features/
https://azure.microsoft.com/pt-br/services/devops/compare-features/
https://azure.microsoft.com/pt-br/pricing/details/devops/azure-devops-services/
https://azure.microsoft.com/pt-br/pricing/details/devops/azure-devops-services/
 
 
Fundamentos de Engenharia de Software – Página 41 de 71 
https://marketplace.visualstudio.com/items? 
itemName=ms.vss-testmanager-web 
Microsoft 
Teams 
Solução de chat e reuniões on-line com recursos para 
hospedar áudio, vídeo e webconferências, e conversar 
com qualquer pessoa dentro ou fora da organização. 
https://products.office.com/pt-br/compare-all-microsoft-
office-products?tab=2 
Wiki 
Wiki do Azure DevOps. 
 
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. 
https://marketplace.visualstudio.com/items?%20itemName=ms.vss-testmanager-web
https://marketplace.visualstudio.com/items?%20itemName=ms.vss-testmanager-web
https://products.office.com/pt-br/compare-all-microsoft-office-products?tab=2
https://products.office.com/pt-br/compare-all-microsoft-office-products?tab=2
 
 
Fundamentos de Engenharia de Software – Página 42 de 71 
 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. 
 
 
 
Fundamentos de Engenharia de Software – Página 43 de 71 
A tabela abaixo descreve cada uma das partes desta solução. 
Atlassian Jira 
Software (Server 
License). 
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 
de versionamento Atlassian Bitbucket, além de manter a 
equipe sincronizada com as atividades de cada um. 
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 
Atlassian 
Confluence 
(Server License). 
Software que mantém toda base de conhecimento e 
documentação dos projetos, ou de atividades do suporte 
técnico das equipes, em um único local de fácil localização 
e atualização, integrado com todas as ferramentas da 
Atlassian. 
https://br.atlassian.com/software/confluence/pricing 
Atlassian 
Bitbucket (Server 
License). 
Software para controle de versionamento local, totalmente 
integrado com os projetos de desenvolvimento no Atlassian 
Jira, onde podemos comentar dentro do código fonte 
informando sobre alguma mudança ou melhoramento, 
acompanhamento do gestor sobre novos envios de código 
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/jira/pricing
https://br.atlassian.com/software/confluence/pricing
 
 
Fundamentos de Engenharia de Software – Página 44 de 71 
https://br.atlassian.com/software/bitbucket/pricing?tab=clou
d 
Atlassian Bamboo 
(Server License). 
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 
Bamboo é integrado com o sistema de controle de chamadas 
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 
Atlassian Crowd 
(Server License). 
Autentica em um único ponto todos os softwares 
relacionados acima, ademais, podemos melhorar a 
administração e centralizar todas as aplicações atuais em 
um único ponto e utilizando o sistema de autenticação de 
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 
Atlassian Jira 
Portfólio (Server 
License). 
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 
trabalho da equipe. Geralmente esses ambientes mudam 
constantemente e, por meio de um poderoso agendador de 
recursos, podemos adaptar a equipe para novas mudanças. 
https://www.atlassian.com/software/jira/portfolio/pricing 
https://br.atlassian.com/software/bitbucket/pricing?tab=cloud
https://br.atlassian.com/software/bitbucket/pricing?tab=cloud
https://br.atlassian.com/software/bamboo/pricing
https://www.atlassian.com/software/crowd/pricing
https://www.atlassian.com/software/jira/portfolio/pricing
 
 
Fundamentos de Engenharia de Software – Página 45 de 71 
Atlassian Jira 
Service Desk 
Ferramenta de gestão de solicitações de demandasde 
serviços de TI. Possui templates pré-configurados de 
processos aos processos de gestão de serviços de TI. 
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. 
https://br.atlassian.com/software/jira/service-desk/pricing
 
 
Fundamentos de Engenharia de Software – Página 46 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 47 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 48 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 49 de 71 
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. 
 
 
 
 
 
 
Fundamentos de Engenharia de Software – Página 50 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 51 de 71 
 Todos os estágios do fluxo de valor com ambientes iguais ou semelhantes aode 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: 
 
 
Fundamentos de Engenharia de Software – Página 52 de 71 
‒ 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. 
 
 
 
 
 
 
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. 
Apps/aplicativos 
hospedados 
Ferramentas de 
desenvolvimento, 
gerenciamento de 
banco de dados, 
análise de negócios 
Sistemas 
operacionais 
Servidores e 
armazenamento 
Seguran
ça/firewalls de 
rede 
Construção/
planta física do 
datacenter 
Segurança
/firewalls 
de rede 
Construção/planta 
física do datacenter 
https://azure.microsoft.com/
 
 
Fundamentos de Engenharia de Software – Página 53 de 71 
 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). 
 
 
Fundamentos de Engenharia de Software – Página 54 de 71 
 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. 
 
 
Fundamentos de Engenharia de Software – Página 55 de 71 
 
 
 
Fonte: https://specify.io/concepts/serverless-baas-faas. 
 
 
https://specify.io/concepts/serverless-baas-faas
 
 
Fundamentos de Engenharia de Software – Página 56 de 71 
 
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 
 
Fonte: Livro Jornada DevOps (MUNIZ et al., 2019). 
 
 
 
Fundamentos de Engenharia de Software – Página 57 de 71 
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. 
 
 
 
Fundamentos de Engenharia de Software – Página 58 de 71 
 
Fonte: Livro Jornada DevOps (MUNIZ et al., 2019). 
 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. 
 
 
 
 
Fundamentos de Engenharia de Software – Página 59 de 71 
Arquitetura de baixo risco 
Figura 11 – Vantagens e desvantagens de cada tipo de arquitetura. 
 
Fonte: Livro Jornada DevOps (MUNIZ et al., 2019). 
 
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. 
 
 
 
Fundamentos de Engenharia de Software – Página 60 de 71 
Figura 12 – Segunda Maneira. 
 
Fonte: adaptado de (MUNIZ, 2019). 
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. 
 
 
Fundamentos de Engenharia de Software – Página 61 de 71 
 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. 
 
 
 
 
Fundamentos de Engenharia de Software – Página 62 de 71 
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. 
 
Fonte: adaptado de (MUNIZ, 2019). 
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; 
 
 
Fundamentos de Engenharia de Software – Página 63 de 71 
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). 
 
 
 
Fundamentos de Engenharia de Software – Página 64 de 71 
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. 
 
 
Fundamentos de Engenharia de Software – Página 65 de 71 
 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