Gerenciamento ágil de projetos de software

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
ESCOLA POLITÉCNICA
DCC/SEGRAC
GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE

ATRAVÉS DE EXTREME PROJECT MANAGEMENT (XPM)
Felipe Barbosa Nogueira
2007
GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVÉS DE
EXTREME PROJECT MANAGEMENT (XPM)
Monografia apresentada no Curso de

Pós-Graduação em Gerenciamento
de Projetos, da Escola Politécnica,
da Universidade Federal do Rio de
Janeiro.
Orientador
George Wosley Barbosa Nogueira Lima
Fortaleza
Janeiro, 2007
Orientador
George Wosley Barbosa Nogueira Lima
Monografia submetida ao Curso de Pós-graduação Gerenciamento de Projetos,

da Escola Politécnica, da Universidade Federal do Rio de Janeiro – UFRJ,
como parte dos requisitos necessários à obtenção do título de Especialista em
Gerenciamento de Projetos.
Aprovado por:
__________________________________________
Prof. Eduardo Linhares Qualharini
__________________________________________
Profª.Fernanda Veras
__________________________________________
Prof. Alexsandro Amarante da Silva
Fortaleza
Janeiro, 2007
ii
NOGUEIRA, Felipe Barbosa.
Gerenciamento de Desenvolvimento de Software
Através de Extreme Project Management (XPM) /
NOGUEIRA, F. B. Fortaleza: UFRJ/EP, 2007.
vii, 35f. il.; 29,7cm.
Orientador: George Wosley Barbosa Nogueira
Lima.
Monografia (especialização) – UFRJ/ Escola
Politécnica/ Curso de Especialização em
Gerenciamento de Projetos, SEGRAC, 2007.
Referências Bibliográficas: f. 33-35
1. Gerenciamento de Projetos. 2. Práticas da
Qualidade I. LIMA, G. W. B. N. II. Universidade Federal
do Rio de Janeiro, Escola Politécnica, Pós-graduação
III. Especialista.
iii
RESUMO

Resumo da Monografia submetida ao corpo docente do curso de Pós-

