Você está na página 1de 63

UNIVERSIDADE SO JUDAS TADEU

GERNCIA DE PROJETOS COM NFASE NAS


PRTICAS DO PMI

PATRCIA FONTOURA DE SENE

GERENCIAMENTO GIL DE PROJETOS

SO PAULO
2010

PATRCIA FONTOURA DE SENE

GERENCIAMENTO GIL DE PROJETOS

Trabalho de Concluso de Curso apresentado ao


Curso de Ps-Graduao Gerncia de Projetos
com nfase nas Prticas do PMI como requisito
parcial para a aprovao. Universidade So
Judas Tadeu.
Orientador (a): Prof.() Nelson J. Rosamilha, PMP

SO PAULO
2010

DEDICATRIA

Isa Karasek, que sempre se orgulhou das minhas pequenas e grandes


vitrias.

AGRADECIMENTOS

Agradeo minha amiga Gitnia que, mesmo sem saber, me estimulou a dar
o primeiro passo nesta caminhada.

EPGRAFE
"Suba o Primeiro degrau com f. No necessrio que voc veja toda a
escada. Apenas de o primeiro passo." Martin Luther King.

RESUMO

Os Mtodos geis surgiram quando os Mtodos Tradicionais de desenvolvimento de


software comearam a ser questionados devido, principalmente, ao grande volume
de documentao. Eles ganharam mais ateno com a publicao de um manifesto
em 2001 e aps com o surgimento do Gerenciamento gil de Projetos, que
representa um conjunto de valores, princpios e prticas, que auxiliam a equipe de
projeto a entregar produtos de valor em ambientes desafiadores. Com a elaborao
deste estudo concluiu-se que as metodologias geis buscam o estabelecimento de
novos paradigmas para o desenvolvimento de software, onde o desenvolvimento gil
de software o foco principal dessas metodologias. As metodologias geis visam
simplicidade na implementao de um projeto, pois suas regras so simples de
serem seguidas. O sucesso na adoo de um modelo gil est diretamente
relacionado ao comprometimento do time, pois sua forma de conduo dos
trabalhos possui um elevado grau de informalidade.
PALAVRAS-CHAVE:
Metodologias
Desenvolvimento gil de Software.

geis;

Gerenciamento

de

Projetos;

ABSTRACT
Agile methods have emerged when the traditional methods of software development
began to be questioned, mainly due to the large volume of documentation. They
gained more attention with the publication of a Agile Alliance in 2001 and after the
emergence of Agile Project Management, which represents a set of values, principles
and practices that help the project team to deliver value products in challenging
environments. With the preparation of this study concluded that agile methodologies
seek to establish new paradigms for software development, where the agile software
development is the main focus of these methodologies. The agile methodologies aim
at simplicity in the implementation of a project, its principles are simple rules to follow.
The successful adoption of an agile model is directly related to the involvement of the
team, because their way of conducting the work has a high degree of informality.
KEYWORDS:
Development.

Agile

Methodologies,

Project

Management,

Agile

Software

LISTA DE FIGURAS
Figura 1: Frmula funcionalidade FDD ...........................................................37
Figura 2: Metodologia Scrum..........................................................................39
Figura 3: Ciclo do Sprint .................................................................................41
Figura 4: Processo do XP ...............................................................................50
Figura 5: Iterao com o XP ...........................................................................50

LISTA DE QUADROS
Quadro 1: Transio de conceitos de gerenciamento de projetos..................19
Quadro 2: Processos de gerenciamento de projetos ......................................23
Quadro 3: Princpios metodologias geis .......................................................29
Quadro 4: Comparao entre metodologias geis e tradicionais ...................34
Quadro 5: Valores da metodologia XP............................................................43
Quadro 6: Prticas do XP ...............................................................................46
Quadro 7: Caractersticas da equipe ..............................................................48
Quadro 8: Tcnicas e metodologias ...............................................................51
Quadro 9: Comparao gesto clssica e gesto gil....................................57

SUMRIO
1 INTRODUO ........................................................................................12
1.1 OBJETIVO ............................................................................................13
1.2 JUSTIFICATIVA ....................................................................................14
1.3 VIABILIDADE ........................................................................................15
1.4 METODOLOGIA....................................................................................15

2 GERENCIAMENTO CLSSICO DE PROJETOS...........................16


2.1 O QUE O PMI? ..................................................................................16
2.2 O QUE UM PROJETO?.....................................................................17
2.3 O QUE A GESTO DE PROJETOS?................................................18
2.4 O GERENCIAMENTO DE PROJETOS SEGUNDO O PMI ..................21
2.5 O GERENCIAMENTO DE PROJETOS DE SOFTWARE .....................25

3 METODOLOGIAS GEIS ....................................................................27


3.1 CARACTERSTICAS DAS METODOLOGIAS GEIS ..........................30
3.1.1 Caractersticas das Equipes geis .................................................33
3.2 DIFERENAS ENTRE MTODOS GEIS E MTODOS CLSSICOS33
3.3 DESENVOLVIMENTO RPIDO DE APLICATIVOS (SOFTWARES) ...35
3.4 Principais Metodologias geis ..............................................................36
3.4.1 Feature-Driven Development FDD ..............................................36
3.4.2 Adaptative Software Development - ASD .......................................38
3.4.3 Lean Development - LD ..................................................................38
3.4.4 Scrum .............................................................................................39
3.4.5 Extreme Programming - XP ............................................................42
3.4.6 Comparativo dos Mtodos geis ....................................................50

3.5 LIMITAES NO EMPREGO DOS MTODOS GEIS .......................51


3.6 DESVANTAGENS DOS MTODOS GEIS .........................................53
3.7 VANTAGENS DOS MTODOS GEIS ................................................53

4 GERENCIAMENTO GIL DE PROJETOS ......................................55


4.1 O QUE GERENCIAMENTO GIL DE PROJETOS? .........................56
4.2 CARACTERSTICAS DOS PROJETOS PARA UTILIZAO DO
GERENCIAMENTO GIL ......................................................................................56
4.3 COMPARAO ENTRE GESTO CLSSICA E GESTO GIL DE
PROJETOS ...........................................................................................................57
4.4 FATORES CRTICOS DE SUCESSO PARA O GERENCIAMENTO
GIL ......................................................................................................................58

5 CONCLUSO ..........................................................................................59
6 REFERNCIAS BIBLIOGRFICAS...................................................61

12

1 INTRODUO

O Gerenciamento de Projetos de Software vem apresentando uma busca


incessante por um mtodo cientfico que proporcione resultados produtivos e
qualitativos, e que possa ser utilizado similarmente a uma receita de bolo,
independentemente de cultura, tecnologia e tipo de negcios. Por trs desta busca
existem os anseios mais ntimos e importantes das empresas: fazer projetos de
software com lucro, com a plenitude da satisfao do cliente, com a fidelizao do
cliente e com crescimento tcnico profissional.
A cada ano que passa a importncia do software e, consequentemente, sua
complexidade

vem

crescendo

significativamente.

Processos

orientados

documentao podem ser fatores limitadores ao desenvolvimento de software, alm


de muitas organizaes no possurem recursos ou inclinao para processos
pesados de produo de software. Por esta razo, as organizaes pequenas
acabam por no usar nenhum processo, o que pode levar a efeitos desastrosos na
qualidade do produto final, alm de dificultar a entrega do software nos prazos e
custos predefinidos.
Neste contexto, as metodologias geis tm sido apontadas como uma
alternativa s abordagens tradicionais para o desenvolvimento de software. Trata-se
de uma abordagem de gerenciamento de projetos geralmente empregada no
desenvolvimento de software. A metodologia gil auxilia as equipes a responder aos
imprevistos durante a construo de softwares por meio de um trabalho interativo,
denominado sprints.
Os mtodos geis surgiram como oposio ao desempenho insatisfatrio dos
projetos de desenvolvimento de software conduzidos com uso de mtodos
tradicionais de desenvolvimento e gerenciados de acordo com prticas e princpios
do gerenciamento clssico de projetos. Tiveram seu desenvolvimento focado,
principalmente, em projetos onde h dificuldades no estabelecimento de requisitos,
ou onde os requisitos mudam de forma dinmica no decorrer do projeto.

13

Iniciado em princpio num mbito tcnico, com a instaurao de novos


modelos e mtodos de desenvolvimento de software, passou, posteriormente, ao
mbito gerencial, dando-se incio ao Gerenciamento gil de Projetos. E
considerando o ritmo acelerado das mudanas nos projetos de desenvolvimento de
software, existe, no mercado, uma forte tendncia para o desenvolvimento e
gerenciamento gil das aplicaes.
Desenvolvimento gil um termo usado para agrupar metodologias
interativas e incrementais de desenvolvimento de software, tais como Extreme
Programming (XP), Scrum, Crystal, Dynamic Systems Development Method
(DSDM), Lean Development, e Feature Driven Development (FDD). Especialmente
durante os ltimos anos, o desenvolvimento gil consolidou sua presena em
empresas como a Siemens, CapitalOne, Lockheed Martin, Motorola, Microsoft,
Yahoo, Google, GE e Cisco Systems. Essas e muitas outras empresas adotaram
processos geis para entregar melhorias significativas em matria de inovao,
qualidade, produtividade e vantagem competitiva.
Este trabalho explora teorias e abordagens alternativas para o gerenciamento
de projetos de desenvolvimento de software. Esta explorao feita avaliando-se
abordagens que foram consideradas influenciadoras nos resultados positivos de
projetos, como o caso dos Mtodos geis. apresentada uma viso geral das
metodologias geis e do gerenciamento gil de projetos de software, partindo
inicialmente da metodologia clssica de desenvolvimento e de gerenciamento de
projetos.

1.1 OBJETIVO
O objetivo principal deste trabalho comprovar os benefcios do
Gerenciamento gil de Projetos de Desenvolvimento Software, atravs a avaliao
das metodologias geis.
Para alcanar o objetivo acima explicitado, faz-se necessrio:

14

Estudar as metodologias para desenvolvimento de software;

Estudar os mtodos e tcnicas geis de desenvolvimento de software;

Construir resultados e quadros comparativos entre os mtodos de


desenvolvimento estudados;

Entender as caractersticas dos projetos de software gerenciados com


mtodos geis;

Formular a concluso deste trabalho.

1.2 JUSTIFICATIVA
Atualmente, comum encontrar software de baixa qualidade e projetos que
excedem as previses de custos e tempo de desenvolvimento, ou ainda, sistemas
que no atendem a todas as exigncias esperadas. Desse modo, os processos de
desenvolvimento de software e de gerenciamento de projetos desta natureza, tm
ganhado maior importncia como forma de prover software de qualidade e cumprir
corretamente os prazos de desenvolvimento.
Neste sentido, o presente trabalho busca fazer um estudo dentre os vrios
modelos de processos de desenvolvimento de software, dando-se uma maior nfase
aos modelos classificados como geis, e ao gerenciamento gil de projetos.
As metodologias geis de desenvolvimento de software se propem a
construir softwares com maior produtividade e, sobretudo, com qualidade garantida.
Para isso elas encaram os projetos sobre um novo paradigma e defendem a adoo
de uma srie de princpios e prticas. Entre as quebras de paradigma est a forma
de encarar a mudana. Ela passa a ser encarada como algo inevitvel no projeto de
software, pois enquanto que as metodologias tradicionais abordam o escopo como
fixo, devendo ser controlado o mximo possvel para no haver mudanas; as
metodologias geis abordam o escopo como manipulvel e oferecem flexibilidade
para sua mudana.

15

1.3 VIABILIDADE

Para o desenvolvimento desta pesquisa faz-se necessrio um levantamento e


estudo antecipado da bibliografia disponvel sobre o tema. Como o assunto ainda
recente, alguns tpicos abordados possuem escassa bibliografia editada, sendo
necessrio recorrer pesquisa de outros artigos e trabalhos escritos no meio
acadmico. Sendo assim, a Internet constitui recurso de pesquisa importante para o
desenvolvimento deste trabalho.

1.4 METODOLOGIA

A metodologia utilizada neste trabalho constitui um estudo bibliogrfico,


seguido de uma fundamentao terica sobre os diversos tipos de abordagens de
desenvolvimento de software e gerenciamento de projetos desta natureza. O
contedo do estudo apresenta entre as metodologias de desenvolvimento e suas
caractersticas, e permitem a analise das principais vantagens e desvantagens dos
mtodos geis de desenvolvimento bem como seu impacto na gerncia dos
projetos. O trabalho concludo com a exposio dos benefcios de se gerenciar
projetos de software com gerenciamento gil.

