Evolução do Desenvolvimento de Software

Prévia do material em texto

Página inicial 
A EVOLUÇÃO DO 
PROCESSO DE 
DESENVOLVIMEN 
TO DE SOFTWARE 
Professor : 
Esp. Marcos Joaquim de Freitas 
Objetivos de aprendizagem 
Compreender o contexto e os objetivos da Engenharia de Software para melhor entender o 
surgimento do Scrum e das metodologias ágeis. 
Compreender as características dos modelos clássicos de ciclo de vida de software para melhor 
entender os conceitos do modelo utilizado pelo Scrum. 
Compreender o conceito dos modelos interativos e entender por que esse modelo faz parte do 
conceito ágil de desenvolvimento. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
Compreender o contexto de criação do Scrum e os avanços que esse framework proporcionou para o 
gerenciamento de projetos de desenvolvimento. 
Plano de estudo 
A seguir, apresentam-se os tópicos que você estudará nesta unidade: 
Engenharia de Software. 
Modelos de Ciclo de Vida de Software. 
Modelos Iterativos. 
O Nascimento do Scrum. 
Introdução 
O processo de desenvolvimento de software variou muito ao longo do tempo, com diversos modelos e 
estratégias sendo testados e utilizados, para que o produto final de software tivesse cada vez mais 
qualidade, com custo, risco e esforço cada vez mais minimizados ao logo do projeto. Diferentes modelos e 
formatos foram propostos para que se consolidassem, hoje em dia, os modelos mais difundidos como o 
SCRUM e as demais metodologias ágeis. 
Dos anos sessenta até os dias mais atuais, o processo de desenvolvimento de software experimentou 
desde um formato de desenvolvimento completamente sem controle e sem nenhum processo definido 
até os modelos mais atuais, os quais estabelecem de forma bem clara e definida uma gama de elementos 
que se envolvem diretamente e indiretamente na construção de um sistema. 
Os modelos clássicos, em cascata, criados e aplicados nas equipes de desenvolvimento, traziam para a 
realidade da sua época uma organização e uma padronização para a forma de trabalho, que foi 
fundamental na evolução dos conceitos aplicados em projetos de software. No entanto, esses modelos 
clássicos não se adequavam à realidade vivida pelas pessoas dentro do processo de desenvolvimento. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial
https://getfireshot.com
A partir da necessidade de dar mais resultado em menos tempo e de satisfazer mais o cliente, era preciso 
que fossem criados outros conceitos mais dinâmicos, que se adaptassem melhor às inevitáveis alterações 
de escopo que surgem ao longo dos projetos. Os modelos iterativos e incrementais representaram uma 
evolução e abriu as portas para que formatos ainda mais dinâmicos, ágeis e adaptáveis surgissem. 
Dentro dessa realidade, para iniciarmos uma construção do conhecimento, é fundamental conhecer, de 
modo geral, toda a evolução desse processo, ocorrida ao longo do tempo. Você é nosso convidado para 
melhorar o conhecimento e compreender como funciona o framework Scrum. 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial/unidade-1
Página inicial 
ENGENHARIA DE SOFTWARE 
Engenharia de Software é a aplicação de princípios científicos, métodos, modelos, padrões e teorias que 
permitem gerenciar, planejar, modelar, projetar, implementar, medir, analisar, manter e aprimorar um 
software (SOMMERVILLE, 2010). Tem por objetivo obter um software de qualidade, com alta 
produtividade ao longo do desenvolvimento, garantindo sua operação e manutenção dentro de custos e 
prazos controlados. 
Processo de Software 
Processo de desenvolvimento de software é um conjunto de atividades ordenadas capaz de gerar 
resultados que irão conduzir à produção de um produto de software (SOMMERVILLE, 2010). Esse 
processo pode ser entendido também como a abordagem que será dada para construir, implantar e, até 
mesmo, manter o software. 
Dentro do processo geral de desenvolvimento de software, existem algumas atividades que são comuns, 
ainda que isso possa passar por alguma variação dependendo do tipo de desenvolvimento que estiver 
sendo realizado ou do tipo de modelo que será adotado. Essas atividades são comumente conhecidas 
como: Requisitos, Projeto e Implementação, Validação e Evolução. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
Requisitos 
A atividade de requisitos, também conhecida como etapa de elicitação, é responsável por extrair do 
usuário do software as funções que este deve executar, bem como informação referente às restrições, 
escopo, premissas, entre outras. 
Sommerville (2010) destaca que o sucesso das etapas posteriores depende da qualidade dos requisitos 
gerados. Portanto, para que essa atividade seja executada de forma adequada, evitando retrabalhos nas 
atividades posteriores, uma série de técnicas de elicitação de requisitos deve ser utilizada pelos analistas 
ao longo de toda execução dessa atividade. 
Projeto e Implementação 
Muitas vezes tratadas como atividades independentes, nessa fase o software é codificado de acordo com 
as especificações. Modelos propostos em diagramas são apresentados para a equipe de desenvolvimento 
que será responsável por fazer a codificação. 
Nessa etapa se pressupõe o uso de uma linguagem de programação. A escolha da linguagem de 
programação é influenciada pela estrutura do sistema, a qual foi estabelecida durante a atividade de 
projeto e pela cultura do time de desenvolvimento. 
Validação 
Nessa etapa, o software desenvolvido na atividade anterior é validado para que seja garantido, antes de 
entrar em produção, que todas as suas funcionalidades estão de acordo com os requisitos levantados. 
Diversos tipos de testes são realizados para garantir que o software foi desenvolvido acordo com o 
levantamento realizado. São exemplos de alguns testes de software: Teste Funcional, Teste de Unidade, 
Teste de Integração, Teste de Volume. 
Evolução 
Todo o software precisa ser evoluído, constantemente, para continuar sendo útil para o usuário. É possível 
considerar que desenvolvimento e manutenção serão atividades constantes ao longo de toda a vida útil 
de um software que estiver em funcionamento. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
A evolução do software pode partir de alguma necessidade de correção de algum problema existente, de 
adaptações decorrentes de novas exigências, ou ainda de algum melhoramento das funcionalidades. 
MODELOS DE CICLO DE VIDA 
DE SOFTWARE 
Modelos de ciclo de vida de software são representações abstratas mais simplificadas do processo de 
desenvolvimento do software. 
Existem diversos modelos de ciclo de vida de software e as suas denominações podem variar conforme os 
autores. Sommerville (2010) e Pressman (2001) apresentam em suas obras os modelos de ciclo de vida 
dos quais iremos destacar os principais. 
Modelo em Cascata 
Também conhecido como clássico, esse modelo foi a primeira tentativa de se formalizar uma metodologia 
de desenvolvimento de software, tem um formato sequencial similar a um processo de manufatura 
concebido no contexto industrial. Seguindo um modelo linear, a fase seguinte só inicia após a fase anterior 
estar concluída, conforme é possível observar na Figura 1. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
Figura 1 – Modelo em Cascata. 
Na prática, o modelo em cascata não é muito indicado em função da sua característica pouco dinâmica. 
Apesar de ser um modelo de fácil utilização, por ter as etapas bem definidas,um erro de sistema 
identificado na fase de testes, ou qualquer necessária alteração de escopo do projeto, gera um elevado 
custo de correção ou alteração para o projeto. 
De acordo com estudos realizados, o custo em correção de um software em 
desenvolvimento cresce exponencialmente 10 vezes para cada estágio que o projeto 
avança sem ser corrigido. 
Portanto, defeitos encontrados nas fases iniciais do desenvolvimento do software são 
mais baratos de serem corrigidos do que aqueles encontrados quando o software já 
está em produção. 
Fonte: Myers (1979). 
Prototipação 
Após algumas definições mais gerais, um protótipo do software é desenvolvido e apresentado para o 
cliente, para que ele faça uma avaliação. A partir daí, novos levantamentos de requisitos passam a ser 
realizados, para que o produto de software possa refinar-se, até atingir um nível aceitável de satisfação do 
usuário. Com isso, esse modelo proporciona uma visão mais real de como será o produto final ao longo do 
desenvolvimento. A Figura 2 mostra como se constitui o formato evolucionário do desenvolvimento a 
partir de protótipos que não chega a ser um modelo iterativo. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
Figura 2 - Formato evolucionário do desenvolvimento. 
Fonte: elaborada pelo autor. 
As desvantagens desse modelo é que padrões de qualidade geralmente são esquecidos e a documentação 
acaba sendo deixada de lado, o que dificulta a manutenção em longo prazo. Além disso, requisitos não 
funcionais (desempenho, robustez, confiabilidade, etc) dificilmente são observados durante a 
implementação. 
MODELOS ITERATIVOS 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
Modelos criados para flexibilizar o formato rígido do modelo em cascata, tornando possível que os 
requisitos de sistema sempre evoluam ao longo do projeto. Numa estratégia de dividir para conquistar, as 
iterações ocorrem diversas vezes até que o produto esteja adequado às necessidades e alterações do 
cliente. 
Modelo Iterativo e Incremental 
Neste modelo, os requisitos sempre evoluem ao longo do projeto dentro de um formato no qual todas as 
atividades ocorrem de forma iterada, em que as iterações no processo são representadas por 
minicascatas que, em dado momento, resultam em entregas que vão ocorrendo de forma incremental. 
Se pensássemos em um projeto de desenho no formato iterativo, numa primeira iteração se faria um 
esqueleto da imagem, na segunda iteração seria feito o esboço, depois o traço mais firme, o sombreado, e 
assim por diante até que na última iteração se tenha a arte final. Se fossemos montar um desenho de 
forma incremental, ele seria formado pela união dos vários pedaços acabados (incrementos), como se 
fossemos montando um quebra cabeça. 
Na Figura 3 é possível ver a estrutura do modelo iterativo incremental com suas iterações. 
Figura 3 – Modelo iterativo incremental. 
No modelo incremental, o usuário do software pode avaliar as entregas antecipadamente, os rumos do 
projeto podem ser corrigidos mais cedo, caso seja necessário, e com isso as chances do projeto todo 
fracassar são pequenas. As iterações seguintes podem ser replanejadas com base na avaliação dos 
incrementos disponibilizados anteriormente. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
Não confunda a palavra iterativo, que está conceitualmente presente nas abstrações 
dos modelos de ciclo de vida de software, com a palavra interativo. As duas palavras 
possuem significados distintos, e se forem trocadas, mudam todo o entendimento dos 
conceitos apresentados até agora. 
Por definição (MICHAELIS, 2017), interativo é tido como algo em que há interação. Na 
perspectiva da área de informática, está definido como um programa de computador 
que permite ao usuário ter interação por meio de troca de dados e informações. 
Iterativo, por sua vez, é o que se diz do verbo, substantivo ou frase que indica ações 
repetidas. Fonte: o autor. 
Modelo em Espiral 
O modelo espiral foi definido por Barry Boehm em 1988 para melhorar as características dos modelos 
apresentados anteriormente, propondo um formato para o desenvolvimento rápido de versões cada vez 
mais completas (PRESSMAN, 2011). 
Nesse modelo, foram acrescentados aspectos gerenciais, como planejamento e análise de riscos. Com 
isso, o modelo acaba sendo mais complexo de ser aplicado, exigindo certa experiência para a avaliação dos 
riscos. O modelo apresentado na Figura 4 nos permite observar uma divisão no processo de software em 
quatro atividades principais: Planejamento, Análise dos Riscos, Desenvolvimento e Avaliação pelo 
Cliente. 
Figura 4 – Modelo em Espiral 
Fonte: o autor. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
O processo se inicia a partir do centro da espiral e cada volta que é dada é uma nova iteração que ocorre e 
uma nova versão mais completa que é disponibilizada. Se um grau elevado de incertezas for identificado 
no quadrante onde se identifica os riscos, técnicas de prototipação e simulação entre outras, podem ser 
utilizadas para definir melhor os problemas e auxiliar no refinamento dos requisitos. Os loops da espiral 
podem ser definidos de acordo com o que for mais necessário. 
O NASCIMENTO DO SCRUM 
Na década de 80, um modelo de desenvolvimento de software bastante utilizado nas empresas de 
tecnologia era o modelo em cascata. Essa forma de trabalho, pouco adequado à realidade, fazia com que 
muitos projetos atrasassem ou até mesmo fracassassem completamente sem nunca sair do papel em 
função do elevado custo que alcançavam. 
Nessa mesma década, no ano de 1983, o analista de dados Jeff Sutherland foi convidado a trabalhar numa 
empresa chamada MidContinent Computer Services , com a missão de implantar um sistema de 
autoatendimento nas agências bancárias dos Estados Unidos, que se viam tomadas por filas de pessoas 
que necessitavam apenas sacar dinheiro (SUTHERLAND, 2014). 
Sutherland se deparou com um projeto em andamento, com centenas de programadores seguindo o 
modelo em cascata de desenvolvimento, sem conseguir fazer as entregas dentro do prazo e com um custo 
que seria de 30% a mais para cada caixa eletrônico, em comparação com a receita gerada. 
Diante da realidade encontrada, o analista de dados resolveu recomeçar tudo do zero; aquilo tudo parecia 
defeituoso demais para ser consertado. Dentro da empresa foi criada uma miniempresa, que tinha como 
objetivo específico o desenvolvimento do produto pela qual Sutherland foi contratado. A partir daí, alguns 
conceitos interessantes começaram a ser criados, os quais, mais tarde, serviriam de base para a criação do 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
Scrum, que veremos mais aprofundado ao longo desse estudo. 
A empresa criada passou a ser dirigida com um conceito de equipe, sendo dividida em subequipes. Além 
disso, foram criados outros conceitos, que mais tarde passariam a ser consolidados no Scrum, como o 
Product Owner , Product Backlog e Sprints semanais. A empresa passou a ter ótimos resultados com uma 
receita 30% maior que o custo e os caixas eletrônicos em bancos são utilizados até hoje nas agências. 
Após alguns anos, em 1993, Jeff Sutherland foi contratado por outra empresa para a entrega outro 
produto. Convicto de que o modelo em cascata não era um modelo de desenvolvimento eficiente e que 
era preciso outro modelo que garantisse maior produtividade, começou com sua equipe uma grande 
pesquisa por diversos documentos, livros e artigos até que o artigo de dois professores, chamados 
Hirotaka Takeuchi e Ikujiro Nonaka, publicado na Harvard Business Review em 1986 chamou demais a 
atenção e acabou servindo de base para a geração de ideias para uma nova metodologia. 
O artigo escritopelos japoneses fazia uma análise das equipes de projetos de grandes empresas japonesas 
e tecia uma forte crítica ao método em cascata utilizado, sustentando que era um método com muitas 
falhas. O argumento trazia que as melhores empresas se utilizavam do formato de desenvolvimento de 
sobreposição, com equipes multifuncionais trabalhando de forma autônoma, em que executivos atuavam 
como facilitadores interessados em retirar os obstáculos. 
Esse artigo norteou toda a forma de conduzir o processo de desenvolvimento do software, na qual 
Sutherland havia sido contratado para gerenciar. No ano de 1995, Jeff Sutherland publicou junto com Ken 
Schwaber um artigo chamado SCRUM Development Process , o qual consolidava todas as práticas desse 
novo método de trabalho. Com o passar do tempo, a metodologia foi passando por algumas adaptações, 
mas o principal segue conforme foi escrito, há mais de vinte anos. 
Muitos se perguntam de onde surgiu a palavra Scrum e por que ela foi utilizada para 
batizar esse método de trabalho para projetos de desenvolvimento. Não se trata de 
uma sigla e muito menos de alguma palavra ligada à área de tecnologia; muito pelo 
contrário, é um termo utilizado em um esporte coletivo. 
No artigo escrito por Hirotaka Takeuchi e Ikujiro Nonaka, que serviu de base para a 
formulação das ideias do Scrum, os professores japoneses compararam o trabalho em 
equipe com um time de rugby. A equipe avança enquanto a bola vai sendo passada por 
todo o time. Essa jogada, que ocorre após uma paralisação ou uma penalização, se 
chama Scrum. Esse conceito de trabalho em equipe, em que cada um faz sua parte para 
alcançar um objetivo maior, serviu de inspiração para dar nome a esse framework. 
Fonte: Sutherland (2014). 
Avançar 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial/atividades
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/unidade-1
https://getfireshot.com
Página inicial 
ATIVIDADES 
1. É possível dizer que a engenharia de software busca aplicar princípios científicos, métodos, modelos, 
padrões e teorias que permitem: 
a) Gerenciar, Planejar, Modelar, Projetar, Inflar, Medir e Analisar. 
b) Gerenciar, Planilhar, Modelar, Projetar, Implementar, Enfileirar, Analisar, Manter e Aprimorar um 
software. 
c) Gerenciar, Planejar, Modelar, Projetar, Flexibilizar, Impedir, Analisar, Manter e Aprimorar um software. 
d) Gerenciar, Planejar, Modelar, Projetar, Implementar, Medir, Analisar, Manter e Aprimorar um software. 
e) Gerenciar, Planejar, Cultivar, Projetar, Flexibilizar, Impedir, Alinhar, Modificar. 
2. Processo de desenvolvimento de software é: 
a) Uma estimativa de tempo utilizada durante a implementação do software. 
b) Um conjunto de atividades ordenadas capaz de gerar resultados que irão conduzir à produção de um 
produto de software. 
c) Uma atividade isolada capaz de gerar resultados que irão conduzir à produção de um produto de 
software. 
d) Uma etapa do ciclo de vida do software. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/atividades
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
e) Um conjunto de atividades desordenadas incapaz de gerar qualquer resultado que possa conduzir à 
produção de um produto de software. 
3. Preencha as lacunas do texto e identifique a alternativa correta: 
O modelo em cascata foi a __________ tentativa de se formalizar uma metodologia de desenvolvimento de 
software, tem um formato __________ similar a um processo de ___________ concebido no contexto industrial. 
a) Primeira, incremental, software. 
b) Segunda, sequencial, venda. 
c) Primeira, sequencial, manufatura. 
d) Última, sequencial, manufatura. 
e) Primeira, espiral, incrementos. 
Resolução das atividades 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/atividades
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial/resumo
Página inicial 
RESUMO 
Neste estudo, conseguimos compreender um pouco do porquê da Engenharia de Software, quais seus 
objetivos e como ela busca manter a qualidade do desenvolvimento do produto de software. Foi possível 
observar que, junto com essa engenharia, existe o processo de software, que possui um ciclo de atividades 
comuns nos projetos. 
Os processos de software possuem, portanto, ciclos de vida, que dizem respeito ao conjunto de atividades 
desempenhadas ao longo do desenvolvimento do software, desde o planejamento até a evolução. A forma 
como as atividades dentro do ciclo de vida ocorrem varia conforme o modelo de ciclo de vida de software 
adotado para a execução do projeto. 
Dos modelos apresentados, destacam-se os modelos clássicos e os modelos evolucionários, iterativos e 
incrementais. O modelo clássico, um pouco mais distante da realidade, tem suas atividades ocorrendo de 
forma sequencial em um fluxo similar a uma linha de produção de fábrica. O modelo iterativo e 
incremental deixa o desenvolvimento mais leve, ocorrendo em iterações, que passam pelas atividades, e 
vão resultando em entregas para o usuário ao longo do tempo. 
Em meio a todo o cenário apresentado, Jeff Sutherland se viu como líder de um projeto de 
desenvolvimento, com equipes trabalhando em um modelo em cascata, sem apresentar o resultado 
esperado. O projeto não tinha perspectiva de entrega e o custo se tornava cada vez maior. Foi então que 
surgiu a inquietação de criar um novo modelo de gerência de projetos, que pudesse se adaptar à realidade 
das equipes de desenvolvimento e às necessidades do cliente. 
A ideia extraída de dentro de um modelo japonês abriu as portas para Sutherland alcançar novos 
resultados em menos tempo, com um custo mais baixo e com maior satisfação do cliente. Junto com Ken 
Schwaber, Jeff Sutherland escreveu as ideias que servem até hoje para milhares de projetos espalhados 
pelo mundo inteiro. 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/resumo
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial/eu-indico
Página inicial 
Material Complementar 
Leitura 
A Arte de Fazer o Dobro na Metade do Tempo 
Autor: Jeff Stherland 
Editora: Leya Casa da Palavra 
Sinopse : Se você já foi surpreendido por quão rápido o 
mundo está mudando, Scrum é uma das razões. Para 
aqueles que acreditam que deve haver uma maneira mais 
eficiente de se fazer as coisas, este é um livro sobre o 
processo de gestão que está mudando a maneira como 
vivemos. Desde o advento do método, já foram registrados 
ganhos de produtividade de até 1.200%. Tecida com 
insights de artes marciais, tomadas de decisão judicial, 
combate aéreo avançado, robótica e muitas outras 
disciplinas, Scrum é sempre fascinante. Seja para inventar 
uma tecnologia pioneira ou para estabelecer os alicerces de 
prosperidade de uma família. 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/eu-indico
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial/refer%C3%AAncias
Página inicial 
REFERÊNCIAS 
MICHAELIS. Dicionário Brasileiro da Língua Portuguesa. Disponível em: http://michaelis.uol/ . Acesso em: 
5 ago. 2017. 
MYERS, G. J. The art of software testing. New York: John Wiley & Sons, 1979. 
PRESSMAN, R. S. Software engineering: a practitione’s approach. 5. ed. Boston: Mc Graw-Hill, 2001. 
SOMERVILLE,I. Engenharia de Software. 8. ed. São Paulo: Pearson, 2010. 
SUTHERLAND, J. Scrum: a arte de fazer em dobro do trabalho na metade do tempo. São Paulo: Leya, 
2014. 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/refer�ncias
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
http://www.google.com/url?q=http%3A%2F%2Fmichaelis.uol%2F&sa=D&sntz=1&usg=AFQjCNGHvFY_IxAIsuiUn24c_UK4IOU-Vg
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial/aprofundando
Página inicial 
APROFUNDANDO 
Vamos usar o exemplo de um projeto de desenvolvimento de um automóvel como se a demanda do 
veículo em questão fosse a demanda de desenvolvimento de um produto de software. Então vamos lá, 
pense em um cenário onde você está à frente de uma equipe de desenvolvimento, e um cliente te passa a 
missão de desenvolver um automóvel confortável, com boa aerodinâmica, que chegue a uma velocidade 
alta e que tenha um ronco bonito, capaz de chamar a atenção por onde passa. Com a descrição 
apresentada, um modelo começa a ficar claro na cabeça do analista, conforme a figura 1. 
A partir daí os requisitos passam a ser refinados e são definidas outras características do veículo como 
cor, velocidade máxima, número de marchas, entre outras. 
Você como gerente do projeto opta por um modelo de desenvolvimento em cascata. Ou seja, com base 
nos requisitos levantados e no planejamento feito, o desenvolvimento se inicia com previsão de parar 
apenas quando a máquina de corrida do cliente estiver concluída. O projeto segue, portanto, um fluxo 
sequencial, ou seja, uma vez passada as etapas de requisitos e projeto, não existe mais a possibilidade de 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/aprofundando
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
levantar novas características do produto. 
O projeto segue por longos meses, a expectativa em cima do retorno do cliente se torna alta a medida que 
o custo do projeto vai ficando cada vez maior. Faltando poucas semanas para a conclusão do 
desenvolvimento, o cliente informa que devido à alta no preço dos combustíveis ele gostaria que o veículo 
fosse econômico. 
O veículo projetado até ali não havia sido projetado para ser um dos mais econômicos da categoria, o que 
acaba gerando um desconforto com o cliente e tal situação precisa ser contornada. 
Passado mais alguns dias o cliente informa que já comprou o capacete para usar o veículo e que não vê a 
hora de receber o produto. 
O cliente informa que sua expectativa em relação ao produto era de receber uma moto nova uma vez que 
no condomínio onde mora só teria vaga para mais um veículo de duas rodas. Por não conhecer muito de 
automóveis, o cliente não sabia que precisaria informar que se tratava de um veículo de duas rodas. 
A situação descrita acima parece um pouco exagerada, mas casos como estes ocorrem diariamente no dia- 
a-dia do desenvolvimento de software. Não é raro um investimento, de milhares de reais, acabar indo por 
água abaixo em função de uma mudança no ambiente nos negócios do cliente ou por conta de um 
levantamento errado de requisitos. 
Se voltarmos no exemplo do automóvel e substituirmos o modelo de desenvolvimento escolhido pelo 
modelo iterativo e incremental utilizado pelo Scrum, em uma primeira iteração ocorrida nas primeiras 
semanas, seria disponibilizado para o cliente um primeiro incremento, que poderia ser apenas a carcaça 
do veículo com as quatro rodas, assim o cliente pode movimentá-la e fornecer um feedback de como está 
até ali e como deveria ser o produto. 
No modelo iterativo, ao final da primeira iteração o erro no levantamento de requisitos seria identificado 
com a primeira entrega e o projeto poderia ser corrigido ao final de um primeiro ciclo de desenvolvimento. 
Assim, o custo de investimento perdido seria baixo em comparação com o valor investido em um cenário 
onde todo o veículo tivesse sido desenvolvido, para ao final descobrir o erro. 
Além disso, no modelo iterativo, uma vez que os requisitos são levantados novamente e o planejamento é 
refeito a cada iteração, alterações nas definições do produto e adições de escopo costumam ser atendidas 
mais facilmente. 
No caso da solicitação do cliente para que o veículo fosse mais econômico, possivelmente daria tempo de 
adaptar o projeto para melhorar o desempenho do consumo de combustível, sem gerar grandes custos na 
entrega final. 
Pensar que os requisitos em um projeto seguirá igual do início ao fim é um terrível engano, a ideias do 
cliente mudam, o mercado aonde ele esta inserido muda e consequentemente essas mudanças causam 
impacto e alterações na necessidade do produto que está sendo solicitado. Raramente você conseguirá 
levantar requisitos e desenvolver em uma única rodada sem que se tenham retrabalhos exceto se o 
projeto for consideravelmente pequeno. 
Esperamos que o exemplo tenha servido para explicar melhor a diferença do modelo iterativo e 
incremental utilizado pelo Scrum e o modelo em cascata, sobretudo frente a uma situação tão comum 
vivida nos ambientes de desenvolvimento. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/aprofundando
https://getfireshot.com
PARABÉNS! 
Você aprofundou ainda mais seus estudos! 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/aprofundando
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial/editorial
Página inicial 
EDITORIAL 
DIREÇÃO UNICESUMAR 
Reitor Wilson de Matos Silva 
Vice-Reitor Wilson de Matos Silva Filho 
Pró-Reitor de Administração Wilson de Matos Silva Filho 
Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva 
Pró-Reitor de Ensino de EAD Janes Fidélis Tomelin 
Presidente da Mantenedora Cláudio Ferdinandi 
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ . Núcleo de Educação a 
Distância; FREITAS, Marcos Joaquim de. 
Scrum. Marcos Joaquim de Freitas. 
Maringá-Pr.: UniCesumar, 2017. 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/editorial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
25 p. 
“Pós-graduação Universo - EaD”. 
1. Scrum. 2. Software. 3. EaD. I. Título. 
CDD - 22 ed. 658 
CIP - NBR 12899 - AACR/2 
Pró Reitoria de Ensino EAD Unicesumar 
Diretoria de Design Educacional 
Equipe Produção de Materiais 
Fotos : Shutterstock 
NEAD - Núcleo de Educação a Distância 
Av. Guedner, 1610, Bloco 4 - Jardim Aclimação - Cep 87050-900 
Maringá - Paraná | unicesumar.edu.br | 0800 600 6360 
Retornar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum1/p�gina-inicial/editorial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum1/p%C3%A1gina-inicial
Página inicial 
CONHECENDO 
CONCEITOS DO 
SCRUM 
Professor : 
Esp. Marcos Joaquim de Freitas 
Objetivos de aprendizagem 
Conhecer como surgiu e quais são os conceitos, valores e princípios dos métodos ágeis de 
desenvolvimento de software. 
Aprender os conceitos gerais do framework de processo Scrum utilizado para o desenvolvimento de 
produtos. 
Conhecer os artefatos que são gerados ao longo dos projetos gerenciados por meio do Scrum. 
Compreender os papéis que compõe o Time Scrum e quais suas principais responsabilidades. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
Plano de estudo 
A seguir, apresentam-se os tópicos que você estudará nesta unidade: 
Métodos Ágeis de Desenvolvimento. 
Visão Geral do Scrum.Os Artefatos do Scrum. 
Os Papéis do Scrum. 
Introdução 
Em alguns momentos nos deparamos com algumas situações que nos obrigam a repensar toda nossa 
forma de agir, nos levado a querer fazer diferente, criar e inovar. A máxima que nos diz que você não pode 
esperar resultados diferentes se fizer sempre as mesmas coisas pode ser entendida facilmente no dia a dia 
do desenvolvimento de software. 
Mudar não é uma tarefa fácil, mas foi exatamente o que fez Jeff Sutherland junto com outros especialistas 
em desenvolvimento de software. Em meio a padrões de desenvolvimento pesados, rígidos, que não 
estavam adaptados à realidade das equipes de desenvolvimento de software, era preciso inovar e propor 
novos conceitos a partir de um formato mais dinâmico e com novos valores. E foi propondo esse novo 
modelo que Sutherland e mais outros 16 desenvolvedores lançaram o manifesto ágil, que trazia conceito 
até hoje aplicados por meio de metodologias ágeis como o Scrum. 
O Scrum pode ser utilizado em qualquer tipo de processo, e mediante seus princípios, pilares, papéis, 
eventos e artefatos, obtém-se o resultado do produto que vai sendo desenvolvido e disponibilizado pelos 
incrementos. Esse modelo mais leve e dinâmico permite que os rumos do desenvolvimento em curso 
possam ser constantemente avaliados e corrigidos caso tenham ocorrido erros no entendimento do 
projeto ou até mesmo tenha ocorrido alterações de cenários e mudanças de prioridades. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial
https://getfireshot.com
A partir de agora, iremos adentrar um pouco nos métodos ágeis de desenvolvimento e no framework 
proposto há mais de 15 anos, que até hoje vem sendo utilizado para diversos tipos de projetos dentro de 
inúmeras organizações espalhadas pelo mundo inteiro. Você é convidado a conhecer um pouco da história 
do surgimento dos métodos ágeis bem como um pouco dos aspectos do Scrum no seu uso para projetos 
gerenciamento de projetos. 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial/unidade-2
Página inicial 
MÉTODOS ÁGEIS DE 
DESENVOLVIMENTO 
Com o passar do tempo, as metodologias de desenvolvimento de software foram evoluindo e com elas 
uma série de processos e documentações foram sendo estabelecidos. Na angústia de tornar esse 
desenvolvimento de software com mais flexibilidade, dinamismo e com o foco principal na entrega e na 
satisfação do usuário, foi criado o conceito método ágil. 
Esse conceito de metodologia não desconsidera a importância de processos estabelecidos, da 
documentação e dos padrões, no entanto, reestabelece as prioridades e o foco do projeto, que passa a ser 
no código e, baseado nas abordagens iterativas, tem o objetivo de entregar o produto de software 
funcionando o mais rápido possível. 
O Manifesto e os Valores Ágil 
No ano de 2001, um grupo de desenvolvedores se reuniu no norte dos Estados Unidos a fim de debater 
novos paradigmas para o desenvolvimento de software, que ia contra os conceitos da engenharia de 
software tradicional (FOWLER, 2017). O encontro contou com a presença de dezessete defensores das 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
novas ideias para o desenvolvimento de software, dentre eles alguns criadores de metodologias já 
difundidas no mercado, como Jeff Sutherland e Ken Schwaber, fundadores do Scrum. 
Ao longo da reunião, o entendimento em relação aos conceitos básicos sobre o desenvolvimento de 
software foi consolidado, os métodos – então chamados de métodos leves – passaram a ser chamados de 
métodos ágeis e um documento foi escrito e publicado com o nome de manifesto ágil. No Quadro 1 estão 
os valores apresentados no manifesto. 
Quadro 1 – Valores do Desenvolvimento Ágil de Software. 
Fonte: Beck et al., (2001). 
Para o desenvolvimento ágil, ainda que os itens da coluna à direita do Quadro 1 tenham valor, se valoriza 
mais os itens da coluna à esquerda. 
O manifesto ágil representou tudo o que aqueles especialistas defendiam em relação ao desenvolvimento 
de software. Os itens foram redigidos para fazer uma clara diferenciação das opiniões apresentadas em 
contraponto aos conceitos mais tradicionais do desenvolvimento de software. 
Princípios Ágeis 
Uma vez decidido lançar os manifesto e definidos os valores, foi a vez de consolidar princípios básicos de 
forma colaborativa ao longo dos dois meses seguintes, de forma que representassem todos os ideais dos 
desenvolvedores ágeis. 
Os princípios que estão por trás do manifesto ágil estão apresentados no Quadro 2 a seguir: 
Quadro 2 - Princípios por trás do Manifesto Ágil 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
Fonte: Beck et al., (2001). 
Após a reunião que culminou no manifesto Ágil, alguns dos dezessete desenvolvedores, 
que lá estavam reunidos, mais outros que foram agregados posteriormente, queriam 
uma organização mais permanente, que pudesse promover os métodos ágeis. Dessa 
forma, uma associação sem fins lucrativos foi criada, no final de 2001, e recebeu o 
nome de Agile Alliance. A Agile Alliance tem o objetivo de propagar princípios e 
práticas de desenvolvimento ágil, apoiando quem explora e aplica esses princípios no 
desenvolvimento de software. Para isso, existem diversas iniciativas que incluem 
workshops, conferências e projetos de pesquisa acadêmica, além de um trabalho por 
programas que funcionam de forma bastante independente e passa pela monitoria de 
um comitê que os re-aprovam anualmente. Esse trabalho tem como vitrine a 
conferência ágil anual. No Brasil, existe uma sede da associação em Fortaleza, com 
representantes brasileiros. 
Para saber mais, acesse: https://www.agilealliance.org/ . 
Fonte: Agile Alliance ([2017], on-line)1 . 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
https://www.google.com/url?q=https%3A%2F%2Fwww.agilealliance.org%2F&sa=D&sntz=1&usg=AFQjCNFW1Ex531hSzTxnsnjx2rOYOnwlnA
VISÃO GERAL DO SCRUM 
Embora o Scrum tenha sido escrito por desenvolvedores de software, como visto anteriormente, ele se 
baseia em técnicas utilizadas na indústria japonesa. Portanto, é uma ferramenta que pode ser utilizada 
para qualquer projeto que envolva pessoas com um objetivo específico a ser alcançado. 
O Scrum pode ser definido como um framework do qual as pessoas podem tratar e resolver problemas. 
Vêm sendo usado para o desenvolvimento de produtos complexos desde o início da década de 90, com 
foco no gerenciamento das equipes preocupadas na organização dos processos e no modo como as 
atividades devem ser executadas (SUTHERLAND; SCHWABER, 2016). 
Esse framework é composto por times associados a papéis, eventos, artefatos e regras. Cada componente 
tem seu propósito específico e é fundamental para o uso e o sucesso do Scrum. Segundo o próprio criador, 
o Scrum aplicado de forma correta gera de modo geral uma vantagem na produtividade de 300% a 400% 
para o projeto, se comparado com outros modelos mais tradicionais, que não utilizam métodos ágeis. 
O Scrum segue um modelo iterativo e incremental, em que os requisitos (funcionalidades dos clientes) são 
listados em um artefato chamado Product Backlog, e o produto evolui a partir de Sprints, que vão gerando 
os incrementos e são disponibilizados para o cliente. A Figura 1 nos mostra uma visão geral da base do 
funcionamento do Scrum. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
Figura 1 – Funcionamento do Scrum. 
Pilares do Scrum 
Esse framerwork é baseado no empirismo. O fato de ter sido baseado nas experiências práticas faz comque ele esteja muito mais adequado à realidade, visto que conhecimento empírico é o conhecimento 
adquirido sobre o tema a partir das experiências vividas, o que faz com que as tomadas de decisões sejam 
baseadas no que já é conhecido pela prática. 
O método empírico está baseado em três pilares que apoiam esse controle de processo: 
O Scrum é iterativo e incremental, por isso o usuário pode testar os incrementos que vão sendo 
disponibilizados ao longo do processo, as iterações vão variando conforme o feedback recebido e os 
rumos do projeto vão sendo corrigidos de forma imediata de acordo com o replanejamento realizado. 
Esse modelo aumenta de forma considerável as chances de sucesso de um projeto, diferente de um 
modelo em cascata, no qual o usuário recebe o sistema completo ao final de todo o processo com base nos 
requisitos levantado lá no início, na fase de levantamento. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
Valores do Scrum 
No Scrum, as equipes se auto-organizam para maximizar a comunicação e reduzir a supervisão a partir do 
momento que realizam os eventos, seguem os papéis e produzem os artefatos do Scrum. Estes passam a 
desenvolver e praticar os valores do Scrum de forma colaborativa uns com os outros, havendo um 
desenvolvimento natural dos times em direção à agilidade e eficiência. Além disso, por meio desses 
valores, o processo fica fortalecido em cima dos pilares de transparência, inspeção e adaptação, 
fortalecendo a confiança do time. 
As pessoas possuem um papel fundamental para que esse framework dê certo e seja alcançada a maior 
produtividade possível. Todos os stakeholders (partes interessadas do projeto) devem trabalhar para que 
o Time Scrum possa alcançar os objetivos e encarar os desafios. O Scrum apresenta os seguintes valores: 
Coragem: É necessário que o Time Scrum tenha coragem para fazer o que é certo e enfrentar 
problemas difíceis. 
Foco: Todos focam no trabalho da Sprint e nos objetivos gerais do Time Scrum 
Comprometimento: As pessoas passam a se comprometer pessoalmente para alcançar os objetivos do 
Time Scrum. 
Respeito: Os membros do Time Scrum respeitam uns aos outros, pois acreditam que todos são 
capazes e independentes. 
Abertura: O Time Scrum e seus stakeholders concordam em estarem abertos a todo o trabalho e 
dispostos a vencer os desafios. 
Em projetos de desenvolvimento de software é comum utilizar a palavra stakeholders 
para se referir às partes interessadas do projeto. A definição de partes interessadas 
(stakeholder) pode ser considerada como sendo qualquer pessoa ou organização que 
está ativamente envolvida em um projeto, ou aqueles que seus interesses podem ser 
afetados positiva ou negativamente pela execução do mesmo. 
Fonte: Gerardi (2012). 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
OS ARTEFATOS DO SCRUM 
Os artefatos do Scrum são documentações geradas ao longo do processo e serve para aumentar a 
transparência das informações que devem circular ao longo do projeto. Serão apresentados a seguir os 
seguintes artefatos: Product Backlog, Sprint Backlog, Burndown de Versão e Burndown da Sprint. 
Product Backlog 
O Backlog do Produto é uma lista ordenada de responsabilidade do Product Owner, cujos itens são 
extraídos a partir do levantamento de requisitos. Nessa lista deve conter todas as demandas de 
desenvolvimento do produto em ordem de prioridade. Esse artefato nunca estará fechado, ele parte de 
um levantamento inicial com os itens melhor entendidos, mas a qualquer momento é possível acrescentar 
novos itens ao Backlog, basta que isso seja identificado como uma necessidade do projeto (SCHWABER, 
2009). 
O Scrum dentro de sua característica de adaptação precisa que o Product Owner esteja aberto a uma 
reavaliação constante do Product Backlog. Acrescenta-se a isso o fato de que uma vez que o produto 
começa a ser disponibilizado e testado pelo mercado, feedbacks dos usuários fazem com que, 
consequentemente, surjam novas demandas que necessariamente devem compor o Backlog do Produto. 
Os itens do Backlog do Produto devem conter informações, características, funções, tecnologias, 
melhorias e correções, podem ser representados por meio de Histórias do Usuário com auxílio de Casos 
de Uso. É necessário que cada item possua uma descrição, uma prioridade e uma estimativa. O Time de 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
Desenvolvimento contribui com as informações dos itens e decide quando o refinamento da lista já está 
de acordo. 
A prioridade dos itens do Backlog do Produto leva em conta risco, valor e necessidade dentro do escopo 
do produto. Quanto mais alta a prioridade de um item, mais urgente é o seu desenvolvimento e maior 
deve ser seu grau de detalhamento. Quanto menor a prioridade do item, menor deve ser a preocupação 
com seu detalhamento. Isso evita retrabalhos futuros, pois se um item for ser desenvolvido mais adiante, 
até seu requisito pode ter sido alterado em função de uma mudança no projeto com alterações de 
requisitos de itens que serão desenvolvidos mais adiante. 
Burndown do Produto 
Esse gráfico é responsável por mostrar o quanto de estimativa de esforço, geralmente medido em 
quantidade de Sprints, ainda é necessário para concluir o Backlog do Produto na linha do tempo. Essas 
informações de progresso do Product Backlog devem estar disponíveis para todas as partes interessadas 
e o Product Owner é responsável por mantê-las sempre atualizadas no gráfico. 
Ainda que esse Gráfico de Burndown seja importante para situar e passar para os stakeholders um 
panorama geral do andamento do projeto, ele não deve sobrepor o conceito empírico no qual o Scrum se 
baseia nem o dinamismo proposto pelas metodologias ágeis. As estimativas de tempo devem ser 
constantemente reavaliadas e atualizadas conforme as alterações que devem ocorrer ao longo do tempo 
no Backlog do Produto. 
Sprint Backlog 
O Backlog da Sprint é uma lista de tarefas que contém tudo o que deve ser desenvolvido ao longo da 
Sprint para que ao final dela seja disponibilizado um incremento do produto. Essas tarefas são extraídas 
do Backlog do Produto pelo próprio Time de Desenvolvimento que se auto-organiza para realizar o 
esforço definido para a Sprint. 
Após iniciada a Sprint, o Time de Desenvolvimento pode acabar verificando que é necessário acrescentar 
itens no Backlog da Sprint. Essa necessidade pode ocorrer tanto pelo fato do Time não ter se dado conta 
da prioridade de um item antes de iniciar o desenvolvimento, quanto pelo surgimento de um novo 
requisito que não havia sido relatado inicialmente. 
A Figura 2 demonstra como é a sequência dos artefatos, com o Backlog do Produto sendo criado pelo 
Product Owner, com a colaboração e a influência dos stakeholders até a definição do Backlog da Sprint 
extraído do Backlog do Produto pelo Time de Desenvolvimento. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
Figura 2 – Sequência dos artefatos. 
Burndown da Sprint 
O Burndown da Sprint é o gráfico da quantidade de esforço que resta para concluir o Backlog da Sprint 
que pode ser desenhado a mão em uma folha grande de papel para ser exibida no local de trabalho do 
Time. Esse somatório da quantidade de trabalho restante pode ser atualizado diariamente na linha que 
cruza o gráfico para que o time possa gerenciar seu progresso dia a dia. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
OS PAPÉIS DO SCRUM 
No Scrum, existem alguns papéis que são responsáveis por fazer com que o processo de fato aconteça 
dentro do framework. Esses papéis estão dentro do conceito de Time Scrum, o qual é composto pelo 
Product Owner, pelo Time de Desenvolvimento e pelo Scrum Master. Todos atuam para o sucesso do 
projetodentro das suas responsabilidades. Considera-se que o Time de Desenvolvimento é a parte mais 
comprometida no projeto, enquanto que os demais estão apenas envolvidos. A seguir, veremos 
detalhadamente a função de cada um dentro do funcionamento do Scrum. 
Product Owner 
Existe uma velha máxima que diz que o cachorro que possuí mais de um dono tende a morrer de fome. No 
Scrum nós temos a figura do dono do produto que é responsável por definir os itens do produto a ser 
entregue ao final do projeto. Ou seja, o Product Owner é o único responsável por gerenciar o backlog do 
produto, garantindo que ele seja visível por todos do Time Scrum. O dono do produto é responsável por 
fazer a priorização dos itens que devem ser desenvolvido e o time deve respeitar essa priorização não 
realizando o desenvolvimento de qualquer outro item que não esteja priorizado por ele (SCHWABER, 
2009). 
O Product Owner deve ordenar os itens do produto a fim de buscar o melhor aproveitamento possível 
para alcançar as metas propostas. Ele pode ouvir as sugestões de outras pessoas ou até mesmo delegar 
essa função para o Time de Desenvolvimento, sem deixar de ser o responsável pelos trabalhos. O Dono do 
Produto deve garantir que o backlog do produto seja visível, transparente e bastante claro, garantindo 
que o Time de Desenvolvimento tenha entendido os itens de forma adequada. 
Development Team 
O Time de Desenvolvimento é responsável por transformar os itens do Product Backlog em entregáveis. 
Em pesquisa realizada em mais de sete mil projetos, o tamanho ideal para uma equipe obter a maior 
produtividade é de cinco a sete pessoas (COHN, 2011). No Scrum, esse também é o número indicado para 
a composição do Time de Desenvolvimento, podendo variar entre 5 e 9 (SCHWABER, 2009). É levado em 
consideração que times pequenos demais perdem pela falta de interação resultando na perda da 
produtividade, ao passo que times com mais de nove pessoas aumenta a complexidade do gerenciamento 
da equipe além de dificultar a disseminação do conhecimento. Os times se auto-organizam e descobrem 
por si como transformar o Backlog do Produto em incrementos, cada membro deve aplicar seu 
conhecimento e suas habilidades para se chegar à entrega final. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
Os times também são multidisciplinares, ou seja, as competências podem variar dentro dos membros. No 
exemplo do ciclo de desenvolvimento de software os programadores, testadores e desenvolvedores de 
interfaces variam dentro dos membros do time. As alterações da composição do time podem ocorrer 
somente ao final da Sprint. 
O Scrum Master 
O Scrum Master deve garantir que o Time Scrum esteja adequado aos valores do Scrum, que as práticas 
estão sendo aplicadas e as regras estejam de acordo. Esse papel deve levar o time a ser mais produtivo e a 
desenvolver com mais qualidade, além de auxiliar também no autogerenciamento e na 
interdisciplinaridade da equipe. 
Esse papel não deve ser confundido com um papel de gerente para o time, até porque não existe gerente 
para o Time de Desenvolvimento; vale lembrar que as pessoas devem se auto-organizar, e o Scrum Master 
atuar na facilitação disso. 
O Scrum Master é responsável pela devida aplicação das práticas do Scrum, ele deve remover os 
obstáculos, facilitando os resultados e garantindo a plena funcionalidade e produtividade da equipe. Deve 
atuar como um escudo, impedindo interferências externas no Time. 
O Scrum Master deve ensinar o Product Owner a como fazer seu trabalho, passando técnicas para o 
gerenciamento do Backlog do Produto. Caso o Product Owner não saiba garantir os valores do Scrum, 
essa atribuição passa para o Scrum Master, que fica como o responsável. 
Na perspectiva da empresa, o Scrum Master auxilia na liderança e no treinamento para aplicação do 
Scrum, planeja implementações, tem contato direto com os patrocinadores, ajuda os funcionários e os 
stakeholders a compreender e desenvolvimento por meio deste framework, marca reuniões, realiza 
mudanças necessárias para o aumento de produtividade e trabalha com outros Scrum Master para 
garantir o sucesso da aplicação do Scrum nas organizações. 
Os artefatos gerados no Scrum são: Product Backlog (Backlog do Produto), Gráfico de 
Burndown do Produto, Sprint Backlog, Burndown da Sprint. Além disso, outros 
recursos como o quadro Kanban e as Histórias de Usuário podem ser utilizados. 
Os papéis, por sua vez, que compõe o Time Scrum são: Product Owner (Dono do 
Produto), Development Team (Time de Desenvolvimento), Scrum Master (Mestre 
Scrum). 
Avançar 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial/atividades
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/unidade-2
https://getfireshot.com
Página inicial 
ATIVIDADES 
1. O Scrum pode ser definido como: 
a) Um framework que é usado para o desenvolvimento de produtos complexos. 
b) Uma ferramenta case. 
c) Um software utilizado por equipes de desenvolvimento. 
d) Um conceito que jamais conseguiu ser aplicado. 
e) Um modelo de ciclo de vida de software. 
2. O Scrum segue o modelo: 
a) Em cascata. 
b) De prototipagem. 
c) Iterativo e Incremental. 
d) O modelo formal. 
e) O Modelo Clássico. 
3. Quais os valores do Scrum: 
a) Coragem, Foco, Comprometimento, Respeito, Abertura. 
b) Coragem, Facilidade, Comprometimento, Respeito, Leveza. 
c) Coragem, Facilidade, Comprometimento, Rapidez, Leveza. 
d) Coragem, Facilidade, Comprometimento, Rapidez, Custo. 
e) Coragem, Foco, Compreensão, Respeito, Leveza. 
Resolução das atividades 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/atividades
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial/resumo
Página inicial 
RESUMO 
Um grupo de desenvolvedores, os quais compartilhavam dos mesmos ideais em relação ao 
desenvolvimento de software, reuniu-se para definir valores e princípios que refletissem a metodologia 
utilizada em projetos de software, até então chamada de métodos leves. A conclusão de tudo isso foi o 
lançamento do Manifesto Ágil, assinado por 17 especialistas, que apresentou valores e princípios para o 
desenvolvimento ágil que passou a se mostrar mais eficiente do que os métodos tradicionais de 
desenvolvimento. 
O Scrum faz parte da família ágil e tem como base o modelo iterativo e incremental que, a partir de 
Sprints, realiza entregas frequentes para o usuário. O framework possui como pilares transparência, 
inspeção e adaptação e suas equipes se auto-organização com olhar voltado para os valores (coragem, 
foco, comprometimento, respeito e abertura). 
Ainda que o Scrum não possua uma variedade muito extensa de documentação, existem alguns artefatos 
que são produzidos ao longo do processo todo de desenvolvimento. Um dos artefatos gerados é o Product 
Backlog que é uma lista de itens priorizados e que representam todas as demandas, em linhas gerais, do 
produto que está em desenvolvimento. Um gráfico chamado de Burndown mostra quantas Sprints ainda 
são necessárias para concluir o Backlog do Produto. 
Outro artefato importante, o Sprint Bcklog, pode ser resumindo como sendo uma lista daquilo que deve 
ser desenvolvido em determinado ciclo de desenvolvimento, ou seja, em uma Sprint. Um gráfico 
Brundown da Sprint também é utilizado para demonstra quanto resta para concluir a Sprint. 
No Scrum os papéis são fundamentais para que o projeto tenha sucesso a partir dos conceitos do 
framework. O Product Owner é o dono do produto e é responsável por definir e priorizar os itens do 
Product Backlog. O Time de Desenvolvimentoé responsável por “meter a mão na massa” e codificar 
aquilo que foi priorizado, enquanto que o Scrum Master é o responsável por garantir o bom andamento do 
projeto, além de retirar obstáculos que possam estar atrapalhando o Time de Desenvolvimento 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/resumo
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial/eu-indico
Página inicial 
Material Complementar 
Na Web 
Nesse vídeo, os dois criadores do Scrum, Jeff Stherland e 
Ken Schwaber, trazem pontos relevantes e atualizados do 
Guia do Scrum escrito por eles, e contam porque decidiram 
criar o Scrum, como eles usaram ao longo do tempo e para 
onde o Scrum está indo. 
Acesse 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/eu-indico
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://www.youtube.com/watch?v=0hRZffDD1ec
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial/refer%C3%AAncias
Página inicial 
REFERÊNCIAS 
BECK, K; et al. Agile Manifesto. Disponível em: http://agilemanifesto.org/ . Acesso em: 20 ago. 2017. 
COHN, M. Desenvolvimento de Software com Scrum: aplicando métodos ágeis com sucesso. Porto 
Alegre: Bookman Companhia Editora Ltda., 2011. 
FOWLER, M. Writing The Agile Manifesto. Disponível em: https://martinfowler.com/articles/ . Acesso 
em: 20 ago. 2017. 
GERARDI, B. Gerenciamento de Projetos sem Crise. Tradução: Rafael Zanolli. São Paulo: Novatec 
Editora; New York, EUA: Apress Inc, 2012. 
SCHWABER, K. Guia do Scrum. Disponível em: http://www.trainning.com.br/download/GUIA_ . Acesso 
em: 20 ago. 2017. 
SUTHERLAND, J.; SCHWABER, K. Um guia definitivo para o Scrum: a regra do jogo. Disponível em: 
https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Portuguese-Brazilian.pdf . 
Acesso em: 20 ago. 2017. 
REFERÊNCIAS ON-LINE 
¹ Em: https://www.agilealliance.org/ . Acesso em 20 ago. 2017 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/refer�ncias
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
http://www.google.com/url?q=http%3A%2F%2Fagilemanifesto.org%2F&sa=D&sntz=1&usg=AFQjCNF1DPUAQJzfAMFkFo6-GDfBRXHabQ
https://www.google.com/url?q=https%3A%2F%2Fmartinfowler.com%2Farticles%2F&sa=D&sntz=1&usg=AFQjCNGzQosOtbJJ9AmRVRA4fFyLGclVew
http://www.google.com/url?q=http%3A%2F%2Fwww.trainning.com.br%2Fdownload%2FGUIA_&sa=D&sntz=1&usg=AFQjCNHg428HO3KHapmNdhK4IiyY9Itcog
https://www.google.com/url?q=https%3A%2F%2Fwww.scrumguides.org%2Fdocs%2Fscrumguide%2Fv2016%2F2016-Scrum-Guide-Portuguese-Brazilian.pdf&sa=D&sntz=1&usg=AFQjCNEDvfm2Qd-SebVrJ0i9M2EQGYl0fg
https://www.google.com/url?q=https%3A%2F%2Fwww.agilealliance.org%2F&sa=D&sntz=1&usg=AFQjCNFW1Ex531hSzTxnsnjx2rOYOnwlnA
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial/aprofundando
Página inicial 
APROFUNDANDO 
Além de Scrum, Kanban e XP, existe uma série de métodos de desenvolvimento de software que são 
considerados da família ágil e são utilizados nos mais diferentes ambientes espalhados pelas grandes 
empresas. 
Com o passar do tempo esse conceito de desenvolvimento mais leve foi sendo difundido e cada vez mais 
metodologias de desenvolvimento foram sendo conhecidas. Vamos ver a partir de agora alguns dos 
principais métodos que pertencem à família ágil. 
Feature-Driven Developmento (FDD) 
O Feature-Driven Development ou o Desenvolvimento Guiado por Funcionalidades tem como foco 
modelar e planejar, através do uso de diagramas, as características e funções que irão trazer valor para o 
cliente (PALMER; FELSING, 2002). O FDD possui um conjunto de práticas que definem e guiam o 
funcionamento do método. Essas práticas são: 
Modelagem Orientada a Objetos de Domínio: Um diagrama de classes com os objetos de domínio 
deve ser modelado para definir a arquitetura. 
Desenvolvimento por Funcionalidades: O desenvolvimento tem por base as funcionalidades para o 
cliente. 
Propriedade Individual: As classes criadas por um desenvolvedor pertencem apenas aquele 
desenvolvedor e ele é responsável por alterá-la. 
Equipes por Funcionalidades: Equipes são criadas para desenvolver determinadas funcionalidades 
específicas. Inspeção: Constante avaliação da qualidade do código implementado. 
Integração Contínua: As integrações ocorrem com certa regularidade para evitar dificuldades na hora 
de integrar uma grande quantidade de código. 
Gerência de Configuração: Manter versões organizadas. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/aprofundando
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
Visibilidade de Progresso: Deixar visível e conhecido o progresso do projeto. 
Crystal 
Crystal é uma família de métodos que podem ser utilizados conforme a carga de informação e a 
criticidade de cada projeto. Esses métodos são divididos em Clear, Yellow, Orange e Red (COCKBURN, 
2002). Os princípios que regem os métodos Crystal são os seguintes: 
Entrega Frequente: Liberar entregas, testadas e funcionando para o usuário com a maior frequência 
possível. 
Comunicação Estreita: Encorajar a comunicação face a face, presencial, com todos os membros em 
uma mesma sala. 
Melhorias Reflexivas: Deve-se parar para pensar constantemente no processo e naquilo que pode ser 
aprimorado. 
Segurança Pessoal: Encorajar que todos os membros da equipe manifestem insatisfações sem medo 
de represarias. 
Foco: Minimizar interrupções e manter o foco no que realmente importa dentro do projeto, que são as 
tarefas de maior prioridade. 
Acesso fácil a usuários experientes: Obter feedback de usuários experientes. 
Ambiente Técnico: Com testes automatizados, gerenciamento de configuração e integração 
frequente. 
Lean Development (LD) 
Esse método é baseado na produção Lean, foi criado a partir da manufatura e tinha o objetivo de diminuir 
gastos com metade do esforço, do espaço e dos investimentos em geral (HIGHSMITH, 2002). Os 
princípios do Lean Development são: 
Eliminar Desperdícios: Evitar retrabalhos pensando sempre no aproveitamento do desenvolvimento. 
Aumentar o Aprendizado: Priorizar comunicação e os feedbacks contínuos. 
Adiar Compromissos: Parte-se do princípio de que quanto mais se espera para tomar uma decisão 
mais conhecimento se adquire sobre o tema. 
Entregas Rápidas: Entregar de forma rápida e contínua. 
Fortalecer o Time: Favorecer um ambiente onde o time possa se auto-organizar e tomar decisões. 
Construa com Integridade: Desenvolver sempre com foco na qualidade com testes unitários, 
refatoração e integração contínua. 
Visão do Todo: O desenvolvimento de uma funcionalidade deve estar inserida dentro da visão geral do 
produto. 
Adaptive Software Development 
Esse método tem por base o método RAD (Rapid Application Development) (HIGHSMITH, 2000). O 
Adaptive Software Developent tem como base as seguintes características: 
Foco na Missão: Objetivo deve estar definido e claro para a equipe. 
Baseado em Funcionalidades: Entregas que apresente resultados para o cliente. 
Iterativo: O ciclo de desenvolvimento sendo realizado repetidas vezes. 
Time-boxes: Os prazos devem estar fechados, com hora prevista para acabar. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/aprofundando
https://getfireshot.com
Dirigido a Riscos: Análise de riscos constante ao longo projeto. 
Tolerante a Mudanças: Incorporar as mudanças que aparecerem ao longo do projeto. 
REFERÊNCIASCOCKBURN, A. Agile Software Development . Addison Wesley, 2002. 
HIGHSMITH, J. Retiring Lifecycle Dinosaurs . Software Testing & Quality Engineering 2, n.4, July/August 
2000. 
HIGHSMITH, J. Agile Software Development Ecosystems . Addison Wesley, 2002. 
PALMER, S. R.; FELSING, J. M. A Practical Guide to Feature-Driven Development . Prentice Hall, 2002. 
PARABÉNS! 
Você aprofundou ainda mais seus estudos! 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/aprofundando
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial/editorial
Página inicial 
EDITORIAL 
DIREÇÃO UNICESUMAR 
Reitor Wilson de Matos Silva 
Vice-Reitor Wilson de Matos Silva Filho 
Pró-Reitor de Administração Wilson de Matos Silva Filho 
Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva 
Pró-Reitor de Ensino de EAD Janes Fidélis Tomelin 
Presidente da Mantenedora Cláudio Ferdinandi 
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ . Núcleo de Educação a 
Distância; FREITAS , Marcos Joaquim de. 
Scrum. Marcos Joaquim de Freitas. 
Maringá-Pr.: UniCesumar, 2017. 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/editorial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
27 p. 
“Pós-graduação Universo - EaD”. 
1. Scrum. 2. Software. 3. EaD. I. Título 
CDD - 22 ed. 658 
CIP - NBR 12899 - AACR/2 
Pró Reitoria de Ensino EAD Unicesumar 
Diretoria de Design Educacional 
Equipe Produção de Materiais 
Fotos : Shutterstock 
NEAD - Núcleo de Educação a Distância 
Av. Guedner, 1610, Bloco 4 - Jardim Aclimação - Cep 87050-900 
Maringá - Paraná | unicesumar.edu.br | 0800 600 6360 
Retornar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum2/p�gina-inicial/editorial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum2/p%C3%A1gina-inicial
Página inicial 
O SCRUM E 
OUTROS 
MÉTODOS ÁGEIS 
Professor : 
Esp. Marcos Joaquim de Freitas 
Objetivos de aprendizagem 
Compreender a aplicação dos eventos do Scrum ao longo do fluxo do projeto em andamento. 
Compreender o fluxo completo do Scrum e as interações dos atores, artefatos e eventos. 
Compreender as técnicas utilizadas no método Kanban que podem ser utilizadas em conjunto com o 
Scrum. 
Estudar a metodologia XP utilizada de forma complementar ao Scrum em projetos de 
desenvolvimento. 
https://sites.google.com/fabrico.com.br/scrum3/p�gina-inicial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum3/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum3/p%C3%A1gina-inicial
Plano de estudo 
A seguir, apresentam-se os tópicos que você estudará nesta unidade: 
Os Eventos do Scrum. 
Compreendendo o Fluxo do Scrum. 
Kanban. 
Visão Geral da Extreme Programming (XP). 
Introdução 
O Scrum é um framework que, quando é aplicado da forma correta, representa uma melhora significativa 
no desempenho do projeto. Para que o valor do framework seja percebido, é necessário que, além dos 
papéis desempenhados e dos artefatos produzidos, sejam realizados alguns importantes eventos, também 
conhecidos como cerimônias. 
Todos nós somos pautados no dia a dia por eventos de rotina que devemos seguir ao longo de nossas 
vidas, seja o momento de escovação dos dentes, o intervalo de almoço ou passear com o cachorro, todos 
são eventos necessários com uma finalidade específica e com um tempo médio determinado. No Scrum, 
esses eventos se dão em forma de ciclo de desenvolvimento, reuniões de avaliação e planejamento. 
O Scrum possui um fluxo contínuo de iterações que tem como foco um constante planejamento e uma 
constante reavaliação. Seus eventos bem estabelecidos e os papéis bem definidos deixam os processos 
bem organizados. Em muitos casos, a utilização do Scrum associado a outros métodos ágeis, como o 
Kanban e a Exteme Programming (XP), faz com que se tenha ainda mais organização e rendimento em 
projetos, sobretudo, de desenvolvimento de software. 
As metodologias ágeis surgiram a partir dos mesmos ideais, e algumas, além de compartilhar 
determinadas técnicas e conceitos, podem gerar ainda mais valor quando utilizadas juntas. No caso do 
Scrum e Kanban, observa-se um ganho obtido com o uso de técnicas do Kanban no framework, uma vez 
https://sites.google.com/fabrico.com.br/scrum3/p�gina-inicial
https://getfireshot.com
que a partir de acompanhamento visual se torna mais claro o andamento do desenvolvimento realizado. 
Da mesma maneira, a XP – que é uma técnica de programação exclusivamente voltada para o 
desenvolvimento de software – aliada ao Scrum estabelece projetos de software muito mais gerenciado e 
planejado fazendo com que o melhor das duas técnicas, já similares em alguns aspectos, possa ser 
utilizado. 
Vamos nos aprofundar um pouco mais, a partir de agora nesse estudo, no universo do Scrum, Kanban e 
Extreme Programming. 
Avançar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/scrum3/p�gina-inicial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum3/p%C3%A1gina-inicial/unidade-3
Página inicial 
OS EVENTOS DO SCRUM 
Existem alguns eventos determinados no Scrum que são responsáveis por criar uma rotina e diminuem a 
ocorrência de reuniões não planejadas. Os eventos estão relacionados a um conceito chamado Time-Box, 
possuem uma duração fixa, prédeterminada. Ou seja, quando o evento inicia, ele já possui uma duração 
máxima estabelecida (SUTHERLAND; SCHWABER, 2016). 
Os eventos conhecidos como Time-Boxes, que serão apresentados a seguir, são: Sprint, Reunião de 
Planejamento da Sprint, Reunião Diária, Revisão da Sprint, Retrospectiva da Sprint. 
Sprint 
Sprint é um período de tempo determinado no qual a equipe trabalha para realizar uma entrega. É uma 
iteração em que a implementação ocorre de fato pelo Time de Desenvolvimento e o Scrum Master 
trabalha para garantir que não ocorrerá nenhuma mudança que poderá alterar a qualidade e o objetivo da 
Sprint. As Sprints ocorrem uma após outra, sem intervalos de tempo. 
É possível afirmar que as Sprints são a base do Scrum, são compostas de reunião de planejamento da 
Sprint, reuniões diárias, desenvolvimento propriamente dito, revisão e retrospectiva da Sprint. O método 
do Scrum é inspirado no método Deming, conhecido pelo acrônimo PDCA que corresponde a Plan 
https://sites.google.com/fabrico.com.br/scrum3/p�gina-inicial/unidade-3
https://getfireshot.com
https://sites.google.com/fabrico.com.br/scrum3/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/scrum3/p%C3%A1gina-inicial
(planeje), Do (faça), Check (verifiquei) e Act (aja) (SUTHERLAND, 2014). A Figura 1 mostra como é a 
representação do fluxo do PDCA. 
Figura 1 – Fluxo do PDCA 
A Sprint não deve passar de um mês e, nesse meio tempo, não são aceitas mudanças que possam alterar o 
objetivo da Sprint. O escopo da Sprint é extraído do Product Backlog, e um plano é projetado para auxiliar 
no entendimento do que deve ser construído, qual o trabalho e quais os resultados devem ser alcançados. 
Caso a meta da Sprint se torne fora de contexto e seu escopo não atenda mais o cliente por alguma 
alteração na direção do projeto, ou por troca de tecnologias, por exemplo, ela pode ser cancelada se, e 
somente se, o Product Owner decidir que seja o melhor caminho, ainda que essa decisão possa partir da 
influência do Time de Desenvolvimento ou do Scrum Master. Não é comum surgir a necessidade de 
cancelamento de uma Sprint, em função de sua curta duração. 
Sprint Planning 
Esse é um evento Time-Box, cujo tempo total não deve ultrapassar 5% da duração total de uma Sprint. A 
reunião é dividida em duas partes, na primeira parte da reunião é tratado “o que?” na qual o Product 
Owner deve trazer ao Time qual a priorização do Backlog do Produto, o incremento mais recente e o 
históricode desempenho do time, e a partir disso serão definidas, em conjunto, quais funcionalidades 
serão desenvolvidas durante a próxima Sprint. 
Na outra parte da reunião é tratado o “como?”; a partir daí, o Time define como irá transformar as tarefas 
definidas na parte do “o que?” em um incremento a ser disponibilizado, a partir do Backlog da Sprint 
formado por uma lista de tarefas juntamente com um plano de entregas, define-se o esforço de 
desenvolvimento. 
O Time de Desenvolvimento se auto-organiza para se encarregar pelo trabalho listado, cada um fica 
responsável por uma parte do trabalho e ao final da reunião o Time de Desenvolvimento deve explicar ao 
https://sites.google.com/fabrico.com.br/scrum3/p�gina-inicial/unidade-3
https://getfireshot.com
Product Owner e para Scrum Master como pretende trabalhar para alcançar o objetivo da Sprint. 
Daily Scrum 
A Reunião Diária do Scrum serve para o que Time de Desenvolvimento possa se atualizar em relação ao 
andamento das atividades, bem como se planejar para as próximas horas. Essa reunião não deve 
ultrapassar 15 minutos e também conhecida como Daily Stand-Up, pois ocorre com todos os 
participantes em pé, exatamente para que seja rápida e objetiva e deve ocorrer sempre no mesmo horário 
e local para que faça parte de uma rotina diária, como é escovar os dentes onde você acaba sempre tendo 
que fazer isso no banheiro. 
Se definirmos uma sequência para as Daily Scrum, podemos dizer que primeiro o Scrum Master organiza a 
reunião, define a pauta e chama todos para o local e horário estabelecido, explicando quais as regras da 
reunião. Após isso, a bola fica com o Time de Desenvolvimento, no qual um a um deve falar, iniciando pelo 
que chegou por último na sala, respondendo em linhas gerais os seguintes questionamentos: 
O que eu fiz desde a última reunião? 
O que eu irei fazer até a próxima reunião? 
Quais obstáculos estão me impedindo de alcançar os objetivos? 
O Scrum Master toma nota das informações passadas pelos membros da equipe e busca soluções para os 
obstáculos apresentados. O quadro Kanban é atualizado caso esteja sendo utilizado no projeto e o Time 
de Desenvolvimento se reúne para realizar discussões técnicas mais detalhadas sobre alguma questão 
levantada na reunião, caso seja necessário. 
Para resumir, o papel do Scrum Master é de garantir que a reunião ocorra, a condução das da reunião é de 
responsabilidade do próprio Time de Desenvolvimento que deve se autogerenciar. Ela serve para o 
próprio time medir o progresso e garantir que a direção do desenvolvimento está seguindo o caminho 
correto para o devido cumprimento do Backlog da Sprint. 
A Reunião Diária tem o objetivo de melhorar a comunicação, identificar os obstáculos para o 
desenvolvimento, propicia rápidas escolhas e decisões, nivela o conhecimento do time e elimina outras 
reuniões; nela é possível inspecionar o processo e se adaptar caso seja necessário. 
Sprint Review 
A Revisão da Sprint é uma reunião de no máximo 4 horas de duração, podendo variar conforme o tamanho 
da Sprint. É realizada ao final da Sprint e tem por objetivo fazer um balanço do que foi realizado. O Time 
Scrum e os stakeholders (partes interessadas) apresentam de forma informal o que foi feito de 
funcionalidades e colaboram em relação às mudanças que possam vir a ocorrer nos rumos das próximas 
Sprints. Tem o objetivo de atualizar o status, conhecer os incrementos e promover a colaboração no 
projeto. 
https://sites.google.com/fabrico.com.br/scrum3/p�gina-inicial/unidade-3
https://getfireshot.com
Nessa reunião, o Product Owner informa quais itens do Backlog do Produto foram atendidos, o Time de 
Desenvolvimento mostra o incremento esclarecendo questões que possam surgir sobre o trabalho que 
está pronto, as datas de entregas do Backlog do Produto são debatidas, todo o grupo contribui sobre 
como o trabalho deve prosseguir, é realizada uma avaliação sobre mudanças externas, é feito uma análise 
de orçamento, mercado e potencial do produto. 
Sprint Retrospective 
A Retrospectiva da Sprint é um momento para que o Time Scrum identifique o que funcionou de forma 
adequada, o que pode ser melhorado e quais ações podem ser tomadas para chegar nessa melhora. O 
Scrum Master é responsável por fazer com que essa reunião ocorra e por encorajar o time a fazer essa 
avaliação do processo de desenvolvimento dentro das práticas do Scrum. O tempo máximo dessa reunião 
é de 3 horas, podendo diminuir conforme o tamanho da Sprint. 
Essa é uma reunião de inspeção que irá resultar na adaptação, quanto mais o Time Scrum contribuir nessa 
avaliação mais é possível tornar o processo ainda melhor. A cada retrospectiva, o Time Scrum busca 
formas de aumentar a qualidade do produto, por meio de adaptações que visam o aprimoramento 
constante. 
Um exemplo de roteiro para uma Reunião Planejamento das 13h às 17h seria da 
seguinte forma: 
13h às 13h30: O Product Owner revisa o objetivo da Sprint trazendo os itens 
priorizados do Product Balcklog. 
13h30 às 15h: O Time define tempo, quebrando os itens conforme necessário, além 
de esclarecer e refinar melhor as informações. 
15h às 16h: A equipe escolhe as histórias que devem ser desenvolvidas; 
16h às 17h: É definido local para a reunião diária e complementam a quebra de 
histórias em tarefas; 
Fonte: Kniberg (2008). 
https://sites.google.com/fabrico.com.br/scrum3/p�gina-inicial/unidade-3
https://getfireshot.com
COMPREENDENDO O FLUXO 
DO SCRUM 
Agora que vimos separadamente os elementos que compõe basicamente o Scrum, é a vez de entender de 
uma vez por todas como funciona esse framework ao longo de todo o seu fluxo e revivendo um pouco 
sobre artefatos, papéis e eventos, vistos até agora nesse estudo, de uma forma agora contextualizada. 
O Scrum tem por base trabalhar em pequenas porções, que dentro do modelo iterativo e incremental, 
possibilite entregas frequente de fragmentos que sejam importantes para o negócio experimentar e 
validar se estamos no caminho certo, enquanto deixamos para mais tarde fazer mais definições ou tomar 
outras decisões em relação ao projeto. 
O projeto inicia por uma reunião de visão, também conhecida com pré-game ou pré-jogo. Ainda que essa 
reunião não faça parte dos eventos oficiais do Scrum, esse momento é importante para definir a missão do 
projeto, os objetivos macros, a contextualização e porque esse produto deve ser desenvolvido e existir. 
https://sites.google.com/fabrico.com.br/scrum3/p�gina-inicial/unidade-3
https://getfireshot.com
Uma vez entendidas essas questões gerais, é momento de gerar uma lista de requisitos mínimos que 
agreguem valor ao produto chamado de Product Backlog. 
Após definida a estratégia e com o Backlog do Produto priorizado pelo Product Owner , é possível 
selecionar para a Sprint uma lista de requisitos desejados, para esse ciclo de desenvolvimento, chamada 
de Sprint Backlog. A definição dessa lista, bem como a estimativa de esforço para cada tarefa, é realizada 
por meio da Sprint Planning. 
Entramos, então, na execução da Sprint propriamente dita que compreende desde o Sprint Planning até a 
entrega do resultado, podendo variar de 2 a 4 semanas de trabalho. Ao longo dos dias nesse período, a 
cada 24 horas ocorre uma reunião, chamada de Daily Scrum , para que cada integrante do time passe um 
relato breve sobre como está andando o desenvolvimento e quais os obstáculos encontrados. 
Durante todo o desenvolvimento, um quadro de tarefas trazido das técnicas do método Kanban é fixado 
de modo que fique visível a todo o time. Assim, com a atualização em tempo real feito por cada integrante, 
é possível acompanhar de forma visual o andamento do trabalho para que decisões para garantir o 
sucesso da Sprint sejam tomadas, caso seja necessário. 
Uma revisão com o nome de Sprint Review ocorre no último dia previsto da Sprint com todo o Time 
Scrum e os Stakeholders com o objetivo de apresentar e discutir o que foi feito e