Gerenciamento+Ágil+de+Projetos+de+Desenvolvimento+de+Software_+Uma+Alternativa+ao+Gerenciamento+Tradicional

Prévia do material em texto

EDSON MESQUITA DA COSTA NETO 
 
 
 
 
 
 
 
Gerenciamento Ágil de Projetos de Desenvolvimento de Software: 
Uma Alternativa ao Gerenciamento Tradicional 
 
 
 
 
 
Trabalho apresentado ao curso MBA em 
Gerenciamento de Projetos, Pós-Graduação lato 
sensu, da Fundação Getulio Vargas como 
requisito parcial para a obtenção do Grau de 
Especialista em Gerenciamento de Projetos. 
 
 
 
 
ORIENTADOR: ARNALDO LYRIO BARRETO 
 
 
 
 
 
 
 
Salvador 
Junho / 2018 
II 
 
FUNDAÇÃO GETULIO VARGAS 
PROGRAMA FGV MANAGEMENT 
MBA EM GERENCIAMENTO DE PROJETOS 
 
 
O Trabalho de Conclusão de Curso 
 
Gerenciamento Ágil de Projetos de Desenvolvimento de Software: Uma Alternativa ao 
Gerenciamento Tradicional 
 
elaborado por Edson Mesquita da Costa Neto 
 
e aprovado pela Coordenação Acadêmica do curso de MBA em Gerenciamento de Projetos, foi 
aceito como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível 
de especialização do Programa FGV Management. 
 
 
Salvador, 27/06/2018 
 
 
André Barcaui 
Coordenador Acadêmico Executivo 
 
 
 
 
Arnaldo Lyrio Barreto 
Professor Orientador 
 
III 
 
TERMO DE COMPROMISSO 
 
 
O aluno Edson Mesquita da Costa Neto, abaixo assinado, do curso de MBA em Gerenciamento 
de Projetos, Turma (número da turma) 36 do Programa FGV Management, realizado nas 
dependências da FGV Salvador, no período de 14/10/16 a 12/05/18, declara que o conteúdo do 
Trabalho de Conclusão de Curso intitulado Gerenciamento Ágil de Projetos de 
Desenvolvimento de Software: Uma Alternativa ao Gerenciamento Tradicional é autêntico, 
original e de sua autoria exclusiva. 
 
Salvador, 27/06/2018 
 
 
Edson Mesquita da Costa Neto 
 
 
 
IV 
 
RESUMO 
 
 
As dificuldades apresentadas para o gerenciamento de projetos de desenvolvimento de software 
SCADA, trazem a necessidade de novas práticas e métodos para atender de forma satisfatória 
os projetos deste ambiente. As áreas voltadas a tecnologia da informação e engenharia são as 
que mais utilizam metodologias para gestão, contudo os projetos que apresentam problemas de 
escopo mal definido e mudanças de escopo constantes, características inerentes ao 
desenvolvimento de software, continuam apresentando índices de insucesso bem elevados. 
Com maior foco no desenvolvimento e satisfação do cliente, a abordagem ágil, embasada em 
princípios que visam a simplificação do processo de gerenciamento, surge como uma boa 
alternativa. Isto se dá pela redução da burocracia defendida pelo método tradicional e, 
principalmente, pela capacidade de se adaptar de forma mais suave para absorção de mudanças 
no escopo, mesmo quando essas acontecem no final do projeto. O Scrum, prática ágil mais 
utilizada atualmente, busca maior aproximação com o cliente, para que desta forma o mesmo 
obtenha o que realmente necessita e deseja, e assim, aumentar a taxa de sucesso desses projetos. 
Comparando a proposta de gerenciamento das duas abordagens (tradicional e ágil), a diferença 
mais notória é visualizada no planejamento. Enquanto a abordagem tradicional objetiva 
planejar detalhadamente a execução de todo projeto, a abordagem ágil visa realizar o 
planejamento por partes, priorizando o que será executado nas próximas duas ou quatro 
semanas, de forma sucessiva e constante. Além do planejamento, a cultura ágil necessita de 
mudanças organizacionais, que costuma agregar valor, mas também pode se tornar uma barreira 
para implantação, isso porque, essa cultura “dilui” o poder dos superiores e dar mais poder e 
responsabilidade para a equipe de desenvolvimento. A literatura e estudos obtidos para o 
desenvolvimento do trabalho, evidenciam que os projetos dessa natureza obtêm maior taxa 
sucesso, quando utilizam o gerenciamento ágil. 
 
 
Palavras-Chave: Projetos; Gerenciamento; Gerenciamento ágil de projetos; Scrum; SCADA. 
 
 
 
 
 
 
V 
 
ABSTRACT 
 
 
The difficulties presented for the management of SCADA software development projects bring 
the need for new practices and methods to satisfactorily fulfill the projects of this environment. 
The areas that focus on information technology and engineering are those that most use 
management methodologies, however, projects that present problems of poorly defined scope 
and constant changes of scope, characteristics inherent in software development, continue to 
present very high failure rates. With a greater focus on customer development and satisfaction, 
the agile approach, based on principles aimed at simplifying the management process, emerges 
as a good alternative. This is due to the reduction of the bureaucracy defended by the traditional 
method and, mainly, by the ability to adapt more smoothly to absorb changes in the scope, even 
when these happen at the end of the project. Scrum, the most agile practice currently used, seeks 
greater rapprochement with the client, so that it can get what it really needs and want, and thus, 
increase the success rate of these projects. Comparing the management proposal of the two 
approaches (traditional and agile), the most notorious difference is visualized in planning. 
While the traditional approach aims to plan in detail the execution of every project, the agile 
approach aims to carry out the planning in parts, prioritizing what will be executed in the next 
two or four weeks, in a successive and constant way. In addition to planning, agile culture 
requires organizational changes, which usually add value, but can also become a barrier to 
implementation, because this culture "dilutes" the power of superiors and gives more power 
and responsibility to the development team. The literature and studies obtained for the 
development of the work, show that the projects of this nature obtain a greater success rate, 
when they use the agile management. 
 
Keywords: Projects, Management, Agile project management, Scrum, SCADA. 
 
 
 
 
VI 
 
LISTA DE FIGURAS 
 
Figura 1 - Layout Sistema SCADA .......................................................................................... 11 
Figura 2 - Centro Operacional - SCADA ................................................................................. 12 
Figura 3 - Arquitetura Sistema SCADA ................................................................................... 13 
Figura 4 - Interfaces para o Usuário - SCADA ........................................................................ 14 
Figura 5 - Representação Genérica de um Ciclo de Vida do Projeto ....................................... 18 
Figura 6 - Componentes-chave do Guia PMBOK .................................................................... 20 
Figura 7 - Valores do Manifesto Ágil ....................................................................................... 29 
Figura 8 - Princípios do Scrum ................................................................................................. 32 
Figura 9 - Papéis do Scrum ...................................................................................................... 35 
Figura 10 - Artefatos do Scrum para Sprint ............................................................................. 38 
 
 
 
LISTA DE QUADROS 
 
Quadro 1 - Comparação Áreas de Conhecimento - Abordagens Tradicional e Ágil ............... 51 
 
 
VII 
 
SUMÁRIO 
 
1. INTRODUÇÃO ................................................................................................................ 9 
2. FUNDAMENTAÇÃO TEÓRICA .................................................................................. 11 
2.1. Software SCADA (Supervisory Control and Data Aquisition) ............................. 11 
2.2. Gerenciamento tradicional de projetos (PMBOK GUIDE) ................................... 14 
2.2.1. PMI e PMBOK ............................................................................................. 14 
2.2.2. Projetos .........................................................................................................15 
2.2.3. Gerenciamento de projetos ........................................................................... 16 
2.2.4. Papel do gerente de projetos (GP) ................................................................ 17 
2.2.5. Ciclo de vida do projeto ............................................................................... 17 
2.2.6. Áreas do conhecimento em gerenciamento de projetos ............................... 18 
2.2.7. Grupos de processos de gerenciamento de projetos ..................................... 19 
2.2.7.1. Grupo de processos de iniciação ............................................................. 21 
2.2.7.2. Grupo de processos de planejamento ...................................................... 22 
2.2.7.3. Grupo de processos de execução ............................................................. 24 
2.2.7.4. Grupo de processos de monitoramento e controle................................... 26 
2.2.7.5. Grupo de processos de encerramento ...................................................... 27 
2.3. Metodologia ágil de gerenciamento ...................................................................... 28 
2.3.1. Definições ..................................................................................................... 28 
2.3.2. Manifesto ágil de desenvolvimento de software .......................................... 28 
2.3.3. Métodos ágeis de desenvolvimento de software .......................................... 30 
2.4. Scrum ..................................................................................................................... 30 
2.4.1. Origem .......................................................................................................... 30 
2.4.2. Valores e princípios ...................................................................................... 31 
2.4.3. Definição ...................................................................................................... 33 
2.4.4. Papéis (equipe) ............................................................................................. 34 
2.4.4.1. Time Scrum ............................................................................................. 35 
2.4.4.2. Dono do produto (product owner) ........................................................... 36 
2.4.4.3. Scrum master ........................................................................................... 37 
2.4.5. Artefatos ....................................................................................................... 38 
2.4.5.1. Backlog do produto .................................................................................. 39 
2.4.5.2. Backlog da Sprint .................................................................................... 39 
2.4.5.3. Definição de pronto ................................................................................. 40 
2.4.5.4. Incremento do produto............................................................................. 41 
2.4.6. Eventos ......................................................................................................... 41 
2.4.6.1. Sprint ....................................................................................................... 42 
2.4.6.2. Planejamento da Sprint ............................................................................ 43 
2.4.6.3. Reunião diária .......................................................................................... 44 
2.4.6.4. Revisão da Sprint ..................................................................................... 45 
2.4.6.5. Retrospectiva da Sprint ............................................................................ 46 
3. ANÁLISE DE TÓPICOS MAIS RELEVANTES .......................................................... 47 
VIII 
 