16

2 GERENCIAMENTO CLSSICO DE PROJETOS

Um projeto pode ser definido como um empreendimento organizado para


alcanar um objetivo especfico. Segundo Davis, Aquilano e Chase (2001),
tecnicamente, um projeto definido como uma srie de atividades ou tarefas
relacionadas que so, geralmente, direcionadas para uma sada principal e que
necessitam um perodo de tempo significativo para sua realizao.
Vargas (2009, p. 6) apresenta duas citaes sobre o que vem a ser um
projeto:
Para Cleland, um projeto uma combinao de recursos organizacionais,
colocados juntos para criarem ou desenvolverem algo que no existia
previamente, de modo a prover um aperfeioamento da capacidade de
desempenho no planejamento e na realizao de estratgias
organizacionais.
J para Meredith, um projeto uma atividade nica e exclusiva com um
conjunto de resultados desejveis em seu trmino. tambm complexo o
suficiente para necessitar de uma capacidade de coordenao especfica e
um controle detalhado de prazos, relacionamentos, custos e desempenho.

2.1 O QUE O PMI?

Em 1969 um grupo de cinco profissionais de gesto de projetos da


Philadelphia e Pensilvnia reuniram-se, nos EUA, para discutir melhores prticas de
gerenciamento de projetos. Assim, Jim Snyder fundou o PMI - Project Management
Institute, uma entidade internacional e sem fins lucrativos, que congrega
profissionais que atuam em reas relacionadas gesto de projetos.
A premissa do PMI que as ferramentas e as tcnicas da gerncia de projeto
so terra comum desde a aplicao difundida em projetos da indstria do software
at indstria de construo. Em 1981, os diretores do PMI autorizaram o
desenvolvimento do Guia PMBOK - Project Management Body of Knowledge, que

17

se transformou em um guia de projetos contendo os padres e as linhas mestras


das prticas utilizadas para o gerenciamento de projetos (PMBOK, 2004).

2.2 O QUE UM PROJETO?

Segundo a definio do PMI, apresentada na 3 edio do Guia P PMBOK


(2004, p. 5), "Um projeto um esforo temporrio empreendido para criar um
produto, servio ou resultado exclusivo".
Sendo assim, um projeto uma iniciativa que nica de alguma forma:


Seja no produto que gera;

Seja no cliente do projeto;

Seja na localizao;

Seja nas pessoas envolvidas;

Seja em outro fator.


Um projeto possui um incio e um fim bem definido, o que d a caracterstica

de temporrio. Em outras palavras, possui um objetivo claro, que quando atingido,


caracteriza o final do projeto (PMBOK, 2004).
Os atributos de um projeto, segundo os autores Mattos e Guimares (2005; p.
132), so:


Propsito nico;

Temporrio;

Necessidade de recursos, frequentemente de vrias reas;

Necessidade de financiador e cliente;

Envolve incertezas, decorrentes de premissas assumidas como verdadeiras


no incio do projeto e que podem no ocorrer. So usualmente consideradas
na anlise de riscos.

18

2.3 O QUE A GESTO DE PROJETOS?

A Gerncia de Projetos surgiu como um processo de gerenciamento para lidar


com a complexidade do trabalho em grupo baseado em conhecimento e pelas
demandas de novos mtodos de gerenciamento. Nos Estados Unidos, o pai da
gerncia de projetos Henry Gantt. Ele chamado o pai das tcnicas de
planejamento e de controle e conhecido pelo uso do grfico de barra como uma
ferramenta de gesto de projeto. O trabalho de Henry Gantt precursor de muitas
ferramentas da gesto de projetos, tais como a WBS - Work Breakdown Structure ou
EAP - Estrutura Analtica do Projeto (WIKIPEDIA, 2010).
Um projeto est sujeito a uma tripla limitao estabelecida nas metas de
escopo, de prazo e de custos. Para que as atividades de um projeto sejam
realizadas e seus objetivos sejam atingidos, os projetos demandam de esforo de
gerenciamento. Como uma disciplina, a gerncia de projetos foi desenvolvida de
diversos campos de aplicao que vo desde a construo civil e a engenharia
mecnica at projetos militares (MATTOS, GUIMARES, 2005).
Portanto, a Gerncia de Projetos (ou Gesto de Projetos) a aplicao de
conhecimentos, habilidades e tcnicas para projetar atividades que visem atingir ou
exceder as expectativas das partes envolvidas (MATTOS, GUIMARES, 2005).
Gerenciar, administrar, coordenar ou gerir um projeto, envolve desde inici-lo
at finaliz-lo, passando pelas etapas de planejamento, execuo e atividades de
controle. A Gesto de Projetos envolve um processo de estabelecimento de um
plano que ser implementado para atingir os objetivos propostos. Em sntese, o
gerenciamento de projetos consiste primeiramente no planejamento do trabalho e
depois na execuo do plano (GIDO, CLEMENTS, 2007).
O gerenciamento de projetos pode ser entendido como o planejamento, a
direo e o controle de recursos (pessoas, equipamentos e materiais) para atender
s restries tcnicas, de custos, e de tempo do projeto.

19

O quadro abaixo apresenta os principais mitos do gerenciamento de projetos


e os conceitos revisados por Kerzner (1998).
Quadro 1: Transio de conceitos de gerenciamento de projetos
MITOS
CONCEITOS REVISADOS
Gerenciamento de projetos requer mais Gerenciamento de projetos permite ao
pessoas e adiciona custos indiretos projeto realizar mais trabalho em menos
empresa.
tempo com menos pessoas.
A
lucratividade
pode
diminuir
em A lucratividade ir aumentar devido
decorrncia dos custos de controle.
presena de controle.
O gerenciamento de projetos aumenta o O gerenciamento de projetos permite maior
nmero de mudanas no escopo.
controle sobre as mudanas de escopo.
O
gerenciamento
de
projetos
cria O gerenciamento de projetos torna a
instabilidade organizacional e aumenta os organizao mais eficiente e melhor
conflitos entre departamentos.
efetivamente a relao entre os setores por
meio do trabalho em equipe.
O
gerenciamento
de
projetos
cria O gerenciamento de projetos possibilita a
problemas.
soluo de problemas.
Somente grandes projetos necessitam de Todos
os
projetos
se
beneficiam
gerenciamento.
diretamente do gerenciamento de projetos.
O gerenciamento de projetos cria problemas O gerenciamento de projetos reduz conflitos
de poder e autoridade.
por poder.
O gerenciamento de projetos tem como O gerenciamento de projetos tem como
objetivos os produtos.
objetivo as solues.
O custo do gerenciamento de projetos pode O gerenciamento de projetos aprimora os
tornar a companhia menos competitiva.
negcios da empresa.
Fonte: Kerzner, 1998.

Germano (2008) descreve nove pecados mortais no planejamento de


projetos:


Sem planejamento algum: o problema mais comum no ter planejamento


algum, mas isto pode ser facilmente evitado, pois uma pessoa no precisa ser
um especialista na rea para criar um planejamento eficiente. Mas, o
planejamento essencial.

Falha ao contabilizar todas as atividades de projeto: ou seja, no planejar o


suficiente. Alguns planos de projetos so criados assumindo que ningum no
time de desenvolvimento ficar doente, ter treinamentos, frias ou sair da
empresa. As atividades principais so geralmente subestimadas em grande
nvel. Planejamentos criados assumindo condies irreais como estas levaro
projetos ao desastre.

Falha ao planejar por riscos: para projetos de software, esquivar-se


constantemente de falhas to importante quanto simular o sucesso. Em
muitos contextos, a palavra risco no mencionada a menos que o projeto

20

j esteja em grandes problemas. Em software, o gestor do projeto que no


utiliza a palavra risco todos os dias e no incorpora o gerenciamento de
riscos em seu plano provavelmente no est realizando seu trabalho.


Utilizar o mesmo plano para todos os projetos: algumas empresas crescem


envoltas em uma forma particular de conduzir os projetos de software, que
conhecida como o jeito que fazemos as coisas por aqui. Quando esta
abordagem utilizada, a empresa tende a ir bem enquanto o projeto se
parecer com os antigos projetos.

Aplicar indiscriminadamente planejamentos pr-fabricados: os planos prfabricados podem ajudar a evitar problemas, mas no so substitutos para a
tentativa de otimizar o planejamento de um projeto para suas principais
necessidades.

Nenhum

especialista

de

fora

pode

compreender

as

necessidades especficas de um projeto to bem quanto s pessoas


diretamente envolvidas nele.


Permitir que um planejamento fuja realidade do projeto: uma abordagem


comum para o planejamento criar um plano no incio do projeto e ento
desprez-lo, no seguindo o que foi planejado. medida que as condies do
projeto mudam, o plano torna-se invariavelmente irrelevante, e, ao chegar
metade, o projeto correr livre de formas, sem nenhuma relao real entre o
planejamento inicial e a realidade do projeto. O planejamento do projeto deve
evoluir atravs do projeto.

Planejar em muitos detalhes muito cedo: alguns gestores bem intencionados


tentam mapear todo o valor das atividades de um projeto muito cedo. Mas um
projeto de software consiste em um grupo de decises constantemente
desconhecido, e cada fase de um projeto cria dependncias para as futuras
decises. Deste modo, tentar planejar atividades distantes em muitos
detalhes um exerccio burocrtico e prejudica o planejamento.

Planejando para alcanar no futuro: para projetos que trabalham em atraso,


um erro comum planejar para recuperar o tempo perdido no futuro. Mas,
medida que a equipe progride para as fases mais adiantadas do projeto, a
velocidade no aumenta; ela ir diminuir media que encontrar as
consequencias dos erros cometidos mais cedo e investir tempo tentando
corrigir tais erros.

21

No aprender com os erros de planejamentos antigos: projetos de software


podem durar muito tempo, no final de um longo projeto, pode ser difcil
recordar todas as decises anteriores que afetaram sua concluso. Uma
forma fcil de conter esta tendncia e prevenir futuros pecados mortais
conduzir uma retrospectiva post mortem. Tal processo estruturado pode no
apagar os erros passados de um projeto, mas pode certamente ajudar a
prevenir os erros de projetos futuros.

2.4 O GERENCIAMENTO DE PROJETOS SEGUNDO O PMI

A proposta de gesto de projetos atravs da abordagem tradicional de


gerenciamento de projetos, estruturada segundo uma viso de processos conforme
proposto pelo PMI, bastante aceita dentro da gerncia tradicional de projetos. A
definio de gerenciamento de projetos est baseada na gesto funcional, com a
estruturao do gerenciamento por meio de processos, encarando o projeto como
uma sequencia de atividades linearmente distribudas. Esta definio trata do ciclo
de vida do projeto da maneira pela qual ele visto pelas principais metodologias de
desenvolvimento, com suas fases bem definidas.
O PMI descreve, no Guia PMBOK (2004, p. 8), o gerenciamento de projetos
como "[...] a aplicao de conhecimentos, habilidades, ferramentas e tcnicas s
atividades do projeto, a fim de atender aos seus requisitos". O PMI destaca ainda
que o "gerenciamento de projetos realizado atravs da aplicao e da integrao
dos seguintes processos de gerenciamento de projeto: iniciao, planejamento,
execuo, monitoramento e controle e encerramento" (PMBOK , 2004, p. 8).
Ainda segundo o PMI, gerenciar um projeto inclui identificar as necessidades,
estabelecer objetivos claros e alcanveis, balancear demandas conflitantes de
qualidade, escopo, tempo e custo, adaptar especificaes, planos e abordagens s
diferentes preocupaes e expectativas das diversas partes interessadas (PMBOK,
2004).

22

Na viso do PMI (2004, p. 37-38) "o gerenciamento de projetos realizado


atravs de processos, usando conhecimento, habilidades, ferramentas e tcnicas do
gerenciamento de projetos que recebem entradas e geram sadas". Neste caso,
Processo definido como "um conjunto de aes e atividades inter-relacionadas
realizadas para obter um conjunto pr-especificado de produtos, resultados ou
servios".
Existem duas categorias de processos em um projeto (PMBOK, 2004):


Processos de gerenciamento de projetos: comuns a maioria dos projetos,


visando um objetivo integrado: iniciar, planejar, executar, monitorar e controlar
e encerrar um projeto.

