099 - gerenciamento de desenvolvimento de software atraves de extreme project management - xpm

8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM

1/47

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

ESCOLA POLITCNICADCC/SEGRAC

GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWAREATRAVS DE EXTREME PROJECT MANAGEMENT(XPM)

Felipe Barbosa Nogueira

2007


2/47

GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWAREATRAVS DE

EXTREME PROJECT MANAGEMENT(XPM)


Monog ra f ia ap resen tada no Cu rso dePs -Graduao em Gerenc iamen tode P ro je tos , da Esco la Po l i t cn ica ,da Un ive rs idade Fede ra l do R io deJane i ro .

Orientador

George Wosley Barbosa Nogueira Lima

FortalezaJaneiro, 2007


3/47

ii

GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWAREATRAVS DE

EXTREME PROJECT MANAGEMENT(XPM)


Orientador

George Wosley Barbosa Nogueira Lima

Monografia submetida ao Curso de Ps-graduao Gerenciamento de Projetos,da Escola Politcnica, da Universidade Federal do Rio de Janeiro UFRJ,

como parte dos requisitos necessrios obteno do ttulo de Especialista em

Gerenciamento de Projetos.

Aprovado por:

__________________________________________

Prof. Eduardo Linhares Qualharini

__________________________________________

Prof.Fernanda Veras

__________________________________________

Prof. Alexsandro Amarante da Silva



4/47

iii

NOGUEIRA, Felipe Barbosa.Gerenciamento de Desenvolvimento de Software

Atravs de Extreme Project Management (XPM) /NOGUEIRA, F. B. Fortaleza: UFRJ/EP, 2007.

vii, 35f. il.; 29,7cm.Orientador: George Wosley Barbosa Nogueira

Lima.Monografia (especializao) UFRJ/ Escola

Politcnica/ Curso de Especializao emGerenciamento de Projetos, SEGRAC, 2007.

Referncias Bibliogrficas: f. 33-351. Gerenciamento de Projetos. 2. Prticas da

Qualidade I. LIMA, G. W. B. N. II. Universidade Federal

do Rio de Janeiro, Escola Politcnica, Ps-graduaoIII. Especialista.


5/47

RESUMO

GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVS DE

EXTREME PROJECT MANAGEMENT (XPM)Felipe Barbosa Nogueira

Resumo da Monografia submetida ao corpo docente do curso de Ps-

Graduao em Gerenciamento de Projetos Universidade Federal do Rio de

Janeiro UFRJ, como parte dos requisitos necessrios obteno do ttulo de

Especialista em Gerenciamento de Projetos.

O XPM visa melhorar o gerenciamento de projetos, em especial aos projetos

de software para os quais o tempo e o custo para tornar o produto disponvel

no mercado so crticos, no sendo possvel elaborar um cronograma

detalhado e uma especificao de requisitos em um estgio preliminar do

processo, e mostra-se necessria uma avaliao diria do projeto para adequ-

lo situao de mercado. A meta a entrega do resultado desejado, e nonecessariamente o resultado inicialmente planejado.

Palavras-chave:Gerenciamento de Projetos, Prticas da Qualidade



6/47

v

SUMRIO

1. Introduo ________________________________________________________1

2. Gerncia Tradicional de Projetos______________________________________3

2.1 Histria_________________________________________________________3

2.2 Gerenciamento Informal de Projetos__________________________________4

2.3 O Gerenciamento Tradicional de Projetos segundo o Project Management Box

of Knowledge(PMBoK) _______________________________________________6

3. Metodologias geis de Desenvolvimento de Software ____________________9

3.1 Caractersticas das Metodologias ____________________________________9

3.2 Metodologias geis ______________________________________________10

3.2.1 Extreme Programming(XP) ____________________________________11

3.2.2 SCRUM____________________________________________________13

3.2.3 Famlia Cristal De Metodologias_________________________________15

3.2.4 Feature Driven Development(FDD) ______________________________16

3.2.5 Mtodo de Desenvolvimento de Sistema Dinmico (MDSD) ___________20

3.2.6 Desenvolvimento Adaptativo de Software(DAS) ____________________22

4. eXtreme Project Management (XPM) __________________________________24

4.1 Regras ________________________________________________________24

4.1.1 XPM Regra 1: A gerncia de pessoas e processos criativos demanda

processos criativos. _______________________________________________24

4.1.2 XPM Regra 2: Quanto menos o gerente souber sobre questes tcnicas do

projeto, melhor. __________________________________________________25

4.1.3 XPM Regra 3: O que ocorre depois do projeto mais importante do que

ocorre durante o projeto____________________________________________26

4.1.4 XPM Regra 4: O planejamento de projeto desenvolvido sem a participao

completa dos stakeholders no mais que a fantasia de uma nica pessoa___26

4.1.5 XPM Regra 5: Quanto mais tempo o gerente de projetos permanecer com

os stakeholders melhor ____________________________________________274.1.6 XPM Regra 6: Se o sucesso do projeto no for definido no comeo, ele

nunca ser alcanado no final _______________________________________28

4.1.7 XPM Regra 7: Mostre-lhes o lucro: nada mais importa _______________28

4.1.8 XPM Regra 8: Os Stakeholders do projeto podem ser seus melhores aliados

ou seus piores inimigos ____________________________________________29

4.1.9 XPM Regra 9: Se voc no pode prever o futuro, no planeje em detalhe 29

4.1.10 XPM Regra 10: Se o seu projeto no mudou, fique apreensivo, muito

apreensivo. _____________________________________________________304.1.11 XPM Regra 11: Em e-projects, um dia um tempo muito longo _______30


7/47

vi

5. Consideraes Finais ______________________________________________31

Referncias Bibliogrficas ____________________________________________34

Referencias Eletrnicas_________________________________________35


8/47

vii

LISTA DE FIGURAS

Figura 1 Ciclo de vida tpico de um projeto XP__________________________12

Figura 2 Fases do SCRUM ________________________________________ 13

Figura 3 Incremento Crystal Orange _________________________________ 16

Figura 4 Fases FDD______________________________________________17

Figura 5 Diagramas de processos do MDSD___________________________22

Figura 6 Diagramas de Fases do DAS_______________________________ 23

LISTA DE QUADROS

Quadro 1 Os doze princpios da agilidade________________________________ 9

Quadro 2 Comparativo entre o PMBoK e XPM / Gerenciamento da Integrao____ 10

Quadro 3 Etapas do planejamento rpido _________________________________27

LISTA DE SIGLAS

XPM Extreme Project Management

PMBoK Project Management Box of Knowledge

XP Extreme Programming

FDD Feature Driven Development

MDSD Mtodo de Desenvolvimento de Sistemas Dinmicos

DAS Desenvolvimento Adaptativo de Software

EAP Estrutura Analtica do Projeto

ANSI American National Standards Institute

PMI Project Management Institute

TI Tecnologia da Informao

RAD - Rapid Application Development

IRACIS Increase Reveue, Avoid Cost and Improve Services


9/47

1. Introduo

Ao longo do tempo, o desenvolvimento de software tem sido rotulado como

uma atividade complexa e marcada por fracassos: prazos e oramentos no

cumpridos, expectativas no satisfeitas, retorno de investimento muito menor que oesperado. Uma das principais razes apontadas para isto tem sido a dificuldade de

encontrar a melhor relao entre custo, prazo, escopo e qualidade. Em busca de uma

soluo, procurou-se adotar junto aos projetos de software a mesma abordagem

empregada aos projetos de engenharia, acreditando-se que a receita para o sucesso

seria investir muito tempo e recursos, em um planejamento e designmais detalhados,

e garantir o sucesso da execuo com gerenciamento e processos bem definidos.

Nesta direo, diversas organizaes partiram em busca de uma soluo final para

seus problemas: utilizando normas e modelos existentes, definiram processosorganizacionais e tcnicos complexos, suportados por muita documentao escrita e

dispensavam a participao do cliente no decorrer do desenvolvimento, Insistindo em

erros comuns de muitos projetos de engenharia, muitas organizaes acabaram por

ampliar o tamanho do problema com tentativas de soluo.

Por mais que os processos e controles tenham sido definidos, os resultados

acabavam ficando longe da expectativa, pois a construo de software diferente de

outras construes da engenharia tradicional: um software , pela sua prpria

natureza, intangvel; impossvel se antever todas as suas funcionalidades; as

necessidades emergem durante todo o seu desenvolvimento, e vo amadurecendo at

a sua implantao; alm disso, a prpria utilizao do software que geralmente

impulsiona o aprimoramento de seus recursos. A mudana , portanto, inevitvel e o

no reconhecimento desta realidade leva ao desperdcio de recursos em planejamento

e designdesnecessrios, que acabam sendo descartados posteriormente. Ao procurar

satisfazer custo, prazo, escopo e qualidade, o caminho adotado pela gerncia

tradicional de projetos tem sido, a partir de um escopo fechado definir custo e prazo e,em funo do andamento do projeto, manipular a qualidade. Mas ser que melhor no

seria ter prazo predefinido, um custo fixo, mantendo os nveis de qualidade e

manipulando o escopo, e por qu no fazer o mais simples primeiro, e refinar depois,

mudando somente e quando for necessrio, deixando de gerar documentao

desnecessria para execuo do escopo.

Em meio a estes questionamentos, esta pesquisa discute os princpios e

prticas das metodologias geis de gerenciamento de software em relao aos

processos e prticas descritas pela abordagem tradicional de planejamento,


10/47

2

monitoramento e controle de projetos, buscando mostrar que a adoo da abordagem

gil pode no s aumentar a credibilidade deste paradigma, mas tambm ajudar a

elevar a qualidade dos produtos em conseqncia da melhoria da qualidade derivada

das boas prticas empregadas.


11/47

3

2. Gerncia Tradicional de Projetos

2.1 Histria

Em 1960, mais e mais executivos renderam-se busca de novas tcnicas de

gerenciamento e estruturas organizacionais que pudessem ser rapidamente