3.1. Gerenciamento de projetos de desenvolvimento de software SCADA ................. 47 
3.2. Gerente de projetos e Scrum master ...................................................................... 47 
3.3. Gerenciamento do ciclo de vida dos projetos ........................................................ 48 
3.3.1. Iniciação ....................................................................................................... 48 
3.3.2. Planejamento ................................................................................................ 49 
3.3.3. Execução ...................................................................................................... 49 
3.3.4. Monitoramento e controle ............................................................................ 49 
3.3.5. Encerramento ............................................................................................... 50 
3.4. Gerenciamento das áreas do conhecimento em gerenciamento de projetos .......... 50 
3.5. Benefícios .............................................................................................................. 52 
3.6. Barreiras de entrada para abordagens ágeis ........................................................... 54 
4. CONSIDERAÇÕES FINAIS .......................................................................................... 55 
5. REFERÊNCIAS .............................................................................................................. 56 
9 
 
1. INTRODUÇÃO 
Percebe-se que a área de tecnologia da informação e engenharia, setores que mais possuem 
projetos de desenvolvimento de software, são as áreas que mais utilizam metodologias de 
gerenciamento de projetos (PMI, 2014). 
 
Contudo, a utilização de metodologias não garante o sucesso dos projetos, de acordo com o 
Standish Group (2016), no período de 2011 a 2015, em média, menos de 30% dos projetos de 
desenvolvimento de software podem ser considerados bem-sucedidos. 
 
Segundo o PMI (2014), 58,5% dos projetos têm problemas de escopo mal definido e 54,2% têm 
problemas com mudanças de escopo constantes. Sendo que estes pontos, são características 
inerentes aos projetos de desenvolvimento de software. 
 
Apesar da maior atenção e dedicação para o gerenciamento de projeto por parte das áreas 
voltadas a tecnologia, os índices de insucesso continuam elevados. Jeff Sutherland (2014) 
defende que investir demais no planejamento, tentando restringir mudanças e adivinhar o 
imponderável, não é muito efetivo, já que o cenário planejado nunca vira realidade. 
 
Mais que a metade dos projetos têm problemas de escopo mal definido ou com mudanças de 
escopo constantes, segundo o PMI (2014). Como indicado anteriormente, em grande parte dos 
projetos de desenvolvimento de software, os requisitos estão sujeitos a frequentes alterações de 
escopo durante o projeto. 
 
Além disso, conforme Standish Group (2016), comparando os resultados obtidos por projetos 
de desenvolvimento de software no período de 2011 a 2015, foi constatado que os projetos que 
utilizaram métodos ágeis obtiveram maior taxa de sucesso quando comparados aos projetos 
conduzidos de forma tradicional. 
 
Em vista que as metodologias ágeis absorvem as mudanças de requisitos, mesmo que estas 
ocorram próximo ao final do projeto (BECK, 2001), essas surgem como uma boa proposta para 
gerenciar os projetos de desenvolvimento de software SCADA. E como o Scrum é a 
metodologia ágil mais utilizada no mundo, segundo Version One (2017), terá maior enfoque 
neste trabalho. 
10 
 
Este trabalho está delimitado a projetos de desenvolvimento de software SCADA. Em geral, 
estes possuem muitas incertezas e estão suscetíveis a mudanças durante a execução dos 
mesmos. 
 
Para efeito deste trabalho, será realizada uma pesquisa bibliográfica sobre o tema. Além disso, 
será realizada uma análise comparativa entre o gerenciamento ágil e tradicional evidenciando 
qual destes é mais efetivo para o gerenciamento de projetos de desenvolvimento de software. 
 
Desta forma, este trabalho tem como objetivogeral realizar um estudo comparativo entre 
gerenciamento de projetos ágil e tradicional, gerando subsídios para identificação do método 
mais apropriado para o gerenciamento de projetos de desenvolvimento de software. 
 
De modo a alcançar este objetivo geral, o trabalho abordará os seguintes objetivos específicos: 
• Estudo geral sobre gerenciamento de projetos tradicional (PMBOK); 
• Estudo geral sobre metodologias ágeis de gerenciamento; 
• Estudo mais aprofundado sobre a metodologia ágil mais utilizada no gerenciamento de 
projetos; 
• Realizar uma análise comparativa entre o gerenciamento de projetos tradicional e ágil. 
 
11 
 
2. FUNDAMENTAÇÃO TEÓRICA 
2.1. Software SCADA (Supervisory Control and Data Aquisition) 
Os softwares SCADA (Supervisory Control and Data Aquisition), também conhecidos como 
Sistemas Supervisórios, têm o propósito de representar o comportamento de um processo de 
forma gráfica, tornando-se assim, uma interface objetiva entre um operador e o processo 
(URZÊDA, 2006). 
 
Segundo Boyer (2004, p.9), “SCADA é a tecnologia que permite ao usuário coletar dados de 
uma ou mais instalações à distância e enviar instruções de controle limitadas para essas 
instalações”. Desta forma, não se faz necessário que um operador permaneça ou se desloque 
constantemente para locais ou insalubres, quando essas instalações remotas estiverem operando 
normalmente, conforme pode ser visto na Figura 1. 
 
Figura 1 - Layout Sistema SCADA 
 
FONTE: HI TECNOLOGIA (2018) 
 
12 
 
Um sistema SCADA é composto de hardware e software. O hardware principal é formado por 
terminais remotos, CLP (Controlador Lógico Programável) ou UTR (Unidade Terminal 
Remota), e dispositivos de campo, atuadores e sensores. Estes em conjunto obtêm dados em 
tempo real do processo e transmitem esses dados a uma estação principal por meio de um 
sistema de comunicação (BAILEY, 2003). 
 
A estação principal contempla o software SCADA (ver Figura 2), o qual exibe os dados 
adquiridos no processo e permite que o operador monitore e execute tarefas de controle remoto. 
Os dados obtidos possibilitam a otimização da operação do processo. Além disso, o processo 
se torna mais eficiente, confiável e é operacionalizado de forma mais segura (BAILEY, 2003). 
 
Figura 2 - Centro Operacional - SCADA 
 
FONTE: SIAUTEC (2018) 
 
Para o funcionamento correto de um sistema SCADA, a automação deve ser empregada no 
processo, possibilitando a comunicação com os equipamentos de campo. Desta forma, o 
operador consegue visualizar as informações na interface gráfica, de modo a exibir a evolução 
do estado dos dispositivos e do processo controlado, permitindo informar anomalias, sugerir 
medidas a serem tomadas ou reagir automaticamente, bem como registrar todas as condições 
em bancos de dados (SILVA, 2005). 
 
13 
 
Figura 3 - Arquitetura Sistema SCADA 
 
FONTE: SILVA (2005) 
 
Segundo Urzêda (2006), O software SCADA em geral apresenta funções especificas para cada 
processo. Entretanto, existem funções básicas que estão diretamente ligadas ao conceito de 
supervisão, as quais estão disponíveis em praticamente todos os Sistemas Supervisórios, são 
elas: 
• Visualização Gráfica 
• Informação e Registro de Alarmes 
• Verificação do Status do Processo 
• Execução de Comandos para o Processo 
 
Atualmente, os sistemas de automação industrial, através dos avanços tecnológicos (de 
computação e comunicação), proporcionam otimizar a monitoração e o controle dos processos 
industriais, efetuando coleta de dados mesmo em ambientes mais complexos, e apresentando-
os de modo amigável para o operador, seja numa interface própria, mensagens via e-mail, 
celular, entre outros, como pode ser visto na Figura 4 (SILVA, 2005). 
 
 
14 
 
Figura 4 - Interfaces para o Usuário - SCADA 
 
FONTE: ELIPSE SOFTWARE (2018) 
2.2. Gerenciamento tradicional de projetos (PMBOK GUIDE) 
2.2.1. PMI e PMBOK 
O Project Management Institute (PMI), fundado em 1969 por James R. Snyder, Eric Jenett, J. 
Gordon Davis, E.A. “Ned” Engman e Susan Gallagher, foi criado com o objetivo principal de 
criar um meio para os gerentes de projeto se associarem, compartilharem informações e 
discutirem problemas comuns (PMI, 2018). 
 
Segundo Luiz (2017), o PMI é considerado a organização mais reconhecida em termos de 
promoção de práticas de gerenciamento. Além disso, outro ponto importante é o 
reconhecimento como um desenvolvedor de padrões American National Standards Institute 
(ANSI) e ser a primeira organização do segmento a ter seu programa de certificação 
reconhecido pela International Organization for Standardization (ISO) 9001. 
 
15 
 
Atualmente, o PMI é considerado a maior associação sem fins lucrativos do mundo para 
profissionais de gerenciamento de projetos, com mais de meio milhão de associados e de 
Profissionais Certificados em 185 países (PMI BRAZIL, 2018). 
 
Como dito, o PMI busca o estabelecimento de boas práticas de gerenciamento, e até o presente 
momento, sua contribuição mais expressiva direcionada ao assunto é um guia contemplando 
estas práticas, o Project Management Body of Knowledge (PMBOK). Devido a utilização 
difundida e aceitação internacional, este guia representa o modelo de gerenciamento tradicional 
de projetos. 
2.2.2. Projetos 
Segundo o PMI (2017, p.4), “projeto é um esforço temporário empreendido para criar um 
produto, serviço ou resultado único”. Diante dessa afirmativa, a primeira característica de um 
projeto, a temporariedade do empreendimento, indica que, diferentemente dos processos 
operacionais (repetitivos), os projetos devem ter um encerramento. Contudo, esta afirmação 
não implica que esta duração deva ser curta, um projeto pode ter duração de um dia ou dez anos, 
por exemplo. 
 
