curso-150060-aula-03-v1

Prévia do material em texto

Aula 03
Engenharia de Software p/ BASA
(Técnico Científico - TI) 2021 - Pré-Edital
Autores:
Diego Carvalho, Fernando
Pedrosa Lopes 
Aula 03
23 de Agosto de 2020
Curso adquirido no site www.rateiobarato.com
 
 
 
 
 
 
 
1 
121 
 
Sumário 
1 – Metodologias Ágeis ................................................................................................................... 4 
1.1 – Conceitos Básicos ................................................................................................................ 4 
1.2 – Agilidade x Velocidade ......................................................................................................... 8 
1.3 – Princípios Ágeis ................................................................................................................. 10 
1.4 – Método Ágil x Método Lean ............................................................................................... 14 
2 – Scrum..................................................................................................................................... 15 
2.1 – Conceitos Básicos .............................................................................................................. 15 
2.2 – Pilares Fundamentais......................................................................................................... 19 
2.3 – Papéis .............................................................................................................................. 22 
2.3.1 – Product Owner (PO)..................................................................................................... 23 
2.3.2 – Development Team (DT) .............................................................................................. 23 
2.3.3 – Scrum Master (SM)...................................................................................................... 24 
2.4 – Artefatos .......................................................................................................................... 27 
2.4.1 – Product Backlog .......................................................................................................... 27 
2.4.2 – Sprint Backlog ............................................................................................................. 29 
2.4.3 – Product Increment ...................................................................................................... 30 
2.5 – Eventos ............................................................................................................................ 33 
2.5.1 – Planejamento da Sprint ............................................................................................... 34 
2.5.2 – Reunião Diária ............................................................................................................ 37 
2.5.3 – Revisão da Sprint ........................................................................................................ 38 
2.5.4 – Retrospectiva da Sprint ................................................................................................ 38 
2.6 – Novidades: Scrum 2017 ..................................................................................................... 42 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
2 
121 
 
3 – Extreme Programming (XP) ...................................................................................................... 47 
3.1 – Conceitos Básicos .............................................................................................................. 47 
3.2 – Principais Práticas ............................................................................................................. 50 
3.3 – Valores Fundamentais ....................................................................................................... 52 
3.4 – Princípios Básicos .............................................................................................................. 53 
Exercícios Comentados ................................................................................................................. 55 
Lista de Exercícios ......................................................................................................................... 99 
Gabarito .................................................................................................................................... 121 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
3 
121 
 
APRESENTAÇÃO 
 
Faaaaaaaaaaaala, galera... animação que essa aula é sensacional! Vamos ver agora um novo 
paradigma de desenvolvimento de software bem interessante, muda bastante coisa em relação 
às metodologias tradicionais e adivinha... essa parada não cai na prova, essa parada despenca! 
Eu juro para você que eu teria coragem de apostar dinheiro que vai ter pelo menos uma 
questãozinha sobre esse assunto na sua prova. Então, vem na fé que vocês vão gostar :) 
 
 PROFESSOR DIEGO CARVALHO - www.instagram.com/professordiegocarvalho 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
4 
121 
 
1 – METODOLOGIAS ÁGEIS 
1.1 – Conceitos Básicos 
 
 
 
Em meados de 2001, dezessete especialistas proeminentes da área de desenvolvimento de 
software se reuniram em um resort em Utah (foto acima) para conversar, esquiar, discutir e 
encontrar um terreno comum para suas ideias sobre métodos de desenvolvimento de 
software. Essa galera pegou uma mesa, se sentaram, tomaram umas cervejas e começaram a 
desabafar sobre seus projetos de desenvolvimento de software que estavam falhando por 
diversos motivos. 
 
 
Imagem - 17 Engenheiros de Software 
 
Foi quando um deles levantou a mão e disse que usou o Modelo em Cascata e o projeto 
estourou o orçamento; o outro disse que isso também já aconteceu com ele, mas recentemente 
um projeto falhou porque estourou o prazo; aí outro se compadeceu e disse que os projetos dele 
viviam falhando porque ele não conseguia construir todo o escopo que foi pedido pelos usuários 
do sistema. E assim foi... 
 
Eles foram compartilhando suas experiências ruins com o uso das metodologias tradicionais, 
mas depois cada um desses caras foi dizendo: “para remediar isso, agora eu uso iterações”; aí o 
outro disse que não usa mais tanta documentação como antigamente; aí o outro levantou a mão 
e falou que não faz mais tanto planejamento; e assim por diante. Então, no decorrer da reunião, 
foi sendo criado um consenso entre os participantes. 
 
Foi aí que alguns acharam que era o momento de formalizar e elevar aquela reunião em um 
patamar maior. Eles decidiram escrever um documento que serviria de grito de guerra contra 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
5 
121 
 
os processos tradicionais de desenvolvimento de software que vigoravam naquela época. 
Para isso, eles pensaram: “Nós precisamos de um nome que expresse bem o significado dessa 
reunião e das nossas ideias comuns”. 
 
Na discussão, eles decidiram que a palavra “leve” não expressava tão bem o que eles queriam 
dizer e decidiram trocar pela palavra “ágil”, que captava melhor a abordagem que eles estavam 
propondo.Em um segundo momento, eles começaram a escrever um documento bem 
pequeno, bem objetivo, bem claro e que conteria as crenças, valores e princípios daqueles 
dezessete engenheiros de software. 
 
Foi então que surgiu o documento chamado Manifesto Ágil Para Desenvolvimento De 
Software, que definia bem o que era ágil, o que não era ágil e o que essas pessoas defendiam. 
Além disso, eles passaram a se autodenominar como Aliança Ágil, que era um grupo de 
pensadores independentes sobre desenvolvimento de software e muitas vezes concorrentes 
entre si, mas que concordaram em um documento chamado Manifesto Ágil. 
 
Isso se tornou uma organização sem fins lucrativos que procura promover conhecimento e 
discussões sobre os vários métodos ágeis que existem hoje em dia. A partir daí, galera... esses 
caras – que eram os líderes do movimento ágil – começaram a escrever artigos, fazer palestras e 
disseminar esse novo paradigma. Como vocês sabem, esse negócio explodiu e hoje a imensa 
maioria dos projetos de software são feitos utilizando metodologias ágeis. 
 
Bem, para aqueles que não conhecem, nós trazemos na imagem a seguir quais são os 
fundamentos do Manifesto Ágil. Vejamos... 
 
“Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando 
outros a fazê-lo. Através desse trabalho, passamos a valorizar:“ 
INDIVÍDUOS E INTERAÇÃO > PROCESSOS E FERRAMENTAS 
SOFTWARE EM FUNCIONAMENTO > DOCUMENTAÇÃO ABRANGENTE 
COLABORAÇÃO COM CLIENTE > NEGOCIAÇÃO DE CONTRATOS 
RESPONDER A MUDANÇAS > SEGUIR UM PLANO 
“Isto é, mesmo os itens da direita tendo valor, valorizamos mais os itens da esquerda“. 
 
 
Notem que a coluna da esquerda representa os anseios das metodologias ágeis, enquanto a 
coluna da direita representa o que as metodologias tradicionais costumavam vigorar! Agora 
prestem atenção: o manifesto ágil afirma que, mesmo havendo valor nos itens à direita, 
valorizam-se mais os itens à esquerda. Uma pegadinha comum de prova é dizer que os 
métodos ágeis não possuem documentação. Isso está correto? 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
6 
121 
 
Não, isso evidentemente está errado! O manifesto ágil preconiza que se valorize mais software 
em funcionamento do que documentação abrangente, logo isso não significa que não tenha 
documentação. E isso serve para os outros três fundamentos, isto é, os itens da direita tem o 
seu valor, por outro lado se valoriza mais os itens da esquerda. Tudo certo até aqui? Agora 
vamos detalhar um pouco mais... 
 
Por que valorizar mais indivíduos e suas interações do que processos e ferramentas? 
 
Porque, em última instância, quem gera produtos e serviços são os indivíduos, que possuem 
características únicas como talento e habilidade. Pessoal, programar é uma atividade humana 
e, como tal, depende de questões humanas para que obtenha sucesso. Jim Highsmith, um dos 
signatários do manifesto ágil, afirma que as habilidades, as personalidades e as peculiaridades 
de cada indivíduo são críticas para o sucesso dos projetos. 
 
Ele diz também que pessoas muitas vezes são desorganizadas e difíceis de entender, por outro 
lado elas também são inovadoras, criativas, apaixonadas, entre outros. E quanto às ferramentas 
e aos processos, professor? Galera, ambos são importantíssimos para guiar e apoiar o 
desenvolvimento, mas é a capacidade e o conhecimento dos indivíduos que ajudam a tomar 
decisões críticas no projeto. 
 