Processos de orientados ao produto: especificam e criam o produto do


projeto.
Os processos de gerenciamento de projetos esto agrupados em 5 grupos,

de acordo com o PMI (2004, p. 41), que os descreve como:




Processos de iniciao: definem e autorizam o projeto ou fase do projeto;

Processos de planejamento: definem e refinam os objetivos e planejam as


aes necessrias para atingir os objetivos e o escopo para os quais o projeto
foi concebido;

Processos de execuo: integram pessoas e outros recursos visando a


execuo do plano de gerenciamento do projeto;

Processos de monitoramento e controle: medem e monitoram o progresso do


projeto regularmente para identificao das variaes em relao ao plano,
possibilitando a tomada de aes corretivas para atendimento aos objetivos
do projeto.

Processos de encerramento: formalizam a aceitao final do produto, servio


ou resultado, conduzindo o projeto ou fase a um final ordenado.
Nestes cinco grupos de processos, esto distribudos os 44 processos de

gerenciamento de projetos, distribudos em nove reas de conhecimento segundo o


PMI descreve em seu guia (2004, p. 10), sendo estas:


Gerenciamento da integrao: rea que engloba os processos requeridos


para assegurar que todos os elementos do projeto sejam adequadamente

23

coordenados e integrados, garantindo que o seu todo seja sempre


beneficiado.


Gerenciamento de escopo: rea que engloba os processos necessrios para


assegurar que, no projeto, esteja includo todo o trabalho requerido, e
somente o trabalho requerido, para conclu-lo de maneira bem-sucedida.

Gerenciamento de tempo: rea que engloba os processos necessrios para


assegurar a concluso do projeto no prazo previsto. uma das aeras mais
visveis do gerenciamento de projetos.

Gerenciamento de custos: rea que engloba os processos requeridos para


assegurar que os produtos ou servios do projeto estaro em conformidade
com o solicitado pelo cliente, ou contratante.

Gerenciamento de recursos humanos: rea que engloba os processos


requeridos para fazer uso mais efetivo do pessoal envolvido com o projeto.

Gerenciamento das comunicaes: rea que engloba os processos


requeridos

para

assegurar

que

as

informaes

do

projeto

sejam

adequadamente obtidas e disseminadas.




Gerenciamento de riscos: rea que visa planejar, identificar, qualificar,


quantificar, responder e monitorar os riscos do projeto.

Gerenciamento das aquisies: rea que engloba os processos requeridos


para adquirir bens e servios de fora da organizao promotora. Tambm
conhecido como gerenciamento de suprimentos ou contratos.
O PMBOK 3 edio (PMBOK, 2004) aborda 42 processos divididos em

noves reas de conhecimento que formam um fluxo contnuo de processos. O


quadro abaixo resume o mapeamento dos processos de gerenciamento de projetos
com sua associao aos grupos de processos e reas de conhecimento.
Quadro 2: Processos de gerenciamento de projetos
Grupos de Processos de Gerenciamento de Projetos
Grupo de
Grupo de
Grupo de
processos de
processos de
processos de
planejamento
execuo
monitoramento e
controle
Gerenciamento
Desenvolvimento
Desenvolvimento
Orientao e
Monitoramento e
da integrao do do termo de
do plano de
gerenciamento da controle do
projeto
abertura do projeto gerenciamento do execuo do
trabalho do projeto
Desenvolvimento
projeto
projeto
Controle integrado
da declarao de
de mudanas
escopo preliminar
do projeto
Grupo de
processos de
iniciao

Grupo de
processos de
encerramento
Encerramento do
projeto

24

Gerenciamento
do escopo do
projeto

Gerenciamento
de
tempo
do
projeto

Gerenciamento
de custos do
projeto
Gerenciamento
da qualidade do
projeto
Gerenciamento
de
recursos
humanos
do
projeto
Gerenciamento
das
comunicaes do
projeto
Gerenciamento
de
riscos
do
projeto

Gerenciamento
de aquisies do
projeto

Planejamento do
escopo
Definio do
escopo
Criao da EAP
(Estrutura Analtica
do Projeto)
Definio da
atividade
Sequenciamento
de atividades
Estimativa de
recursos da
atividade
Estimativa de
durao da
atividade
Desenvolvimento
do cronograma
Estimativa de
custos
Oramento
Planejamento da
Realizao da
qualidade
garantia da
qualidade
Planejamento de
Contratao ou
recursos humanos mobilizao da
equipe do projeto
Desenvolvimento
da equipe do
projeto
Planejamento das Distribuio das
comunicaes
informaes

Planejamento do
gerenciamento de
riscos
Identificao de
riscos
Anlise qualitativa
de riscos
Anlise
quantitativa de
riscos
Planejamento de
respostas a riscos
Planejamento das
compras e
aquisies
Planejamento das
contrataes

Solicitao das
respostas de
fornecedores
Seleo de
fornecedores

Verificao do
escopo
Controle do escopo

Controle do
cronograma

Controle de custos
Realizao do
controle da
qualidade
Gerenciamento da
equipe do projeto

Relatrio de
desempenho
Gerenciamento
das partes
interessadas
Monitoramento e
controle dos riscos

Administrao de
contrato

Encerramento de
contrato

Fonte: PMBOK, 2004, p. 70.

O sucesso na gesto de um projeto est relacionado ao alcance dos


seguintes objetivos:


Entrega dentro do prazo previsto;

Entrega dentro do custo orado;

Entrega com nvel de desempenho adequado;

25

Aceitao pelo cliente;

Atendimento de forma controlada s mudanas de escopo, e;

Respeito cultura da organizao.


A pessoa responsvel pela gesto do projeto o gerente do projeto, que

consequentemente, tambm responsvel pelo sucesso ou insucesso do projeto. O


gerente do projeto deve ser designado no incio do projeto, tendo o apoio da alta
administrao da organizao. Ele deve ter sua competncia reconhecida pelos
demais interessados no projeto, embora no necessite ter conhecimento tcnico
aprofundado, uma vez que suas competncias so mais voltadas para o
entendimento geral e no especfico (PMBOK, 2004).

2.5 O GERENCIAMENTO DE PROJETOS DE SOFTWARE

As regras do gerenciamento de projetos tambm podem ser aplicadas aos


projetos de software. A gerncia de projetos de desenvolvimento de software deve
ter em mente que sua atividade deve objetivar a qualidade, produtividade e a
reduo de riscos atravs do planejamento e execuo do desenvolvimento do
produto (PMBOK, 2004).
O modelo de gerncia de projetos processual destaca a forma com que os
processos so divididos, facilitando a comunicao entre as fases do projeto. O
modelo incorpora os conceitos de gerncia de projetos do PMI em um modelo de
gerncia de projeto de software.
A Gerncia um item fundamental dentro de um projeto de software, e deve
estar presente durante todo o ciclo de vida do desenvolvimento de um sistema. A
capacidade gerencial em um projeto de software deve levar em consideraes
fatores como (ENGENHARIA, 2009):


Gesto da qualidade: alicerada sobre a qualidade do produto e qualidade do


processo. No primeiro necessrio verificar se as necessidades prestabelecidas pelos clientes esto implementadas no produto. No segundo,

26

importante analisar se o processo est organizado, estruturado para produzir


subprodutos de qualidade;


Gesto de configurao: conjunto de aes (ou tarefas) que possibilitam


identificar

todos

os

artefatos

gerados

pelo

processo

de

software,

estabelecendo um relacionamento entre eles. A gesto de configurao


tambm responsvel por subsidiar a atividade de gerenciamento em
projetos, pois esta necessita controlar as diferentes verses geradas para um
mesmo produto;


Gesto de expectativa: caracterizada pelo estabelecimento de uma relao


harmoniosa entre clientes internos e externos;

Gesto de risco: a gesto para minimizar as condies que comprometem


ou impendem realizao de alguma parte projeto;

Gesto de escopo: contextualizada por delimitar de maneira recorrente, as


necessidades, os produtos e as pessoas;

Gesto de aquisio: caracterizada pelo estabelecimento de um conjunto de


atividades e critrios que possibilitam a obteno de bens e servios fora dos
limites organizacionais.

27

3 METODOLOGIAS GEIS

At o ano de 2001, a maior parte dos modelos de sucesso para a realizao


de projetos de software era baseada no modelo Cascata, onde existe uma grande
fase de planificao que d todo o suporte ao desenvolvimento. Nestes modelos a
mudana de requisitos muito difcil de ser aceita em fases posteriores ao
planejamento, pois exige uma regresso para a fase de concepo do plano. Os
mtodos geis para desenvolvimento de software formaram uma alternativa aos
mtodos tradicionais, considerados pesados e caracterizados pelo foco excessivo
em documentao.
Os Mtodos geis de Desenvolvimento de Software surgiram, nos anos 90,
como uma resposta s cobranas por inovao em prazos cada vez mais reduzidos,
constantes necessidades de mudanas de requisitos e mau desempenho de grande
parte dos projetos de desenvolvimento de software. Nesta poca, as metodologias
tradicionais comearam a ser questionadas devido ao grande volume de
documentao, e um crescente nmero de organizaes passou a adotar um ou
mais mtodo gil para produzir software com menos documentao, sob condies
de mudanas rpidas e com foco na satisfao do cliente (MOL, 2007).
As metodologias geis estabelecem prticas que auxiliam a ampliar a
capacidade de aprendizado e adaptao dos projetos.
Segundo Vale (2008a, p. 30),
A adaptao e o aperfeioamento contnuo geram um processo
evolutivo que emerge das relaes sistmicas dos organismos com o
seu meio ambiente. Em projetos geis, seus processos tambm
emergem das relaes sistmicas estabelecidas entre as pessoas
envolvidas no projeto (stakeholders) e o seu meio de negcio. A
capacidade de adaptao elemento essencial de diferenciao do
modelo gil em relao aos processos tradicionais para
desenvolvimento de software. Os pequenos ciclos de avaliao e
aprendizado que o compe desafiam equipe e cliente a evolurem
seu processo por meio da deteco, anlise, correo e absoro
sistemtica de conhecimento sobre erros, ineficincias ou falsas
suposies encontrados durante seu tempo de vida.

28

Na concepo de metodologias geis, as correes sistemticas de pequenos


erros cometidos devido s falsas suposies so denominadas Adaptive Software
Development (ASD), e so consideradas a chave para o funcionamento dos seus
ciclos de especulao, colaborao e aprendizado (VALE, 2008a).
O termo Metodologias geis surgiu a partir de um manifesto criado por
dezessete profissionais veteranos na rea de software, representantes de diversas
metodologias, que se reuniram no ano de 2001 nos EUA para discutir o que havia
em comum entre estas metodologias. Esse manifesto foi chamado de Manifesto for
Agile Software Development, ou simplesmente Manifesto gil. Os participantes
deste manifesto foram: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor,
Ken Schwaber, Jeff Sutherland e Dave Thomas.
Segundo o Manifesto gil (AGILEALLIANCE, 2001):
Estamos evidenciando maneiras melhores de desenvolver software
fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse
trabalho, passamos a valorizar:
- Pessoas e interao MAIS QUE processos e ferramentas;
- Software em funcionamento MAIS QUE documentao abrangente;
- Colaborao com o cliente MAIS QUE negociao de contratos; e
- Responder a mudanas MAIS QUE seguir um plano.
Ou seja, mesmo tendo valor os itens direita, valorizamos mais os
itens esquerda.

As metodologias geis visam o auto-aperfeioamento. Nesse sentido, o


Manifesto gil (AGILEALLIANCE, 2001) afirma que um time de projeto deve refletir,
em intervalos regulares, sobre como ser mais efetivo, e assim afinar e ajustar seu
comportamento apropriadamente.
Um dos princpios do Manifesto gil diz que (AGILEALLIANCE, 2001) "as
Mudanas de requisitos so bem vindas, mesmo em estgios tardios do

29

desenvolvimento. Processos geis devem admitir mudanas que trazem vantagens


competitivas para o cliente".
Segundo Vale (2008b, p.22),
Projetos geis so semelhantes a campeonatos esportivos. Um
campeonato disputado jogo a jogo. Cada jogo ter uma histria
diferente e apresentar um resultado diferente. A equipe vencer se
conseguir focar em resultados, se adaptar com a realidade de cada
jogo e ao mesmo tempo aperfeioar sua forma de jogar ao longo do
campeonato. Projetos tradicionais esperam o campeonato terminar
para refletir e melhorar. O modelo gil, por outro lado, trata cada uma
de suas iteraes como as equipes esportivas tratam seus jogos. A
primeira atitude de um tcnico esportivo depois de um jogo reunir a
equipe para falar sobre os pontos positivos e negativos do ltimo
jogo. No contexto do modelo gil, tais reunies so chamadas de
Reunies de Retrospectiva.

