Comparativo entre Waterfall e Scrum na Gestão da Qualidade

UNIVERSIDADE PRESBITERIANA MACKENZIE
CARLOS EDUARDO FADDUL NUNES
GESTÃO DE QUALIDADE: UM ESTUDO COMPARATIVO ENTRE OS
PROCESSOS DA METODOLOGIA WATERFALL COM A METODOLOGIA ÁGIL
São Paulo
2017

CARLOS EDUARDO FADDUL NUNES
GESTÃO DE QUALIDADE: UM ESTUDO COMPARATIVO ENTRE OS
PROCESSOS DA METODOLOGIA WATERFALL COM A METODOLOGIA ÁGIL
Trabalho de Conclusão de Curso apresentado
ao Programa de Pós-graduação Lato Sensu da
Escola de Engenharia da Universidade
Presbiteriana Mackenzie, como requisito
parcial para a obtenção do Título de
Especialista em Gestão de Projetos.
São Paulo
2017

Dedico, com muita afeição, à minha
família. Aos meus pais, por se
empenharem e dedicarem no decorrer dos
anos para que eu e minhas irmãs
pudéssemos adquirir uma boa formação.

AGRADECIMENTOS
À minha família, pela abundância de paciência, compreensão e apoio no decorrer de
todos os anos de estudo.
À Profa. Ms. Ana Claudia Rossi, por ter feito surgir interesse na área de Gestão de
Projetos ainda em graduação e oferecido auxilio de abordagem de tema para a
monografia.
À Profa. Ms. Regiane Moreno, por me auxiliar durante o período de orientação com
dicas para melhor estruturação da monografia.
Às amizades Cinthia Guedes, Erick Munekata e Mariana Rudella por terem me
fornecido conhecimentos outros frameworks baseados em metodologia ágil que
serviram de base para o alinhamento do trabalho.
Às amizades de Mariana Costa e Nubia Ferr pela ajuda na criação e edição das
imagens presentes neste trabalho.
Às amizades de Maiara Leones, Mariana Costa, Natália Alcântara, Nathalia Negreiros,
Silvia Jensen e Yasmin Abrão pelas leituras e sugestões de melhoria para o
entendimento do texto.
Aos meus colegas de sala, pela a companhia nesses dois anos de estudos.

“Não existem inocentes. Só existem
diferentes graus de responsabilidade. ”
(Stieg Larsson).

RESUMO
Este trabalho tem como objetivo apresentar a metodologia waterfall, utilizada pelo
PMBoK, e a metodologia ágil, que é empregada no Scrum, de maneira que a escolha
delas pode influenciar a visão de Qualidade e o sucesso em projetos. Com as
transformações que ocorrem no transcorrer do ciclo de vida dos projetos, a escolha
da metodologia exerce um papel fundamental, o do sucesso ou do fracasso na visão
de Qualidade tal como na conclusão do mesmo. Como cada metodologia possui uma
abordagem individual, uma estrutura e um ciclo de processo distinto, se deve analisar
a natureza e o contexto do projeto, desta maneira tendo em vista qual é a metodologia
que agregará mais valor ao projeto. Será mostrado como cada metodologia e um de
seus diversos frameworks, como eles são estruturados, para que, por conseguinte
seja explicada progressivamente suas vantagens no conceito de Qualidade e valor,
fornecendo conhecimento para que se possa realizar uma escolha mais assertiva na
metodologia que será empregada durante o ciclo de vida do projeto.
Palavras-chave: Waterfall, Scrum, Qualidade, Comparativo.

ABSTRACT
This study has the objective to present the waterfall methodology used by PMBoK and
the agile methodology that is used in Scrum, so that their choice can influence the
vision of Quality and success in projects. With the transformations that occur during of
the life cycle of projects, the choice of methodology plays a fundamental role, that of
success or failure in the vision of Quality as in the conclusion of it. As each
methodology has an individual approach, a structure and a distinct process cycle, must
be analyzed the nature and context of the project, in this way considering the
methodology that will add more value to the project. It will be shown how each
methodology and one of its several types of frameworks, how they are structured, so
that it is progressively explained its advantages in the concept of Quality and Value,
providing knowledge so that a more assertive choice can be made in the methodology
that will be employed during the projetc's lifecycle.
Keywords: Waterfall, Scrum, Quality, Comparative.

LISTA DE ILUSTRAÇÕES
Ilustração 1 Comparativo entre as metodologias..................................................................11
Fluxograma 1 Modelo waterfall descrito por Royce em 1970................................................15
Quadro 1 Mapeamento das áreas de conhecimento pelo grupo de processos..................17
Fluxograma 2 Organização dos grupos de processos...............................................................17
Fluxograma 3 Exemplo do ciclo de vida do Scrum..................................................................27
Ilustração 2 Modelo espiral adotado Scrum .........................................................................31
Ilustração 3 Áreas que definem o sucesso do projeto...........................................................33

LISTA DE ABREVIATURAS, SIGLAS E SÍMBOLOS
EAP Estrutura Analítica do Projeto
MVP Minimum Viable Product
PMBOK Project Management Body of Knowledge
PMI Project Management Institute
PDCA Plan-Do-Check-Act
RH Recursos Humanos
ROI Return Of Invesment

SUMÁRIO
1 INTRODUÇÃO....................................................................................................................11
1.1 OBJETIVOS.....................................................................................................................12
1.1.1 Objetivo geral..............................................................................................................12
1.1.2 Objetivos específicos ...............................................................................................12
1.2 JUSTIFICATIVA ..............................................................................................................13
1.3 METODOLOGIA..............................................................................................................13
1.4 ESTRUTURA DO TRABALHO .....................................................................................14
2 METODOLOGIA WATERFALL.......................................................................................15
2.1 PMBOK .............................................................................................................................16
2.2 CICLO DE VIDA DO PROJETO...................................................................................17
2.2.1 Iniciação.......................................................................................................................18
2.2.2 Planejamento ..............................................................................................................18
2.2.3 Execução......................................................................................................................19
2.2.4 Monitoramento e Controle ......................................................................................20
2.2.5 Encerramento .............................................................................................................21
3 METODOLOGIA ÁGIL......................................................................................................22
3.1 SCRUM.............................................................................................................................23
3.2 PAPÉIS NO SCRUM ......................................................................................................24
3.3 CICLO DE VIDA DO PROJETO...................................................................................26
3.2.1 Product Backlog ........................................................................................................27

3.3.2 Sprint Planning...........................................................................................................28
3.3.3 Sprint Backlog............................................................................................................28
3.3.4 Sprint.............................................................................................................................29
3.3.5 Sprint Review..............................................................................................................30
3.3.6 Sprint Retrospective .................................................................................................30
3.3.7 Increment .....................................................................................................................31
4 GESTÃO DA QUALIDADE: UM COMPARATIVO ENTRE WATERFALL E ÁGIL32
4.1 COMPARATIVO SOBRE ESCOPO.............................................................................33
4.2 COMPARATIVO SOBRE TEMPO................................................................................35
4.3 COMPARATIVO SOBRE CUSTOS.............................................................................36
5 CONCLUSÃO .....................................................................................................................38
REFERÊNCIAS......................................................................................................................40