Dessa forma, basta eu ensinar um conjunto de processos para a minha equipe, assim como um 
conjunto de ferramentas para garantir que a equipe criará bons softwares? Claro que não! Uma 
equipe possui características intrínsecas à personalidade, habilidades e capacidades de cada 
um dos seus integrantes e isso deve ser considerado e valorizado na construção de um 
software. Entendido, pessoal? Seguindo... 
 
Por que valorizar mais software em funcionamento do que documentação abrangente? 
 
Porque o que gera valor para o cliente é o resultado que você entrega e, não, a documentação 
em si. Respondam-me uma pergunta: quando você compra um carro, você olha o motor, o design, 
o painel, o interior ou você sai correndo loucamente para ler o manual do carro e outras 
documentações? Imagino que vocês tenham respondido a primeira opção! Dito isso, concluímos 
que o software em funcionamento é o único indicador do que, de fato, a equipe construiu. 
 
Claro, não se exclui a necessidade de documentação, que é bastante útil para o desenvolvimento, 
mas é recomendável produzir somente a documentação necessária e suficiente para a realização 
do trabalho em si. Nada de burocratizar demais e construir trezentas páginas de 
documentação com quatrocentos diagramas diferentes para representar o software. Tudo 
certo? Eu vou repetir, porque esse assunto cai bastante em prova! 
 
No ágil, documentação é descartável? Não, ela é útil para ajudar a comunicação e a colaboração 
dos integrantes da equipe, além de melhorar a transferência de conhecimento, preservar 
informações históricas, satisfazer necessidades contratuais ou legais, entre outros. A 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
7 
121 
 
documentação é importante, sim; mas valoriza-se mais o software em funcionamento, que 
é o que de fato agrega valor ao cliente. Belê? 
 
Por que valorizar mais colaboração com o cliente do que negociação de contratos? 
 
Porque é importante o envolvimento contínuo do cliente! Aliás, desenvolvedores e clientes 
devem estar sempre lado a lado, visto que ambos possuem interesses em comum. Qual? Um 
software que agregue valor! No Modelo em Cascata, vocês devem se lembrar que o cliente até 
colaborava com a equipe no início do projeto (em geral, na fase de levantamento de requisitos), 
mas – depois disso – o cliente saía de cena e só aparecia novamente para ver o software já pronto. 
 
E pior: muitas vezes, o cliente saía insatisfeito, porque o resultado não era o que ele 
esperava. Dessa forma, o manifesto ágil afirma que você tem que valorizar mais a sua relação 
com o cliente do que ficar discutindo itens de contrato: “Isso não estava previsto no contrato”; 
“Isso não estava combinado previamente”; “Vou cobrar a mais porque você mudou tal coisa”; entre 
outros. Professor, então contratos não são importantes? Claro que são! 
 
Contratos regulam essa relação entre cliente e fornecedor, mas não se deve ser excessivamente 
rigoroso, porque isso pode acabar com a relação com seu cliente. Por falar em contrato, existem 
várias maneiras de fazer contratos de desenvolvimento ágil. Uma maneira comum é fixar o 
tempo e deixar o escopo variar. É o famoso: “Tempo Fixo e Escopo Variável”! Você fala para o 
seu cliente: “É o seguinte: eu faço tudo que você pedir desde que seja possível fazer no prazo tal”. 
 
Por que valorizar mais a resposta a mudanças do que seguir um planejamento específico? 
 
Porque, em geral, é necessário obter respostas rápidas a mudanças e seguir um 
desenvolvimento contínuo do software. Todo projeto deve balancear o planejamento com a 
mudança, dependendo do nível de incerteza do projeto. Manter-se preso a um planejamento 
ultrapassado pode ser nocivo ao andamento do projeto. Galera, nós estamos no século 21! Uma 
empresa líder de mercado pode acabar de uma hora para outra – nós vemos isso o tempo todo. 
 
Cadê o Orkut? Cadê o MSN? Cadê a Nokia? Cadê a Kodak? Cadê a BlockBuster? Todas essas 
empresas foram gigantes pouco tempo atrás e simplesmente morreram! Logo, a única certeza 
que você tem em um projeto é a instabilidade! Logo, a equipe deve estar preparada para 
mudanças no escopo, tempo, custo, tecnologia,arquitetura, no paradigma de programação, 
regulamentações, leis, regras de conformidade, entre outros. 
 
Não tem como fazer um planejando e achar que ele vai ficar fixo ali ao longo do tempo – isso é 
pensamento do século passado (se muito!). Acreditem: mudanças vão ocorrer! Planejar é bom 
demais. É tão bom que é recomendável refazer o planejamento a todo momento, de forma 
contínua e, não, fazer um planejamento estático e simplesmente segui-lo com todo rigor 
ignorando mudanças externas que venham a ocorrer. Fechou? 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
8 
121 
 
1.2 – Agilidade x Velocidade 
 
Pessoal, agora vamos falar rapidamente sobre uma 
diferença importante! Vocês sabem qual a diferença entre 
agilidade e velocidade? Antes de explicá-la no contexto de 
desenvolvimento de software, eu vou explicar como uma 
metáfora em outros dois contextos para facilitar o 
entendimento. Vamos pensar no atleta Usain Bolt! O Usain Bolt 
é um cara veloz ou um cara ágil? Bem, em comparação com seres 
humanos normais, ele é mais ágil e mais veloz que todo mundo! 
No entanto, vamos pensar só no grupo dos grandes atletas que 
disputam mundiais e olimpíadas de atletismo. Nesse contexto, 
ele é absurdamente veloz, mas menos ágil que a maioria dos 
seus concorrentes. 
 
Como é, professor? Vejam as imagens a seguir! Observem que à esquerda nós temos cerca de 
vinte metros de corrida e o Bolt é o atleta de azul. Notem também que ele está mais ou menos 
em quarto lugar na corrida. Por que? Porque agilidade é a capacidade de reagir ou responder 
adequadamente a mudanças e o Bolt sempre teve problemas de largada, uma vez que ele 
ele é mais alto e pesado que os outros. 
 
 
 
Logo, ele acaba reagindo de forma mais lenta que seus adversários quando o tiro de início da 
corrida é disparado. Vejam: todos estão parados e, ao disparar o tiro, nós temos uma mudança. 
Essa mudança faz com que o os atletas reajam e saiam da inércia. O Bolt demora mais que seus 
concorrentes a sair da inércia, uma vez que ele não responde tão bem quanto os outros a 
mudança. Nesse sentido, ele evidentemente é ágil, mas não destoa dos outros pela sua 
agilidade. 
 
Se nós tivéssemos corridas de 50 metros em vez de 100 metros, talvez ele não fosse tricampeão 
olímpico. Por outro lado, vejam o final da corrida quando ele não tem mais que reagir a 
mudanças, ele só tem que correr até o fim dos 100 metros. Ele termina muito distante do 
segundo lugar! Por que? Porque ele é um cara extremamente veloz, logo ele destoa de todos 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
9 
121 
 
os outros com muita facilidade. Entenderam que agilidade não é velocidade? É a capacidade de 
reagir a mudanças! 
 
A velocidade trata de quão rápido é possível entregar um software para o cliente. E, para isso, 
nós temos outras metodologias de desenvolvimento (Ex: Rapid Application Development (RAD) 
é capaz de desenvolver softwares em poucos meses). Utilizando outra metáfora, isso ocorre 
também quando você tem uma disputa entre um carro muito potente e pesado, e um carro 
menos potente e mais leve. 
 
É provável que o carro mais leve, mesmo sendo menos potente, tenha uma arrancada melhor 
que o carro mais potente, logo ele é mais ágil. Ele é mais rápido? Não, o carro mais potente é 
mais rápido, mas ele é mais potente! Claro, pessoal, que esses são exemplos genéricos – apenas 
para entender a ideia. Diego, e como esse conceito de agilidade pode ser utilizado no contexto de 
um desenvolvimento de software? 
 
No contexto de projetos de software, podemos imaginar: eu estou gerenciando meu projeto de 
um novo sistema e, de repente, descubro que vou ter que mudar a arquitetura do software – não 
tem problema; se eu descubro que, por conta de cortes de gastos, eu terei que reduzir o tamanho 
a minha equipe – não tem problema; se eu tiver que trocar a tecnologia utilizada porque ela se 
tornou defasada – mais uma vez, não tem problema. 
 
Pressman afirma que a agilidade pode ser aplicada a qualquer processo de software. No 
entanto, para obtê-la, é essencial que o processo de software seja projetado para que a equipe 
possa adaptar e racionalizar suas tarefas; para que a equipe possa conduzir o planejamento 
compreendendo a fluidez de uma abordagem do desenvolvimento ágil; e para que a equipe 
possa eliminar tudo, exceto os artefatos essenciais do processo. 
 
Além disso, deve enfatizar a estratégia de entrega incremental, entregando para o cliente o 
software operacional o mais rapidamente possível para o tipo de produto e ambiente 
operacional. Essa são as diretivas para que um processo de software qualquer possa ser, 
também, ágil. Métodos ágeis são ágeis porque partem do princípio de que tem que responder 
adequadamente a mudanças que venham a ocorrer durante o ciclo de vida do projeto. 
 