De acordo com Cmara (2008, p. 19),


Mtodos geis so propostas incomuns de tcnicas para projetos de
software. XP, como o nome sugere, algo um pouco mais radical.
Propostas estranhas de tcnicas esquisitas fazem os gerentes de
projetos temerem utiliz-las em grandes projetos. Para atrapalhar
ainda mais as poucas iniciativas de se quebrar paradigmas, o
radicalismo de alguns pensadores de XP afastam a compreenso
sobre as reais vantagens e os benefcios para o negcio que
podemos alcanar com estes mtodos.

No Manifesto gil foram descritos 12 princpios que as metodologias de


desenvolvimento gil devem seguir (vide quadro abaixo).
Quadro 3: Princpios metodologias geis
Princpios
Descries
Satisfazer o cliente atravs de
Se um cliente necessita de um software de 10 mdulos, o
entregas iniciais e contnua de
manifesto gil prega que deve ser entregue para o cliente os
software que agregue valor
mdulos conforme ficarem prontos. Isso cria a possibilidade
quele.
do cliente comear a ter um retorno para o seu negcio mais
cedo, atravs desses mdulos prontos.
Aceitar mudanas nos requisitos Processos geis tm que serem abertos s mudanas para
mesmo que tarde no projeto.
que o cliente tenha vantagens competitivas.
Entregar software funcional
Quanto antes o cliente puder usar o software, antes ele ter
frequentemente.
condies de entender melhor as necessidades do negcio.
Preferencialmente em uma escala Assim possvel detectar mudanas mais cedo.
de tempo pequena.
Pessoas do negcio e
Isso ajuda os desenvolvedores a entender melhor as
desenvolvedores tm que
necessidades do negcio.
trabalhar juntos durante o projeto.

30

Construa projetos em torno de


indivduos motivados. D-lhes o
ambiente e o apoio que
necessitam, confie no trabalho
deles.
O mtodo mais eficaz e eficiente
de se comunicar com a equipe de
desenvolvimento o face-a-face.
Software que funcione a
primeira mtrica de progresso.

Ter pessoas motivadas no projeto potencializa a


probabilidade do projeto ser um sucesso.

Preferir comunicao verbal comunicao escrita.

Para evitar que o progresso do projeto seja medido por


atividades que no tenham um retorno direto para o negcio
do cliente. Muitas vezes os projetos j esto 60% prontos,
porm essa porcentagem somente o planejamento do
projeto, se o projeto for cancelado nessa etapa o cliente no
tem nenhum mdulo que funcione, ou seja, no tem nada
que realmente de retorno direto para o seu negcio.
Processos geis promovem
Os patrocinadores, desenvolvedores e usurios devem ser
desenvolvimento sustentvel.
capazes de manter um ritmo constante indefinidamente.
Ter ateno contnua para a
Obviamente, quanto melhor estruturado estiver o software,
excelncia tcnica e para os bons mais fcil ser alter-lo.
designs promovem a agilidade.
Simplicidade.
Sempre evite complexidade desnecessria. No insira
complexidade com o objetivo de suportar uma necessidade
futura, postergue a incluso da complexidade para quando a
necessidade futura chegar.
As melhores arquiteturas,
Equipes que se auto-organizam so equipes que esto
requisitos e designs surgem de
empenhadas no projeto, isso facilita a excelncia tcnica.
equipes que se auto-organizam.
Em intervalos regulares, a equipe A equipe pode fazer otimizaes na sua forma de trabalhar
reflete como ser mais eficiente,
para que o projeto se beneficie.
ento faz os ajustes necessrios.
Fonte: AGILEALLIANCE, 2001.

Com base nestes princpios, pode-se afirmar que os mtodos geis so


(AGILEALLIANCE, 2001):


Incrementais: pequenas verses e ciclos rpidos de desenvolvimento;

Cooperativos: estimulam a proximidade com o cliente e a interao entre os


programadores;

Diretos: aprendizado e documentao simplificada;

Adaptativos: acomodao hbil de mudanas durante o projeto.

3.1 CARACTERSTICAS DAS METODOLOGIAS GEIS

As metodologias geis tm como pontos fortes a frequente participao do

31

cliente e grande flexibilidade. De acordo com as bases das Metodologias geis, as


pessoas tm papel fundamental no desenvolvimento dos projetos, sendo que para
isso essencial que em todas as equipes exista uma boa comunicao e haja
motivao e preocupao de cada indivduo com a qualidade. O cliente passa a
fazer parte da equipe de desenvolvimento, uma vez que a todo o momento
questionado sobre prioridades e testes de verses. tambm frequentemente
chamado a intervir, iterao a iterao, tendo um papel decisivo na definio dos
novos requisitos, contrariando a prtica de quase tudo deve ser planificado e
acordado no inicio do projeto. Nenhum projeto totalmente previsvel, portanto ser
gil, ter conhecimento desta realidade e aceitar que os requisitos habitualmente
mudam.
Outras caractersticas importantes exibidas pela aplicao de metodologias
geis foram descritas por Neumann, Baureis e Stock (2009, p. 65):


Orientao ao valor proporcionado ao cliente;

Desenvolvimento das competncias individuais;

Times pequenos;

Autodisciplina sustentvel;

Intensa colaborao;

Reduzido custo de transferncia da informao;

Tempo reduzido para feedback;

Aprendizado e adaptao constantes.


Abaixo, so exibidos outros aspectos que tambm caracterizam os mtodos

geis (GERENCIAMENTO, 2009):




Estratgia de Negcio: Para ajudar a equipe preciso fazer com que ela
entenda do negcio que esta por trs do projeto. Por este motivo, muito
importante o conceito de responsabilidade de cada pessoa dentro da equipe
gil;

Gesto de Risco: Para analisar os riscos fazemos sempre suposies sobre o


futuro, sendo este o mais prximo possvel. No caso das equipes geis esse
plano de riscos feito para no mximo uma viso de duas semanas.
Normalmente feito semanalmente, ou por perodos curtos chamados de
sprints;

32

Estimativa de Tempo: Para estimar o tempo em equipes geis normalmente


trabalha-se uma semana para ver o progresso real, e ento pode-se entender
e calcular a velocidade semanal em cima de uma taxa de cada programador
ou membro da equipe, fazendo assim uma previso cientfica de quanto
tempo o trabalho ir levar;

Qualidade: Os testes so realizados imediatamente aps a realizao da


tarefa e no depois de tudo estar completo. Isso gera uma maior
dinamicidade, criando uma forma mais livre e um produto final j testado;

Comunicao: As reunies de controle demoram no mximo 15 minutos no


incio ou no final do dia. Podem receber a participao do cliente;

Motivao: Todos os membros da equipe gil participam do brainstorming e


kick-off do projeto, entendendo a importncia e reconhecendo de seus
respectivos deveres dentro da equipe. importante a ao continua de
motivao por parte do gerente de projeto, para que a equipe no tenha uma
queda de desempenho nos sprints;

Satisfao do cliente: Notamos que uma das coisas mais fceis de se atingir
nesse tipo de mtodo de gerenciamento a satisfao do cliente. Como o
mesmo est muito presente e participa ativamente das atividades do projeto,
e as entregas tm prazos menores, pode-se dizer que o cliente ter confiana
plena que o produto sair conforme ele deseja;

Fases de Transio: Ocorre quando libera-se uma verso de funcionalidades


para que possa ser testada e avaliada pelo cliente, e aprovada antes que a
equipe gil se mova ou transpasse para a prxima fase de desenvolvimento;

Lies Aprendidas: Em vez de se esperar at o final do projeto, possvel se


beneficiar com esses dados desde o incio do projeto, tendo-se como base os
sprints de trabalho. Fazendo-se isso, a garantia de sucesso e a rapidez para
tomadas de decises so aumentadas.

33

3.1.1 Caractersticas das Equipes geis

fundamental que algumas caractersticas estejam presentes entre as


pessoas de uma equipe gil. Estas caractersticas foram apresentadas por Toms
(2009, p. 6):


Competncia: independente da metodologia (gil ou tradicional) diz respeito a


talento inato, habilidades especficas relacionadas a software e a um
conhecimento global do processo que a equipe decidiu aplicar;

Foco comum: os membros podem ter diferentes competncias e habilidades,


mas todos eles devem ter o mesmo foco, que entregar um incremento de
software em funcionamento ao cliente dentro do prazo prometido;

Colaborao: a equipe precisa de colaborao entre si, com o cliente e com


os gerentes de forma a conseguir analisar, avaliar e usar/comunicar
informao de forma eficiente;

Capacidade de tomada de deciso: importante que a equipe tenha


autonomia para tomar decises de tpicos tcnicos e de projeto;

Habilidade de resolver problemas vagos: uma equipe gil lida continuamente


com ambiguidades e ser confrontada com modificaes. Os problemas que
resolvem num dia, podem no ser significantes numa fase posterior, porque
teve de se mudar a maneira de realizar algo. Contudo, a equipe aprendeu a
resolver aquele tipo de problema;

Respeito e confiana mtua: a equipe tem de funcionar como um todo;

Auto-organizao: a equipe organiza-se para o trabalho ser feito; a equipe


organiza o processo para melhor acomodar seu ambiente local; a equipe
organiza o cronograma de trabalho para conseguir melhorar a entrega do
incremento de software.

3.2 DIFERENAS ENTRE MTODOS GEIS E MTODOS CLSSICOS


A maioria das metodologias geis nada possui de novo em relao s
metodologias tradicionais. O que as diferencia das metodologias tradicionais
(clssicas) so o enfoque e os valores.

34

A principal idia das metodologias geis o enfoque nas pessoas e no em


processos, como a idia dos mtodos tradicionais, gastando assim menos tempo
com documentao e mais tempo com implementao. Dessa forma, as
metodologias geis so adaptativas ao invs de serem preditivas. Com isso, elas se
adaptam a novos fatores decorrentes do desenvolvimento do projeto, ao invs de
procurar analisar previamente tudo o que pode acontecer no decorrer do
desenvolvimento.
Portanto, a diferena primordial est em evitar os problemas j conhecidos de
tentar estimar e planejar software em detalhes, atividades que comprovadamente
falham. Junto a isso, somam-se os atrativos de se manter uma equipe mais
motivada e produtiva, envolver mais pessoas (como o cliente) na tomada de deciso
e focar em trabalhos que realmente agregam valor.
Segundo Bernardino, Gomes e Vasconcelos (2005) as metodologias geis
assim como as metodologias tradicionais possuem pontos fortes e pontos fracos. O
quadro abaixo apresenta uma comparao entre as metodologias geis e as
metodologias tradicionais em algumas reas principais.
Quadro 4: Comparao entre metodologias geis e tradicionais
Metodologias guiadas por
Principais reas
Metodologias geis
planejamento
Orientado ao planejamento,
gil,
voltado
ao
habilidades
adequadas,
Desenvolvimento
conhecimento, arranjado e
acesso ao conhecimento
colaborativo.
externo.
Dedicado,
voltado
ao
Acesso ao conhecimento,
conhecimento,
arranjado,
Clientes
colaborativo, representativo
colaborativo, representativo
e clientes com poder.
e com poder.
Largamente
emergentes, Conhecidos
previamente,
Requisitos
mudanas rpidas.
largamente estveis.
Projetada para requisitos Projetada para requisitos
Arquitetura
atuais.
atuais e futuros.
Refatorao
Barata.
Cara.
Tamanho
Pequenos times e produtos. Grandes times e produtos.
Objetivo primrio
Valor rpido.
Garantia elevada.
Fonte: Boehm, 2002 apud Bernardino, Gomes e Vasconcelos, 2005, p. 26.

35

3.3 DESENVOLVIMENTO RPIDO DE APLICATIVOS (SOFTWARES)


As metodologias e ferramentas de desenvolvimento rpido de aplicativos
(Rapid Application Development - RAD) permitem desenvolver sistemas de forma
muito mais rpida, especialmente aqueles sistemas onde a interface de usurio
representa um componente importante.
O processo RAD semelhante ao processo de prototipao. Ambos so
altamente repetitivos e do nfase velocidade de desenvolvimento. A prototipao
muitas vezes utiliza linguagens especializadas, tais como linguagens de quarta
gerao e geradores de tela, enquanto que os pacotes RAD incluem diferentes
ferramentas