Graduação em Gerenciamento de Projetos – Universidade Federal do Rio de
Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título 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 disponível
no mercado são críticos, não sendo possível elaborar um cronograma
detalhado e uma especificação de requisitos em um estágio preliminar do
processo, e mostra-se necessária uma avaliação diária do projeto para adequá-
lo à situação de mercado. A meta é a entrega do resultado desejado, e não
necessariamente o resultado inicialmente planejado.
Palavras-chave: Gerenciamento de Projetos, Práticas da Qualidade
Fortaleza
Janeiro, 2007
SUMÁRIO
1. Introdução ________________________________________________________1
2. Gerência Tradicional de Projetos______________________________________3
2.1 História_________________________________________________________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 Características das Metodologias ____________________________________9
3.2 Metodologias Ágeis ______________________________________________10
3.2.1 Extreme Programming (XP) ____________________________________11
3.2.2 SCRUM____________________________________________________13
3.2.3 Família Cristal De Metodologias _________________________________15
3.2.4 Feature Driven Development (FDD) ______________________________16
3.2.5 Método de Desenvolvimento de Sistema Dinâmico (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 gerência de pessoas e processos criativos demanda
processos criativos. _______________________________________________24
4.1.2 XPM Regra 2: Quanto menos o gerente souber sobre questões técnicas 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 participação
completa dos stakeholders não é 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 ____________________________________________27
4.1.6 XPM Regra 6: Se o sucesso do projeto não for definido no começo, ele
nunca será alcançado 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ê não pode prever o futuro, não planeje em detalhe 29
4.1.10 XPM Regra 10: Se o seu projeto não mudou, fique apreensivo, muito
apreensivo. _____________________________________________________30
4.1.11 XPM Regra 11: Em e-projects, um dia é um tempo muito longo _______30
v
5. Considerações Finais ______________________________________________31
Referências Bibliográficas ____________________________________________34
Referencias Eletrônicas_________________________________________35
vi
LISTA DE FIGURAS
Figura 1 Ciclo de vida típico 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 princípios da agilidade________________________________ 9
Quadro 2 Comparativo entre o PMBoK e XPM / Gerenciamento da Integração____ 10
Quadro 3 Etapas do planejamento rápido _________________________________27
LISTA DE SIGLAS
XPM – Extreme Project Management
PMBoK – Project Management Box of Knowledge
XP – Extreme Programming
FDD – Feature Driven Development
MDSD – Método de Desenvolvimento de Sistemas Dinâmicos
DAS – Desenvolvimento Adaptativo de Software
EAP – Estrutura Analítica do Projeto
ANSI – American National Standards Institute
PMI – Project Management Institute
TI – Tecnologia da Informação
RAD - Rapid Application Development
IRACIS – Increase Reveue, Avoid Cost and Improve Services
vii
1. Introdução
Ao longo do tempo, o desenvolvimento de software tem sido rotulado como
uma atividade complexa e marcada por fracassos: prazos e orçamentos não
cumpridos, expectativas não satisfeitas, retorno de investimento muito menor que o
esperado. Uma das principais razões apontadas para isto tem sido a dificuldade de
encontrar a melhor relação entre custo, prazo, escopo e qualidade. Em busca de uma
solução, 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 design mais detalhados,
e garantir o sucesso da execução com gerenciamento e processos bem definidos.
Nesta direção, diversas organizações partiram em busca de uma solução final para
seus problemas: utilizando normas e modelos existentes, definiram processos
organizacionais e técnicos complexos, suportados por muita documentação escrita e
dispensavam a participação do cliente no decorrer do desenvolvimento, Insistindo em
erros comuns de muitos projetos de engenharia, muitas organizações acabaram por
ampliar o tamanho do problema com tentativas de solução.
Por mais que os processos e controles tenham sido definidos, os resultados

acabavam ficando longe da expectativa, pois a construção de software é diferente de
outras construções da engenharia tradicional: um software é, pela sua própria
natureza, intangível; é impossível se antever todas as suas funcionalidades; as
necessidades emergem durante todo o seu desenvolvimento, e vão amadurecendo até
a sua implantação; além disso, a própria utilização do software é que geralmente
impulsiona o aprimoramento de seus recursos. A mudança é, portanto, inevitável e o
não reconhecimento desta realidade leva ao desperdício de recursos em planejamento
e design desnecessários, que acabam sendo descartados posteriormente. Ao procurar
satisfazer custo, prazo, escopo e qualidade, o caminho adotado pela gerência
tradicional de projetos tem sido, a partir de um escopo fechado definir custo e prazo e,
em função do andamento do projeto, manipular a qualidade. Mas será que melhor não
seria ter prazo predefinido, um custo fixo, mantendo os níveis de qualidade e
manipulando o escopo, e por quê não fazer o mais simples primeiro, e refinar depois,
mudando somente e quando for necessário, deixando de gerar documentação
desnecessária para execução do escopo.
Em meio a estes questionamentos, esta pesquisa discute os princípios e

práticas das metodologias ágeis de gerenciamento de software em relação aos
processos e práticas descritas pela abordagem tradicional de planejamento,
2
monitoramento e controle de projetos, buscando mostrar que a adoção da abordagem

ágil pode não só aumentar a credibilidade deste paradigma, mas também ajudar a
elevar a qualidade dos produtos em conseqüência da melhoria da qualidade derivada
das boas práticas empregadas.
3
2. Gerência Tradicional de Projetos

2.1 História
Em 1960, mais e mais executivos renderam-se à busca de novas técnicas de
gerenciamento e estruturas organizacionais que pudessem ser rapidamente
adaptadas ao seu ambiente, o gerenciamento de projeto vem a ser uma nova
ferramenta no auxílio dos trabalhos.
Inicialmente as empresas, como, as do setor aeroespacial, defesa e

construção, as principais da época, mantinham o método 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 organizações teve o primeiro contato com sistemas
de computação. 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 participação tímida por parte dos
clientes, que as repassavam à equipe de TI (Tecnologia de Informação). Os Clientes,
então, só tinham mais alguma participação no processo caso houvesse a necessidade
de mais informação a ser dada. Neste momento o cliente era totalmente dependente
do profissional de TI.
Em 1970 e início de 1980, mais empresas começaram a sair da filosofia

informal de gerenciamento de projeto para um processo mais formalizado de gerência,
tendo em vista o tamanho e complexidade que as atividades estavam assumindo
dificultando o gerenciamento dentro da estrutura utilizada.
O gerenciamento de projeto, então começou, a ganhar força 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 obstáculos internos e externos.
Para o gerenciamento formal de projeto a ser adotado nas empresas,

mudanças eram inevitáveis, para satisfazê-las as organizações voltaram-se para si, a
fim de se reestruturarem. As mudanças então, iniciaram-se. As empresas como as do
setor aeroespacial, defesa e construção, foram pioneiras.
As empresas advogavam que o gerenciamento informal que vinha sendo

aplicado era um sucesso e não viam a aplicação formal do gerenciamento de projeto
com diferencial que os forçasse a mudar. Já as empresas que decidiram implantar
4
esta nova abordagem tinham a seguinte pergunta a responder: “Quanto tempo leva o
período de conversão para esta nova abordagem de gerenciamento?”
Em regra geral isto poderia demandar de dois a três anos para converter a
estrutura tradicional para o gerenciamento estruturado, sendo uma das principais
razões 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
início.
Para Rob Thomsett, (2001), o desenvolvimento de software neste período

caracterizava-se pela fase do tokenismo (tokenism), em que os sistemas
desenvolvidos na fase anterior (Dark Age) foram re-desenvolvidos para tirar vantagem
dos benefícios oferecidos pelas tecnologias de banco de dados, redes e comunicação
que estavam emergindo na época. Esta fase marcou a primeira tentativa de
automatizar novos tipos de sistemas de informação, tais como, gerenciamento de
informação e suporte a decisão.
A partir de 1990, as empresas notaram que a implementação do

gerenciamento de projeto era uma necessidade não uma escolha. A questão então,
era como implementá-lo da forma mais rápida possível.
Para Rob Thomsett (2001), a próxima fase do desenvolvimento de sistema, é

onde a participação 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 pressões sociais forçaram as organizações (públicas e
privadas) a avaliarem os métodos de trabalho, gerencia e planejamento
empreendidos, até então, 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 usuários (clientes), onde as responsabilidades
são divididas e a cooperação dá espaço a uma abordagem bilateral.
2.2 Gerenciamento Informal de Projetos

À medida que o gerenciamento de projetos tornava-se um processo
reconhecido, muita documentação formal passou a ser produzida, visando
principalmente tranqüilizar o cliente. Considerando o tempo consumido na elaboração,
digitação, leitura, cópia, distribuição e arquivamento de documentos, essa
5
formalização resultava em um custo muito alto. Mais grave do que isto, os gerentes de
projeto acabaram ficando tão absorvidos com a documentação a ser gerada que
pouco tempo lhes restava para gerenciar efetivamente o projeto.
Nos últimos 20 anos, porém, esse cenário mudou. Segundo Kerzner (2002), a
mudança mais significativa no campo do gerenciamento de projetos foi a comprovação
de que o gerenciamento informal dá resultados. Com o gerenciamento informal, a
necessidade de documentação foi reduzida para níveis minimamente aceitáveis, e
diretrizes formais foram substituídas por listas de verificação menos detalhadas e mais
genéricas. Gerenciamento Informal é baseado mais em guias do que em políticas e
procedimentos que são as bases do gerenciamento formal de projetos. Mudar da
formalidade para a informalidade exige, porém, uma alteração na cultura da
organização. Kerzner aponta ainda, quatro elementos chave para o sucesso da
implementação da gestão informal de projetos:
Confiança: fundamental na consolidação de uma relação efetiva

entre o fornecedor/ terceirizado e o cliente, a confiança traz inúmeros
benefícios para ambas as partes. Sem ela, gerentes e responsáveis
por projetos precisariam de uma vasta documentação, apenas para
terem a certeza de que todos os encarregados estão cumprindo suas
tarefas da maneira que lhes foi determinada.
Comunicação: em geral, embora os executivos prefiram comunicar-

se verbal ou informalmente, existe a crença de que aquilo que não
foi escrito não foi dito. Um dos pré-requisitos para o gerenciamento
informal de projetos é que os funcionários entendam a estrutura, as
funções e as responsabilidades que terão no âmbito da empresa e
do projeto. Metodologias eficientes de gerenciamento de projetos
promovem não apenas o gerenciamento informal, mas igualmente a
comunicação eficiente, tanto lateral quanto verticalmente. Dois
grandes obstáculos internos a serem superados para desenvolver-se
uma cultura informal são os relatórios e as reuniões longas e
desnecessárias, decorrentes da intervenção dos gerentes em
atividades rotineiras ou do mal direcionamento de informações.
Quando necessária, a comunicação formal deve ser breve e focada
em três questões básicas: qual a situação atual, qual a situação
desejada e se existe algum problema exigindo a interferência da
administração. Nenhum planejamento, por melhor que seja, irá muito
longe sem uma comunicação eficiente.
Cooperação: mais relacionada com a atitude em relação ao trabalho

do que com o trabalho propriamente dito, consiste em ações
6
voluntárias das pessoas para trabalhar em benefício do todo,

buscando um resultado favorável. Sua efetivação não depende da
intervenção 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 , um
recurso quase sempre escasso em projetos.
Trabalho em equipe: desenvolvido por pessoas atuando juntas com

um espírito de cooperação, sob os limites de uma coordenação,
possibilitando: troca de idéias e informações por iniciativa própria;
estabelecimento de altos índices de inovação e criatividade;
confiança e lealdade entre os membros e para com a empresa;
dedicação 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 padrão de
gerenciamento de projetos pelo ANSI (American National Standards Institute), o
PMBoK, PMI, (2004) descreve o conjunto de conhecimentos e as melhores práticas
para o gerenciamento de projetos, podendo ser utilizado para orientar a definição de
um processo padrão para gerenciamento de projetos de software, pois escreve .o que
deve ser feito e não 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 edição do PMBoK, PMI, (2004)
estão organizados em nove áreas de conhecimento ou de atuação gerencial:
Integração descreve os processos e as atividades que integram os

diversos elementos do gerenciamento de projetos, que são
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 declaração do escopo
preliminar do projeto, Desenvolver o plano de gerenciamento do
projeto, Orientar e gerenciar a execução do projeto, Monitorar e
controlar o trabalho do projeto, Controle integrado de mudanças e
Encerrar o projeto.
Escopo descreve os processos envolvidos na verificação de que o

projeto inclui todo o trabalho necessário, e apenas o trabalho
7
necessário, para que seja concluído com sucesso. Ela consiste nos
processos de gerenciamento de projetos: Planejamento do escopo,
Definição do escopo, Criar Estrutura Analítica do Projeto (EAP),
Verificação do escopo e Controle do escopo.
Tempo descreve os processos relativos ao término do projeto no

prazo correto. Ela consiste nos processos de gerenciamento de
projetos: Definição da atividade, Seqüenciamento de atividades,
Estimativa de recursos da atividade, Estimativa de duração da
atividade, Desenvolvimento do cronograma e Controle do
cronograma.
Custos descrevem os processos envolvidos em planejamento,

estimativa, orçamentação e controle de custos, de modo que o
projeto termine dentro do orçamento aprovado. Ela consiste nos
processos de gerenciamento de projetos: Estimativa de custos,
Orçamentação e Controle de custos.
Qualidade descreve 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.
Comunicações descreve os processos relativos à geração, coleta,

disseminação, armazenamento e destinação final das informações
do projeto de forma oportuna e adequada. Ela consiste nos
processos de gerenciamento de projetos: Planejamento das
comunicações, Distribuição das informações, Relatório de
desempenho e Gerenciar as partes interessadas.
Riscos descreve os processos relativos à realização do

gerenciamento de riscos em um projeto. Ele consiste nos processos
de gerenciamento de projetos: Planejamento do gerenciamento de
riscos, Identificação de riscos, Análise qualitativa de riscos, Análise
quantitativa de riscos, Planejamento de respostas a riscos e
Monitoramento e controle de riscos.
8
Aquisições descreve os processos que compram ou adquirem

produtos, serviços ou resultados, além dos processos de
gerenciamento de contratos. Ele consiste nos processos de
gerenciamento de projetos: Planejar compras e aquisições, Planejar
contratações, Solicitar respostas de fornecedores, Selecionar
fornecedores, Administração de contrato e Encerramento do
contrato.
Tais processos encontram-se divididos em cinco grandes grupos: Iniciação

(que autoriza o início do projeto ou de uma fase), Planejamento (que define, refina e
seleciona as melhores alternativas), Execução (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 finalização do projeto ou de uma fase).
9
3. Metodologias Ágeis de Desenvolvimento de Software
3.1 Características das Metodologias

A dificuldade de uso das metodologias de desenvolvimento de software
tradicionais e a alta freqüência com que os projetos de software deixavam de cumprir
seus cronogramas e extrapolavam seus orçamentos levaram, ao final da década de
1990, à elaboração do Manifesto pela Agilidade, Beck (2001) e à criação de uma
organização sem fins lucrativos denominada Aliança Ágil - Agile Alliance (2005), com
a finalidade de divulgar seus princípios, 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 invés de estabelecer
processos, as metodologias ágeis combinam um pequeno número de regras e
práticas, sendo especialmente adequadas para projetos pequenos ou médios (2-10
pessoas), com requisitos imprecisos ou em constante mudança.
Quadro 1. Os doze princípios da agilidade.
Descrição . Princípios da Agilidade

1. A prioridade é a satisfação do cliente, por meio da liberação rápida e contínua de
software de valor.
2. Receba bem as mudanças de requisitos, mesmo em estágios tardios do
desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens
competitivas para o cliente.
3. Libere software freqüentemente, dando preferência 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 indivíduos motivados, dê a eles o ambiente e suporte que
precisam e confie neles.
6. O método mais eficiente e efetivo para repassar informação é pela comunicação direta.
7. Software funcionando é a principal medida de progresso de um projeto de software.
8. Processos ágeis promovem desenvolvimento sustentado. Assim, patrocinadores,
desenvolvedores e usuários
devem ser capazes de manter conversação pacífica indefinidamente.
9. A atenção contínua para a excelência técnica e um bom projeto (design) aprimoram a
agilidade.
10. Simplicidade . a arte de maximizar a quantidade de trabalho não feito . é essencial,
devendo ser sempre
assumida 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 então refinarem e ajustarem seu comportamento.
Fonte: Manifesto da Agilidade , Beck (2001)
10
3.2 Metodologias Ágeis

A abordagem “ágil” propõe a construção de software de forma evolutiva e
adaptativa. A idéia é começar da forma mais simples possível, apenas com o
planejamento e design necessários e resolver as necessidades mais claras e críticas,
agregando valor ao produto e entregando algum resultado rapidamente. Durante todo
o desenvolvimento, o objetivo é ter um software em operação o mais rápido possível,
para que ele tenha condições de evoluir. Deve-se investir ao máximo em simplicidade,
de forma que a mudança deixe de ser traumática e passe a ser natural.
As metodologias “ágeis” apresentam diferenças significativas em relação às

metodologias tradicionais, conforme quadros abaixo, separados por área de
conhecimento, isso ocorre porque os pressupostos são totalmente divergentes.
Conforme observa-se, ambos apresentam pontos fortes e fracos, o importante é
buscar o ponto de equilíbrio, avaliando riscos: o planejamento pode aperfeiçoar a
agilidade, enquanto esta pode dar maior eficiência ao planejamento. Em qualquer
abordagem, porém, as pessoas ativamente envolvidas e suas proposições de valor
possuem grande importância. A seguir, um comparativo entre o PMBoK e as práticas
da abordagem ágil. (quadro 2). No anexo estão os quadros 3, 4, 5, 6, 7, 8, 9, 10
oferecendo comparativos do PMBoK x abordagem ágil para Escopo, Custos, Riscos,
Tempo, Qualidade, RH, Comunicações e Aquisições.
Quadro 2 : Comparativo entre o PMBoK e XPM / Gerenciamento da Integração

Processos Definidos no PMBoK Princípios e Práticas da Abordagem àgil
Gerenciamento de Integração
Identificar, definir, combinar, unificar e coordenar os diversos processos e atividades de
gerenciamento de projetos
Desenvolver o termo de abertura do projeto: Big Plan: identifica a visão e missão do

gerar uma autorização formal de seu início sistema, dá ao cliente e à equipe uma noção geral
Desenvolver a declaração de escopo para as releases
preliminar do projeto: fornecer uma descrição Planos de release e iteração: detalham etapas
de alto nívelvel do escopo especifica e possibilitam o acompanhamento
Desenvolver o plano de gerenciamento do Jogo do planejamento: acompanha toda a
projeto: definir, preparar, integrar e coordenar execução, avaliando prazo, escopo, risco e
planos auxiliares custo, com pouca carga adicional, ainda que de
Orientar e gerenciar a execução do projeto: maneira informal
executar o Cartões com estórias: indexam os casos de
trabalho definido para atingir os requisitos uso, que s„o selecionados pelo cliente para
definidos na declaração de escopo implementação a cada iteração
Monitorar e controlar o trabalho do projeto: Desenvolvimento por iteração: entrega um
atender aos objetivos de desempenho definidos conjunto de funcionalidades, agregando valor ao
no plano de projeto produto e realimentando o planejamento
Controlar mudanças: aprovar solicitações e Reuniões de acompanhamento: possibilitam
coordenar mudanças em produtos e processos, identificar com rapidez a situação atual e a
de forma integrada necessidade de mudança
Encerrar o projeto: finalizar todas as
atividades para encerrar formalmente o projeto
Fonte: Ana Magalhães (2005)
11
3.2.1. Extreme Programming (XP)
A XP é a metodologia de desenvolvimento ágil mais conhecida e utilizada. De

domínio público, possui este nome porque emprega ao extremo algumas boas práticas
da engenharia de software. Ela é descrita por meio de valores, princípios e práticas,
Beck (2001). Os valores descrevem os objetivos de longo prazo ao aplicar XP e
definem critérios de sucesso. Os princípios proporcionam a pequenas e médias
equipes um ambiente de desenvolvimento cooperativo, capaz de atingir altos níveis de
produtividade e um elevado grau de confiança. As práticas estruturam as atividades
básicas do desenvolvimento XP e seguem seus princípios, 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 cliente
analisam a viabilidade do projeto, identificam um escopo geral as macro
funcionalidades da solução e elaboram o plano inicial, denominado Big Plan. O
desenvolvimento ocorre em releases, que são divididas em iterações. No
planejamento do próximo release, equipe técnica e cliente detalham requisitos e
estimam esforço, utilizando Story Cards - cartões que descrevem estórias (requisitos
de usuário) de forma sucinta, possibilitando estimar o esforço envolvido. Os Story
Cards constituem uma ferramenta efetiva para guiar o desenvolvimento, sendo de fácil
manipulação e armazenamento. As estimativas são realizadas em grupo e baseadas
em histórico: atribuem-se pontos às estórias mais simples e, a partir daí, estima-se de
forma comparativa. Quando não se tem idéia da complexidade de uma estória, alguns
experimentos ou implementações são realizados, em busca de mais dados para
realizar a estimativa. A unidade utilizada é ideal weeks. Após estimar todos os Story
Cards, cliente e equipe técnica definem o escopo do próximo release, que deverá
entregar um software de valor, de forma que usuários possam utilizá-lo, perceber
benefícios de seu uso e realimentar os desenvolvedores com pontos positivos e
negativos. O planejamento das iterações é então realizado, refinando o plano do
release. Os desenvolvedores identificam as tarefas contidas nas estórias, estimam sua
duração em “perfect days” e escolhem o que irão implementar o que gera maior
comprometimento e motivação. Durante todo o desenvolvimento é aplicada,
constantemente, a prática de jogo do planejamento.
12
Figura 1. Ciclo de vida típico de um projeto XP

Fonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)
O desenvolvimento, propriamente dito, corresponde à implementação das