Eles são mais dinâmicos, adaptativos, interativos e colaborativos – eles se adaptam às 
necessidades de um projeto e às suas mudanças no decorrer do desenvolvimento; os 
métodos tradicionais são mais preditivos/prescritivos, processuais, formais, documentais e 
contratuais – eles valorizam mais o planejamento de todos os aspectos do processo de 
desenvolvimento de software como um todo. 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
10 
121 
 
1.3 – Princípios Ágeis 
 
A seguir, nós vamos conhecer quais são os princípios do Manifesto Ágil. Eles vêm 
expressamente no manifesto e vocês podem encontra-lo no site oficial: 
 
www.agilemanifesto.org 
 
NÓS SEGUIMOS ESSES PRINCÍPIOS... 
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor 
agregado. As Metodologias Tradicionais preconizavam planos detalhados do projeto; o Modelo Ágil busca se 
adaptar às necessidades dos clientes e entregar valor continuamente. 
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram 
vantagem das mudanças visando vantagem competitiva para o cliente. As Metodologias Tradicionais são 
preditivas – já vimos que esse cenário é ilusório. 
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor 
escala de tempo. As Metodologias Tradicionais realizam, em geral, uma única entrega – ao final do projeto. 
 
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. As 
Metodologias Tradicionais não valorizavam essa colaboração intensa entre clientes e desenvolvedores, como 
faz o Ágil. 
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles 
para fazer o trabalho. As Metodologias Tradicionais se apoiavam fortemente em processos e ferramentas, em 
detrimento das pessoas que, de fato, construíam o software. 
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é 
através de conversa face a face. As Metodologias Tradicionais utilizam documentos, diagramas, relatórios, 
telefonemas para promover a comunicação no projeto. 
Software funcionando é a medida primária de progresso. As Metodologias Tradicionais propunham a entrega 
de artefatos (Ex: Documentação) que, em geral, não agregavam valor algum aos clientes, como também uma 
forma de medir o progresso do projeto. 
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários 
devem ser capazesde manter um ritmo constante indefinidamente. As Metodologias Tradicionais, muitas 
vezes, patrocinavam horas-extras de forma a fazer a equipe produzir mais em menos tempo. 
Contínua atenção à excelência técnica e bom design aumenta a agilidade. As Metodologias Tradicionais 
acreditavam que, para se obter máxima velocidade e flexibilidade no desenvolvimento de software, poder-se-
ia sacrificar a qualidade deste software. 
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial. As Metodologias 
Tradicionais, algumas vezes, recorriam a implementações desnecessariamente complexas, a planejamentos 
exageradamente detalhados, entre outros1. 
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. As Metodologias 
Tradicionais geralmente precisam de um gerente de projetos responsável por organizar o trabalho da equipe 
como um todo, sendo também responsável pela tomada de decisões. 
 
1 Esse princípio parece não fazer sentido, mas é simples! Deve-se maximizar a quantidade de trabalho não realizado, ou seja, 
se determinado trabalho não é essencial, não deve ser feito - e isso tem que ser maximizado. A negação dessa frase seria: 
minimizar a quantidade de trabalho realizado. Ou seja, fazer o mínimo que resolve determinado problema. 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
11 
121 
 
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu 
comportamento de acordo. As Metodologias Tradicionais muitas vezes são engessadas, i.e., não revisitam 
frequentemente seu comportamento. 
 
Professor, metodologias ágeis são recomendadas para projetos de qualquer tamanho e 
complexidade? Segundo Sommerville: “Todos os métodos têm limites, e os métodos ágeis são 
somente adequados para alguns tipos de desenvolvimento de sistema. Na minha opinião, eles são 
mais adequados para o desenvolvimento de sistemas de pequenas e médias empresas e produtos 
para computadores pessoais”. 
 
Diego, você concorda com essa afirmação? Não, eu discordo! Acredito que ela já foi válida 
tempos atrás, mas hoje não é mais! Projetos Ágeis já são suficientemente maduros para 
serem aplicados a projetos complexos e de grande porte. Pessoal, essa é só a minha opinião! 
Não é possível saber ainda a posição das bancas caso isso seja questionado em provas de 
concurso. Legal? Vamos ver agora alguns exemplos de metodologias ágeis de desenvolvimento 
de software: 
 
METODOLOGIAS ÁGEIS 
SCRUM CRYSTAL XP 
TDD ATDD BDD 
FDD DDD MDD 
DSDM ASD KANBAN 
LEAN AUP AGILE MODELING 
OSSD SCRUMBAN BADM 
 
Agora vamos ver algumas diferenças básicas entre metodologias de desenvolvimento software 
tradicionais e metodologias ágeis: 
 
CRITÉRIO MODELOS TRADICIONAIS MODELOS ÁGEIS 
PLANEJAMENTO 
Comumente realizado em detalhe para todo 
o projeto em sua fase inicial. 
Planejamento de alto nível no início do projeto 
e os detalhes são realizados durante o projeto. 
Não é necessário possuir um planejamento 
detalhado de todo o projeto. A restrição se dá 
apenas em possuir os detalhes do trabalho para 
a próxima iteração. 
RISCOS 
Pode exigir um grande esforço e equipe para 
atuar com os riscos de todo o projeto. 
Prioriza os riscos gerais do projeto, mas foca 
principalmente nos riscos das próximas 
iterações, atuando assim em um escopo bem 
reduzido. A própria equipe atua com os riscos e 
pode obter apoio externo. 
EQUIPE 
Possui profissionais com papéis bem 
definidos, quantificada e mobilizada 
conforme o planejamento do projeto. A 
equipe executa o projeto guiado pelo 
Equipe multidisciplinar, multifuncional e auto-
organizada. Ela decide como fazer e atua de 
forma colaborativa. 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
12 
121 
 
Gerente de Projetos conforme o plano 
estabelecido. 
TEMPO DE 
ENTREGA 
É realizado conforme o plano estabelecido e 
pode durar semanas, meses ou até mesmo 
anos. 
Fixo e é conforme a definição de duração das 
iterações que comumente varia entre 1 e 4 
semanas. 
 
ACEITAÇÃO DE 
MUDANÇAS 
Gerenciamento formal de mudanças, pois 
exige alteração do planejamento já 
realizado e geralmente precisa passar por 
aprovações formais de um ou mais níveis 
hierárquicos. 
Mudanças são bem-vindas. Evita-se mudar o 
escopo da iteração em andamento, mas o 
escopo das futuras iterações podem ser 
replanejado conforme a necessidade do 
cliente. 
PREVISIBILIDADE 
Depende do intervalo de monitoramento e 
controle do projeto. Quanto mais curto, 
maior a chance de prever as ocorrências 
futuras. Quanto maior o intervalo, menor a 
chance de prever as ocorrências futuras. 
Tende a ter uma grande previsibilidade futura 
devido à constante análise e feedback através 
das oportunidades de inspeção e adaptação 
providas pelo método. 
 
RESULTADOS AO 
LONGO DO 
TEMPO 
Tende a demorar a dar resultados a curto 
prazo, pois as entregas são geralmente 
realizadas ao final do projeto. Melhores 
resultados são apresentados em projetos de 
maior duração. 
Gera resultados a curto, médio e longo prazo, 
pois atua com entregas antecipadas e de valor 
agregado e contínuo ao cliente. 
 
 
APRESENTAÇÃO 
DE 
INFORMAÇÕES 
DO PROJETO 
Geralmente de uma apresentação formal 
previamente agendada com os stakeholders 
em intervalos de tempo. As informações 
podem ser detalhadas ou não conforme a 
necessidade do público envolvido. 
Geralmente informal e utiliza radiadores de 
informação no ambiente de trabalho durante 
todo o projeto, de modo que as informações do 
projeto fiquem visíveis e transparentes a toda 
equipe e envolvidos. 
PRAZO DE 
ENTREGA 
Conforme estabelecido no planejamento do 
projeto. No caso de mudanças aprovadas, 
varia conforme os impactos das solicitações 
e podem ser traumáticas aos envolvidos 
quanto às suas expectativas. 
Conforme o tamanho da iteração e o 
planejamento das releases para as entregas 
significativas. 
 
 
DOCUMENTAÇÃO 
Detalhada desde o início do projeto. 
 
 
 
Abrangente no início e detalhada somente o 
necessário durante o projeto conforme os 
objetivos das iterações e releases. 
 
ATUAÇÃO DO 
CLIENTE 
Nas fases iniciais e nas principais validações 
do produto. 
 
 
Durante todo o projeto, o cliente faz parte da 
equipe. 
 
 
DISCUSSÕES E 
MELHORIAS 
Geralmente em prazos longos através da 
realização de reuniões após uma grande 
etapa ou grande entrega do projeto. 
Em prazos curtos, sempre ao final das 
iterações. 
 
 
 
