UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO

FACULDADE DE TECNOLOGIA
CAMPUS REGIONAL DE RESENDE
PS-GRADUAO EM ENGENHARIA DE PRODUO COM
NFASE EM GESTO DE PROJETOS
SCRUM e XP: Aderene! " D#$er%ene! &" PM'O()
Ander!"n M"*!+! de Ar&,-" (andersonmoyses@gmail.com)
D#e%" d& S#.$& M&r/&" (dmarcato@gmail.com)
Or#en&d"r: C&r."! A.0er" P"ne! Fr&n/1#
C"-Or#en&d"r: R"!en/.e$er L"2e! G&3"n#
RESUMO
O processo de gerenciamento de projetos de software algo complexo devido ao seu alto
nvel de abstrao. !s caractersticas dos projetos de software podem variar dependendo da
caracterstica do software ou do pr"prio cliente re#uerente. $iante dessa necessidade% metodologias
de gerenciamento de projetos so utili&adas. O '()O* dentre todos o mais comum no mercado%
por ser o mais abrangente em meio + diversidade de projetos desse ramo. Outras metodologias
como o ,' e o -./0( tem por objetivo redu&ir o nvel de complexidade e diminuio do tempo
gasto na implementao deste tipo de projeto. O presente artigo apresenta os pontos #ue estas tr1s
metodologias possuem 2reas de con3ecimento afim de maneira a se reali&ar um estudo de cada uma
delas para o problema de gerenciamento de projetos de software. .om este estudo espera4se c3egar
+ uma efetiva comparao entre elas para facilitar a integrao delas. 5nicialmente apresentada
uma breve introduo da 3ist"ria do gerenciamento de projetos e contextuali&ao de cada
metodologia. 6ogo ap"s feito o detal3amento dos principais conceitos de cada metodologia
atravs da refer1ncia bibliogr2fica. ! seguir% explicado o processo de projeto de software para
contextuali&ao. 72 no desenvolvimento% as 2reas de con3ecimento do '()O* #ue so afins com
o -./0( e ,' so descritas e comparadas. !o trmino do artigo uma an2lise geral entre as tr1s
metodologias feita afim de se responder a pergunta inicial do artigo8 -./0( e ,'8 aderentes ou
divergente do '()O*9
P&.&$r&!-C1&$e: .omunicao: ;#uipe: ;scopo: <erenciamento de 'rojetos: '()O*% /ecursos
=umanos: -./0(: >empo: ,'.
A'STRACT
>3e process of managing software projects is complex due to its 3ig3 level of abstraction. >3e
c3aracteristic of software projects may vary depending on t3e c3aracteristic of t3e software or t3e
re#uesting client. ?aced wit3 t3is need project management met3odologies are used. >3e '()O*
among all is t3e most common on t3e mar@et% for being t3e most compre3ensive amid diversity of
industry projects. Ot3er met3odologies suc3 as ,' and -./0( aims to reduce t3e level of
complexity and decrease time spent on t3e implementation of t3is project type. >3is article presents
t3e points t3at t3ese t3ree met3odologies 3ave areas of expertise related way to conduct a study of
eac3 to t3e problem of managing projects of software.com t3is study is expected to reac3 an
effective comparison between t3em to facilitate t3e integration of t3em. 5s initially presented a brief
introduction to t3e 3istory of project management and contextuali&ation of eac3 met3odology. -oon
after it are done drill core concepts of eac3 met3odology by bibliograp3ic reference. >3e following
is explained t3e process of designing software for contextuali&ation. !lready in development% t3e
'()O* @nowledge areas t3at are related wit3 -crum and ,' are described and compared. !t t3e
end of t3e article a general analysis between t3e t3ree met3odologies is made in order to answer t3e
original #uestion of t3e article8 -crum and ,'8 acceding or divergent '()O*9
(e*4"rd!: .ommunication: =uman /esources: '()O*: 'roject (anagement: >eam% -cope:
-./0(: >ime: ,'.
56 Inr"d789"
O processo gradativo de evoluo da 3umanidade se deu atravs de v2rios projetos. Ao incio
desse processo% os feitos #ue 3oje podemos conceituar de projetos% foram reali&ados de maneira
totalmente emprica. Ao sculo ,5,% com os ensaios de !uguste .omte sobre o mtodo cientfico e
o seu positivismo mudaram o rumo da nossa sociedade% onde agora o empirismo passou a ser
substitudo pela observao dos fatos e de pr2ticas j2 utili&adas. .om o passar do tempo os feitos
agora j2 no sculo ,, sendo c3amados de projetos% foram se tornando cada ve& mais complexos.
;xistem as mais variadas metodologias de projetos para os mais diversos segmentos da
sociedade. ;ste trabal3o ir2 apresentar tr1s Bmetodologias de gerenciamento de projetosC ('()O*%
-./0( e ,')% sendo duas Dltimas con3ecidas como metodologias 2geis% #ue pre&am por fatores
como indivduos e as suas interaEes% constante aproximao e feedback dos clientes alm de
F
resposta imediata a mudanas. $entre as metodologias 2geis uma voltada especificamente para o
setor de >5 (>ecnologia da 5nformao)% no segmento de desenvolvimento de software% e a outra
pode ser aplicada em outros segmentos. !p"s apresent24las% este estudo confronta seus pontos fortes
e pr2ticas utili&adas por cada uma delas alm de extrair o #ue 32 de mel3or% a fim #ue atendam as
necessidades de gestores #ue buscam gerenciar projetos de forma efetiva com o mnimo de pra&o
possvel% utili&ando de princpios apresentados inicialmente pelos autores do Agile Manifesto
(FGGH)% #ue pre&am por8
5ndivduos e interaEes mais #ue processos e ferramentas:
-oftware em funcionamento mais #ue documentao abrangente:
.olaborao com o cliente mais #ue negociao de contratos:
/esponder a mudanas mais #ue seguir um plano. (Agile Manifesto% FGGH).
$evido + alta complexidade #ue exigida no gerenciamento de projetos% uma grande dose de
experi1ncia e assertividade% so fundamentais para aos gerentes de projetos. 'ara tal temos uma
enorme gama de metodologias a serem aplicadas em projetos. .om isso gerentes de projeto tendem
a ter dificuldades em definir #ual a mel3or metodologia a ser aplicada em seu projeto. !lguns
gerentes optam pela metodologia #ue ele possui mais experi1ncia% outros optam pela metodologia
de acordo com o perfil do projeto e das premissas reportadas no contrato% alegando #ue muitas
metodologias no podem ser aplicadas simultaneamente.
$iante da dificuldade apresentada anteriormente% o presente artigo se propEe a observar as
pr2ticas do '()O*% -./0( e ,'% e apontar #uais so as mel3ores ferramentas e mtodos de cada
uma das BmetodologiasC% a fim de refinar o processo de gerenciamento de projetos eliminando
possveis erros decorrentes da falta de experi1ncia
O estudo foca em projetos de >ecnologia de 5nformao% mais precisamente% projetos de
desenvolvimento de software. !lm do uso de casos de sucesso% sero adotados artigos cientficos
de relevIncia sobre o assunto.
:6 Re$#!9" d& L#er&7r&
:656 G7#& d" C"n1e/#;en" e; Geren/#&;en" de Pr"-e"! <PM'O(=
O <uia do .on3ecimento em <erenciamento de 'rojetos (<uia '()O*) uma norma
recon3ecida para a profisso de gerenciamento de projetos. 0m padro% um documento formal #ue
descreve normas% processos e pr2ticas estabelecidas. !ssim como em outras profissEes como
advocacia% medicina e contabilidade% o con3ecimento contido nesse padro evoluiu a partir das boas
J
pr2ticas recon3ecidas de profissionais de gerenciamento de projetos #ue contriburam para o seu
desenvolvimento. ('(5% FGGK)
-egundo o '(5% o objetivo do '()O* 8
O principal objetivo do <uia '()O* identificar o subconjunto do conjunto de
con3ecimentos em gerenciamento de projetos #ue amplamente recon3ecido como boa
pr2tica. B5dentificarC significa fornecer uma viso geral% e no uma descrio completa.
B!mplamente recon3ecidoC significa #ue o con3ecimento e as pr2ticas descritas so
aplic2veis + maioria dos projetos na maior parte do tempo% e #ue existe um consenso geral
em relao ao seu valor e sua utilidade. B)oa pr2ticaC significa #ue existe acordo geral de
#ue a aplicao correta dessas 3abilidades% ferramentas e tcnicas podem aumentar as
c3ances de sucesso em uma ampla srie de projetos diferentes. 0ma boa pr2tica no
significa #ue o con3ecimento descrito dever2 ser sempre aplicado uniformemente em
todos os projetos: a e#uipe de gerenciamento de projetos respons2vel por determinar o
#ue ade#uado para um projeto especfico ('(5% FGGK% p. L).
O conceito de projeto do '()O* est2 ligado diretamente ao esforo despendido de car2ter
tempor2rio% 3avendo assim um incio e fim. $urante o perodo de vida do projeto este conjunto de
boas pr2ticas busca controlar o bom andamento do projeto atravs de nove compet1ncias
(5ntegrao% ;scopo% >empo% .ustos% Mualidade% /ecursos =umanos% .omunicaEes% /iscos e
!#uisiEes) de maneira #ue na falta de uma delas pelo menos outra compet1ncia seja afetada.
:6:6 SCRUM
O -./0( no uma tcnica% ou processo para o desenvolvimento de um produto% e sim uma
espcie de ambiente% onde tcnicas e processos podem ser empregados% transparecendo efici1ncia e
efic2cia% na mel3oria do desenvolvimento de determinado produto. -egundo Aeto (FGGK)% sua
origem ocorreu na segunda metade da dcada de KG% em um artigo escrito por >a@euc3i e Aona@a%
#ue apresenta as de& mel3ores e mais inovadoras pr2ticas em empresas japonesas% denominado
BThe New New Product Development Game, Harvard usiness !eviewC (A;>O% FGGK).
.om nome originado em uma jogada do rDgbi% #ue os jogadores planejam a jogada seguinte%
assim como na conduo de um projeto% onde utili&a de pe#uenos ciclos% mas com um foco% #ue
gan3ar o jogo.
.onforme -oares (FGGL) esclarece a respeito do -./0(8
N um processo 2gil #ue permite manter o foco na entrega do maior valor de neg"cio% no
menor tempo possvel. !s necessidades do neg"cio #ue determinam as prioridades do
O
desenvolvimento de um sistema. !s e#uipes se auto4organi&am para definir a mel3or
maneira de entregar as funcionalidades de maior prioridade. (-O!/;-% FGGL% p.FK)
.3apiews@i (FGGL) di& #ue as pr2ticas do -./0( podem ser aplicadas em #ual#uer contexto
onde pessoas precisem trabal3ar juntas para atingir um objetivo comum. -./0( recomendado
para projetos de outras 2reas alm de software principalmente para projetos de pes#uisa e inovao.
! filosofia -./0(% como c3amada por alguns seguidores% sustenta sob tr1s importantes
pilares% #ue pre&am8 a transpar1ncia% a inspeo e a adaptao. ;stes sempre devem permanecer em
3armonia% cada um com sua designao para #ue 3aja a garantia de uma efica& utili&ao
(-.=P!);/% FGGL).
Outras importantes vertentes so as ;#uipesQ>imes (flexveis% produtivos% auto4organi&2veis%
interdisciplinares e iterativos)% Time"o#es (;ventos com durao fixa)% !rtefatos (itens de controle
necess2rios para o desenvolvimento) e as /egras (elo entre os eventos com durao fixa (Time"
o#es)% a e#uipe e os artefatos) (-.=P!);/% FGGL).
$entre os papis da ;#uipe -./0(% 32 dois #ue se diferem das tradicionais formas de
<erenciamento de 'rojeto% so eles8
O -crum(aster respons2vel por garantir #ue o >ime -./0( esteja aderindo aos valores
do -./0(% +s pr2ticas e +s regras. O -crum(aster ajuda o >ime -./0( e a organi&ao
a adotarem o -./0(. O -crum(aster educa o >ime -./0( treinando4o e levando4o a
ser mais produtivo e a desenvolver produtos de maior #ualidade. O -crum(aster ajuda o
>ime -./0( a entender e usar autogerenciamento e interdisciplinaridade. Ao entanto% o
-crum(aster no gerencia o >ime -./0(: o >ime -./0( auto4organi&2vel.
(-.=P!);/% *.% FGGL% p. R)
O outro papel o de Product $wner% representa os interesses de todos os envolvidos% define e
priori&a as funcionalidades do produto #ue ser2 desenvolvido. >oda essa estrutura do -./0( est2
sob importantes itens #ue no poderiam deixar de serem abordados. $e acordo com -oares (FGGL)%
os mesmos so Product acklog (uma lista de funcionalidades desejadas para o produto)% %print
(#ue se julga possvel desenvolver num cicloQiterao) e urndown &hart (<r2fico de .onsumo%
#ue utili&ado para acompan3ar o progresso e a velocidade da e#uipe de desenvolvimento).
:6>6Extreme Programming <XP=
! '#treme Programming (,') uma metodologia 2gil para e#uipes de pe#ueno e mdio porte
onde os re#uisitos de um software so vagos ou esto em constante mudana. ! sua premissa maior
S
o contato com o cliente atravs de reuniEes di2rias% afim de #ue 3aja um constante ajuste da
necessidade real do cliente. O cliente descreve as funcionalidades predi&endo o #ue ser2 feito para
os desenvolvedores. ! idia #ue de posse desses formul2rios a e#uipe de desenvolvedores possa
entregar um produto #ue o cliente efetivamente ten3a condiEes de usar ();.*% FGGO).
;sta metodologia de desenvolvimento de software% nascida nos ;stados 0nidos ao final da
dcada de LG. >em por objetivo ajudar a criar sistemas de mel3or #ualidade% #ue so produ&idos em
menos tempo e de forma mais econTmica #ue o 3abitual. >ais objetivos so alcanados atravs de
um pe#ueno conjunto de valores% princpios e pr2ticas% #ue diferem substancialmente da forma
tradicional de se desenvolver um software (>;6;-% FGGS).
>6 Me"d"."%#&
O processo de construo deste trabal3o ser2 baseado nas 2reas de con3ecimento do '()O*
onde 3aja pontos com visEes e forma de atuao divergente entre as tr1s metodologias citadas.
$iverg1ncias essas #ue sero apresentadas dentro das 2reas de con3ecimento do '()O*% #ue
sofrem os maiores impactos em projetos de software (;scopo% >empo% /ecursos =umanos e
.omunicaEes).
=aver2 uma seco para #ue os projetos de softwares sejam apresentados% mostrando suas
principais caractersticas e diferenas em relao aos demais tipos de projetos com os da construo
civil e projeto das da 2rea de defesa% dos #uais originaram o '()O*.
'ara a obteno das informaEes necess2rias para a construo deste trabal3o% sero utili&ados
os mais diversos tipos de literatura% como livros% trabal3os acad1micos% peri"dicos especiali&ados e
at sites #ue apresentem informaEes contextuali&adas e confi2veis. !travs de todo esse estudo
poder2 ser feito um correto cru&amento das caractersticas do '()O*% -./0( e ,'.
?6 Pr"-e"! de S"@4&re!
O projeto de um software tem muitas caractersticas em comum com projetos de engen3aria%
do ponto de vista do mapeamento dos re#uisitos funcionais em soluEes tecnol"gicas ('5(;A>;6%
FGGU). !pesar de se tratar de um servio prestado% o dito produto de um projeto de software possui
caractersticas e processos especficos. -egundo ?albo (FGGL)8
Ao #ue se refere ao produto% a primeira coisa a se fa&er definir o escopo do projeto. 'ara
tal% necess2rio fa&er um levantamento de re#uisitos inicial. ! idia decompor o
problema% em uma abordagem Bdividir para con#uistarC. 5nicialmente% o sistema deve ser
decomposto em subsistemas #ue so% por sua ve&% decompostos em m"dulos. Os m"dulos
R
podem% ainda% ser recursivamente decompostos em sub4m"dulos ou funEes% at #ue se
ten3a uma viso geral das funcionalidades a serem tratadas no projeto.
(?!6)O% FGGL% p. HH)
-egundo -ommerville (FGGU)% o gerenciamento eficiente de software depende de um
planejamento minucioso do progresso do projeto. Os gerentes devem prever os problemas #ue
podem ocorrer e preparar soluEes experimentais para esses problemas. 0m plano elaborado no
incio de um projeto deve ser usado como guia. ;sse plano inicial deve ser o mel3or possvel em
relao +s informaEes disponveis. ;le deve evoluir + medida #ue o projeto progride e mel3ores
informaEes se tornem disponveis.
;m projeto de software o escopo normalmente trabal3ado de forma fec3ada% onde so feitas
reuniEes iniciais com cliente% a fim de se definir com ele o tempo necess2rio a ser utili&ado no
planejamento e execuo do projeto. ;ste processo tra& para a e#uipe de projeto todo o risco
decorrente das mudanas de escopo% aumentando as c3ances de mudanas de escopo% e em casos
mais extremos% paralisao do projeto. N de suma importIncia a participao do cliente. 'ara >eles
(FGGS)% ao colocar as pessoas com as necessidades de neg"cio em contato direto com os
desenvolvedores facilita a compreenso dos re#uisitos% alm de acelerar o feedback. O usu2rio #ue
participa da e#uipe pode dar um feedback mais r2pido e ajudar a definir prioridades.
Outro grande desafio no projeto de software alocao de recursos 3umanos no projeto. Voc1
pode precisar montar sua e#uipe usando engen3eiros relativamente inexperientes. 5sso pode tra&er
problemas% pois os membros da e#uipe no compreendem o domnio da aplicao ou tecnologia.
;ntretanto% em um projeto de longo pra&o% a compreenso de conceitos e de domnio da aplicao
mais importante #ue o con3ecimento especfico% particularmente de linguagens de programao e
mtodos. (-O((;/V566;% FGGU).
'imentel (FGGL) cita #ue estimar e calcular a complexidade de um sistema de software um
parImetro importante para o desenvolvimento com #ualidade. N importante ter4se uma estimativa
do taman3o do sistema para se conseguir estimar o esforo necess2rio na sua construo. 'ara tal
so usadas mtricas especficas para a medio de esforo de desenvolvimento de software. ;stas
mtricas avaliam o taman3o e a complexidade do produtoQsoftware desenvolvido% tendo como
objetivo servir de base para estimativas de esforo para futuros desenvolvimentos e para avaliar a
produtividade das e#uipes. !s mtricas de software so #uantitativas e% por este motivo% no tem
como di&er se um conjunto de classes e objetos o mais ade#uado para satisfa&er um determinado
conjunto de re#uisitos funcionais% mas apenas di&er se um conjunto de classes mais complexo #ue
outro.
A6 Bre&! D#$er%ene!
U
A656Geren/#&;en" de E!/"2"
O <erenciamento do ;scopo do projeto definido com muita propriedade por -otille (FGHG)8
O <erenciamento do escopo do projeto o processo #ue garante #ue o projeto inclui todo
o trabal3o re#uerido% e somente o trabal3o re#uerido% para complet24lo com sucesso. O
gerenciamento do escopo a base para o planejamento do projeto e para a criao de sua
lin3a base% e deve ser condu&ido de forma precisa% uma ve& #ue forma a base do trabal3o a
ser desenvolvido no projeto. (-O>566; et. al% FGHG% p. HL).
!ssim como todas as 2reas de con3ecimentos do '()O* trabal3am baseadas em processos%
#ue muitas ve&es so rgidos% e de difcil aceitao +s mudanas% com o escopo% no seria diferente%
este processos so8
C".e&r "! reC7#!#"! D O processo de definio e documentao das necessidades
das partes interessadas para alcanar os objetivos do projeto.
De@#n#r " e!/"2" D O processo de desenvolvimento de uma descrio detal3ada do
projeto e do produto.
Cr#&r " EAP
5
D O processo de subdiviso das entregas e do trabal3o do projeto em
componentes menores e mais facilmente gerenci2veis.
Ver#@#/&r " e!/"2" D O processo de formali&ao da aceitao das entregas
terminadas do projeto.
C"nr".&r " e!/"2" D O processo de monitoramento do progresso do escopo do
projeto e escopo do produto e gerenciamento das mudanas feitas na lin3a de base do
escopo.
('(5% FGGK% p. LF).
$entro do -./0(% o Product acklog (acklog do 'roduto)% assume o papel do escopo%
como explanado por -c3waber (FGGL)8
O acklog do 'roduto representa tudo #ue necess2rio para desenvolver e lanar um
produto de sucesso. N uma lista de todas as caractersticas% funEes% tecnologias% mel3orias
e correEes de defeitos #ue constituem as mudanas #ue sero efetuadas no produto para
versEes futuras. Os itens do acklog do 'roduto possuem os atributos de descrio%
1
;strutura !naltica de 'rojetos% do ingl1s% (ork reakdown %tructure (P)-) uma ferramenta de decomposio do
trabal3o do projeto em partes manej2veis.
K
prioridade e estimativa. ! prioridade determinada por risco% valor e necessidade. =2
diversas tcnicas para dar valor a esses atributos. (...)
Os re#uisitos nunca param de mudar. O acklog do 'roduto um documento vivo.
(udanas nos re#uisitos de neg"cios% condiEes do mercado% tecnologia e e#uipe causam
mudanas no acklog do 'roduto. 'ara minimi&ar o retrabal3o% apenas os itens de maior
prioridade precisam ser mais detal3ados. (-.=P!);/% *.% FGGL% p. HU).
Ao ,'% o processo de gerenciamento do escopo% passa diretamente pela 2rea de comunicao%
pois conforme !raDjo WHX (FGGL)% o planejamento funciona de forma iterativa% ou seja% atravs de
ciclosQloopings% o #ue garante e exige uma maior proximidade dos usu2rios (solicitantes)% forando
para #ue 3aja uma validao e priori&ao a cada entrega. >oda essa proximidade com os usu2rios
vem antes mesmo do desenvolvimento% inicia4se no planejamento do projeto% pois so os
solicitantes #uem escreve as Best"rias de usu2riosC% #ue descreve todos os cen2rios com situaEes
de utili&ao% na #ual o projeto dever2 reali&ar ap"s sua concluso.
A6:6Geren/#&;en" d" Te;2"
O bom desenvolvimento do projeto est2 relacionado com um planejamento de tempo coerente
com a e#pertise dos recursos e a complexidade do projeto. -egundo o '()O* (FGGK)% o
gerenciamento de tempo do projeto inclui os processos necess2rios para gerenciar o trmino pontual
do projeto. -o eles8
De@#n#r &! &#$#d&de! D O processo de identificao das aEes especficas a serem
reali&adas para produ&ir as entregas de projeto.
SeC7en/#&r &! &#$#d&de! D O processo de identificao e documentao dos
relacionamentos entre as atividades do projeto.
E!#;&r "! re/7r!"! d& &#$#d&de D O processo de estimativa dos tipos e #uantidades
de material% pessoas% e#uipamentos ou suprimentos #ue sero necess2rios para reali&ar
cada atividade.
E!#;&r &! d7r&8Ee! d& &#$#d&de D O processo de estimativa do nDmero de perodos
de trabal3o #ue sero necess2rios para terminar as atividades especficas com os
recursos estimados.
De!en$".$er " /r"n"%r&;& D O processo de an2lise das se#u1ncias das atividades% suas
duraEes% recursos necess2rios e restriEes do cronograma visando criar o cronograma
do projeto.
L
C"nr".&r " /r"n"%r&;& D O processo de monitoramento do andamento do projeto
para atuali&ao do seu progresso e gerenciamento de mudanas feitas na lin3a de base
do cronograma.
('(5% FGGK% p. HKH).
;sses processos interagem entre si e com os de outras 2reas de con3ecimento. 'odem envolver
esforos de um grupo ou de uma pessoa% com base nas necessidades de projeto. .ada processo
ocorre pelo menos uma ve& em todo projeto e em uma ou mais fases do mesmo% se dividido em
fases ('(5% FGGK% p. HHF).
O processo de definio de datas e pra&os no ,' normalmente definido semanalmente
atravs do Planning Game. Aestes encontros a e#uipe de desenvolvimento se reDne com o cliente
onde so priori&adas as funcionalidades a serem desenvolvidas alm de neste momento estim24las.
-egundo 6eonel et. al. (FGGU)% a cada comeo de semana o escopo do projeto reavaliado% girando
em torno de um contrato de escopo negoci2vel% #ue diferente das formas normais de contratao
de desenvolvimento de software. !o final de cada semana% os desenvolvedores entregam resultado
desenvolvido durante a semana% podendo assim o cliente j2 colocar as funcionalidades
desenvolvidas em ao.
$e acordo com $ecarlo (FGGO)% para a reali&ao da estimativa do esforo re#uerido a cada
interao% devem ser levadas tr1s consideraEes8
5ncerte&as #ue possam vir a ocorrer no projeto e #ue devem ser revisadas
pela e#uipe atravs o ar#uivamento de incerte&as para acompan3amento
dos riscos:
6evantar o nvel de #ualidade re#uerido para condiEes vencedoras. -em
essa diretri& o projeto pode vir a ser um fracasso. ;steja certo de #ue as
mtricas definidas por voc1 ten3am sido aceitas pela e#uipe.
$efinir para cada entrega o esforo mel3or% pior e o ra&o2vel levando em
considerao para cada recurso R 3orasQdia% j2 #ue apesar do dia ter K
3oras Dteis% parte de este tempo ser gasto em outras atividades
!raDjo WFX (FGGL) cita #ue no -./0( a e#uipe de projeto junto com o cliente deve colaborar
para definir o cronograma% a sua se#u1ncia e a forma de controle ade#uada% en#uanto no '()O* a
confeco do cronograma uma responsabilidade inerente ao gerente de projetos. !s abordagens do
-./0( e do '()O* no tocante + confeco do cronograma so semel3antes nas definiEes de
atividades e processos de estimativas.
HG
'ara o -./0(% estimativa de esforo combinada com velocidade igual ao oramento e
cronograma de um projeto% sendo ele desenvolvido de forma iterativa atravs do sprint e gerenciado
atravs do gr2fico de burndown (-;V;/5AO% FGGL).
A6>6Geren/#&;en" de Re/7r!"! H7;&n"!
Ao possvel falar de /ecursos =umanos sem fa&er algumas definiEes prvias% conceitos
#ue podem parecer simples% mas algumas ve&es acabam passando por despercebido ao longo dos
estudos% definiEes como as de grupo e e#uipe por exemplo. .onforme (ac1do (FGHG) explana% um
grupo uma reunio de pessoas com um ou mais objetivos comuns e #ue se percebem como seus
integrantes. 72 uma e#uipe so grupos #ue evoluram% ou seja% #uando este grupo em #uesto passa
a prestar ateno + sua pr"pria forma de operar e procura resolver problemas #ue impactam suas
atividades% aplicando assim 3abilidades e experi1ncias.
-egundo o '(5 (FGGK)% o gerenciamento dos recursos 3umanos do projeto composto por
processos (#ue organi&am e gerenciam a e#uipe de projeto)% e#uipes (#ue so as pessoas com papis
e responsabilidades designadas). !inda no '()O*% pode4se observar os processos8
De!en$".$er " 2.&n" de re/7r!"! 17;&n"! D O processo de identificao e
documentao de funEes% responsabilidades% 3abilidades necess2rias e relaEes
3ier2r#uicas do projeto% alm da criao de um plano de gerenciamento pessoal.
M"0#.#3&r & eC7#2e d" 2r"-e" D O processo de mel3oria de confirmao da
disponibilidade dos recursos 3umanos e obteno da e#uipe necess2ria para concluir as
designaEes do projeto.
De!en$".$er & eC7#2e de 2r"-e" D O processo de mel3oria de compet1ncias% interao
da e#uipe e ambiente global da e#uipe para aprimorar o desempen3o do projeto.
Geren/#&r & eC7#2e d" 2r"-e" D O processo de acompan3ar o desempen3o de
membros da e#uipe% fornecer feedback% resolver #uestEes e gerenciar mudanas para
otimi&a o desempen3o.
('(5% FGGK% p. HKH).
'ara as e#uipes de projeto% deve4se definir os papis% autoridade% responsabilidades e
compet1ncias #ue so necess2rias para a concluso de um projeto8
HH
P&2e. D ! designao #ue descreve a parte de um projeto pela #ual uma pessoa
respons2vel e responde pelos resultados. (...) ! clare&a do papel em relao a autoridade%
responsabilidades e limites deve ser documentada.
A7"r#d&de D O direito de aplicar recursos do projeto% tomar decisEes e assinar
aprovaEes.
Re!2"n!&0#.#d&de D O trabal3o #ue se espera #ue um membro da e#uipe do projeto
execute para concluir as atividades do projeto.
C";2eFn/#& D ! 3abilidade e a capacidade necess2rias para concluir atividades do
projeto.
('(5% FGGK% p. HKU).
!s pr2ticas de ,' impactam diretamente no gerenciamento de recursos 3umanos de um
projeto e at mesmo de uma organi&ao como um todo% conforme >eles (FGGK) apresenta8
'rojetos ,' afetam as pr2ticas de recursos 3umanos de uma organi&ao% em particular no
#ue se refere a contrataEes e avaliaEes peri"dicas dos funcion2rios. O fato de os
programadores trabal3arem em pares% por exemplo% leva + necessidade de pessoas #ue no
apenas ten3am boas 3abilidades tcnicas% mas tambm saibam interagir socialmente com
naturalidade. 'ortanto% a contratao no pode se basear apenas em critrios tcnicos e as
avaliaEes individuais se tornam complexas por#ue difcil isolar o rendimento do
trabal3o individual #uando se trabal3a em par a maior parte do tempo. (...)
'apis em uma e#uipe ,' no so fixos e rgidos. O objetivo fa&er com #ue cada um
contribua com o mel3or #ue tem a oferecer para #ue a e#uipe ten3a sucesso. ;m princpio%
papis fixos podem ser Dteis para se aprender novos 32bitos% como por exemplo% fa&er com
#ue as decisEes tcnicas sejam deixadas para o pessoal tcnico e decisEes de neg"cio% com
pessoas de neg"cio. (>;6;-% FGGK).
.onforme 'ac3eco (FGHG)% Bo -./0( prov1% atravs de um mtodo simples 4 uma instIncia
do '$.! 4% uma forma de forar a conversao na e#uipe e a reflexo dos atos das pessoasC%
integrando assim duas 2reas% .omunicao e /ecursos =umanos% #ue na grande maioria dos
projetos so crticas. !lm disso% percebe4se sob a viso de -everino (FGGL)% #ue o gerenciamento
de /ecursos =umanos dentro do -./0(% pre&a #ue as e#uipes sejam multidisciplinares% ou seja%
necessita #ue todos ten3am a consci1ncia e a liberdade para fa&er um pouco de tudo.
HF
A6?6Geren/#&;en" d& C";7n#/&89"
.omunicao muito bem definida por ;isc3en (FGGF)8
.omo os soci"logos sabem% comunicao intrinsecamente difcil% mediadas por c"digos
#ue so sempre contextuais% normas% culturas e percepEes. (...)
! construo de re#uisitos b2sicos% por exemplo% envolve um processo de comunicao de
con3ecimento t2cito% o #ue explica grande parte da dificuldade no desenvolvimento de
software. >radu&ir con3ecimento de um contexto para outro% como tradu&ir #ual#uer
lngua% no envolve apenas gram2tica b2sica e regras sint2ticas% mas tambm #uestEes de
significado e inteno #ue so contextuais e subjetivas.
(;5-.=;A FGGF% apud >;6;-% FGGS% p.RG).
! partir da definio e do dimensionamento da comunicao num projeto% seja #ual for a 2rea
de desenvolvimento do mesmo% sabe4se #ue 32 diversas formas e canais para a execuo desta
tarefa #ue no das mais simples% mas conforme >eles (FGGS)% projetos ,' procuram envolver
ativamente seus usu2rios (representantesQclientes)% tornando4os parte integrante da e#uipe de
desenvolvimento% deixando presente muita das ve&es no mesmo ambiente onde o projeto est2 sendo
feito% possibilitando #ue o acesso aos especialistas seja mais r2pido% direto e consistente. $entro do
,' 32 diversas outras pr2ticas #ue otimi&am o processo de comunicao dentro do projeto% dentre
as principais pr2ticas esto a B'rogramao em 'arC e o )eedback. ! primeira conforme explanado
por Parden et al. (FGGJ apud 0/$!A<!/5A% /.% FGGK% p.JH)% o objetivo principal da
programao em par disseminar o con3ecimento% a experi1ncia e as idias. !travs de dois
desenvolvedores trabal3ando juntos em uma mesma atividade% em um mesmo computador%
simultaneamente. 72 a segunda pr2tica citada anteriormente o feedback% #ue conforme >eles
(FGGS)% o Bmecanismo fundamentalC% #ue permite #ue o cliente condu&a o desenvolvimento
diariamente e garanta #ue a e#uipe direcione as suas atenEes para a#uilo #ue ir2 gerar mais valor.
(as para #ue 3aja um bom feedback% o ideal #ue a uma boa comunicao interpessoal seja
reali&ada% assim como explica (ac1do et al.(FGHG)8
! comunicao interpessoal face a face considerada a mais completa de todas% visto #ue
propicia uma troca instantInea% feedback em caso de eventuais dDvidas e v2rias pistas #ue
vo muito alm das palavras8 gestos% expressEes faciais% tom de vo& etc.
((!.Y$O et al.% FGHG% p.KG)
HJ
.omo uma pr2tica do '()O*% o #uesito gerenciamento de comunicao% composto por
Bprocessos necess2rios para assegurar #ue as informaEes sejam geradas% coletadas distribudas%
arma&enadas% recuperadas e organi&adas de maneira oportuna e apropriada.C ('(5% FGGK).
O '()O* (FGGK) apresenta os seguintes processos para o gerenciamento da comunicao8
Iden#@#/&r &! 2&re! #nere!!&d&! D O processo de identificao de todas as pessoas ou
organi&aEes #ue podem ser afetadas pelo projeto e de documentao das informaEes
relevantes relacionadas aos seus interesses% envolvimento e impacto:
P.&ne-&r &! /";7n#/&8Ee! D O processo de determinao das necessidades de
informao das partes interessadas no projeto e definio de uma abordagem de
comunicao:
D#!r#07#r #n@"r;&8Ee! D O processo de colocar as informaEes necess2rias +
disposio das partes interessadas no projeto% conforme planejado:
Geren/#&r &! eG2e/&#$&! d&! 2&re! #nere!!&d&! D O processo de comunicao e
interao com as partes interessadas para atender +s suas necessidades e solucionar as
#uestEes + medida #ue ocorrem:
Re2"r&r " de!e;2en1" D O processo de coleta e distribuio de informaEes sobre o
desempen3o% incluindo relat"rios de andamento% mediEes do progresso e previsEes.
('(5% FGGK% p. FGO).
!inda no '()O* (FGGK)% cabe a observao% #ue todos esses processos explanados
anteriormente% interagem entre si% e com ou com processos de outras 2reas de con3ecimento.
Muando se trata de -./0(% fica praticamente impossvel no falar de comunicao% #ue
encontra as reuniEes como principal forma de contato entre os integrantes da e#uipe e os
interessados no projeto. ;xistem os mais variados tipos de reunio% mas segundo -c3waber (FGGL)
as principais so8 /eunio de planejamento da verso para entrega% /eunio de planejamento do
%print% /eviso do %print% /etrospectiva do %print e /eunio di2ria. Ordenando por ocorr1ncias
(necessidades)% primeiramente vem /eunio de planejamento da verso para entrega8
O prop"sito do planejamento da verso para entrega o de estabelecer um plano e metas
#ue o >ime -./0( e o resto da organi&ao possam entender e comunicar. O
planejamento da verso para entrega responde +s #uestEes8 B.omo podemos transformar a
viso em um produto vencedor da mel3or maneira possvel9 .omo podemos alcanar ou
exceder a satisfao do cliente e o /etorno sobre 5nvestimento (/O5) desejado9C
(-.=P!);/% *.% FGGL% p. L).
HO
;m seguida% vem a /eunio de planejamento do %print% #ue simplesmente define a iterao
(grupo de tarefas) em #uesto. !compan3ando as ocorr1ncias (necessidades)% vem /eviso do
%print% #ue verifica como foi o andamento de tudo #ue foi planejado na reunio de planejamento. 72
a /etrospectiva do %print8
! finalidade da /etrospectiva inspecionar como correu a Dltima %print em se tratando de
pessoas% das relaEes entre elas% dos processos e das ferramentas. ! inspeo deve
identificar e priori&ar os principais itens #ue correram bem e a#ueles #ue% se feitos de
modo diferente% poderiam ter deixado as coisas ainda mel3ores. 5sso inclui a composio
do time% preparativos para reuniEes% ferramentas% definio de BprontoC% mtodos de
comunicao e processos para transformar itens do acklog do 'roduto em alguma coisa
BprontaC. Ao final da /etrospectiva da %print% o >ime -./0( deve ter identificado
medidas de mel3oria factveis #ue ele implementar2 na pr"xima %print. ;ssas mudanas se
tornam a adaptao para a inspeo emprica. (-.=P!);/% *.% FGGL% p. HO).
'or fim a /eunio di2ria8
.ada time se encontra diariamente para uma reunio de HS minutos c3amada /eunio
$i2ria. ;ssa reunio sempre feita no mesmo 3or2rio e no mesmo local durante as %prints.
$urante a reunio% cada membro explica8
O #ue ele reali&ou desde a Dltima reunio di2ria:
O #ue ele vai fa&er antes da pr"xima reunio di2ria: e
Muais obst2culos esto em seu camin3o.
(-.=P!);/% *.% FGGL% p. HS).
H6 C"n/.7!9"
.onclumos #ue as metodologias 2geis -./0( e ,' muito aderem e pouco divergem em
relao ao '()O*.
Aas 2reas de con3ecimento do '()O* como .ustos% Mualidade e /isco na realidade t1m por
objetivo #uantificar e #ualificar os pontos a serem desenvolvidos pelo gerente de projeto. !
proposta do desenvolvimento 2gil est2 diretamente ligada + proposta de gan3o na fase de execuo
do projeto% integrando v2rias 2reas de con3ecimento atravs de um processo de comunicao
conciso e efica&% envolvendo todos os interessados no projeto desde o nvel de recurso. $esta
maneira% envolvendo o usu2rio% redu&4se o risco ligado + dificuldade de entendimento por parte da
contratao de um projeto de software% decorrente do alto seu nvel de abstrao.
HS
$iferente do '()O*% as metodologias 2geis focam no planejamento iterativo% pois no esto
focadas no #uesito pra&o (este passa ser uma conse#Z1ncia j2 #ue o nvel de retrabal3o do projeto
diminui)% e sim na ader1ncia do usu2rio em relao ao escopo definido e #ualidade esperada.
$esenvolver softwares em #ue o usu2rio no con3ece bem o escopo algo muito complexo.
'ara tal a mescla entre o '()O*% -./0( e o ,' facilita muito o processo de gerenciamento do
ciclo de vida do software por parte do gerente de projeto% j2 #ue ele tem um processo de
desenvolvimento baseado na efetividade da comunicao entre os envolvidos% e por tr2s disso
existindo o arcabouo dos processos do '()O*% como o de a#uisiEes e custos para medir os
rudos #ue inviabili&ariam o projeto% garantindo assim #ue as metodologias 2geis atuem de forma
complementar ao '()O*. !ssegurando #ue de forma implcita ao projeto as demais 2reas de
con3ecimento (.usto% Mualidade% /iscos% 5ntegrao e !#uisiEes) sejam aplicadas.
Re@erFn/#&! '#0.#"%rI@#/&!
!gile (anifesto. M&n#@e!" 2&r& De!en$".$#;en" B%#. de S"@4&re. W-.l.X% FGGH. $isponvel em8
[3ttp8QQagilemanifesto.orgQisoQptbrQmanifesto.3tml\. !cesso em8 HK nov. FGHG.
!/!]7O WFX% 6. E!7d" C";2&r&#$" d& C";2&#0#.#d&de enre &! ;e.1"re! 2rI#/&! d" PMI
e SCRUM6 FGGL6 KK f. >rabal3o de .oncluso de .urso ('"s <raduao em <esto de 'rojetos 4
'(5)% ?aculdade de 5nform2tica e !dministrao 'aulista% -o 'aulo% FGGL.
!/!]7O WHX% /. AnI.#!e de E!/"2" e P.&ne-&;en" n" De!en$".$#;en" de S"@4&reJ !"0 &
Per!2e/#$& B%#.6 FGGL. K f. ;studo )ibliogr2fico ()ac3arelado em -istemas de 5nformao)% -o
6eopoldo% FGGL.
);.*% *. Pr"%r&;&89" eGre;& <XP= eG2.#/&d&: &/".1& &! ;7d&n8&!6 H. ed. 'orto !legre8
)oo@man% FGGO. HKF p.
.=!'5;P-*5% <. C";" e!&;"! #nd" /"; & &d"89" de SCRUM n& G."0"6/";. W-.l.X% FGGK.
$isponvel em8 [3ttp8QQgc.blog.brQFGGKQGSQFUQcomo4estamos4indo4com4a4adocao4de scrum4na4
globocom\. !cesso em8 HJ nov. FGHG.
$;.!/6O% $. EGre;e Pr"-e/ M&n&%e;en6 H. p. -an ?rancisco (;0!)8 7ossey4)ass% FGGO.
SHS p. (traduo nossa)
HR
;5-.=;A% *. S"@4&re de$e."2;en: an outsider^s view. 5;;;. .omputer% v. JS% n. S% FGGF. p.
JR4OO.
?!6)O% /. En%en1&r#& de S"@4&re6 FGGS. LL f. Aotas de !ula ($isciplina de ;ngen3aria de
-oftware) _ 0niversidade ?ederal do ;sprito -anto% ;sprito -anto FGGS.
6;OA;6% 6.% et. al.% Ge!9" d& Pr"d7#$#d&de: EGre;e Pr"%r&;;#n%. FGGU. JF f. ;studo
)ibliogr2fico% -o 'aulo% FGGU.
(!.Y$O% 5. et al. A!2e/"! /";2"r&;en&#! de %e!9" de 2e!!"&!6 L. ed. /io de 7aneiro8
;ditora ?<V% FGHG. HSG p.
A;>O% ;.% S/r7;;#n%: Ferr&;en& Ed7/&/#"n&. 2&r& En!#n" de PrI#/&! d" SCRUM6 FGGK.
KG f. >rabal3o de .oncluso de .urso ()ac3arelado em -istemas de 5nformao)% 'ontifcia
0niversidade .at"lica do /io <rande do -ul% /io <rande do -ul% FGGK.
'!.=;.O% $. S/r7; e & %e!9" de 2e!!"&!6 W-.l.X% FGGL. $isponvel em8
[3ttp8QQimasters.com.brQartigoQHFRFGQagileQscrum`e`a`gestao`de`pessoas\. !cesso em FS nov.
FGHG.
'5(;A>;6% !. U;& A0"rd&%e; 2&r& " 2r"-e" de !"@4&re "r#en&d" & "0-e"! 0&!e&d" n&
e"r#& de 2r"-e" &G#";I#/"6 FGGU. HKL f. >ese ($outorado em .i1ncias) 4 0niversidade
>ecnol"gica ?ederal do 'aran2% 'aran2% FGGU.
'(5 4 '/O7;.> (!A!<;(;A> 5A->5>0>;. U; G7#& d" C"n1e/#;en" d" Geren/#&;en"
de Pr"-e"! <G7#& PM'O(=% O. ed. FGGK. JJU p.
-.=P!);/% *. GUIA DO SCRUM6 FGGL. FF p.
-;V;/5AO% 6. O 2"der d" PM'O( n" %eren/#&;en" de 7; 2r"-e" SCRUM6 FGGL. RH f.
>rabal3o de .oncluso de .urso (<raduao em .i1ncia da .omputao)% 0niversidade ;stadual
de 6ondrina% 6ondrina% FGGL.
-O!/;-% !. Pr"/e!!" B%#. de De!en$".$#;en" de S"@4&re 2&r& EC7#2e! Se2&r&d&!
Re;"&;ene C7e U#.#3&; Ferr&;en&! de S"@4&re L#$re /";" S72"re &"
HU
De!en$".$#;en"6 FGGL. RG f. >rabal3o de .oncluso de .urso (<raduao em ;ngen3aria da
.omputao)% 0niversidade ?ederal de 'ernambuco% /ecife% FGGL.
-O((;/V566;% 5. En%en1&r#& de S"@4&re6 K. ed. -o 'aulo8 'earson% FGGU. SOK p.
-O>566; et al.% Geren/#&;en" d" e!/"2" e; 2r"-e"!. F. ed. /io de 7aneiro8 ;ditora ?<V%
FGHG. HUG p.
>;6;-% V. U; E!7d" de C&!" d& Ad"89" d&! PrI#/&! e V&."re! d" EGre;e Pr"%r&;;#n%6
FGGS. HUL f. $issertao ((estrado em 5nform2tica) _ 0niversidade ?ederal do /io de 7aneiro% /io
de 7aneiro% FGGS.
>;6;-% V. EGre;e Pr"%r&;;#n%J XP: ;e"d"."%#& de!en$".$#;en" I%#.6 W-.l.X% FGGK.
$isponvel em8 [3ttp8QQwww.improveit.com.brQxp\. !cesso em FK out. FGHG.
0/$!A<!/5A% /. U;& In$e!#%&89" !"0re " U!" de PrI#/&! EGre;e Pr"%r&;;#n% n"
De!en$".$#;en" G."0&. de S"@4&re6 FGGK. HHK f. $issertao ((estrado em .i1ncia da
.omputao) _ 'ontifcia 0niversidade .at"lica do /io <rande do -ul% /io <rande do -ul% FGGK
P!/$;A% -. EGre;e Pr"%r&;;#n% P"/Ke G7#de. H ed. -ebastopol8 Oa/eilly% FGGJ. KJp.
HK