adaptadas ao seu ambiente, o gerenciamento de projeto vem a ser uma nova

ferramenta no auxlio dos trabalhos.

Inicialmente as empresas, como, as do setor aeroespacial, defesa e

construo, as principais da poca, mantinham o mtodo informal de gerenciamento

de projetos onde a autoridade do gerente de projeto era fraca e os principais projetos

eram gerenciados diretamente por gerentes funcionais.

Nesta poca, a maioria das organizaes teve o primeiro contato com sistemas

de computao. Segundo Rob Thomsett [Extreme Project Management, 2001] o

desenvolvimento de software encontrava-se na era das trevas (Dark Age) onde a

necessidade de qualquer desenvolvimento tinha uma participao tmida por parte dos

clientes, que as repassavam equipe de TI (Tecnologia de Informao). Os Clientes,

ento, s tinham mais alguma participao no processo caso houvesse a necessidade

de mais informao a ser dada. Neste momento o cliente era totalmente dependente

do profissional de TI.

Em 1970 e incio de 1980, mais empresas comearam a sair da filosofia

informal de gerenciamento de projeto para um processo mais formalizado de gerncia,

tendo em vista o tamanho e complexidade que as atividades estavam assumindo

dificultando o gerenciamento dentro da estrutura utilizada.

O gerenciamento de projeto, ento comeou, a ganhar fora dentro das

empresas, os executivos vislumbraram que esta abordagem estaria entre os principais

interesses das empresas, se bem implementado, poderia ajudar as empresas a

transpor os obstculos internos e externos.

Para o gerenciamento formal de projeto a ser adotado nas empresas,

mudanas eram inevitveis, para satisfaz-las as organizaes voltaram-se para si, a

fim de se reestruturarem. As mudanas ento, iniciaram-se. As empresas como as do

setor aeroespacial, defesa e construo, foram pioneiras.

As empresas advogavam que o gerenciamento informal que vinha sendo

aplicado era um sucesso e no viam a aplicao formal do gerenciamento de projeto

com diferencial que os forasse a mudar. J as empresas que decidiram implantar


12/47

4

esta nova abordagem tinham a seguinte pergunta a responder: Quanto tempo leva o

perodo de converso para esta nova abordagem de gerenciamento?

Em regra geral isto poderia demandar de dois a trs anos para converter a

estrutura tradicional para o gerenciamento estruturado, sendo uma das principais

razes para isto, o fato do empregado terem um chefe nico, em uma nica estrutura

o empregado teria que se reportar verticalmente com seu gerente funcional e

horizontalmente com o gerente de projeto, o que causa um grande choque cultural no

incio.

Para Rob Thomsett, (2001), o desenvolvimento de software neste perodo

caracterizava-se pela fase do tokenismo (tokenism), em que os sistemas

desenvolvidos na fase anterior (Dark Age) foram re-desenvolvidos para tirar vantagem

dos benefcios oferecidos pelas tecnologias de banco de dados, redes e comunicaoque estavam emergindo na poca. Esta fase marcou a primeira tentativa de

automatizar novos tipos de sistemas de informao, tais como, gerenciamento de

informao e suporte a deciso.

A partir de 1990, as empresas notaram que a implementao do

gerenciamento de projeto era uma necessidade no uma escolha. A questo ento,

era como implement-lo da forma mais rpida possvel.

Para Rob Thomsett (2001), a prxima fase do desenvolvimento de sistema, onde a participao do cliente se torna presente. A terceira fase o troco (Payback)

por parte dos clientes, que trazem o controle do processo para si. Entretanto, a

competitividade, custos e presses sociais foraram as organizaes (pblicas e

privadas) a avaliarem os mtodos de trabalho, gerencia e planejamento

empreendidos, at ento, por parte dos executivos, sobre tudo nos investimentos de TI

a fim de descobrirem se este conjunto estava alinhado aos interesses da empresa.

Nos dias atuais, o desenvolvimento de software, trabalha em parceria

(Partnership) entre a equipe de TI e os usurios (clientes), onde as responsabilidades

so divididas e a cooperao d espao a uma abordagem bilateral.

2.2 Gerenciamento Informal de Projetos

medida que o gerenciamento de projetos tornava-se um processo

reconhecido, muita documentao formal passou a ser produzida, visando

principalmente tranqilizar o cliente. Considerando o tempo consumido na elaborao,digitao, leitura, cpia, distribuio e arquivamento de documentos, essa


13/47

5

formalizao resultava em um custo muito alto. Mais grave do que isto, os gerentes de

projeto acabaram ficando to absorvidos com a documentao a ser gerada que

pouco tempo lhes restava para gerenciar efetivamente o projeto.

Nos ltimos 20 anos, porm, esse cenrio mudou. Segundo Kerzner (2002), a

mudana mais significativa no campo do gerenciamento de projetos foi a comprovao

de que o gerenciamento informal d resultados. Com o gerenciamento informal, a

necessidade de documentao foi reduzida para nveis minimamente aceitveis, e

diretrizes formais foram substitudas por listas de verificao menos detalhadas e mais

genricas. Gerenciamento Informal baseado mais em guias do que em polticas e

procedimentos que so as bases do gerenciamento formal de projetos. Mudar da

formalidade para a informalidade exige, porm, uma alterao na cultura da

organizao. Kerzner aponta ainda, quatro elementos chave para o sucesso daimplementao da gesto informal de projetos:

Confiana: fundamental na consolidao de uma relao efetiva

entre o fornecedor/ terceirizado e o cliente, a confiana traz inmeros

benefcios para ambas as partes. Sem ela, gerentes e responsveis

por projetos precisariam de uma vasta documentao, apenas para

terem a certeza de que todos os encarregados esto cumprindo suas

tarefas da maneira que lhes foi determinada.

Comunicao: em geral, embora os executivos prefiram comunicar-se verbal ou informalmente, existe a crena de que aquilo que no

foi escrito no foi dito. Um dos pr-requisitos para o gerenciamento

informal de projetos que os funcionrios entendam a estrutura, as

funes e as responsabilidades que tero no mbito da empresa e

do projeto. Metodologias eficientes de gerenciamento de projetos

promovem no apenas o gerenciamento informal, mas igualmente a

comunicao eficiente, tanto lateral quanto verticalmente. Dois

grandes obstculos internos a serem superados para desenvolver-se

uma cultura informal so os relatrios e as reunies longas e

desnecessrias, decorrentes da interveno dos gerentes em

atividades rotineiras ou do mal direcionamento de informaes.

Quando necessria, a comunicao formal deve ser breve e focada

em trs questes bsicas: qual a situao atual, qual a situao

desejada e se existe algum problema exigindo a interferncia da

administrao. Nenhum planejamento, por melhor que seja, ir muito

longe sem uma comunicao eficiente.

Cooperao: mais relacionada com a atitude em relao ao trabalho

do que com o trabalho propriamente dito, consiste em aes


14/47

6

voluntrias das pessoas para trabalhar em benefcio do todo,

buscando um resultado favorvel. Sua efetivao no depende da

interveno formal da autoridade, pois os integrantes geralmente

sabem o que devem fazer e o que fazem. As pessoas aprendem a

cooperar medida que se conhecem melhor, o que leva tempo , umrecurso quase sempre escasso em projetos.

Trabalho em equipe: desenvolvido por pessoas atuando juntas com

um esprito de cooperao, sob os limites de uma coordenao,

possibilitando: troca de idias e informaes por iniciativa prpria;

estabelecimento de altos ndices de inovao e criatividade;

confiana e lealdade entre os membros e para com a empresa;

dedicao ao trabalho realizado e aos compromissos assumidos;

franqueza e honestidade em seu relacionamento.

2.3 O Gerenciamento Tradicional de Projetos segundo o

Project Management Box of Knowledge(PMBoK)

Mundialmente reconhecido e aceito desde 1999 como padro de

gerenciamento de projetos pelo ANSI (American National Standards Institute), o

PMBoK, PMI, (2004) descreve o conjunto de conhecimentos e as melhores prticas

para o gerenciamento de projetos, podendo ser utilizado para orientar a definio deum processo padro para gerenciamento de projetos de software, pois escreve .o que

deve ser feito e no como fazer. Diversas empresas no mundo utilizam com sucesso o

PMBoK como base para o estabelecimento de uma cultura em gerenciamento de

projetos. Os 44 processos que integram a terceira edio do PMBoK, PMI, (2004)

esto organizados em nove reas de conhecimento ou de atuao gerencial:

Integraodescreve os processos e as atividades que integram os

diversos elementos do gerenciamento de projetos, que so

identificados, definidos, combinados, unificados e coordenados

dentro dos grupos de processos de gerenciamento de projetos. Ela

consiste nos processos de gerenciamento de projetos: Desenvolver

o termo de abertura do projeto, Desenvolver a declarao do escopo

preliminar do projeto, Desenvolver o plano de gerenciamento do

projeto, Orientar e gerenciar a execuo do projeto, Monitorar e

controlar o trabalho do projeto, Controle integrado de mudanas e

Encerrar o projeto.

Escopodescreve os processos envolvidos na verificao de que o

projeto inclui todo o trabalho necessrio, e apenas o trabalho


15/47

7

necessrio, para que seja concludo com sucesso. Ela consiste nos

processos de gerenciamento de projetos: Planejamento do escopo,

Definio do escopo, Criar Estrutura Analtica do Projeto (EAP),

Verificao do escopo e Controle do escopo.

Tempo descreve os processos relativos ao trmino do projeto no

prazo correto. Ela consiste nos processos de gerenciamento de

projetos: Definio da atividade, Seqenciamento de atividades,

Estimativa de recursos da atividade, Estimativa de durao da

atividade, Desenvolvimento do cronograma e Controle do

cronograma.

Custos descrevem os processos envolvidos em planejamento,

estimativa, oramentao e controle de custos, de modo que o

projeto termine dentro do oramento aprovado. Ela consiste nosprocessos de gerenciamento de projetos: Estimativa de custos,

Oramentao e Controle de custos.

Qualidadedescreve os processos envolvidos na garantia de que o