estórias selecionadas. A arquitetura é definida e remodelada em seções rápidas de
design, sempre buscando a simplicidade deve-se resolver o problema atual, usando
metáforas, e gerar código preparado para mudar e evoluir. A programação em pares é
uma constante: o driver fica no teclado, focado no que está sendo implementado,
enquanto o partner atua como inspetor, acompanhando a produção do driver, com
trocas ocorrendo várias vezes ao dia. Desenvolvido utilizando um padrão de
codificação, o código gerado é comunitário, sendo freqüentemente reestruturado em
busca de um melhor desempenho e simplicidade. Testes unitários automáticos são
gerados junto com o código, o que motiva e dá mais confiança à equipe. Builds são
gerados a cada integração do código, ocasião em que todos os testes são refeitos. Se
ocorrer erro, qualquer integrante da equipe poderá alterá-lo. Os testes de aceitação
são especificados pelo cliente, que define com o apoio dos testers como quer o
produto. As práticas XP utilizadas em conjunto promovem um processo eficiente de
desenvolvimento do software.
O tracker é o responsável por acompanhar o progresso da iteração, verificando

periodicamente com o programador quantos “perfect days” este já trabalhou na tarefa
e quantos ainda faltam para concluí-la. Reuniões diárias de acompanhamento (stand-
up meetings) são realizadas com o objetivo de verificar a evolução, comunicar
problemas e providenciar soluções. Caso exista algum desvio ou problema, o coach é
alertado para intervir junto à equipe e envolver o cliente, se necessário. Gráficos
visíveis são disponibilizados para acompanhar progresso do projeto, apresentando em
geral estimativas, testes executados, densidade de erros(bugs) e progresso de
estórias.
13
3.2.2 SCRUM
A primeira menção na literatura sobre o termo “SCRUM” surgiu com o artigo de

Takeuchi e Nokata (1986) que dizia ser um processo adaptativo, rápido, alto
organizável. O SCRUM consiste em uma aplicação da abordagem empírica da teoria
de controle do processo industrial para o desenvolvimento de software resultando em
uma abordagem flexível, adaptativa e produtiva. O SCRUM concentra-se em como os
membros da equipe devem agir de forma a produzir sistemas flexíveis em um
ambiente em constante mudança.
A principal idéia do SCRUM é que o desenvolvimento de sistema envolve

