Upload
luisaureliosurek
View
218
Download
0
Embed Size (px)
Citation preview
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
2/47
GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWAREATRAVS DE
EXTREME PROJECT MANAGEMENT(XPM)
Felipe Barbosa Nogueira
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
3/47
ii
GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWAREATRAVS DE
EXTREME PROJECT MANAGEMENT(XPM)
Felipe Barbosa Nogueira
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
FortalezaJaneiro, 2007
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
FortalezaJaneiro, 2007
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
7/47
vi
5. Consideraes Finais ______________________________________________31
Referncias Bibliogrficas ____________________________________________34
Referencias Eletrnicas_________________________________________35
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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,
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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).
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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)
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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)
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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)
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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.
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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)
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
Fonte: Ana Magalhes (2005)
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
Fonte: Ana Magalhes (2005)
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
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
Fonte: Ana Magalhes (2005)
Quadro 6: Comparativo entre o PMBOK e XPM / Gerenciamento de Tempo
ProcessosDefinidosnoPMBOK Princpios e Prticas da Abordagem gil
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
Fonte: Ana Magalhes (2005)
8/7/2019 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM
46/47
Quadro 7 : Comparativo entre o PMBoK e XPM / Gerenciamento de Qualidade
ProcessosDefinidosnoPMBOK Princpios e Prticas da Abordagem gil
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
Fonte: Ana Magalhes (2005)
Quadro 8 : Comparativo entre o PMBOK e XPM / Gerenciamento de Recursos Humanos
ProcessosDefinidosnoPMBOK Princpios e Prticas da Abordagem gil
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