projeto ir satisfazer os objetivos para os quais foi realizado. Ela

consiste nos processos de gerenciamento de projetos: Planejamento

da qualidade, Realizar a garantia da qualidade e Realizar o controle

da qualidade.

Recursos Humanos descreve os processos que organizam e

gerenciam a equipe do projeto. Ela consiste nos processos de

gerenciamento de projetos: Planejamento de recursos humanos,

Contratar ou mobilizar a equipe do projeto, Desenvolver a equipe do

projeto e Gerenciar a equipe do projeto.

Comunicaesdescreve os processos relativos gerao, coleta,

disseminao, armazenamento e destinao final das informaes

do projeto de forma oportuna e adequada. Ela consiste nos

processos de gerenciamento de projetos: Planejamento dascomunicaes, Distribuio das informaes, Relatrio de

desempenho e Gerenciar as partes interessadas.

Riscos descreve os processos relativos realizao do

gerenciamento de riscos em um projeto. Ele consiste nos processos

de gerenciamento de projetos: Planejamento do gerenciamento de

riscos, Identificao de riscos, Anlise qualitativa de riscos, Anlise

quantitativa de riscos, Planejamento de respostas a riscos e

Monitoramento e controle de riscos.


16/47

8

Aquisies descreve os processos que compram ou adquirem

produtos, servios ou resultados, alm dos processos de

gerenciamento de contratos. Ele consiste nos processos de

gerenciamento de projetos: Planejar compras e aquisies, Planejar

contrataes, Solicitar respostas de fornecedores, Selecionarfornecedores, Administrao de contrato e Encerramento do

contrato.

Tais processos encontram-se divididos em cinco grandes grupos: Iniciao

(que autoriza o incio do projeto ou de uma fase), Planejamento (que define, refina e

seleciona as melhores alternativas), Execuo (que coordena recursos a partir do que

foi planejado), Controle (que monitora e mede o progresso do que foi executado) e

Encerramento (formaliza o aceite e a finalizao do projeto ou de uma fase).


17/47

9

3. Metodologias geis de Desenvolvimento de Software

3.1 Caractersticas das Metodologias

A dificuldade de uso das metodologias de desenvolvimento de software

tradicionais e a alta freqncia com que os projetos de software deixavam de cumprir

seus cronogramas e extrapolavam seus oramentos levaram, ao final da dcada de

1990, elaborao do Manifesto pela Agilidade, Beck (2001) e criao de uma

organizao sem fins lucrativos denominada Aliana gil - Agile Alliance(2005), com

a finalidade de divulgar seus princpios, Beck (2001), apresentados no Quadro 1, em

busca de uma forma mais objetiva de se desenvolver software.

Surgiu, assim, um novo paradigma para o desenvolvimento de software, as

metodologias leves (lightweight methodologies), ou geis. Ao invs de estabelecerprocessos, as metodologias geis combinam um pequeno nmero de regras e

prticas, sendo especialmente adequadas para projetos pequenos ou mdios (2-10

pessoas), com requisitos imprecisos ou em constante mudana.

Quadro 1. Os doze princpios da agilidade.

Descrio . Princpios da Agilidade1. A prioridade a satisfao do cliente, por meio da liberao rpida e contnua de

software de valor.

2. Receba bem as mudanas de requisitos, mesmo em estgios tardios dodesenvolvimento. Processos geis devem admitir mudanas que trazem vantagenscompetitivas para o cliente.

3. Libere software freqentemente, dando preferncia para uma escala de tempo mais curta.4. Mantenha stakeholders e desenvolvedores trabalhando juntos a maior parte do tempo do

projeto.5. Construa projetos com indivduos motivados, d a eles o ambiente e suporte que

precisam e confie neles.

6. O mtodo mais eficiente e efetivo para repassar informao pela comunicao direta.

7. Software funcionando a principal medida de progresso de um projeto de software.

8. Processos geis promovem desenvolvimento sustentado. Assim, patrocinadores,desenvolvedores e usuriosdevem ser capazes de manter conversao pacfica indefinidamente.

9. A ateno contnua para a excelncia tcnica e um bom projeto (design) aprimoram aagilidade.

10. Simplicidade . a arte de maximizar a quantidade de trabalho no feito . essencial,devendo ser sempreassumida em todos os aspectos do projeto.

11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.12. Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas,

para ento refinarem e ajustarem seu comportamento.Fonte: Manifesto da Agilidade , Beck (2001)


18/47

10

3.2 Metodologias geis

A abordagem gil prope a construo de software de forma evolutiva e

adaptativa. A idia comear da forma mais simples possvel, apenas com o

planejamento e designnecessrios e resolver as necessidades mais claras e crticas,agregando valor ao produto e entregando algum resultado rapidamente. Durante todo

o desenvolvimento, o objetivo ter um software em operao o mais rpido possvel,

para que ele tenha condies de evoluir. Deve-se investir ao mximo em simplicidade,

de forma que a mudana deixe de ser traumtica e passe a ser natural.

As metodologias geis apresentam diferenas significativas em relao s

metodologias tradicionais, conforme quadros abaixo, separados por rea de

conhecimento, isso ocorre porque os pressupostos so totalmente divergentes.

Conforme observa-se, ambos apresentam pontos fortes e fracos, o importante

buscar o ponto de equilbrio, avaliando riscos: o planejamento pode aperfeioar a

agilidade, enquanto esta pode dar maior eficincia ao planejamento. Em qualquer

abordagem, porm, as pessoas ativamente envolvidas e suas proposies de valor

possuem grande importncia. A seguir, um comparativo entre o PMBoK e as prticas

da abordagem gil. (quadro 2). No anexo esto os quadros 3, 4, 5, 6, 7, 8, 9, 10

oferecendo comparativos do PMBoK x abordagem gil para Escopo, Custos, Riscos,

Tempo, Qualidade, RH, Comunicaes e Aquisies.

Quadro 2 : Comparativo entre o PMBoK e XPM / Gerenciamento da Integrao

ProcessosDefinidosnoPMBoK Princpios e Prticas da Abordagem gil

GerenciamentodeIntegraoIdentificar,definir,combinar,unificarecoordenarosdiversosprocessoseatividadesde

gerenciamentodeprojetos

Desenvolver otermo de abertura doprojeto:geraruma autorizaoformaldeseuincioDesenvolver a declarao de escopopreliminar doprojeto:fornecerumadescrio

dealtonvelveldoescopoDesenvolver o plano de gerenciamentodoprojeto:definir, preparar,integrarecoordenarplanosauxiliaresOrientar e gerenciar a execuo do projeto:executar otrabalho definido para atingir os requisitosdefinidos na declaraodeescopoMonitorar e controlar o trabalho do projeto:atender aos objetivosdedesempenhodefinidosnoplanodeprojetoControlar mudanas: aprovar solicitaes ecoordenar mudanasemprodutoseprocessos,deformaintegrada

Encerrar o projeto: finalizar todas asatividades para encerrarformalmenteoprojeto

Big Plan: identifica a viso e misso dosistema, d ao clienteeequipeumanoogeralparaasreleases

Planos de release eiterao:detalhametapasespecificaepossibilitamoacompanhamentoJogo do planejamento: acompanha toda aexecuo, avaliando prazo, escopo, risco ecusto, com pouca carga adicional,aindaquedemaneirainformalCartes com estrias: indexam os casos deuso, que so selecionados pelo cliente paraimplementao a cada iteraoDesenvolvimento por iterao: entrega umconjunto de funcionalidades, agregandovaloraoprodutoe realimentandooplanejamentoReunies de acompanhamento: possibilitamidentificar comrapidezasituaoatualeanecessidadedemudana

Fonte: Ana Magalhes (2005)


19/47

11

3.2.1. Extreme Programming(XP)

A XP a metodologia de desenvolvimento gil mais conhecida e utilizada. De

domnio pblico, possui este nome porque emprega ao extremo algumas boas prticas

da engenharia de software. Ela descrita por meio de valores, princpios e prticas,

Beck (2001). Os valores descrevem os objetivos de longo prazo ao aplicar XP e

definem critrios de sucesso. Os princpios proporcionam a pequenas e mdias

equipes um ambiente de desenvolvimento cooperativo, capaz de atingir altos nveis de

produtividade e um elevado grau de confiana. As prticas estruturam as atividades

bsicas do desenvolvimento XP e seguem seus princpios, sustentando os valores

definidos.

O ciclo de vida de um projeto XP iterativo e incremental, como apresentado

na Figura 1. Existe uma etapa de planejamento inicial, na qual o coach e o clienteanalisam a viabilidade do projeto, identificam um escopo geral as macro

funcionalidades da soluo e elaboram o plano inicial, denominado Big Plan. O

desenvolvimento ocorre em releases, que so divididas em iteraes. No

planejamento do prximo release, equipe tcnica e cliente detalham requisitos e

estimam esforo, utilizando Story Cards- cartes que descrevem estrias (requisitos

de usurio) de forma sucinta, possibilitando estimar o esforo envolvido. Os Story

Cardsconstituem uma ferramenta efetiva para guiar o desenvolvimento, sendo de fcil

manipulao e armazenamento. As estimativas so realizadas em grupo e baseadas

em histrico: atribuem-se pontos s estrias mais simples e, a partir da, estima-se de

forma comparativa. Quando no se tem idia da complexidade de uma estria, alguns

experimentos ou implementaes so realizados, em busca de mais dados para

realizar a estimativa. A unidade utilizada ideal weeks. Aps estimar todos os Story

Cards, cliente e equipe tcnica definem o escopo do prximo release, que dever

entregar um software de valor, de forma que usurios possam utiliz-lo, perceber

benefcios de seu uso e realimentar os desenvolvedores com pontos positivos e

negativos. O planejamento das iteraes ento realizado, refinando o plano do

release. Os desenvolvedores identificam as tarefas contidas nas estrias, estimam sua

durao em perfect days e escolhem o que iro implementar o que gera maior

comprometimento e motivao. Durante todo o desenvolvimento aplicada,