COMANDANTE 
Gerente de Projetos. 
 
 
 
Equipe do Projeto. 
 
 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
13 
121 
 
PAPÉIS Claros e definidos. 
Conforme a confiança na equipe e ambiente 
colaborativo. 
 
 
PROCESSO 
Guiado conforme o planejamento do 
projeto e nos processos estabelecidos no 
plano. 
 
Empírico e guiado ao produto e às pessoas. 
Orientado à geração de valor e conforme 
priorização dos riscos. 
 
RESULTADO 
Melhor resultado em projetos com escopo 
muito bem definido e orientado a 
planejamento. 
Melhor resultado em projetos cujo escopo é 
dinâmico e construído durante a execução do 
projeto. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com14 
121 
 
1.4 – Método Ágil x Método Lean 
 
Galera, muitas pessoas me perguntam se Método Ágil é idêntico ao Método Lean! Apesar de 
serem conceitos semelhantes, são diferentes! O Método Lean é uma filosofia de gestão inspirada 
em práticas e resultados do Sistema Toyota e se caracteriza por uma estrutura de processos em 
que há uma tentativa de minimizar o desperdício. O Lean serve de base para o Ágil. Ele 
apresenta sete princípios... 
 
Os princípios são: (1) Eliminar desperdício: O que seria um desperdício, professor? Trabalho 
parcialmente feito (que você vai acabar tendo que terminar em algum momento); processos 
extras (como documentação pesada); funcionalidades extras (entregue valor com qualidade e 
ponto); alternação de tarefas ou multitarefas (trocar de tarefa toda hora acumula desperdícios). 
Acabou? Não, tem mais... 
 
Evitar esperas (ex: cliente não tem tempo de homologar); esforços de comunicação (equipes 
geograficamente distribuídas podem gerar problemas de gestão); defeitos (entregar um 
software cheio de bugs). Enfim... tudo isso é considerado desperdício. (2) Amplificar 
conhecimento: trata-se de priorizar a comunicação e o feedback contínuos entre equipes e 
usuários durante o desenvolvimento. 
 
(3) Fortalecer o time: criar um ambiente onde a equipe trabalhe de forma autoorganizada e 
autodirigida, evitando microgerenciamento; (4) Entregas rápidas: maximizar o ROI (Return 
Of Investiment) do projeto, entregando software de valor de forma rápida e contínua; (5) 
Construir qualidade: garantir qualidade no desenvolvimento do software utilizando técnicas 
como TDD, Refatoração, etc. 
 
(6) Otimizar o todo: entender que o software concluído é muito mais que a soma das partes 
entregues e verificar como ele está alinhado com os objetivos da empresa. (7) Adiar decisões! 
Deixar as decisões e comprometimentos para o último momento possível, permitindo coletar 
informações e ter experiências para fortalecer a tomada de decisão. Enfim, galera... isso é o 
Método Lean! 
 
Ele serviu de base para o método ágil e tem várias características em comum, mas são 
diferentes. A tabela abaixo organiza um comparativo para vocês terem noção das diferenças. 
 
CARACTERÍSTICA LEAN ÁGIL 
Obcecado com... Desperdício Clientes e Mercados 
Gerencia... Processos Incertezas 
Entrega de... Valor Produto em Funcionamento 
Aplica... Heurísticas Princípios 
Foca no processo de... Padronização e Conformidade Autogerenciamento p/ maximizar autonomia 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
15 
121 
 
2 – SCRUM 
2.1 – Conceitos Básicos 
 
Galera, alguém de vocês sabe de onde vem esse nome? Então, eu vou contar para vocês! Esse nome 
vem do Rugby e é utilizado como uma metáfora para refletir o alto grau de cooperação 
necessária para obter sucesso no alcance de algum objetivo. Imagino que poucos de vocês 
entendam as regras desse esporte, portanto vou explicar de forma bastante rápida e objetiva o 
porquê dessa metáfora ser utilizada. 
 
No Rugby, um time pontua sempre que a bola cruza a linha de gol e toca o chão – sendo 
carregada ou por meio de passes. Caso o jogador seja derrubado, ele deve soltar a bola, e a 
jogada se reiniciará! Além disso, deve haver intensa troca de passes entre os jogadores, de modo 
a deixá-los menos vulneráveis a serem derrubados por outros jogadores. Calma que tudo isso 
que estou dizendo fará sentido... 
 
 
 
 
 
 
 
 
 
 
 
 
 
Bem... cada jogada se inicia quando um scrum é realizado, isto é, forma-se uma parede de força 
entre os jogadores, como pode ser visto nas imagens acima. Observem que os jogadores se 
reúnem de forma bastante próxima e coesa, unindo suas forças e habilidades para trabalhar 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
16 
121 
 
em conjunto e harmonicamente a fim de conseguir recuperar a bola. Percebam, portanto, que 
o time inteiro deve trabalhar para que a equipe possa pontuar. 
 
Diferentemente do Futebol Americano, não há um quarterback ou uma estrela no time – todos 
têm suas funções e responsabilidades, e são igualmente importantes! Acredito que agora ficou 
mais fácil entender de onde vem esse nome. Chega de papo e vamos à teoria... antes de 
iniciarmos, eu gostaria de fazer uma observação importante: o guia oficial do Scrum é um 
documento de apenas 19 páginas! 
 
Logo, eu recomendo que vocês o leiam por inteiro, porque ele é a fonte de praticamente tudo 
que veremos aqui! Tem versão em português, é gratuito, é enxuto, então não tem desculpas :) 
 
 
 
Scrum é um framework leve, simples de entender e extremamente difícil de dominar, para 
desenvolver e manter produtos complexos e adaptativos, enquanto entrega produtiva e 
criativamente produtos com o mais alto valor possível. Na minha época de concurso, eu decorava 
essa definição – sim, eu recomendo decorar algumas definições! Fiquem calmos porque nós 
vamos esmiuçar cada parte desse conceito. 
 
Em primeiro lugar, percebam que ele é um framework – isso significa dizer que ele agrega 
processos, métodos e técnicas. Fundamentalmente, ele possui pressupostos, conceitos, 
valores e práticas, mas quem utilizá-lo pode incluir outras novidades (Ex: Pair Programming, do 
XP). Ele não te dirá tudo o que fazer, logo você tem a liberdade para fazer o que melhor funcionar 
dentro das suas necessidades. 
 
Em segundo lugar, ele é um documento bastante enxuto conforme acabamos de ver! Vocês 
verão que, oficialmente e obrigatoriamente, ele é composto por três papeis (Product Owner, 
Scrum Master e Development Team); por quatro eventos (Sprint Planning, Daily Meeting, Sprint 
Review e Sprint Retrospective); por três artefatos (Product Backlog, Sprint Backlog e Product 
Increment); e por um fluxo (chamado Sprint). 
 
Aqueles que já conhecem devem estar um pouco confusos! Professor, o Gráfico Burndown não é 
um artefato? O Documento de Visão não é um artefato? Calma, galera! São, todos esses também 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
17 
121 
 
são artefatos! No entanto, oficialmente é possível utilizar o framework sem nada isso! Essas 
coisas são espécies de “plug-ins” que podem ser adicionados ao framework para ajudar no 
processo, mas eles são opcionais. Seguindo... 
 
O Scrum é um framework para gerenciar projetos, produtos e processos, focado na adaptação 
em vez de planejamento, que não utiliza muita documentação e que adota processos mais 
simplificados, facilitando a adaptação às mudanças de requisitos e permitindo entregas rápidas 
e menores. Ele é usado em ambientes complexos, onde os requisitos e as prioridades mudam 
constantemente. 
 
Diego, o que seria exatamente um ambiente complexo? Existe uma coisa chamada Modelo 
Cynefin que explica bem os tipos de ambientes. Existem os ambientes simples, complicados, 
complexos e caóticos. O que vocês precisam saber é que um ambiente complexo é aquele que 
não é muito bem definido, não é muito acoplado, há muitas mudanças, apresenta muitas formas 
de realizar um trabalho. 
 
Vamos ver um exemplo: O McDonalds é um ambiente complexo? Não, é um ambiente simples! 
Ele é muito bem definido, extremamente acoplado, não tem liberdade e não existem muitas 
opções de como realizar um trabalho. Em qualquer lugar do mundo, o cardápio será 
praticamente o mesmo; o cara que faz o sanduba realiza os mesmos passos; não há mudanças; 
não há várias formas de realizar um trabalho. 
 
 
 
Diego Carvalho, FernandoPedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
18 
121 
 
O Scrum é um framework em que podem ser empregados vários processos e técnicas. Pode ser 
definido como um conjunto de papéis, eventos, artefatos e regras associadas a uma equipe. Ele 
é fundamentado em teorias empíricas de controle de processo e emprega uma abordagem 
iterativa e incremental (maximizando as oportunidades de feedback) para aperfeiçoar a 
previsão e controle de riscos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
19 
121 
 