Outro ponto importante é quanto a exclusividade do resultado do projeto. Esta, segundo PMI 
(2017), refere-se apenas as características principais do resultado, ou seja, a repetição pode estar 
presente em algumas atividades do projeto. 
 
De forma similar ao PMI, Vargas (2008) afirma que projeto é um empreendimento sem 
repetição, caracterizado por uma sequência clara e lógica de eventos, com início, meio e fim, 
como foco em atingir um objetivo claro, num prazo pré-definido, com custos, recursos e 
parâmetros de qualidade especificados. 
 
Vargas (2009) considera ainda que os projetos atingem todos os níveis da organização, 
envolvem uma quantidade variável de pessoas (desde pequenos grupos a milhares) e tempo 
(desde menos de um dia a vários anos). Os projetos ainda, costumam extrapolar as fronteiras 
da organização, envolvendo fornecedores, clientes, parceiros e governo, e muitas vezes, buscam 
alcançar os objetivos estratégicos da organização. 
 
16 
 
Camargo (2014) afirma ainda que, apesar do PMBOK ter maior foco para projetos de grande 
porte, os projetos menores devem ser gerenciados seguindo princípios similares para que toda 
a organização de projetos da empresa trabalhe de forma consistente. 
 
Segundo PMI (2017), o encerramento do projeto é identificado na ocorrência de pelo menos 
uma das seguintes situações: 
• Os objetivos do projeto foram alcançados; 
• Os objetivos não serão ou não poderão ser cumpridos; 
• Os recursos estão esgotados ou não estão mais disponíveis para alocação ao projeto; 
• A necessidade do projeto não existe mais; 
• O projeto é finalizado por motivo legal ou por conveniência. 
2.2.3. Gerenciamento de projetos 
Segundo o PMI (2017, p.10), “gerenciamento de projetos é a aplicação de conhecimentos, 
habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir os seus requisitos”. 
Seguindo o mesmo raciocínio, para Vargas (2008), o gerenciamento de projetos é um conjunto 
de ferramentas gerenciais, e estas possibilitam que a empresa desenvolva habilidades para o 
controle de eventos não repetitivos, únicos e complexos, considerando o tempo, custo equalidade. 
 
Em geral, o gerenciamento de projetos pode ser aplicado a qualquer situação onde exista um 
empreendimento que foge ao operacional (rotineiro) na empresa. Além disso, se o 
empreendimento é único e pouco familiar, a atividade de gerenciamento de projetos deve ser 
intensificada, já que o sucesso da gestão de um projeto está intimamente ligado ao sucesso com 
que as atividades são identificadas e realizadas (VARGAS, 2009). 
 
Por fim, segundo PMI (2017), o gerenciamento de projetos é realizado através da aplicação e 
integração apropriadas dos processos de gerenciamento de projetos identificados para o projeto, 
e esta aplicação apropriada é responsabilidade do gerente de projeto (GP). 
17 
 
2.2.4. Papel do gerente de projetos (GP) 
“O gerente de projetos é a pessoa designada pela organização executora para liderar a equipe 
responsável por alcançar os objetivos do projeto” (PMI, 2017, p.552). 
 
Conforme PMI (2017), além das habilidades técnicas específicas e gerais de gerenciamento 
necessárias para o projeto, os gerentes de projetos devem possuir no mínimo os seguintes 
atributos: 
• Conhecimento sobre gerenciamento de projetos, o ambiente de negócios, aspectos 
técnicos e outras informações necessárias para administrar o projeto com eficácia; 
• Habilidades necessárias para liderar com eficácia a equipe do projeto, coordenar o 
trabalho, colaborar com as partes interessadas, solucionar problemas e tomar decisões; 
• Capacidades para desenvolver e administrar escopo, cronogramas, orçamentos, 
recursos, riscos, planos, apresentações e relatórios; 
• Outros atributos necessários para gerenciar o projeto com sucesso, como personalidade, 
atitude, ética e liderança. 
 
O PMI (2017) cita ainda que os gerentes de projetos devem apoiar-se em habilidades 
interpessoais, a exemplo de liderança, motivação, comunicação e influência, para realizar o 
trabalho esperado, através da equipe e de outras partes interessadas. 
 
Um aspecto importante de sucesso é a satisfação das partes interessadas, principalmente das 
partes mais relevantes. Além disso, para ter sucesso, o gerente do projeto deve cumprir os 
objetivos do projeto, requisitos de projeto e produto, e para isso a capacidade de adaptar a 
abordagem do projeto, o ciclo de vida e os processos de gerenciamento de projetos se fazem 
muito importante (PMI, 2017). 
2.2.5. Ciclo de vida do projeto 
“Todo projeto pode ser subdividido em determinadas fases de desenvolvimento. O 
entendimento dessas fases permite ao time do projeto um melhor controle do total de recursos 
gastos para atingir as metas estabelecidas” (VARGAS, 2009, p.28). 
 
Conforme pode ser visto na Figura 5, esse conjunto de fases é conhecido como ciclo de vida. 
18 
 
 
Figura 5 - Representação Genérica de um Ciclo de Vida do Projeto 
 
FONTE: PMI (2017) 
 
Esse ciclo fornece a estrutura básica para o gerenciamento do projeto. Segundo PMI (2017), 
esta estrutura se aplica a qualquer projeto, independentemente do seu contexto ou área de 
atuação. As fases desse ciclo podem ser sequenciais, iterativas ou sobrepostas. Outro quesito 
importante sobre o ciclo de vida é a possibilidade de avaliar uma série de similaridades que 
podem ser encontradas em outros os projetos (VARGAS, 2009). 
2.2.6. Áreas do conhecimento em gerenciamento de projetos 
O PMI (2017) define que as áreas de conhecimento são áreas de especialização que costumam 
ser aplicadas no gerenciamento de projetos. Uma área de conhecimento é um conjunto de 
processos associados com um tema específico em gerenciamento de projetos. Atualmente, são 
contempladas dez áreas de conhecimento, as quais são utilizadas na maior parte dos projetos, 
são elas: 
• Gerenciamento da integração do projeto: Processos e atividades para identificar, definir, 
combinar, unificar e coordenar os vários processos e atividades de gerenciamento dentro 
dos Grupos de Processos; 
• Gerenciamento do escopo do projeto: Processos necessários para assegurar que o 
projeto inclui todo o trabalho necessário, e apenas o necessário, para terminar o projeto 
com sucesso; 
19 
 
• Gerenciamento do cronograma do projeto: Processos necessários para gerenciar o 
término dentro do prazo do projeto; 
• Gerenciamento dos custos do projeto: Processos envolvidos em planejamento, 
estimativas, orçamentos, financiamentos, gerenciamento e controle dos custos, de modo 
que o projeto possa ser terminado dentro do orçamento aprovado; 
• Gerenciamento da qualidade do projeto: Processos para incorporação da política de 
qualidade da organização com relação ao planejamento, gerenciamento e controle dos 
requisitos de qualidade do projeto e do produto para atender as expectativas das partes 
interessadas; 
• Gerenciamento dos recursos do projeto: Processos para identificar, adquirir e gerenciar 
os recursos necessários para a conclusão bem-sucedida do projeto; 
• Gerenciamento das comunicações do projeto: Processos necessários para assegurar que 
as informações do projeto sejam planejadas, coletadas, criadas, distribuídas, 
armazenadas, recuperadas, gerenciadas, controladas, monitoradas e dispostas de 
maneira oportuna e apropriada; 
• Gerenciamento dos riscos do projeto: Processos de condução de planejamento, 
identificação e análise de gerenciamento de risco, planejamento de resposta, 
implementação de resposta e monitoramento de risco em um projeto; 
• Gerenciamento das aquisições do projeto: Processos necessários para comprar ou 
adquirir produtos, serviços ou resultados externos à equipe do projeto; 
• Gerenciamento das partes interessadas do projeto: Processos necessários para identificar 
todas as pessoas ou organizações impactadas pelo projeto, analisando as suas 
expectativas e o impacto das partes interessadas no projeto, e desenvolvendo estratégias 
de gerenciamento apropriadas para o engajamento eficaz das partes interessadas nas 
decisões e execução do projeto. 
2.2.7. Grupos de processos de gerenciamento de projetos 
Conforme indicado na Figura 6, o ciclo de vida do projeto é gerenciado através da execução de 
uma série de atividades de gerenciamento de projeto, conhecidas como processos de 
gerenciamento de projetos, os quais são agrupados nos denominados grupos de processos (PMI, 
2017). 
 
 
20 
 
Figura 6 - Componentes-chave do Guia PMBOK 
 
FONTE: PMI (2017) 
 
Cada processo possui uma ou mais entradas, que através de técnicas e ferramentas de 
gerenciamento de projetos adequadas, dão origem uma ou mais saídas. Sendo que estas saídas 
representam as entregas ou resultados do projeto (PMI, 2017). 
 
Segundo PMI (2017), um Grupo de Processos de Gerenciamento de Projetos é um agrupamento 
lógico de processos de gerenciamento de projetos para atingir os objetivos específicos do 
21 
 
projeto. Atualmente, os processos de gerenciamento de projetos são agrupados em cinco 
grupos: 
• Grupo de Processos de Iniciação; 
• Grupo de Processos de Planejamento; 
• Grupo de Processos de Execução; 
• Grupo de Processos de Monitoramento e Controle; 
• Grupo de Processos de Encerramento. 
2.2.7.1. Grupo de processos de iniciação 
A iniciação começa a partir do momento em que o projeto é selecionado, seja qual for 
necessidade (interna, estratégica ou de mercado), que culminou na aprovação do projeto, deve 
haver um plano de negócios que justifique o investimento no projeto e deixe claro quais os 
benefícios esperados com a implantação do mesmo (CAMARGO, 2014). 
 