constantemente, a prtica de jogo do planejamento.


20/47

12

Figura 1. Ciclo de vida tpico de um projeto XPFonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)

O desenvolvimento, propriamente dito, corresponde implementao das

estrias selecionadas. A arquitetura definida e remodelada em sees rpidas de

design, sempre buscando a simplicidade deve-se resolver o problema atual, usando

metforas, e gerar cdigo preparado para mudar e evoluir. A programao em pares

uma constante: o driver fica no teclado, focado no que est sendo implementado,

enquanto o partner atua como inspetor, acompanhando a produo do driver, com

trocas ocorrendo vrias vezes ao dia. Desenvolvido utilizando um padro de

codificao, o cdigo gerado comunitrio, sendo freqentemente reestruturado em

busca de um melhor desempenho e simplicidade. Testes unitrios automticos sogerados junto com o cdigo, o que motiva e d mais confiana equipe. Buildsso

gerados a cada integrao do cdigo, ocasio em que todos os testes so refeitos. Se

ocorrer erro, qualquer integrante da equipe poder alter-lo. Os testes de aceitao

so especificados pelo cliente, que define com o apoio dos testers como quer o

produto. As prticas XP utilizadas em conjunto promovem um processo eficiente de

desenvolvimento do software.

O tracker o responsvel por acompanhar o progresso da iterao, verificando

periodicamente com o programador quantos perfectdays este j trabalhou na tarefae quantos ainda faltam para conclu-la. Reunies dirias de acompanhamento (stand-

up meetings) so realizadas com o objetivo de verificar a evoluo, comunicar

problemas e providenciar solues. Caso exista algum desvio ou problema, o coach

alertado para intervir junto equipe e envolver o cliente, se necessrio. Grficos

visveis so disponibilizados para acompanhar progresso do projeto, apresentando em

geral estimativas, testes executados, densidade de erros(bugs) e progresso de

estrias.


21/47

13

3.2.2 SCRUM

A primeira meno na literatura sobre o termo SCRUM surgiu com o artigo de

Takeuchi e Nokata (1986) que dizia ser um processo adaptativo, rpido, alto

organizvel. O SCRUMconsiste em uma aplicao da abordagem emprica da teoria

de controle do processo industrial para o desenvolvimento de software resultando em

uma abordagem flexvel, adaptativa e produtiva. O SCRUMconcentra-se em como os

membros da equipe devem agir de forma a produzir sistemas flexveis em um

ambiente em constante mudana.

A principal idia do SCRUM que o desenvolvimento de sistema envolve

vrias variveis tcnicas e ambientais que mudam durante o processo, tornando o

desenvolvimento imprevisvel e complexo, requerendo flexibilidade do processo de

desenvolvimento de sistema, para torn-lo hbil a responder as mudanas. Suas fasespodem ser vistas na Figura 2.

Figura 2 Fases SCRUMFonte: Abrahamsson, Salo, Ronkaisen e Warsta (2002)

O SCRUM consiste em trs fases, segundo Schwaber e Beedle (1995):

Fase pr-game inclue duas sub-fases: Planejamento e Arquitetura. No

Planejamento, define-se o que o sistema ver fazer. criado o Product Backlog List

(PBL) contendo todos os requisitos conhecidos do sistema. Os requerimentos so


22/47

14

priorizados e o esforo necessrio de sua implementao estimado. O PBL

constantemente atualizado com novos ou mais detalhes de seus itens, como tambm

estimativas mais precisas e nova ordem de prioridades. O planejamento inclue

tambm a definio do time do projeto, ferramentas necessrias e outros recursos,

anlise de risco e controle de verses. A cada iterao, o PBL revisto pelo Time(s)

SCRUM, depois do aceite coletivo com relao verso nesta iterao, passa-se

prxima.

Na sub-fase de arquitetura, so planejados detalhes de implementao

baseados nos requerimentos do PBL.

A fase de desenvolvimento (tambm chamada fase de jogo) a parte gil do

SCRUM. Esta fase tratada como uma caixa preta onde o imprevisvel esperado.

As diferentes variveis tcnicas e ambientais (tais como tempo, qualidade,requerimentos, recursos, implementaes tecnolgicas e ferramentas) identificados no

SCRUM, que podem mudar no decorrer do processo, so observados e controlados

atravs de prticas durante os Sprintsda fase de desenvolvimento.

Na fase de desenvolvimento o sistema desenvolvido em Sprints. Os Sprints

so ciclos iterativos onde a funcionalidade desenvolvida ou melhorada para produzir

novos incrementos. Cada Sprint inclue as fases tradicionais de desenvolvimento de

software: requerimento analise, design, evoluo e delivery. A arquitetura e designdo

sistema evoluem durante o desenvolvimento do Sprint.

A fase de ps-game consiste no encerramento do release. O desenvolvimento

entrar nesta fase quando os requisitos forem todos atendidos. Nesta fase so

tratadas tambm as tarefas de integrao, testes e documentao.

Existem 5 papis no SCRUM que desempenham diferentes tarefas e

propsitos durante o processo e suas prticas: SCRUM Master, Product Owner,

SCRUMTeam, Cliente e Gerncia. Estes papeis so apresentados de acordo com as

definies de Schwaber e Beedle (1995):

SCRUM Master responsvel por garantir que o projeto seja

conduzido de acordo as prticas, valores e regras do SCRUM e

garantir que o projeto progrida como planejado. Ele interage com

time de projeto, como tambm com os clientes e a gerncia durante

o projeto. Ele tambm responsvel por garantir que quaisquer

impedimentos sejam removidos ou alterados no processo para

manter o time de trabalho sempre produtivo.


23/47

15

Product Owner oficialmente responsvel pelo projeto, pela

gerncia, e controle do PBL. Ele escolhido pelo SCRUM Master, o

cliente e a gerncia. Ele toma as decises finais relacionadas ao

PBL e participa na estimativa de cada item do PBL.

SCRUM Team o equipe de projeto responsvel pelas aes

necessrias produo de cada Sprint.

Customers so os clientes participantes em tarefas relacionadas

aos itens do PBL.

Management responsvel pelas decises, padres e convenses

a serem seguidas pelo projeto.

3.2.3 FAMLIA CRISTAL DE METODOLOGIAS

A metodologia utilizada pela famlia Cristal consiste em um gerenciamento de

projeto por ciclos de desenvolvimento.

A famlia Cristalde metodologias inclui um nmero de diferentes metodologias,

selecionando a que mais se adequar ao projeto em questo. Cada membro da famlia

cristal marcado com um indicador de cor. As cores mais escuras indicam uma

metodologia Heavy. Sugere a escolha da cor apropriada de metodologia para um

projeto baseado em seu tamanho e criticidade. Projetos maiores exigem maiscoordenao e rigor, logo exige as metodologias de cores mais escuras.

H certas regras, vantagens e valores que so comuns a todas as

metodologias na famlia Cristal. Primeiro de tudo, os projetos sempre usam o

desenvolvimento incremental por ciclos com o mximo tamanho dos ciclos de quatro

meses, mas preferencialmente de um a trs meses. A nfase na comunicao e

cooperao das pessoas. As metodologias da famlia Cristal no se limitam em

nenhuma prtica de desenvolvimento, ferramentas ou produtos. As trs principais

metodologias da famlia Cristalso : Crystal Clear, Crystal Orange e Crystal Orange

Web.

Todas as metodologias da famlia Cristal possuem guias de polticas de

padres, produtos de trabalho, ferramentas e papeis a serem seguidos no processo de

desenvolvimento.

O Crystal Clear destinado para pequenos projetos, de no mximo seis

desenvolvedores. O Crystal Orange destinado para projetos mdios, com no mximo


24/47

16

de 40 pessoas e com durao de um a dois anos. No Crystal Orange o projeto

separado entre vrias equipes multifuncionais.

A diferena bsica entre o Crystal Clear e Orange que o primeiro formado

por uma nica equipe, enquanto o segundo, possui vrios grupos multidisciplinares,

esta diviso do projeto em grupos feito atravs do mtodo chamado Estratgia de

diversidade holstica, cuja idia central incluir mltiplos especialistas em um grupo.

No Crystal Clear os principais papis so o patrocinador do projeto,

programador snior, programadores e usurios. Em adio aos papis introduzidos no

Crystal Clear, Crystal Orange sugere outros papis necessrios ao projeto, estes

papis so agrupados em reas, tais como planejamento de sistema, coordenao de

projeto, arquitetura, tecnologia, infra-estrutura e testes. Os grupos do divididos em

estruturas multifuncionais contendo diferentes papis.

A Crystal Orangeintroduz vrios outros papis tais como Designerde interface,

Designer de banco de dados, expert em usabilidade, facilitador tcnico, analista de

negcio, arquiteto, documentadores e testadores. Um membro do grupo pode assumir

mltiplos papis se necessrio.

Figura 3 Incremento Crystal OrangeFonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)

3.2.4 Feature Driven Development(FDD)

FDD uma abordagem gil e adaptativa de desenvolvimento de sistema. OFDD no cobre o processo inteiro de desenvolvimento de software, dando preferncia


25/47

17

ao design e as fases de construo, Palmer e Felsing (2002). Ele preparado para

trabalhar com outras atividades de um projeto de desenvolvimento de software e no

requer qualquer modelo especfico para ser usado, Palmer e Felsing (2002). O FDD

incorpora o desenvolvimento interativo com as melhores prticas efetivas encontradas na

industria. Ele enfatiza aspectos de qualidade atravs de processos e inclue deliveries

freqentes e tangveis, com um acompanhamento preciso de evoluo do projeto.

A FDD consiste em cinco processos seqenciais e prov mtodos, tcnicas e

guias necessrios aos Stakeholders para a entrega do sistema em questo. Alem

disso, o FDD inclue papis, artefatos, objetivos e timeline necessrios em um projeto,

Palmer e Felsing (2002). Ao contrrio de algumas outras metodologias geis, FDD