várias variáveis técnicas e ambientais que mudam durante o processo, tornando o
desenvolvimento imprevisível e complexo, requerendo flexibilidade do processo de
desenvolvimento de sistema, para torná-lo hábil a responder as mudanças. Suas fases
podem ser vistas na Figura 2.
Figura 2 – Fases SCRUM

Fonte: Abrahamsson, Salo, Ronkaisen e Warsta (2002)
O SCRUM consiste em três 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 são
14
priorizados e o esforço necessário de sua implementação é estimado. O PBL é

constantemente atualizado com novos ou mais detalhes de seus itens, como também
estimativas mais precisas e nova ordem de prioridades. O planejamento inclue
também a definição do time do projeto, ferramentas necessárias e outros recursos,
análise de risco e controle de versões. A cada iteração, o PBL é revisto pelo Time(s)
SCRUM, depois do aceite coletivo com relação à versão nesta iteração, passa-se à
próxima.
Na sub-fase de arquitetura, são planejados detalhes de implementação

baseados nos requerimentos do PBL.
A fase de desenvolvimento (também chamada fase de jogo) é a parte ágil do

SCRUM. Esta fase é tratada como uma “caixa preta” onde o imprevisível é esperado.
As diferentes variáveis técnicas e ambientais (tais como tempo, qualidade,
requerimentos, recursos, implementações tecnológicas e ferramentas) identificados no
SCRUM, que podem mudar no decorrer do processo, são observados e controlados
através de práticas durante os Sprints da fase de desenvolvimento.
Na fase de desenvolvimento o sistema é desenvolvido em Sprints. Os Sprints

são 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, evolução e delivery. A arquitetura e design do
sistema evoluem durante o desenvolvimento do Sprint.
A fase de pós-game consiste no encerramento do release. O desenvolvimento

entrará nesta fase quando os requisitos forem todos atendidos. Nesta fase são
tratadas também as tarefas de integração, testes e documentação.
Existem 5 papéis no SCRUM que desempenham diferentes tarefas e

propósitos durante o processo e suas práticas: SCRUM Master, Product Owner,
SCRUM Team, Cliente e Gerência. Estes papeis são apresentados de acordo com as
definições de Schwaber e Beedle (1995):
SCRUM Master é responsável por garantir que o projeto seja

conduzido de acordo as práticas, valores e regras do SCRUM e
garantir que o projeto progrida como planejado. Ele interage com
time de projeto, como também com os clientes e a gerência durante
o projeto. Ele também é responsável por garantir que quaisquer
impedimentos sejam removidos ou alterados no processo para
manter o time de trabalho sempre produtivo.
15
Product Owner é oficialmente responsável pelo projeto, pela

gerência, e controle do PBL. Ele é escolhido pelo SCRUM Master, o
cliente e a gerência. Ele toma as decisões finais relacionadas ao
PBL e participa na estimativa de cada item do PBL.
SCRUM Team é o equipe de projeto responsável pelas ações

necessárias à produção de cada Sprint.
Customers são os clientes participantes em tarefas relacionadas

aos itens do PBL.
Management é responsável pelas decisões, padrões e convensões

a serem seguidas pelo projeto.
3.2.3 FAMÍLIA CRISTAL DE METODOLOGIAS
A metodologia utilizada pela família Cristal consiste em um gerenciamento de

projeto por ciclos de desenvolvimento.
A família Cristal de metodologias inclui um número de diferentes metodologias,

selecionando a que mais se adequar ao projeto em questão. Cada membro da família
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 mais
coordenação e rigor, logo exige as metodologias de cores mais escuras.
Há certas regras, vantagens e valores que são comuns a todas as

metodologias na família Cristal. Primeiro de tudo, os projetos sempre usam o
desenvolvimento incremental por ciclos com o máximo tamanho dos ciclos de quatro
meses, mas preferencialmente de um a três meses. A ênfase é na comunicação e
cooperação das pessoas. As metodologias da família Cristal não se limitam em
nenhuma prática de desenvolvimento, ferramentas ou produtos. As três principais
metodologias da família Cristal são : Crystal Clear, Crystal Orange e Crystal Orange
Web.
Todas as metodologias da família Cristal possuem guias de políticas de

padrões, produtos de trabalho, ferramentas e papeis a serem seguidos no processo de
desenvolvimento.
O Crystal Clear é destinado para pequenos projetos, de no máximo seis

desenvolvedores. O Crystal Orange é destinado para projetos médios, com no máximo
16
de 40 pessoas e com duração de um a dois anos. No Crystal Orange o projeto é

separado entre várias equipes multifuncionais.
A diferença básica entre o Crystal Clear e Orange é que o primeiro é formado

por uma única equipe, enquanto o segundo, possui vários grupos multidisciplinares,
esta divisão do projeto em grupos é feito através do método chamado “Estratégia de
diversidade holística”, cuja idéia central é incluir múltiplos especialistas em um grupo.
No Crystal Clear os principais papéis são o patrocinador do projeto,

programador sênior, programadores e usuários. Em adição aos papéis introduzidos no
Crystal Clear, Crystal Orange sugere outros papéis necessários ao projeto, estes
papéis são agrupados em áreas, tais como planejamento de sistema, coordenação de
projeto, arquitetura, tecnologia, infra-estrutura e testes. Os grupos dão divididos em
estruturas multifuncionais contendo diferentes papéis.
A Crystal Orange introduz vários outros papéis tais como Designer de interface,
Designer de banco de dados, expert em usabilidade, facilitador técnico, analista de
negócio, arquiteto, documentadores e testadores. Um membro do grupo pode assumir
múltiplos papéis se necessário.
Figura 3 – Incremento Crystal Orange

3.2.4 Feature Driven Development (FDD)
FDD é uma abordagem ágil e adaptativa de desenvolvimento de sistema. O

FDD não cobre o processo inteiro de desenvolvimento de software, dando preferência
17
ao design e as fases de construção, Palmer e Felsing (2002). Ele é preparado para

trabalhar com outras atividades de um projeto de desenvolvimento de software e não
requer qualquer modelo específico para ser usado, Palmer e Felsing (2002). O FDD
incorpora o desenvolvimento interativo com as melhores práticas efetivas encontradas na
industria. Ele enfatiza aspectos de qualidade através de processos e inclue deliveries
freqüentes e tangíveis, com um acompanhamento preciso de evolução do projeto.
A FDD consiste em cinco processos seqüenciais e provê métodos, técnicas e

guias necessários aos “Stakeholders” para a entrega do sistema em questão. Alem
disso, o FDD inclue papéis, artefatos, objetivos e “timeline” necessários em um projeto,
Palmer e Felsing (2002). Ao contrário de algumas outras metodologias ágeis, FDD
afirma ser adequada para o desenvolvimento de sistemas críticos, Palmer e Felsing
(2002).
Como mencionado antes, o FDD é composto de cinco processos seqüenciais

que são destinados ao design e construção do sistema. A parte iterativa dos
processos do FDD suporta desenvolvimento ágil com adaptações rápidas a mudanças
no requerimento. A iteração de uma “feature” envolve uma a três semanas de trabalho
para equipe.
Figura 4 – Fases FDD

Os processos são descritos abaixo:
a) Modelo Develop an Overall - Neste processo os experts de

domínio já estão cientes do escopo, contexto e requerimentos do sistema
para ser construído, Palmer e Felsing (2002). Requerimentos
documentados, tais como, casos de uso ou especificações funcionais são
prováveis de existir neste estágio. Os experts de domínio apresentam o
chamado walkthrough no qual os membros da equipe e o arquiteto chefe
são informados detalhadamente sobre o sistema.
18
b) Construção de uma lista de features – O “walkthrough”,

modelos de objetos e documentos de requerimentos existentes dão a base
para construção de uma lista de features para o sistema ser desenvolvido.
Nesta lista, a equipe de desenvolvimento apresenta as funções valiosas
para os clientes incluídas no sistema.
c) Planejamento por Feature – O planejamento por feature, inclue

a criação de um plano mais detalhado, no qual o conjunto feature são
seqüenciadas de acordo com suas prioridades e dependências e entregues
aos programadores chefes. Além disso, as classes identificadas no Modelo
Develop an Overall são designadas aos desenvolvedores, isto é, os donos
das classes. O cronograma e principais marcos podem ser definidos neste
processo.
d) Design por Feature e Contrução por Feature – Um pequeno

grupo de features podem ser escolhidos para serem desenvolvidos. Os
Features são produzidos através de procedimentos iterativos. As Iterações
devem durar de poucos a no máximo duas semanas. Podem haver
múltiplos grupos de features realizando o design e a construção de seus
próprios features. Os processos iterativos incluem tarefas como inspeção
de design, codificação, teste, integração e inspeção de código. Depois do
sucesso da iteração inicia-se uma nova iteração com um novo conjunto de
feature.
O FDD classifica seus papeis em três categorias: papéis chaves, papéis de