2.2 – Pilares Fundamentais 
 
O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com 
base naquilo que é verdadeiro e conhecido. Para tal, ele emprega uma abordagem iterativa e 
incremental para aperfeiçoar e otimizar a previsibilidade e controle de riscos, fundamentando-
se – para tal – em três pilares fundamentais: Transparência, Inspeção e Adaptação (é o famoso 
TIA). Vejamos em detalhes: 
 
– Transparência: aspectos significativos (e padronizados) devem estar visíveis aos responsáveis 
pelos resultados. Deve haver transparência dentro e fora da equipe, permitindo a qualquer 
pessoa compreender o que realmente está ocorrendo, ocasionando melhor comunicação e 
confiança. Ken Schwaber diz: “Scrum é igual sogra: chega na sua casa e esfrega todos os seus 
problemas na sua cara“. 
 
Se uma iteração falhar, todos devem ficar sabendo; se os feedbacks forem ruins, todos devem 
ficar sabendo; se o projeto atrasou, todos devem ficar sabendo. O objetivo é encarar as 
dificuldades de forma honesta e chegar a um consenso sobre como estes podem ser 
ultrapassados. Os erros são inevitáveis e a equipe deve ser incentivada a encarar esta premissa 
como uma base para aprender com os erros que são cometidos. 
 
– Inspeção: também chamada de verificação, os usuários devem frequentemente 
inspecionar os artefatos produzidos e o progresso para detectar variações indesejáveis (claro, 
não pode ser extremamente frequente ao ponto de atrapalhar a execução das tarefas). Uma vez 
que todos os problemas sejam transparentes, esse é o momento de inspecionar o processo e o 
produto em busca de resolver o problema. 
 
Galera, a ideia aqui é identificar rapidamente qualquer desvio em relação à meta que deve 
ser atingida. Nós veremos mais à frente que, tanto na Reunião de Revisão quanto na Reunião de 
Retrospectiva, os produtos e os processos serão devidamente inspecionados. Essas inspeções 
em geral são mais benéficas quando realizadas de forma diligente e cuidadosa por inspetores 
especializados no trabalho a se verificar. 
 
– Adaptação: se um inspetor determina que um ou mais aspectos de um processo desviou para 
fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o artefato 
sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para 
minimizar mais desvios. Como mudanças sempre ocorrem, é recomendável se adaptar a 
mudanças em vez de evitar mudanças. 
 
Legal, então vamos resumir os três pilares que sustentam o nosso framework! Tudo no 
Scrum deve ser transparente e facilmente acessível. Partindo dessa premissa, podemos 
inspecionar e identificar problemas e oportunidades de melhoria do produto e/ou processo – em 
geral, por meio de eventos (também chamados de reuniões ou cerimônias). Feito isso, deve-se 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
20 
121 
 
buscar ajustar e adaptar produto e/ou processo para minimizar desvios. Calma que ficará mais 
claro... 
 
Pessoal, lembrem-se que o Scrum é um framework para gerenciar projetos! Em algum momento 
eu falei aqui sobre desenvolvimento de software? Não, ele é capaz de gerenciar qualquer projeto 
que vise aumentar a agilidade e qualidade da sua execução. Embora tenha sido concebido 
inicialmente como uma metodologia de desenvolvimento de software, ele contém elementos 
que podem ajudar a formar uma equipe de alto desempenho para qualquer projeto. 
 
O Scrum apenas fornece um framework estruturado para executar alguns princípios. As 
equipes de desenvolvimento de software seguem essa metodologia porque seu trabalho é 
altamente complexo, interdependente e acelerado. No entanto, se ele funciona para essas 
equipes, certamente pode funcionar para outros casos. Se você é um líder de uma equipe que 
gerencia projetos complexos, é interessante pensar na aplicação do Scrum! 
 
Dito isso, notem que todos os conceitos que veremos daqui para frente podem ser aplicados a 
qualquer projeto, apesar de ter sido concebido para desenvolvimento de software. O primeiro e 
talvez principal conceito seja a Sprint! O que é uma Sprint? Trata-se de uma unidade de trabalho 
que satisfaz um requisito de negócio. Em outras palavras, é um ciclo completo de 
desenvolvimento de um incremento potencialmente entregável de um produto. 
 
Pensem comigo: estou em um projeto cujo objetivo é criar uma página de e-commerce para uma 
empresa de varejo. Eu tenho que realizar diversas tarefas para construir essa página, como por 
exemplo criar uma funcionalidade que permita o pagamento via cartão de crédito e débito. Essa 
funcionalidade pode ser (em conjunto com outras) a unidade de trabalho que satisfaz um 
requisito de negócio, logo pode ser realizada em uma sprint. 
 
O Scrum prega que, ao fim de cada sprint, deve-se entregar um incremento potencialmente 
funcional do produto ao cliente. O que seria potencialmente funcional? É aquilo que tem 
potencial de entrar ser utilizado pelo cliente em seu ambiente. As sprints têm duração de até um 
mês, permitindo feedbacks constantes quanto ao que está sendo desenvolvido. Ela é como um 
contêiner para todos os outros eventos e cerimônias que veremos à frente. 
 
Eu sei que está um pouco abstrato, então vamos pensar em uma metáfora! Imagina que você 
contrate um marceneiro para construir os armários do apê novo que você comprou logo após 
passar em um concurso público. Há duas maneiras de fazer isso: se fôssemos utilizar um método 
tradicional, ele perguntaria como você quer os armários, passaria alguns meses construindo e 
algum dia montaria todos os armários na sua casa de uma só vez – sem interações com você. 
 
No método ágil, nós vamos dividir esse projeto de construção dos armários em vários ciclos 
de tempo fixo. Por exemplo: nós vamos combinar com o marceneiro que a cada quinze dias eu 
quero que ele entregue um incremento dos armários já potencialmente funcional, ou seja, que 
você já possa utilizar na sua casa. Nos primeiros quinze dias, ele deve entregar os armários do 
banheiro prontinhos para você utilizar. 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
21 
121 
 
 
Nos próximos quinze dias, ele deve entregar os armários da área de serviço também prontos para 
utilizar. Nos outros quinze, não será possível entregar todos os armários do quarto, mas ele 
deve entregar pelo menos o guarda-roupa já pronto para você utilizar. Vocês conseguem notar 
que a cada intervalo regular de quinze dias, você vai recebendo incrementos potencialmente 
funcionais? Com o software é a mesma coisa... 
 
Qual é a grande vantagem dessa segunda opção em relação à primeira? Bem, primeiro você não 
morre de ansiedadede receber os móveis somente ao final; a segunda vantagem é que você pode 
mudar de ideia no meio do caminho e pedir para ele mudar o projeto. Enfim, o que importa disso 
tudo que eu disse? Importa que esses ciclos regulares de tempo fixo de desenvolvimento de 
um incremento potencialmente funcional são conhecidos também como Sprint! Clareou 
agora? 
���� 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
22 
121 
 
2.3 – Papéis 
 
O Scrum possui poucos papeis, mas eles são muito bem definidos! O Scrum Team (Equipe 
Scrum) é formado por três papeis: Product Owner (PO), Scrum Master (SM) e Development 
Team (DT). As pessoas que desempenham esses papeis são igualmente responsáveis e 
responsabilizadas pelos resultados do trabalho e, assim, se comprometem com o projeto. Eles 
são membros de um mesmo time, e trabalham juntos, de forma colaborativa, para alcançarem 
seus resultados. 
 
Aqui é importante não confundir Development Team com Scrum Team – vejam na hierarquia 
apresentada abaixo! A Equipe Scrum que é um time auto-organizável e multifuncional! Ser 
auto-organizável significa que ela é capaz de escolher qual a melhor forma para realizar seu 
próprio trabalho em vez de serem dirigidos por outros de fora do Time. Ser multifuncional 
significa que ela possui todas as competências e não depende de outros de fora da equipe. 
 
Em outras palavras, os times de desenvolvimento não contêm subtimes dedicados a domínios 
específicos de conhecimento (Ex: testadores, analistas de negócio, entre outros). A Equipe 
Scrum é o responsável por entregar produtos de forma iterativa e incremental, maximizando 
as oportunidades de realimentação (feedback). Uma dúvida comum é: professor, pode existir 
uma sobreposição nesses papeis, isto é, uma mesma pessoa desempenhando dois papeis diferentes? 
 
Sim, em tese o Scrum Master e o Product Owner podem fazer parte do Development Team, 
mas um Scrum Master jamais pode ser simultaneamente Product Owner! Essa última 
afirmação não está explícita no Guia Scrum, mas é possível inferir que pode haver um conflito de 
interesses. Quanto à primeira afirmação: “The Product Owner and Scrum Master roles are not 
included in this count unless they are also executing the work of the Sprint Backlog”. 
 
 
 
 
 
 
 
 
SC
RU
M
 T
EA
M
 
( E
QU
IP
E 
SC
RU
M
 )