afirma ser adequada para o desenvolvimento de sistemas crticos, Palmer e Felsing

(2002).Como mencionado antes, o FDD composto de cinco processos seqenciais

que so destinados ao design e construo do sistema. A parte iterativa dos

processos do FDD suporta desenvolvimento gil com adaptaes rpidas a mudanas

no requerimento. A iterao de uma feature envolve uma a trs semanas de trabalho

para equipe.

Figura 4 Fases FDDFonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)

Os processos so descritos abaixo:

a) Modelo Develop an Overall - Neste processo os experts de

domnio j esto cientes do escopo, contexto e requerimentos do sistema

para ser construdo, Palmer e Felsing (2002). Requerimentos

documentados, tais como, casos de uso ou especificaes funcionais so

provveis de existir neste estgio. Os experts de domnio apresentam o

chamado walkthroughno qual os membros da equipe e o arquiteto chefe

so informados detalhadamente sobre o sistema.


26/47

18

b) Construo de uma lista de features O walkthrough,

modelos de objetos e documentos de requerimentos existentes do a base

para construo de uma lista de featurespara o sistema ser desenvolvido.

Nesta lista, a equipe de desenvolvimento apresenta as funes valiosas

para os clientes includas no sistema.

c) Planejamento por Feature O planejamento por feature, inclue

a criao de um plano mais detalhado, no qual o conjunto feature so

seqenciadas de acordo com suas prioridades e dependncias e entregues

aos programadores chefes. Alm disso, as classes identificadas no Modelo

Develop an Overallso designadas aos desenvolvedores, isto , os donos

das classes. O cronograma e principais marcos podem ser definidos neste

processo.d) Design por Feature e Contruo por Feature Um pequeno

grupo de features podem ser escolhidos para serem desenvolvidos. Os

Featuresso produzidos atravs de procedimentos iterativos. As Iteraes

devem durar de poucos a no mximo duas semanas. Podem haver

mltiplos grupos de features realizando o designe a construo de seus

prprios features. Os processos iterativos incluem tarefas como inspeo

de design, codificao, teste, integrao e inspeo de cdigo. Depois do

sucesso da iterao inicia-se uma nova iterao com um novo conjunto de

feature.

O FDD classifica seus papeis em trs categorias: papis chaves, papis de

suporte e papis adicionais, Palmer e Felsing (2002). Os seis papis principais em um

projeto FDD so: Gerente de Projeto, Arquiteto Chefe, Gerente de

Desenvolvimento, Programador Chefe, Dono da Classe e expert de domnios. Os

cinco papis de suporte so: Gerente de Release, Guru de Linguagem, engenheiro de

construo, ToolSmith e Administrador de Sistema. Os trs papis adicionais so:Testadores, Deployers e documentadores tcnicos. Um membro pode ter mltiplos

papis, Palmer e Felsing (2002).

Segue abaixo as tarefas e responsabilidades dos diferentes papis existentes

na FDD, segundo Palmer (2002):

a) Gerente de Projeto o lder administrativo e financeiro do

projeto. Uma de suas tarefas evitar disperses por parte da equipe do

projeto, fazendo que os mesmos mantenham um nvel de trabalho contnuo.


27/47

19

b) Arquiteto Chefe o responsvel por todo o designer do

sistema. Se necessrio este papel pode ser desmembrado em dois:

arquiteto de domnio e arquiteto tcnico.

c) Gerente de Desenvolvimento lidera atividades dirias de

desenvolvimento e resolve qualquer conflito que possa ocorrer dentro do

time. As tarefas do papel podem ser combinadas com as do arquiteto chefe

ou gerente de projeto

d) Programador Chefe um desenvolvedor experiente que

participa na anlise de requisitos e designdos projetos. Ele responsvel

por liderar pequenos times em anlise, designe desenvolvimento de novos

features.

e) Dono da Classe subordinado ao programador chefe nas

tarefas de design, codificao, teste e documentao. Ele responsvel

pelo desenvolvimento de classes.

f) Expert de domnio pode ser um usurio, um cliente, um

patrocinador, um analista de negcio ou uma mistura destes. Ele possui o

conhecimento de como os diferentes requerimentos do sistema devem

funcionar.

g) Gerente de Domnio lidera os expert de domnios e d a palavrafinal quando se trata de divergncias de opinio sobre o requerimentos do

sistema.

h) Gerente de Release controla o progresso do processo atravs

de relatrios dos programadores. Ele reporta o progresso ao gerente de

projeto.

i) Engenheiro do Construo responsvel pelo controle de

verso do sistema e publicao da documentao.

j) Language Guru o detentor do conhecimento de uma

linguagem ou tecnologia especfica.

k) ToolSmith o papel destinado a construo de pequenas

ferramentas para desenvolvimento, teste e converso de dados no projeto.

l) Administrador de Sistema se destina a configurao,

gerenciamento e a descoberta de defeitos nos servidores, rede,

desenvolvimento e ambiente de teste.


28/47

20

m) Testador verifica se o sistema produzido atende aos

requerimentos dos clientes. Pode ser uma equipe independente ou parte do

time do projeto.

n) Deployer trabalham na converso dos dados existentes para

o formato requerido do novo sistema. Pode ser uma equipe independente

ou parte do time do projeto.

o) Documentador Tcnico, responsvel pela documentao

tcnica do sistema. Pode ser uma equipe independente ou parte do time do

projeto.

3.2.5 Mtodo de Desenvolvimento de Sistema Dinmico (MDSD)Desde suas origens em 1994, MDSD, tem se tornado o framewok nmero

para o desenvolvimento de aplicaes rpidas no Reino Unido , Stapleton (1997). A

MDSD um framework sem fins lucrativos mantido por um consrcio que leva o

mesmo nome do mtodo.

A idia principal por trs da MDSD que ao invs de fixar um conjunto de

funcionalidade ao produto e ajustar tempo e recursos para atingi-lo, ele fixa o tempo e

recursos, adaptando as funcionalidades.

A MDSD consiste em cinco fases: Estudo de viabilidade, Estudo do negcio,

Iterao do modelo funcional, iterao do designe construo e implementao. As

duas primeiras fases so seqenciais e so feitas apenas uma vez. As ltimas trs

fases so iterativas e incrementais. As iteraes em MDSD so conhecidas como

caixas de tempo, que podem durar de poucos dias a semanas.

As fases do MDSD so detalhadas abaixo:

a) Estudo de Viabilidade, verifica-se se o MDSD adequado ao projeto. Nesta fase dois produtos so preparados: o

relatrio de viabilidade e o plano de desenvolvimento. Esta fase

rpida e deve levar poucas semanas.

b) Estudo do Negcio fase onde as caractersticas

essenciais e tecnolgicas so analisadas. A abordagem recomendada

organizar workshops, onde um nmero suficiente de experts dos

clientes so reunidos para discutirem sobre todas as funcionalidades do

sistema e definir as prioridades de desenvolvimento. Os processos de


29/47

21

negcio afetados e classes de usurio so descritos na definio de

rea de negcio. Alm da definio da rea de negcio so feitos

tambm a definio da arquitetura do sistema e um plano de

prototipagem.

c) Iterao do modelo funcional, primeira fase iterativa e

incremental. A cada iterao, o contedo e a abordagem da iterao

so planejados e os resultados analisados para iteraes seguintes.

Anlise e codificao so feitas, prottipos so construdos e as

experincias adquiridas so usadas para a melhoria dos modelos de

anlise. O modelo funcional produzido contendo o cdigo do prottipo

e modelos de anlise. Testar tambm uma continua e essencial parte

desta fase. Outros produtos desta fase so a lista de funespriorizadas, documento de reviso das funes do prottipo,

requerimentos no funcionais e anlise de risco.

d) Iterao de design e construo, onde o sistema

realmente construdo.

e) Implementao, fase onde o sistema transferido do

ambiente de desenvolvimento para o ambiente atual de produo. O

treinamento dado aos usurios. Nesta fase incluem-se a entrega do

manual do usurio e o relatrio de reviso de projeto.

O MDSD define 15 papis para usurios e desenvolvedores. Cinco dominantes

esto descritos a seguir:

a) Desenvolvedores e Desenvolvedores seniores, os

desenvolvedores snior estaro na liderana do time de

desenvolvimento. Estes papis englobam todo o staff de

desenvolvimento, que so analistas, designers, programadores e

testadores.

b) Coordenador Tcnico define a arquitetura do sistema e

responsvel pela qualidade tcnica do projeto. Ele tambm

responsvel pelo controle do projeto tcnico, como por exemplo, o

gerenciamento da configurao de software.

c) Usurio Embaixador, responsvel por divulgar entre os

outros usurios o progresso do projeto, garantindo um feedback

adequado aos outros usurios.


30/47

22

d) Visionrio, usurio participante que possui uma

percepo apurada dos objetivos do negcio do sistema e do projeto. O

visionrio provavelmente, aquele que iniciou a idia de construo do

sistema. A tarefa do visionrio garantir que os requerimentos

essenciais sejam encontrados logo e que o projeto mantenha-se na

direo certa com relao a estes requerimentos.

e) Patrocinador Executivo a pessoa da organizao que

tem autoridade e responsabilidade financeira.

Figura 5 Diagrama de Processos do MDSDFonte: Abrahamsson, Salo, Ronkaisen e Warsta (2002)

3.2.6 Desenvolvimento Adaptativo de Software (DAS)

O desenvolvimento adaptativo de software foi desenvolvido por Highsmith

(2000). Muitos dos princpios da DAS deriva da pesquisa de Highsmith em mtodos

iterativos de desenvolvimento. O DAS antecessor do desenvolvimento radical de

software.

O DAS foca-se principalmente em problemas de desenvolvimento complexo e

grandes sistemas. O mtodo encoraja o desenvolvimento iterativo e incremental, com

prototipao constante.

Ele composto por trs fases: Especular, Colaborar e Aprender. Especulao

usada no lugar de planejamento, pois um plano visto como algo que demanda


31/47

23

alguma incerteza que pode ocasionar uma falha. Similarmente, Colaborar reala a