suporte e papéis adicionais, Palmer e Felsing (2002). Os seis papéis principais em um
projeto FDD são: Gerente de Projeto, Arquiteto Chefe, Gerente de
Desenvolvimento, Programador Chefe, Dono da Classe e expert de domínios. Os
cinco papéis de suporte são: Gerente de Release, Guru de Linguagem, engenheiro de
construção, “ToolSmith” e Administrador de Sistema. Os três papéis adicionais são:
Testadores, “Deployers” e documentadores técnicos. Um membro pode ter múltiplos
papéis, Palmer e Felsing (2002).
Segue abaixo as tarefas e responsabilidades dos diferentes papéis existentes

na FDD, segundo Palmer (2002):
a) Gerente de Projeto é o líder administrativo e financeiro do

projeto. Uma de suas tarefas é evitar dispersões por parte da equipe do
projeto, fazendo que os mesmos mantenham um nível de trabalho contínuo.
19
b) Arquiteto Chefe é o responsável por todo o designer do

sistema. Se necessário este papel pode ser desmembrado em dois:
arquiteto de domínio e arquiteto técnico.
c) Gerente de Desenvolvimento lidera atividades diárias 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 análise de requisitos e design dos projetos. Ele é responsável
por liderar pequenos times em análise, design e desenvolvimento de novos
features.
e) Dono da Classe é subordinado ao programador chefe nas

tarefas de design, codificação, teste e documentação. Ele é responsável
pelo desenvolvimento de classes.
f) Expert de domínio pode ser um usuário, um cliente, um

patrocinador, um analista de negócio ou uma mistura destes. Ele possui o
conhecimento de como os diferentes requerimentos do sistema devem
funcionar.
g) Gerente de Domínio lidera os expert de domínios e dá a palavra

final quando se trata de divergências de opinião sobre o requerimentos do
sistema.
h) Gerente de Release controla o progresso do processo através

de relatórios dos programadores. Ele reporta o progresso ao gerente de
projeto.
i) Engenheiro do Construção responsável pelo controle de

versão do sistema e publicação da documentação.
j) Language Guru é o detentor do conhecimento de uma

linguagem ou tecnologia específica.
k) “ToolSmith” é o papel destinado a construção de pequenas

ferramentas para desenvolvimento, teste e conversão de dados no projeto.
l) Administrador de Sistema se destina a configuração,

gerenciamento e a descoberta de defeitos nos servidores, rede,
desenvolvimento e ambiente de teste.
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 conversão dos dados existentes para

o formato requerido do novo sistema. Pode ser uma equipe independente
ou parte do time do projeto.
o) Documentador Técnico, responsável pela documentação

técnica do sistema. Pode ser uma equipe independente ou parte do time do
projeto.
3.2.5 Método de Desenvolvimento de Sistema Dinâmico (MDSD)
Desde suas origens em 1994, MDSD, tem se tornado o “framewok” número

para o desenvolvimento de aplicações rápidas no Reino Unido , Stapleton (1997). A
MDSD é um “framework” sem fins lucrativos mantido por um consórcio que leva o
mesmo nome do método.
A idéia principal por trás da MDSD é que ao invés 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 negócio,

Iteração do modelo funcional, iteração do design e construção e implementação. As
duas primeiras fases são seqüenciais e são feitas apenas uma vez. As últimas três
fases são iterativas e incrementais. As iterações em MDSD são conhecidas como
“caixas de tempo”, que podem durar de poucos dias a semanas.
As fases do MDSD são detalhadas abaixo:
a) Estudo de Viabilidade, verifica-se se o MDSD é

adequado ao projeto. Nesta fase dois produtos são preparados: o
relatório de viabilidade e o plano de desenvolvimento. Esta fase é
rápida e deve levar poucas semanas.
b) Estudo do Negócio é fase onde as características

essenciais e tecnológicas são analisadas. A abordagem recomendada é
organizar “workshops”, onde um número suficiente de experts dos
clientes são reunidos para discutirem sobre todas as funcionalidades do
sistema e definir as prioridades de desenvolvimento. Os processos de
21
negócio afetados e classes de usuário são descritos na definição de

área de negócio. Além da definição da área de negócio são feitos
também a definição da arquitetura do sistema e um plano de
prototipagem.
c) Iteração do modelo funcional, primeira fase iterativa e

incremental. A cada iteração, o conteúdo e a abordagem da iteração
são planejados e os resultados analisados para iterações seguintes.
Análise e codificação são feitas, protótipos são construídos e as
experiências adquiridas são usadas para a melhoria dos modelos de
análise. O modelo funcional é produzido contendo o código do protótipo
e modelos de análise. Testar é também uma continua e essencial parte
desta fase. Outros produtos desta fase são a lista de funções
priorizadas, documento de revisão das funções do protótipo,
requerimentos não funcionais e análise de risco.
d) Iteração de design e construção, onde o sistema é

realmente construído.
e) Implementação, fase onde o sistema é transferido do

ambiente de desenvolvimento para o ambiente atual de produção. O
treinamento é dado aos usuários. Nesta fase incluem-se a entrega do
manual do usuário e o relatório de revisão de projeto.
O MDSD define 15 papéis para usuários e desenvolvedores. Cinco dominantes

estão descritos a seguir:
a) Desenvolvedores e Desenvolvedores seniores, os

desenvolvedores sênior estarão na liderança do time de
desenvolvimento. Estes papéis englobam todo o staff de
desenvolvimento, que são analistas, designers, programadores e
testadores.
b) Coordenador Técnico define a arquitetura do sistema e

é responsável pela qualidade técnica do projeto. Ele também é
responsável pelo controle do projeto técnico, como por exemplo, o
gerenciamento da configuração de software.
c) Usuário Embaixador, responsável por divulgar entre os

outros usuários o progresso do projeto, garantindo um “feedback”
adequado aos outros usuários.
22
d) Visionário, usuário participante que possui uma

percepção apurada dos objetivos do negócio do sistema e do projeto. O
visionário é provavelmente, aquele que iniciou a idéia de construção do
sistema. A tarefa do visionário é garantir que os requerimentos
essenciais sejam encontrados logo e que o projeto mantenha-se na
direção certa com relação a estes requerimentos.
e) Patrocinador Executivo é a pessoa da organização que

tem autoridade e responsabilidade financeira.
Figura 5 – Diagrama de Processos do MDSD

3.2.6 Desenvolvimento Adaptativo de Software (DAS)
O desenvolvimento adaptativo de software foi desenvolvido por Highsmith

(2000). Muitos dos princípios da DAS deriva da pesquisa de Highsmith em métodos
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 método encoraja o desenvolvimento iterativo e incremental, com
prototipação constante.
Ele é composto por três fases: Especular, Colaborar e Aprender. Especulação

é usada no lugar de planejamento, pois um plano é visto como algo que demanda
23
alguma incerteza que pode ocasionar uma falha. Similarmente, Colaborar realça a
importância 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 iniciação do projeto define-se a missão do projeto, que se destina a

descobrir as informações para se fazer o projeto. As observações importantes da
missão são definidas em três itens: Project vision charter, Project data sheet e product
specification outline. A iniciação 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 prática, isto

significa que o foco é mais em resultados e em sua qualidade, ao contrário 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, é através de ciclos de
desenvolvimento adaptativos, contido na fase colaboração onde vários componentes
podem está sendo desenvolvido concorrentemente. O planejamento dos ciclos é parte
do processo iterativo e as definições dos componentes são continuamente refinadas
para refletir qualquer nova informação.
Na fase de aprendizagem, a qualidade é revista de forma repetitiva, com o foco

na demonstração da funcionalidade do software desenvolvido durante o ciclo. Um fator
importante de performance nas revisões é a presença do cliente.
Os principais papéis da DAS são: Patrocinador executivo, pessoa que possui

responsabilidade completa pelo desenvolvimento do produto, facilitador para planejar
e liderar as sessões, um escrivão para marcar os minutos, gerente de projeto e cliente.
Figura 6 – Diagrama de fases do DAS

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

XPM consiste em uma abordagem ágil de gerenciamento de projetos cuja
característica principal está na sua relação à mudança: diferentemente da abordagem
tradicional, na qual o planejamento é direcionado aos resultados, ao contrário da ágil,
onde os resultados direcionam o planejamento, sendo necessário facilitar a mudança,
e não 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 disponível no
mercado são críticos, não sendo possível elaborar um cronograma detalhado e uma
especificação de requisitos em um estágio preliminar do processo, e mostra-se
necessária uma avaliação diária do projeto para adequá-lo à situação de mercado. A
meta é a entrega do resultado desejado, e não necessariamente o resultado
inicialmente planejado. Ela é definida por um conjunto de 11 regras e cinco
ferramentas, descritas a seguir, que possuem como missão dar suporte à mudança,
planejando critérios de sucesso para stakeholders, citando cenários e eventos
principais, definindo benefícios esperados e como atingi-los e estabelecendo acordos
com parceiros e em relação à qualidade exigida.
4.1 Regras
4.1.1 XPM Regra 1: A gerência de pessoas e processos criativos