O objetivo principal deste grupo de processos é alinhar as expectativas das partes interessadas 
com o objetivo do projeto, informar a essas partes sobre o escopo e os objetivos, bem como 
discutir como sua participação pode ajudar a garantir que suas expectativas sejam realizadas 
(PMI, 2017). 
 
Segundo Camargo (2014), a iniciação se caracteriza basicamente pela criação do Termo de 
Abertura. Esse documento é de extrema importância, pois formaliza o início dos trabalhosem 
um determinado projeto e registra as primeiras informações sobre o mesmo, contextualizando 
suas necessidades principais. 
 
Segundo PMI (2017), o projeto é autorizado oficialmente e o gerente do projeto é autorizado a 
aplicar recursos organizacionais às atividades do projeto somente quando o termo de abertura 
do projeto é aprovado. Dessa forma, somente projetos que estão alinhados com os objetivos 
estratégicos da organização são autorizados, e os benefícios e as partes interessadas são 
considerados desde o início do projeto. 
 
Conforme PMI (2017), os processos contemplados neste grupo são: 
22 
 
• Desenvolver o termo de abertura do projeto (TAP): Processo de desenvolver um 
documento que formaliza a existência de um projeto e fornece ao GP a autoridade 
necessária para aplicar recursos organizacionais às atividades do projeto; 
• Identificar as partes interessadas: Processo de identificar regularmente as partes 
interessadas do projeto, analisar e documentar informações relevantes sobre seus 
interesses, envolvimento, interdependências, influência e impacto potencial no sucesso 
do projeto. 
2.2.7.2. Grupo de processos de planejamento 
Este grupo contempla os processos necessários para definir o escopo total do esforço, 
estabelecer e refinar os objetivos, e desenvolver o curso de ação necessário para alcançar esses 
objetivos. São os processos desse grupo que desenvolvem os componentes do plano de 
gerenciamento do projeto e os documentos do projeto usados para realizar o projeto (PMI, 
2017). 
 
Um ponto importante a ressaltar é que, à medida que mais informações ou características do 
projeto são coletadas e entendidas, ou na ocorrência de mudanças significativas, pode ser 
necessário uma revisão no planejamento inicial. Esta verificação constante do plano de 
gerenciamento de projetos é denominada elaboração progressiva, que indica que o 
planejamento e a documentação são atividades iterativas ou contínuas (PMI, 2017). 
 
Segundo o PMI (2017), a versão aprovada do plano de gerenciamento do projeto, resultado de 
todos os planos gerados, é considerada uma linha de base. Esta linha de base serve 
principalmente para os processos de Monitoramento e Controle, para avaliar o desempenho do 
projeto. 
 
Conforme PMI (2007), os processos contemplados neste grupo são: 
 
• Desenvolver o plano de gerenciamento do projeto: Processo de definição, preparação e 
coordenação de todos os componentes do plano e a consolidação em um plano de 
gerenciamento integrado do projeto: 
23 
 
• Planejar o gerenciamento do escopo: Processo de criar um plano de gerenciamento do 
escopo do projeto e produto, que documenta como tal escopo será definido, validado e 
controlado: 
• Coletar os requisitos: Processo de determinar, documentar e gerenciar as necessidades 
e requisitos das partes interessadas a fim de cumprir os objetivos: 
• Definir o escopo: Processo de desenvolvimento de uma descrição detalhada do projeto 
e do produto; 
• Criar a estrutura analítica do projeto (EAP): Processo de subdivisão das entregas e do 
trabalho do projeto em componentes menores e mais facilmente gerenciáveis; 
• Planejar o gerenciamento do cronograma: Processo de estabelecer as políticas, os 
procedimentos e a documentação para o planejamento, desenvolvimento, 
gerenciamento, execução e controle do cronograma do projeto; 
• Definir as atividades: Processo de identificação e documentação das ações específicas 
a serem realizadas para produzir as entregas do projeto; 
• Sequenciar as atividades: Processo de identificação e documentação dos 
relacionamentos entre as atividades do projeto; 
• Estimar as durações das atividades: Processo de estimativa do número de períodos de 
trabalho que serão necessários para terminar atividades específicas com os recursos 
estimados; 
• Desenvolver o cronograma: Processo de analisar sequências de atividades, durações, 
necessidades de recursos e restrições de cronograma para criar o modelo de cronograma 
para execução, monitoramento e controle do projeto; 
• Planejar o gerenciamento dos custos: Processo de definir como os custos do projeto 
serão estimados, orçados, gerenciados, monitorados e controlados; 
• Estimar os custos: Processo de desenvolvimento de uma estimativa dos recursos 
monetários necessários para executar o trabalho do projeto; 
• Determinar o orçamento: Processo de agregação dos custos estimados de atividades 
individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos 
autorizada; 
• Planejar o gerenciamento da qualidade: Processo de identificação dos requisitos e/ou 
padrões de qualidade do projeto e suas entregas, e de documentação de como o projeto 
demonstrará conformidade com os requisitos e/ou padrões de qualidade; 
24 
 
• Planejar o gerenciamento dos recursos: Processo de definir como estimar, adquirir, 
gerenciar e utilizar recursos físicos e de equipe; 
• Estimar os recursos das atividades: Processo de estimar recursos da equipe, o tipo e as 
quantidades de materiais, equipamentos e suprimentos necessários para realizar o 
trabalho do projeto; 
• Planejar o gerenciamento das comunicações: Processo de desenvolver uma abordagem 
e um plano adequados para atividades de comunicação do projeto, com base nas 
necessidades de informação de cada parte interessada ou grupo, de ativos 
organizacionais disponíveis e nas necessidades do projeto; 
• Planejar o gerenciamento dos riscos: Processo de definição de como conduzir as 
atividades de gerenciamento dos riscos de um projeto; 
• Identificar os riscos: Processo de identificação dos riscos individuais do projeto, bem 
como fontes de risco geral do projeto, e de documentar suas características; 
• Realizar a análise qualitativa dos riscos: Processo de priorização de riscos individuais 
do projeto para análise ou ação posterior, através da avaliação de sua probabilidade de 
ocorrência e impacto, assim como outras características; 
• Realizar a análise quantitativa dos riscos: Processo de analisar numericamente o efeito 
combinado dos riscos individuais identificados no projeto e outras fontes de incerteza 
nos objetivos gerais do projeto; 
• Planejar as respostas aos riscos: Processo de desenvolver alternativas, selecionar 
estratégias e acordar ações para lidar com a exposição geral de riscos do projeto, e tratar 
os riscos individuais do projeto; 
• Planejar o gerenciamento das aquisições: Processo de documentação das decisões de 
compras do projeto, especificando a abordagem e identificando vendedores em 
potencial; 
• Planejar o engajamento das partes interessadas: Processo de desenvolvimento de 
abordagens para envolver as partes interessadas do projeto, com base em suas 
necessidades, expectativas, interesses e potencial impacto no projeto. 
2.2.7.3. Grupo de processos de execução 
Este grupo de processos envolve coordenar recursos, gerenciar o engajamento das partes 
interessadas, e integrar e executar as atividades do projeto em conformidade com o plano de 
gerenciamento do projeto a fim de cumprir os requisitos do projeto (PMI, 2017). 
25 
 
 
Segundo PMI (2017), os processos desse grupo podem gerar solicitações de mudança, e caso 
aprovadas, estas solicitações podem impactar em um ou mais processos de planejamento, 
resultando em modificações no plano de gerenciamento, nos documentos do projeto e 
possivelmente constituindo novas linha de base. 
 
Conforme PMI (2007), os processos contemplados neste grupo são: 
• Orientar e gerenciar o trabalho do projeto: Processo de liderança e realização do trabalho 
definido no plano de gerenciamento do projeto e implementação das mudanças 
aprovadas para atingir os objetivos do mesmo; 
• Gerenciar o conhecimento do projeto: Processo que utiliza conhecimentos existentes e 
novos para alcançar os objetivos do projeto e contribui para a aprendizagem 
organizacional; 
• Gerenciar a qualidade: Processo de transformar o planode gerenciamento da qualidade 
em atividades da qualidade executáveis que incorporam no projeto as políticas de 
qualidade da organização; 
• Adquirir recursos: Processo de obter membros da equipe, instalações, equipamentos, 
materiais, suprimentos e outros recursos necessários para concluir o trabalho do projeto; 
• Desenvolver a equipe: Processo de melhoria de competências, da interação da equipe e 
do ambiente da equipe para aprimorar o desempenho do projeto; 
• Gerenciar a equipe: Processo de acompanhar o desempenho dos membros da equipe, 
fornecer feedback, resolver problemas e gerenciar mudanças para otimizar o 
desempenho do projeto; 
• Gerenciar as comunicações: Processo de assegurar a coleta, criação, distribuição, 
armazenamento, recuperação, gerenciamento, monitoramento e disposição final das 
informações do projeto de forma oportuna e adequada; 
• Implementar respostas aos riscos: Processo de implementar planos acordados de 
resposta aos riscos; 
• Conduzir as aquisições: Processo de obtenção de respostas de vendedores, seleção de 
um vendedor e adjudicação de um contrato; 
• Gerenciar o engajamento das partes interessadas: Processo de se comunicar e trabalhar 
com as partes interessadas para atender suas necessidades e expectativas, lidar com 
questões e promover a participação das partes interessadas adequadas. 
26 
 