11
1 INTRODUÇÃO
Segundo Vargas (2016), a qualidade é garantir que o projeto será entregue
dentro da qualidade desejada, garantindo a satisfação de todos os stakeholders 1
.
Desta forma a ideia de qualidade fornecida pelo Project Management Body of
Knowledge (PMBoK) foca no gerenciamento da qualidade do projeto conta com os
processos e as atividades da organização executora, se utilizando do ciclo de Deming,
também conhecido como PDCA (Plan-Do-Check-Act 2
), que consiste em melhoria
continua para se alcançar uma qualidade superior.
De acordo com Vaz (2016) “O intuito é ajudar a entender não só como um
problema surge, mas também como deve ser solucionado, focando na causa e não
nas consequências”. Entretanto segundo a Venki (2016), uma vez que se implante o
ciclo PDCA, ele deve ser uma constante na empresa, como um círculo vicioso para
que desta maneira se alcance sempre a melhoria continua.
As metodologias exercem um papel importante no projeto, elas auxiliam se o
projeto agregará valor ao cliente ou se irá causar prejuízo.
Em uma pesquisa realizada pela Ambysoft, em 2014, voltada para os projetos
na área de Tecnologia da Informação, foram obtidos números que se tornam
chamativos devido aos resultados, conforme a ilustração 1:
Ilustração 1 - Comparativo entre as metodologias
Fonte: Adaptado e traduzido de Ambysoft (2014)
1
A tradução utilizada decorrer do trabalho será “partes interessadas”
2
Tradução literal: Planejar-Fazer-Checar-Agir

12
De acordo com a ilustração 1, a escolha da metodologia acabar influenciando
expressivamente o sucesso do projeto. O sucesso impacta diretamente na visão de
qualidade do projeto, uma vez que segundo Carvalho e Paladini (2012) classificam a
qualidade em cinco abordagens distintas, sendo elas a transcendental, baseada no
produto, baseada no usuário, baseada na produção e baseada no valor.
Mas após escolhendo uma das abordagens de qualidade, focamos em como
comparar as metodologias e desta forma, uma maneira mais clara para escolher uma
metodologia que auxilie desde a concepção até a conclusão do projeto visando que o
ciclo de vida da metodologia alcance a qualidade desejada.
1.1 OBJETIVOS
1.1.1 Objetivo geral
Este trabalho tem como objetivo entender como a escolha de uma metodologia
na Gestão de Projetos, delineando as alternativas de metodologias como waterfall e
a ágil, pode definir o sucesso ou fracasso de um projeto no conceito de Qualidade.
1.1.2 Objetivos específicos
Devido à proposta apresentada, o objetivo deste trabalho se enfatiza de
maneira teórica na apresentação e estudos da metodologia waterfall, que é
apresentada pelo utilizando o PMBoK, e na metodologia ágil, que será apresentada
usando o Scrum, de maneira a comparar teoricamente o ciclo de vida de projetos
baseando no conceito de Qualidade final para o projeto.

13
1.2 JUSTIFICATIVA
Segundo Arantes e Lima (2016) os projetos são desenvolvidos por pessoas e
para pessoas. Assim pode-se mensurar o departamento de recursos humanos
utilizando métricas (Harrell, 2015), mas sem mensurar um escopo ou outras fases com
qualidade desde sua concepção.
E estas métricas realmente se aplicam em aspectos intangíveis como
colaboração e participação das partes interessadas envolvidas no projeto. Dentre
aspectos intangíveis, pode-se citar o engajamento dos funcionários, que englobaria
desde a participação do mesmo com o cliente até a sua motivação em concluir suas
tarefas com qualidade.
Contudo, pelo PMBoK, as métricas podem ser utilizadas como a matriz RACI
(Responsible, Accountable, Consult, Inform3), apesar de a mesma ser utilizada para
atribuição de responsabilidades dentro dos processos (Palma, 2016). Assim, tem-se
a criação de uma qualidade relacionada aos processos de entrada e saída, das
atividades de cada parte envolvida no projeto, mas não temos como medir o
alinhamento de perfil dos funcionários ao projeto em si.
Careli (2015) afirma que o uso de indicadores se trata de um dos grandes
desafios para quem trabalha na área de RH, pois eles devem conhecer a situação
atual da empresa para auxiliar na definição de uma meta futura baseando o indicador
e a avaliação dos resultados no momento futuro em comparação com a meta atual.
São utilizadas diversas métricas e técnicas, para analisar o fator humano em
um projeto. Entretanto, estas métricas visam a qualidade do projeto em um segmento
apenas, como o descrito.
1.3 METODOLOGIA
Este trabalho foi desenvolvido por meio de pesquisas teóricas, a partir de
consultas bibliográficas, trabalhos acadêmicos, artigos científicos além de livros
relacionados com o tema.
3
Tradução Literal – Responsável, Autoridade, Consultado, Informado

14
A pesquisa teórica terá como base a pesquisa bibliográfica referente à Gestão
da Qualidade em projetos, com ênfase no modelo waterfall (PMBoK 5ª Edição) e no
modelo ágil (Scrum), tendo como enfoque as métricas de qualidade em ambos. Serão
apresentados os processos de qualidade, juntamente com processos dependentes
em cada metodologia.
1.4 ESTRUTURA DO TRABALHO
Este trabalho estará estruturado em cinco seções.
A Seção 1 apresentará a Introdução, que é composta pelos seguintes itens:
texto de conceituação e caracterização do tema; Objetivos; Justificativa; e
Metodologia.
A Seção 2 abordará como é a metodologia waterfall utilizada pelo PMBOK 5ª
Edição, com demonstração de como é o modelo waterfall, ciclo de vida do projeto e
suas fases.
A Seção 3 abordará como é a metodologia ágil, utilizando o Scrum como
referência para a metodologia ágil, demonstrando como é o ciclo de vida do projeto,
suas vantagens e suas desvantagens.
A Seção 4 será feito um comparativo teórico entre as duas metodologias e as
faceando no quesito de Gestão de Qualidade.
A Seção 5 relatará as conclusões do trabalho e indicará algumas
recomendações para pesquisas futuras.

15
2 METODOLOGIA WATERFALL
Para entendermos o que é a metodologia waterfall, devemos ter o
conhecimento que esta surgiu após um artigo publicado por Winston Walker Royce,
em 1970, intitulado Managing the development of large software systems4
. Onde o
modelo proposto por ele lidava com o desenvolvimento de software para computador,
separando etapas como a análise e codificação do software, mas de forma
estruturada, criando um efeito de dependência linear entre suas áreas, conforme
ilustrado no fluxograma 1.
Fluxograma 1- Modelo waterfall descrito por Royce em 1970
Fonte: Adaptado e traduzido de Royce (1970)
Contudo, em seu artigo ele menciona “They must be planned and staffed
differently for best utilization of program resources.” 5
(Royce, 1970), onde demonstra
4
Tradução literal: Gerenciando o desenvolvimento de grandes sistemas de software
5
Tradução literal: Eles devem ser planejados e empregados de forma diferente para a melhor utilização dos
recursos do programa.

16
que o modelo em cascata, pode ser adaptado e variado a depender dos recursos
disponíveis.
Ainda assim, mesmo com este adendo feito por Royce em seu artigo, grande
parte das metodologias que seguem o princípio cascata tendem em focar apenas uma
fase por vez a ser desenvolvida, de maneira sequencial.
2.1 PMBOK
Um dos frameworks mais conhecidos e que se utiliza da metodologia waterfall
é o modelo do PMBoK, concebido pelo Project Management Institute (PMI).
Em sua versão mais recente, a 5ª Edição datada de 2014, é agrupado em 10
áreas de conhecimentos distintos, possuindo 47 processos para gerenciar um projeto,
segundo Project Management Institute (2014). As 10 áreas de conhecimento são:
 Aquisições;
 Comunicação;
 Custo;
 Escopo;
 Integração;
 Partes interessadas;
 Qualidade;
 Recursos Humanos;
 Riscos;
 Tempo;