demanda processos criativos.
Não existe uma forma única e ideal para gerenciar projetos na

dinâmica atual do mercado. Tanto gerente quanto equipe precisam ser criativos
no desenvolvimento de um produto inovador, com alto valor para o negócio e
maior qualidade. É necessário considerar não só as expectativas e os requisitos
dos clientes, mas também o contexto e as estratégias da própria organização,
em busca de um planejamento, monitoramento e controle mais tangível do
projeto.
25
4.1.2 XPM Regra 2: Quanto menos o gerente souber sobre questões

técnicas do projeto, melhor.
O gerente de projeto vai ter que se responsabilizar em

analisar o número de variáveis complexas para poder desenvolver
um plano realístico que não somente identifique as expectativas dos
clientes, requerimentos funcionais especificados, riscos e custos,
mas também 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

distinção entre os aspectos gerenciais e técnicos.
O gerenciamento tradicional freqüentemente confunde o

gerenciamento de projeto com o gerenciamento técnico. O processo
de gerenciamento técnico requer um entendimento detalhado do
processo de desenvolvimento de sistema: análise, design,
programação e teste e consiste em assistência ao time técnico. O
gerente técnico é um “guru”, pessoa que detém profundas
habilidades técnicas.
O gerente de projeto tem um foco diferente e é direcionado

por um conjunto diferente de informações que não são técnicas,
elas trazem em seu contexto, informações gerenciais sobre o
projeto. Os aspectos técnicos e gerenciais são integrados através
do escopo, objetivos, estratégias e requerimentos de qualidade do
cliente.
Com a freqüente mudança da tecnologia e a complexidade

envolvendo as mais variadas técnicas de desenvolvimento, torna-se
difícil, se não impossível para o gerente de projeto ter todas as
habilidades técnicas necessárias para torná-lo responsável pelo
gerenciamento técnico do projeto.
O escopo, objetivos, estratégia e qualidade são um elo de

ligação entre o gerenciamento técnico 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 então se
focar neste escopo e objetivos acordados para realizar sua análise e
design.
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, após o

desenvolvimento, poucas empresas rastreiam seus custos ou os
benefícios realizados. A ausência destas informações no ciclo de
produção deixam o alto escalão sem evidências do valor agregado
através dos novos produtos ou sistemas de informação, o que tem
também contribuído para o se ter uma visão errada da Tecnologia
de Informação como um centro de custo.
4.1.4 XPM Regra 4: O planejamento de projeto desenvolvido sem a

participação completa dos stakeholders não é mais que a fantasia de uma
única pessoa
Para ser um sucesso, o planejamento dos e-projects em um

contexto organizacional contemporâneo o gerente de projeto deve
identificar os stakeholdes1 chaves 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 serviço para o gerente de projeto e
todos os gerentes de projetos nos projetos relacionados estejam
preparados para suportar sua tabela de horários previamente
estabelecida.
As complexidades internas e externas dos e-projects podem

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 responsável. Freqüentemente o time envolvido não vai
chegar a um consenso e nestes casos, cabe ao gerente de projeto
1
Stakeholders são indivíduos ou as organizações que estão ativamente envolvidos em um projeto cujos interesses
podem afetar positivamente ou negativamente o resultado da execução do projeto
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
experiências mostram que o processo aberto é mais rápido, tem
menos custo e mais preciso. A XPM usa o Planejamento Rápido
(RAP) para produzir planos de projeto – um conceito semelhante ao
Desenvolvimento Rápido de Aplicação (RAD)
Quadro 03 : Etapas do Planejamento Rápido (RAP)

Etapa Descrição
Definir Sucesso Estabelecer as expectativas que cada
participante tem para o sucesso.
Definir escopo, objetivos, stakeholders e Analisar o escopo e objetivos do projeto
projetos relacionados
Analisar os benefícios do projeto Analisar os benefícios gerados ao
negócio com o produto, sistema ou
serviço sendo desenvolvido
Analisar a qualidade do projeto Analisar a qualidade do produto que está
sendo gerado
Analisar cenários / estratégias do projeto Definir as estratégias que devem ser
tomadas ao longo do projeto
Analisar risco do projeto e desenvolver Estabelecer os riscos para o projeto, a
um plano de gerenciamento de risco probabilidade e impacto dos mesmos e
um plano de respostas a estes riscos.
Desenvolver a lista de tarefas do projeto Estabelecer a lista de tarefas do projeto
Estimar as tarefas do projeto Estimar o tempo de conclusão para cada
uma das tarefas.
Desenvolver cronograma do projeto Elaborar o cronograma das tarefas do
projeto.
4.1.5 XPM Regra 5: Quanto mais tempo o gerente de projetos permanecer

com os stakeholders melhor
A XPM está envolvida com o contexto do projeto (ambiente

organizacional, social, político e financeiro no qual o projeto está
sendo desenvolvido), logo a gerência 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.
28
4.1.6 XPM Regra 6: Se o sucesso do projeto não for definido no começo,

ele nunca será alcançado no final
Para muitos gerentes de projetos e analistas de sistemas,

expectativas são simplesmente aqueles elementos requeridos que
não foram especificados pelos clientes. Para outros, expectativas
são a diferença entre o que o cliente quer e o que eles realmente
precisam. Em uma batalha dura para o gerente de projeto, as
expectativas são uma lista de desejo que inicia uma serie de
negociações difíceis para reduzir estas expectativas. As
expectativas ansiadas pelos clientes são relativas a satisfação dos
stakeholders, atendimento dos objetivos / requerimentos funcionais,
a permanência dentro do orçamento, a manutenção dos prazos,
agregar valor ao negócio, 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 critérios de
sucesso.
4.1.7 XPM Regra 7: Mostre-lhes o lucro: nada mais importa
Mais do que facilitadora de processos, a força atual da TI reside em tornar o

negócio mais lucrativo e competitivo. Uma análise cuidadosa do negócio permitirá
identificar o valor agregado pelo produto e priorizar funcionalidades a serem
desenvolvidas, visando empregar menos esforço na obtenção de mais benefícios. As
ferramentas utilizadas são:
a) O modelo O3 (Objective, Output, Outcome), que cria uma

cadeia de valores para o projeto, permitindo modelar e perceber os
benefícios associados aos objetivos. Ele parte do princípio de que a
organização só será capaz de alcançar seus resultados se o projeto
tiver sucesso na produção de resultados relevantes. Ele está
baseado no modelo IRACIS (Increase Revenue, Avoid Costs and
Improve Services), Thomsett (2002), que possibilita identificar se os
benefícios propostos são realistas ou não.
29
b) Um Acordo de Qualidade que, a partir dos objetivos do

produto, estabelece os critérios para definir sua qualidade e os
processos presentes no desenvolvimento que irão 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 Stakeholders do 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 interdependências 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 situações, o XPM sugere ao gerente a utilização de
Acordos de Parceria, uma ferramenta que documenta os serviços requeridos, o
tempo e o custo estimado para sua realização e a identificação de pessoas em
condições de fornecer um retorno sobre os serviços para o stakeholder.
Manter os stakeholders informados sobre os resultados ajuda a manter uma
boa relação no projeto.
4.1.9 XPM Regra 9: Se você não pode prever o futuro, não planeje em
detalhe
O XPM abrange planejamento e re-planejamento diários, como parte

do processo da equipe e dos stakeholders. Todas as alterações relativas a
contexto, externas e internas. Riscos, escopo, objetivos, valor agregado, etc. .
são identificadas e avaliadas diariamente, o que se ajusta extremamente bem
aos conceitos de XP. Na sessão de RAP os principais eventos e cenários
relacionados à entrega do produto são identificados, e somente tarefas que
visem atingir um evento específico são detalhadas e incluídas no cronograma.
A ferramenta de planejamento em tempo real de eventos e cenário é uma
extensão simples das práticas de desenvolvimento utilizadas em XP.
30
4.1.10 XPM Regra 10: Se o seu projeto não mudou, fique apreensivo,
muito apreensivo.
A abordagem mais comum de medição do progresso do projeto é o encontro

da equipe com o gerente de projeto no inicio do dia. O foco deste encontro é o
contexto e não o conteúdo, do projeto. Em outras palavras, é avaliado se a equipe
está fazendo o que é esperado ao projeto.
Estes encontros matinais tentam responder as seguintes questões:
a) Se as expectativas de sucesso mudaram.
b) Se houve alguma mudança no escopo.
c) Se houve alguma mudança relacionada com os stakeholders.
d) Se as premissas de benefícios e custos ainda são relevantes.
e) Se os benefícios adquiridos até então ainda são relevantes.
f) Se a qualidade mudou.
g) Se houve mudança para os riscos do projeto e gerenciamento de