com

recursos

semelhantes.

Com

as

ferramentas

RAD,

os

desenvolvedores aperfeioam e ampliam a verso inicial por meio de repeties


mltiplas at que ela esteja adequada para o uso operacional (TURBAN, MCLEAN,
WETHERBE, 2007).
As ferramentas trabalham juntas como parte do pacote integrado, produzindo
componentes funcionais para uma verso final do sistema, em vez de criar
simulaes ou verses em escala reduzida. Os produtos tpicos de RAD so
adequados ao desenvolvimento de uma grande variedade de plataformas, em
especial cliente/servidor, cada vez mais utilizada, e plataformas baseadas na Web
(TURBAN, MCLEAN, WETHERBE, 2007).
Alm dos benefcios de velocidade e portabilidade, o RAD usado para criar
aplicativos mais fceis de manter e modificar. No entanto, os pacotes de RAD
tambm apresentam algumas desvantagens, pois tal como na prototipao, se no
houver um critrio claro para concluir o processo repetitivo de desenvolvimento, ele
poder continuar indefinidamente. Os pacotes de RAD podem possuir recursos para
criar documentao do sistema, mas isso no garante que os desenvolvedores iro
produzir a documentao de boa qualidade (TURBAN, MCLEAN, WETHERBE,
2007).

36

3.4 Principais Metodologias geis


As metodologias geis apresentam uma srie de propostas geis, cada uma
delas possui peculiaridades e formas de encarar o desenvolvimento de software. As
principais metodologias geis para desenvolvimento de software sero descritas a
seguir.

3.4.1 Feature-Driven Development FDD

A FDD (Feature-Driven Development) dirigida pelas funcionalidades de


valor para o cliente. Seu diferencial que ela trabalha com diagramas de UML
coloridos auxiliando o entendimento desses pela equipe (FELSING, PALMER,
2002).

O FDD foi criado em 1999, em Cingapura, por um time liderado por


Jeff De Luca, que inclua tambm Tom De Marco, Tim Lister, Jerry
Weinberg e Frederic Brooks. Trata-se de um mtodo de
desenvolvimento de software especfico para aplicaes crticas e
est baseado em processos bem definidos que podem ser repetidos.
O FDD mais um mtodo de gerenciamento de software do que um
ciclo de vida de desenvolvimento de software propriamente dito
(DIAS, 2005, p. 71).

As caractersticas (features) so funes que o cliente valoriza e que podem


ser implementadas em menos de duas semanas, e tem um formato prprio para
serem descritas. H ento uma srie de fases at que se cumpra a realizao da
caracterstica.
Resumidamente, FDD dividido em 5 fases que explicam sua funo. So
elas, conforme descrito por Cmara (2008, p. 19):


Shape Modeling: uma forma de questionar se todos compreendem o que


para fazer, analisar requisitos no-funcionais e modelo de arquitetura;

Feature List: a representao do escopo listando a compreenso do que


para ser feito e os requerimentos a serem desenvolvidos;

37

Plan by subject area: a modularizao da lista em conjuntos de


funcionalidades relacionadas, permitindo o desenvolvimento de parte do
sistema autonomamente;

Design by feature set: uma orientao que determina o desenvolvimento


com base no domnio do problema. Sugere-se nesta fase uma modelagem
profunda e detalhada em UML;

Build by Chief Programmer Work Package: o empacotamento de pequenas


funcionalidades, uma reduo evolutiva que nasce na fase 2 at a fase 4.
Prioriza-se este pacote, codificando suas funcionalidades e criando unit tests.
A FDD define tambm 4 camadas de arquitetura de software, conforme

descrito por Cmara (2008, p. 19):




UI: User Interface;

PD: Problem Domain (lgica do negcio);

DM: Data Management;

SI: Systems Interfaces.


A FDD tem como caracterstica a arquitetura baseada em funcionalidade

(feature), onde cada funcionalidade definida com uma frmula simples, que
permite ser repetvel e confivel.
Ainda segundo o mesmo autor, frmula da funcionalidade tem a seguinte
estrutura: <action> <result> <object> (vide exemplo na figura abaixo).

Figura 1: Frmula funcionalidade FDD


Fonte: Camara, 2008, p.20.

38

3.4.2 Adaptative Software Development - ASD

O Adaptative Software Development ASD foi criado por Highsmith em 1992.


Trata-se de uma evoluo do Rapid Application Development - RAD, o qual foi
projetado para lidar com ambientes complexos e cheios de incertezas. O ASD
estimula o aprendizado durante o processo de desenvolvimento e a adaptao
constante a mudanas de negcio e do projeto, alm de encorajar o
desenvolvimento iterativo e incremental (IID) com a liberao constante de novas
verses (DIAS, 2005).
O ASD explicitamente orientado para componentes ao contrrio de
orientado a tarefas. Isso significa que o foco est mais em seus resultados e
qualidades que em tarefas e processos usados para produzir o resultado. A forma
que o ASD conduz isso atravs de ciclos de trs fases. Essas fases so:
Speculate (Especular): utilizado no lugar de Planejamento; Collaborate (Colaborar):
enfatiza a importncia da equipe desenvolver um software altamente altervel; Learn
(Aprender): reala a necessidade de reconhecer e reagir aos erros, e o fato que
requisitos tambm podem mudar durante o desenvolvimento (DIAS, 2005).
Segundo seu criador, o ASD indicado para equipes pequenas, mas pode
ser adaptado para equipes maiores.

3.4.3 Lean Development - LD

O Lean Development (LD) considerado o mtodo gil de maior foco


estratgico devido a suas origens estarem baseadas na indstria automotiva,
especialmente no Modelo Toyota de Produo. O LD derivado dos princpios de
produo enxuta, a qual reestruturou a indstria de automveis no incio de 1980.
Foi criado por Bob Charette e tem como principais objetivos a reduo de prazo,
custo e nvel de defeitos no desenvolvimento em um tero.
O LD composto por trs fases (DIAS, 2005), sendo:

39

Startup (inicial): nesta fase realizado o planejamento do desenvolvimento;

Steady state (estado fixo): nesta fase realizada a concepo do desenho do


software, composta de uma srie de ciclos pequenos de desenvolvimento;

Transition-renewal (transio-renovao): aps a entrega do produto, este


mantido em constante fase de renovao e transio. Nesta fase tambm
desenvolvida e entregue a documentao.

3.4.4 Scrum

O Scrum um processo gil que permite manter o foco na entrega de maior


valor de negcio, no menor tempo possvel. Isto permite a rpida e contnua
inspeo do software em produo.
O Scrum possui um processo bem definido com uma fase de planejamento e
de encerramento, conforme ilustrado na figura abaixo. Entre estas fases, h uma
fase chamada de Sprint, com durao de aproximadamente 4 semanas, que ocorre
vrias vezes durante o desenvolvimento do projeto. So as iteraes que
caracterizam as Metodologias geis. O Sprint como uma caixa preta onde ocorre o
desenvolvimento do produto.

Figura 2: Metodologia Scrum


Fonte: Agile Software Development with Scrum (BEEDLE, SCHWABER, 2002).

40

De acordo com Cmara (2008, p. 21),


SCRUM um mtodo de gerenciamento de software que pode ser
usado com XP ou MSF. baseado na teoria do controle emprico de
processos e seus fundamentos so originados na indstria de
manufatura japonesa. Ciclo de vida emprico um ciclo baseado na
observao dos fatos. Muitos gerentes de projetos no gostam do
mtodo reativo sugerido pelo SCRUM e preferem trabalhar com um
planejamento que na minha leitura um trabalho especulativo, pois
tenta prever uma seqncia de atividades lineares. Por mais que o
cronograma tenha um valor que o planejamento prvio, ou seja,
pensar antes de sair fazendo, perde muito em tentar prever
atividades distantes cheias de dependncias predecessoras e no
facilita o controle das mudanas de requisitos.

Cmara (2008, p. 21) afirma ainda que:


Segundo o SCRUM, o desenvolvimento deve ser trabalhado em 3
nveis: Sprint, Release e Product. O ponto central que os requisitos
so convertidos em uma lista que contm valores do cliente chamada
Product Backlog. Um subconjunto desta lista criado e chamado de
Release Backlog. Este subconjunto particionado mais uma vez
transformando-se em Sprint, uma espcie de acordo de
desenvolvimento de funcionalidades que aps aceito pela equipe no
deve ser mais alterado. Praticando SCRUM, o que mais chama a
ateno a simplicidade. Controlar projetos desta forma participar
de um jogo competitivo e saudvel em que todos se auto-avaliam
todos os dias (daily stand-up meeting) tornando possvel resultados e
tcnicas de melhoria contnua.

Scrum mantm

uma lista

de

funcionalidades

que

devero

ser

implementadas, essa lista chamada de Product Backlog. Para cada iterao ou


Sprint, feita uma reunio inicial de planejamento, chamada de Sprint Planning
Meeting, onde itens desta lista so priorizados pelo cliente, chamado no Scrum de
Product Owner. A equipe define quais funcionalidades podero ser atendidas dentro
da iterao de acordo com a capacidade da mesma. Essa lista planejada para a
iterao chamada de Sprint Backlog (SCHWABER, 2004).
Diariamente, durante o Sprint, a equipe faz uma reunio chamada de Daily
Meeting que ajuda a manter a comunicao do time sobre o andamento do projeto,
disseminar conhecimento e identificar possveis impedimentos. No final de cada
Sprint, na reunio chamada Sprint Review, a equipe apresenta as funcionalidades
que foram concludas durante o Sprint.

41

Ao final do Sprint deve sair um produto com valor agregado, ou seja, feito
um incremento no produto. Esse ciclo se repete vrias vezes at que o Product
Backlog seja todo atendido. A figura abaixo representa o ciclo do Sprint.

Figura 3: Ciclo do Sprint


Fonte: Agile Software Development with Scrum (BEEDLE, SCHWABER, 2002).

O Scrum possui 3 grupos de fases: Pregame; Game; e Postgame, tendo


ainda atividades para cada uma destas fases (CAMARA, 2008).
Quanto aos papis e responsabilidades do Scrum, este define basicamente
apenas 3 papis: Product Owner; Scrum Master; e Scrum Team (CAMARA, 2008).
As caractersticas de cada um desses papis so descritas a seguir:


Product Owner: Traduzido literalmente significa Dono do Produto. o cliente


do projeto, tipicamente um usurio chave que representa os interesses de
todos os envolvidos com o software (SCHWABER, 2004). quem define e
prioriza as funcionalidades que compem o Product Backlog. Deve estar
acessvel

equipe,

tem

a responsabilidade

de

no trazer

novas

funcionalidades durante o Sprint e de fazer a validao do produto ao final de


cada Sprint.


Scrum Team: a Equipe responsvel pelo desenvolvimento do produto de


acordo com as prioridades definidas pelo Product Owner. No h uma
definio de papis formal como programador, testador, arquiteto ou analista,

42

o que no impede que haja estas funes. Todos trabalham juntos para
completar as funcionalidades que todos conjuntamente se comprometeram
para o Sprint. A equipe deve ser idealmente pequena, de 5 a 9 pessoas,
porm pode ser maior (BEEDLE, SCHWABER, 2002).


Scrum Master: o papel do gerente do projeto, mas pode ser exercido por
qualquer membro da equipe. Responsvel por garantir o trabalho da equipe
atravs da remoo de obstculos identificados e da proteo da equipe
contra interferncias externas. Deve disseminar e aplicar os valores e prticas
do Scrum na equipe.
Os principais artefatos definidos pelo Scrum so o Product Backlog, que a

lista de funcionalidades definidas pelo Product Owner. O Sprint Backlog que uma
lista dos itens do Product Backlog que foram priorizados para serem atendidos no
Sprint. E o Burndown Chart que consiste de um grfico para acompanhamento dirio
do Sprint quanto velocidade do time pelo consumo dirio de horas.
No que se refere ao planejamento, execuo e controle do Sprint, preciso
observar que durante o Sprint cada funcionalidade do software trabalhada de
forma a ser completada dentro do mesmo Sprint. Em se tratando de software, a
funcionalidade planejada, projetada, codificada e testada gerando software
funcionando. O tamanho do Sprint, de 2 a 4 semanas, uma vez estabelecido no
deve ter a data final alterada para que as mtricas de velocidade do time sejam
consistentes (SCHWABER, 2004).