Para o PMBoK, no modelo de desenvolvimento de projetos, o ciclo de vida do
projeto é dividido em 5 grupos de áreas que são: Iniciação, Planejamento, Execução,
Monitoramento e Controle e por fim Encerramento.
Por se tratar de um modelo de desenvolvimento de projetos, baseado no
waterfall, cada ciclo de vida do projeto só é iniciado após a conclusão do anterior, visto
que o projeto é abordado como um todo.

17
2.2 CICLO DE VIDA DO PROJETO
Cada grupo definido pelo modelo PMBoK tem suas peculiaridades e áreas de
conhecimento associadas, totalizando um modelo com 47 processos para gerenciar
um projeto, conforme mostrado no Quadro 1, sendo que os grupos de processos se
interligam conforme mostrado no fluxograma 2
Quadro 1 - Mapeamento das áreas de conhecimento pelo grupo de processos
Áreas de
Conhecimento
Iniciação Planejamento Execução Monitoramento e
Controle
Encerramento
Integração 1 proc. 1 proc. 1 proc. 2 proc. 1 proc.
Escopo 4 proc. 2 proc.
Tempo 6 proc. 1 proc.
Custo 3 proc. 1 proc.
Qualidade 1 proc. 1 proc. 1 proc.
Recursos Humanos 1 proc. 3 proc. 1 proc.
Comunicações 1 proc. 1 proc. 1 proc.
Riscos 5 proc. 1 proc.
Aquisições 1 proc. 1 proc. 1 proc. 1 proc.
Partes Interessadas 1 proc. 1 proc. 1 proc. 1 proc.
Fonte: Adaptado PMBoK (p. 61, 2014)
Fluxograma 2 - Organização dos Grupos de Processos
Fonte: PMBoK (p. 42, 2014)

18
2.2.1 Iniciação
Neste grupo de processos, são englobadas as áreas de conhecimento de
Integração e Partes Interessadas. Segundo o PMBoK (2014), nesta área os processos
são feitos para definirem um projeto novo e/ou fase nova do mesmo, após ser
concedida uma autorização para iniciar o projeto ou fase do mesmo.
Segundo Montes (2016), os fatores críticos desta fase, de grupo de processos,
englobam a clareza do objetivo e da abrangência total do projeto. Após análise
completa do projeto, onde incluem-se os cenários de riscos internos e externos é
possível a definição dos papéis que variam do gerente do projeto até as partes
interessadas.
Nesta etapa as áreas de conhecimento demandadas são:
 Integração: autoriza o início do projeto pelo termo de abertura do projeto
 Partes interessadas: identificação, interesses e envolvimento entre as
partes interessadas ao projeto
Somente após esta fase de identificações e definições de papéis, objetivos e a
aceitação por parte do patrocinador do projeto que ele começará a ser planejado e
desenvolvido.
2.2.2 Planejamento
Passada a fase de Iniciação do projeto, dá-se prosseguimento à etapa de
Planejamento, que foca em refinar o escopo pré-definido. Caso ocorra alguma
mudança drástica no decorrer da Execução, Monitoramento e Controle, o projeto
retorna para o ciclo de Planejamento.
Nesta etapa todas as áreas de conhecimento do PMBoK são utilizadas, as
quais definem a importância do planejamento para o sucesso do projeto. Serão
destacados abaixo alguns processos mais conhecidos relacionados com suas áreas
para melhor exemplificação.
 Integração: desenvolverá o plano de gerenciamento do projeto;

19
 Escopo: criação a Estrutura Analítica do Projeto (EAP);
 Tempo: criação do cronograma;
 Custos: determinar o orçamento do projeto no todo ou em partes
 Qualidade: determinar quais serão os padrões de qualidade do projeto
ou fase;
 RH: planejar os recursos que serão demandados no decorrer de todo o
projeto;
 Comunicação: definir como será realizada a comunicação dentro do
projeto;
 Riscos: quais serão os riscos previstos e como serão mitigados;
 Aquisições: planejar e/ou definir quando serão realizadas aquisições;
 Partes interessadas: como engajar as partes interessadas de maneira
eficaz;
Neste momento, o projeto será arquitetado e alinhado junto ao cliente
(Montes,2016), para assim criar as definições para benchmarking 6
para o projeto.
Segundo Trage (2014) tem a seguinte definição:
“é utilizado para comparar práticas de projetos
reais ou planejados com demais projetos, a fim
de identificar melhores práticas, considerar
melhorias e fornece uma base para o
mensurar o desempenho, contribuindo na
obtenção melhores práticas que conduzam ao
um desempenho superior” (TRAGE, 2014)
2.2.3 Execução
Segundo o Project Management Institute (2014), nesta etapa os processos
consistem na realização e execução dos parâmetros definido no plano de
gerenciamento do projeto, a fim de satisfazer as especificações do mesmo. Contudo
é necessário que exista uma linha base bem definida, os planos de projeto detalhados
e previamente aprovados, visto que cada área irá conduzir um ou mais processos no
decorrer deste ciclo. Dentre os diversos processos, alguns serão destacados:
6
Tradução literal: análise comparativa

20
 RH: mobilização da equipe para o projeto
 Qualidade: garantia da qualidade pelos benchmarkings escolhidos
 Comunicação: gerenciamento das comunicações no decorrer da fase
 Integração: orientação de como gerenciar o trabalho
 Aquisições: definir quais e quando as aquisições serão realizadas
 Partes interessadas: garantir que as expectativas possuam a maior
aceitação entre as partes interessadas ao projeto
Assim, nesta etapa é necessária a execução conforme planejamento do
projeto, além de solicitar a participação do cliente, para que assim, haja uma
probabilidade maior na aceitação. A equipe responsável pelo projeto, começa a
informar e reportar seu progresso para o gerente responsável do projeto, o qual atua
como intermediador entre as partes interessadas do projeto, repassando tais
informações.
As criações de marcos pré-definidos na etapa de Planejamento, incidem no
controle e gestão do cronograma, criando um meio de tornar mais assertivo o projeto
que, por sua vez, influencia na Qualidade final como um todo.
2.2.4 Monitoramento e Controle
Segundo o PMBoK (2014), este grupo de processos é utilizado para
acompanhar, analisar e controlar o progresso e desempenho do projeto. Contudo
Vargas (2016), enfoca que este grupo de processos, acontece paralelamente com as
demais fases do projeto, com ênfase em ações preventivas e corretivas no menor
espaço de tempo, para reduzir e/ou mitigar ao máximo potenciais riscos ao projeto.
Nesta etapa, as áreas de conhecimento demandadas dos processos, focam em
ações que basicamente se assemelham em controles e validações, a fim de que se
possa comparar o projeto atual com o previsto do Planejamento (VARGAS, 2016).
A seguir, destacam-se, algumas áreas associadas a um dos processos
indicados pelo PMBoK:
 Escopo: validação do escopo afim de formalizar os aceites parciais

21
 Integração: monitoração e controle do trabalho identificando áreas que