risco.
Assim, se houver qualquer mudança nos objetivos do projeto um re-

planejamento deve ocorrer imediatamente, até mesmo antes que se inicie qualquer
trabalho técnico.
4.1.11 XPM Regra 11: Em e-projects, um dia é um tempo muito longo
O gerenciamento efetivo de e-projects demanda uma abordagem

nova e radical para o gerenciamento de projetos. O XPM tem provado em
muitas organizações ser efetivo e poderoso em gerenciamento de e-
projects.
31
5. Considerações Finais
A bibliografia escassa, principalmente nacional, porque o assunto ainda é muito
novo, foi a grande dificuldade para que este levantamento pudesse ser realizado. Além
disso, soma-se a este fato a grande discussão ainda pertinente, de que o
gerenciamento das metodologias ágeis surgem como um novo paradigma para
desenvolvimento de software.
Apesar das dificuldades, houve tempo suficiente para levantar os dados e as

informações necessárias para que pudéssemos gerar as descrições explicativas do
gerenciamento destas metodologias ágeis, principalmente a XPM. Sabemos das
limitações das informações, quanto ao não atingimento do universo de metodologias
ágeis, bem como um detalhamento do eXtreme Programming Management. Contudo
acredita-se que ele são um começo, uma base para futuros trabalhos que tentem
detalhar essa nova visão, ou então para trabalhos que sigam a linha de avaliação
dessa metodologia.
Observa-se com o levantamento que, as vantagens e desvantagens da adoção

do paradigma ágil de desenvolvimento de software têm sido largamente debatidas.
Uma das principais desvantagens abordadas tem sido a indefinição de como deve ser
conduzida a gerência de projetos, o que poderia levar a um desenvolvimento caótico
sob o ponto de vista gerencial. Esta pesquisa apresenta e discute alguns valores,
princípios e práticas estabelecidos para as metodologias ágeis de desenvolvimento e
gerenciamento de software em relação aos processos e práticas descritos pela
abordagem tradicional de planejamento, monitoramento e controle de projetos,
visando aumentar a credibilidade deste paradigma e incentivar a adoção de uma
cultura ágil nas organizações.
A abordagem gerencial XPM veio complementar as práticas de metodologias

ágeis existentes e preencher esta lacuna, com diretrizes claras para a liderança de
projetos e introdução de práticas efetivas de gerenciamento que requerem criatividade,
flexibilidade e atenção somadas às qualidades específicas e interações entre os
membros da equipe. Além disso, muitas das práticas de gerenciamento de projeto
tradicionais ainda se aplicam a projetos de desenvolvimento ágeis. Com alguma
adaptação e com uma forte dose de liderança. Na realidade, independentemente das
metodologias ágeis, outras tendências em gerenciamento de projetos já indicavam
uma certa convergência entre a comunidade de gerenciamento e a comunidade
técnica em relação à agilidade. Muitas das práticas ágeis não são novidades advindas
do XP. Por exemplo, o gerenciamento informal já sinalizava a confiança, a
32
comunicação, a cooperação 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 confiança no processo de desenho evolutivo e o
desenvolvimento dirigido por testes são práticas mais recentes, trazidas pelo XP. A
definição 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” não é estritamente uma

metodologia, mas uma forma de visão e um conjunto de atitudes, valores e princípios.
Há processo, mas não 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 usuários têm a oportunidade de obter um
sistema mais próximo de suas necessidades; o cliente tem um retorno mais rápido do
seu investimento; os desenvolvedores têm 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 idéias em prática, porém, é preciso que os
desenvolvedores adequem sua forma de desenvolver software, e que o cliente reveja
também a sua forma de conduzir e comprar um projeto de software. Para atender aos
anseios do mercado, porém, não basta melhorar apenas o processo de
desenvolvimento de software: é necessário definir objetivos claros para a qualidade,
comprometer toda a equipe com a melhoria contínua, orientar atividades para
resultados de curto prazo, bem como focar na satisfação do cliente e nas
necessidades do mercado. A melhoria de processos deve ser implementada não
apenas com foco na qualidade do produto, mas também na saúde e longevidade da
empresa, considerando fatores como competência, produtividade e inovação. Neste
sentido, a cultura da agilidade pode e deve permear todos os processos de uma
organização. Seu informalismo não pressupõe desorganização, e suas práticas estão
embasadas em muita disciplina. Assim, processos de gestão e realização do produto
podem ser totalmente concebidos e implementados com base nos princípios e práticas
ágeis. Por serem mais centradas no desenvolvimento, as metodologias ágeis
aparentam minimizar o papel do gerenciamento em assegurar sucesso.
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 usuários têm a
oportunidade de obter um sistema mais próximo de suas necessidades; o cliente tem
um retorno mais rápido do seu investimento; os desenvolvedores têm 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 básicas de um projeto de desenvolvimento ágil

são 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 são realizados na abordagem ágil, porém, é diferente e requer do gerente de
projeto uma reavaliação do conhecimento sobre gerência tradicional, valores e
práticas ágeis, visando incorporá-los ao seu próprio estilo de gerência, de forma a
acrescentar valor aos projetos.
34
REFERÊNCIAS BIBLIOGRÁFICAS
BECK, Kent. et. al..Exteme Programming Explained. Addison-Wesley. (1999)
_____,_________. Planning Extreme Programming. Addison-Wesley. (2001a)
KELLY, Kevin. Out of Control: The New Biology of Machines, Social Systems,and the
Economic World. Addison-Wesley. (1994).
KERZNER, Harold. Gestão de projetos: as melhores práticas. 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)

35
REFERÊNCIAS ELETRÔNICAS
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
ANEXO
Quadro 3 : Comparativo entre o PMBOK e XPM / Gerenciamento do Escopo

Processos Definidos no PMBOK Princípios e Práticas da Abordagem àgil
Gerenciamento de
Escopo
Assegurar que o projeto inclua todo o trabalho requerido - e somente ele -, visando concluí-lo com
sucesso
Planejar o escopo: criar um plano que Big Plan: distribuição geral de etapas e produtos
documenta como definir, verificar e controlar gerados Cartões com estórias: definem e
escopo e estrutura analítica formalizam o escopo - o cliente enumera os
Definir escopo: desenvolver uma declaração principais casos de uso e define o valor
detalhada do escopo que servir· de base para agregado ao negócio por cada um
decisões futuras Jogo do planejamento: Equipe e cliente avaliam
Criar estrutura analítica: subdividir principais casos de uso, considerando o lado técnico e
entregas e trabalho em componentes menores e interesses do negócio, em busca de consenso
mais gerenciáveis quanto ao escopo de cada release. Se
Verificar o escopo: formalizar a aceitação das ocorrerem mudanças no conteúdo da release
entregas que foram concluídas no projeto que não possam ser absorvidas, o conjunto de
Controlar escopo: gerir mudanças de escopo estórias é redefinido
ocorridas
Quadro 4 : Comparativo entre o PMBOK e XPM / Gerenciamento de Custos

Gerenciamento de
Custos
Estimar custos: desenvolver uma aproximação concluído
Assegurar que o projeto seja dentro dopor
Desenvolvimento orçamento
iteração:previsto
de duração fixa,
dos custos dos recursos necessários para facilita controlar custos - se necessário, negocia-se
concluir as atividades seu escopo Planejamento de custo amarrado ao
Fazer orçamentação: alocar estimativas de de tempo: como cada iteração possui duração
custos globais fixa, uma estimativa de custo da release pode
a itens individuais, estabelecer linha de base dos ser obtida a partir do n˙mero de pessoas
custos alocadas e de iterações
Controlar custos: acompanhar fatores que
acarretam variações no custo, acompanhar
mudanças no orçamento

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

Gerenciamento de Riscos
Cuidar da identificação, análise, monitoramento e resposta a riscos, visando aumentar a probabilidade e o impacto dos
eventos positivos e diminuir a probabilidade e o impacto de eventos adversos nos objetivos do projeto
Planejar o gerenciamento de riscos: decidir como Valores ajudam a controlar e mitigar riscos: a
abordar, planejar e executar atividades para busca da simplicidade diminui a complexidade; a
gerenciar riscos Identificar riscos: determinar riscos realimentação antecipa a detecção de erros; a
que podem afetar o projeto e documentar suas comunicação aberta minimiza problemas
características relacionados e a falta de informação Práticas ajudam
Fazer an·lise quantitativa de riscos: priorizar riscosa controlar e mitigar riscos: a quebra em iterações e
para análise ou ação, avaliando sua probabilidade e o planejamento constante ajudam a controlar prazo
impacto Fazer análise qualitativa de riscos: fazer e custos; cliente disponível e entrega em releases
uma análise numérica do efeito dos riscos nos diminuem o risco de se obter produtos inadequados
objetivos do projeto Planejar respostas a riscos: Reuniões diárias de acompanhamento:
desenvolver opções e ações para aumentar possibilitam identificar com antecedência a
oportunidades e reduzir ameaças iminência de um risco, permitindo atuar a tempo e
Monitorar e controlar riscos: executar planos de minimizando suas possíveis conseqüências
resposta a riscos e avaliar sua eficácia durante todo
o projeto
Quadro 6: Comparativo entre o PMBOK e XPM / Gerenciamento de Tempo