importncia do trabalho de equipe. Aprender enfatiza a necessidade de reconhecer e

reagir a erros e o fato que os requerimentos podem mudar durante o desenvolvimento.

Na iniciao do projeto define-se a misso do projeto, que se destina a

descobrir as informaes para se fazer o projeto. As observaes importantes da

misso so definidas em trs itens: Project vision charter, Project data sheet e product

specification outline. A iniciao do projeto fixa todo o cronograma e objetivos para os

ciclos de desenvolvimento. Os ciclos tipicamente duram de quatro a oito semanas.

O DAS explicitamente orientada a componentes (figura 6). Na prtica, isto

significa que o foco mais em resultados e em sua qualidade, ao contrrio do que

seria se o foco fosse em tarefas ou processos usados para produzir resultados. O

modo como o DAS viabiliza este ponto de vista, atravs de ciclos dedesenvolvimento adaptativos, contido na fase colaborao onde vrios componentes

podem est sendo desenvolvido concorrentemente. O planejamento dos ciclos parte

do processo iterativo e as definies dos componentes so continuamente refinadas

para refletir qualquer nova informao.

Na fase de aprendizagem, a qualidade revista de forma repetitiva, com o foco

na demonstrao da funcionalidade do software desenvolvido durante o ciclo. Um fator

importante de performance nas revises a presena do cliente.

Os principais papis da DAS so: Patrocinador executivo, pessoa que possui

responsabilidade completa pelo desenvolvimento do produto, facilitador para planejar

e liderar as sesses, um escrivo para marcar os minutos, gerente de projeto e cliente.

Figura 6 Diagrama de fases do DASFonte: Abrahamsson, Salo, Ronkaisen e Warsta (2002)


32/47

24

4. eXtreme Project Management(XPM) (BECK, 2001)

XPM consiste em uma abordagem gil de gerenciamento de projetos cuja

caracterstica principal est na sua relao mudana: diferentemente da abordagem

tradicional, na qual o planejamento direcionado aos resultados, ao contrrio da gil,onde os resultados direcionam o planejamento, sendo necessrio facilitar a mudana,

e no desencoraj-la por meio de processos complexos, que restringem e diminuem a

criatividade.

O XPM visa melhorar o gerenciamento de projetos, em especial aos projetos

de software para os quais o tempo e o custo para tornar o produto disponvel no

mercado so crticos, no sendo possvel elaborar um cronograma detalhado e uma

especificao de requisitos em um estgio preliminar do processo, e mostra-se

necessria uma avaliao diria do projeto para adequ-lo situao de mercado. A

meta a entrega do resultado desejado, e no necessariamente o resultado

inicialmente planejado. Ela definida por um conjunto de 11 regras e cinco

ferramentas, descritas a seguir, que possuem como misso dar suporte mudana,

planejando critrios de sucesso para stakeholders, citando cenrios e eventos

principais, definindo benefcios esperados e como atingi-los e estabelecendo acordos

com parceiros e em relao qualidade exigida.

4.1 Regras

4.1.1 XPM Regra 1: A gerncia de pessoas e processos criativos

demanda processos criativos.

No existe uma forma nica e ideal para gerenciar projetos na

dinmica atual do mercado. Tanto gerente quanto equipe precisam ser criativos

no desenvolvimento de um produto inovador, com alto valor para o negcio e

maior qualidade. necessrio considerar no s as expectativas e os requisitos

dos clientes, mas tambm o contexto e as estratgias da prpria organizao,

em busca de um planejamento, monitoramento e controle mais tangvel do

projeto.


33/47

25

4.1.2 XPM Regra 2: Quanto menos o gerente souber sobre questes

tcnicas do projeto, melhor.

O gerente de projeto vai ter que se responsabilizar em

analisar o nmero de variveis complexas para poder desenvolverum plano realstico que no somente identifique as expectativas dos

clientes, requerimentos funcionais especificados, riscos e custos,

mas tambm devem focar-se e entender o contexto organizacional

dentro a qual o projeto est sendo desenvolvido.

Para entender e gerenciar um projeto, o gerente deve fazer

distino entre os aspectos gerenciais e tcnicos.

O gerenciamento tradicional freqentemente confunde o

gerenciamento de projeto com o gerenciamento tcnico. O processo

de gerenciamento tcnico requer um entendimento detalhado do

processo de desenvolvimento de sistema: anlise, design,

programao e teste e consiste em assistncia ao time tcnico. O

gerente tcnico um guru, pessoa que detm profundas

habilidades tcnicas.

O gerente de projeto tem um foco diferente e direcionado

por um conjunto diferente de informaes que no so tcnicas,elas trazem em seu contexto, informaes gerenciais sobre o

projeto. Os aspectos tcnicos e gerenciais so integrados atravs

do escopo, objetivos, estratgias e requerimentos de qualidade do

cliente.

Com a freqente mudana da tecnologia e a complexidade

envolvendo as mais variadas tcnicas de desenvolvimento, torna-se

difcil, se no impossvel para o gerente de projeto ter todas as

habilidades tcnicas necessrias para torn-lo responsvel pelo

gerenciamento tcnico do projeto.

O escopo, objetivos, estratgia e qualidade so um elo de

ligao entre o gerenciamento tcnico e o de projeto. O gerente de

projeto deve definir e concordar com o escopo e objetivos do projeto

como requerido pelo cliente. O analista de sistema deve ento se

focar neste escopo e objetivos acordados para realizar sua anlise e

design.


34/47

26

4.1.3 XPM Regra 3: O que ocorre depois do projeto mais importante do

que ocorre durante o projeto

No gerenciamento tradicional de projeto, aps odesenvolvimento, poucas empresas rastreiam seus custos ou os

benefcios realizados. A ausncia destas informaes no ciclo de

produo deixam o alto escalo sem evidncias do valor agregado

atravs dos novos produtos ou sistemas de informao, o que tem

tambm contribudo para o se ter uma viso errada da Tecnologia

de Informao como um centro de custo.

4.1.4 XPM Regra 4: O planejamento de projeto desenvolvido sem a

participao completa dos stakeholders no mais que a fantasia de uma

nica pessoa

Para ser um sucesso, o planejamento dos e-projectsem um

contexto organizacional contemporneo o gerente de projeto deve

identificar os stakeholdes1chaves relacionados ao projeto e com os

membros do time de projeto realizar um processo de planejamento

de maneira aberta e colaborativa.

Este conceito de gerenciamento de projeto aberto garante

que todos os provedores de servio para o gerente de projeto e

todos os gerentes de projetos nos projetos relacionados estejam

preparados para suportar sua tabela de horrios previamente

estabelecida.

As complexidades internas e externas dos e-projectspodem

simplesmente sobrecarregar uma nica pessoa. Um time tem uma

capacidade maior para garantir que tudo que foi planejado seja

completado e preciso.

Deve ser enfatizado que a abordagem do planejamento

aberto baseada em consenso, o gerente de projeto ainda a

pessoa responsvel. Freqentemente o time envolvido no vai

chegar a um consenso e nestes casos, cabe ao gerente de projeto

1Stakeholders so indivduos ou as organizaes que esto ativamente envolvidos em um projeto cujos interessespodem afetar positivamente ou negativamente o resultado da execuo do projeto


35/47

27

juntamente com o dono ou patrocinador do projeto resolver o

impasse.

O conceito de um encontro de um grande grupo de pessoas

para planejar o projeto pode ser visto como risco e custo, mas

experincias mostram que o processo aberto mais rpido, tem

menos custo e mais preciso. A XPM usa o Planejamento Rpido

(RAP) para produzir planos de projeto um conceito semelhante ao

Desenvolvimento Rpido de Aplicao (RAD)

Quadro 03 : Etapas do Planejamento Rpido (RAP)Etapa Descrio

Definir Sucesso Estabelecer as expectativas que cadaparticipante tem para o sucesso.Definir escopo, objetivos, stakeholders eprojetos relacionados

Analisar o escopo e objetivos do projeto

Analisar os benefcios do projeto Analisar os benefcios gerados aonegcio com o produto, sistema ouservio sendo desenvolvido

Analisar a qualidade do projeto Analisar a qualidade do produto que estsendo gerado

Analisar cenrios / estratgias do projeto Definir as estratgias que devem sertomadas ao longo do projeto

Analisar risco do projeto e desenvolver

um plano de gerenciamento de risco

Estabelecer os riscos para o projeto, a

probabilidade e impacto dos mesmos eum plano de respostas a estes riscos.Desenvolver a lista de tarefas do projeto Estabelecer a lista de tarefas do projetoEstimar as tarefas do projeto Estimar o tempo de concluso para cada

uma das tarefas.Desenvolver cronograma do projeto Elaborar o cronograma das tarefas do

projeto.Fonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)

4.1.5 XPM Regra 5: Quanto mais tempo o gerente de projetos permanecer

com os stakeholdersmelhor

A XPM est envolvida com o contexto do projeto (ambiente

organizacional, social, poltico e financeiro no qual o projeto est

sendo desenvolvido), logo a gerncia do contexto trata do

gerenciamento das expectativas de um conjunto complexo e variado

de stakeholders. O gerenciamento do contexto preocupa-se com o

time de projeto e processos internos envolvendo o desenvolvimento

do produto.


36/47

28

4.1.6 XPM Regra 6: Se o sucesso do projeto no for definido no comeo,

ele nunca ser alcanado no final

Para muitos gerentes de projetos e analistas de sistemas,expectativas so simplesmente aqueles elementos requeridos que

no foram especificados pelos clientes. Para outros, expectativas

so a diferena entre o que o cliente quer e o que eles realmente

precisam. Em uma batalha dura para o gerente de projeto, as

expectativas so uma lista de desejo que inicia uma serie de

negociaes difceis para reduzir estas expectativas. As

expectativas ansiadas pelos clientes so relativas a satisfao dos

stakeholders, atendimento dos objetivos / requerimentos funcionais,

a permanncia dentro do oramento, a manuteno dos prazos,