2.2.7.4. Grupo de processos de monitoramento e controle 
Segundo PMI (2017), este grupo de processo consiste dos processos necessários para 
acompanhar, analisar e ajustar o progresso e o desempenho do projeto. Nesse contexto, 
monitorar representa a coleta e divulgação dos dados de desempenho do projeto, enquanto 
controlar é realizar a comparação do desempenho real com o planejado, recomendando ações 
corretivas quando necessário. 
 
O objetivo das ações deste grupo de processos é, basicamente, através do acompanhamento 
periódico das atividades, identificar possíveis desvios e corrigi-los de maneira que o impacto 
no projeto seja o menor possível. 
 
Conforme PMI (2007), os processos contemplados neste grupo são: 
• Monitorar e controlar o trabalho do projeto: Processo de acompanhamento, análise e 
relato do progresso geral para atender aos objetivos de desempenho definidos no plano 
de gerenciamento do projeto; 
• Realizar o controle integrado de mudanças: Processo de revisar todas as solicitações de 
mudança, aprovar as mudanças e gerenciar as mudanças nas entregas, ativos de 
processos organizacionais, documentos do projeto e no plano de gerenciamento do 
projeto, além de comunicar a decisão sobre os mesmos. Este processo revisa todas as 
solicitações de mudança em documentos do projeto, nas entregas ou no plano de 
gerenciamento do projeto e determina a resolução das solicitações de mudança; 
• Validar o escopo: Processo de formalização da aceitação das entregas concluídas do 
projeto; 
• Controlar o escopo: Processo de monitorar o status do projeto e o escopo do produto e 
gerenciar mudanças feitas na linha de base do escopo; 
• Controlar o cronograma: Processo de monitorar o status do projeto para atualizar o 
cronograma do projeto e gerenciar mudanças na linha de base do mesmo; 
• Controlar os custos: Processo de monitoramento do andamento do projeto para 
atualização no seu orçamento e gerenciamento das mudanças feitas na linha de base de 
custos; 
• Controlar a qualidade: Processo de monitorar e registrar resultados da execução de 
atividades de gerenciamento da qualidade para avaliar o desempenho e garantir que as 
saídas do projeto sejam completas, corretas e atendam as expectativas do cliente; 
27 
 
• Controlar os recursos: Processo de garantir que os recursos físicos designados e 
alocados ao projeto estão disponíveis conforme planejado, bem como monitorar a 
utilização planejada versus utilização real de recursos e executar ação corretiva 
conforme necessário; 
• Monitorar as comunicações: Processo de garantir que as necessidades de informação do 
projeto e de suas partes interessadas sejam atendidas; 
• Monitorar os riscos: Processo de monitorar a implementação de planos acordados de 
resposta aos riscos, rastrear riscos identificados, identificar e analisar novos riscos, e 
avaliar a eficácia do processo de risco ao longo do projeto; 
• Controlar as aquisições: Processo de gerenciar relacionamentos de aquisições, 
monitorar o desempenho do contrato, fazer alterações e correções conforme apropriado, 
e encerrar contratos; 
• Monitorar o engajamento das partes interessadas: Processo de monitorar as relações das 
partes interessadas do projeto e adaptação de estratégias para engajar as partes 
interessadas através da modificação de planos e estratégias de engajamento. 
2.2.7.5. Grupo de processos de encerramento 
O processo de encerramento pode ser resumido em um fechamento administrativo do projeto, 
que irá também deixar registros para projetos futuros. Este fechamento exige do gerente de 
projeto uma atenção a integração das diversas áreas de conhecimento do projeto, já que tudo 
tenha deve ser concluído, sem pendências (CAMARGO, 2014). 
 
Segundo PMI (2017), este grupo de processos contempla apenas um processo, necessário para 
encerrar formalmente e adequadamente um projeto, fase ou contrato. Contudo, apesar de haver 
apenas um processo, as organizações podem ter procedimentos próprios associados ao 
encerramento do projeto, fase ou contrato. 
 
Conforme PMI (2007), o processo contemplado neste grupo o encerrar o projeto ou fase. Este 
processo é responsável por finalizar todas as atividades do projeto, fase ou contrato. 
28 
 
2.3. Metodologia ágil de gerenciamento 
2.3.1. Definições 
O nome “ágil” foi escolhido para representar um movimento que surgiu em meados dos anos 
90 em resposta aos métodos pesados para o gerenciamento de desenvolvimento de software que 
predominavam na época (SABBAGH, 2013). 
 
Seguindo este pensamento, Conforto (2009, p.36) definiu que “o gerenciamento ágil de projetos 
é uma abordagem fundamentada em um conjunto de princípios, cujo objetivo é tornar o 
processo de gestão de projetos simples, flexível e iterativo”. Além disso, o gerenciamento ágil 
busca adaptar as práticas de gerenciamento existentes para aplicação em ambientes dinâmicos, 
com elevados níveis de incertezas e complexidade. 
 
Nota-se que o gerenciamento de projetos através de metodologias ágeis, possui algumas 
características fortes, como a necessidade de flexibilidade e habilidade para absorver mudanças 
durante o ciclo de vida do projeto e o enfoque mais humanista, apoiado com o desenvolvimento 
da equipe de projeto, a valorização do aprendizado contínuo, valorizando mais os indivíduos 
que as técnicas e processos de gestão de projetos (CONFORTO, 2009). 
 
Em resumo, para ser “ágil”, um determinado método, metodologia ou framework, deve seguir 
os princípios e valores contidos no Manifesto Ágil de Desenvolvimento de Software. 
2.3.2. Manifesto ágil de desenvolvimento de software 
No ano de 2001, numa estação de esqui das montanhas de Wasatch, em Utah, dezessete 
especialistas em projetos de desenvolvimento de software se encontraram e discutiram a 
necessidade de uma alternativa aos processos de desenvolvimento de software, os quais eram 
pesados e burocráticos. Deste encontro, nasceu o manifesto ágil de desenvolvimento de 
software (HIGHSMITH, 2001). 
 
Segundo Beck (2001), nesse manifesto, os autores informam que estão descobrindo, de forma 
conjunta, as melhores maneiras para o desenvolvimento de softwares. Deste trabalho, eles 
frisaram quatro valores, os quais podem ser observados na Figura 7. 
29 
 
 
Figura 7 - Valores do Manifesto Ágil 
 
FONTE: ASR(2018) 
 
Segundo Beck (2001), mesmo havendo valor nos itens à direita, os itens à esquerda são mais 
valorizados. Sendo assim, pode-se observar que a relação interpessoal é mais valorizada que a 
burocracia, atender os anseios do cliente se torna fundamental.Além dos valores supracitados, Beck (2001) divulgou também os doze princípios do manifesto: 
• “Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada 
de software com valor agregado.” 
• “Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. 
Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o 
cliente.” 
• “Entregar frequentemente software funcionando, de poucas semanas a poucos meses, 
com preferência à menor escala de tempo.” 
• “Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por 
todo o projeto.” 
• “Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte 
necessário e confie neles para fazer o trabalho.” 
• “O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de 
desenvolvimento é através de conversa face a face.” 
30 
 
• “Software funcionando é a medida primária de progresso.” 
• “Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, 
desenvolvedores e usuários devem ser capazes de manter um ritmo constante 
indefinidamente.” 
• “Contínua atenção à excelência técnica e bom design aumenta a agilidade.” 
• “Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial.” 
• “As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.” 
• “Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então 
refina e ajusta seu comportamento de acordo.” 
 
Existem diversas práticas ágeis sendo aplicadas e desenvolvidas para o gerenciamento de 
projetos desde o manifesto, dentre elas o Scrum, o qual segundo PMI (2014), é a metodologia 
ágil mais utilizada para o gerenciamento de projetos e foco deste trabalho. 
2.3.3. Métodos ágeis de desenvolvimento de software 
Ao longo dos anos, diversos métodos ágeis foram desenvolvidos e implantados. Dentre os 
principais, podem ser citados: Extreme Programming, Scrum, Dynamic Systems Development 
Method, Adaptative Software Development, Crystal Method, Feature-Driven Development e 
Lean Development (DIAS, 2005). 
 
Devido ao Scrum ser a prática ágil mais utilizada no gerenciamento de projetos, dados de 
Standish Group (2016), esta abordagem tem maior destaque neste trabalho. 
2.4. Scrum 
2.4.1. Origem 
Com base em estudos de caso de diversas industrias, em meados dos anos 80, Hirotaka 
Takeuchi e Nonaka Ikujiro definiram uma abordagem para o desenvolvimento de produtos, 
denominada de abordagem holística. Esta abordagem propõe que o desenvolvimento do 
produto não deve ser como uma sequência de eventos, mas sim semelhante ao jogo de rugby, 
em que o time trabalha em conjunto, como uma unidade (SCRUMstudy, 2017). 
 
31 
 
O primeiro time de Scrum foi criado por Jeff Sutherland em 1993, quando Jeff Sutherland 
trabalhava numa empresa de software, a Easel Corporation. Por acreditar que o modo de 
gerenciar projetos de software na época estava “quebrado”, o mesmo aplicou uma outra 
abordagem no projeto mais crítico da organização, o Scrum. Os resultados obtidos com este 
novo modelo foram expressivos (SUTHERLAND, 2014). 
 
Em 1995, Jeff Sutherland apresentou o primeiro time de Scrum a Ken Schwaber, na época CEO 
da empresa Advanced Development Methods, que estava focado em abordagens empíricas para 
o desenvolvimento de software, e com a similaridade de ideias, ambos trabalharam juntos para 
criar uma dentição formal do Scrum, apresentada na conferência Object Oriented 
Programming, Systems, Languages & Applications (OOPSLA) em Austin, Texas, nesse mesmo 
ano (SABBAGH, 2013). 
 
