Gerenciamento Ágil de Projetos de Desenvolvimento de ...
59
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
Transcript of Gerenciamento Ágil de Projetos de Desenvolvimento de ...
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 objetivo geral 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 e
qualidade.
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 trabalhos em
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 plano de 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) afirma ainda 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 suma importâ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, as
Sprints 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 às ferramentas, bem como identificar e ordenar os principais itens que foram bem e as
potenciais melhorias, e por fim criar um plano para implementar melhorias no modo que o time
de desenvolvimento faz seu trabalho.
Esta é uma reunião de no máximo três horas para uma Sprint de um mês. Para Sprint menores,
este evento é usualmente menor (SCHWABER, 2017).
Ao final da retrospectiva da Sprint, as melhorias devem ter sido identificadas, e a implantação
dessas melhorias na próxima é a forma de adaptação à inspeção que o time faz a si próprio. No
Scrum, as melhorias devem ser implementadas a qualquer momento, no entanto a retrospectiva
da Sprint fornece uma oportunidade formal focada em inspeção e adaptação (SCHWABER,
2017).
47
3. ANÁLISE DE TÓPICOS MAIS RELEVANTES
3.1. Gerenciamento de projetos de desenvolvimento de software SCADA
Como dito no capítulo anterior, o ambiente de desenvolvimento de software SCADA é repleto
de incertezas e mudanças, cujos os requisitos estão sujeitos a frequentes alterações durante todo
o desenvolvimento até a entrega final do produto. Isso para atender às solicitações de prováveis
novas demandas, seja devido a tecnologia utilizada tornar-se obsoleta ou até uma mudança no
planejamento estratégico do cliente.
Seguindo essa linha, Dias (2005) defende que o gerenciamento desses projetos deve ter um
tratamento diferenciado, tendo em vista que estes normalmente possuem um elevado grau de
incertezas iniciais, dificultando o detalhamento do escopo e, consequentemente, a elaboração
de um planejamento consistente. Além disso, diversas inclusões são constantes durante o
desenvolvimento, e neste cenário, ciclos rápidos de especificação, teste, validação e
implantação podem produzir resultados mais vantajosos que o desenho e o planejamento
integral de todo o projeto.
Sendo assim, sempre que possível, o gerenciamento ágil de projetos será comparado ao
tradicional nesse contexto.
3.2. Gerente de projetos e Scrum master
De acordo com Eder (2012), o papel exercido pelo GP no gerenciamento tradicional é
fundamental e essencial para execução de qualquer projeto, tendo em vista que ele é responsável
pelo controle do projeto, cuidando das atualizações necessárias, realizando reuniões formais,
entre outros. Nesse caso, somente o GP tem a visão geral do projeto. Já o Scrum master,
segundo Sliger (2011), tem uma função mais voltada a liderança, ou seja, ele tem a função de
facilitar o desenvolvimento da equipe, seja removendo obstáculos, intermediando discussões
dentro da equipe ou sendo o intermediário para os externos a equipe;
Seguindo esta mesma linha, Dias (2005), afirma que o estilo de condução de projetos tem
grande diferença. O GP adota um estilo baseado em comando e controle, ou seja, uma gestão
individual que favorece a especialização nesse segmento. De forma diferente, o Scrum master
48
tem um estilo focado na liderança e colaboração, cuja a distribuição de papeis e equipes auto-
organizadas, encorajam o intercâmbio de papéis e o desenvolvimento de todo o time.
Quando ocorre a mudança da abordagem, da tradicional para ágil, muitas vezes o GP se torna
Scrum master. Contudo, cada caso deve ser analisado, a exemplo, um gerente que atua num
determinado segmento por muito tempo, a ponto de se tornar um especialista em determinado
assunto, pode ser melhor posicionado como dono do produto. Outra possibilidade, é que caso
o GP esteja liderando uma equipe muito grande, este pode permanecer exercendo essa função,
concentrando-se nas tarefas gerais do projeto, e transformar a atual equipe em times Scrum,
cada time com o seu Scrum master. Dessa forma, o GP poderia auxiliar os Scrum masters
(SLIGER, 2011).
3.3. Gerenciamento do ciclo de vida dos projetos
Segundo Dias (2005), o gerenciamento tradicional dá ênfase ao planejamento detalhado do
projeto e nos processos estruturados para monitoramento e controle. Enquanto o gerenciamento
ágil foca na execução, preterindo o planejamento detalhado, visando à entrega constante e
rápida de valor ao cliente, o controle para adaptação, o qual permite alterações substanciais de
escopo, absorvendo de forma mais suave as mudanças de requisitos. Dessa forma, pode-se fazer
uma correlação do gerenciamento do ciclo de vida para ambos os métodos.
3.3.1. Iniciação
Na iniciação, não são apresentadas diferenças tão relevantes. No gerenciamento tradicional,
esta etapa contempla a formalização e autorização de um novo projeto ou fase, bem como a
definição preliminar do escopo do projeto. Por outro lado, o gerenciamento ágil, inicia o projeto
ou fase determinando a visão do produto e o escopo inicial do projeto (DIAS, 2005).
Na mesma linha de raciocínio, Udo e Koppensteiner (2003) afirmam que, com base no
PMBOK, a abordagem tradicional tem como foco obter aprovação formal para iniciar um novo
projeto ou a próxima fase do projeto, com ênfase na identificação das partes interessadas e de
suas necessidades, objetivos e expectativas para o projeto, enquanto as abordagens ágeis
começam descrevendo como os requisitos são coletados e priorizados (UDO;
KOPPENSTEINER, 2003).
49
3.3.2. Planejamento
As distinções mais significativas começam no planejamento. Segundo Eder (2012), na
abordagem ágil, “o plano” é realizado sucessivas vezes, com um grau menor de detalhe, com
priorização nas entregas mais importantes segundo os requisitos do cliente/mercado. No Scrum,
isso é evidenciado através do backlog do produto. Enquanto no tradicional, o plano é realizado
com grande detalhamento desde o início do projeto ou em ondas sucessivas (fases), sendo
reavaliado sempre que necessário.
Seguindo a mesma linha, Udo e Koppensteiner (2003) afirmam que esta etapa no gerenciamento
ágil, contrapondo o planejamento integral e detalhado da abordagem tradicional, contempla o
desenvolvimento de um plano inicial, sem grande detalhamento, seguido por planejamentos
individuais a cada iteração. Este último, fazendo referência ao Scrum, correspondem ao
planejamento da Sprint, o qual determina o backlog da Sprint.
3.3.3. Execução
Segundo Dias (2005), a etapa de execução, para o gerenciamento tradicional, resume-se em
executar tudo o que consta no plano de projeto. De forma diferente, a abordagem ágil busca
através da exploração entregar as funcionalidades e/ou produtos previstos no ciclo, com
objetivo de entregar valor em todo ciclo. O Scrum define esta etapa como Sprint, e esta tem por
objetivo entregar o que foi definido no planejamento da mesma.
3.3.4. Monitoramento e controle
Na abordagem ágil, o controle é feito de forma mais transparente, cuja a comunicação face-a-
face é incentivada entre os profissionais envolvidos no projeto, e a medição de progresso é
orientada para resultados, sendo estes normalmente tangíveis, a exemplo de protótipos e
funcionalidades. Já a abordagem tradicional foca no plano de projeto, ou seja, o plano é
encarado como base fundamental do projeto, descrevendo exatamente o que deve ser realizado
e como. Essa postura, em muitos casos, faz com que diversas variáveis que podem impactar no
desenvolvimento de um novo produto ou serviço sejam desprezadas (EDER, 2012).
Dias (2005) fez uma análise similar, e afirma que o monitoramento e controle, do
gerenciamento tradicional, enfatiza o controle do progresso dos trabalhos, bem como no
50
gerenciamento de mudanças para minimizar os impactos no projeto. Enquanto, o gerenciamento
ágil visa a adaptação, ou seja, a revisão dos resultados entregues e abertura para adaptações do
escopo, visando o atendimento aos possíveis novos requisitos.
Eder (2012) afirma que, na abordagem tradicional, os desvios no plano do projeto são
identificados de modo que ações sejam aplicadas para que os trabalhos voltem a ficar de acordo
com o plano. Estas alterações de escopo são evitadas, tendo em vista que resultam na
reavaliação de todo o plano do projeto, sem a participação ativa do cliente, podendo resultar em
erros ou problemas que somente serão identificados nas fases finais do projeto, retrabalho.
Diminuindo o foco no plano inicial, a abordagem ágil objetiva identificar as mudanças
necessárias para absorvê-las quando indicarem benefícios para o projeto. De certa forma, essa
postura possibilita antecipar possíveis riscos e entregar maior valor ao cliente. Outro ponto de
destaque é que no gerenciamento ágil, as alterações acontecem através de decisões e mudanças
orientadas pela priorização e com participação ativado cliente (EDER, 2012).
No Scrum, seguindo o que foi dito para a abordagem ágil, a reunião diária, revisão da Sprint,
bem como retrospectiva da Sprint são eventos utilizados para monitorar e controlar o projeto.
3.3.5. Encerramento
O encerramento é tratado de forma semelhante em ambas as abordagens de gerenciamento. O
objetivo desta etapa é buscar a formalização do aceite final do projeto (ou fase) para o
gerenciamento tradicional, ou iteração para gerenciamento ágil. Uma diferença é quanto a
formalização no encerramento do contrato, enquanto este é enfatizado na abordagem
tradicional, a abordagem ágil coloca a colaboração do cliente sobre a negociação do contrato.
Em muitos casos, os contratos formais desempenham um papel menos importante (UDO;
KOPPENSTEINER, 2003).
3.4. Gerenciamento das áreas do conhecimento em gerenciamento de projetos
Conforme pode ser visualizado no quadro a seguir, pode-se realizar também um paralelo com
as áreas de conhecimento do gerenciamento tradicional.
51
Quadro 1 - Comparação Áreas de Conhecimento - Abordagens Tradicional e Ágil
Áreas de
Conhecimento Abordagem Tradicional Abordagem Ágil
Integração Garante que todos os elementos dos projetos
são devidamente coordenados.
A necessidades de uma coordenação formal
é limitada devido a redução da utilização de
processos.
Escopo
Garante que o projeto contemple somente o
trabalho requerido para a finalização do
mesmo de forma bem-sucedida. Foco em
definir e controlar o que está ou não está no
projeto.
O escopo é fixo somente no decorrer das
interações. Não é necessário um controle
formal do escopo.
Cronograma
Foco em definir (e estimar) as atividades para
elaboração do cronograma e no controle do
mesmo para garantir a finalização do projeto
no prazo.
O prazo é fixado apenas por iteração. Foco na
entrega de valor (funcionalidades) o mais
rápido possível. No geral, o cronograma é
baseado em funcionalidades e não em
atividades.
Custos
Determina o orçamento do projeto baseado
nos recursos necessários para o projeto, bem
como controla-lo para garantir que o projeto
seja completamente finalizado dentro do
orçamento aprovado.
Determina o orçamento baseado nas
funcionalidades requeridas. Os recursos, as
funcionalidades e os prazos são balanceados,
e o custo é mensurado por atraso.
Qualidade
Garante que o projeto atenda de forma
satisfatória às necessidades para as quais foi
concebido. Foco na conformidade dos
requisitos.
Os critérios de sucesso do projeto são
definidos pelo cliente, o qual apresenta seu
feedback após cada iteração. Foco na
execução do propósito ou na adequação para
uso.
Recursos
humanos
Processos para tornar mais efetivo a
utilização de todos os envolvidos no projeto.
Foco no time e não no indivíduo. Incentivos
são baseados na produtividade do grupo.
Comunicações
Garante a geração oportuna e apropriada,
coleta, disseminação, armazenamento e
disposição final da informação do projeto.
Foco na eliminação de desperdício, sem
recursos, documentação ou papelada
desnecessária. E acesso aberto a informação
para todos os envolvidos.
Riscos Foco em identificar, analisar e responder aos
riscos do projeto.
Cada método ágil trata gerenciamento de
riscos de maneira diferente, não havendo um
padrão para esta abordagem.
Aquisições
Foco na aquisição de bens e serviços, de fora
da organização executora, para alcançar o
escopo de projetos. Baseado em contratos,
boas práticas, processos e procedimentos.
Seguem melhores princípios para aquisição
de bens e serviços por meio de contratos
colaborativos.
FONTE: ADAPTADO DE DIAS (2005)
52
A área de conhecimento referente as partes interessadas não foi contemplado no quadro, devido
ao fato que, sem muitas diferenças, ambas abordagens buscam identificar e gerenciar as partes.
O método ágil inclusive, foca completamente no cliente e na equipe de desenvolvimento, duas
das principais partes interessadas do projeto.
3.5. Benefícios
Para Ricardo Vargas (2009), dentre os principais benefícios do gerenciamento tradicional,
podem-se destacar os seguintes: Evitar surpresas durante a execução dos trabalhos; Antecipar
as situações desfavoráveis que poderão ser encontradas, para que ações preventivas e corretivas
possam ser tomadas antes que essas situações se consolidem como problemas; Aumentar o
controle gerencial de todas as fases a serem implementadas devido ao detalhamento ter sido
realizado. Contudo, levando em consideração o ambiente de projetos de desenvolvimento de
software, a princípio, estes benefícios não são tangíveis, já que as surpresas e situações
desfavoráveis (mudanças) aparecerão em todos os projetos, e o controle gerencial de todas as
fases devido ao detalhamento torna-se infactível.
Dados do Standish Group (2016) revelam que a taxa de sucesso para projetos grandes é muito
inferior quando comparado a projetos menores. O Scrum busca justamente aumentar a
possibilidade de sucesso, “quebrando” o projeto em projetos menores (Sprint), com duração de
duas a quatro semanas. Além disso, somente 61% das funcionalidades previstas eram de fato
implementadas e a média de utilização do usuário final era de somente 16%. A cooperação
entre cliente e o time Scrum, com maior presença e influência do cliente no desenvolvimento,
tendem a melhorar estes números.
Os benefícios oriundos da utilização do Scrum podem ser percebidos em toda a hierarquia da
empresa. Os diretores, devido aos ciclos curtos de desenvolvimento e a flexibilidade na
alteração de requisitos, têm facilidade para adaptar o projeto de acordo com decisões que
envolvam, por exemplo, o plano estratégico da empresa, oscilações do mercado, bem como o
posicionamento dos concorrentes. Os gerentes por sua vez obtêm ganho, por exemplo, com a
redução do risco de planejamento e execução, tendo em vista que a estratégia da abordagem
ágil evita que mudanças de escopo causem surpresas no fim do projeto, ou que dificuldades na
implementação sejam anunciadas somente próximo da data de entrega (BASSI FILHO, 2008).
53
Ainda segundo Bassi Filho (2008), a equipe de desenvolvimento é beneficiada devido as
abordagens ágeis serem centradas no desenvolvimento, ou seja, a opinião especializada passa a
ter maior importância para o projeto, o trabalho deixa de ser um processo onde cada um executa
uma tarefa de forma mecânica e a equipe mantém seu foco no que mais gosta, na
implementação.
Os clientes, diante do contato antecipado e constante com o software, absorvem o que está
sendo produzido com um nível de detalhamento elevado, e com base no conhecimento
adquirido durante o projeto, as funcionalidades podem ser melhoradas ou adaptadas. Por fim,
os usuários beneficiam-se porque podem usar o software de forma antecipada e com
disponibilização periódica de novas funcionalidades, dessa forma, a opinião e dificuldades do
usuário são relatadas a tempo de influenciar o desenvolvimento do restante do sistema (BASSI
FILHO, 2008).
Outro ponto de destaque, é com relação ao comprometimento e motivação da equipe de
desenvolvimento. Como a equipe é auto-gerenciável, cada membro da equipe recebe uma
responsabilidade, e isso eleva sua autoestima, pois significa que o resto da equipe acredita que
ele é capaz de realizar a tarefa e que a mesma será bem executada. Este comprometimento é
obtido quando o membro percebe que é o responsável pelo sucesso da execução. Contudo, para
que seja efetivo, a equipe precisa confiar na sua capacidade e oferecer apoio, caso necessário
(BASSI FILHO, 2008).
O estudo de Oliveira (2014) mostra que desde os estágios inicias, os metodos ageis adotam
atividades que garatem a qualidade do resultado. Atividades frequentes inerentes do Scurm no
processo de desenvolvimento, como planejamento da Sprint, reunião diária, revisão e
retrospectiva da sprtint atuam direatamente na melhoria de qualidade, identificação e mitigação
de riscos dos projetos.
Outro ponto de destaque desse estudo, é com relação ao comprometimento do time de
desenvolvimento. Percebeu-se também que os praticantes de métodos ágeis são entusiastas do
método, ou seja, possuem maior interesse em promover o resultado dos trabalhos e demonstram
total confiança na qualidade de seus produtos. É importante que todas as pessoas envolvidas
em um projeto de desenvolvimento de software saibam os benefícios do processo que está sendo
utilizado (OLIVEIRA, 2014).
54
Eder (2012) afirma ainda que, ao analisar a abordagem tradicional, o termo entregar valor para
o cliente também é citado. Contudo, a entrega de valor não é tratada da mesma forma, já que
existem dificuldades em antecipar atividades e até mesmo o fato do planejamento ser pouco
flexível, não absorvendo mudanças no decorrer do projeto.
3.6. Barreiras de entrada para abordagens ágeis
A implantação de uma abordagem ágil para o gerenciamento de projetos encontra muitas
barreiras e críticas. O Scrum, muito aceito na indústria de software, sofre oposições grandes
defendidas por acadêmicos mais tradicionais. Gregório (2007) afirma que dentre os pontos
fracos dessa abordagem, a falta de escalabilidade para equipes grandes e a necessidade da
mudança de cultura da instituição, são as principais.
Entretanto, contrapondo o que alguns acadêmicos alegam, dados do Standish Group (2016),
comprovam que a utilização dos métodos ágeis, mesmo quando utilizados em projetos de
grandes dimensões, são mais efetivos que os tradicionais. Com relação a segunda crítica, esta
procede, já que a implantação do Scrum necessita de mudanças na cultura da gestão de projetos.
Vale ressalta, que conforme visto na seção 3.5, esta cultura também gera benefícios.
Bassi Filho (2012) concorda que a principal diferença encontrada nos métodos ágeis é a cultura
ágil. E como dito, agrega benefícios, mas pode tornar-se uma grande barreira para
implementação de uma abordagem nova. Principalmente tendo em vista que em diversas
organizações, as hierarquias se apoiam no conceito de chefe e subordinados, e as práticas ágeis
buscam ceder mais poder para a equipe, o que pode não ser bem visto pelos atuais “chefes”.
Outra questão é que uma relação de poder forte, tende a inibir os colaboradores de posições
inferiores a opinar.
Oliveira (2014) afirma ainda que após a mudança da abordagem tradicional para a abordagem
ágil, alguns funcionários podem sair da empresa por questão de adaptação. Contudo, esta
situação deve ser tratada como uma evolução natural e suave, tendo em vista que quando
implantada corretamente, acarretará em maiores ganhos do que em perdas.
55
4. CONSIDERAÇÕES FINAIS
Devido a globalização, avanços constantes da tecnologia e concorrência elevada, é notório que
o ambiente atual dos projetos de desenvolvimento de software SCADA apresente um
dinamismo muito grande, com alta imprevisibilidade e com grande propensão a mudanças
durante todo o projeto. Portanto, buscar metodologias alternativas que possuam flexibilidade
para se adaptar e absorver as mudanças de forma mais fluida, torna-se fundamental para a
sobrevivência das organizações.
Nesse contexto, a rigidez inerente a abordagem tradicional de gerenciamento acaba não
atendendo a atual demanda de forma satisfatória, sendo imprescindível novas ideias para
projetos em ambientes mais complexos.
Além disso, nesses casos, a metodologia empregada pode muito bem ser o fator mais importante
na determinação da probabilidade de sucesso, e tendo em vista que produzir sistemas em
circunstâncias que mudam rapidamente, as vezes sob circunstâncias caóticas, os métodos ágeis
surgem como uma boa opção. Nessa linha, o Scrum, metodologia ágil mais utilizada
atualmente, apresenta uma abordagem adequada a esses projetos, com alto grau de tolerância a
mudanças.
Todavia, as metodologias ágeis sofrem algumas críticas de estudiosos mais tradicionais,
principalmente argumentando que a mudança de cultura da organização, necessária para
implantar a nova abordagem, é uma grande barreira. Contudo, conforme visto no trabalho, a
cultura ágil apresenta possibilidades grandiosas de melhorias no processo de desenvolvimento
e na taxa de sucesso dos projetos, minimizando os impactos oriundos da sua cultura.
Também é consenso entre os autores pesquisados que se deve fazer uma análise antes da
implantação de uma abordagem ágil. Deve-se considerar sempre os aspectos organizacionais e
culturais, bem como o contexto externo no qual o projeto está inserido, para desta forma
selecionar o modelo de gerenciamento de projetos mais adequado, tradicional ou ágil.
Por fim, é perceptível que a depender do projeto, uma abordagem pode ser mais adequada do
que outra, mas tudo indica que o gerenciamento ágil é mais adequado para projetos de
desenvolvimento de software SCADA.
56
5. REFERÊNCIAS
ASR. Figuras. In: http://Scrumasr.wordpress.com/. Acesso: 20 de fevereiro de 2018.
BAILEY, David; WRIGHT, Edwin. Pratical SCADA for Industry. Grã-Bretanha: Elsevier,
2003.
BASSI FILHO, Dairton Luiz. Experiências com desenvolvimento ágil. 2008. Dissertação
(Mestrado em Ciência da Computação) - Instituto de Matemática e Estatística, Universidade de
São Paulo, São Paulo.
BECK, K. et al. Manifesto for Agile Software Development. 2001. In:
http://agilemanifesto.org. Acesso: 10 de dezembro de 2017.
BOYER, Stuart A.. SCADA: Supervisory Control and a Data Acquisition. 3rd Edition. EUA:
ISA, 2004.
CAMARGO, Marta Rocha. Gerenciamento de projetos: fundamentos e prática integrada. 1ª
Edição. Rio de Janeiro: Elsevier, 2014.
CARVALHO, Bernardo Vasconcelos de; MELLO, Carlos Henrique Pereira. Aplicação do
método ágil scrum no desenvolvimento de produtos de software em uma pequena empresa de
base tecnológica. 2012. Artigo (Gestão da Produção) - Escola de Engenharia de São Carlos,
São Paulo.
CONFORTO, Edivandro Carlos. Gerenciamento ágil de projetos: proposta e avaliação de
método para gestão de escopo e tempo. 2009. Dissertação (Mestrado em Engenharia de
Produção) - Escola de Engenharia de São Carlos, São Paulo.
DIAS, Marisa Villas Bôas. Um novo enfoque para o gerenciamento de projetos de
desenvolvimento de software. 2005. Dissertação (Mestrado em Administração) - Faculdade de
Economia, Administração e Contabilidade, Universidade de São Paulo, São Paulo.
57
EDER, Samuel. Práticas de gerenciamento de projetos de escopo e tempo nas perspectivas das
abordagens ágil e tradicional. 2012. Dissertação (Mestrado em Processos e Gestão de
Operações) - Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos.
______. Diferenciando as abordagens tradicional e ágil de gerenciamento de projetos. 2015.
Artigo (Produção). São Paulo.
GREGÓRIO, M. et al. Os sete pecados na aplicação de processos de software. UNIBRATEC –
União Brasileira dos institutos de tecnologia, 2007. In: http://www.unibratec.edu.br/tecnologus
/edicoes-anteriores/edicao-02-30-ago-2007. Acesso em: 14 de janeiro de 2018.
HIGHSMITH, Jim. History: The agile Manifesto. 2001. In:
http://agilemanifesto.org/history.html . Acesso: 02 de março de 2018.
HI TECNOLOGIA. Sistema de Supervisão SCADA. In: http://www.hitecnologia.com.br/
automacao-industrial/sistema-supervisao-scada. Acesso: 20 de fevereiro de 2018.
KOPPENSTEINER, S.; UDO, N. Will agile development change the way we manage software
projects? Agile from a PMBOK® Guide perspective. 2003. Artigo (PMI® Global Congress
2003). Baltimore, EUA.
LUIZ, João Victor Rojas; SOUZA, Fernando Bernardi de; LUIZ, Octaviano Rojas. Práticas
PMBOK® e Corrente Crítica: antagonismos e oportunidades de complementação. 2017. Artigo
(Gestão da Produção) - Escola de Engenharia de São Carlos, São Paulo.
OLIVEIRA, Bruno Henrique. Qualidade de software no desenvolvimento com métodos ágeis.
2014. Dissertação (Mestrado em Ciências de Computação e Matemática Computacional) -
Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Carlos.
PMI - Project Management Institute. A Guide to the Project Management Body of Knowledge
- PMBOK® Guide. 6th Edition. Pennsylvania: PMI, 2017.
______. PMSURVEY.ORG – World Report. 2014. In: http://www.pmsurvey.org/. Acesso: 03
de dezembro de 2017.
58
______. Founders. 2018. In: http://www.pmi.org/about/learn-about-pmi/founders. Acesso: 23
de fevereiro de 2018.
PMI BRASIL. Sobre o PMI. 2018. In: http://brasil.pmi.org/brazil/AboutUS.aspx. Acesso: 23
de fevereiro de 2018.
RECH, Paulo Jacó. Gerenciamento de riscos em projetos de desenvolvimento de software com
Scrum. 2013. Dissertação (Mestrado em Ciências da Computação) - Faculdade de Informática
da Pontifícia Universidade Católica do Rio Grande do Sul, Rio Grande do Sul.
SABBAGH, Rafael. Scrum – Gestão Ágil para Projetos de Sucesso. São Paulo: Casa do Código,
2013.
SCHWABER, Ken. SCRUM Development Process. 1995. In:
http://www.jeffsutherland.org/oopsla/schwapub.pdf. Acesso: 25 de março de 2018.
SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum 2017 - Um guia definitivo para o
Scrum: As regras do Jogo. In: http://www.scrumguides.org/docs/scrumguide/v2017/2017-
Scrum-Guide-Portuguese-Brazilian.pdf. Acesso: 11 de março de 2018.
SCRUM ALLIANCE. Agile Atlas. 2016. In: http://www.scrumalliance.org/learn-about-
scrum/agile-atlas. Acesso: 20 de março de 2018
SCRUMstudy. A Guide to the Scrum Body of Knowledge (SBOK™GUIDE). 3rd Edition.
Arizona: VMEdu, 2017.
SIAUTEC. Programação Sistema Supervisório. In: http://siautec.com.br/servicos/programacao
-sistema-supervisorio/. Acesso: 20 de fevereiro de 2018.
SILVA, Ana Paula Gonçalves; SALVADOR, Marcelo. O que são sistemas supervisórios?.
2005. In: http://www.wectrus.com.br/artigos/sist_superv.pdf. Acesso: 20 de março de 2018.
59
SLIGER, M.. Agile project management with Scrum. 2011. Artigo (PMI® Global Congress
2011). Dallas, EUA.
SUTHERLAND, Jeff. Scrum - A Arte de Fazer o Dobro do Trabalho na Metade do Tempo.
Lisboa: Leya, 2014.
THE STANDISH GROUP. “CHAOS Report 2015”. In: http://blog.standishgroup.com/post/50.
Acesso: 14 de janeiro de 2018.
URZÊDA, Claiton Cesar de. Software SCADA como plataforma para a racionalização
inteligente de energia elétrica em automação predial. 2006. Dissertação (Mestrado em
Engenharia Elétrica) - Universidade de Brasília, Brasília.
VARGAS, Ricardo Viana. Practical guide to project planning. New York: Auerbach
Publications, 2008.
______. Gerenciamento de projetos - Estabelecendo Diferenciais Competitivos. 7 ª Edição. Rio
de Janeiro: Brasport, 2009.
VERSION ONE. 11th Annual “State of Agile Report" Survey. 2017. In:
http://explore.versionone.com/state-of-agile/versionone-11th-annual-state-of-agile-report-2.
Acesso: 06 de fevereiro de 2018.