Processos Definidos no PMBOK Princípios e Práticas da Abordagem ágil
Gerenciamento de
Tempo
Assegurar a conclusão do projeto no prazo previsto
Definir atividades: identificar atividades … contra um planejamento inicial detalhado: no

especificas a realizar visando produzir os início, o cliente explica os casos de uso, em alto
diversos produtos previstos nível, e a equipe calcula o tempo para
Sequenciar atividades: identificar e implementação, o que resulta em uma
documentar as relações de dependência entre programação grosseira (releases e iterações), a
atividades do cronograma ser refinada ‡ medida que o projeto evolui. Se
necessário, gerar protótipos e pesquisar
Estimar recursos: identificar tipo e quantidade de soluções, em busca de uma estimativa mais
recursos para cada atividade do cronograma precisa
Estimar duração: identificar períodos de Releases decompostas em iterações : o
trabalho para concluir as atividades do n˙mero de iterações pode variar, mas cada
cronograma iteração possui duração fixa, o que permite
acompanhar melhor o progresso obtido
Desenvolver cronograma: analisar recursos,
restrições, duração e seqüência das atividades e
distribuir no tempo
Controlar cronograma: acompanhar mudanças

Quadro 7 : Comparativo entre o PMBoK e XPM / Gerenciamento de Qualidade
Gerenciamento de
Qualidade
Determinar responsabilidades, objetivos e políticas para atender as necessidades que motivaram o projeto
Planejar a qualidade: identificar padrões deNão formaliza a área de qualidade: n„o define
qualidade relevantes e determinar a forma degrupo de SQA nem atividades de revis„o e
satisfazê-los auditoria de processos
Garantir a qualidade: realizar atividades de Diversas práticas relacionadas: desenvolvimento
qualidade planejadas, para garantir que o dirigido por testes, uso de padrões de
projeto empregue todos os processos codificação, realimentação„o constante,
necessários para atender aos requisitos p r o g r a ma ç ã o aos pares, integração continua
Controle da qualidade: monitorar resultados com suporte de frameworks para testes
específicos do projeto para determinar se eles automatizados fornecem métricas reais da situação
estão de acordo com padrões de qualidade do desenvolvimento
relevantes e identificar como eliminar as Ao final de cada release: o produto È
causas de desempenhos insatisfatórios verificado e validado com o cliente. Após aceito,
entra em produção
Quadro 8 : Comparativo entre o PMBOK e XPM / Gerenciamento de Recursos Humanos
Gerenciamento de Recursos Humanos

Organizar e gerenciar a equipe do projeto, fazendo uso mais efetivo de competências e habilidades
Planejar recursos humanos: identificar e Programação aos pares: permite que uns aprendam
documentar funções, responsabilidades e hierarquia com os outros, favorecendo o aprendizado
no projeto, além de criar plano de gerenciamento de Informalidade da documentação: leva a necessidade
pessoal de um conhecimento tácito da equipe, para não ter
Contratar e mobilizar equipe do projeto: conseguir que explicitá-lo e formalizá-lo em documento ñ pode
os recursos humanos necessários para trabalhar no ter vários perfis profissionais, mas pelo menos alguns
projeto Ágeis
Desenvolver a equipe: aperfeiçoar competências Visão direcionada, comprometimento, confiança e
e intensão da equipe, melhorar o desempenho do cooperação: ajudam a acompanhar e elevar o
projeto desempenho
Gerenciar a equipe: acompanhar desempenho, Coach ajuda a identificar problemas e resolvê-los
resolver problemas, obter realimentação, e coordenar
mudanças

Quadro 9 : Comparativo entre o PMBoK e XPM / Gerenciamento de Comunicações
Gerenciamento de
Comunicações
Garantir a geração, coleta, distribuição, armazenamento e recuperação de informação, de forma
oportuna e adequada
Planejar as comunicações: determinar as Comunicação: considerada fundamental - confia-

necessidades de informação e comunicação das se muito na comunicação oral e aberta, sendo
partes interessadas Distribuir informação: desnecessário definir canais e estruturas formais
disponibilizar as informações necessárias das Informalidade da documentaÁ„o: Informações e
partes interessadas, no momento oportuno Gerar resultados se tornam de conhecimento tácitoe
relatórios de desempenho: distribuir informações de interpessoal, ao invês de documentado e explicito
desempenho, andamento, medições e previsões Realimentação constante: junto com a
Gerenciar partes interessadas: gerir a comunicação aberta, permite que o desempenho seja
comunicação„o para satisfazer requisitos e resolver acompanhado
problemas dos envolvidos
Quadro 10 : Comparativo entre o PMBoK e XPM / Gerenciamento de Aquisições

Processos Definidos no PMBoK Princípios e Práticas da Abordagem ágil
Gerenciamento de Aquisições
Gerenciar contratos ou pedidos de compra emitidos pela equipe do projeto, controlando possíveis
mudanças
Planejar compras e aquisções: o que, quando e Voltada para o desenvolvimento: não faz
como Planejar contrataÁıes: requisitos / referência ‡
fornecedores potenciais Solicitar resposta de Aquisição de produtos e serviços
fornecedores: cotação, preço, ofertas Selecionar
fornecedores: analisar, negociar, formalizar
Administrar contrato: avaliar desempenho, tomar
ações Encerrar contrato: liquidar contrato e
pendências

Gerenciamento ágil de projetos de software

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Gerenciamento ágil de projetos de software

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE

Felipe Barbosa Nogueira

Felipe Barbosa Nogueira

Monografia apresentada no Curso de

Felipe Barbosa Nogueira

Monografia submetida ao Curso de Pós-graduação Gerenciamento de Projetos,

GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVÉS DE

Felipe Barbosa Nogueira

Resumo da Monografia submetida ao corpo docente do curso de Pós-

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

Palavras-chave: Gerenciamento de Projetos, Práticas da Qualidade

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

Em meio a estes questionamentos, esta pesquisa discute os princípios e

monitoramento e controle de projetos, buscando mostrar que a adoção da abordagem

2. Gerência Tradicional de Projetos

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

Em 1970 e início de 1980, mais empresas começaram a sair da filosofia

O gerenciamento de projeto, então começou, a ganhar força dentro das

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

As empresas advogavam que o gerenciamento informal que vinha sendo

Para Rob Thomsett, (2001), o desenvolvimento de software neste período

A partir de 1990, as empresas notaram que a implementação do

Para Rob Thomsett (2001), a próxima fase do desenvolvimento de sistema, é

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

2.2 Gerenciamento Informal de Projetos

Confiança: fundamental na consolidação de uma relação efetiva

Comunicação: em geral, embora os executivos prefiram comunicar-

Cooperação: mais relacionada com a atitude em relação ao trabalho

voluntárias das pessoas para trabalhar em benefício do todo,

Trabalho em equipe: desenvolvido por pessoas atuando juntas com

2.3 O Gerenciamento Tradicional de Projetos segundo o

Integração descreve os processos e as atividades que integram os

Escopo descreve os processos envolvidos na verificação de que o

Tempo descreve os processos relativos ao término do projeto no

Custos descrevem os processos envolvidos em planejamento,

Qualidade descreve os processos envolvidos na garantia de que o

Recursos Humanos descreve os processos que organizam e

Comunicações descreve os processos relativos à geração, coleta,

Riscos descreve os processos relativos à realização do

Aquisições descreve os processos que compram ou adquirem

Tais processos encontram-se divididos em cinco grandes grupos: Iniciação

3. Metodologias Ágeis de Desenvolvimento de Software

3.1 Características das Metodologias

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

Quadro 1. Os doze princípios da agilidade.

Descrição . Princípios da Agilidade

3.2 Metodologias Ágeis

As metodologias “ágeis” apresentam diferenças significativas em relação às

Quadro 2 : Comparativo entre o PMBoK e XPM / Gerenciamento da Integração

Desenvolver o termo de abertura do projeto: Big Plan: identifica a visão e missão do

3.2.1. Extreme Programming (XP)

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

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

Figura 1. Ciclo de vida típico de um projeto XP

O desenvolvimento, propriamente dito, corresponde à implementação das

O tracker é o responsável por acompanhar o progresso da iteração, verificando

A primeira menção na literatura sobre o termo “SCRUM” surgiu com o artigo de

A principal idéia do SCRUM é que o desenvolvimento de sistema envolve

Figura 2 – Fases SCRUM

O SCRUM consiste em três fases, segundo Schwaber e Beedle (1995):

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

priorizados e o esforço necessário de sua implementação é estimado. O PBL é