DEVELOPMENT TEAM 
( EQUIPE DE DESENVOLVIMENTO )
PRODUCT OWNER 
( DONO DO PRODUTO )
SCRUM MASTER 
( MESTRE SCRUM )
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
23 
121 
 
2.3.1 – Product Owner (PO) 
 
O Product Owner é uma pessoa e não um comitê. Ele pode representar o desejo de um comitê 
no Product Backlog (veremos adiante), mas aqueles que quiserem uma alteração nas 
prioridades dos itens de backlog devem convencer o Product Owner. Para que ele tenha 
sucesso, toda a organização deve respeitar as suas decisões e elas devem ser visíveis no conteúdo 
e na priorização do Backlog do Produto. Vejamos a seguir suas responsabilidades e 
características: 
 
RE
SP
ON
SA
BI
LI
DA
DE
S 
E 
CA
RA
CT
ER
ÍS
TI
CA
S:
 
PR
OD
UC
T 
OW
NE
R 
(P
O)
 
Ele é responsável pela macro-gestão e pela gestão do produto. 
 
Ele é o responsável por maximizar o valor do produto e do trabalho da equipe de desenvolvimento, 
sendo o único que pode gerenciar o Product Backlog. 
Ele pode até delegar as atividades de gerenciamento para o time de desenvolvimento, mas ainda será 
considerado o responsável pelos trabalhos. 
Ele é responsável por priorizar/ordenar os itens do Product Backlog e seleciona aqueles que serão 
implementados. 
Ele é responsável por garantir o ROI (Returno On Investment ou Retorno sobre Investimento). 
 
Ele é responsável por expressar claramente os itens do Product Backlog. 
 
Ele é responsável por garantir que o Backlog do Produto seja visível, transparente, claro para todos, e 
mostrar o que a Equipe Scrum vai trabalhar a seguir. 
Ele é responsável por garantir que o Time de Desenvolvimento entenda os itens do Product Backlog 
no nível necessário. 
 
2.3.2 – Development Team (DT) 
 
O Development Team consiste de profissionais que realizam o trabalho de entregar uma 
versão usável que potencialmente incrementa o produto “pronto” ao final de cada sprint. 
Somente integrantes do Time de Desenvolvimento criam incrementos. Ninguém tem permissão 
para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o 
Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem. 
 
O Time de Desenvolvimento só responde ao Product Owner. Além disso, só ele pode 
cancelar uma sprint. Perfeito? Ele deve ser pequeno o suficiente de forma a se manter ágil e 
produtivo, e grande o suficiente de forma que a coordenação dos membros não cause 
problemas. Com menos de três pessoas, há menor interação e pode haver problemas em relação 
ao conhecimento durante a execução da sprint. Com mais de nove, há muita complexidade no 
gerenciamento. 
 
Dessa forma, recomenda-se que a equipe tenha entre 3 e 9 integrantes (excluídos o Product 
Owner e Scrum Master – exceto se eles também executarem o trabalho da sprint), de modo 
que não seja pequena demais que haja restrições de habilidades nem grande demais que seja 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
24 
121 
 
complicado de gerenciar. E, para finalizar, vou enfatizar mais uma vez: não confundam Equipe 
de Desenvolvimento (Development Team) com Equipe Scrum (Scrum Team)! 
 
RE
SP
ON
SA
BI
LI
DA
DE
S 
E 
CA
RA
CT
ER
ÍS
TI
CA
S:
 
DE
VE
LO
PM
EN
T 
TE
AM
 (d
t)
 
Responsável pela micro-gestão e pela criação do produto. 
 
Eles são auto-organizados. Ninguém (nem mesmo o SM) diz ao Time de Desenvolvimento como 
transformar o Product Backlog em incrementos de funcionalidades potencialmente utilizáveis. 
Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, 
enquanto equipe, para criar o incremento do Produto. 
O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja 
Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; 
Individualmente, os integrantes do Time de Desenvolvimento podem ter habilidades especializadas, 
mas a responsabilidade pertence aos desenvolvedores como um todo. 
Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de 
conhecimento, tais como teste ou análise de negócios. 
Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e 
gerenciar seu próprio trabalho. 
 
2.3.3 – Scrum Master (SM) 
 
O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado! Ele faz 
isso para garantir que a Equipe Scrum adira à teoria, práticas e regras do Scrum. O Scrum Master 
é um servo-líder para a Equipe Scrum. Ele ajuda aqueles que estão fora da a Equipe Scrum a 
entender quais as suas interações com a Equipe Scrum são úteis e quais não são. Ademais, ele 
ajuda todos a mudarem estas interações para maximizar o valor criado pela Equipe Scrum. 
 
RE
SP
ON
SA
BI
LI
DA
DE
S 
E 
CA
RA
CT
ER
ÍS
TI
CA
S:
 
sc
ru
m
 m
as
te
r 
(s
m
) 
Responsável pela gestão de pessoas e gestão do processo. 
 
Ele deve garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que a 
Equipe Scrum adere à teoria,práticas e regras do Scrum. 
O Scrum Master ajuda aqueles que estão fora da Equipe Scrum a entender quais as suas interações 
com a Equipe Scrum são úteis e quais não são. 
O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pela Equipe 
Scrum. 
Ele é responsável por orientar o Product Owner na criação e ordenação do Product Backlog. 
 
Ele é responsável por garantir que as regras do Scrum estejam sendo cumpridas e seus valores estejam 
sendo seguidos. 
Ele é responsável por ajudar a remover impedimentos que o time enfrente, fazendo isso sem o uso de 
qualquer autoridade. 
Ele utiliza técnicas de facilitação e coaching para que os membros do time consigam visualizar os 
problemas e encontrem a melhor solução. 
Durante eventos, ele é responsável por fazer com que a reunião flua adequadamente, utilizando 
técnicas de facilitação, embora não seja o responsável pela condução. 
Ele ajuda a treinar o time de desenvolvimento em autogerenciamento e interdisciplinaridade. 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
25 
121 
 
Ele treina o time de desenvolvimento em ambientes organizacionais nos quais o Scrum não é 
totalmente adotado e compreendido. 
Ele ensina a Equipe Scrum a criar itens do Product Backlog de forma clara e concisa. 
 
Ele comunica claramente a visão, objetivo e itens do Product Backlog para o time de 
desenvolvimento. 
 
 
Galera, eu só consigo explicar por metáfora, então vamos tentar entender esses papeis! 
Imaginem que João Canabrava deseja construir uma casa. Para tal, ele contrata uma renomada 
empresa de engenharia. A empresa irá fornecer todo seu know-how por meio de uma Equipe de 
Construção de Casas, que será composta por uma Equipe de Pedreiros, um Mestre de Obras 
e... por você! Sim, você fará parte da Equipe de Construção de Casas como principal parte 
interessada. 
 
Vamos dar um nome para você? Você ocupará o cargo de Dono da Casa. Portanto, a Equipe de 
Construção de Casas será composta por uma Equipe de Pedreiros, pelo Mestre de Obras e pelo 
Dono da Casa. E como será a organização e a função de cada um desses papeis? Bem, a Equipe de 
Pedreiros é composta por 3 a 9 pedreiros multidisciplinares, isto é, todos dominam todas as 
atividades de um pedreiro. 
 
Galera, esses caras são os responsáveis por colocar a mão na massa, levantar parede, fazer o 
concreto, alinhar o piso, entre outras atividades. Já o Mestre de Obras é o grande facilitador! 
Como assim, professor? Ele é o cara que vai retirar os impedimentos que aparecem no decorrer 
do nosso projeto. Um pedreiro faltou? Ficou doente? Se machucou? Ele irá buscar uma maneira 
de reduzir os impactos dessa ausência. 
 
Os pedreiros estão desmotivados, distraídos, descuidados? Ele irá arrumar uma maneira de 
solucionar isso. Um pedreiro saiu na porrada com outro? Ele vai tentar intermediar o conflito. Além 
disso, ele que vai trazer a demanda do Dono da Casa, entender o que ele quer e passar de 
maneira simples, clara e objetiva para a Equipe de Pedreiros. Ele é o cara que mais deve 
conhecer os fundamentos da construção de uma casa! 
 
Imaginem ele como um grande estudioso da construção de casas com bastante experiência 
adquirida em anos de empreendimentos. Ele saca tudo sobre como se faz para se construir uma 
casa, qual é o papel de cada um, qual é a melhor ordem, quais são as melhores técnicas e é um 
grande professor, capaz de ensinar a todos os outros integrantes quais são os melhores princípios 
para a construção de casas. Em outras palavras, ele é um grande mestre! 
 