Já em 2001, Jeff Sutherland e Ken Schwaber foram signatários do manifesto ágil. Como dito 
anteriormente, esse manifesto deu início ao chamado movimento ágil, do qual Scrum faz parte. 
Segundo Sabbagh (2013), nesse mesmo ano, Ken Schwaber publicou o primeiro livro a 
descrever o framework Scrum, o Agile software Development with Scrum. 
2.4.2. Valores e princípios 
Segundo SCRUMstudy (2017), os princípios do Scrum são as diretrizes fundamentais para a 
aplicação do framework e devem obrigatoriamente serem usados em todos os projetos Scrum. 
 
Os seis princípios do Scrum são: 
• Controle de processos empíricos: Esse princípio enfatiza a filosofia central do Scrum; 
• Auto-organização: Esse princípio está focado nos colaboradores atuais de uma 
organização, que entregam um maior valor quando são auto-organizados e isto resulta 
em times mais satisfeitos e produtivos; 
• Colaboração: Esse princípio concentra-se nas três dimensões básicas relacionadas com 
o trabalho colaborativo (consciência, articulação e apropriação). Dessa forma, defende 
que o gerenciamento de projetos é um processo de criação de valor compartilhado, com 
times trabalhando e interagindo em conjunto para atingirem melhores resultados; 
• Priorização baseada em valor: Esse princípio destaca o foco do Scrum em entregar o 
máximo de valor de negócio possível, durante todo o projeto; 
32 
 
• Time-boxing: Esse princípio descreve como o tempo é considerado uma restrição 
limitada em Scrum e como ele é usado para ajudar a gerenciar o planejamento e 
execução do projeto com eficácia; 
• Desenvolvimento iterativo: Esse princípio define o desenvolvimento iterativo e enfatiza 
como administrar melhor as mudanças e criar produtos que atendam às necessidades do 
cliente. 
 
Figura 8 - Princípios do Scrum 
 
FONTE: SCRUMstudy (2017) 
 
Já os cinco valores do Scrum são: foco, coragem, franqueza, compromisso e respeito (SCRUM 
ALLIANCE, 2016): 
• Foco: Porque nos concentramos em apenas algumas coisas de cada vez, trabalhamos 
bem juntos e produzimos um excelente trabalho. Nós entregamos itens valiosos mais 
cedo; 
• Coragem: Por trabalharmos em equipe, nos sentimos apoiados e temos mais recursos à 
nossa disposição. Isso nos dá coragem para enfrentar maiores desafios; 
• Abertura: Enquanto trabalhamos juntos, expressamos como estamos fazendo, o que está 
em nosso caminho e nossas preocupações para que possam ser abordados; 
• Comprometimento: Porque temos grande controle sobre nosso próprio destino, estamos 
mais comprometidos com o sucesso; 
33 
 
• Respeito: À medida que trabalhamos juntos, compartilhando sucessos e fracassos, 
passamos a respeitar uns aos outros e a nos ajudar mutuamente a sermos dignos de 
respeito. 
 
É possível observar que os valores e princípios do Scrum se assemelham aos descritos sobre 
Metodologias Ágeis pelo Manifesto Ágil, o que evidencia que o Scrum é uma abordagem Ágil. 
2.4.3. Definição 
O Scrum é um framework para gestão de projeto, e não uma metodologia ou um conjunto de 
processos, ou seja, uma estrutura básica que pretende servir de suporte e guia para a construção, 
que não define práticas específicas e detalhadas a serem seguidas (SABBAGH, 2013). 
 
Carvalho (2012) também sugere que este método não requer ou fornece qualquer técnica 
específica para o desenvolvimento, apenas estabelece conjuntos de regras e práticas gerenciais 
que devem ser adotadas para conduzir um projeto. 
 
Seguindo o mesmo pensamento, Schwaber (2017) define Scrum como um framework estrutural 
dentro do qual você pode ser empregado vários processos e técnicas. O Scrum deixa claro a 
eficácia relativa de suas práticas de gerenciamento de produto e técnicas de trabalho, de modo 
que você possa melhorar de forma contínua o produto, o time e o ambiente de trabalho. 
 
Sendo assim, o Scrum entende que as práticas necessárias para o sucesso do projeto são muito 
específicas para cada contexto. Sendo assim, não existe um passo-a-passo que funcione para 
qualquer situação. A ideia é que a partir dos papéis, eventos, artefatos e regras, as pessoas 
possam avaliar, adquirir e desenvolver um conjunto de práticas que melhor lhe servirão. Esse é 
um trabalho contínuo de descoberta, inspeção e adaptação (SABBAGH, 2013). 
 
Schwaber (2017) afirmaainda que o Scrum é fundamentado nas teorias empíricas de controle 
de processo, ou seja, o conhecimento é obtido da experiência e de tomada de decisões baseadas 
no que já é conhecido. Esta abordagem é apoiada por três pilares: 
• Transparência: Aspectos significativos do processo devem estar visíveis aos 
responsáveis pelos resultados; 
34 
 
• Inspeção: Os usuários devem, frequentemente, inspecionar os artefatos do Scrum e o 
progresso em direção ao objetivo da Sprint buscando detectar variações indesejadas; 
• Adaptação: Se um inspetor determina que um ou mais aspectos de um processo desviou 
para fora dos limites aceitáveis, o processo ou o material sendo produzido deve ser 
ajustado. 
 
O Scrum é livre, mas apesar disso, os papéis, eventos, artefatos e regras são imutáveis, e embora 
seja possível implementar somente partes do Scrum, o resultado não é Scrum. Scrum existe 
somente na sua totalidade e funciona bem como um suporte para outras técnicas, metodologias 
e práticas (SCHWABER, 2017). 
2.4.4. Papéis (equipe) 
Um dos pontos importantes do Scrum é com relação ao tamanho da equipe. Diversos autores 
afirmam que a dinâmica da equipe só funciona bem em grupos pequenos. Schwaber (1995) 
defende que cada equipe não deve possuir mais de seis membros, podendo haver várias equipes 
em um projeto. Já Sutherland (2014) afirma que o número ideal é sete, concedendo uma 
variação de duas pessoas a mais ou a menos. Sem fugir muito dos outros autores, o 
SCRUMStudy (2017) declara que o tamanho ideal é de seis a dez membros. 
 
Ainda segundo Sutherland (2014), dados indicam que se a equipe tiver mais do que nove 
pessoas, a velocidade costuma cair, inclusive o mesmo relata que já viu equipes de três 
membros atingirem alto nível de funcionamento, ou seja, chega um ponto que mais recursos 
tornam a equipe mais lenta. 
 
Segundo o SCRUMstudy (2017), entender os papéis definidos e suas responsabilidades em um 
projeto Scrum é o primeiro passo, e talvez o mais importante, para garantir o sucesso na 
implementação. Como pode ser observado na Figura 9, a equipe é composta pelo dono do 
produto (Product Owner), Scrum master e time Scrum (ou time de desenvolvimento). 
 
 
35 
 
Figura 9 - Papéis do Scrum 
 
FONTE: SCRUMstudy (2017) 
2.4.4.1. Time Scrum 
Também conhecido como time de desenvolvimento, o time Scrum é responsável pelo 
desenvolvimento do produto, serviço ou de outro resultado. Trata-se de um grupo 
multidisciplinar de indivíduos que trabalham no backlog da Sprint para criar as entregas para o 
projeto (SCRUMSTUDY, 2017). 
 
Segundo Sabbagh (2017, p.81), “a partir das prioridades definidas pelo product owner, o time 
de desenvolvimento gera, em cada Sprint, um incremento do produto pronto, de acordo com a 
definição de pronto, e que significa valor visível para os clientes do projeto”. 
 
O trabalho de desenvolvimento do produto é gerenciando pelo próprio time Scrum. A equipe 
planeja o trabalho, determina tecnicamente como o produto será desenvolvido e acompanha seu 
progresso. Para que isso funcione, a equipe deve ter autoridade sobre suas decisões e, ao mesmo 
tempo, responsabilidade pelos resultados (SABBAGH, 2013). 
 
36 
 
Seguindo o Raciocínio, Schwaber (2017), afirma que a equipe é totalmente responsável pelo 
desenvolvimento da funcionalidade, ou seja, as equipes são autogeridas, auto-organizadas e 
multifuncionais. Sendo assim, o time é responsável por descobrir como transformar o backlog 
do produto em um incremento, gerenciando seu próprio trabalho para isso. 
 
Times multifuncionais tendem a possuir as competências necessárias para executar o trabalho 
sem depender de outros que não fazem parte da equipe. Dessa forma, o time é projetado para 
aperfeiçoar a flexibilidade, criatividade e produtividade (SCHWABER, 2017). 
 
Times Scrum entregam produtos de forma iterativa e incremental, maximizando as 
oportunidades para feedback. Entregas incrementais de produto pronto garantem que uma 
versão potencialmente funcional do produto do trabalho esteja sempre disponível 
(SCHWABER, 2017). 
2.4.4.2. Dono do produto (product owner) 
O dono do produto representa os interesses dos stakeholders para o time Scrum. Sendo assim, 
esse é responsável por garantir uma comunicação clara sobre requisitos de funcionalidade do 
produto ou serviço, os critérios de aceitação (definição de pronto), e o cumprimento desses 
critérios, a entrega de valor (SCRUMSTUDY, 2017). 
 
O dono do produto obtém o financiamento do projeto, criando os requisitos gerais iniciais do 
projeto, os objetivos de retorno do investimento e os planos de liberação. A lista de requisitos 
é chamada de backlog do produto, e o dono do produto deve garantir que a funcionalidade que 
entregue mais valor seja produzida primeiro, enfileirando os requisitos mais valiosos para a 
próxima iteração (SCHWABER, 2007). 
 