demandam atenção extra
 Tempo: controlar o cronograma baseado nos status das estimativas
 Custo: controle dos custos previstos e a atualização dos custos atuais
 Qualidade: controlar a qualidade monitorada em resultados específicos
 Comunicação: controlar de forma a eliminar as distorções de
informações nas comunicações
 Riscos: acompanhar os riscos identificados previamente e os monitorar
 Aquisições: monitorar a eficiência dos contratos referentes as aquisições
 Partes Interessadas: monitorar o envolvimento das mesmas
2.2.5 Encerramento
Segundo o PMBoK (2014), é utilizada para verificar se os processos foram
concluídos e todos os grupos de processos anteriores já descritos a fim de encerrar
formalmente o projeto. Neste momento é aguardado para o projeto a aceitação por
parte do cliente, a documentação das lições aprendidas e a liberação dos recursos
utilizados, de modo a realizar a definição e comunicação dos responsáveis pela
manutenção do projeto criado.
Por ser uma fase relativamente breve, apenas duas áreas são solicitadas
 Integração: encerramento formalmente do projeto
 Aquisições: certificar que os contratos de aquisições estejam encerrados

22
3 METODOLOGIA ÁGIL
Segundo Daft (2015), a norma hoje é de mudança e não de estabilidade.
Partindo deste conceito, deve-se entender o porquê desta afirmação, a qual tem se
tornado cada vez mais corriqueira no cenário atual em que vivemos.
Segundo Druker (1998):
“most of our assumptions about business, technology
and organizations are at least 50 years old. They have
outlived their time. As a result, we are teaching and
practicing policies that are increasingly at odds with
reality and therefore counterproductive” 7
. (DRUCKER,
1998)
O conceito de metodologia ágil surgiu como alternativa ao modelo tradicional,
a metodologia waterfall, iniciando igualmente por necessidade no desenvolvimento de
software, após o encontro de Jeff Sutherland e mais 16 líderes de desenvolvimento
no qual escreveram o “Manifesto Ágil”.
No Manifesto Ágil, os autores descrevem como 4 pilares para boa execução:
 Indivíduos e interações mais que processos e ferramentas
 Software em funcionamento mais que documentação abrangente
 Colaboração com o cliente mais que negociação de contratos
 Responder a mudanças mais que seguir um plano
Juntamente com doze princípios para sucesso na implementação do mesmo:
 Nossa maior prioridade é satisfazer o cliente, através da entrega
adiantada e contínua de software de valor.
 Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.
Processos ágeis se adequam a mudanças, para que o cliente possa tirar
vantagens competitivas.
 Entregar software funcionando com frequência, na escala de semanas
até meses, com preferência aos períodos mais curtos.
 Pessoas relacionadas à negócios e desenvolvedores devem trabalhar
em conjunto e diariamente, durante todo o curso do projeto.
7
Tradução literal: A maioria de nossas suposições sobre negócios, tecnologias e organizações tem pelo menos 50
anos. Elas sobreviveram ao seu tempo. Como resultado, estamos ensinando e praticando políticas que estão cada
vez mais em desacordo com a realidade e, portanto, contraproducente.

23
 Construir projetos ao redor de indivíduos motivados. Dando a eles o
ambiente e suporte necessário, e confiar que farão seu trabalho.
 O Método mais eficiente e eficaz de transmitir informações para, e por
dentro de um time de desenvolvimento, é através de uma conversa cara
a cara.
 Software funcional é a medida primária de progresso.
 Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser capazes de
manter indefinidamente, passos constantes.
 Contínua atenção à excelência técnica e bom design, aumenta a
agilidade.
 Simplicidade: a arte de maximizar a quantidade de trabalho que não
precisou ser feito.
 As melhores arquiteturas, requisitos e designs emergem de times auto
organizáveis.
 Em intervalos regulares, o time reflete em como ficar mais efetivo, então,
se ajustam e otimizam seu comportamento de acordo.
Existem diversas metodologias ágeis, que segundo Steffen (2012) algumas são
mais prescritivas ou menos prescritivas, Dentre elas, as mais comuns são: Extreme
Programming (XP), Scrum, Lean Development, Feature-Driven Development (FDD),
Kanban, RUP e OpenUP.
3.1 SCRUM
No começo do ano de 1986, em um artigo escrito por Hirotaka Takeuchi e Ikujiro
Nonaka chamado “The New New Product Development Game”8
, no qual os autores
analisavam equipes de empresas produtivas e inovadoras à época que, onde ao invés
de terem equipes especialistas, utilizavam-se de equipes multifuncionais e com alto
grau de autonomia, criando uma flexibilidade para o desenvolvimento do projeto;
Neste ponto, a direção do projeto não era voltada em determinar o papel de cada um
no projeto, mas sim retirar dificuldades provenientes que a equipe pudesse ter para o
8
Tradução literal: O novo jogo no desenvolvimento de novos produtos

24
desenvolver. Eles compararam o trabalho de uma equipe, que utilizava esta
metodologia mais dinâmica, a uma equipe de rúgbi “as in rugby, the ball gets passed
within the team as it moves as a unit up the field.” 9
(TAKEUCHI; NONAKA, 1986).
Após a leitura deste artigo, Jeff Sutherland e Ken Schwaber, considerados os
criadores do Scrum, tentaram, sete anos após a publicação do artigo, aplicar os
conceitos presentes no artigo em sua equipe, para tentar criar uma maneira de
entregar o projeto dentro do tempo estimado, com orçamento menor, menos bugs10
,
criando um marco de assertividade nos projetos concluídos que até aquele momento
não possuíam.
Mesmo que nascido do desenvolvimento de software, segundo Sutherland
(2016) “Scrum não é sobre os desenvolvedores. Mas sim sobre os clientes e os
stakeholders. [...] Mostrar o produto real era a parte mais eficaz.”. Como a metodologia
é baseada em equipes multifuncionais com alta autonomia muito assemelhado em
uma equipe de rúgbi em que, a bola é passada pelo time, mas o avanço é feito pelo
time por completo.
A definição da ordem cronológica do projeto se baseia na pergunta que deve
ser respondida no começo de cada etapa “o que agregará mais valor para o projeto?
Faça essas coisas primeiro.” (Sutherland, 2016, p.14).
Contudo, conforme dito anteriormente, por se tratar de uma metodologia ágil, o
Scrum, tal como quaisquer outros frameworks voltados para o modelo ágil, se
desenvolve usando o modelo em espiral, se baseado no ciclo de Deming, o que
consiste desenvolvimentos incrementais, rápidos, com poucos recursos alocados e
focado em entregar o que confere valor mais rápido para o projeto.
3.2 PAPÉIS NO SCRUM
Pelo fato do Scrum nascer de equipes multifuncionais, a aplicação de posições,
como são conhecidos normalmente (gerente, coordenadores, analistas, entre outros
cargos), acabam tendo ênfase em poucas posições, tratadas como papéis para
agilizar a organização do projeto, bem como os processos que os envolvem.
9
Tradução literal: como no rúgbi, a bola é passada dentro da equipe enquanto ela se move como uma unidade no
campo.
10
Tradução literal / sentido literal: inseto/ se remete à problemas dentro de projetos não esperados.

25
Os papéis para uma equipe de Scrum se baseiam em serem apenas um trio de
papéis, dentre eles são:
 Scrum Master – Segundo Carvalho e Melo (2012), o Scrum Master é eleito
pelos desenvolvedores11
, este papel se assemelha muito com um “Gerente
de Projetos”, contudo o papel dele no projeto é de facilitador. Segundo Pries
e Quigley (2010) mesmo ele possuindo diversas responsabilidades os
autores destacam cinco responsabilidades que se tornam muito chamativas
1. Remover obstáculos
2. Facilitar na resolução de conflitos (problemas internos da equipe)
3. Garantir a aderência ao Scrum e as regras da equipe
4. Obter recursos
5. Manter o time focado.
Neste último item, o Scrum Master é responsável por manter a equipe
isolada de demais partes interessadas externas à equipe, garantindo o foco
da Scrum Team e prevenindo da presença de interferências.
 Product Owner (P.O.) – Este membro do time geralmente representa o
cliente (interno ou externo) (CARVALHO; MELLO, 2012). Normalmente ele
define quais dos requisitos do projeto terão mais importância e sua
prioridade. Geralmente para este papel é muito necessário que o membro
conheça bem as regras de negócio do cliente para que ele possa sanar
qualquer dúvida que possa surgir do time de desenvolvimento sobre as
funcionalidades do produto. Segundo Pries e Quigley (2010) o papel do
Product Owner é ser a voz do cliente, validando a eficiência sobre o ponto
de vista do negócio como o projeto está se comportando. Ele é o
responsável pela gestão do produto que está sendo desenvolvido, contudo
ele não faz o papel de gerenciar o Scrum.
 Scrum Team – por Sutherland (2014) o conceito das Scrum Team ou time
de desenvolvimento, normalmente são entre 3 até 10 pessoas, pois
11
A notação desenvolvedor, a partir deste ponto, no decorrer do texto será para remeter ao time de
desenvolvimento.

26
assegura que todos se tornem responsáveis. Nela não são utilizadas as
definições tradicionais de papéis como: funcionais, testes ou similares. É
necessário que o time seja pequeno, para que ele se torne auto-organizado
e auto-conduzido, para que os objetivos sejam focados e a equipe seja
responsável pela conclusão deles. É ela que determina tecnicamente se o
produto será desenvolvido negociando com o Product Owner no decorrer
da Sprint.
Outros papéis que também influenciam e colaboram para o sucesso do projeto
são:
 Stakeholders – também conhecidos como partes interessadas, podendo ser
clientes, fornecedores, outras áreas da mesma empresa, contudo os
mesmos só são envolvidos no projeto durante as etapas de revisões de
Sprints.
 Gerentes – são incluídos gerentes de projeto, contudo o papel de gerente
no Scrum foca em permitir a facilitação do projeto em si, ao contrário do que
se está habituado, como definição de escopo, listas de atividades, riscos e
similares, o foco dos gerentes se alinham mais em se tornarem prestadores
de contas, liderando a equipe.
3.3 CICLO DE VIDA DO PROJETO
No Scrum, mesmo que o foco seja a agilidade, ele tem alguns poucos
processos, também conhecidos como artefatos, conforme mostrado abaixo no
fluxograma 3

27
Fluxograma 3- Exemplo do ciclo de vida do Scrum
Fonte: SCRUM (2017)
3.2.1 Product Backlog
Esta etapa, pode ser entendida como uma lista de requisitos e funcionalidades
desejada para o produto. Esta lista pode ser alterada a qualquer momento, e
geralmente seu conteúdo é realizado pelo Product Owner. Não é necessário que ela
se encontre completa no começo do projeto, visto que a natureza do Scrum é ser
mutável então se pode mudar e alterar constantemente para atender as necessidades
do cliente. Contudo, a lista tende a aumentar conforme se aprende mais sobre o
produto e os usuários do mesmo. Uma das maneiras para obtenção de detalhes sobre
o projeto é a utilização de user story12
, a fim de aumentar o detalhamento do que o
cliente almeja com o projeto
12
Tradução Literal: História do usuário

28
3.3.2 Sprint Planning
No Sprint Planning13
, ou também conhecido como Sprint Planning Meeting14
, é
o momento em que as dúvidas por parte do Scrum Tream são tiradas com o Product
Owner . Nesta etapa é recomendado que esteja presente o Scrum Team por completo,
sendo opcional a presença do Scrum Master, o foco é de sanar dúvidas técnicas e
quebrar as funcionalidades.
Não é necessário que o Product Owner descreva todos os itens presentes no
processo do obtido para o Product Backlog, contudo ele deve descrever os itens que
possuírem maior prioridade ao projeto no todo, quebrando, assim, as user story em
partes e criando a lista de tarefas para o Sprint Backlog.
Neste momento, de maneira conjunta, tanto o Product Owner como o Scrum
Team definem o objeto para a Sprint, que busca uma pequena descrição do que será
a Sprint.
Após esta reunião, o Scrum Team se encontra em separado para conversarem
sobre o que foi apresentado na Sprint Planning e decidirem o quanto cada um irá se
comprometer para a Sprint atual. Este é o momento em que a Scrum Team se
responsabilizará e irá determinar o que é capaz de fazer no Sprint atual.
3.3.3 Sprint Backlog
O Sprint Backlog consiste em uma lista de atividades que o Scrum Team se
compromete em realizar durante o Sprint atual. Ele é baseado nas prioridades
fornecidas pelo Product Owner e pelo entendimento necessário do Scrum Team para
completar todas suas funcionalidades.
A quantidade de itens que uma equipe pode assumir é aberta, sem
limites mínimos ou máximos, cuja de comprometimento com a realização dos itens
continua em vigência.
13
Tradução Literal: Planejamento da Sprint
14
Tradução Literal: Reunião de planejamento da Sprint

29
3.3.4 Sprint
A Sprint, como espelhado no rúgbi, consiste em uma corrida de alta velocidade
em um curto período de tempo, o qual representa em quanto tempo a Sprint será
realizada. É nesta etapa que propriamente começa o desenvolvimento do projeto.
As durações da Sprint, segundo Cruz (2016), devem ser pelas regras entre
duas a quatro semanas no máximo, de forma que o mesmo recomenda que
inicialmente as Sprint possuam no máximo duas semanas, para que assim o Scrum
Team aprenda sem ficar com incertezas. Como tudo no Scrum é baseado em time-
box, todo o esforço despendido no projeto tem duração fixa e trabalho pré-
estabelecido. Segundo Campos (2011), no Scrum o time-box é aplicado em todos os
momentos, desde os Sprints até as reuniões também conhecidas como Daily Scrum
Quando a Sprint ou item do backlog é terminado por completo, o valor de
“Pronto” é assumido, assegurando que foi completo um item do backlog, uma
funcionalidade ou até mesmo a Sprint.
3.3.4.1 Daily Scrum
A Daily Scrum é uma reunião feita diariamente por todo o time de
desenvolvimento, com alguns pré-requisitos como:
 O time-box dela não pode ultrapassar 15 minutos;
 Todos os membros devem permanecer em pé;
 A presença do Product Owner é opcional;
 A presença do Scrum Master é recomendada para que ele remova
impedimentos no decorrer do projeto;
 Sutherland, Viktorov e Blount (2007) recomendam realizar durante o
período da manhã;
O foco da Daily Scrum deve ser baseado em 3 perguntas para serem
respondidas por cada membro
 O que você realizou ontem?
 O que você realizará hoje?
 Existiu algum impedimento no seu caminho?

30
Desta forma o tempo da Daily Scrum não supera os 15 minutos previstos no
time-box e torna o processo mais ágil no quesito problemas.
3.3.4.2 Cancelamento do Scrum
No decorrer da Sprint, apenas o Product Owner pode cancelar uma Sprint
inteira, caso a meta do Sprint não possua mais o foco que almejava ou se torne
antiquada. Mesmo não sendo comum o cancelamento da Sprint, caso ocorra o
cancelamento os itens presentes no Product Backlog, que estejam em situação de
completos e/ou prontos, devem ser revisados para que possam representar uma
melhoria de valor para o projeto.
3.3.5 Sprint Review
O Sprint Review consiste na apresentação da do produto funcionando, o qual
a Scrum Team se encarregou de realizar naquele Sprint. Nesta etapa é necessário
que estejam presentes, Product Owner , Scrum Team, Scrum Master, gerentes e se
possível, partes interessadas como clientes.
Esta etapa possui uma duração que varia entre uma à duas horas. E tem como
objetivo validar se todos os itens planejados no Sprint Planning, foram alcançados ou
não na Sprint, de maneira a assegurar se o caminho definido pela equipe está certo
ou não, mitigando os riscos da não aceitação do projeto final.
3.3.6 Sprint Retrospective
Como o Scrum se baseia no ciclo de Deming, esta etapa é o prefácio para o
início de outra Sprint, de maneira que os participantes incluem a Scrum Team, Product
Owner, Scrum Master e opcionalmente gerentes ou partes interessadas (a fim de
remover qualquer obstáculo futuro). Ela possui um time-box um pouco maior do que
a Sprint Review, variando entre duas a quatro horas.
Contudo, nesta etapa ela encerra oficialmente a Sprint e foca no projeto em si,
com reflexões que visam a Qualidade do projeto, conforme questões citadas na seção

31
3.3.4.1 sobre a Daily Scrum. Após o conseguirem estas respostas, se inicia o ciclo da
nova Sprint, incrementando e melhorando o que foi feito até o momento inclusive.
3.3.7 Increment
Como Schwaber e Sutherland (2016) descrevem no Guia do Scrum, o
increment15
é a soma dos itens do backlog do produto realizados na Sprint e possuam
o status “Pronto” associado a eles. Podem ser pequenas funcionalidades do produto
ou o produto em si, desde que esteja previsto no Sprint.
Por se desenvolver de forma em espiral, conforme ilustrado no fluxograma 4,
ilustrado na página a seguir, o incremento produzido em uma Sprint pode ser um ser
um Minimum Viable Product (MVP), que é a versão mais simples do produto produzida
com a menor quantidade de recursos, ou a versão final do produto desenvolvido no
projeto.
O conceito do increment, por se tratar de um modelo em espiral, é ser
incrementado e melhorado conforme aperfeiçoamento de um projeto no ciclo de vida
dele, não se limitando apenas na Sprint do mesmo.
Ilustração 2- Modelo espiral adotado Scrum
Fonte: Carlos Eduardo Faddul Nunes (2017)
15
Tradução literal: incremento

32
4 GESTÃO DA QUALIDADE: UM COMPARATIVO ENTRE WATERFALL E ÁGIL
Quando se aborda o assunto de Gestão de Qualidade, deve-se primeiramente
entender o que será avaliado como qualidade e o que realmente é qualidade no
projeto e para o cliente. É possível usar métricas de benchmarking para comparar
práticas de projetos reais com os demais como Trage (2014) já caracterizou.
Atualmente existem diversos modelos, padrões, boas práticas a fim de garantir
a qualidade, como o padrão da ISO 9000, voltada para o sistema de gestão da
qualidade em ambientes de produção, que surgiu em 1987 em sua primeira versão, e
vem se atualizando desde então, atualmente com sua última versão datada de 2015.
Contudo, normalmente se lembra do famoso Modelo Toyota de Produção, que
Liker e Hoseus (2009) mencionam os pilares centrais para o modelo são o just-in-
time16
e jidoka17
, princípios que vem desde a época Sakichi Toyoda (1867-1930), o
percursor do modelo Toyota, que pouco tempo depois se tornou referência em
qualidade e modelo de administração.
Pela qualidade estar presente em diversos momentos e etapas do projeto, tanto
no waterfall como no ágil, este tema será abordado nos contextos que agregam mais
valor para a entrega de um projeto ao cliente. Todavia deve-se lembrar a definição de
projeto que segundo Maximiano (2002) “é um empreendimento temporário ou uma
sequência de atividades com começo, meio e fim programados e tem por objetivo
fornecer um produto singular dentro das restrições orçamentárias.”. Correlata à esta
definição, se pode entender que três áreas impactam e definem um projeto. As áreas
mencionadas são:
 Escopo
 Custos
 Tempo
A escolha destas áreas, foi baseada por estarem presentes em ambas as
metodologias e devido sua correlação. Estas áreas estão diretamente ligadas ao
projeto desde sua concepção até sua conclusão. Desta forma todas, será utilizada a
16
Quando é mencionado just-in-time se refere que tudo deve ser produzido, transportado ou comprado em horas
exatas, sem antecipação dos mesmos, muito utilizado na indústria automobilística com foco na produção por
demanda.
17
Tradução popular: autonomação, também entendido como automação com toque humano, onde é necessário
um ser humano para supervisionar a produção que é realizada por máquinas

33
visão de Qualidade como a soma das três áreas, como um fator de agregação de valor
ao cliente, de acordo como demonstrado na ilustração 2.
Ilustração 3 - Áreas que definem o sucesso do projeto
Fonte: Carlos Eduardo Faddul Nunes (2017)
4.1 COMPARATIVO SOBRE ESCOPO
Para entender como a qualidade influencia em um projeto desde o princípio,
deve-se entender o que é o escopo e como será avaliado este tema de forma
comparativa.
O escopo consiste em avaliar e detalhar os requisitos necessários para a
execução do projeto. Essa avaliação pode ser feita baseada em experiências prévias
de projetos similares ao que se está para ser desenvolvido.
Nesta avaliação realizada é definida a abrangência de cada processo, como os
riscos associados aos mesmos. Resultando no que será realizado no projeto, tal como
detalhes e funcionalidades contempladas ou não pelo projeto.
A princípio, o conhecimento completo do escopo aumenta a possibilidade de
êxito do projeto, contudo como Maximiano (2002) menciona que o projeto possui
objetivo em fornecer um produto singular, a criação de um escopo, por completo, na

34
etapa de iniciação gera uma contradição, pois como é possível estimar algo que em
teoria é único e nunca foi realizado anteriormente?
Neste ponto a metodologia waterfall, utilizada pelo PMBoK, cria uma
inconsistência, uma vez que ela só permite que se crie um protótipo, após ter avaliado
e documentado, na etapa de iniciação e planejamento, pois este tempo gasto nestes
processos, acaba gerando uma desvantagem no projeto, em razão que caso tenha
sido mal analisado, tanto o custo como o tempo, irão sofrer de um aumento
significativo para que se possa realizar correções no escopo e se alinhar ao que é
demandado do projeto.
Mesmo sendo analisado todos os possíveis cenários, definidos os potenciais
riscos (tanto internos como externos ao projeto), consultando as lições aprendidas de
projetos anteriores parecidos, acontecem problemas que podem inviabilizar um
projeto por completo como, por exemplo, a de falta de equipe ou problemas
associados ao local para desenvolver o projeto. Neste momento, já tendo sido
utilizados e desperdiçados recursos nas etapas de Iniciação e Planejamento, forçando
que o projeto se reinicie para readequar os requisitos desejados.
No contraponto do PMBoK, o Scrum, que se utiliza da metodologia ágil, gera
uma vantagem, pois ao ter um processo mais simplificado em questões de fases, tal
como recursos humanos, ele se baseia em um escopo aberto, focando em entregar
valor18
, por ele não se limitar ao que pode acontecer tal como um fluxo previamente
definido de ações.
Pelo fato de ser uma equipe enxuta e multifuncional, no Scrum, a criação do
MVP, necessita de poucos recursos nas áreas de Recursos Humanos e Tempo,
focando na criação de valor ao cliente, tornando o projeto mais palpável em menos
tempo e processos do que o proposto pelo PMBoK, uma vez que Sutherland(2014)
menciona que o Scrum se assemelha ao ciclo PDCA de Deming, do qual é focado em
observar, avaliar, decidir e agir.
Um exemplo de sucesso em escopo, pode ser entendido como o da
Ideo..(2012), onde é demonstrado, como um escopo sendo menos burocrático e
aberto para as mudanças, do que o sugerido pelos processos do PMBoK, que visa a
geração de valor do projeto ocorrerá a partir da quarta fase dele nomeada
18
A partir deste momento, o conceito de qualidade será equivalente ao de valor, devido ao retorno que o projeto
irá obter após alcançada tal qualidade esperada.

35
Monitoramento e Controle19
, após terem sido realizados pouco mais de 30 processos,
causando pouca certeza de garantia de valor sobre o projeto, visto que o escopo tende
em ser alterado com o decorrer do projeto fazendo com que os requisitos aumentem
e/ou diminuam.
4.2 COMPARATIVO SOBRE TEMPO
O tempo no projeto, é o que muitas vezes define o sucesso ou fracasso na
visão do cliente. Ele é considerado desde a fase inicial de análise do projeto até a
entrega do mesmo.
Como o foco do projeto sempre é gerar valor ao cliente, podemos assentir, que
teoricamente, quando mais rápido for entregue o projeto, mais rápido será obtido o
valor para o cliente.
Inicialmente a afirmação pode ser entendida como concreta, no entanto, a
escolha da metodologia para o projeto pode impactar diretamente tempo e no sucesso
do projeto.
Tomando como exemplo o modelo waterfall do PMBoK, o desenvolvimento de
um projeto ocorrerá com a utilização sete processos para gerenciamento de tempo e
mesmo assim existindo possibilidades de fracasso do projeto tal como o uso do
Scrum.
Entretanto, deve-se atentar de que projetos são sempre feitos por pessoas e
para resolver problemas de pessoas e mesmo que no modelo proposto pelo PMBoK,
possuam processos relacionados aos Recursos Humanos, no momento de estimar o
tempo e atividades e definir atividades associadas, as estimativas são realizadas de
maneira top-down20
, onde ao mesmo tempo em que se demonstra formalmente como
será executado o projeto, se perde na área de Gestão de Pessoas, pois é
desconsiderado neste momento as dificuldades em que as equipes podem ter para
alcançar uma parte empregável do projeto.
Em contrapartida, na relação de tempo para a geração de valor no projeto, o
modelo oferecido pelo Scrum utilizando uma abordagem down-top21
, onde as equipes
19
Ver seção 2.2.4 Monitoramento e Controle
20
Tradução literal: de cima para baixo
21
Tradução literal: de baixo para cima

36
que irão desenvolver o projeto se responsabilizam pelos ciclos e isso acaba se
destacando no quesito de tempo, pois ao mesmo tempo de utilizar equipes
multifuncionais e enxutas, um novo increment utilizável do projeto é entregue a cada
ciclo, aumentando as funcionalidades continuamente ao mesmo tempo em que o
cliente já se utiliza do projeto, desta maneira garantindo a qualidade e o aceite
constante por parte do cliente.
4.3 COMPARATIVO SOBRE CUSTOS
O custo em um projeto é algo que influência tanto quanto a participação de
partes interessadas. Segundo o PMBoK (2014), “Se não for possível um aumento no
orçamento, o escopo ou a qualidade poderão ser reduzidos para entregar o produto
do projeto em menos tempo, com o mesmo orçamento.”.
Como é uma pirâmide de áreas correlacionadas, o custo é um dos fatores que
impactam mais claramente na visão de valor para o projeto. Entretanto os custos,
possuem uma razão de elasticidade, quanto mais desenvolvimento existir no projeto,
maior será o custo, tempo e escopo; quanto menos desenvolvimento, menos será
demandado em tempo, escopo e custo, porém não serão inexistentes no decorrer do
projeto possíveis aumentos.
No PMBoK, os custos possuem quatro processos, sendo três distribuídos na
fase de Planejamento e um na fase de Monitoramento e Controle. Todavia o
planejamento financeiro do projeto, é todo construído em torno de apenas três itens:
 EAP
 Plano de desenvolvimento do projeto
 Cliente
Possuindo nos processos, detalhamento de como serão medidas a precisão,
exatidão, limites de controles, entre outros itens, para que se torne aceitável no projeto
qualquer possibilidade de aumento ou redução de custos.
A abordagem utilizada pelo PMBoK para custos, visa ser utilizada de um ou
mais projetos ao mesmo tempo, criando uma estrutura onde os gastos são previstos
e possuem como apresentar o ROI, no decorrer até o final do projeto, desse modo
facilitando potenciais aquisições referente ao projeto, posto que a destinação de
recursos é feita de forma organizada e documentada.

37
Enquanto na metodologia ágil, segundo Sutherland (2016):
Se você começa um projeto e pouco depois
percebe que o valor verdadeiro, aqueles 20%,
não está nos atributos que você definiu — está
em um conjunto diferente que você descobriu
no decorrer do trabalho —, então o
gerenciamento de projetos tradicional foi
projetado para impedir isso.
(SUTHERLAND,2016)
Essa realocação dos recursos livremente, sugerida por Sutherland, pode
causar conflito de interesses. Pois ao se realocar um recurso, de natureza humana ou
financeira, a fim de aumentar o valor do projeto atual, acaba por si podendo afetar
outro projeto, pois o recurso pode estar em outro projeto com outras finalidades, e
quando for recurso humano que se é tratado, pelas equipes serem pequenas e
multifuncionais, este recurso pode acabar prejudicando outra parte do projeto e/ou
outro projeto.

38
5 CONCLUSÃO
Cada metodologia aborda o projeto de uma forma, cuja a abordagem impacta
na qualidade do projeto, tal como a conclusão do mesmo. Ambas metodologias
possuem pontos fortes e fracos, a escolha da metodologia deve ser baseada nos
aspectos do projeto, sendo análogos aos já desenvolvidos pela equipe, tal como a
equipe tem que ser observada, em termos de tamanho e experiência.
Na metodologia waterfall, uma das vantagens seria que ela por ser tradicional,
se torna mais fácil de ser entendida e gerenciada com uma equipe que possui pouca
experiência e/ou uma equipe muito grande. Paralelamente algumas das desvantagens
se deve ao fato que o PMBoK ser altamente estruturado, cujo o impacto de uma
mudança, acarreta na demora que leva para a mesma seja executada, o que resulta
em atrasos nas diversas outras áreas, fazendo com que o projeto perca valor. Outra
desvantagem seria a aplicação dele em projetos cuja demanda de recursos é
reduzida, influenciando no tempo e custo do mesmo. No entanto para projetos de
maior complexidade, como por exemplo em programas22
, se torna indicado para
melhor controle e gestão de todos os projetos.
Uma vez que na metodologia ágil, uma das vantagens seria por ela requisitar
que as equipes sejam enxutas e multifuncionais, desta forma facilmente gerenciáveis.
Outro aspecto positivo é devido as constantes pequenas entregas alinhadas ao
cliente, desta forma validando o projeto de maneira constante. Entretanto a utilização
do Scrum, se limita em projetos avulsos, não abrangendo programas, pois torna o
gerenciamento um tanto quanto complexo e incerto; outro fator que se deve ter
atenção é caso a equipe seja pouco experiente e não tenha uma boa comunicação
entre si, acarretará que a Sprint irá falhar constantemente, juntamente com o nas
Sprints iniciais podem acontecer atrasos, tal como imprecisões nas responsabilidades
assumidas pela equipe.
Ambas as metodologias possuem pontos válidos para sua utilização, ainda
assim é possível implementar algumas fases e conceitos da metodologia ágil dentro
da waterfall e/ou vice-versa, no entanto se deve ter cuidado, pois a equipe que
22
A definição de programa, é a que diversos projetos são executados simultaneamente para concepção de um
projeto que abrange todos.

39
desenvolverá o projeto, pode acabar tendo um desarranjo entre si, desde os papéis
que serão desempenhados até na Qualidade do projeto.

40
REFERÊNCIAS
AMBYSOFT. 2013 IT Project Success Rates Survey Results. Disponível em:
<http://www.ambysoft.com/surveys/success2013.html>. Acesso em: 10 abr. 2017.
ARANTES, Adriano Torres de Lima; LIMA, Cleisiane de Souza. O Aspecto Humano
na Gestão de Projetos de Sucesso: A Influência da Inteligência Emocional.
Disponível em:
<http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/674>. Acesso em:
02 abr. 2016.
CAMPOS, Ester Lima de. Time Box no Scrum. 2011. Disponível em:
<http://blog.myScrumhalf.com/2011/11/time-box-no-Scrum/>. Acesso em: 30 mar.
2017.
CARELI, Gabriel. Uso Eficaz De Indicadores De Recursos Humanos. 2015.
Disponível em: <http://www.rhportal.com.br/artigos/rh.php?idc_cad=7qgc42bu7>.
Acesso em: 30 mar. 2016.
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. Disponível em:
<http://dx.doi.org/10.1590/S0104-530X2012000300009>. Acesso em: 30 mar. 2017.
CARVALHO, Marly Monteiro de; PALADINI, Edson Pacheco. Gestão da Qualidade:
Teoria e Casos. 2. ed. [s. L.]: Campus, 2012. 456 p.
CRUZ, Fabio. Sprint. 2016. Disponível em:
<http://www.fabiocruz.com.br/outros/sprint-1/>. Acesso em: 30 mar. 2017.
DAFT, Richard L.. Organizações - Teoria e Projetos. S.l: Cengage Learning, 2015.
688 p.
IDEO - Processo de criação. Produção de Abc News. S.l., 2009. (9 min.), son., color.
Legendado. Disponível em: <https://vimeo.com/7953312>. Acesso em: 20 fev. 2017.
INSTITUTE, Project Management. Um Guia do Conhecimento em Gerenciamento
de Projetos: Guia PMBOK®. 5. ed. Brasil: Saraiva Editora, 2014.
MAXIMIANO, Antônio Cesar Amaru. Administração de Projetos: como transformar
idéias em resultados. 2. ed. – São Paulo: Atlas, 2002.
MONTES, Eduardo. Grupo de Processos de Iniciação. 2016. Disponível em:
<https://escritoriodeprojetos.com.br/grupo-de-processos-de-iniciacao>. Acesso em:
20 mar. 2017.

41
MONTES, Eduardo. Grupo de Processos de Planejamento. 2016. Disponível em:
<https://escritoriodeprojetos.com.br/grupo-de-processos-de-planejamento>. Acesso
em: 20 mar. 2017.
PALMA, Fernando. A Matriz RACI é a solução dos seus problemas ! Disponível
em: <http://www.portalgsti.com.br/2013/04/matriz-raci.html>. Acesso em: 30 mar.
2016.
PRIES, Kim H.; QUIGLEY, Jon M.. Scrum Project Management. Eua: Crc Press,
2010. 256 p.
ROYCE, Winston Walker. Managing the development of large software systems.
S.l: S.n., 1970. Disponível em:
<http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf>. Acesso
em: 20 fev. 2017.
SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum. [s.l.]: [s.n.], 2016. 18 p.
Disponível em: <https://www.Scrumguides.org/docs/Scrumguide/v2016/2016-Scrum-
Guide-Portuguese-Brazilian.pdf>. Acesso em: 30 mar. 2017.
SCRUM. What is Scrum? Disponível em: <https://www.Scrum.org/resources/what-is-
Scrum>. Acesso em: 30 mar. 2017.
STEFFEN, Juliana Berossa. O que são essas tais de metodologias Ágeis ? 2012.
Disponível em:
<https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_q
ue_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en>. Acesso em: 20
mar. 2017.
SUTHERLAND, Jeff et al. Manifesto para o desenvolvimento ágil de software.
2001. Disponível em: <http://www.manifestoagil.com.br/>. Acesso em: 20 mar. 2017.
SUTHERLAND, Jeff. SCRUM a arte de fazer o dobro do trabalho na metade do
tempo. Brasil: Leya, 2016. 240 p.
SUTHERLAND, Jeff; VIKTOROV, Anton; BLOUNT, Jack. Distributed Scrum: Agile
Project Management with Outsourced Development Teams. 2007. Disponível em:
<http://ieeexplore.ieee.org/document/4076936/>. Acesso em: 30 mar. 2017.
TAKEUCHI, Hirotaka; NONAKA, Ikujiro. The New New Product Development Game.
1986. Disponível em: <https://hbr.org/1986/01/the-new-new-product-development-
game>. Acesso em: 30 abr. 2017.
TRAGE, Rodrigo. Integrando o framework i* ao processo de planejamento de
qualidade de software proposto pelo guia PMBOK. 2014. 108 f. TCC (Graduação)
- Curso de Ciência da Computação, Universidade Estadual do Oeste do Paraná,
Cascavel, 2014.
VARGAS, Ricardo Viana. Gerenciamento de Projetos: Estabelecendo Diferenciais
Competitivos. 8. ed. S.l: Brasport, 2016.

42
VAZ, Thassia. Ciclo PDCA: uma ferramenta imprescindível ao gerente de
projetos! Disponível em: <http://www.projectbuilder.com.br/blog-
pb/entry/pratica/ciclo-pdca-uma-ferramenta-imprescindivel-ao-gerente-de-projetos>.
Acesso em: 01 abr. 2016.
VENKI (Comp.). O que é o Ciclo PDCA? Entenda em Detalhes cada etapa.
Disponível em: <http://www.venki.com.br/blog/o-que-e-ciclo-pdca/>. Acesso em: 01
abr. 2016.

Comparativo entre Waterfall e Scrum na Gestão da Qualidade

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Comparativo entre Waterfall e Scrum na Gestão da Qualidade

Semelhante a Comparativo entre Waterfall e Scrum na Gestão da Qualidade (20)

Comparativo entre Waterfall e Scrum na Gestão da Qualidade