3.4.5 Extreme Programming - XP

Extreme Programming (XP) consiste em um processo de desenvolvimento de


software voltado para (TELES, 2009):


Projetos cujos requisitos so vagos e mudam com freqncia;

Desenvolvimento de sistemas orientados a objeto;

Equipes pequenas, preferencialmente at 12 desenvolvedores;

43

Desenvolvimento incremental (ou iterativo), onde o sistema comea ser


implementado logo no incio do projeto e vai ganhando novas funcionalidades
ao longo do tempo.
O XP visa assegurar que o cliente receba o mximo de valor de cada dia de

trabalho da equipe de desenvolvimento, sendo organizado atravs de um conjunto


de valores e prticas que atuam harmonicamente para garantir que o cliente sempre
receba um alto retorno do investimento em software.
De acordo com Bernardino, Gomes e Vasconcelos (2005) o XP possui as
seguintes caractersticas:


A maioria das regras do XP causa polmica primeira vista e muitas no


fazem sentido se aplicadas isoladamente. a sinergia de seu conjunto que
sustenta o sucesso do XP, encabeando uma verdadeira revoluo no
desenvolvimento de software.

O XP enfatiza o desenvolvimento rpido do projeto e visa garantir a satisfao


do cliente, alm de favorecer o cumprimento das estimativas. As regras,
prticas e valores do XP proporcionam um agradvel ambiente de
desenvolvimento de software para os seus seguidores, que so conduzidos
por quatro valores: comunicao, simplicidade, feedback e coragem.
O quadro a seguir apresenta as consideraes sobre os quatro valores

(comunicao, simplicidade, feedback e coragem) de acordo com a metodologia XP,


baseado na reviso de literatura de dois autores.
Quadro 5: Valores da metodologia XP
Bernardino, Gomes e Vasconcelos, Teles, 2009
Valor
2005
Para que o cliente possa
compartilhar
o
seu
A
finalidade
do
princpio
da aprendizado com a equipe,
comunicao manter o melhor necessrio que ele utilize
relacionamento possvel entre clientes permanentemente o valor da
e
desenvolvedores,
preferindo comunicao. A comunicao
Comunicao
conversas pessoais a outros meios de entre o cliente e equipe
comunicao. A comunicao entre os permite que todos os detalhes
desenvolvedores e o gerente do do projeto sejam tratados com
projeto tambm encorajada.
ateno e a agilidade que
merecem. O XP procura
assegurar que a comunicao

44

Simplicidade

A simplicidade visa permitir a criao


de cdigo simples que no deve
possuir funes desnecessrias. Por
cdigo
simples
entende-se
implementar o software com o menor
nmero possvel de classes e
mtodos. Outra idia importante da
simplicidade procurar implementar
apenas requisitos atuais. A aposta do
XP que melhor fazer algo simples,
hoje e pagar um pouco mais amanh
para fazer modificaes necessrias
do que implementar algo complicado
hoje que talvez no venha a ser
usado, sempre considerando que
requisitos so mutveis.

Feedback

A prtica do feedback constante


significa que o programador ter
informaes constantes do cdigo e
do cliente. A informao do cdigo
dada pelos testes constantes, que
indicam os erros tanto individuais
quanto do software integrado. Em
relao ao cliente, o feedback
constante significa que ele ter
frequentemente uma parte do software
totalmente funcional para avaliar. O
cliente ento, constantemente, sugere
novas caractersticas e informaes

ocorra da forma mais direta e


eficaz possvel. Sendo assim,
ele busca aproximar todos os
envolvidos do projeto de modo
que
todos
possam
se
comunicar face-a-face ou da
forma mais rica que for vivel.
necessrio que a equipe
compreenda e utilize o valor
da simplicidade, que nos
ensina a implementar apenas
aquilo que suficiente para
atender a cada necessidade
do cliente. Ou seja, ao
codificar uma funcionalidade
preciso se preocupar apenas
com os problemas de hoje e
deixar os problemas do futuro
para o futuro. No se deve
tentar prever o futuro, pois
raramente as previses sero
acertadas. Ao evitar especular
sobre o que acontecer
amanh, ganha-se tempo e
permite-se que o cliente tenha
acesso funcionalidade mais
rapidamente. Isso permite que
o cliente utilize o software em
seu negcio, gerando valor
para ele e tornando vivel que
ele d feedback para a equipe
o
quanto
antes.
Eventualmente, com base no
feedback, a equipe poder
fazer generalizaes quando
elas se fizerem necessrias.
Neste caso, entretanto, elas
viro na forma de uma
necessidade explcita e no
como a especulao de algo
que poderia vir a ser
necessrio no futuro.
Quando o cliente aprende
com o sistema que utiliza e reavalia as suas necessidades,
ele gera feedback para a
equipe de desenvolvimento.
Isto , ele realimenta a equipe
com
alteraes
nas
necessidades que ainda sero
implementadas
e,
eventualmente, naquela que
fazem parte do software. O
feedback o mecanismo
fundamental que permite que

45

aos desenvolvedores. Eventuais erros


e no conformidades so rapidamente
identificados e corrigidos nas prximas
verses. Desta forma, a tendncia
que o produto final esteja de acordo
com as expectativas reais do cliente.

Coragem

necessrio
coragem
para
implementar os trs valores anteriores.
Por exemplo/; no so todas as
pessoas que possuem facilidade de
comunicao
e
tm
bom
relacionamento. A coragem tambm
d suporte simplicidade, pois assim
que a oportunidade de simplificar o
software percebida, a equipe pode
experimentar. Alm disso, preciso
coragem
para
obter
feedback
constante do cliente.

o
cliente
conduza
o
desenvolvimento diariamente
e garanta que a equipe
direcione as suas atenes
para aquilo que ir gerar mais
valor.
Dado que o sistema
desenvolvido
de
forma
incremental, a equipe est
continuamente fazendo a
manuteno do software e
criando
novas
funcionalidades. Em muitos
casos, ela ir alterar algo que
vinha
funcionando
corretamente, o que leva ao
risco de gerar falhas no
sistema. Por esta razo, a
equipe precisa ser corajosa e
acreditar que, utilizando as
prticas e valores do XP, ser
capaz de fazer o software
evoluir com segurana e
agilidade.

Fonte: Adaptao do pesquisador.

O XP se baseia em 13 prticas (TELES, 2009):




Cliente Presente;

Jogo do Planejamento;

Stand Up Meeting;

Programao em Par;

Desenvolvimento Guiado pelos Testes;

Refactoring;

Cdigo Coletivo;

Cdigo Padronizado;

Design Simples;

Metfora;

Ritmo Sustentvel;

Integrao Contnua;

Releases Curtos.
O quadro abaixo apresenta as principais caractersticas de cada uma das

prticas do XP.

46

Quadro 6: Prticas do XP
Prtica
Descrio
O XP trabalha com a premissa de que o cliente deve conduzir o
desenvolvimento a partir do feedback que recebe do sistema.
Para que a troca de feedback possa ocorrer e o cliente possa
Cliente presente
obter o mximo de valor do projeto, essencial que ele participe
ativamente do processo de desenvolvimento.
Alm disso, a sua presena viabiliza a simplicidade do processo
em diversos aspectos, especialmente na comunicao.
O XP utiliza diversas formas de planejamento para assegurar que
a equipe esteja sempre trabalhando naquilo que o mais
importante para o cliente. Por esta razo, todo projeto em XP
dividido em releases e iteraes, de modo que cliente e equipe
tenham diversas oportunidades de se reunir para revisar o
planejamento.
Releases so mdulos do sistema que geram um valor bem
definido para o cliente. Iteraes, por sua vez, so perodos de
tempo de poucas semanas (em torno de duas, em mdia) no qual
a equipe implementa um conjunto de funcionalidades acordado
com o cliente. No incio de cada release e de cada iterao
ocorre o jogo do planejamento. Trata-se de uma reunio onde o
Jogo do planejamento
cliente avalia as funcionalidades que devem ser implementadas e
prioriza aquelas que faro parte do prximo release ou da
prxima iterao.
No XP, as funcionalidades so descritas em pequenos cartes e
so chamadas de estrias. Durante o jogo do planejamento as
estrias so estimadas, para que o cliente possa conhecer o
custo da implementao de cada uma delas. A estimativa feita
utilizando-se uma unidade especial que recebe o nome de ponto.
O ponto representa uma unidade de tempo que varia ao longo do
desenvolvimento de acordo com a velocidade da equipe, onde a
velocidade indica o quanto a equipe foi capaz de implementar na
iterao anterior.
A equipe de desenvolvimento se rene a cada manh para
avaliar o trabalho que foi executado no dia anterior e priorizar
Stand Up Meeting
aquilo que ser implementado no dia que se inicia. Trata-se de
uma reunio rpida que recebe o nome de stand up meeting, que
em ingls significa reunio em p.
No XP, os desenvolvedores implementam as funcionalidades em
pares, ou seja, diante de cada computador, existem sempre dois
desenvolvedores que trabalham juntos para produzir o mesmo
cdigo. Esta prtica, que recebe o nome de programao em par
Programao em par
permite que o cdigo seja revisado permanentemente, enquanto
construdo. Tambm contribui para que a implementao seja
mais simples e eficaz, j que os desenvolvedores se
complementam e tm mais oportunidades de gerar solues
inovadoras.
O XP destinado construo de sistemas com alta qualidade, o
que leva necessidade de diversos mecanismos de validao
para assegurar que o software est correto. Um destes
Desenvolvimento
mecanismos a programao em par, tal como foi citado
guiado pelos testes
anteriormente. Alm dela, o XP tambm utiliza a tcnica de
desenvolvimento guiado pelos testes.
Os desenvolvedores escrevem testes para cada funcionalidade

47

Refactoring

Cdigo coletivo

Cdigo padronizado

Design simples

Metfora

Ritmo sustentvel

antes de codific-las. Fazendo isso, eles aprofundam o


entendimento das necessidades do cliente (o que aprimora a
anlise), se preocupam com as interfaces externas dos mtodos
e classes antes de codific-los (o que melhora o design), sabem
at onde codificar cada funcionalidade (o que ajuda a manter o
sistema simples) e passam a contar com uma massa de testes
que pode ser usada a qualquer momento para validar todo o
sistema.
Para que o sistema possa evoluir de forma incremental, a equipe
deve fazer com que ele expresse os seus objetivos facilmente e
esteja sempre claro e fcil de compreender. Freqentemente,
isso levar a equipe a modificar partes do sistema que estejam
funcionando para facilitar a sua manuteno.
O refactoring o ato de alterar um cdigo sem afetar a
funcionalidade que ele implementa. utilizado para tornar o
software mais simples de ser manipulado e se utiliza fortemente
dos testes descritos anteriormente para garantir que as
modificaes no interrompam o seu funcionamento.
No XP o sistema no segmentado em partes, de modo que
cada desenvolvedor fique responsvel por uma delas. Os
desenvolvedores tm acesso a todas as partes do cdigo e
podem alterar aquilo que julgarem importante sem a necessidade
de pedir autorizao de outra pessoa, pois o cdigo coletivo.
Isso fornece maior agilidade ao processo e cria mais um
mecanismo de reviso e verificao do cdigo, j que aquilo que
escrito por um par hoje, acaba sendo manipulado por outro
amanh. Se alguma coisa estiver confusa no cdigo, o par
dever fazer refactoring para torn-lo mais legvel.
Para que todos os desenvolvedores possam manipular qualquer
parte do software de forma mais rpida, a equipe estabelece
padres de codificao, que servem tambm para tornar o
sistema mais homogneo e permitir que qualquer manuteno
futura seja efetuada mais rapidamente.
Para que o cliente possa obter feedback logo, a equipe precisa
ser gil no desenvolvimento, o que a leva a optar pela
simplicidade do design. Ao invs de criar generalizaes dentro
do cdigo, de modo a prepar-lo para possveis necessidades
futuras, a equipe deve sempre optar por um cdigo que seja
suficiente para atender s necessidades da funcionalidade que
est implementando.
Os desenvolvedores se baseiam na premissa de que sero
capazes de incorporar qualquer necessidade futura quando e se
ela surgir. Para isso, eles contam com o refactoring, os testes e
as demais prticas do XP para apoi-los.
Para facilitar a criao de um design simples, a equipe de
desenvolvimento utiliza metforas, j que elas tm o poder de
transmitir idias complexas de forma simples, atravs de uma
linguagem comum que estabelecida entre a equipe de
desenvolvimento e o cliente.
A qualidade do design, do cdigo, das metforas e do sistema
determinada diretamente pela qualidade dos desenvolvedores e a
capacidade que eles tm de se manter atentos, criativos e
dispostos a solucionar problemas. Para garantir que a equipe
tenha sempre o mximo de rendimento e produza software com

