099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM

Embed Size (px)

Text of 099 - GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVES DE EXTREME PROJECT MANAGEMENT - XPM

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

    1/47

    UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

    ESCOLA POLITCNICADCC/SEGRAC

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

    Felipe Barbosa Nogueira

    2007

  • 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