Por fim, ele também é capaz de treinar a equipe de construção para que ela seja auto-gerenciável 
e interdisciplinar. Legal, mas está faltando um papel nessa história. E qual é? É o seu papel! Qual 
a sua função? Você é o Dono da Casa! Logo, você que gerencia o que será feito e o que não será 
feito, sendo também o responsável pelo que será entregue. A Equipe de Pedreiros responde a 
você! Até o Mestre de Obras responde somente a você! Viu a sua importância? 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
26 
121 
 
 
Você é o cara que tem que tentar fazer essa casa ficar da melhor forma possível – com máximo 
valor agregado). Você é o cara que vai priorizar o que deve ser feito primeiro; você é o cara 
que coloca ou tira tarefas da lista tarefas a serem realizadas; você é o único cara que pode 
cancelar determinada tarefa; você é o cara que fiz expressamente o que deve ser feito; enfim... 
você ocupa um papel importantíssimo para o sucesso do projeto de construir uma casa. 
 
Galera, toda metáfora possui suas limitações, mas acho que vocês conseguiram captar a 
mensagem aqui! A Equipe de Construção de Casas é o Scrum Team; a Equipe de Pedreiros é o 
Development Team; o Mestre de Obras é o Scrum Master; e o Dono da Casa é o Product Owner. 
Além disso, cada um desses tem atividades bem definidas e o controle sobre essas atividades 
é descentralizado. Entendido? Seeeeeegue o jogo... 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
27 
121 
 
2.4 – Artefatos 
 
Segundo o Guia do Scrum, o framework possui apenas três artefatos oficiais: Product Backlog, 
Sprint Backlog e Product Increment. Vejamos cada um deles... 
 
2.4.1 – Product Backlog 
 
Antes de tudo, o que é um backlog? Galera, um backlog é basicamente uma lista, um resumo 
histórico, de acumulação de trabalho num determinado período de tempo, pode ser uma pilha 
de pedidos que devem ser produzidos. Já o Product Backlog é uma lista ordenada (por valor, 
risco, prioridade, entre outros) de requisitos ou funcionalidades que o produto deve conter2 
criada pela Equipe Scrum. 
 
O Product Backlog é a origem única dos requisitos para qualquer mudança a ser feita no produto. 
Costuma-se dizer que ele é um artefato dinâmico que nunca estará completo e existirá 
enquanto o produto também existir. Por que? Porque sempre haverá novos requisitos, novas 
necessidades e mudanças a serem incorporadas. Logo, trata-se de um artefato vivo – sempre em 
movimento. 
 
O Product Backlog evolui tanto quanto o produto e o ambiente no qual ele será utilizado 
evoluem. Ele muda constantemente para identificar o que o produto necessita para ser mais 
apropriado, competitivo e útil para as partes interessadas. Lembrando que somente o Product 
Owner pode inserir, remover ou reordenar esses itens, incluindo seu conteúdo, disponibilidade e 
ordenação. 
 
Rafael Prikladnicki afirma que o formato mais utilizado para os itens são Histórias de Usuário 
(User Stories) ordenadas de acordo com o critério escolhido pelo Product Owner. O que são 
histórias de usuário? É basicamente uma especificação de uma ou mais frases na linguagem 
de negócio ou cotidiana do usuário do sistema que captura o que um usuário faz ou necessita 
fazer como parte de sua função de trabalho. 
 
Enfim... em geral, itens mais importantes ficam no topo do Product Backlog e são 
implementados primeiro. Na maioria das vezes, esses são os itens sobre os quais há maior 
conhecimento, logo são mais detalhados e refinados. Itens que precisem de maior refinamento 
geralmente têm uma importância menor e ficam mais abaixo. Não existe, no entanto, uma forma 
única para materializar esse artefato e descrever seus itens. 
 
Além das Histórias de Usuário, podem ser utilizadas descrições textuais de funcionalidades, 
cenários de casos de uso, entreoutros. Galera, o Product Backlog pode apresentar itens 
 
2 Apesar de o Scrum Team (PO, SM, DT) ser o responsável pela criação do Product Backlog, o responsável pelo artefato e o 
único que pode priorizar suas funcionalidades é o Product Owner. 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
28 
121 
 
funcionais, não-funcionais, arquiteturais ou de infraestrutura – além de itens que representem 
riscos a serem removidos. É claro que, durante o andamento do projeto, algumas 
funcionalidades podem acabar perdendo a importância – não importando sob que circunstâncias 
isso ocorreu. 
 
Isso é totalmente normal na maioria dos projetos, uma vez que é impossível saber, desde o 
início, os detalhes de tudo o que queremos no produto. Assim, algumas funcionalidades 
podem acabar até mesmo desaparecendo. Da mesma forma, novas funcionalidades também 
podem ser adicionadas de acordo com a necessidade. Vejam o exemplo retirado do livro Métodos 
Ágeis para Desenvolvimento de Software: 
 
 
 
Vocês conseguiram entender? O Product Backlog é onde eu vou armazenar todas as 
necessidades que eu desejo no meu projeto, entre outras coisas. No exemplo acima, deseja-
se poder tanto tuitar quanto remover um tuite – são duas histórias de usuário diferentes que eu 
desejo que sejam implementadas na minha aplicação. Legal, mas quando eu sei quando um desses 
itens pode realmente ser considerado pronto (também chamado ready)? 
 
Para que um item possa ser incluído em uma sprint, ele deve ser pequeno o suficiente para que 
caiba em uma única sprint e deve deixar tudo claro e transparente quanto à expectativa do 
Product Owner (geralmente através de um critério de aceite). Mas até que ponto estes requisitos 
precisam ser detalhados? Eles devem ser detalhados até atender ao conceito de Definition of 
Ready (DoR). O que é isso, Diego? 
 
Isso significa que o requisito tem informações suficientes para começar a ser desenvolvido 
imediatamente. Esta definição é bastante específica de cada organização – não há um padrão. 
Vou dar um exemplo para melhor entendimento... eu já trabalhei em um projeto em que as 
histórias de usuário eram entregues aos desenvolvedores de forma muito pobres, pouco 
refinadas e demasiadamente confusas. 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
29 
121 
 
 
O Product Owner estava rejeitando a conclusão das sprints, declarando que não havia sido 
feito o que ele havia pedido. Os desenvolvedores reclamavam que a especificação era péssima 
e que nem o próprio Product Owner sabia o que queria. A partir daí, modificamos nosso processo! 
A equipe combinou critérios explícitos e visíveis do que uma história de usuário deveria conter 
para ser aceita para entrar em uma sprint. Como diz o ditado, combinado não sai caro! 
 
Dessa forma, uma vez que todos haviam concordado, as brigas reduziram bastante. Por que? 
Porque eles nos disseram exatamente (por meio de um checklist) o que a história de usuário 
deveria conter para que elas pudessem ser aceitas para entrar no Product Backlog e serem de 
fato implementadas pelos desenvolvedores. A partir daí, essa definição de “pronto” nos ajudou 
a mitigar falhas de comunicação. 
 
2.4.2 – Sprint Backlog 
 
O Sprint Backlog é o conjunto de itens selecionados para serem implementados durante a 
sprint mais o plano para transformá-los em um incremento. Assim, ao final de cada Reunião 
de Planejamento, um novo Sprint Backlog é criado. Normalmente, o plano é composto por 
tarefas técnicas necessárias para transformar o item em um incremento do produto. Vamos 
diferenciar Product Backlog e Sprint Backlog? Essa é uma pegadinha comum em prova! 
 
O primeiro é uma lista ordenada dos requisitos ou funcionalidades que o software deverá possuir. 
O segundo é uma lista de tarefas a serem executadas durante uma sprint para atingir a sua 
meta. Trata-se do desmembramento de cada item selecionado do Product Backlog em pequenas 
tarefas. O Sprint Backlog torna visível todo o trabalho que o time de desenvolvimento identifica 
como necessário para atingir a meta da sprint. 
 
Aliás, os membros do time de desenvolvimento (e somente eles) podem adicionar novas tarefas 
caso descubram, no decorrer da sprint, que mais trabalho será necessário. Da mesma forma, 
também podem remover tarefas caso estas se mostrem desnecessárias. Conforme o trabalho é 
realizado ou completado, a estimativa do trabalho restante é atualizada. Em qualquer ponto do 
tempo na sprint, o total do trabalho remanescente dos itens pode ser somado. 
 
O Sprint Backlog é altamente visível, uma imagem em tempo real 
do trabalho que o time de desenvolvimento planeja completar 
durante a sprint, e pertence exclusivamente ao time de 
desenvolvimento. O time de desenvolvimento monitora o total do 
trabalho restante pelo menos a cada Reunião Diária. O time de 
desenvolvimento acompanha estes resumos diários e projeta a 
probabilidade de alcançar o objetivo da sprint. Com o 
rastreamento do trabalho restante em toda a sprint, o time de 
desenvolvimento é capaz de gerenciar o seu progresso. Exemplo: 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
30 
121 
 
 
 
 
2.4.3 – Product Increment 
 
Ao final de cada sprint, a equipe de desenvolvimento entrega um incremento do produto – 
resultado do que foi produzido ao final do trabalho realizado na sprint. Esse é um dos 
principais conceitos do framework e vai ao encontro da sua natureza empírica, já que permite ao 
Product Owner perceber o valor do investimento realizado e também vislumbrar outras 
possibilidades de novos incrementos. 
 