Este membro do time além de representar o cliente (interno ou externo), necessita conhecer 
muito bem as regras e objetivos de negócios do cliente, de forma que ele possa priorizar as 
funcionalidades do produto de forma correta, bem como esclarece qualquer dúvida que o time 
possa ter em relação a essas funcionalidades (CARVALHO, 2012). 
 
O dono do produto deve manter um contato frequente com os clientes e demais partes 
interessadas ao longo de todo o projeto, desta forma o mesmo consegue fazer o levantamento 
37 
 
correto dos objetivos ou necessidades de negócios mais prioritárias do produto em cada 
momento (SABBAGH, 2013). 
 
O dono do produto pode fazer o trabalho acima, ou delegar para o time de desenvolvimento 
fazê-lo. No entanto, independente da opção, ele continua sendo o responsável pelos trabalhos. 
 
Outro ponto importante é que o dono do produto é um indivíduo e não um comitê. Ou seja, para 
que esse membro tenha sucesso, toda a organização deve respeitar as decisões tomadas por ele. 
Essas decisões são visíveis no conteúdo e na priorização do backlog do produto. As prioridades 
podem até ser tratadas com o mesmo, mas ninguém pode forçar o time de desenvolvimento a 
trabalhar em um diferente conjunto de requerimentos (SCHWABER, 2017). 
2.4.4.3. Scrum master 
O Scrum master é o "líder servidor" do time, sua função é basicamente facilitar a interação do 
time, agindo como motivador e mentor. O Scrum master também é responsável por garantir 
que o time tenha um ambiente de trabalho produtivo, removendo qualquer impedimento e 
protegendo o time de influências externas, para dessa forma maximizar o valor criado 
(SCRUMSTUDY, 2017). 
 
De forma similar, Shuterland (2014, p.39) diz que o Scrum master “não era um gerente, e sim 
um líder da equipe, algo entre um capitão e um treinador”, ou seja, a função do Scrum master 
não é dar ordens ou delegar, mas sim potencializar o trabalho, motivar os membros e encontrar 
soluções para os impedimentos que surjam. 
 
Para que não existam impedimentos para o desenvolvimento durante a Sprint, o Scrum master 
interage com os membros da equipe na reunião diária para obtê-los. Com já dito, remover os 
obstáculos apontados é seu dever, de modo que os desenvolvedores se concentrem apenas nas 
questões técnicas (CARVALHO, 2012). 
 
Outra responsabilidade do Scrum master é manter o processo Scrum, ou seja, ensinar a todos 
os envolvidos no projeto, principalmente recém-chegados, como proceder para que ele se 
encaixe na cultura de uma organização e ainda forneça os benefícios esperados, bem como 
garantir que todos sigam as regras e práticas definidas (SCHWABER, 2007). 
38 
 
2.4.5. Artefatos 
Segundo Schwaber (2017, p.14), “os artefatos do Scrum representam o trabalho ou o valor para 
o fornecimento de transparência e oportunidades para inspeção e adaptação”. Esses artefatos 
são como processos, projetados para maximizar a transparência das informações, de forma que 
todos tenham o mesmo entendimento dos artefatos. 
 
A transparência é de sumaimportância, já que as decisões de otimização de valor e o controle 
de riscos são tomadas com base na percepção do estado dos artefatos. Em caso desses artefatos 
não serem completamente transparentes, estas decisões podem ser falhas, valores podem 
diminuir e riscos podem aumentar (SCHWABER, 2017). 
 
Como pode ser visto na Figura 10, originalmente, o Scrum define o uso de quatro artefatos: O 
backlog do produto, o backlog da Sprint, a definição de pronto e o incremento do produto 
(SABBAGH, 2013). 
 
Figura 10 - Artefatos do Scrum para Sprint 
 
FONTE: ASR (2018) 
39 
 
2.4.5.1. Backlog do produto 
No Scrum, o dono do produto, responsável pelo backlog do produto, busca através de reuniões 
com todas as partes interessadas, identificar todas as necessidades do negócio e as 
funcionalidades necessárias que devem ser desenvolvidas. Dessa forma, o backlog do produto 
é uma lista de funcionalidades, ordenadas por prioridade, que provavelmente serão 
desenvolvidas durante o projeto (CARVALHO, 2012). 
 
Sabbagh (2013) reafirma que o backlog do produto é uma lista de tudo o que se acredita que 
será desenvolvido pelo time de desenvolvimento no decorrer do projeto. Isso porque, esta lista 
pode ser, e possivelmente será, atualizada, já que essa lista é ordenada de acordo com a 
importância para os clientes do projeto, e o feedback, torna essa lista maior e mais completa. 
 
Para Schwaber (2017), essa lista é a única origem dos requisitos para qualquer mudança a ser 
feita no produto. Ou seja, essa lista nunca está completa. As primeiras Sprints estabelecem os 
requisitos iniciais, a evolução do produto e o ambiente no qual ele será utilizado tornam o 
backlog do produto dinâmico, um artefato vivo, mudando sempre para identificar o que o 
produto necessita para ser mais apropriado, competitivo e útil. 
 
 “O product backlog é a única fonte de trabalho a ser realizado no produto pelo time de 
desenvolvimento. Esse trabalho também inclui as correções de problemas encontrados no 
sistema” (SABBAGH, 2013, p.112). 
2.4.5.2. Backlog da Sprint 
Segundo Schwaber (2017, p.15), “o backlog da Sprint é um conjunto de itens do backlog do 
produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do 
produto e atingir o objetivo da Sprint”. Basicamente o backlog da Sprint é a previsão de quais 
funcionalidades serão entregues no próximo incremento. 
 
A definição do backlog da Sprint acontece durante a reunião de planejamento da Sprint. E torna 
visível todo o trabalho que o time de desenvolvimento identifica como necessário para atingir 
o objetivo dessa Sprint (CARVALHO, 2012). 
 
40 
 
Um ponto importante é que somente o time de desenvolvimento pode alterar o backlog da Sprint 
durante a Sprint. Isso ocorre na percepção de que um novo trabalho é necessário ou quando 
elementos planejados são considerados desnecessários. Estes itens demonstram uma imagem 
em tempo real do trabalho que o time planeja completar durante a Sprint (SCHWABER, 2017). 
 
Essa lista de itens é escolhida pelo time de desenvolvimento e negociada com o dono do produto 
no planejamento da Sprint, contemplando os itens prioritários do backlog do produto. Para 
construí-la, o time busca obter detalhes suficientes e necessários com o dono do produto para 
ser capaz de escolher uma quantidade de itens que preencha sua capacidade de trabalho em uma 
Sprint (SABBAGH, 2013). 
 
Durante a Sprint, por vezes, o total do trabalho remanescente dos itens do backlog da Sprint é 
verificado, com o objetivo de monitorar o total do trabalho restante pelo menos a cada reunião 
diária, desta forma é possível projetar a probabilidade de alcançar o objetivo da Sprint, e o time 
de desenvolvimento pode gerenciar o seu próprio progresso (SCHWABER, 2017). 
2.4.5.3. Definição de pronto 
A definição de pronto para o time Scrum é usada para assegurar quando o trabalho está 
finalizado no incremento do produto. Sendo assim, o propósito do time de desenvolvimento é 
entregar ao final de cada Sprint incrementos de funcionalidades potencialmente liberáveis que 
aderem à definição atual de pronto (SCHWABER, 2017). 
 
A responsabilidade de aceitar a funcionalidade como pronta é do dono do produto. A definição 
de pronto é um acordo formal entre dono do produto e time de desenvolvimento, o qual estipula 
o que é necessário para se considerar que um trabalho realizado durante a Sprint está aprovado. 
São, portanto, critérios definidos em conjunto para garantir a transparência do que está sendo 
realizado e entregue (SABBAGH, 2013). 
 
Após a entrega de um incremento, este é adicionado aos incrementos anteriores e testado, de 
forma a garantir que todos os incrementos funcionam juntos. Acredita-se que com o 
amadurecimento do time, a definição de pronto inclua critérios mais rigorosos de qualidade. 
Quando esses novos critérios são aplicados, pode ser constatada a descoberta de trabalho a ser 
realizado em incrementos considerados prontos anteriormente (SCHWABER, 2017). 
41 
 
2.4.5.4. Incremento do produto 
O incremento é a soma de todos os itens completos do backlog do produto durante a Sprint. Ao 
final de cada Sprint, um novo incremento deve estar pronto. Um incremento é uma parte 
principal inspecionável de trabalho. O time de desenvolvimento deve sempre disponibilizar um 
incremento na condição de ser utilizado, independente da liberação ou não do mesmo pelo dono 
do produto (SCHWABER, 2017). 
 
Reforçando, Sabbagh (2013) afirma que é esperado um incremento do produto entregável 
sempre, de forma que o dono do produto possa decidir por fazer um lançamento para os clientes 
do projeto ao final da Sprint. No entanto, o dono do produto pode optar por acumular alguns 
incrementos do produto para posteriormente fazer o lançamento. 
 
A opção de não entregar o incremento ao final da Sprint, pode ser pelo fato do mesmo não 
representar valor suficiente para ser utilizado por seus usuários, ou ainda representar valor 
suficiente, mas os clientes podem não conseguir absorver com tanta frequência as mudanças, 
ou mesmo por questões políticas, burocráticas ou técnicas (SABBAGH, 2013). 
2.4.6. Eventos 
Os eventos prescritos no Scrum são utilizados para criar uma padronização, regularidade e 
minimizar a necessidade de reuniões não definidas. Todos os eventos são eventos time-boxed, 
ou seja, todos possuem uma duração máxima estipulada. Para a Sprint sua duração é fixa e não 
pode ser reduzida e nem aumentada. Os demais eventos não possuem duração mínima, e podem 
ser finalizados quando o propósito do evento é alcançado, evitando desperdícios no processo 
(SCHWABER, 2017). 
 