48

melhor qualidade possvel, o XP recomenda que os


desenvolvedores trabalhem apenas oito horas por dia e evitem
fazer horas-extras, visto que essencial estar descansado a
cada manh, de modo a utilizar a mente na sua plenitude ao
longo do dia.
Quando uma nova funcionalidade incorporada ao sistema, ela
pode afetar outras que j estavam implementadas. Para
assegurar que todo o sistema esteja sempre funcionando de
forma harmoniosa, a equipe pratica a integrao contnua que
leva os pares a integrarem seus cdigos com o restante do
sistema diversas vezes ao dia. Cada vez que um par faz isso, ele
executa todos os testes para assegurar que a integrao tenha
ocorrido de forma satisfatria.
Uma integrao sempre pode produzir erros no sistema. Sendo
assim, a equipe utiliza os testes para descobrir eventuais defeitos
o mais rapidamente possvel j que descobri-los logo facilita e
acelera a correo e diminui a probabilidade de pequenos
problemas se transformarem em grandes dores de cabea no
futuro.
Como explicado anteriormente, o XP tem como objetivo gerar um
fluxo contnuo de valor para o cliente. Sendo assim, ele trabalha
com releases curtos, ou seja, a equipe produz um conjunto
reduzido de funcionalidades e coloca em produo rapidamente
de modo que o cliente j possa utilizar o software no dia-a-dia e
se beneficiar dele. Durante todo o projeto, a equipe colocar o
sistema em produo diversas vezes, cada vez incorporando
mais funcionalidades e gerando mais valor.

Integrao contnua

Realises curtos

Fonte: Teles, 2009, adaptao do pesquisador.


Uma equipe que utiliza o XP geralmente composta por pessoas que
representam os seguintes papis (TELES, 2009):


Gerente de projeto;

Coach;

Analista de teste;

Redator tcnico;

Desenvolvedor.
O

quadro

abaixo

apresenta

as

caractersticas

de

cada

uma

das

caractersticas da equipe.
Quadro 7: Caractersticas da equipe
Funo
Descrio
O gerente de projeto responsvel pelos assuntos
administrativos do projeto. Ele procura liberar a equipe de
questes que no estejam diretamente ligadas atividade diria
Gerente de projeto
de desenvolvimento. Alm disso, administra o relacionamento
com o cliente assegurando que o mesmo participe ativamente do

49

desenvolvimento e fornea as informaes essenciais para que a


equipe possa implementar o sistema desejado.
O coach o responsvel tcnico do projeto. O XP recomenda
que um profissional tecnicamente bem preparado seja destacado
para orientar a equipe de modo que ela siga as boas prticas
Coach
recomendadas pelo XP. Embora tambm possa atuar na
implementao do sistema, sua tarefa principal assegurar o
bom funcionamento do processo e buscar formas de melhor-lo
continuamente.
O analista de teste responsvel por ajudar o cliente a escrever
os testes de aceitao. Quando estes testes no so
automatizados, o analista de teste deve fazer com que eles sejam
executados diversas vezes ao longo das iteraes do projeto. Ele
Analista de teste
procura fazer com que os eventuais defeitos do sistema sejam
identificados to logo apaream. Desta forma, fornece feedback
para a equipe rapidamente, de modo que ela possa fazer as
correes com rapidez e evitar que os problemas se propaguem.
O redator tcnico ajuda a equipe de desenvolvimento a
documentar o sistema. A sua presena permite que os
desenvolvedores
se
concentrem
prioritariamente
na
Redator tcnico
implementao do software. Embora eles possam continuar
fazendo algumas documentaes, o redator tcnico quem faz a
maior parte do trabalho de documentao.
O desenvolvedor a pessoa que analisa, projeta e codifica o
sistema. Em suma, a pessoa que efetivamente constri o
Desenvolvedor
software. Dentro do XP, no existem divises entre analista,
projetista, programador etc. Cada desenvolvedor exerce estes
diferentes papis em diversos momentos do projeto.
Fonte: Teles, 2009, adaptao do pesquisador.

No que se refere ao processo do XP, como demonstra a figura abaixo existem


duas grandes fases: Explorao e Manuteno; Na fase de Explorao, as Estrias
so ditas e documentadas e a arquitetura desenvolvida. Na fase de Manuteno,
ocorre todo o processo de desenvolvimento (programao) em uma srie de
iteraes at a entrega do produto.

50

Figura 4: Processo do XP

Figura 5: Iterao com o XP

Os passos gerais nas iteraes do XP so: planejamento, projeto, codificao


e testes. Estes quatros passos sero alternados constantemente entre eles.

3.4.6 Comparativo dos Mtodos geis

Strode (2005), em seu estudo apresenta um comparativo entre as seguintes


metodologias DSDM, XP, Scrum e Crystal (vide quadro abaixo).

51

Quadro 8: Tcnicas e metodologias


Tcnica

DSDM

XP

Desenvolvimento Concorrente

Scrum

Crystal

Desenvolvimento Iterativo

Desenvolvimento Incremental

Prottipo Evolucionrio

Produtos de Softwares
releases pequenos

com

Testes antes do desenvolvimento


Integrao
completo

diria

do

sistema

Testes automticos de regresso

Refatorao do cdigo

Testes atravs das iteraes

Programao em par

Equipe trabalhando na mesma


sala ou andar

Cdigo de acordo com um padro

Cdigo coletivo

Daily team meetings

Iteration planning meeting

Planning game

Reflective workshops

User stories

Metforas

Design mais simples possvel

Product Backlog

Sprint Backlog

Release Backlog

Milestones
desempenho

para

Regras MOSCOW
Fonte: Strode, 2005.

verificar

x
x

3.5 LIMITAES NO EMPREGO DOS MTODOS GEIS

O trabalho de Dias (2005, p. 88-89) agrupa o estudo e descrio de um

52

conjunto de limitaes para o emprego das metodologias geis. Dentre as limitaes


pesquisadas por ela, uma das maiores dificuldades para a adoo de metodologias
geis no desenvolvimento de software est relacionada ao suporte a equipes
distribudas, pois a comunicao facilitada quando a equipe de desenvolvimento e
o cliente esto prximos. Quando o trabalho realizado em localidades diferentes, o
uso de documentao formal passa a ser necessrio.
Outra limitao encontrada diz respeito ao tamanho da equipe de trabalho.
Quando a equipe muito grande, no caso de projetos grandes e complexos, tendese a aumentar tambm a complexidade da comunicao, tornando o processo
menos gil. Portanto, o tamanho da equipe acaba por restringir a eficincia da
comunicao face a face, tendendo tambm ao aumento de documentao.
A questo do reuso de artefatos tambm limitante para o uso dos mtodos
geis, visto que a premissa de documentao mnima dificulta a reutilizao dos
artefatos que tem como foco o desenvolvimento de solues para problemas muitos
especficos e no de cdigos genricos e reutilizveis.
Outro ponto negativo para a utilizao dos mtodos geis sua adoo no
desenvolvimento de projetos de Sistemas Crticos. Como estes sistemas exigem que
todos os seus componentes sejam exaustivamente testados e projetados de forma a
no haver falhas que impossibilitem seu uso seguro, os pressupostos relacionados
documentao e garantia de qualidade dos mtodos geis no so vlidos. Aqui
necessria a especificao formal, os testes intensivos e demais tcnicas de anlise
dos mtodos clssicos de desenvolvimento de software. Esta uma das razes para
que os mtodos geis no se sobreponham totalmente ao desenvolvimento clssico
de software, pois os sistemas crticos devem passar por um rgido controle de
qualidade.
E como item final, as metodologias geis no so indicadas para softwares
com milhes de linhas de cdigo e alto grau de interao entre os componentes,
pois estes projetos requerem grande esforo de gerenciamento e controle, alm de
processos estruturados e formais que garantam o entendimento do software.

53

3.6 DESVANTAGENS DOS MTODOS GEIS

Uma desvantagem apontada aos mtodos geis o fato de estes no serem


escalveis. Estes mtodos no foram desenhados para projetos muito longos,
existindo contudo a abordagem Scrum.
Outra desvantagem dos mtodos geis um menor controle de custos e
prazos. Nestas metodologias o projeto termina quando o cliente no levantar mais
funcionalidades relevantes que deseje ver concretizadas, em oposio a ser
acordado um preo e um plano. Com isso, os custos e prazos (duraes) podem
variar e podem ser de difcil gesto para o gestor do projeto, alm de causarem um
certo risco na viso do cliente (TOMAS, 2009).

3.7 VANTAGENS DOS MTODOS GEIS

As entregas constantes constituem a principal vantagem da utilizao das


metodologias geis nos projetos de desenvolvimento de software. Outras vantagens
so a integrao e o teste contnuo, pois possibilitam a melhora na qualidade do
software, no sendo mais necessrio existir uma fase de integrao de mdulos,
uma vez que eles so continuamente integrados e eventuais problemas so
identificados e resolvidos constantemente devido aos testes contnuos.
Uma outra vantagem das metodologias geis est centrada no aumento do
controle por parte dos gestores, uma vez que se baseia no que est realmente
sendo produzido e no que vai ser feito a curto prazo. Desta forma, h mais
visibilidade e adequao das medies e avaliaes do estado das funcionalidades
e tarefas realizadas (TOMAS, 2009). Este mtodo aproxima os desenvolvedores e
gestores pois existe uma maior e melhor comunicao. especialmente adequado
para projetos direcionados para a Web, onde os requisitos vo evoluindo e no se
exigem muitos trabalhadores.

54

Como as equipes geis so pequenas, os membros da equipe no


competem, pois geralmente devem ter habilidades e atribuies complementares
entre si. As equipes geis tende a se empenham juntas nas atividades como
definies de trabalho, tomadas de deciso, apresentao para os clientes e
retrospectivas. Ainda que a maioria desse trabalho conjunto possa potencialmente
incentivar um clima de competio, a abordagem gil favorece o que diversos
autores chamam de "conflito produtivo" em que as equipes tm reunies
interessantes e animadas, extraem e exploram ideias de todos os membros da
equipe e minimizam questes polticas.
Outros pontos fortes dos mtodos geis so o desenvolvimento de
comprometimento e responsabilidade. Prticas geis recomendam fortemente que
todas as coisas sejam dirigidas e estejam sob controle da equipe, e o progresso e o
sucesso podem ser meramente medidos pelo grau de envolvimento que tenha sido
experimentado pela equipe. E como o trabalho de cada membro da equipe fica
visvel, cria-se uma responsabilizao pessoal pelo trabalho em equipe e no por
presso superior.

55

4 GERENCIAMENTO GIL DE PROJETOS

A gerncia de projetos de software no sempre to fcil como parece. As


tcnicas de gerncia tradicionais de projeto so incapazes de adaptar-se bem s
mudanas e aos novos riscos. Isto faz com que as equipes tenham cada vez mais
dificuldades para reagirem rapidamente s mudanas intrnsecas ao processo de
desenvolvimento de software.
Para isto, as novas tcnicas com mtodos geis podem tornar mais fcil a
gesto de gerentes de projeto e equipes, desde que executadas corretamente.
Diferentes tipos de problemas e desafios possuem caractersticas diferenciadas que
requerem diferentes tipos de abordagens. O maior desafio est em selecionar,
adaptar e integrar estas abordagens, de acordo com as caractersticas presentes em
um determinado ambiente.
Os projetos de desenvolvimento de software possuem duas vertentes: uma
tcnica e outra gerencial, sendo que durante muitos anos a ateno voltou-se para o
aprimoramento de modelos de desenvolvimento (nfase tcnica), ficando o
componente gerencial relegado ao segundo plano.
Alguns autores, como Highsmith apud Dias (2005), mencionam que o
gerenciamento clssico de projetos no se mostrou plenamente efetivo para projetos
de desenvolvimento de software, devido a estes projetos estarem inseridos em
ambientes extremamente dinmicos, sujeitos a mudanas constantes, fugindo assim
aos padres do gerenciamento clssico de projetos.
Desta