Para a equipe de desenvolvimento, é importante entender que o incremento deve ser algo 
potencialmente entregável. Por que potencialmente? Porque o cliente pode optar por 
disponibilizar de imediato o incremento ou não. A equipe, portanto, deve produzir código que 
tenha qualidade – e, então, chegamos à Definition of Done (DoD). O que seria isso, professor? 
Calma, eu vou explicar... 
 
 
 
Pronto significa pronto mesmo! Quando uma equipe ágil diz que uma funcionalidade está 
pronta, isso significa que não tem aquele “veja bem…” ou “só falta uma coisinha, mas já está 
pronto…”. O DoD é um acordo formal que define claramente quais são os passos mínimos 
para a conclusão de um item ou funcionalidade potencialmente entregável. Em outras 
palavras, é uma lista de verificação de atividades necessárias para que um incremento seja 
considerado como completo. 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
31 
121 
 
 
Ele serve, mais ou menos, como um contrato entre a Equipe de Desenvolvimento e o Product 
Owner, garantindo que todo produto gerado pelo projeto estará dentro dos padrões de 
qualidade estabelecidos anteriormente. Vocês devem se lembrar que a Definition of Ready 
(DoR) é um checklist de critérios acordados para que a equipe de desenvolvimento possa aceitar 
um requisito. Correto? 
 
Aqui acontece exatamente o contrário: trata-se de um checklist de critérios acordados para 
que o Product Owner possa aceitar uma funcionalidade. Ambos tratam de critérios de aceite, 
mas o primeiro trata dos critérios de aceite das histórias de usuário pela equipe de 
desenvolvimento e o segundo trata dos critérios de aceite dasfuncionalidades pelo Product 
Owner. Em suma: toda a Equipe Scrum deve entender o que significa “pronto” para ambos os 
casos. 
 
Uma funcionalidade só é considerada “pronta” se tiver passado por todas as etapas definidas 
pela equipe de desenvolvimento (Ex: codificado, passado por todos os testes unitários, 
passado pelos testes de aceitação, entre outros). Uma funcionalidade que não esteja “pronta” 
ao final da sprint deve retornar ao Product Backlog para que seja incluída em uma próxima sprint. 
Esse critério é bastante específico, cada um escolhe o seu! 
 
 
 
Por outro lado, é uma boa prática revisar essas definições de “pronto” a cada sprint porque elas 
podem mudar ao longo do tempo. O amadurecimento organizacional e a habilidade da equipe 
de resolver impedimentos podem fazer com que alguns itens sejam acrescentados com o 
passar do tempo. Sempre lembrando que o Definition of Ready é opcional, já o Definition of Done 
é obrigatório. Compreenderam? 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
32 
121 
 
 
 
 
Por fim, é interessante mencionar outros artefatos que não estão explícitos no guia como o 
Gráfico Burndown, que torna visível a evolução diária do trabalho da equipe de desenvolvimento, 
na medida em que mostra a comparação entre o trabalho estimado inicialmente com a 
quantidade restante estimada de trabalho. Via de regra, as unidades utilizadas são de esforço 
(em horas) planejado pelo tempo decorrido. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
33 
121 
 
2.5 – Eventos 
 
Vamos falar agora sobre os eventos – também conhecidos como reuniões ou cerimônias! No 
entanto, uma vez que agora nós já temos mais subsídios teóricos, é interessante falar um pouco 
mais sobre sprints. Bem, uma sprint dura um mês ou menos! Além disso, uma sprint se inicia 
imediatamente após a conclusão da sprint anterior. Durante a sprint é proibido realizar 
mudanças que coloquem em risco os objetivos da própria sprint. 
 
Na nossa metáfora, se eu planejei que nessa sprint eu vou construir os armários do banheiro 
utilizando madeira do tipo Cedro, eu não posso no meio do caminho alterar para madeira do tipo 
Mogno porque isso coloca em risco os objetivos da minha sprint, isto é, essa mudança pode 
inviabilizar a entrega na data acordada e a sprint pode falhar! Além disso, é proibido mudar a 
composição da equipe ou diminuir as metas de qualidade. 
 
Apesar disso, o escopo pode ser sempre clarificado e renegociado entre o Product Owner e a 
Equipe de Desenvolvimento durante a sprint. Aliás, nada impede que uma sprint seja 
cancelada antes de seu time-box terminar e isso somente pode ser feito pelo Product Owner 
(sob influência de stakeholders, equipe de desenvolvimento, entre outros). Professor, por que 
alguém faria esse cancelamento? 
 
A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se 
a organização mudar sua direção ou se as condições do mercado ou das tecnologias 
mudarem. Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas 
circunstâncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem 
sentido. Se uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product 
Owner o aceita. 
 
Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no 
Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente 
reestimado. O cancelamento de Sprints consome recursos, já que todos tem que se reagrupar 
em outra reunião de planejamento da sprint para iniciar outra sprint. Cancelamentos de sprints 
são frequentemente traumáticos para a Equipe Scrum, e são muito incomuns. 
 
Por falar em planejamento da sprint, vamos falar agora sobre os eventos. Por que eu fiz essa 
pausa para falar um pouco mais sobre as sprints? Porque os quatro eventos que serão detalhados 
a seguir compõem uma sprint – além, é claro, do próprio trabalho de desenvolvimento. Galera, 
Eventos Scrum são eventos time-boxed – o que significa apenas que eles possuem uma 
duração máxima predefinida. 
 
Eles são utilizados para criar uma rotina e minimizar a necessidade de reuniões não definidas 
pelo Scrum. Esses eventos que compõem a sprint são: (1) Reunião de Planejamento da Sprint; 
(2) Reunião Diária; (3) Revisão da Sprint; e (4) Retrospectiva da Sprint. Veremos nas próximas 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
34 
121 
 
páginas em detalhes cada um desses eventos, mas já deixo a dica de que não é possível ir para a 
prova sem saber pelo menos o básico sobre cada um deles. Ok? Vamos lá... 
 
2.5.1 – Planejamento da Sprint 
 
O trabalho a ser realizado na Sprint é planejado na Reunião de Planejamento da Sprint. Este 
planejamento é criado com o trabalho colaborativo de toda a Equipe Scrum. Ela possui um time-
box com no máximo oito horas para uma sprint de um mês de duração – para sprints menores, a 
duração é menor. O Scrum Master garante que o evento ocorra e que os participantes entendam 
seu propósito. Ela consiste em duas partes e devem responder adequadamente as perguntas: 
 
 
1. O que será entregue como resultado do incremento da próxima Sprint? 
 
 
 
2. Como o trabalho necessário para entregar o incremento será realizado? 
 
 
Na primeira parte, a Equipe de Desenvolvimento tenta prever as funcionalidades que serão 
desenvolvidas durante a sprint. O Product Owner apresenta as histórias de usuário mais 
priorizados do Product Backlog à Equipe de Desenvolvimento. Como ele faz isso? Em geral, ele dá 
um valor de negócio para cada item do backlog, organizando-os em forma decrescente de valor 
de negócio. Como assim, professor? 
 
Imaginem que exista um item que o Product Owner deseja muito que seja implementado – ele 
pode dizer que esse item tem o valor de negócio de 1000. Agora imagine que exista outro item 
no Product Backlog que o Product Owner não liga tanto – ele dá um valor de negócio de 10. Dessa 
forma, o Product Owner consegue ordenar os itens de acordo com o valor de negócio. Feito 
isso, é hora de estimar o esforço de desenvolvimento de cada item do backlog. 
 
Quando nós utilizamos histórias de usuário, é comum utilizarmos uma outra unidade de medida 
para medir esforço, em vez do tempo – utilizado frequentemente em metodologias tradicionais. 
No caso de Histórias de Usuário (User Stories), nós utilizamos Pontos de História (Story Points). 
Trata-se de uma unidade de medida relativa que leva em consideração o esforço3 necessário 
para realizar uma determinada funcionalidade. 
 
Se uma funcionalidade requerer o dobro de esforço para ser implementada, ela receberá 
aproximadamente o dobro de Story Points. Para fazer essa estimativa, a equipe de 
desenvolvimento realiza uma comparação com outras histórias já estimadas. Caso não haja 
 
3 Há uma polêmica danada: alguns afirmam que ela estima complexidade e, não, esforço; outros dizem que é uma combinação 
de complexidade, esforço, risco, etc. 
Diego Carvalho, Fernando Pedrosa Lopes 
Aula 03
Engenharia de Software p/ BASA (Técnico Científico - TI) 2021 - Pré-Edital
www.estrategiaconcursos.com.br
1658294
Curso adquirido no site www.rateiobarato.com
 
 
 
 
35 
121 
 
ainda nada estimado no Product Backlog, a equipe localiza a história de usuário com o menor 
esforço para desenvolvimento