GRA1592 CRIATIVIDADE, IDEAÇÃO E RESOLUÇÃO DE PROBLEMAS GR0518211 - 202110 ead-7354 08

Prévia do material em texto

23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 1/36
CRIATIVIDADE, IDEAÇÃO ECRIATIVIDADE, IDEAÇÃO E
RESOLUÇÃO DE PROBLEMASRESOLUÇÃO DE PROBLEMAS
METODOLOGIAS ÁGEISMETODOLOGIAS ÁGEIS
DE GERENCIAMENTO DEDE GERENCIAMENTO DE
PROJETOS - SCRUMPROJETOS - SCRUM
Autor: Esp. Anderson Oliveira
Revisor : Rafae l Araújo
I N I C I A R
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 2/36
introduçãoIntrodução
Na economia globalizada, a velocidade das ações a serem tomadas precisa
acompanhar o timing esperado pelas empresas, e o planejamento não pode
fugir desse princípio. Na década de 1990, quando iniciou o desenvolvimento em
massa de softwares para as grandes companhias, Je� Sutherland e Ken
Schwaber identi�caram que o planejamento tradicional de projetos já não era
tão e�ciente quanto o mercado exigia, especialmente no tocante aos prazos que
precisavam ser cumpridos para a entrega dos produtos. E como os clientes não
percebiam de imediato os resultados do planejamento, que durava muito
tempo, a proposta de valor se perdia. Para tanto, eles desenvolveram uma
metodologia de planejamento e execução de projetos que tinham um claro
propósito: oferecer ao cliente a percepção do valor do projeto a ser entregue,
num curto espaço de tempo. Surgia assim o Scrum.
Como diz o próprio Sutherland, o Scrum pode ser de�nido como “A arte de fazer
o dobro, na metade do tempo”. Vamos conhecer melhor essa metodologia e
suas aplicações a partir de agora!
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 3/36
Nos dias atuais as transformações são muito rápidas, especialmente devido ao
�uxo incessante de informações e às transformações político-econômicas, como
o surgimento de novos mercados, produtos, concorrentes e até modelos de
negócio baseados no avanço tecnológico acessível a todos. Nesse sentido, as
empresas, para obterem sucesso, precisam ser resilientes nos processos de
gestão, buscando a adaptação aos cenários desfavoráveis, a agilidade nos
processos, e um planejamento que busque estratégias para atender às suas
necessidades. É nesse sentido que o gerenciamento de projetos busca oferecer
uma possibilidade de atingir as metas esperadas.
Com isso, busca-se a melhoria nos processos de gerenciamento de projetos,
dada a importância do tema na gestão organizacional. Para tanto, existem
diversas fontes de conhecimento, habilidades e ferramentas para produzir
resultados interessantes para agir em resposta às mudanças o mais
e�cientemente possível.
O GerenciamentoO Gerenciamento
de Projetosde Projetos
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 4/36
O gerenciamento de projetos como um estudo formal que leva as organizações
a obterem resultados positivos iniciou-se a partir da fundação do PMI – Project
Management Institute – que desenvolveu estudos no campo do gerenciamento
de projetos que culminou na criação de um livro que lista um conjunto de “boas
práticas” em gestão, chamado PMBoK – Project Management Book of Knowledge.
O modelo proposto pelo PMBoK não pode ser considerado de fato uma
metodologia, visto que não precisa ser cumprido “à risca” para proporcionar os
resultados esperados, mas oferece premissas que os projetos desenvolvidos
pelas empresas mais renomadas no mercado mundial cumpriram e obtiveram
resultados excelentes em seus projetos. O modelo proposto pelo livro traz a
conexão entre 10 áreas do conhecimento (6ª edição – integração, escopo,
cronograma, custos, qualidade, recursos, comunicações, riscos, aquisições,
partes interessadas) que regulam e associam todos os passos durante o ciclo de
vida do projeto, atribuindo responsabilidades, recursos, prazos e �uxos de
comunicações bem de�nidos, com o objetivo de atender os requisitos de�nidos
no escopo para cumprir as necessidades dos stakeholders (partes interessadas
no projetos. De�ne-se partes interessadas quaisquer pessoas que possam
impactar ou serem impactadas pelo projeto).
O gerenciamento de projetos baseado nas boas práticas oferece uma
assertividade na execução que evidencia sua relevância no planejamento de
soluções para as empresas. Entretanto, apesar das inúmeras vantagens, a
aplicação das ferramentas do PMBoK tem algumas desvantagens, onde a
principal delas advém do conjunto demasiado grande de processos em sua
aplicação. Exatamente por esse motivo, a sua aplicação em alguns casos
especí�cos já não atendia às expectativas de agilidade em seu desenvolvimento.
Nesse viés, as metodologias ágeis de gerenciamento de projetos ganharam
força em seu desenvolvimento de projetos de software, devido à necessidade de
velocidade na resposta aos clientes. E dada a sua e�cácia nesses casos,
passaram a ter sua aplicação difundida nos mais diversos âmbitos do
planejamento. Assim, a partir do manifesto ágil a metodologia passou a ser
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 5/36
estruturada e organizada. O manifesto ágil é um documento que organiza as
premissas básicas de uma �loso�a que prega a diminuição dos processos
buscando uma maior agilidade na entrega dos projetos aos clientes.
Atualmente, a metodologia de gerenciamento de projetos ágeis mais conhecida
é o Scrum.
Diferenças Entre as Metodologias:
Tradicional x Ágil
Ambas metodologias são relevantes e possuem características semelhantes em
diversos pontos, porém divergem em tantos outros, o que nos faz precisar
saibamaisSaiba mais
O manifesto ágil é o documento que
regulamenta a �loso�a de gerenciamento que
visa a agilidade na entrega dos
produtos/serviços planejados, aumentando a
e�ciência dos processos, eliminando os passos
que não agregam valor ao produto �nal. Saiba
mais acessando o vídeo a seguir.
ASS IST IR
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 6/36
avaliar qual delas (ou se até ambas) pode(m) ser utilizada(s) para produzir o
resultado mais satisfatório para o projeto que desejamos desenvolver.
No método tradicional de gestão (o método mais rígido, proposto pelo PMI no
guia PMBoK), o objetivo é concluir todo o projeto para que haja a percepção de
valor por parte do cliente, ou seja, apenas o projeto �nalizado é passível de ser
avaliado. Já na metodologia ágil, uma das premissas básicas é a subdivisão das
metas a serem atingidas, de�nidas como “entregáveis”. Tal fato faz com que o
cliente possa perceber as funcionalidades, como uma espécie de “degustação”
do resultado �nal do projeto, que vai sendo construído como um quebra-
cabeças, e cada fase do projeto agrega valor para o cliente.
Outra característica que diferencia as metodologias de gestão toca no fato que
abrange o custo do projeto. A metodologia tradicional preconiza durante a fase
de planejamento seja estabelecido um orçamento prévio e as margens de erro,
especialmente de�nidas (na maioria dos casos) como um dos critérios de
aceitação e qualidade do projeto. Na metodologia ágil, na maioria dos casos, o
escopo é muito aberto e passível a mudanças, o que faz com que as
expectativas de custo �quem distantes daqueles planejados no início do projeto.
No que tange aos processos, na metodologia tradicional há uma maior rigidez
nos passos a serem cumpridos, no escopo de�nido, gerenciamento do tempo e
recursos, o que faz com que o gerenciamento passe por menos mudanças. Na
metodologia ágil os processos são mais abertos, suscetíveis às mudanças.
As equipes partícipes de projetos baseados na metodologia tradicional
costumam ser maiores e mais heterogêneas, com papéis e responsabilidades
distintas, competências e habilidades diversas e hierarquiasbem de�nidas. As
responsabilidades desses pro�ssionais estão ligadas à execução do seu trabalho
em si, não sendo cobrados pelos resultados �nais do projeto. Na gestão ágil, as
equipes tendem a ser mais enxutas, multidisciplinares e autogerenciadas. Cada
pro�ssional tem responsabilidades múltiplas, e comprometidos diretamente
com o resultado �nal do projeto.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 7/36
Em geral, não existe metodologia certa nem errada para a aplicação no
gerenciamento de um determinado projeto. O correto é um planejamento que
contemple as necessidades do projeto, especialmente no que tange ao
atendimento às demandas do cliente, principal stakeholder do projeto (CRUZ,
2018).
reflitaRe�ita
Je� Sutherland e Ken Schwaber
desenvolveram a metodologia ágil para
resolver um problema que aturdia a
cabeça deles no que tangia ao
desenvolvimento de projetos: entregar
resultados rapidamente, garantindo a
qualidade e reduzindo custos.
Entretanto, a metodologia tradicional
proposta pelo PMBoK ainda é
amplamente utilizada e respeitada em
todo o mundo. Na sua opinião, qual das
metodologias mais se adequa à sua
realidade?
Fonte: Adaptado de Sutherland (2016).
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 8/36
praticarVamos Praticar
A metodologia Scrum desenvolvida por Je� Sutherland e Ken Schwaber é uma
proposta de gerenciamento de projetos de maneira mais rápida e sistemática, com
atividades altamente caracterizáveis e com uma proposta clara e objetiva. Assinale a
alternativa que traz a proposta da metodologia Scrum.
a) Gestão heterogênea.
b) Mais processos.
c) Proposta de valor.
d) Rigidez.
e) Boas práticas.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 9/36
Uma de�nição resumida do Scrum pode ser apresentada como uma
metodologia ágil para proporcionar o desenvolvimento de projetos nos quais as
equipes trabalhem em sinergia para atingir os objetivos propostos. A
metodologia é baseada no preceito de que o cliente enxerga melhor o valor do
projeto quando recebe “pequenos produtos utilizáveis”. E para alcançar esse
objetivo, a metodologia propõe que a equipe de pro�ssionais precisa ser
autônoma, promovendo uma cultura de autogestão, ou seja, cada membro da
equipe está comprometido com o seu “entregável”.
É fundamental para o �uxo correto dos processos uma estratégia de
gerenciamento chamada “gestão à vista” onde os processos precisam ser
visualmente conhecidos para avaliar seu progresso, até mesmo para garantir o
engajamento de todos em prol do resultado �nal, além de evidenciar gargalos e
falhas nos processos preestabelecidos.
Metodologia ScrumMetodologia Scrum
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 10/36
Outra premissa atribuída ao desenvolvimento de projetos via Scrum é que os
prazos para a concretização dos chamados “entregáveis” sejam curtos e críveis,
de forma que as medições do projeto aconteçam em intervalos de tempo que
não passem do horizonte de “alguns dias”. As entregas precisam ser
comunicadas à equipe sempre que as medições forem aceitas pelo cliente,
fomentando o espírito de engajamento da equipe em prol do resultado �nal.
Além das características apresentadas, ainda existe mais uma que é
fundamental para a e�ciência da aplicação do Scrum: a tendência de adaptar-se
a novas realidades apresentadas pelo ambiente ou exigências advindas do
cliente. Ou seja, as mudanças nos projetos executados via metodologia Scrum
são altamente resilientes no que diz respeito às mudanças no projeto, cujos
processos são muito menos rígidos (em comparação com a metodologia
tradicional do PMI).
Os estudos da metodologia Scrum foram iniciados por Je� Sutherland e Ken
Schwaber, que desenvolveram um documento que norteia a aplicação do
framework nas mais diversas aplicações, cujo propósito, declarado no Scrum
Guide (2013) é contribuir na elaboração e manutenção de produtos complexos.
O guia do Scrum atribui e de�ne os papéis, eventos, artefatos e as regras do
Scrum (SUTHERLAND; SCHWABER, 2013).
De acordo com Sutherland e Schwaber (2013, p. 3), a de�nição formal do Scrum
é “um framework dentro do qual pessoas podem tratar e resolver problemas
complexos e adaptativos, enquanto produtiva e criativamente entregam
produtos com o mais alto valor possível”.
A metodologia foi desenvolvida com o intuito de ser leve, simples de entender e
difícil de dominar. Ainda de acordo com os autores, o Scrum não pode ser
associado a um processo ou técnica para construir produtos. É um framework
aberto, que pode ser associado a diversas técnicas e ferramentas para seu
desenvolvimento. O Scrum tem por objetivo evidenciar a e�cácia dos processos
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 11/36
de gerenciamento de projetos, apresentando um potencial solução para
melhorá-los (SUTHERLAND; SCHWAlBER, 2013).
Teoria da Aplicação do Scrum
O Scrum é uma metodologia que utiliza processos empíricos em sua
estruturação básica. Ou seja, muitos dos conhecimentos aplicados no seu
desenvolvimento são construídos sobre o alicerce da experiência prévia e da
tomada de decisão em cima de lições aprendidas, visto que o Scrum utiliza uma
estrutura iterativa, isto é, seu desenvolvimento é construído em cima de ciclos
de produção incremental, para re�nar os resultados esperados e reduzir os
riscos, apoiados em 3 pilares básicos: transparência, inspeção e adaptação
(SUTHERLAND; SCHWABER, 2013).
Sobre a transparência, a aplicação do Scrum preconiza que os principais passos
e resultados precisam estar acessíveis, especialmente aqueles que dizem
respeito aos principais stakeholders. Entretanto, essa acessibilidade requer
alguns padrões comuns para que todos possam obter o mesmo nível de
entendimento sobre o que está sendo apresentado. Já no que tange às
inspeções, faz-se necessário que, em intervalos de tempo regulares, os usuários
(alguns dos principais stakeholders do projeto) precisam acompanhar o
desenvolvimento dos “artefatos”, documentos que constituem o planejamento e
execução do projeto, com o intuito de procurar “discrepâncias” entre o
planejado e o executado. Essa veri�cação ativa é fundamental para o
re�namento do produto �nal, e precisa ser executado por especialistas, pois os
feedbacks são essenciais para as melhorias, evidenciando os erros e potenciais
ajustes. A adaptação busca realizar os ajustes, o mais rápido possível para evitar
os erros em cascata no projeto. Na ocasião da inspeção, caso algum processo
não esteja adequado com a sua usabilidade, pode ser ajustado ou realinhado
em seu propósito. Conforme será descrito posteriormente, as inspeções
ocorrerão nos eventos formais em 4 instantes: reunião de planejamento do
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 12/36
sprint; reunião diária; reunião de revisão do sprint; retrospectiva do sprint
(SUTHERLAND; SCHWABER, 2013; SABBAGH, 2014).
O �uxo dos processos da aplicação do framework Scrum pode ser visto na
Figura 4.1. 
A metodologia, até mesmo por conta de sua construção, utiliza vários termos
especí�cos, a maioria deles em inglês, que possuem reconhecimento mundial e,
justamente por esse motivo, serão aqui apresentados.
praticarVamos Praticar
Figura 4.1 - Fluxo de processos da metodologia Scrum 
Fonte: Aleksandra Sabelskaia / 123RF.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 13/36
A metodologia Scrum desenvolvida por Je� Sutherland e KenSchwaber é uma
proposta de gerenciamento de projetos de maneira mais rápida e sistemática, com
atividades altamente caracterizáveis e com uma proposta clara e objetiva, alicerçada
em 3 pilares fundamentais. Assinale a alternativa que apresenta os 3 pilares
fundamentais corretamente.
a) Transparência, inspeção e adaptação.
b) Time Scrum, eventos e artefatos.
c) Proposta de valor, boas práticas e framework.
d) Backlog do produto, Backlog da Sprint e incremento.
e) Product Owner, Scrum Master e time de desenvolvimento.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 14/36
O time Scrum é o conjunto de pessoas que planejam, orientam, desenvolvem e
executam o planejamento do projeto através da metodologia Scrum. Sutherland
e Schwaber (2013) dividem a equipe de trabalho de aplicação do framework em:
Product Owner;
Time de desenvolvimento;
Scrum Master.
A grande premissa para o bom funcionamento da metodologia é a capacidade
de autogerenciamento do time Scrum, além da mobilidade funcional entre os
participantes, dada a multifuncionalidade deles. Esses times autogerenciáveis
determinam as melhores ferramentas a serem utilizadas no desenvolvimento da
metodologia, característica avessa ao planejamento tradicional (onde as ações a
serem tomadas seguem um �uxo claro de hierarquia, geralmente o sponsor ou
patrocinador é o responsável). Outra característica importante dessas equipes é
que cada membro possui clara responsabilidade sobre suas ações, então todos
Time ScrumTime Scrum
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 15/36
precisam possuir as habilidades e competências necessárias para executar as
suas ações independentemente de qualquer pessoa fora do time Scrum. A
metodologia impõe a utilização dessa estrutura para disseminar a cultura de
�exibilidade, criatividade e produtividade (SUTHERLAND; SCHWABER, 2013).
A proposta clara da formação do time Scrum é oferecer o desenvolvimento de
soluções de maneira iterativa e incremental, aproveitando o feedback gerado ao
longo do processo para retroalimentação. Os entregáveis, produtos ou parcelas
utilizáveis do produto �nal têm a missão de oferecer a experiência da utilização
de funcionalidades do resultado �nal, proporcionando a valorização contínua do
projeto (SUTHERLAND; SCHWABER, 2013).
Vamos apresentar agora, cada um dos “membros” do time Scrum.
Product Owner
O “dono do produto” é o maior responsável pela proposta de valor do projeto
via metodologia Scrum. Possui a missão de explorar todo o potencial do time de
desenvolvimento, com a utilização de diversas ferramentas para atingir seu
objetivo. Também é responsabilidade do Product Owner o gerenciamento do
Backlog do produto (cuja de�nição será apresentada posteriormente). Segundo
Sutherland e Schwaber (2013, p. 5), a responsabilidade do Product Owner sobre
o gerenciamento do Backlog do produto inclui:
Expressar claramente os itens do Backlog do Produto;
Ordenar os itens do Backlog do Produto para alcançar melhor as metas
e missões;
Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;
Garantir que o Backlog do Produto seja visível, transparente, claro para
todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,
Garantir que o Time de Desenvolvimento entenda os itens do Backlog
do Produto no nível necessário.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 16/36
O papel do Product Owner, apesar de, em vários casos atuar sob os propósitos
de uma empresa ou um comitê, é executado sempre por apenas uma pessoa,
responsável direto pelas ações a serem tomadas sob sua área de competência.
Entretanto, as ações sob sua responsabilidade podem ser executadas por
outrem, sob seu controle. É imprescindível que o Product Owner conquiste o
respeito de toda equipe sobre as suas decisões, sem as quais não será possível
obter sucesso em seu gerenciamento. Todas as suas decisões são evidenciadas
no conteúdo e nas etapas de priorização do Product Backlog. Suas decisões são
soberanas sobre as dos demais membros do time (time de desenvolvimento e
Scrum Master), especialmente no que tange às prioridades de execução
(SUTHERLAND; SCHWABER, 2013).
Time de Desenvolvimento
(Development Team)
O time de desenvolvimento do Scrum é o conjunto de pessoas que executam o
trabalho que constrói os “entregáveis”, que segundo o framework Scrum são
chamados de Pronto ou DoD (De�nition of Done), sempre que um Sprint é
�nalizado. Somente os membros do time de desenvolvimento possuem a
responsabilidade de elaborar os incrementos, e exatamente por esse motivo, os
membros estão aptos a gerir seu próprio trabalho, devidamente autorizados a
tomarem as decisões necessárias para cumprir a sua missão. A efetividade do
processo de gerenciamento é garantida pela sinergia entre os membros do time
(SUTHERLAND; SCHWABER, 2013).
Segundo os autores do Guia do Scrum (SUTHERLAND; SCHWABER, 2013, p. 6), as
responsabilidades do time de desenvolvimento são:
Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz
ao Time de Desenvolvimento como transformar o Backlog do Produto
em incrementos de funcionalidades potencialmente utilizáveis;
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 17/36
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 o Desenvolvedor, independentemente
do trabalho que está sendo realizado pela pessoa; Não há exceções
para esta regra;
Individualmente os integrantes do Time de Desenvolvimento podem ter
habilidades especializadas e área de especialização, mas a
responsabilidade pertence ao Time de Desenvolvimento como um
todo; e,
Times de Desenvolvimento não contêm subtimes dedicados a domínios
especí�cos de conhecimento, tais como teste ou análise de negócios.
Outra questão relevante sobre o time de desenvolvimento trata sobre o
tamanho da equipe. A quantidade de membros do time precisa ser de uma
abrangência tal que seja su�ciente para atender às demandas do projeto e
garantir as entregas no �nal do Sprint, porém não pode ser demasiadamente
grande para garantir a agilidade dos processos. De acordo com o Guia do Scrum
(SUTHERLAND; SCHWABER, 2013), usualmente os times têm entre 3 e 9
colaboradores, excluindo-se o Scrum Master e o Product Owner. Nos casos
onde eles também executam o papel de membro do time de desenvolvimento,
eles entram na conta do time.
Scrum Master
O papel do pro�ssional que ocupa a função de Scrum Master no framework é
garantir que a metodologia seja compreendida por todos os membros do Time
Scrum. É da sua responsabilidade garantir o cumprimento dos papéis e
responsabilidades do Time Scrum, e as práticas comuns à metodologia, como as
entregas dos artefatos, o cumprimento dos eventos e as de�nições de Pronto
(DoD). O Scrum Master também tem o papel de avaliar (especialmente durante
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 18/36
as inspeções) as iterações desnecessárias e os erros nos processos,
evidenciando o valor oferecido pelo produto construído via Scrum
(SUTHERLAND; SCHWABER, 2013).
O Scrum Master trabalha no apoio e lida diretamente com 3 stakeholders do
projeto: Product Owner, Time de desenvolvimento e Organização. De acordo
com Sutherland e Schwaber (2013, p. 7) a relação entre o Scrum Master e cada
um deles estão listados como segue:
Scrum Master x Product Owner
Encontrar técnicas para o gerenciamento efetivo do Backlog do
Produto;
Claramente comunicar a visão, objetivo e itens do Backlogdo Produto
para o Time de Desenvolvimento;
Ensinar o Time Scrum a criar itens de Backlog do Produto de forma
clara e concisa;
Compreender em longo prazo o planejamento do Produto no ambiente
empírico;
Compreender e praticar a agilidade; e,
Facilitar os eventos Scrum conforme exigidos ou necessários.
Scrum Master x Time de desenvolvimento:
Treinar o Time de Desenvolvimento em autogerenciamento e
interdisciplinaridade;
Ensinar e liderar o Time de Desenvolvimento na criação de produtos de
alto valor;
Remover impedimentos para o progresso do Time de
Desenvolvimento;
Facilitar os eventos Scrum conforme exigidos ou necessários; e,
Treinar o Time de Desenvolvimento em ambientes organizacionais nos
quais o Scrum não é totalmente adotado e compreendido.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 19/36
Scrum Master x Organização:
Liderar e treinar a organização na adoção do Scrum;
Planejar implementações Scrum dentro da organização;
Ajudar funcionários e partes interessadas a compreender e tornar
aplicável o Scrum e o desenvolvimento de produto empírico;
Causar mudanças que aumentam a produtividade do Time Scrum; e,
Trabalhar com outros Scrum Masters para aumentar a e�cácia da
aplicação do Scrum nas organizações.
Assim, evidenciamos os papéis e responsabilidades do Time Scrum,
responsáveis diretos pelo planejamento, controle e execução do framework.
Agora apresentaremos os eventos preconizados pela metodologia Scrum,
fundamentais na sua construção. 
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 20/36
As atividades realizadas durante a execução do framework Scrum visam oferecer
a agilidade necessária para a execução do projeto como um todo. Para tanto, a
metodologia visa construir rotinas para o seu desenvolvimento, de forma a
evitar pausas desnecessárias, especialmente as reuniões improdutivas ao longo
do projeto. Todos os eventos executados ao longo da execução do Scrum
acontecem com uma duração especí�ca (time-boxed). Também durante o
planejamento, o Sprint (será apresentada a sua de�nição logo em seguida) terá
a duração do seu ciclo fechado, de tal maneira que não poderá ser alterada ao
longo do projeto. Todos os demais eventos poderão ser encerrados assim que o
objetivo �nal do projeto for atingido (SUTHERLAND, SCHWABER, 2013).
A lista de eventos do Scrum abrange, além do Sprint, que se subdivide em
alguns outros subeventos, a Reunião de planejamento do Sprint (Sprint Planning
Meeting), a Reunião diária (Daily meeting), Revisão do Sprint (Sprint Review) e
Retrospectiva do Sprint (Sprint Retrospective). A partir da ocasião de cada um
desses eventos, evidencia-se uma oportunidade de inspecionar o planejamento
Eventos ScrumEventos Scrum
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 21/36
e restaurar o seu rumo, na ocasião de erros. A proposta da realização dos
eventos visa oferecer uma maior transparência da execução e a possibilidade de
uma auditoria criteriosa das atividades (SUTHERLAND; SCHWABER, 2013).
Apresentaremos a seguir cada um dos eventos realizados ao longo do
desenvolvimento do framework Scrum.
Sprint
O Sprint é o principal evento da metodologia Scrum. É o intervalo de tempo
(normalmente cerca de um mês), no qual um produto “Pronto” (DoD) é
entregue. Ou seja, uma parte da solução �nal já pode ser avaliada pelo usuário
do produto/serviço. Durante a execução do Sprint, os demais eventos são
executados, para garantir o cumprimento do planejamento, além da execução
realizada pelo time de desenvolvimento.
De acordo com Sutherland e Schwaber (2013, p. 8), durante a execução do
Sprint:
Não são feitas mudanças que possam pôr em perigo o objetivo do
Sprint;
As metas de qualidade não diminuem; e,
O escopo pode ser clari�cado e renegociado entre o Product Owner e o
Time de Desenvolvimento quanto mais for aprendido.
O planejamento do Sprint não contempla prazos (time-box) maiores do que 1
mês, visto que uma das propostas do framework é a adaptação às mudanças, e
nesse intervalo de tempo, muita coisa pode mudar o planejamento, até mesmo
por que cada Sprint têm no seu planejamento, as atividades a serem realizadas
para atingir o objetivo do Sprint, o trabalho executado e o “pronto” a ser
entregue. Os riscos também aumentam e a previsibilidade do resultado
diminuem, reduzindo sua efetividade.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 22/36
Durante a execução de um Sprint, apenas um membro do Time Scrum possui a
autoridade de cancelar a sua execução antes do �nal do prazo preestabelecido:
O Product Owner. Sua ação (cancelar) pode ser motivada por outros interesses,
mas durante a aplicação da metodologia, a decisão só poderá ser tomada pelo
Product Owner. As ocasiões que levam ao cancelamento do Sprint são poucas,
mas a principal delas é quando o Sprint já não conseguirá atender a expectativa
do usuário �nal do produto. Isso ocorre em muitos casos devido ao próprio
avanço tecnológico, às condições mercadológicas ou se a própria organização já
não possui o mesmo processo gerencial. Em resumo, o Sprint deve ser
cancelado quando o propósito ao qual ele se destina se extinguiu. Na ocasião do
cancelamento, os artefatos resultantes do processo (Backlog do produto e
“Pronto”) são revisados para avaliar se o trabalho poderá ser aproveitado, e essa
aprovação é realizada pelo Product Owner (KNAPP; ZERATSKY; KOWITZ, 2017).
Reunião de Planejamento do Sprint
(Sprint Planning Meeting)
A reunião de planejamento do Sprint é realizada no início do seu
desenvolvimento, e visa elencar as atividades que serão realizadas no Sprint.
Tem duração estimada de 2h para cada semana de trabalho do Sprint
(Conforme falamos anteriormente, os tempos “time-box” são rigorosamente
de�nidos, de forma a evitar desperdício de tempo com reuniões
desnecessariamente longas). Esse controle rígido do time-box da reunião é
papel do Scrum Master.
De acordo com Sutherland e Schwaber (2013, p.9), a reunião de planejamento
do Sprint precisa responder às seguintes questões:
O que pode ser entregue como resultado do incremento do próximo
Sprint?
Como o trabalho necessário para entregar o incremento será realizado?
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 23/36
O planejamento do Sprint visa de�nir alguns pontos de alinhamento da sua
execução e controle:
O que será executado e entregue como “Pronto” do Sprint;
Quais os critérios de execução do “Pronto”;
Objetivo ou meta do Sprint.
A reunião de planejamento do Sprint é fundamental para que o time de
desenvolvimento possa entender como e quais atividades deverão ser
executadas prioritariamente para cumprir o incremento planejado para esse
Sprint. Essa reunião auxilia também no estabelecimento de metas do projeto.
Reunião Diária (Daily Meeting)
O evento Reunião diária (em muitos locais também é conhecido como Stand-up
meeting, pois em vários casos, a reunião diária acontece com os membros de pé,
para evitar o prolongamento desnecessário) do framework Scrum é realizado
diariamente, com tempo de�nido de 15 minutos (Controlado pelo Scrum
Master) para avaliar as atividades executadas no dia anterior, corrigindo
possíveis erros ou discrepâncias no planejamento anterior e planejar as
atividades que serão executadas no dia de trabalho. Possui uma característica
interessante para aumentar a produtividade: todos os dias, no mesmo horário e
local.
Segundo Sutherland e Schwaber (2013, p. 11) durante a reunião diária os
membros do time de desenvolvimento buscam esclarecer:
O que eu �z ontem que ajudou o Time de Desenvolvimento a atender a
meta do Sprint?
O que eu farei hoje para ajudar o Timede Desenvolvimento a atender a
meta do Sprint?
Eu vejo algum obstáculo que impeça a mim ou o Time de
Desenvolvimento no atendimento da meta do Sprint?
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 24/36
A principal motivação da reunião diária é inspecionar o desenvolvimento do
framework em prol do “Pronto” de�nido no Planejamento do Sprint, pois
evidencia as divergências entre o “planejado x realizado” e visa distribuir as
atividades para que os membros possam reparti-las para retomar o
planejamento. Por isso mesmo a reunião é totalmente voltada para o time de
desenvolvimento, visto que todos os membros do grupo possuem as
competências e habilidades para desenvolver todas as etapas da construção do
pronto. Essa característica não pode ser dissociada de um time autogerenciável,
competência básica dos times de desenvolvimento. O Scrum Master regula as
ações, mas não interfere na reunião, visto que é voltado para o time, também
evitando que haja interferências de outras pessoas de fora do time (como o
Product Owner, por exemplo). As reuniões diárias além dos objetivos
supracitados ainda reforçam o sentimento de unidade do time, melhoram a
comunicação, eliminam ruídos e evidenciam as barreiras para o
desenvolvimento, melhorando a capacidade de tomada de decisão
(SUTHERLAND; SCHWABER, 2013).
Revisão do Sprint (Sprint Review)
O evento Revisão do Sprint (Sprint Review) tem o objetivo de inspecionar a
iteração para veri�car o incremento realizado, para ajustar o Backlog do produto
caso não esteja de acordo com o planejado. A Revisão do Sprint é realizada ao
�nal do “time-box” do Sprint, e conta com todo o time Scrum (Scrum Master,
Product Owner e Time de desenvolvimento) e os principais stakeholders para
identi�car oportunidades de melhoria para o processo e garantir a proposta de
valor do framework. A Revisão do Sprint, cuja proposta é engajar ainda mais os
participantes do projeto, obter feedbacks e incentivar a colaboração, é um
evento informal no processo de desenvolvimento da metodologia e possui uma
duração estimada de 1h para cada semana do time-box do Sprint (controlado
rigidamente pelo Scrum Master).
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 25/36
Como proposto por Sutherland e Schwaber (2013, p.12), a reunião de revisão do
Sprint precisa abordar os seguintes elementos:
Os participantes incluem o Time Scrum e os Stakeholders-chaves
convidados pelo Product Owner;
O Product Owner esclarece quais itens do Backlog do Produto foram
“Prontos” e quais não foram “Prontos”;
O Time de Desenvolvimento discute o que foi bem durante o Sprint,
quais problemas ocorreram dentro do Sprint, e como esses problemas
foram resolvidos;
O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e
responde às questões sobre o incremento;
O Product Owner discute o Backlog do Produto tal como está. Ele (ou
ela) projeta as prováveis datas de conclusão baseado no progresso até
a data (se necessário);
O grupo todo colabora sobre o que fazer a seguir, e é assim que a
Reunião de Revisão do Sprint fornece valiosas entradas para a Reunião
de Planejamento do próximo Sprint;
Análise de como o mercado ou o uso potencial do produto pode ter
mudado e o que é a coisa mais importante a se fazer a seguir; e,
Análise da linha do tempo, orçamento, potenciais capacidades, e
mercado para a próxima versão esperada do produto.
O principal produto da reunião de retrospectiva do Sprint é a melhoria do
Backlog do produto que será executado no Sprint seguinte.
Retrospectiva do Sprint (Sprint
Retrospective)
O evento Retrospectiva do Sprint (Sprint Retrospective) é executado pelo time
Scrum sempre entre a reunião de revisão do Sprint e o planejamento do
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 26/36
próximo Sprint, com o objetivo de promover uma auditoria nos processos,
inspecionando-se com o intuito de planejar as melhorias potencialmente
aplicáveis nos próximos Sprints. Tem duração estimada de 1,5 h para cada
semana de execução do Sprint. Durante a reunião, o Scrum Master, membro
responsável pela aplicação do framework, deverá utilizar todo o seu
conhecimento sobre a metodologia para incentivar e engajar a equipe na
execução, evidenciando as vantagens da sua aplicação. A �uidez do processo é
essencial para o propósito da metodologia, e o Scrum Master possui a
responsabilidade de evidenciá-la. Para isso, durante a retrospectiva, ele deverá
enxergar os pontos falhos que podem ser melhorados, para serem
implementados nos próximos Sprints. Como um time autogerenciável, o time
Scrum precisa melhorar-se continuamente, e é na retrospectiva do Sprint que
esse ciclo �ca evidente.
O propósito da reunião de retrospectiva do Sprint é (SUTHERLAND; SCHWABER,
2013, p. 13):
Inspecionar como o último Sprint foi em relação às pessoas, aos
relacionamentos, aos processos e às ferramentas;
Identi�car e ordenar os principais itens que foram bem e as potenciais
melhorias; e,
Criar um plano para implementar melhorias no modo que o Time
Scrum faz seu trabalho.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 27/36
Os artefatos produzidos ao longo da execução do framework são os
“entregáveis” desenvolvidos para representar o valor do projeto ao usuário �nal,
ou para oferecer ao time Scrum a oportunidade de se autoavaliar ou readaptar.
São prioritariamente desenvolvidos para evidenciar a transparência do
framework e precisam ser de fácil entendimento para todos os stakeholders.
Dentre os artefatos do Scrum podemos listar o Backlog do produto, Backlog do
Sprint e incremento (SUTHERLAND; SCHWABER, 2013).
Backlog do Produto (Product Backlog)
O Backlog do produto (Product Backlog) constitui-se como um conjunto de
funcionalidades a serem cumpridas para atender aos requisitos do usuário do
produto, listando todas as características, rotinas, requisitos e mudanças
realizadas no objeto do estudo. O único responsável pela administração do
Backlog do produto sobre todos os aspectos (conteúdo, ordem e
Artefatos do ScrumArtefatos do Scrum
((Scrum ArtifactsScrum Artifacts))
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 28/36
disponibilidade) é o Product Owner. O Backlog do produto é desenvolvido
inde�nidamente e dinamicamente, na mesma proporção que o produto é
re�nado, a equipe evolui e o ambiente é favorável. A construção do Backlog do
produto é contínua, e ele perdura enquanto o produto ainda existir, visto que a
proposta de valor do Scrum só estará completa a partir da utilização do
produto, e o feedback gerado após a sua utilização deve constar no Backlog do
Produto. O desenvolvimento do produto deve seguir a ordem determinada pelo
Product Owner, e deve contemplar as mudanças ambientais as quais afetam o
diretamente o framework ou seus stakeholders, e as alterações feitas nos
produtos geram incrementos, que devem ser registrados no Product Backlog.
(SUTHERLAND; SCHWABER, 2013).
Visto que o desenvolvimento do Backlog do produto é realizado a cada
incremento no objeto em estudo, para melhor descrever e organizar as
alterações realizadas nele, apresentaremos alguns itens que podem oferecer
um detalhamento (CRUZ, 2018):
Story (estória) – Processo de desenvolvimento de um novo incremento;
ID – Identi�cação ou código de um incremento realizado no produto. É
realizado para mantermos o controle sobre as alterações realizadas;
Nome – Atribuição de uma descrição, que possa ser de fácil
compreensão por parte de todos os stakeholders, para o incremento
realizado;
Importância – Criterização (quantitativamente ou qualitativamente) do
incremento por ordem de relevância, porparte do Product Owner;
Estimativa de conclusão – Duração estimada para concretização do
incremento;
Demonstração dos resultados – Apresentação da rotina de utilização do
incremento após a entrega;
Notas explicativas.
De acordo com o Scrum Guide (SUTHERLAND; SCHWABER, 2013) no processo de
previsão e ajuste do Backlog do produto podem ser utilizadas técnicas como
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 29/36
burndown, burnup, entre outras técnicas de previsão. Entretanto, ainda não
podemos desprezar o efeito do empirismo no processo de melhoria contínua do
Backlog do produto.
Backlog do Sprint
O Backlog do Sprint reúne todos os requisitos do projeto que devem ser
cumpridos naquele Sprint especí�co, além de incluir o plano de execução para
desenvolvimento do incremento e atender as metas do Sprint. É uma espécie de
estimativa realizada pelo time de desenvolvimento sobre os requisitos que
estarão presentes no produto ao �nal do Sprint e o trabalho a ser realizado,
transformando o incremento em um “Pronto”. Ele contém um planejamento
saibamaisSaiba mais
As ferramentas burndown e burnup são
essenciais no acompanhamento do
cumprimento das metas previstas para o
Sprint, identi�car gargalos e planejar soluções.
No artigo a seguir, Canazaro, Costa e Oliveira
apresentam uma aplicação prática das
ferramentas.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 30/36
detalhado das atividades que serão apresentadas a cada reunião diária. O time
de desenvolvimento é inteiramente responsável pela construção, manutenção e
cumprimento do Backlog do Sprint, de forma a cumprir as metas
preestabelecidas. O Backlog do Sprint também tem a meta de garantir a
transparência no desenvolvimento do planejamento do Sprint além de
evidenciar potenciais falhas e oportunidades de melhorias (SUTHERLAND;
SCHWABER, 2013).
Incremento
O incremento de um produto pode ser de�nido como o conjunto de todos os
itens constantes no Backlog do produto, bem como o resultado de todos os
Sprints anteriores. Cada Sprint tem como objetivo produzir um incremento
“Pronto” utilizável ainda que não seja liberado pelo Product Owner.
Conforme falado anteriormente, um dos pilares do Scrum é a transparência, e
os seus processos precisam garantir essa virtude. O Scrum Master tem a
obrigação de, em conjunto com os demais membros do time, proporcionar a
transparência dos artefatos, em um trabalho contínuo e incessante, visto que a
tomada de decisão para aumentar o valor e o controle dos riscos contemplam o
estado em tempo real dos artefatos. Entretanto, muitas decisões erradas podem
acontecer, fazendo com que a proposta de valor ao usuário diminua,
aumentando os riscos (SUTHERLAND; SCHWABER, 2013).
Uma das características que mais demandam a transparência do framework
Scrum é a “De�nição de Pronto” (De�nition of Done – DoD). A de�nição de
“Pronto” a�rma o instante no qual um incremento ou algum item do Backlog do
produto atinge esse status para todos os membros da equipe Scrum. Essa
de�nição é essencial na metodologia, pois guia o time de desenvolvimento
sobre quais itens do Backlog do produto poderão ser realizados durante o “time-
box” do Sprint, visto que um “Pronto” precisa oferecer uma versão
“potencialmente utilizável” do produto, e cabe ao Product Owner liberá-lo ou
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 31/36
não. Caso haja mais de um time Scrum trabalhando em um determinado
projeto, todos eles devem compartilhar a mesma de�nição de “Pronto”, assim
que um determinado incremento de�nido como “Pronto”, testado e liberado, é
somado aos demais incrementos já produzidos. É importante salientar que com
o progresso do time Scrum, e a sua metodologia está altamente compreendida
pela organização, os critérios que levam a “De�nição de Pronto” são mais rígidas
e com altos padrões de qualidade.
A apresentação da metodologia evidencia uma característica fundamental para
o desenvolvimento de projetos que envolvem criatividade: a proposta de valor
para o usuário. Por isso que a metodologia Scrum tem sido aplicada nos mais
diversos planejamentos de produtos/serviços com sucesso, porque propicia um
planejamento com menos erros, transparência, menos custos e tempo para
execução, tornando-se uma excelente opção de planejamento em detrimento
do gerenciamento de projetos.
praticarVamos Praticar
Os artefatos são produtos do desenvolvimento do framework Scrum que são
produzidos ao longo de sua execução. O Backlog do produto é um deles, onde consta
o registro de todas as atividades e incrementos realizados ao longo da execução da
metodologia. Em relação ao assunto, assinale a alternativa que corresponda ao
responsável pela gerência do Backlog do produto.
a) Scrum Master.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 32/36
b) Product Owner.
c) Time de desenvolvimento.
d) Sponsor.
e) Stakeholder.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 33/36
indicações
Material
Complementar
FILME
Invictus
Ano: 2009
Comentário: O �lme relata a história real do time de
rugby sul-africano campeão da copa do mundo de Rugby,
em 1995, inspirado pelo líder da libertação do país que
sofria com o apartheid, Nelson Mandela, e liderado pelo
capitão François Pienaar, superando todas as diferenças
e evidenciando o trabalho em equipe, fundamental para
o sucesso. Uma curiosidade: O termo Scrum origina-se de
uma jogada do rugby: o scrummage.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 34/36
Para conhecer mais sobre o �lme, acesse o trailer a
seguir.
T R A I L E R
LIVRO
A arte de fazer o dobro na metade do tempo
Je� Sutherland
Editora: Leya
ISBN: 978-8544104514
Comentário: O livro apresenta a experiência de Je�
Sutherland, um dos fundadores do manifesto ágil que
revolucionou os métodos de planejamento, eliminando
os processos burocráticos, evidenciando a proposta de
valor de um projeto.
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 35/36
conclusão
Conclusão
Ao longo do nosso estudo apresentamos a metodologia de gerenciamento de
projetos ágeis chamado Scrum, cujo objetivo essencial é a proposta de valor que
o framework oferece aos seus usuários, apoiada em 3 pilares básicos:
transparência, inspeção e adaptação.
A metodologia é construída a partir do entendimento de 3 entes fundamentais:
Equipe Scrum, eventos e artefatos. A equipe Scrum é orientada pelo Scrum
Master, executada pelo time de desenvolvimento e aprovada pelo Product
Owner. Os eventos do Scrum têm por característica básica ocorrerem em
intervalos de tempo �xos, chamados “time-box” que são determinados pela
duração do Sprint, intervalo de tempo de geralmente um mês para execução de
um “Pronto”. Ao longo do seu desenvolvimento, a metodologia evidencia a
elaboração dos artefatos, que correspondem à criação e manutenção do
Backlog do produto, Backlog do Sprint e os incrementos.
Diante do exposto, podemos concluir que a metodologia Scrum possui as
características essenciais para apoiar o desenvolvimento de projetos criativos,
devido essencialmente à proposta de valor ao usuário �nal. 
referências
23/06/2021 Ead.br
https://ibmr.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_667055_1&PARE… 36/36
Referências
Bibliográ�cas
CANAZARO, J. V.; COSTA, J. V. da S.; OLIVEIRA, F. M. de. Gerenciamento ágil de
projetos com scrum e kanban: desenvolvendo competências estratégicasna
elaboração de material didático de um curso superior em EAD. REINPEC -
Revista Interdisciplinar Pensamento Cientí�co, v. 5, n. 1, p. 124-139, 2019.
CRUZ, F. Scrum e Agile em Projetos: guia completo. 2. ed. Rio de Janeiro:
Brasport, 2018.
KNAPP, J.; ZERATSKY, J.; KOWITZ, B. Sprint: o método usado no Google para
testar e aplicar novas ideias em apenas cinco dias. Rio de Janeiro: Intrínseca,
2017.
SABBAGH, R. Scrum: Gestão ágil para projetos de sucesso. [S.l.]: Casa do Código,
2014.
SUTHERLAND, J. Scrum: A arte de fazer o dobro na metade do tempo. São Paulo:
Leya, 2016.
SUTHERLAND, J.; SCHWABER, K. The Scrum Guide. The de�nitive guide to
Scrum: The rules of the game. July 2013. Disponível em:
https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf. Acesso
em: jan. 2020.
https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf