Você está na página 1de 13

METODOLOGIA ÁGIL – FRAMEWORK SCRUM – EM

GERENCIAMENTO DE PROJETOS DE SOFTWARE.

Jaqueline Martins¹
Discente do Curso de Pós-Graduação em MBA em Gerenciamento de Projetos do Centro
Universitário de Lins – Unilins, Lins-SP, Brasil
jaqmarttins@gmail.com

Renato Marcelo Teixeira de Menezes²


Docente do Curso de Pós-Graduação em MBA em Gerenciamento de Projetos do Centro
Universitário de Lins – Unilins, Lins-SP, Brasil
rmenezes@fpte.br

Resumo the most part, in the Information Technology


O presente artigo discute o uso de metodologias field. Focusing on customer satisfaction, agile
ágeis em gerenciamento de projetos. Elas methodologies are characterized by flexibility
nasceram no berço do desenvolvimento de to change and by having an alternative
software e, atualmente, são usadas, em sua management form compared to the traditional
maioria, na área de Tecnologia da Informação. methodologies. Through a bibliographic review
Com foco na satisfação do cliente, as research, the objective of the article is to show
metodologias ágeis são caracterizadas pela the benefits that these methodologies offer to
flexibilidade às mudanças e possuem uma the management of software projects, to present
forma alternativa de gerenciamento em relação the agile Scrum framework, as well as to detail
às metodologias tradicionais. Por meio de uma its operation and perform a comparative
pesquisa de revisão bibliográfica, o objetivo do analysis between agile and Traditional.
artigo é mostrar os benefícios que essas
metodologias oferecem à gestão de projetos de Keywords: Agile methodologies. Information
software, apresentar o framework1 ágil Scrum2, Technology. Flexibility. Scrum.
bem como detalhar o seu funcionamento e
realizar uma análise comparativa entre os
métodos ágeis e tradicionais. 1 Introdução

Palavras-chave: Metodologias Ágeis. Atualmente, muitas organizações estão


Tecnologia da Informação. Flexibilidade. trabalhando com projetos e estes necessitam ser
Scrum. gerenciados para se obter êxito.
Segundo o PMBOK3, “Projeto é um
esforço temporário empreendido para criar um
Abstract produto, serviço ou resultado exclusivo. A
This article discuss the use of agile natureza temporária dos projetos indica que eles
methodologies in project management. They têm um início e um término definidos. O
have emerged in the cradle of software término é alcançado quando os objetivos do
development and have been currently used, for projeto são atingidos ou quando o projeto é
1 3
Estrutura Guia com conjunto de práticas para gestão de projetos, organizado
2
Framework Ágil pelo instituto PMI e considerado a base do conhecimento sobre gestão
de projetos.
1
encerrado porque os seus objetivos não serão ou comparativa entre os métodos ágeis e
não podem ser alcançados, ou quando a tradicionais.
necessidade do projeto deixar de existir. ” Os conceitos apresentados a seguir são
(PMBOK, 2013, p. 03). fundamentais para o entendimento do contexto
Diferentemente das operações, que são do artigo, pois possuem um elo, visto que
contínuas e repetitivas, os projetos são softwares são considerados produtos,
temporários. Resumidamente, tem início e fim, desenvolvidos em forma de projetos, e que a
e dentro desse período existem as fases que engenharia de software consiste na aplicação de
necessitam ser gerenciadas. “Gerenciamento de processos que garantam qualidade ao software.
projetos é a aplicação do conhecimento, Ainda, o conceito de metodologia tradicional é
habilidades, ferramentas e técnicas às importante para entender porque surgiram as
atividades do projeto para atender aos seus metodologias e frameworks de
requisitos. ” (PMBOK, 2013, p. 05). desenvolvimento ágil para serem aplicadas em
Para o desenvolvimento de um projeto é gerenciamento de projetos.
de suma importância a adoção de uma
metodologia, que nada mais é que um conjunto
de regras a ser seguido visando a sua conclusão 1.1 Software e engenharia de software
com sucesso.
“Visto que os projetos são temporários Segundo Pressman, “software é o produto
em natureza, seu sucesso deve ser medido em que profissionais de software desenvolvem e ao
termos da sua conclusão dentro das restrições qual dão suporte ao longo prazo. Abrange
de escopo, tempo, custo, qualidade, recursos e programas executáveis em um computador de
risco. “ (PMBOK, 2013, p.35). qualquer porte ou arquitetura, conteúdos
Embora exista todo um planejamento, (apresentados à medida que os programas são
monitoramento e controle, mudanças podem executados) e informações.
ocorrer e os Gerentes de Projetos, junto com a A engenharia de software, por sua vez,
equipe, devem estar preparados para contornar abrange um processo, um conjunto de práticas
esse tipo de imprevisto da melhor maneira e ferramentas que possibilitam aos profissionais
possível, evitando que impactem de forma desenvolverem software de alta qualidade. ”
negativa, principalmente, no orçamento do (PRESSMAN, 2011, p.29).
projeto. E as metodologias ágeis são
caracterizadas pela adaptação a essas possíveis
mudanças. 1.2 Metodologias tradicionais de
O Scrum é um framework de desenvolvimento de software
desenvolvimento ágil que busca melhorias no
desenvolvimento de projetos, especialmente em As metodologias tradicionais de
projetos de software – onde é utilizado em sua desenvolvimento de software, ou metodologias
maioria – buscando a satisfação do cliente. clássicas, são caracterizadas pela
Mas, como funciona o Scrum? Por que documentação abrangente e pela ordem e
utilizar metodologias ágeis em projetos de disciplina no decorrer do desenvolvimento,
desenvolvimento de software? Quais são as garantindo um controle excessivo dos
vantagens em relação às metodologias processos.
tradicionais? É possível associar o framework Um tipo de metodologia tradicional ou
às boas práticas citadas pelo PMBOK? clássica é o modelo cascata. Segundo Paige
Diante dos questionamentos acima, por Baltzan, em seu livro “Tecnologia Orientada
meio de uma pesquisa de revisão bibliográfica, para Gestão”, a principal característica do
o objetivo do artigo é mostrar os benefícios que modelo é a divisão do projeto em etapas que
essas metodologias oferecem à gestão de seguem uma sequência linear, onde a próxima
projetos de software, apresentar o framework se inicia somente após o termino da anterior. As
ágil Scrum, bem como detalhar o seu metodologias tradicionais são consideradas
funcionamento e realizar uma análise rígidas e burocráticas.
2
» Flexibilidade às mudanças;
1.3 História do manifesto ágil » Entrega em menor tempo;
De acordo com o site agilemanifesto.org,
» Interação;
o Manifesto Ágil surgiu nos EUA, em fevereiro » Indivíduos motivados;
de 2001, a partir de uma reunião realizada com » Conversa face a face;
dezessete pessoas, especialistas em processos
de desenvolvimento de softwares, cada qual » Software funcionando;
com suas peculiaridades (representantes de » Desenvolvimento sustentável;
Extreme Programming4, Scrum, DSDM5,
Adaptive Software Development6, entre outros), » Excelência técnica e bom design;
que decidiram se reunirem em busca de » Simplicidade;
melhorias no desempenho dos projetos.
Buscavam reagirem contra métodos » Auto-organização;
“pesados” - assim caracterizados por possuírem » Reflexão em intervalos regulares.
uma regulamentação rígida - usados no modelo
Compreender os valores destes doze
cascata para desenvolvimento de software
princípios, e aplicá-los em projetos, pode trazer
(modelo sequencial), visto como burocrático e
inúmeras melhorias.
lento comparado à forma com que os
engenheiros de software desempenhavam o
trabalho.
1.4 Scrum
Conforme consta no site
agilemanifesto.org, a reunião foi simbólica e
Em virtude do Manifesto Ágil, outras
deu origem a “Agile Alliance”, ou seja, Aliança
metodologias e frameworks alternativos foram
Ágil, composta pelo grupo de pensadores que
ganhando espaço, entre eles: o Scrum.
estabeleceu o Manifesto Ágil para
Scrum é um framework de
desenvolvimento de softwares, com base em
desenvolvimento ágil que busca melhorias no
quatro valores, descritos no site:
desenvolvimento de projetos, especialmente em
»“ Indivíduos e interações entre eles projetos de software – onde é utilizado em sua
mais que processos e ferramentas. ” maioria – buscando a satisfação do cliente.
»
“ Software em funcionamento mais Segundo o “Guia do Scrum”,
desenvolvido por Ken Schwaber e Jeff
que documentação abrangente. ”
Sutherland: “ Scrum emprega uma abordagem
» “ Colaboração com o cliente mais que iterativa e incremental para aperfeiçoar a
negociação de contratos. ” previsibilidade e o controle de riscos. Três
»“ Responder às mudanças mais que pilares apoiam a implementação de controle de
processo empírico: transparência, inspeção e
seguir um plano. ”
adaptação “ (SCHWABER; SUTHERLAND,
Embora cada envolvido tivesse suas
2013, p.04).
particularidades, todos concordavam, com base
É composto por um time, denominado
em suas prévias experiências, que quando os
Scrum Team7, formado por três integrantes
projetos eram bem-sucedidos um conjunto
principais: Product Owner8, Scrum Master9 e
composto por doze princípios parecia ter sido
Development Team10.
cumprido:
E por artefatos e eventos importantes,
» Foco no cliente; entre os principais: Product Backlog11,

4 8
Metodologia ágil de desenvolvimento de software Dono do produto
5 9
Metodologia ágil de desenvolvimento de software Líder Scrum
6 10
Técnica de desenvolvimento de software adaptativo Equipe de desenvolvimento
7 11
Equipe Scrum Backlog (lista) do produto
3
Planning Sprint12, Sprint13, Daily Scrum14,
Sprint Review 15e Sprint Retrospective16, que Baltzan destaca os problemas
serão detalhados na dinâmica do processo do relacionados à metodologia cascata
framework adiante. (tradicional). “A metodologia em cascata é
problemática na medida em que presume que os
usuários podem especificar todos os requisitos
1.5 Metodologias tradicionais e metodologias de negócio com antecedência. Definir a
ágeis infraestrutura adequada que seja flexível,
escalável e confiável é um desafio. A solução
As metodologias tradicionais, mesmo final da infraestrutura de TI deve responder não
com o surgimento das metodologias ágeis, só às necessidades atuais, mas também às
ainda estão presentes na gestão de projetos de futuras, em termos de tempo, custo, viabilidade
desenvolvimento de software, porém já não são e flexibilidade. A visão é inevitavelmente
mais tão adequadas ao atual ambiente de limitada à frente da cascata. ” (BALTZAN,
negócios, onde os clientes querem retorno do 2016, p. 281)
benefício o mais rápido possível. O método tradicional possui processos
De acordo com Paige Baltzan, em seu extremamente organizados e o escopo, uma vez
livro “Tecnologia Orientada para Gestão”, a definido, não é recomendado que se altere. Os
metodologia cascata, também conhecida como processos são muito bem disciplinados.
tradicional, consiste em uma sequência de Uma das grandes vantagens da utilização
fases, onde o resultado de cada uma delas se desses métodos é a organização em demasia e
torna o subsídio para a próxima. (BALTZAN, etapas bem documentadas, uma vez que o
2016, p. 280) projeto possua requisitos fixos.
São consideradas metodologias E a desvantagem é que não é flexível às
“pesadas”, marcantes por serem divididas em mudanças e o cliente só usufrui do produto ao
fases, onde cada fase concluída deve ser final da sequência do modelo cascata.
documentada, gerando um marco de conclusão. “ Hoje em dia, o trabalho de software tem
Esse modelo se inicia com a um ritmo acelerado e está sujeito a uma cadeia
especificação de requisitos pelo cliente, de mudanças intermináveis (em características,
planejamento, análise, design, funções e conteúdo de informações). O modelo
desenvolvimento, teste, implementação e cascata é frequentemente inapropriado para tal
finaliza com a manutenção. trabalho. Entretanto, ele pode servir como um
modelo de processo útil em situações nas quais
Figura1 – Modelo Cascata/Tradicional os requisitos são fixos e o trabalho deve ser
realizado até a sua finalização de forma linear.
” (PRESSMAN, 2011, p. 61).
Os métodos tradicionais funcionam, mas
é essencial que o projeto esteja completamente
planejado, com todos os requisitos enfatizados
e não variáveis por um cliente que não exija
utilizar o software antes de estar completamente
pronto.
“ Os conceitos existentes relacionados ao
desenvolvimento ágil de software foram
motivados por uma reação adversa aos
chamados “métodos pesados” de
Fonte: Paige Baltzan - (2016) desenvolvimento de software, caracterizados
por um formalismo muito grande nas

12 15
Planejamento do ciclo Revisão do ciclo
13 16
Ciclo (período) Retrospectiva do ciclo
14
Scrum diário
4
documentações e regulamentações, sendo, na colaborar com a equipe, ativamente, para
sua maioria, micro gerenciados pelo tradicional garantir o sucesso do projeto;
e burocrático modelo em cascata. A partir desta » Scrum Master: Assemelha-se a um
reflexão, novos frameworks para processos de coach17, um facilitador e um líder (e não à
desenvolvimento de software começaram a figura do gerente) que ajuda os indivíduos
surgir, sendo conhecidos inicialmente pela envolvidos a entender e praticar os valores e
denominação “métodos leves ” ou Lightweight princípios do framework. Está diretamente
Methods. “ (SBROCO, 2012, p.87) ligado à produtividade da equipe, poupando-a
Segundo PMBOK, “Os ciclos de vida das interferências externas e auxiliando-a na
adaptativos (também conhecidos como resolução de problemas.
direcionados à mudança ou utilizadores de » Development Team: São as pessoas
métodos ágeis) são projetados para reagir a que, de fato, irão colocar a “mão na massa” e
altos níveis de mudança e envolvimento construir o projeto, os responsáveis pela
contínuo das partes interessadas. ” (PMBOK, concepção do produto desejado. Na visão da
2013, p.46). As metodologias ágeis utilizam um metodologia tradicional de desenvolvimento
processo iterativo e incremental e, por sua vez, corresponde aos analistas, administradores de
são adaptativas às mudanças que podem bancos de dados, programadores, etc. Essa
ocorrer. equipe deve ser auto-organizada para definir a
Iterativo corresponde à repetição, melhor forma de desenvolver o trabalho, com
reiteração, frequentativo. “O incremental vem foco na meta estabelecida pelo Product Owner.
exatamente do fato que a cada entrega (final de
fase) o produto ganha mais um pedaço e vai Figura 2. Scrum Team
crescendo e sendo incrementado com mais
valor, até que se torne um produto completo e o
projeto seja encerrado. ” (CRUZ, 2013, p. 17).
O próximo tópico detalhará o
funcionamento do framework de
desenvolvimento ágil Scrum, onde será
possível perceber a iteratividade e incremento
do processo, o que facilita as possíveis
mudanças e agrega valor para o cliente.

1.6 Detalhamento do framework Scrum

Com base no livro escrito por Kenneth S.


Rubin – Essential Scrum. A Practical Guide to
Fonte: Kenneth S. Rubin – (2012)
the Most Popular Agile Process, o framework é
formado por integrantes que compõem o Scrum
Team e que desempenham, basicamente, os
seguintes papéis: 1.7 Dinâmica do Processo
» Product Owner: é o proprietário do
produto/serviço, o ponto central, e tem poder de Tudo começa a partir da visão do produto,
liderança sob o que será desenvolvido. É a e o responsável por provê-la é o Product Owner
pessoa responsável por decidir os recursos que através da especificação dos requisitos
serão utilizados e as funcionalidades, bem desejados.
como a ordem que serão executadas, definindo Em seguida, essa visão é desmembrada
uma priorização das tarefas e, ainda, deve em funcionalidades, dando origem ao artefato

17
Profissional qualificado e que utiliza metodologias, técnicas e
ferramentas do coaching para o benefício de uma empresa ou de um
indivíduo, quer na sua área pessoal ou profissional.
5
Product Backlog - que nada mais é que uma aleatoriamente e seguem a ordem de
lista de funcionalidades necessárias para o prioridades definida pelo Product Owner,
desenvolvimento do projeto. porém, conforme os incrementos de produto
As funcionalidades desmembradas são entregues, poderá haver a necessidade de
devem ser ordenadas por prioridade – definida mudanças e é neste instante que é possível
pelo Product Owner, juntamente com a equipe observar a flexibilidade do Scrum diante delas.
Scrum e as partes interessadas. As mudanças, com suas devidas prioridades,
também deverão ser inseridas no Product
Figura 3. Product Backlog Backlog.
A repetição do processo ocorrerá até que
o produto final esteja completamente
desenvolvido, incluindo as mudanças que
foram solicitadas no decorrer do
desenvolvimento do projeto.

Figura 4. Sprints

Fonte: Kenneth S. Rubin – (2012)

Uma das principais características do


Scrum é a divisão do processo de
desenvolvimento do projeto em ciclos, períodos
de tempo denominados Sprints, onde algumas
funcionalidades do Product Backlog serão Fonte: Mindmaster – (2014)
construídas e entregues.
Os Sprints devem ser planejados de
No processo Scrum são realizadas,
acordo com a complexidade e a capacidade da
diariamente, reuniões com o intuito de saber o
equipe em relação a execução da
andamento do projeto como um todo, onde os
funcionalidade do respectivo período, porém
membros da equipe podem visualizar, de modo
devem obedecer a uma regra do Scrum
geral, a progressão do trabalho do Sprint.
chamada Time-boxed, que corresponde a
Estas reuniões são chamadas de Daily
evento de duração fixa, ou seja, o ideal é que os
Scrum, possuem curta duração, com tempo de
Sprints possuam a mesma duração, que variam
mais ou menos quinze minutos, e em
entre duas a quatro semanas.
decorrência dessa característica também é
Ao término de cada Sprint espera-se uma
chamada de Stand-up Meeting18, em virtude de
entrega/incremento do produto final, se
uma recomendação para que os participantes da
tratando de um software, parte dele deverá ser
reunião fiquem em pé, objetivando uma reunião
entregue funcionando ao usuário. “O trabalho
rápida e objetiva.
realizado em cada Sprint deve criar algo de
Os interrogados respondem a três
valor tangível para o cliente ou usuário. ”
perguntas básicas feitas pelo Scrum Master:
(RUBIN, 2012, p. 20).
Antes de iniciar cada Sprint é realizado o » O que fez ontem?
Planning Sprint, uma reunião onde é definida a
quantidade de funcionalidades para o ciclo.
» O que fará hoje?
É importante lembrar que as » Existe algum impedimento para realizar
funcionalidades não são implementadas a tarefa?

18
Reunião em pé.
6
“ Um Scrum diário, no entanto, pode ser
útil para comunicar o status do Sprint entre os Outra ferramenta muito útil, que traz
membros da equipe de desenvolvimento. benefícios ao projeto em virtude da
Principalmente, o Scrum diário é uma inspeção, transparência que apresenta, é o Kanban Board.
sincronização e atividade de planejamento A ideia é apresentar o fluxo do trabalho e
diário adaptativo que ajuda a equipe fazer seu pode ser feito de diversas formas, com
trabalho melhor. “ (RUBIN, 2012, p. 24). softwares específicos ou em uma simples lousa
onde serão colados post-its20, representando as
Figura 5. Daily Scrum funcionalidades que fazem parte do Product
Backlog.

Figura 7. Kanban Board

Fonte: Mindmaster – (2014)

Existe uma ferramenta útil chamada


Burndown Chart19, muito utilizada em projetos
gerenciados por métodos ágeis. Trata-se de um
gráfico que relaciona o tempo com o esforço
realizado, sendo possível perceber o
adiantamento ou atraso em relação às Fonte: Guia do Excel – (2016)
estimativas, permitindo, dessa forma, medir o
progresso do trabalho e saber como caminha o
Sprint. Ao final do Sprint existem, ainda, duas
O gráfico apresenta uma linha ideal, atividades que são extremamente
tomada com referência, e outra que representa fundamentais: Sprint Review e Sprint
o que foi realizado. Retrospective.
O ideal é que todos os esforços sejam A primeira tem o objetivo de validar o
realizados ao final do tempo para se obter que está sendo construído no projeto, o
sucesso. produto/serviço, e verificar se está sendo feito
de acordo com o planejamento inicial.
Figura 6. Burndown Chart É neste momento que é apresentado o que
foi realizado na funcionalidade do Sprint e,
também, neste momento podem surgir
mudanças e o Product Backlog ser alterado.
É importante ressaltar que as mudanças
também devem seguir um Grooming21 ao serem
inseridas no Product Backlog.
“A revisão do Sprint representa, portanto,
uma oportunidade programada para inspecionar
e adaptar o produto. ” (RUBIN, 2012, p.26).
A segunda, por sua vez, tem o objetivo de
verificar a necessidade de adaptações no
processo, além dos pontos positivos e os
Fonte: Dbbest – (2014) negativos que precisam de melhorias.

19 21
Gráfico de Burndown Atividade de criar e refinar os itens do product backlog, estimando o
20
Bloco de notas composto por pequenas folhas de papel adesivo. tamanho e esforço de cada item.
7
“ Depois que a retrospectiva de Sprint (Irena Balin), “PMBOK e Gerenciamento de
estiver concluída, todo o ciclo é repetido Projetos” (Márcio d'Ávila), “Scrum: A
novamente - começando com a próxima sessão Metodologia Ágil Explicada de forma
de planejamento de Sprint, realizada para Definitiva” (Denisson Vieira) e os livros
determinar o conjunto de trabalho de maior “Tecnologia Orientada Para Gestão” (Paige
valor atual para a equipe focar. ” (RUBIN, Baltzan), “SCRUM e PMBOK unidos no
2012, p.28). Gerenciamento de Projetos” (Fábio Cruz),
A figura a seguir representa a dinâmica do “Engenharia de software. Uma abordagem
processo Scrum, envolvendo os artefatos e professional” (Roger Pressman), “Essential
eventos até chegar a conclusão/incremento do Scrum. A Practical Guide to the Most Popular
produto ou funcionalidade. Agile Process” (Kenneth S. Rubin),
“Metodologias Ágeis. Engenharia de Software
sob Medida” (José Henrique Teixeira de
Figura 8. Processo Scrum Carvalho Sbrocco e Paulo Cesar de Macedo),
“Guia do Scrum. Um guia definitivo para o
Scrum: As regras do jogo” (Ken Schwaber e
Jeff Sutherland), “Practical Risk Assessment
for Project Management” (Stephen Grey) e o
famoso PMBOK.
Será desenvolvido por meio de uma
pesquisa de revisão bibliográfica nos materiais
citados, onde será possível analisar e comparar
as metodologias, com foco no ambiente de
desenvolvimento de projetos de software.
Ao final do artigo serão apresentadas as
conclusões com fundamento nas questões
citadas no tópico da introdução.
A pesquisa por metodologia de revisão
bibliográfica é realizada através de publicações
anteriores, visando a obtenção de um contexto
Fonte: Desenvolvimento ágil – (2013/2014)
para a análise e discussão do tema.

2 Materiais e Métodos
3 Resultados e discussão
O trabalho consiste em um levantamento
A partir das informações apresentadas,
teórico e bibliográfico e será elaborado a partir
torna-se possível discutir qual a metodologia
de materiais já publicados que discutam sobre
ideal para ser utilizada em projetos de
metodologias de desenvolvimento de
desenvolvimento de software. Para isso, será
softwares, entre eles o conteúdo publicado nos
exposto um breve exemplo com o uso de ambas
sites desenvolvimentoagil.com.br e
metodologias, a tradicional e a ágil (aplicada
agilemanifesto.org, os artigos
com o uso do framework Scrum, para análise
“Desenvolvimento de Software: Processos
comparativa entre elas.
Ágeis ou Tradicionais? Uma visão crítica” e
“Metodologias Ágeis para o Desenvolvimento
de Softwares: Aplicação e o Uso da
3.1 Por que utilizar o Scrum no
Metodologia Scrum em Contraste ao Modelo
desenvolvimento de projetos de software?
Tradicional de Gerenciamento de Projetos”,
disponíveis nos sites enacomp.com.br e
revistas.ung.br, respectivamente, e ainda, os Porque, dificilmente, tudo o que foi
trabalhos “Agile Software Development” estimado no início do projeto ocorrerá

8
conforme planejado, embora o ideal não seja em perfeito funcionamento e totalmente
este. documentado.
Mas alguns imprevistos podem trazer Mas, vamos supor que o usuário, ao
riscos para o projeto de acordo com o livro começar a usar o software, note que seria ideal
“Practical Risk Assessment for Project uma tela para cadastro de fornecedores
Management”: também, além das outras que já tinham sido
»
Gastos que superam o orçamento, em implementadas. Estamos, então, diante de um
imprevisto que irá impactar no custo e no tempo
decorrência de prioridades que não foram
do projeto, pois a funcionalidade para cadastrar
previstas inicialmente, mas que são importantes
fornecedores não foi prevista no início do
para o projeto;
planejamento. Este tipo de imprevisto pode
» Consumo de tempo que supera o ocorrer, principalmente, por conta da falta de
cronograma, ao passo em que mais comunicação.
funcionalidades precisam ser implementadas Agora, imaginemos o projeto sendo
ou alguma das existentes necessite ser alterada, desenvolvido utilizando o framework ágil
o que consequentemente gera atraso na entrega Scrum.
do projeto; O escopo foi definido com as mesmas
»
Funcionalidades mal elaboradas que funcionalidades requisitadas. Tais
funcionalidades irão compor o Product Backlog
podem acontecer por diversos motivos, desde o
– tela de cadastro de clientes, tela de cadastro
distanciamento entre os Stakeholders22 até
de produtos e tela de vendas.
problemas internos entre a equipe de
Os Sprints serão definidos e cada um irá
desenvolvimento;
conter a sua respectiva funcionalidade,
» Qualidade reduzida dos produtos conforme planejado no Planning Sprint.
finais. Ao término de um Sprint, a
Portanto, todos estes riscos podem gerar funcionalidade implementada, depois de
perda de contratos futuros. E controlar estes testada e funcionando corretamente, desde que
pontos, que são inerentes em quaisquer não dependa de uma outra, já poderá ser
projetos, é fundamental para garantir que a entregue ao cliente, o que gerará ao mesmo uma
entrega seja realizada dentro do prazo e certa satisfação em poder utilizar o software,
orçamento previstos. mesmo que não esteja totalmente pronto.
Veremos que, com base na dinâmica do As reuniões diárias possibilitarão a
Scrum, citada no referencial teórico deste descoberta da nova funcionalidade – cadastro
trabalho, as mudanças que surgirem no decorrer de fornecedores – antes do término do sistema
do desenvolvimento dos projetos podem ser completo, o que torna possível incluí-la no
solucionadas mais facilmente em decorrência Product Backlog, em ordem prioritária,
dos artefatos e eventos que compõem o inclusive.
framework. Mas, como? No Sprint Review poderemos validar se o
Imaginemos um projeto de software, produto foi desenvolvido conforme planejado e
onde o usuário solicite um software básico para adaptá-lo caso necessário – neste exemplo,
uma loja, que deverá conter uma tela de adaptar a nova funcionalidade de cadastro de
cadastro de clientes e de produtos e uma tela de fornecedores, solicitada pelo cliente - pois essa
vendas. O escopo é definido e a equipe começa revisão é feita para inspeção e adaptação.
a desenvolver. No Sprint Retrospective poderemos
No método tradicional, a equipe iria observar os pontos negativos e positivos do
desenvolver conforme solicitado e entregaria o desenvolvimento do Sprint, o que permite que
produto final, o software completo, com todas no próximo ciclo se aproveite o que foi bom e
as funcionalidades solicitadas implementadas, evite erros.

22
Parte interessada ou interveniente.
9
Com o uso do gráfico de Burndown Chart O quadro a seguir representa uma análise
é possível ver o que foi realizado em relação ao comparativa entre ambos, com ênfase nas
tempo estimado, tornando visível o progresso principais diferenças que puderam ser
do projeto. observadas no decorrer deste trabalho e
Com o Kanban Board, por exemplo, referenciados.
poderemos visualizar o que está aguardando, o
que está em andamento e o que foi concluído. Figura 9. Quadro com análise comparativa
Resumindo, no Scrum, com a simplificada entre metodologias
organização das funcionalidades por
prioridades, as entregas parciais, reuniões
diárias, entre outros eventos, é possível garantir
maior sucesso ao projeto e evitar que mudanças
ocorram em momentos que são prejudiciais ao
projeto, pois quanto antes prever o que precisa
ser incluso ou alterado, menos impacto
negativo será causado.
Este foi um simples exemplo de
desenvolvimento de um software em que é
possível observar os benefícios que os métodos
ágeis trazem para o gerenciamento de projetos,
principalmente, quando não existe um escopo
bem definido e os requisitos são imprevisíveis.
O Scrum é bem-vindo para aumentar a
taxa de sucesso dos projetos, pois as estratégias, Fonte: Elaborado pela autora, 2016
os processos de negócio e os requisitos podem
mudar, mesmo depois do escopo definido,
porque muitas vezes não há boa comunicação
ou, ainda, o cliente não sabe exatamente o que 3.3 Associação das metodologias ágeis com as
deseja. boas práticas do PMBOK
Diferentemente dos métodos tradicionais
que priorizavam a tripla restrição - escopo, O PMBOK contém um conjunto de
prazo e custo - o Scrum prioriza, também, a processos, ferramentas e técnicas, considerado
qualidade do projeto e o valor agregado. um guia de boas práticas para gerenciamento de
projetos.
É composto por grupos de processos
3.2 Análise comparativa entre métodos (iniciação; planejamento; execução;
monitoramento e controle; e encerramento) que
Diversos fatores influenciam na escolha abrangem diversas áreas de conhecimento
da metodologia a ser utilizada no (integração; escopo; tempo; custos; qualidade;
desenvolvimento de projetos, portanto não recursos humanos; comunicações; riscos;
existe uma regra que defina qual é a melhor. aquisições; e partes interessadas)
Tanto os métodos tradicionais quanto os “ Uma área de conhecimento representa um
métodos ágeis possuem benefícios e a sua conjunto completo de conceitos, termos e
aplicabilidade varia de acordo com cada projeto atividades que compõem um campo
e empresa, levando em consideração a natureza profissional, campo de gerenciamento de
e cultura organizacional, respectivamente. projetos ou uma área de especialização. Essas
O ideal é conhecer cada um deles e dez áreas de conhecimento são usadas na maior
entender as suas principais diferenças. A partir parte dos projetos, na maioria das vezes. As
daí deve-se analisar o projeto para ver qual equipes dos projetos utilizam essas e outras
metodologia melhor se enquadra. áreas de conhecimento, de modo apropriado,

10
para os seus projetos específicos. ” (PMBOK, “ Em outras palavras, pode-se dizer que,
2013, p. 60). ao rodar o Scrum, é possível sentir exatamente
onde os processos do Guia PMBOK podem ser
Figura 10. Áreas de Conhecimento. encaixados na sua rotina. “ (CRUZ, 2013, p. 45)

4 Conclusão

Diante do levantamento teórico e


bibliográfico realizado neste artigo, foi
discutido o uso de metodologias ágeis para
gerenciamento de projetos de software, não
deixando de citar as metodologias tradicionais,
para que fossem comparadas.
O mercado de software é amplo, pois os
sistemas de informações estão sendo
automatizados, ou seja, os softwares estão, cada
vez mais, realizando tarefas humanas de
maneira eficiente.
O objetivo deste trabalho era mostrar os
Fonte: Mhavila – (2015) benefícios que as metodologias ágeis oferecem
à gestão de projetos de software, apresentar o
“ O Guia PMBOK sugere tudo que pode framework ágil Scrum, bem como detalhar o
ser realizado para gerenciar um projeto do seu funcionamento e realizar uma análise
início ao fim, mas não diz como isso pode ser comparativa entre os métodos,
feito - e em algumas vezes não é muito claro na Para atende-lo, foram apresentados,
definição dos momentos ideais para cada inicialmente, os conceitos básicos de software e
aplicação. “ (CRUZ, 2013, p. 43) engenharia de software, metodologias
Diante deste conceito, Fabio Cruz, em seu tradicionais, a história do manifesto ágil para
livro “SCRUM e PMBOK unidos no que ficassem explícitos os objetivos e a origem
gerenciamento de projetos”, diz que é das metodologias e frameworks ágeis.
perceptível que o Guia contém inúmeros No cenário contemporâneo de tecnologia
processos, com uma imensidão de detalhes da informação os clientes exigem que os
praticamente completos quanto ao conteúdo trabalhos solicitados sejam realizados com
gerencial, porém não define uma metodologia qualidade e em prazos cada vez mais curtos, e
exata para a aplicabilidade das boas práticas. as empresas que se encarregarão do
Surge, então, a possibilidade de associar desenvolvimento do projeto devem estar
as boas práticas do PMBOK ao framework ágil preparadas para atender a esses requisitos, para
Scrum. a garantia de contratos futuros e,
O Scrum, diferentemente do Guia consequentemente, lucratividade. Portanto é
PMBOK, não é abrangente e extenso, mas fundamental adotar modelos de gerenciamento
contém um conjunto de regras sequenciais bem compatíveis com este contexto, que garantam a
definidas para aplicar em gerenciamento de satisfação dos clientes.
projetos. A garantia da qualidade de software é
O modelo menos complexo e mais uma atividade que deve ser bem planejada e,
compacto que o PMBOK permite utilizar o nos métodos tradicionais (divididos em fases),
Scrum como uma perspectiva que traz deve cobrir todas as fases, desde análise até
visibilidade ao projeto, o que torna mais fácil implantação do produto, por isso é muito difícil
fazer o uso das boas práticas e entender como e de ser obter essa garantia, visto que a falha em
quando utilizar os processos. uma etapa pode prejudicar as demais.

11
Com o uso do Scrum, onde há a indivíduos e interações entre eles e, ainda, pode
valorização de indivíduos e interações entre ser associado ao PMBOK, visto que o guia não
eles mais que processos e ferramentas, software cita como fazer e sim as boas práticas que
em funcionamento mais que documentação podemos aplicar na gestão de projetos.
abrangente, colaboração com o cliente mais que A respeito da escolha da metodologia
negociação de contratos e responder às ideal, o que deve ficar claro é que, nesse
mudanças mais que seguir um plano, o controle contexto de desenvolvimento de software, é
da qualidade se torna mais eficaz, pois a perfeitamente cabível o uso do Scrum, porém o
iteratividade do framework previne a uso dos métodos tradicionais não é descartado.
ocorrência de riscos, detectando-os no começo A escolha da metodologia varia de acordo com
e evitando que se proliferem para as demais a natureza do projeto e cultura organizacional
etapas do processo e impactem negativamente. da empresa, portanto os métodos devem ser
O detalhamento do framework ágil analisados para ver qual melhor se enquadra
Scrum, com os principais conceitos, papéis, para atender às necessidades do cliente.
eventos e artefatos, tornou possível entender, na É sugerido como pesquisas futuras a
teoria, sobre a sua aplicabilidade, e com aplicação do uso do SCRUM em outras áreas,
posterior exemplo de um projeto de além da Tecnologia da Informação no
desenvolvimento de um software simples, foi desenvolvimento de softwares, visto que a sua
notório o benefício de seu uso em relação aos aplicabilidade é indicada para projetos
métodos tradicionais, pois o envolvimento dos imprevisíveis.
participantes, a transparência, a inspeção
contínua e a flexibilidade agregam valor ao
projeto. 5 Referências
Em virtude das exigências do mercado de
software, onde as condições mudam com ARTIGO acadêmico: Desenvolvimento de
frequência, a aplicação do Scrum é indicada, Software: Processos Ágeis ou Tradicionais?
visto que a metodologia ágil foca na satisfação Uma visão crítica. Disponível em:
do cliente, em entregas parciais (onde o <http://www.enacomp.com.br/2010/cd/artigos/
software pode ser utilizado mesmo completos/enacomp2010_4.pdf>. Acesso em:
incompleto), são adaptativas às mudanças, as 03 nov. 2016.
equipes são auto-organizadas e há mais
comunicação entre os envolvidos.
O artigo apresentou o framework, seus ARTIGO acadêmico: Metodologias Ágeis para
benefícios, simples análise comparativa entre o Desenvolvimento de Softwares: Aplicação e
os métodos, destacando as principais o Uso da Metodologia Scrum em Contraste ao
características de cada um, e a possível Modelo Tradicional de Gerenciamento de
associação dos métodos ágeis às práticas do Projetos. Disponível em:
PMBOK. <http://revistas.ung.br/index.php/computacaoa
Com base nos questionamentos plicada/article/viewFile/1408/1194>. Acesso
apresentados na introdução, é possível concluir em: 03 nov. 2016.
que o uso de métodos ágeis é indicado para o
gerenciamento de projetos imprevisíveis e
complexos, como os de software, e o BALIN, I. Agile Software Development.
framework Scrum apresenta vantagens se Disponível em:
comparado a métodos tracionais, neste cenário, <https://www.dbbest.com/blog/agile-software-
em decorrência da flexibilidade em relação às development/>. Acesso em 06 nov. 2016.
mudanças, que adequa o produto às
necessidades do cliente, e das entregas
contínuas, que agregam valor, entre outras BALTZAN, P. Tecnologia Orientada para
vantagens, uma vez que deixa de focar nos Gestão, 6ed. McGraw Hill Brasil, 2016.
processos e ferramentas e direciona o foco aos
12
CRUZ, F. SCRUM e PMBOK unidos no SCHWABER K.; SUTHERLAND J. Guia do
Gerenciamento de Projetos. Brasport, 2013. Scrum. Um guia definitivo para o Scrum: As
regras do jogo, 2013. Disponível em:
<http://www.scrumguides.org/docs/scrumguid
D’ÁVILA, M. PMBOK e Gerenciamento de e/v1/Scrum-Guide-Portuguese-BR.pdf>.
Projetos. Disponível em: Acesso em 20 nov. 2016.
<http://www.mhavila.com.br/topicos/gestao/p
mbok.html>. Acesso em 05 nov. 2016.
VIEIRA, D. Scrum: A Metodologia Ágil
Explicada de forma Definitiva. Mindmaster
Desenvolvimento Ágil. Disponível Educação Profissional. Disponível em:
em:<http://www.desenvolvimentoagil.com.br/ <http://www.mindmaster.com.br/scrum/>.
scrum/>. Acesso em 29 out. 2016. Acesso em 05 nov. 2016.

GREY, S. Practical Risk Assessment for


Project Management, Nova York: John Wiley
and Sons, 1998.

Manifesto Ágil. Disponível em:


<http://agilemanifesto.org/>. Acesso em: 20
out. 2016.

PMBOK – 5ª ED. Project Management


Institute. 2013.

PRESSMAN, R. S. Engenharia de software.


Uma abordagem profissional, 7ª ed. AMGH
Editora Ltda., 2011.

RIEPER, M. Quadro SCRUM – Quadro de


tarefas KANBAN Excel. Disponível em:
<http://guiadoexcel.com.br/quadro-scrum-
quadro-de-tarefas-kanban-excel/>. Acesso em
06 nov. 2016.

RUBIN, K., S. Essential Scrum. A Practical


Guide to the Most Popular Agile Process.
Addison-Wesley, 2012

SBROCCO, J., H., T., C.; MACEDO, P., C.


Metodologias Ágeis. Engenharia de Software
sob Medida, 1ª ed., Érica, 2012.

13