Vale ressaltar que todos os eventos representam uma oportunidade de inspecionar e adaptar 
algo. Os eventos são projetados para permitir uma transparência e inspeção criteriosa a qualquer 
momento. Sendo assim, falhas na implantação de qualquer um destes eventos resultará na 
redução da transparência e consequentemente na perda de oportunidades de inspecionar e 
adaptar (SCHWABER, 2017). 
 
42 
 
“Os eventos do Scrum são o próprio ciclo de desenvolvimento, chamado de Sprint, e as reuniões 
ou cerimônias realizadas durante o ciclo, que são: Planejamento da Sprint, reunião diária, 
revisão da Sprint e retrospectiva da Sprint” (SABBAGH, 2013, p.193). 
2.4.6.1. Sprint 
Segundo Schwaber (2017, p.8), “o coração do Scrum é a Sprint, um time-boxed de um mês ou 
menos, durante o qual um pronto, incremento de produto potencialmente liberável é criado”. 
As Sprints têm durações fixadas, normalmente, entre 2 e 4 semanas. Uma nova Sprint sempre 
inicia imediatamente após a finalização da última. 
 
Cada Sprint pode ser tratada como um pequeno projeto. A duração limitada a um mês busca 
eliminar alguns possíveis problemas, por exemplo a definição do que será realizado pode 
mudar, a complexidade pode aumentar e o risco pode crescer. A ideia é que dessa forma, asSprints possibilitem maior previsibilidade, o que garante a inspeção e adaptação do progresso 
em direção à meta, bem como limita o risco do custo a um mês (SCHWABER, 2017). 
 
Como qualquer projeto, as Sprints são utilizadas para alcançar algo, nesse caso, a meta da 
Sprint. Os itens a serem desenvolvidos durante a Sprint são os mais importantes para aquele 
momento, negociados e selecionados de forma a fazerem sentido juntos. Cada Sprint tem uma 
meta do que é para ser realizado, um plano previsto que irá guiar o trabalho e o produto 
resultante (SABBAGH, 2013). 
 
Como dito, a meta da Sprint é um objetivo definido durante a reunião de planejamento da Sprint. 
Esta tem o propósito de fornecer ao time de desenvolvimento alguma flexibilidade a respeito 
da funcionalidade que será entregue ao final da Sprint, bem como uma direção sobre o porquê 
de estar construindo o incremento, incentivando ao time trabalhar em conjunto ao invés de 
buscarem iniciativas separadas (SCHWABER, 2017). 
 
Em algumas condições, uma Sprint pode ser cancelada antes do término do time-boxed. Assim, 
a Sprint pode ser cancelada se o objetivo da mesma se tornar obsoleto, ou se ela não faz mais 
sentido às dadas circunstâncias, seja por uma mudança na direção da organização, ou até mesmo 
mudança nas condições do mercado e/ou das tecnologias (SCHWABER, 2017). 
 
43 
 
Segundo Schwaber (2017), somente o dono do produto possui a autoridade para cancelar uma 
Sprint, embora ele possa sofrer influência das partes interessadas, do time de desenvolvimento 
ou do Scrum master para tal. Quando a Sprint é cancelada, qualquer item de backlog do produto 
completado e antes definido como pronto deve ser revisado. 
2.4.6.2. Planejamento da Sprint 
Conforme já visto, o planejamento de um ciclo de desenvolvimento, ou seja, de uma Sprint, é 
realizado na reunião de planejamento da Sprint. Esta reunião é realizada no primeiro momento 
do primeiro dia da Sprint (SABBAGH, 2013). 
 
Esse planejamento conta com a participação obrigatória do dono do produto e dos membros do 
time de desenvolvimento. Eles decidem de forma colaborativa o que será desenvolvido e qual 
a meta desse Sprint. Todos os membros do time possuem igual poder de opinião e decisão. Essa 
reunião também conta com a participação do Scrum master, o qual atua como um facilitador 
(SABBAGH, 2013). 
 
O Scrum master garante que o evento ocorra e que os participantes entendam seu propósito, 
bem como ensina o time Scrum a manter-se dentro dos limites do time-box. Quando a Sprint 
tem duração de um mês, o time-boxed do planejamento da Sprint é oito horas. Para Sprints 
menores, este evento é usualmente menor (SCHWABER, 2017). 
 
Enquanto, o dono do produto debate o objetivo que a Sprint deve realizar e os itens de backlog 
do produto que, se completados durante a Sprint, atingirão o objetivo da mesma. O time de 
desenvolvimento trabalha para prever quais funcionalidades serão desenvolvidas durante a 
Sprint, define o número de itens selecionados do backlog do produto e avalia o que pode ser 
completado ao longo dessa Sprint (SCHWABER, 2017). 
 
Além disso, no final do planejamento da Sprint, o time de desenvolvimento deve explicar ao 
dono do produto e ao Scrum master como pretende trabalhar para alcançar o objetivo da Sprint 
e criar o incremento previsto (SCHWABER, 2017). 
44 
 
2.4.6.3. Reunião diária 
A reunião diária facilita a auto-organização do time de desenvolvimento e, assim, sua realização 
é de grande importância. Esta tem por objetivos proporcionar maior visibilidade ao trabalho 
realizado e a realizar, promover a comunicação sobre esse trabalho, identificar quais obstáculos 
atrapalham ou atrapalharam o desenvolvimento desde a última reunião. Sendo, o resultado 
dessa um plano informal para o trabalho do time até a próxima reunião (SABBAGH, 2013). 
 
Segundo Schwaber (2017), a estrutura básica da reunião pode ser definida por três perguntas: 
• O que eu fiz ontem que ajudou a atingir a meta da Sprint? 
• O que eu farei hoje para ajudar a atingir a meta da Sprint? 
• Eu vejo algum obstáculo que impeça a mim ou o time no atingimento da meta da Sprint? 
 
No entanto, a reunião diária não deve ser vista como forma de prestar contas a uma gerência, 
mas sim como formalização do comprometimento com o resto da equipe. Dessa forma, todos 
os membros do time conhecem as metas e o andamento do trabalho cada integrante, bem como 
os impedimentos (riscos) que podem atingir ao membro ou ao time como todo (CARVALHO, 
2012). 
 
Como o próprio nome sugere, esta reunião é realizada em todos os dias da Sprint. Ela possui 
um time-boxed de 15 minutos e ocorre com o time de desenvolvimento, para que o mesmo 
planeje o trabalho para as próximas 24 horas. Assim, a colaboração e a performance do time 
são otimizadas através da inspeção do trabalho desde a última reunião e da previsão do próximo 
trabalho da Sprint (SCHWABER, 2017). 
 
Essa reunião é interna e o time de desenvolvimento é responsável por conduzi-la. Se outros 
estiverem presentes, o Scrum master deve garantir que eles não interfiram na reunião. Dentre 
os benefícios, essas reuniões melhoram a comunicação, eliminam outras reuniões, identificam 
e removem impedimentos para o desenvolvimento e promovem rápidas tomadas de decisão, 
tornando-a um evento chave para inspeção e adaptação (SCHWABER, 2017). 
45 
 
2.4.6.4. Revisão da Sprint 
A revisão da Sprint tem por objetivo obter o feedback dos clientes do projeto e demais partes 
interessadas sobre o incremento do produto produzido. O time de desenvolvimento e dono do 
produto trabalham em conjunto, com a facilitação do Scrum master, para demonstrar o trabalho 
pronto. O que a torna uma reunião de inspeção e adaptação do produto (SABBAGH, 2013). 
 
Esta é uma reunião informal, que busca, através da apresentação do incremento, motivar e obter 
feedback, bem como promover a colaboração. Já que, com base nesse incremento e em qualquer 
mudança no backlog do produto observada durante a Sprint, os participantes colaboram nas 
próximas coisas que podem ser feitas para otimizar valor (SCHWABER, 2017). 
 
Segundo Schwaber (2017), esta reunião tem duração máxima de 4 horas para uma Sprint de um 
mês. Para Sprints menores, este evento é usualmente menor. A revisão da Sprint inclui os 
seguintes elementos: 
• O dono do produto 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 a Sprint, quais problemas 
ocorreram dentro da Sprint, e como estes problemas foram resolvidos; 
• O time de desenvolvimento demonstra o trabalho que está pronto e responde as questões 
sobre o incremento; 
• O grupo todo colabora sobre o que fazer a seguir, e é assim que a revisão da Sprint 
fornece valiosas entradas para o planejamento da Sprint subsequente; 
• Revisão de como o mercado ou o uso potencial do produto pode ter mudado e qual é a 
coisa mais importante a se fazer a seguir; 
• Revisão da linha do tempo, orçamento, potenciais capacidades, e mercado para a 
próxima versão esperada de funcionalidade ou de capacidade do produto. 
 
Ao final deste evento, o backlog do produto está revisado com os prováveis itens para a próxima 
Sprint (SCHWABER, 2017). 
46 
 
2.4.6.5. Retrospectiva da Sprint 
A retrospectiva da Sprint ocorre depois da revisão da Sprint e antes do planejamento da próxima 
Sprint. Nela, o time Scrum inspeciona a Sprint que está se encerrando, identificam o que foi 
satisfatório, e que por essa razão pode ser mantido na próxima, e o que pode melhorar, buscando 
encontrar as causas raízes dos problemas, bem como definir formas práticas para aplicar as 
melhorias (SABBAGH, 2013). 
 
Seguindo a mesma linha, Schwaber (2017) define que o propósito da retrospectiva da Sprint é 
inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos 
e