forma,

alternativa

de

gerenciamento

deu-se

atravs

do

Gerenciamento gil de Projetos. Highsmith apud Dias (2005) indica a utilizao do


gerenciamento gil para projetos de software que requerem inovao e criatividade
ou que estejam sujeitos a constantes alteraes de requisitos. E em determinadas
situaes, uma combinao do enfoque clssico com as prticas propostas pelo
gerenciamento gil muito apropriada para o alcance de resultados mais efetivos.

56

4.1 O QUE GERENCIAMENTO GIL DE PROJETOS?

O movimento para o desenvolvimento gil de software estendeu-se para o


gerenciamento de projetos, dando origem ao Gerenciamento gil de Projetos com
base nos mesmos valores e princpios dos mtodos geis. Tratando-se de uma nova
plataforma de gerenciamento de projetos, o Gerenciamento gil um modelo
aplicvel a ambientes volteis e desafiadores, sujeitos a mudanas frequentes, onde
o processo padronizado (gerenciamento clssico) no mais adequado (DIAS,
2005).
O gerenciamento gil busca o desenvolvimento da viso do futuro e da
capacidade de explorao, desfazendo-se da postura clssica de gerenciamento,
calcada em planejamento prvio de aes e atividades. Neste sentido, o
Gerenciamento gil de Projetos assume o papel de resposta em mbito gerencial s
presses por inovao, concorrncia acirrada, necessidade de reduo de ciclos de
desenvolvimento, implantao de novos produtos e servios e necessidade de
adaptao a um ambiente de negcio bastante dinmico (DIAS, 2005).
Os valores desse novo modelo de gerenciamento foram citados por Dias
(2005, p.96):


As respostas s mudanas so mais importantes que o surgimento de um


plano;

A entrega de produtos est acima da entrega de documentao;

Priorizao da colaborao do cliente sobre a negociao de contratos;

Os indivduos e s interaes so mais importantes que os processos e as


ferramentas.

4.2 CARACTERSTICAS DOS PROJETOS PARA UTILIZAO DO


GERENCIAMENTO GIL

O fato dos mtodos geis de desenvolvimento e do gerenciamento gil de

57

projetos terem a mesma origem e estarem construdos sobre os mesmos princpios,


sugere que, possivelmente, o Gerenciamento gil de Projetos seja mais indicado
para o gerenciamento de projetos de software realizados com o uso dos mtodos
geis. Entretanto, no foram encontradas evidncias que comprovem ou reneguem
tal afirmao na reviso bibliogrfica. Apenas consenso entre os autores do
assunto, que deve ser realizada uma anlise do ambiente interno (aspectos
organizacionais e culturais) e do contexto externo no qual o projeto est inserido,
para que se selecione o modelo de gerenciamento de projetos (clssico ou gil) e se
defina o mtodo de desenvolvimento (clssico ou gil).
O consenso entre os autores da rea de que em projetos em que h muitas
mudanas, em que os requisitos so passveis de alteraes, onde refazer partes do
cdigo no uma atividade que apresenta alto custo, as equipes so pequenas, as
datas de entrega do software so curtas e o desenvolvimento rpido fundamental,
no podem haver requisitos estticos, necessitando ento de metodologias geis.
Para projetos que se encaixam nestas caractersticas, os processos de
desenvolvimento e gerenciamento devem ser flexveis para serem adaptados a
diversas situaes. Isso para que ao final, seja feita a entrega de um produto com
qualidade, validado e de acordo com o que foi solicitado.

4.3 COMPARAO ENTRE GESTO CLSSICA E GESTO GIL DE


PROJETOS

O quadro abaixo exibe uma comparao entre a gesto clssica e a gesto


gil de projetos.
Quadro 9: Comparao gesto clssica e gesto gil
Gesto Clssica
Prazo, Custo e Qualidade
Objetivos
Funes
Gerenciamento
Fundamento Terico

Gesto gil
Prazo, Custo, Qualidade e
Capacidade de Transformao
e Suporte

do Planejamento,
Controle
Tomada de Deciso
Mecanicismo:
Diviso
do Projeto como um
Trabalho,
Especializao
e Complexo Adaptativo
Controle

Sistema

58

Meio Ambiente

Relativamente
Estvel
Previsvel
Centralizada e Hierrquica

e Turbulento e Imprevisvel

Descentralizada:
Times
Pequenos e Semiautnomos
Restrito: Gestores possuem as Aberto: Informao Domnio
Acesso s Informaes
Informaes
Comum
Controle
Restrito e Centralizado
Baixo e Descentralizado
Centralizada no Gerente
Descentralizada
nos
Times
Responsabilidade
Semiautnomos
Aprendizado
Restrito
Contnuo e Adaptativo
Capacidade
de Baixa
Elevada
Adaptao
Estrutura Formal

Fonte: Neumann, Baureis, Stock, 2009, p. 65.

O gerenciamento clssico de projetos est baseado no planejamento


detalhado do projeto e nos processos formais de monitoramento e controle. Em
contrapartida, o gerenciamento gil enfatiza a execuo, objetivando uma entrega
mais rpida para o cliente e resultados durante todo o projeto (DIAS, 2005).

4.4 FATORES CRTICOS DE SUCESSO PARA O GERENCIAMENTO GIL

A aplicao do gerenciamento gil no trivial. Entre seus pr-requisitos mais


importantes encontra-se a mudana cultural da organizao. Do lado gerencial,
agilidade implica na absteno do gerente em decises do time. Do lado dos
membros, assumir a responsabilidade pelas decises tomadas imprescindvel. A
estrutura organizacional passa a ser determinante e estruturas mecanicistas tornamse inadequadas. O cliente passa a integrar o time sendo que contratos perdem em
significado. prefervel a evoluo iterativa do projeto com a participao ativa do
cliente, a longas fases baseadas em especificaes extremamente detalhadas
(NEUMANN, BAUREIS, STOCK, 2009).

59

5 CONCLUSO

Com a elaborao deste estudo concluiu-se que as metodologias geis


buscam estabelecer novos paradigmas para o desenvolvimento de software, onde o
desenvolvimento gil do software o foco principal. As metodologias geis visam
simplicidade na implementao de um projeto, pois suas regras so simples de
serem seguidas. E o sucesso na adoo de um modelo gil est diretamente
relacionado ao comprometimento do time, pois sua forma de conduo dos
trabalhos possui um elevado grau de informalidade.
O discurso trazido pelas metodologias geis leve e visa uma reduo
drstica da complexidade dos projetos de desenvolvimento de software, bem como
de toda a estrutura da tecnologia da informao, reduzindo em poucos elementos
gerenciveis e trabalhando com profissionais cuja atuao multidisciplinar.
Um dos principais problemas das metodologias geis que o cliente deve
estar presente durante o processo de desenvolvimento, tornando o compromisso do
usurio uma pea fundamental para o sucesso do projeto. Em contrapartida, as
metodologias geis possuem vrias vantagens em relao aos mtodos tradicionais
de desenvolvimento de software, sendo o maior ponto positivo as entregas
constantes do software. Com entregas mais rpidas, o cliente no precisa esperar
muito para ver o software funcionando, o que agrega transparncia sobre o
progresso e o valor entregue, reduzindo tambm as possibilidades de que grandes
falhas aconteam.
Em mbito gerencial, os mtodos tradicionais de gesto para projetos de
desenvolvimento de software no tm se adaptado aos ambientes extremamente
dinmicos. Para isto, os mtodos geis de gesto tornaram mais fcil esta gesto,
calcados em respostas rpidas a mudanas constantes e entregas do produto acima
de documentao, processos e contratos.
Este trabalho permitiu concluir que o Gerenciamento gil de Projetos

60

rapidamente alcanar outros setores alm do Desenvolvimento de Software. E para


isto, o grande desafio das metodologias geis est no princpio de encontrar
maneiras de eliminar alguns de seus pontos fracos, como por exemplo, a falta de
anlise de riscos, sem torn-las metodologias pesadas ao mesmo tempo. Outro
desafio, como implementar o uso dessas metodologias geis em grandes
empresas e equipes, uma vez que normalmente essas metodologias so focadas
em equipes pequenas.
A grande lio aprendida neste trabalho que o Projeto gil tem a
capacidade de aprender e de se adaptar com seu aprendizado.

61

6 REFERNCIAS BIBLIOGRFICAS
AGILE ALLIANCE: MANIFESTO GIL. Estados Unidos, 2001. Disponvel em:
<http://agilemanifesto.org/>. Acesso em: maro, 2010.
BEEDLE, MA; SCHWABER, K. Agile Software Development With Scrum. 1 ed.
Prentice Hall PTR, 2002.
BERNARDINO, CB; GOMES, AS; VASCONCELOS, A. Design interativo em
processos de desenvolvimento de software. Recife: Universidade Federal de
Pernambuco, 2005.
CMARA, F. Um cardpio de metodologias geis. Revista Viso gil. Edio 2, p.
19-21, 2008.
DAVIS, MM; AQUILANO, NJ; CHASE, RB. Fundamentos da administrao da
produo. 3 edio. Porto Alegre: Bookman, 2001.
DIAS,

MVB.

Um

novo

enfoque

para

gerenciamento

de

projetos

de

desenvolvimento de software. So Paulo: Dissertao de Mestrado Universidade


de So Paulo, 2005.
ENGENHARIA

DE

SOFTWARE.

Disponvel

em:

<http://engenhariasoftware.wordpress.com/2009/08/03/gestao-de-projetos-desoftware-ou-gestao-em-projetos-de-software/>. Acesso em: dezembro, 2009.


FELSING, J; PALMER, S. A Practical Guide to Feature-Driven Development. 1 ed.
Prentice Hall PTR, 2002.
GERMANO, VH. Nove pecados mortais no planejamento de projetos. Revista Viso
gil. Edio 4, p.27-30, 2008.
GIDO, J; CLEMENTS, JP. Gesto de projetos. So Paulo: Thomson, 2007.

62

KERZNER, H. In Seach of Excellence in Project Management: successful practies in


high performance orgainzations. New York: Van Nostrand Reinhold, 1998.
MATTOS, JL; GUIMARES, LS. Gesto da tecnologia e inovao: uma abordagem
prtica. So Paulo: Saraiva, 2005.
MOL, AC. Uma discusso sobre os mtodos geis de desenvolvimento de software.
Minas Gerais: Monografia de Final de Curso Universidade Federal de Minas
Gerais, 2007.
NEUMANN, D; BAUREIS, D; STOCK, T. Capacidade de Transformao: Gesto gil
de Projetos em Estruturas Organizacionais Transformveis. Revista Mundo Project
Management. Ano 5, nmero 26, p. 65, abril/maio 2009.
PMBOK GUIDE 3 Edio. Um Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos. 3 edio, 2004.
SCHWABER, K. Agile Project Management With Scrum. 1 ed. Microsoft Press,
2004.
STRODE,

DE.

Agile

Project.

2005.

Disponvel

em

<http://muir.massey.ac.nz/bitstream/10179/515/1/02whole.pdf>. Acesso em maro,


2010.
TELES, VM. Extreme Programming. 1 ed. So Paulo: Novatec, 2009.
TOMAS, MRS. Mtodos geis: Caractersticas, pontos fortes e fracos e
possibilidades de aplicao. Portugal. Universidade Nova de Lisboa, 2009.
Disponvel

em:

<http://dspace.fct.unl.pt/bitstream/10362/2003/1/WPSeries_09_2009Tomas.pdf>
TURBAN, E; MCLEAN, E; WETHERBE, J. Tecnologia da informao para gesto:
transformando os negcios na economia digital. Traduo: Renate Schinke. Porto
Alegre: Bookman, 2007.

63

VALE, A. Aperfeioamento de projetos geis: Parte I: uma viso geral. Revista Viso
gil. Edio 3, p. 29-34, 2008a.
VALE, A. Aperfeioamento de projetos geis: Parte II: as trs perspectivas. Revista
Viso gil. Edio 4, p. 18-24, 2008b.
VARGAS, R. Gerenciamento de projetos: estabelecendo diferenciais competitivos.
Rio de Janeiro: Brasport, 2009.
WIKIPEDIA:

enciclopdia

livre.

Disponvel

em:

<http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_projetos>. Acesso em: janeiro,


2010.