agregar valor ao negcio, assegurar uma boa qualidade ao produto

e deixar os membros da equipe satisfeitos. A ferramenta sugerida

para o acompanhamento composta por sliders de sucesso, um

indicador que representa o grau de atendimento aos critrios de

sucesso.

4.1.7 XPM Regra 7: Mostre-lhes o lucro: nada mais importa

Mais do que facilitadora de processos, a fora atual da TI reside em tornar o

negcio mais lucrativo e competitivo. Uma anlise cuidadosa do negcio permitir

identificar o valor agregado pelo produto e priorizar funcionalidades a serem

desenvolvidas, visando empregar menos esforo na obteno de mais benefcios. As

ferramentas utilizadas so:

a) O modelo O3 (Objective, Output, Outcome), que cria umacadeia de valores para o projeto, permitindo modelar e perceber os

benefcios associados aos objetivos. Ele parte do princpio de que a

organizao s ser capaz de alcanar seus resultados se o projeto

tiver sucesso na produo de resultados relevantes. Ele est

baseado no modelo IRACIS (Increase Revenue, Avoid Costs and

Improve Services), Thomsett (2002), que possibilita identificar se os

benefcios propostos so realistas ou no.


37/47

29

b)Um Acordo de Qualidade que, a partir dos objetivos do

produto, estabelece os critrios para definir sua qualidade e os

processos presentes no desenvolvimento que iro assegur-la, uma

vez que a melhoria de um atributo de qualidade pode causar

impacto negativo em outro.

4.1.8 XPM Regra 8: Os Stakeholdersdo projeto podem ser seus melhores

aliados ou seus piores inimigos

Depois do principal papel do projeto, o patrocinador, a

segunda causa mais comum de falha de projeto o papel de

stakeholders do projeto e projetos relacionados. Em muitos e-

projects h um conjunto complexo de interdependncias entre o

projeto e seu contexto organizacional.

Existe risco de um stakeholder(como um fornecedor de recursos) ser

deslocado para outro projeto, o que geralmente causa impacto negativo. Na

tentativa de evitar tais situaes, o XPM sugere ao gerente a utilizao de

Acordos de Parceria, uma ferramenta que documenta os servios requeridos, o

tempo e o custo estimado para sua realizao e a identificao de pessoas em

condies de fornecer um retorno sobre os servios para o stakeholder.Manter os stakeholders informados sobre os resultados ajuda a manter uma

boa relao no projeto.

4.1.9 XPM Regra 9: Se voc no pode prever o futuro, no planeje em

detalhe

O XPM abrange planejamento e re-planejamento dirios, como parte

do processo da equipe e dos stakeholders. Todas as alteraes relativas acontexto, externas e internas. Riscos, escopo, objetivos, valor agregado, etc. .

so identificadas e avaliadas diariamente, o que se ajusta extremamente bem

aos conceitos de XP. Na sesso de RAP os principais eventos e cenrios

relacionados entrega do produto so identificados, e somente tarefas que

visem atingir um evento especfico so detalhadas e includas no cronograma.

A ferramenta de planejamento em tempo real de eventos e cenrio uma

extenso simples das prticas de desenvolvimento utilizadas em XP.


38/47

30

4.1.10 XPM Regra 10: Se o seu projeto no mudou, fique apreensivo,

muito apreensivo.

A abordagem mais comum de medio do progresso do projeto o encontro

da equipe com o gerente de projeto no inicio do dia. O foco deste encontro ocontexto e no o contedo, do projeto. Em outras palavras, avaliado se a equipe

est fazendo o que esperado ao projeto.

Estes encontros matinais tentam responder as seguintes questes:

a) Se as expectativas de sucesso mudaram.

b) Se houve alguma mudana no escopo.

c) Se houve alguma mudana relacionada com os stakeholders.

d) Se as premissas de benefcios e custos ainda so relevantes.

e) Se os benefcios adquiridos at ento ainda so relevantes.

f) Se a qualidade mudou.

g) Se houve mudana para os riscos do projeto e gerenciamento de

risco.

Assim, se houver qualquer mudana nos objetivos do projeto um re-

planejamento deve ocorrer imediatamente, at mesmo antes que se inicie qualquertrabalho tcnico.

4.1.11 XPM Regra 11: Em e-projects, um dia um tempo muito longo

O gerenciamento efetivo de e-projectsdemanda uma abordagem

nova e radical para o gerenciamento de projetos. O XPM tem provado em

muitas organizaes ser efetivo e poderoso em gerenciamento de e-

projects.


39/47

31

5. Consideraes Finais

A bibliografia escassa, principalmente nacional, porque o assunto ainda muito

novo, foi a grande dificuldade para que este levantamento pudesse ser realizado. Alm

disso, soma-se a este fato a grande discusso ainda pertinente, de que ogerenciamento das metodologias geis surgem como um novo paradigma para

desenvolvimento de software.

Apesar das dificuldades, houve tempo suficiente para levantar os dados e as

informaes necessrias para que pudssemos gerar as descries explicativas do

gerenciamento destas metodologias geis, principalmente a XPM. Sabemos das

limitaes das informaes, quanto ao no atingimento do universo de metodologias

geis, bem como um detalhamento do eXtreme Programming Management. Contudo

acredita-se que ele so um comeo, uma base para futuros trabalhos que tentem

detalhar essa nova viso, ou ento para trabalhos que sigam a linha de avaliao

dessa metodologia.

Observa-se com o levantamento que, as vantagens e desvantagens da adoo

do paradigma gil de desenvolvimento de software tm sido largamente debatidas.

Uma das principais desvantagens abordadas tem sido a indefinio de como deve ser

conduzida a gerncia de projetos, o que poderia levar a um desenvolvimento catico

sob o ponto de vista gerencial. Esta pesquisa apresenta e discute alguns valores,princpios e prticas estabelecidos para as metodologias geis de desenvolvimento e

gerenciamento de software em relao aos processos e prticas descritos pela

abordagem tradicional de planejamento, monitoramento e controle de projetos,

visando aumentar a credibilidade deste paradigma e incentivar a adoo de uma

cultura gil nas organizaes.

A abordagem gerencial XPM veio complementar as prticas de metodologias

geis existentes e preencher esta lacuna, com diretrizes claras para a liderana de

projetos e introduo de prticas efetivas de gerenciamento que requerem criatividade,

flexibilidade e ateno somadas s qualidades especficas e interaes entre os

membros da equipe. Alm disso, muitas das prticas de gerenciamento de projeto

tradicionais ainda se aplicam a projetos de desenvolvimento geis. Com alguma

adaptao e com uma forte dose de liderana. Na realidade, independentemente das

metodologias geis, outras tendncias em gerenciamento de projetos j indicavam

uma certa convergncia entre a comunidade de gerenciamento e a comunidade

tcnica em relao agilidade. Muitas das prticas geis no so novidades advindas

do XP. Por exemplo, o gerenciamento informal j sinalizava a confiana, a


40/47

32

comunicao, a cooperao e o trabalho em equipe como elementos essenciais para

o sucesso de um projeto, mesmo antes do Manifesto pela Agilidade. J a abordagem

de planejamento ininterrupto, a confiana no processo de desenho evolutivo e o

desenvolvimento dirigido por testes so prticas mais recentes, trazidas pelo XP. A

definio de um processo ideal que seja produtivo gere menos carga que as

metodologias tradicionais e que proporcione garantia de qualidade ao software

produzido ainda um desafio a ser enfrentado e vencido pelos pesquisadores da

Engenharia de Software. Mais do que isso existe um longo caminho a ser

percorrido na busca de processos de software adequados realidade brasileira,

composta principalmente por empresas de software de pequeno porte.

importante salientar que a abordagem gil no estritamente uma

metodologia, mas uma forma de viso e um conjunto de atitudes, valores e princpios.H processo, mas no no senso rigoroso de um processo baseado em papel ou uma

metodologia centrada em controle. Por sua natureza adaptativa e pelo seu foco em

resultados, ela demonstra suprir muito bem as necessidades de cada uma das partes

envolvidas no fornecimento de software: os usurios tm a oportunidade de obter um

sistema mais prximo de suas necessidades; o cliente tem um retorno mais rpido do

seu investimento; os desenvolvedores tm a oportunidade de trabalhar em um

ambiente melhor e o fornecedor se beneficia com o trabalho de equipes mais

eficientes e produtivas. Para colocar estas idias em prtica, porm, preciso que os

desenvolvedores adequem sua forma de desenvolver software, e que o cliente reveja

tambm a sua forma de conduzir e comprar um projeto de software. Para atender aos

anseios do mercado, porm, no basta melhorar apenas o processo de

desenvolvimento de software: necessrio definir objetivos claros para a qualidade,

comprometer toda a equipe com a melhoria contnua, orientar atividades para

resultados de curto prazo, bem como focar na satisfao do cliente e nas

necessidades do mercado. A melhoria de processos deve ser implementada no

apenas com foco na qualidade do produto, mas tambm na sade e longevidade da

empresa, considerando fatores como competncia, produtividade e inovao. Neste

sentido, a cultura da agilidade pode e deve permear todos os processos de uma

organizao. Seu informalismo no pressupe desorganizao, e suas prticas esto

embasadas em muita disciplina. Assim, processos de gesto e realizao do produto

podem ser totalmente concebidos e implementados com base nos princpios e prticas

geis. Por serem mais centradas no desenvolvimento, as metodologias geis

aparentam minimizar o papel do gerenciamento em assegurar sucesso.


41/47

33

Por sua natureza adaptativa e pelo seu foco em resultados, a abordagem gil

de desenvolvimento e gerenciamento demonstra atender melhor s necessidades de

cada uma das partes envolvidas no fornecimento de software: os usurios tm a

oportunidade de obter um sistema mais prximo de suas necessidades; o cliente tem

um retorno mais rpido do seu investimento; os desenvolvedores tm a oportunidade

de trabalhar em um ambiente melhor e o fornecedor se beneficia com o trabalho de

equipes mais eficientes e produtivas.

importante notar que as fases bsicas de um projeto de desenvolvimento gil

so as mesmas de qualquer outro projeto - definir e iniciar o projeto, planejar o projeto,

executar um plano, monitorar e controlar os resultados. A maneira pela qual estes

passos so realizados na abordagem gil, porm, diferente e requer do gerente de

projeto uma reavaliao do conhecimento sobre gerncia tradicional, valores eprticas geis, visando incorpor-los ao seu prprio estilo de gerncia, de forma a

acrescentar valor aos projetos.


42/47

34

REFERNCIAS BIBLIOGRFICAS

BECK, Kent. et. al..Exteme Programming Explained. Addison-Wesley. (1999)

_____,_________.Planning Extreme Programming. Addison-Wesley. (2001a)

KELLY, Kevin. Out of Control: T he New Biology of Machines, Social Systems,and the

Economic World. Addison-Wesley. (1994).

KERZNER, Harold. Gesto de projetos: as melhores prticas. Porto Alegre: Bookman.

(2002).

PMI - Project Management Institute (2004). A Guide to the Project Management Body of

Knowledge. Pennsylvania.

THOMSETT, Rob.Radical Project Management. Prentice Hall. (2002)


43/47

35

REFERNCIAS ELETRNICAS

http://www.agilealliance.org AGILE ALLIANCE (2005) Data de Acesso : 18/01/2007

http://www.ccpace.com/TechnologySolutions/TechnologySolutions_ProjectManagement.htm

AUGUSTINE, Sanjiv. (2005).Agile Project Management Explained. Data de Acesso :

18/01/2007

http://www.agilemanifesto.org BECK, Kent (2001) Manifesto for Agile Software

Development. Data de Acesso : 18/01/2007

http://www.xpuniverse.com/pdfs/agileAndPlanDrivenMethods BOEHM, Barry. (2005) .Agile

and Plan-Driven Methods: Oil and Water? Data de Acesso 18/01/2007

http://www.agilealliance.com/articles HIGHSMITH, Jim. (2005) Does Agility Work? Data de

Acesso : 18/01/2007

http://www.glyn.dk/download/synopsisXPM.pdf JACOBSEN, Catrine M. (2005) XPM from

idea to realization - critical approach to the concept of XPM Data de Acesso :

18/01/2007

http://www.agilealliance.com/articles/searchResults?topic=CMM JEFFRIES, Ron. (2004)

. Extreme Programming and the Capability Maturity Model. Data de Acesso :

18/01/2007

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=666

1 LUDWIG, Charles. (2005). Extreme Project Management. Data de Acesso :

18/01/2007

http://www.cutter.com/research/freestuff/epmr0102.pdf THOMSETT, Rob (2005) Extreme

Project Management - Executive Report., Data de Acesso: 18/01/2007

http://www.inf.utt.fi/pdf/p478.pdf ABRASHAMSSON, Pekka (2002) Agile Software

Development Methods, Data de Acesso : 18/01/2007


44/47

ANEXO

Quadro 3 : Comparativo entre o PMBOK e XPM / Gerenciamento do EscopoProcessosDefinidosnoPMBOK Princpios e Prticas da Abordagem gil

GerenciamentodeEscopo

Assegurar que o projeto inclua todo o trabalho requerido - e somente ele -, visando conclu-lo com

Planejar o escopo: criar um plano quedocumenta como definir,verificarecontrolarescopoeestruturaanaltica

Definir escopo:desenvolverumadeclaraodetalhadado escopoqueservirdebaseparadecisesfuturasCriar estrutura analtica: subdividir principaisentregas e trabalhoemcomponentesmenorese

maisgerenciveisVerificar o escopo: formalizar a aceitao das

entregas queforamconcludasnoprojetoControlarescopo:gerirmudanasdeescopoocorridas

Big Plan:distribuiogeraldeetapaseprodutosgerados Cartes com estrias:definemeformalizamoescopo-o cliente enumera osprincipais casos de uso e define o valoragregadoaonegcioporcadaumJogo do planejamento: Equipe e cliente avaliamcasos de uso, considerando o lado tcnico einteresses do negcio, em busca de consenso

quanto ao escopo de cada release. Seocorrerem mudanas no contedo da releaseque no possam ser absorvidas, o conjunto deestrias redefinido


Quadro 4 : Comparativo entre o PMBOK e XPM / Gerenciamento de CustosProcessosDefinidosnoPMBOK Princpios e Prticas da Abordagem gil

GerenciamentodeCustos

Estimar custos:desenvolverumaaproximaodoscustos dosrecursosnecessriosparaconcluirasatividadesFazer oramentao:alocarestimativasde

custosglobaisaitensindividuais,estabelecerlinhadebasedoscustos

Controlar custos: acompanhar fatores queacarretam variaes nocusto,acompanharmudanasnooramento

Desenvolvimento por iterao: de durao fixa,facilita controlarcustos - senecessrio,negocia-seseuescopo Planejamento de custo amarrado aode tempo:comocada iterao possui durao

fixa, umaestimativa decusto darele

ase podeser obtida a partir do nmero de pessoas

alocadasedeiteraes



45/47

Quadro 5 : Comparativo entre o PMBOK e XPM / Gerenciamento de Riscos

ProcessosDefinidosnoPMBOK Princpios e Prticas da Abordagem gil

Gerenciamento de Riscos

Cuidardaidentificao,anlise,monitoramentoerespostaariscos,visandoaumentaraprobabilidadeeoimpactodoseventospositivosediminuiraprobabilidadeeoimpactodeeventosadversosnosobjetivosdoprojeto

Planejar o gerenciamento de riscos:decidircomoabordar, planejareexecutaratividadesparagerenciarriscos Identificar riscos: determinar riscosque podem afetar o projetoedocumentarsuascaractersticasFazer anlise quantitativa de riscos: priorizar riscopara anliseouao,avaliandosuaprobabilidadeeimpacto Fazer anlise qualitativa de riscos: fazeruma anlise numrica doefeitodosriscosnosobjetivosdoprojeto Planejar respostas a riscos:desenvolver opes e aes paraaumentaroportunidadesereduzirameaas

Monitorar e controlar riscos:executarplanosderespostaa riscoseavaliarsua eficcia durantetodooprojeto

Valores ajudam a controlar e mitigar riscos: abusca da simplicidade diminui a complexidade; arealimentao antecipa a deteco de erros; acomunicao aberta minimizaproblemasrelacionadose a faltadeinformao Prticas ajudama controlar e mitigar riscos:aquebraem iteraes eo planejamento constante ajudam a controlar prazoe custos; cliente disponvel e entrega em releasesdiminuemoriscodeseobterprodutosinadequadosReunies dirias de acompanhamento:possibilitam identificar com antecedncia aiminncia de um risco, permitindo atuar a tempo e

minimizando suas possveis conseqncias


Quadro 6: Comparativo entre o PMBOK e XPM / Gerenciamento de Tempo


GerenciamentodeTempo

Asseguraraconclusodoprojetonoprazoprevisto

Definir atividades: identificar atividadesespecificas a realizarvisandoproduzirosdiversosprodutosprevistos

Sequenciar atividades: identificar edocumentar as relaesdedependnciaentreatividadesdocronograma

Estimar recursos:identificartipoequantidadederecursos paracadaatividadedocronogramaEstimar durao: identificar perodos detrabalho para concluirasatividadesdocronograma

Desenvolver cronograma: analisar recursos,restries, duraoeseqnciadasatividadesedistribuirnotempoControlarcronograma:acompanharmudanas

contra um planejamento inicial detalhado: noincio, o cliente explica os casos deuso, em altonvel, e a equipe calcula o tempo paraimplementao, o que resulta em umaprogramaogrosseira (releases e iteraes), aser refinada medida que o projeto evolui. Senecessrio, gerar prottipos e pesquisarsolues, em busca de uma estimativa maisprecisaReleases decompostas em iteraes : onmero de iteraes pode variar, mas cadaiterao possui durao fixa, o que permiteacompanhar melhor o progresso obtido



46/47

Quadro 7 : Comparativo entre o PMBoK e XPM / Gerenciamento de Qualidade


GerenciamentodeQualidade

Determinarresponsabilidades,objetivosepolticasparaatenderasnecessidadesquemotivaramoprojeto

Planejar a qualidade: identificar padres dqualidade relevantes e determinar a forma dsatisfaz-losGarantir a qualidade: realizar atividades dequalidade planejadas, para garantir que oprojeto empregue todos os processosnecessrios paraatenderaosrequisitosControle da qualidade: monitorar resultadosespecficos do projeto para determinar se elesesto de acordo com padres de qualidade

relevantes e identificar como eliminar ascausasdedesempenhosinsatisfatrios

No formaliza a rea de qualidade: no definegrupo de SQAnematividadesderevisoeauditoriadeprocessos

Diversas prticas relacionadas: desenvolvimentodirigido por testes, uso de padres decodificao, realimentaoo constante,programao aos pares, integrao continuacom suporte de frameworks para testesautomatizados fornecemmtricasreaisdasituadodesenvolvimento

Ao final de cada release: o produto verificado e validadocomocliente.Apsaceito,entraem produo


Quadro 8 : Comparativo entre o PMBOK e XPM / Gerenciamento de Recursos Humanos


GerenciamentodeRecursosHumanosOrganizaregerenciaraequipedoprojeto,fazendousomaisefetivodecompetnciasehabilidades

Planejar recursos humanos: identificar edocumentar funes, responsabilidades e hierarquiano projeto, alm de criarplano degerenciamentodepessoalContratar e mobilizar equipe do projeto: conseguiros recursoshumanosnecessriosparatrabalharnoprojetoDesenvolver a equipe: aperfeioar competncias

e intenso daequipe,melhorarodesempenhodoprojetoGerenciar a equipe: acompanhar desempenho,resolver problemas,obterrealimentao,ecoordenarmudanas

Programao aos pares: permite que uns

099 - gerenciamento de desenvolvimento de software atraves de extreme project management - xpm

Documents