ESCOLA POLITÉCNICA
DCC/SEGRAC
GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE
ATRAVÉS DE EXTREME PROJECT MANAGEMENT (XPM)
Felipe Barbosa Nogueira
Felipe Barbosa Nogueira M o n o g r a f i a a p r e s e n t a d a n o C u r s o d e P ó s - G r a d u a ç ã o e m G e r e n c i a m e n t o d e P r o j e t o s , d a E s c o l a P o l i t é c n i c a , d a U n i v e r s i d a d e F e d e r a l d o R i o d e J a n e i r o . Orientador
George Wosley Barbosa Nogueira Lima
Fortaleza Janeiro, 2007
ii
GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVÉS DE
EXTREME PROJECT MANAGEMENT (XPM)
Felipe Barbosa Nogueira
Orientador
George Wosley Barbosa Nogueira Lima
Monografia submetida ao Curso de Pós-graduação Gerenciamento de Projetos, da Escola Politécnica, da Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
Aprovado por:
__________________________________________ Prof. Eduardo Linhares Qualharini
__________________________________________ Profª.Fernanda Veras __________________________________________
Prof. Alexsandro Amarante da Silva
Fortaleza Janeiro, 2007
iii NOGUEIRA, Felipe Barbosa.
Gerenciamento de Desenvolvimento de Software Através de Extreme Project Management (XPM) / NOGUEIRA, F. B. Fortaleza: UFRJ/EP, 2007.
vii, 35f. il.; 29,7cm.
Orientador: George Wosley Barbosa Nogueira Lima.
Monografia (especialização) – UFRJ/ Escola Politécnica/ Curso de Especialização em Gerenciamento de Projetos, SEGRAC, 2007.
Referências Bibliográficas: f. 33-35
1. Gerenciamento de Projetos. 2. Práticas da Qualidade I. LIMA, G. W. B. N. II. Universidade Federal do Rio de Janeiro, Escola Politécnica, Pós-graduação III. Especialista.
GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE ATRAVÉS DE EXTREME PROJECT MANAGEMENT (XPM)
Felipe Barbosa Nogueira
Resumo da Monografia submetida ao corpo docente do curso de Pós-Graduação em Gerenciamento de Projetos – Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
O XPM visa melhorar o gerenciamento de projetos, em especial aos projetos de software para os quais o tempo e o custo para tornar o produto disponível no mercado são críticos, não sendo possível elaborar um cronograma detalhado e uma especificação de requisitos em um estágio preliminar do processo, e mostra-se necessária uma avaliação diária do projeto para adequá-lo à situação de mercado. A meta é a entrega do resultado desejado, e não necessariamente o resultado inicialmente planejado.
Palavras-chave:Gerenciamento de Projetos, Práticas da Qualidade
Fortaleza Janeiro, 2007
v SUMÁRIO
1. Introdução ________________________________________________________1 2. Gerência Tradicional de Projetos______________________________________3 2.1 História_________________________________________________________3 2.2 Gerenciamento Informal de Projetos __________________________________4 2.3 O Gerenciamento Tradicional de Projetos segundo o Project Management Box
of Knowledge (PMBoK) _______________________________________________6
3. Metodologias Ágeis de Desenvolvimento de Software ____________________9 3.1 Características das Metodologias ____________________________________9 3.2 Metodologias Ágeis ______________________________________________10 3.2.1 Extreme Programming (XP) ____________________________________11 3.2.2 SCRUM____________________________________________________13 3.2.3 Família Cristal De Metodologias _________________________________15 3.2.4 Feature Driven Development (FDD) ______________________________16 3.2.5 Método de Desenvolvimento de Sistema Dinâmico (MDSD) ___________20 3.2.6 Desenvolvimento Adaptativo de Software (DAS) ____________________22 4. eXtreme Project Management (XPM) __________________________________24 4.1 Regras ________________________________________________________24
4.1.1 XPM Regra 1: A gerência de pessoas e processos criativos demanda processos criativos. _______________________________________________24 4.1.2 XPM Regra 2: Quanto menos o gerente souber sobre questões técnicas do projeto, melhor. __________________________________________________25 4.1.3 XPM Regra 3: O que ocorre depois do projeto é mais importante do que ocorre durante o projeto____________________________________________26 4.1.4 XPM Regra 4: O planejamento de projeto desenvolvido sem a participação completa dos stakeholders não é mais que a fantasia de uma única pessoa___26 4.1.5 XPM Regra 5: Quanto mais tempo o gerente de projetos permanecer com os stakeholders melhor ____________________________________________27 4.1.6 XPM Regra 6: Se o sucesso do projeto não for definido no começo, ele nunca será alcançado no final _______________________________________28 4.1.7 XPM Regra 7: Mostre-lhes o lucro: nada mais importa _______________28 4.1.8 XPM Regra 8: Os Stakeholders do projeto podem ser seus melhores aliados ou seus piores inimigos ____________________________________________29 4.1.9 XPM Regra 9: Se você não pode prever o futuro, não planeje em detalhe 29 4.1.10 XPM Regra 10: Se o seu projeto não mudou, fique apreensivo, muito apreensivo. _____________________________________________________30 4.1.11 XPM Regra 11: Em e-projects, um dia é um tempo muito longo _______30
vi
5. Considerações Finais ______________________________________________31 Referências Bibliográficas ____________________________________________34 Referencias Eletrônicas_________________________________________35
vii
LISTA DE FIGURAS
Figura 1 Ciclo de vida típico de um projeto XP__________________________12 Figura 2 Fases do SCRUM ________________________________________ 13 Figura 3 Incremento Crystal Orange_________________________________ 16 Figura 4 Fases FDD______________________________________________17 Figura 5 Diagramas de processos do MDSD___________________________22 Figura 6 Diagramas de Fases do DAS_______________________________ 23
LISTA DE QUADROS
Quadro 1 Os doze princípios da agilidade________________________________ 9 Quadro 2 Comparativo entre o PMBoK e XPM / Gerenciamento da Integração____ 10 Quadro 3 Etapas do planejamento rápido _________________________________27
LISTA DE SIGLAS
XPM – Extreme Project Management
PMBoK – Project Management Box of Knowledge XP – Extreme Programming
FDD – Feature Driven Development
MDSD – Método de Desenvolvimento de Sistemas Dinâmicos DAS – Desenvolvimento Adaptativo de Software
EAP – Estrutura Analítica do Projeto
ANSI – American National Standards Institute PMI – Project Management Institute
TI – Tecnologia da Informação
RAD - Rapid Application Development
Ao longo do tempo, o desenvolvimento de software tem sido rotulado como uma atividade complexa e marcada por fracassos: prazos e orçamentos não cumpridos, expectativas não satisfeitas, retorno de investimento muito menor que o esperado. Uma das principais razões apontadas para isto tem sido a dificuldade de encontrar a melhor relação entre custo, prazo, escopo e qualidade. Em busca de uma solução, procurou-se adotar junto aos projetos de software a mesma abordagem empregada aos projetos de engenharia, acreditando-se que a receita para o sucesso seria investir muito tempo e recursos, em um planejamento e design mais detalhados, e garantir o sucesso da execução com gerenciamento e processos bem definidos. Nesta direção, diversas organizações partiram em busca de uma solução final para seus problemas: utilizando normas e modelos existentes, definiram processos organizacionais e técnicos complexos, suportados por muita documentação escrita e dispensavam a participação do cliente no decorrer do desenvolvimento, Insistindo em erros comuns de muitos projetos de engenharia, muitas organizações acabaram por ampliar o tamanho do problema com tentativas de solução.
Por mais que os processos e controles tenham sido definidos, os resultados acabavam ficando longe da expectativa, pois a construção de software é diferente de outras construções da engenharia tradicional: um software é, pela sua própria natureza, intangível; é impossível se antever todas as suas funcionalidades; as necessidades emergem durante todo o seu desenvolvimento, e vão amadurecendo até a sua implantação; além disso, a própria utilização do software é que geralmente impulsiona o aprimoramento de seus recursos. A mudança é, portanto, inevitável e o não reconhecimento desta realidade leva ao desperdício de recursos em planejamento e design desnecessários, que acabam sendo descartados posteriormente. Ao procurar satisfazer custo, prazo, escopo e qualidade, o caminho adotado pela gerência tradicional de projetos tem sido, a partir de um escopo fechado definir custo e prazo e, em função do andamento do projeto, manipular a qualidade. Mas será que melhor não seria ter prazo predefinido, um custo fixo, mantendo os níveis de qualidade e manipulando o escopo, e por quê não fazer o mais simples primeiro, e refinar depois, mudando somente e quando for necessário, deixando de gerar documentação desnecessária para execução do escopo.
Em meio a estes questionamentos, esta pesquisa discute os princípios e práticas das metodologias ágeis de gerenciamento de software em relação aos processos e práticas descritas pela abordagem tradicional de planejamento,
monitoramento e controle de projetos, buscando mostrar que a adoção da abordagem ágil pode não só aumentar a credibilidade deste paradigma, mas também ajudar a elevar a qualidade dos produtos em conseqüência da melhoria da qualidade derivada das boas práticas empregadas.
2. Gerência Tradicional de Projetos
2.1 História
Em 1960, mais e mais executivos renderam-se à busca de novas técnicas de gerenciamento e estruturas organizacionais que pudessem ser rapidamente adaptadas ao seu ambiente, o gerenciamento de projeto vem a ser uma nova ferramenta no auxílio dos trabalhos.
Inicialmente as empresas, como, as do setor aeroespacial, defesa e construção, as principais da época, mantinham o método informal de gerenciamento de projetos onde a autoridade do gerente de projeto era fraca e os principais projetos eram gerenciados diretamente por gerentes funcionais.
Nesta época, a maioria das organizações teve o primeiro contato com sistemas de computação. Segundo Rob Thomsett [Extreme Project Management, 2001] o desenvolvimento de software encontrava-se na era das trevas (Dark Age) onde a necessidade de qualquer desenvolvimento tinha uma participação tímida por parte dos clientes, que as repassavam à equipe de TI (Tecnologia de Informação). Os Clientes, então, só tinham mais alguma participação no processo caso houvesse a necessidade de mais informação a ser dada. Neste momento o cliente era totalmente dependente do profissional de TI.
Em 1970 e início de 1980, mais empresas começaram a sair da filosofia informal de gerenciamento de projeto para um processo mais formalizado de gerência, tendo em vista o tamanho e complexidade que as atividades estavam assumindo dificultando o gerenciamento dentro da estrutura utilizada.
O gerenciamento de projeto, então começou, a ganhar força dentro das empresas, os executivos vislumbraram que esta abordagem estaria entre os principais interesses das empresas, se bem implementado, poderia ajudar as empresas a transpor os obstáculos internos e externos.
Para o gerenciamento formal de projeto a ser adotado nas empresas, mudanças eram inevitáveis, para satisfazê-las as organizações voltaram-se para si, a fim de se reestruturarem. As mudanças então, iniciaram-se. As empresas como as do setor aeroespacial, defesa e construção, foram pioneiras.
As empresas advogavam que o gerenciamento informal que vinha sendo aplicado era um sucesso e não viam a aplicação formal do gerenciamento de projeto com diferencial que os forçasse a mudar. Já as empresas que decidiram implantar
esta nova abordagem tinham a seguinte pergunta a responder: “Quanto tempo leva o
período de conversão para esta nova abordagem de gerenciamento?”
Em regra geral isto poderia demandar de dois a três anos para converter a estrutura tradicional para o gerenciamento estruturado, sendo uma das principais razões para isto, o fato do empregado terem um chefe único, em uma única estrutura o empregado teria que se reportar verticalmente com seu gerente funcional e horizontalmente com o gerente de projeto, o que causa um grande choque cultural no início.
Para Rob Thomsett, (2001), o desenvolvimento de software neste período caracterizava-se pela fase do tokenismo (tokenism), em que os sistemas desenvolvidos na fase anterior (Dark Age) foram re-desenvolvidos para tirar vantagem dos benefícios oferecidos pelas tecnologias de banco de dados, redes e comunicação que estavam emergindo na época. Esta fase marcou a primeira tentativa de automatizar novos tipos de sistemas de informação, tais como, gerenciamento de informação e suporte a decisão.
A partir de 1990, as empresas notaram que a implementação do gerenciamento de projeto era uma necessidade não uma escolha. A questão então, era como implementá-lo da forma mais rápida possível.
Para Rob Thomsett (2001), a próxima fase do desenvolvimento de sistema, é onde a participação do cliente se torna presente. A terceira fase é o troco (Payback) por parte dos clientes, que trazem o controle do processo para si. Entretanto, a competitividade, custos e pressões sociais forçaram as organizações (públicas e privadas) a avaliarem os métodos de trabalho, gerencia e planejamento empreendidos, até então, por parte dos executivos, sobre tudo nos investimentos de TI a fim de descobrirem se este conjunto estava alinhado aos interesses da empresa.
Nos dias atuais, o desenvolvimento de software, trabalha em parceria (Partnership) entre a equipe de TI e os usuários (clientes), onde as responsabilidades são divididas e a cooperação dá espaço a uma abordagem bilateral.
2.2 Gerenciamento Informal de Projetos
À medida que o gerenciamento de projetos tornava-se um processo reconhecido, muita documentação formal passou a ser produzida, visando principalmente tranqüilizar o cliente. Considerando o tempo consumido na elaboração, digitação, leitura, cópia, distribuição e arquivamento de documentos, essa
formalização resultava em um custo muito alto. Mais grave do que isto, os gerentes de projeto acabaram ficando tão absorvidos com a documentação a ser gerada que pouco tempo lhes restava para gerenciar efetivamente o projeto.
Nos últimos 20 anos, porém, esse cenário mudou. Segundo Kerzner (2002), a mudança mais significativa no campo do gerenciamento de projetos foi a comprovação de que o gerenciamento informal dá resultados. Com o gerenciamento informal, a necessidade de documentação foi reduzida para níveis minimamente aceitáveis, e diretrizes formais foram substituídas por listas de verificação menos detalhadas e mais genéricas. Gerenciamento Informal é baseado mais em guias do que em políticas e procedimentos que são as bases do gerenciamento formal de projetos. Mudar da formalidade para a informalidade exige, porém, uma alteração na cultura da organização. Kerzner aponta ainda, quatro elementos chave para o sucesso da implementação da gestão informal de projetos:
Confiança: fundamental na consolidação de uma relação efetiva entre o fornecedor/ terceirizado e o cliente, a confiança traz inúmeros benefícios para ambas as partes. Sem ela, gerentes e responsáveis por projetos precisariam de uma vasta documentação, apenas para terem a certeza de que todos os encarregados estão cumprindo suas tarefas da maneira que lhes foi determinada.
Comunicação: em geral, embora os executivos prefiram comunicar-se verbal ou informalmente, existe a crença de que aquilo que não foi escrito não foi dito. Um dos pré-requisitos para o gerenciamento informal de projetos é que os funcionários entendam a estrutura, as funções e as responsabilidades que terão no âmbito da empresa e do projeto. Metodologias eficientes de gerenciamento de projetos promovem não apenas o gerenciamento informal, mas igualmente a comunicação eficiente, tanto lateral quanto verticalmente. Dois grandes obstáculos internos a serem superados para desenvolver-se uma cultura informal são os relatórios e as reuniões longas e desnecessárias, decorrentes da intervenção dos gerentes em atividades rotineiras ou do mal direcionamento de informações. Quando necessária, a comunicação formal deve ser breve e focada em três questões básicas: qual a situação atual, qual a situação desejada e se existe algum problema exigindo a interferência da administração. Nenhum planejamento, por melhor que seja, irá muito longe sem uma comunicação eficiente.
Cooperação: mais relacionada com a atitude em relação ao trabalho do que com o trabalho propriamente dito, consiste em ações
voluntárias das pessoas para trabalhar em benefício do todo, buscando um resultado favorável. Sua efetivação não depende da intervenção formal da autoridade, pois os integrantes geralmente sabem o que devem fazer e o que fazem. As pessoas aprendem a cooperar à medida que se conhecem melhor, o que leva tempo , um recurso quase sempre escasso em projetos.
Trabalho em equipe: desenvolvido por pessoas atuando juntas com um espírito de cooperação, sob os limites de uma coordenação, possibilitando: troca de idéias e informações por iniciativa própria; estabelecimento de altos índices de inovação e criatividade; confiança e lealdade entre os membros e para com a empresa; dedicação ao trabalho realizado e aos compromissos assumidos; franqueza e honestidade em seu relacionamento.
2.3 O Gerenciamento Tradicional de Projetos segundo o
Project Management Box of Knowledge (PMBoK)
Mundialmente reconhecido e aceito desde 1999 como padrão de gerenciamento de projetos pelo ANSI (American National Standards Institute), o PMBoK, PMI, (2004) descreve o conjunto de conhecimentos e as melhores práticas para o gerenciamento de projetos, podendo ser utilizado para orientar a definição de um processo padrão para gerenciamento de projetos de software, pois escreve .o que deve ser feito e não como fazer. Diversas empresas no mundo utilizam com sucesso o PMBoK como base para o estabelecimento de uma cultura em gerenciamento de projetos. Os 44 processos que integram a terceira edição do PMBoK, PMI, (2004) estão organizados em nove áreas de conhecimento ou de atuação gerencial:
Integração descreve os processos e as atividades que integram os diversos elementos do gerenciamento de projetos, que são identificados, definidos, combinados, unificados e coordenados dentro dos grupos de processos de gerenciamento de projetos. Ela consiste nos processos de gerenciamento de projetos: Desenvolver o termo de abertura do projeto, Desenvolver a declaração do escopo preliminar do projeto, Desenvolver o plano de gerenciamento do projeto, Orientar e gerenciar a execução do projeto, Monitorar e controlar o trabalho do projeto, Controle integrado de mudanças e Encerrar o projeto.
Escopo descreve os processos envolvidos na verificação de que o projeto inclui todo o trabalho necessário, e apenas o trabalho
necessário, para que seja concluído com sucesso. Ela consiste nos processos de gerenciamento de projetos: Planejamento do escopo, Definição do escopo, Criar Estrutura Analítica do Projeto (EAP), Verificação do escopo e Controle do escopo.
Tempo descreve os processos relativos ao término do projeto no prazo correto. Ela consiste nos processos de gerenciamento de projetos: Definição da atividade, Seqüenciamento de atividades, Estimativa de recursos da atividade, Estimativa de duração da atividade, Desenvolvimento do cronograma e Controle do cronograma.
Custos descrevem os processos envolvidos em planejamento, estimativa, orçamentação e controle de custos, de modo que o projeto termine dentro do orçamento aprovado. Ela consiste nos processos de gerenciamento de projetos: Estimativa de custos, Orçamentação e Controle de custos.
Qualidade descreve os processos envolvidos na garantia de que o projeto irá satisfazer os objetivos para os quais foi realizado. Ela consiste nos processos de gerenciamento de projetos: Planejamento da qualidade, Realizar a garantia da qualidade e Realizar o controle da qualidade.
Recursos Humanos descreve os processos que organizam e gerenciam a equipe do projeto. Ela consiste nos processos de gerenciamento de projetos: Planejamento de recursos humanos, Contratar ou mobilizar a equipe do projeto, Desenvolver a equipe do projeto e Gerenciar a equipe do projeto.
Comunicações descreve os processos relativos à geração, coleta, disseminação, armazenamento e destinação final das informações do projeto de forma oportuna e adequada. Ela consiste nos processos de gerenciamento de projetos: Planejamento das comunicações, Distribuição das informações, Relatório de desempenho e Gerenciar as partes interessadas.
Riscos descreve os processos relativos à realização do gerenciamento de riscos em um projeto. Ele consiste nos processos de gerenciamento de projetos: Planejamento do gerenciamento de riscos, Identificação de riscos, Análise qualitativa de riscos, Análise quantitativa de riscos, Planejamento de respostas a riscos e Monitoramento e controle de riscos.
Aquisições descreve os processos que compram ou adquirem produtos, serviços ou resultados, além dos processos de gerenciamento de contratos. Ele consiste nos processos de gerenciamento de projetos: Planejar compras e aquisições, Planejar contratações, Solicitar respostas de fornecedores, Selecionar fornecedores, Administração de contrato e Encerramento do contrato.
Tais processos encontram-se divididos em cinco grandes grupos: Iniciação (que autoriza o início do projeto ou de uma fase), Planejamento (que define, refina e seleciona as melhores alternativas), Execução (que coordena recursos a partir do que foi planejado), Controle (que monitora e mede o progresso do que foi executado) e Encerramento (formaliza o aceite e a finalização do projeto ou de uma fase).
3.
Metodologias Ágeis de Desenvolvimento de Software
3.1 Características das Metodologias
A dificuldade de uso das metodologias de desenvolvimento de software tradicionais e a alta freqüência com que os projetos de software deixavam de cumprir seus cronogramas e extrapolavam seus orçamentos levaram, ao final da década de 1990, à elaboração do Manifesto pela Agilidade, Beck (2001) e à criação de uma organização sem fins lucrativos denominada Aliança Ágil - Agile Alliance (2005), com a finalidade de divulgar seus princípios, Beck (2001), apresentados no Quadro 1, em busca de uma forma mais objetiva de se desenvolver software.
Surgiu, assim, um novo paradigma para o desenvolvimento de software, as metodologias leves (lightweight methodologies), ou ágeis. Ao invés de estabelecer processos, as metodologias ágeis combinam um pequeno número de regras e práticas, sendo especialmente adequadas para projetos pequenos ou médios (2-10 pessoas), com requisitos imprecisos ou em constante mudança.
Quadro 1. Os doze princípios da agilidade.
Descrição . Princípios da Agilidade
1. A prioridade é a satisfação do cliente, por meio da liberação rápida e contínua de software de valor.
2. Receba bem as mudanças de requisitos, mesmo em estágios tardios do
desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente.
3. Libere software freqüentemente, dando preferência para uma escala de tempo mais curta. 4. Mantenha stakeholders e desenvolvedores trabalhando juntos a maior parte do tempo do
projeto.
5. Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles.
6. O método mais eficiente e efetivo para repassar informação é pela comunicação direta. 7. Software funcionando é a principal medida de progresso de um projeto de software. 8. Processos ágeis promovem desenvolvimento sustentado. Assim, patrocinadores,
desenvolvedores e usuários
devem ser capazes de manter conversação pacífica indefinidamente.
9. A atenção contínua para a excelência técnica e um bom projeto (design) aprimoram a agilidade.
10. Simplicidade . a arte de maximizar a quantidade de trabalho não feito . é essencial, devendo ser sempre
assumida em todos os aspectos do projeto.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas. 12. Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas,
para então refinarem e ajustarem seu comportamento. Fonte: Manifesto da Agilidade , Beck (2001)
3.2 Metodologias Ágeis
A abordagem “ágil” propõe a construção de software de forma evolutiva e adaptativa. A idéia é começar da forma mais simples possível, apenas com o planejamento e design necessários e resolver as necessidades mais claras e críticas, agregando valor ao produto e entregando algum resultado rapidamente. Durante todo o desenvolvimento, o objetivo é ter um software em operação o mais rápido possível, para que ele tenha condições de evoluir. Deve-se investir ao máximo em simplicidade, de forma que a mudança deixe de ser traumática e passe a ser natural.
As metodologias “ágeis” apresentam diferenças significativas em relação às metodologias tradicionais, conforme quadros abaixo, separados por área de conhecimento, isso ocorre porque os pressupostos são totalmente divergentes. Conforme observa-se, ambos apresentam pontos fortes e fracos, o importante é buscar o ponto de equilíbrio, avaliando riscos: o planejamento pode aperfeiçoar a agilidade, enquanto esta pode dar maior eficiência ao planejamento. Em qualquer abordagem, porém, as pessoas ativamente envolvidas e suas proposições de valor possuem grande importância. A seguir, um comparativo entre o PMBoK e as práticas da abordagem ágil. (quadro 2). No anexo estão os quadros 3, 4, 5, 6, 7, 8, 9, 10 oferecendo comparativos do PMBoK x abordagem ágil para Escopo, Custos, Riscos, Tempo, Qualidade, RH, Comunicações e Aquisições.
Quadro 2 : Comparativo entre o PMBoK e XPM / Gerenciamento da Integração
Processos Definidos no PMBoK Princípios e Práticas da Abordagem àgil
Gerenciamento de Integração
Identificar, definir, combinar, unificar e coordenar os diversos processos e atividades de gerenciamento de projetos
Desenvolver o termo de abertura do projeto: gerar uma autorização formal de seu início Desenvolver a declaração de escopo preliminar do projeto: fornecer uma descrição de alto nívelvel do escopo
Desenvolver o plano de gerenciamento do projeto: definir, preparar, integrar e coordenar planos auxiliares
Orientar e gerenciar a execução do projeto: executar o
trabalho definido para atingir os requisitos definidos na declaração de escopo
Monitorar e controlar o trabalho do projeto: atender aos objetivos de desempenho definidos no plano de projeto
Controlar mudanças: aprovar solicitações e coordenar mudanças em produtos e processos, de forma integrada
Encerrar o projeto: finalizar todas as atividades para encerrar formalmente o projeto
Big Plan: identifica a visão e missão do sistema, dá ao cliente e à equipe uma noção geral para as releases
Planos de release e iteração: detalham etapas especifica e possibilitam o acompanhamento Jogo do planejamento: acompanha toda a execução, avaliando prazo, escopo, risco e custo, com pouca carga adicional, ainda que de maneira informal
Cartões com estórias: indexam os casos de uso, que s„o selecionados pelo cliente para implementação a cada iteração
Desenvolvimento por iteração: entrega um conjunto de funcionalidades, agregando valor ao produto e realimentando o planejamento
Reuniões de acompanhamento: possibilitam identificar com rapidez a situação atual e a necessidade de mudança
3.2.1. Extreme Programming (XP)
A XP é a metodologia de desenvolvimento ágil mais conhecida e utilizada. De domínio público, possui este nome porque emprega ao extremo algumas boas práticas da engenharia de software. Ela é descrita por meio de valores, princípios e práticas, Beck (2001). Os valores descrevem os objetivos de longo prazo ao aplicar XP e definem critérios de sucesso. Os princípios proporcionam a pequenas e médias equipes um ambiente de desenvolvimento cooperativo, capaz de atingir altos níveis de produtividade e um elevado grau de confiança. As práticas estruturam as atividades básicas do desenvolvimento XP e seguem seus princípios, sustentando os valores definidos.
O ciclo de vida de um projeto XP é iterativo e incremental, como apresentado na Figura 1. Existe uma etapa de planejamento inicial, na qual o coach e o cliente analisam a viabilidade do projeto, identificam um escopo geral as macro funcionalidades da solução e elaboram o plano inicial, denominado Big Plan. O desenvolvimento ocorre em releases, que são divididas em iterações. No planejamento do próximo release, equipe técnica e cliente detalham requisitos e estimam esforço, utilizando Story Cards - cartões que descrevem estórias (requisitos de usuário) de forma sucinta, possibilitando estimar o esforço envolvido. Os Story
Cards constituem uma ferramenta efetiva para guiar o desenvolvimento, sendo de fácil
manipulação e armazenamento. As estimativas são realizadas em grupo e baseadas em histórico: atribuem-se pontos às estórias mais simples e, a partir daí, estima-se de forma comparativa. Quando não se tem idéia da complexidade de uma estória, alguns experimentos ou implementações são realizados, em busca de mais dados para realizar a estimativa. A unidade utilizada é ideal weeks. Após estimar todos os Story
Cards, cliente e equipe técnica definem o escopo do próximo release, que deverá
entregar um software de valor, de forma que usuários possam utilizá-lo, perceber benefícios de seu uso e realimentar os desenvolvedores com pontos positivos e negativos. O planejamento das iterações é então realizado, refinando o plano do release. Os desenvolvedores identificam as tarefas contidas nas estórias, estimam sua duração em “perfect days” e escolhem o que irão implementar o que gera maior comprometimento e motivação. Durante todo o desenvolvimento é aplicada, constantemente, a prática de jogo do planejamento.
Figura 1. Ciclo de vida típico de um projeto XP
Fonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)
O desenvolvimento, propriamente dito, corresponde à implementação das estórias selecionadas. A arquitetura é definida e remodelada em seções rápidas de
design, sempre buscando a simplicidade deve-se resolver o problema atual, usando
metáforas, e gerar código preparado para mudar e evoluir. A programação em pares é uma constante: o driver fica no teclado, focado no que está sendo implementado, enquanto o partner atua como inspetor, acompanhando a produção do driver, com trocas ocorrendo várias vezes ao dia. Desenvolvido utilizando um padrão de codificação, o código gerado é comunitário, sendo freqüentemente reestruturado em busca de um melhor desempenho e simplicidade. Testes unitários automáticos são gerados junto com o código, o que motiva e dá mais confiança à equipe. Builds são gerados a cada integração do código, ocasião em que todos os testes são refeitos. Se ocorrer erro, qualquer integrante da equipe poderá alterá-lo. Os testes de aceitação são especificados pelo cliente, que define com o apoio dos testers como quer o produto. As práticas XP utilizadas em conjunto promovem um processo eficiente de desenvolvimento do software.
O tracker é o responsável por acompanhar o progresso da iteração, verificando periodicamente com o programador quantos “perfect days” este já trabalhou na tarefa e quantos ainda faltam para concluí-la. Reuniões diárias de acompanhamento
(stand-up meetings) são realizadas com o objetivo de verificar a evolução, comunicar
problemas e providenciar soluções. Caso exista algum desvio ou problema, o coach é alertado para intervir junto à equipe e envolver o cliente, se necessário. Gráficos visíveis são disponibilizados para acompanhar progresso do projeto, apresentando em geral estimativas, testes executados, densidade de erros(bugs) e progresso de estórias.
3.2.2 SCRUM
A primeira menção na literatura sobre o termo “SCRUM” surgiu com o artigo de Takeuchi e Nokata (1986) que dizia ser um processo adaptativo, rápido, alto organizável. O SCRUM consiste em uma aplicação da abordagem empírica da teoria de controle do processo industrial para o desenvolvimento de software resultando em uma abordagem flexível, adaptativa e produtiva. O SCRUM concentra-se em como os membros da equipe devem agir de forma a produzir sistemas flexíveis em um ambiente em constante mudança.
A principal idéia do SCRUM é que o desenvolvimento de sistema envolve várias variáveis técnicas e ambientais que mudam durante o processo, tornando o desenvolvimento imprevisível e complexo, requerendo flexibilidade do processo de desenvolvimento de sistema, para torná-lo hábil a responder as mudanças. Suas fases podem ser vistas na Figura 2.
Figura 2 – Fases SCRUM
Fonte: Abrahamsson, Salo, Ronkaisen e Warsta (2002)
O SCRUM consiste em três fases, segundo Schwaber e Beedle (1995): Fase pré-game inclue duas sub-fases: Planejamento e Arquitetura. No
Planejamento, define-se o que o sistema verá fazer. É criado o Product Backlog List
priorizados e o esforço necessário de sua implementação é estimado. O PBL é constantemente atualizado com novos ou mais detalhes de seus itens, como também estimativas mais precisas e nova ordem de prioridades. O planejamento inclue também a definição do time do projeto, ferramentas necessárias e outros recursos, análise de risco e controle de versões. A cada iteração, o PBL é revisto pelo Time(s)
SCRUM, depois do aceite coletivo com relação à versão nesta iteração, passa-se à
próxima.
Na sub-fase de arquitetura, são planejados detalhes de implementação baseados nos requerimentos do PBL.
A fase de desenvolvimento (também chamada fase de jogo) é a parte ágil do SCRUM. Esta fase é tratada como uma “caixa preta” onde o imprevisível é esperado. As diferentes variáveis técnicas e ambientais (tais como tempo, qualidade, requerimentos, recursos, implementações tecnológicas e ferramentas) identificados no SCRUM, que podem mudar no decorrer do processo, são observados e controlados através de práticas durante os Sprints da fase de desenvolvimento.
Na fase de desenvolvimento o sistema é desenvolvido em Sprints. Os Sprints são ciclos iterativos onde a funcionalidade é desenvolvida ou melhorada para produzir novos incrementos. Cada Sprint inclue as fases tradicionais de desenvolvimento de software: requerimento analise, design, evolução e delivery. A arquitetura e design do sistema evoluem durante o desenvolvimento do Sprint.
A fase de pós-game consiste no encerramento do release. O desenvolvimento entrará nesta fase quando os requisitos forem todos atendidos. Nesta fase são tratadas também as tarefas de integração, testes e documentação.
Existem 5 papéis no SCRUM que desempenham diferentes tarefas e propósitos durante o processo e suas práticas: SCRUM Master, Product Owner,
SCRUM Team, Cliente e Gerência. Estes papeis são apresentados de acordo com as
definições de Schwaber e Beedle (1995):
SCRUM Master é responsável por garantir que o projeto seja conduzido de acordo as práticas, valores e regras do SCRUM e garantir que o projeto progrida como planejado. Ele interage com time de projeto, como também com os clientes e a gerência durante o projeto. Ele também é responsável por garantir que quaisquer impedimentos sejam removidos ou alterados no processo para manter o time de trabalho sempre produtivo.
Product Owner é oficialmente responsável pelo projeto, pela gerência, e controle do PBL. Ele é escolhido pelo SCRUM Master, o cliente e a gerência. Ele toma as decisões finais relacionadas ao PBL e participa na estimativa de cada item do PBL.
SCRUM Team é o equipe de projeto responsável pelas ações necessárias à produção de cada Sprint.
Customers são os clientes participantes em tarefas relacionadas aos itens do PBL.
Management é responsável pelas decisões, padrões e convensões a serem seguidas pelo projeto.
3.2.3 FAMÍLIA CRISTAL DE METODOLOGIAS
A metodologia utilizada pela família Cristal consiste em um gerenciamento de projeto por ciclos de desenvolvimento.
A família Cristal de metodologias inclui um número de diferentes metodologias, selecionando a que mais se adequar ao projeto em questão. Cada membro da família cristal é marcado com um indicador de cor. As cores mais escuras indicam uma metodologia Heavy. Sugere a escolha da cor apropriada de metodologia para um projeto baseado em seu tamanho e criticidade. Projetos maiores exigem mais coordenação e rigor, logo exige as metodologias de cores mais escuras.
Há certas regras, vantagens e valores que são comuns a todas as metodologias na família Cristal. Primeiro de tudo, os projetos sempre usam o desenvolvimento incremental por ciclos com o máximo tamanho dos ciclos de quatro meses, mas preferencialmente de um a três meses. A ênfase é na comunicação e cooperação das pessoas. As metodologias da família Cristal não se limitam em nenhuma prática de desenvolvimento, ferramentas ou produtos. As três principais metodologias da família Cristal são : Crystal Clear, Crystal Orange e Crystal Orange
Web.
Todas as metodologias da família Cristal possuem guias de políticas de padrões, produtos de trabalho, ferramentas e papeis a serem seguidos no processo de desenvolvimento.
O Crystal Clear é destinado para pequenos projetos, de no máximo seis desenvolvedores. O Crystal Orange é destinado para projetos médios, com no máximo
de 40 pessoas e com duração de um a dois anos. No Crystal Orange o projeto é separado entre várias equipes multifuncionais.
A diferença básica entre o Crystal Clear e Orange é que o primeiro é formado por uma única equipe, enquanto o segundo, possui vários grupos multidisciplinares, esta divisão do projeto em grupos é feito através do método chamado “Estratégia de diversidade holística”, cuja idéia central é incluir múltiplos especialistas em um grupo.
No Crystal Clear os principais papéis são o patrocinador do projeto, programador sênior, programadores e usuários. Em adição aos papéis introduzidos no Crystal Clear, Crystal Orange sugere outros papéis necessários ao projeto, estes papéis são agrupados em áreas, tais como planejamento de sistema, coordenação de projeto, arquitetura, tecnologia, infra-estrutura e testes. Os grupos dão divididos em estruturas multifuncionais contendo diferentes papéis.
A Crystal Orange introduz vários outros papéis tais como Designer de interface,
Designer de banco de dados, expert em usabilidade, facilitador técnico, analista de
negócio, arquiteto, documentadores e testadores. Um membro do grupo pode assumir múltiplos papéis se necessário.
Figura 3 – Incremento Crystal Orange
Fonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)
3.2.4 Feature Driven Development (FDD)
FDD é uma abordagem ágil e adaptativa de desenvolvimento de sistema. O FDD não cobre o processo inteiro de desenvolvimento de software, dando preferência
ao design e as fases de construção, Palmer e Felsing (2002). Ele é preparado para trabalhar com outras atividades de um projeto de desenvolvimento de software e não requer qualquer modelo específico para ser usado, Palmer e Felsing (2002). O FDD incorpora o desenvolvimento interativo com as melhores práticas efetivas encontradas na industria. Ele enfatiza aspectos de qualidade através de processos e inclue deliveries freqüentes e tangíveis, com um acompanhamento preciso de evolução do projeto.
A FDD consiste em cinco processos seqüenciais e provê métodos, técnicas e guias necessários aos “Stakeholders” para a entrega do sistema em questão. Alem disso, o FDD inclue papéis, artefatos, objetivos e “timeline” necessários em um projeto, Palmer e Felsing (2002). Ao contrário de algumas outras metodologias ágeis, FDD afirma ser adequada para o desenvolvimento de sistemas críticos, Palmer e Felsing (2002).
Como mencionado antes, o FDD é composto de cinco processos seqüenciais que são destinados ao design e construção do sistema. A parte iterativa dos processos do FDD suporta desenvolvimento ágil com adaptações rápidas a mudanças no requerimento. A iteração de uma “feature” envolve uma a três semanas de trabalho para equipe.
Figura 4 – Fases FDD
Fonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)
Os processos são descritos abaixo:
a) Modelo Develop an Overall - Neste processo os experts de domínio já estão cientes do escopo, contexto e requerimentos do sistema para ser construído, Palmer e Felsing (2002). Requerimentos documentados, tais como, casos de uso ou especificações funcionais são prováveis de existir neste estágio. Os experts de domínio apresentam o chamado walkthrough no qual os membros da equipe e o arquiteto chefe são informados detalhadamente sobre o sistema.
b) Construção de uma lista de features – O “walkthrough”, modelos de objetos e documentos de requerimentos existentes dão a base para construção de uma lista de features para o sistema ser desenvolvido. Nesta lista, a equipe de desenvolvimento apresenta as funções valiosas para os clientes incluídas no sistema.
c) Planejamento por Feature – O planejamento por feature, inclue
a criação de um plano mais detalhado, no qual o conjunto feature são seqüenciadas de acordo com suas prioridades e dependências e entregues aos programadores chefes. Além disso, as classes identificadas no Modelo Develop an Overall são designadas aos desenvolvedores, isto é, os donos das classes. O cronograma e principais marcos podem ser definidos neste processo.
d) Design por Feature e Contrução por Feature – Um pequeno
grupo de features podem ser escolhidos para serem desenvolvidos. Os
Features são produzidos através de procedimentos iterativos. As Iterações
devem durar de poucos a no máximo duas semanas. Podem haver múltiplos grupos de features realizando o design e a construção de seus próprios features. Os processos iterativos incluem tarefas como inspeção de design, codificação, teste, integração e inspeção de código. Depois do sucesso da iteração inicia-se uma nova iteração com um novo conjunto de
feature.
O FDD classifica seus papeis em três categorias: papéis chaves, papéis de suporte e papéis adicionais, Palmer e Felsing (2002). Os seis papéis principais em um projeto FDD são: Gerente de Projeto, Arquiteto Chefe, Gerente de Desenvolvimento, Programador Chefe, Dono da Classe e expert de domínios. Os cinco papéis de suporte são: Gerente de Release, Guru de Linguagem, engenheiro de construção, “ToolSmith” e Administrador de Sistema. Os três papéis adicionais são: Testadores, “Deployers” e documentadores técnicos. Um membro pode ter múltiplos papéis, Palmer e Felsing (2002).
Segue abaixo as tarefas e responsabilidades dos diferentes papéis existentes na FDD, segundo Palmer (2002):
a) Gerente de Projeto é o líder administrativo e financeiro do projeto. Uma de suas tarefas é evitar dispersões por parte da equipe do projeto, fazendo que os mesmos mantenham um nível de trabalho contínuo.
b) Arquiteto Chefe é o responsável por todo o designer do sistema. Se necessário este papel pode ser desmembrado em dois: arquiteto de domínio e arquiteto técnico.
c) Gerente de Desenvolvimento lidera atividades diárias de desenvolvimento e resolve qualquer conflito que possa ocorrer dentro do time. As tarefas do papel podem ser combinadas com as do arquiteto chefe ou gerente de projeto
d) Programador Chefe é um desenvolvedor experiente que participa na análise de requisitos e design dos projetos. Ele é responsável por liderar pequenos times em análise, design e desenvolvimento de novos
features.
e) Dono da Classe é subordinado ao programador chefe nas tarefas de design, codificação, teste e documentação. Ele é responsável pelo desenvolvimento de classes.
f) Expert de domínio pode ser um usuário, um cliente, um patrocinador, um analista de negócio ou uma mistura destes. Ele possui o conhecimento de como os diferentes requerimentos do sistema devem funcionar.
g) Gerente de Domínio lidera os expert de domínios e dá a palavra final quando se trata de divergências de opinião sobre o requerimentos do sistema.
h) Gerente de Release controla o progresso do processo através de relatórios dos programadores. Ele reporta o progresso ao gerente de projeto.
i) Engenheiro do Construção responsável pelo controle de versão do sistema e publicação da documentação.
j) Language Guru é o detentor do conhecimento de uma linguagem ou tecnologia específica.
k) “ToolSmith” é o papel destinado a construção de pequenas ferramentas para desenvolvimento, teste e conversão de dados no projeto.
l) Administrador de Sistema se destina a configuração, gerenciamento e a descoberta de defeitos nos servidores, rede, desenvolvimento e ambiente de teste.
m) Testador verifica se o sistema produzido atende aos requerimentos dos clientes. Pode ser uma equipe independente ou parte do time do projeto.
n) “Deployer” trabalham na conversão dos dados existentes para o formato requerido do novo sistema. Pode ser uma equipe independente ou parte do time do projeto.
o) Documentador Técnico, responsável pela documentação técnica do sistema. Pode ser uma equipe independente ou parte do time do projeto.
3.2.5 Método de Desenvolvimento de Sistema Dinâmico (MDSD)
Desde suas origens em 1994, MDSD, tem se tornado o “framewok” número para o desenvolvimento de aplicações rápidas no Reino Unido , Stapleton (1997). A MDSD é um “framework” sem fins lucrativos mantido por um consórcio que leva o mesmo nome do método.
A idéia principal por trás da MDSD é que ao invés de fixar um conjunto de funcionalidade ao produto e ajustar tempo e recursos para atingi-lo, ele fixa o tempo e recursos, adaptando as funcionalidades.
A MDSD consiste em cinco fases: Estudo de viabilidade, Estudo do negócio, Iteração do modelo funcional, iteração do design e construção e implementação. As duas primeiras fases são seqüenciais e são feitas apenas uma vez. As últimas três fases são iterativas e incrementais. As iterações em MDSD são conhecidas como “caixas de tempo”, que podem durar de poucos dias a semanas.
As fases do MDSD são detalhadas abaixo:
a) Estudo de Viabilidade, verifica-se se o MDSD é
adequado ao projeto. Nesta fase dois produtos são preparados: o relatório de viabilidade e o plano de desenvolvimento. Esta fase é rápida e deve levar poucas semanas.
b) Estudo do Negócio é fase onde as características
essenciais e tecnológicas são analisadas. A abordagem recomendada é organizar “workshops”, onde um número suficiente de experts dos clientes são reunidos para discutirem sobre todas as funcionalidades do sistema e definir as prioridades de desenvolvimento. Os processos de
negócio afetados e classes de usuário são descritos na definição de área de negócio. Além da definição da área de negócio são feitos também a definição da arquitetura do sistema e um plano de prototipagem.
c) Iteração do modelo funcional, primeira fase iterativa e
incremental. A cada iteração, o conteúdo e a abordagem da iteração são planejados e os resultados analisados para iterações seguintes. Análise e codificação são feitas, protótipos são construídos e as experiências adquiridas são usadas para a melhoria dos modelos de análise. O modelo funcional é produzido contendo o código do protótipo e modelos de análise. Testar é também uma continua e essencial parte desta fase. Outros produtos desta fase são a lista de funções priorizadas, documento de revisão das funções do protótipo, requerimentos não funcionais e análise de risco.
d) Iteração de design e construção, onde o sistema é
realmente construído.
e) Implementação, fase onde o sistema é transferido do
ambiente de desenvolvimento para o ambiente atual de produção. O treinamento é dado aos usuários. Nesta fase incluem-se a entrega do manual do usuário e o relatório de revisão de projeto.
O MDSD define 15 papéis para usuários e desenvolvedores. Cinco dominantes estão descritos a seguir:
a) Desenvolvedores e Desenvolvedores seniores, os
desenvolvedores sênior estarão na liderança do time de desenvolvimento. Estes papéis englobam todo o staff de desenvolvimento, que são analistas, designers, programadores e testadores.
b) Coordenador Técnico define a arquitetura do sistema e
é responsável pela qualidade técnica do projeto. Ele também é responsável pelo controle do projeto técnico, como por exemplo, o gerenciamento da configuração de software.
c) Usuário Embaixador, responsável por divulgar entre os
outros usuários o progresso do projeto, garantindo um “feedback” adequado aos outros usuários.
d) Visionário, usuário participante que possui uma
percepção apurada dos objetivos do negócio do sistema e do projeto. O visionário é provavelmente, aquele que iniciou a idéia de construção do sistema. A tarefa do visionário é garantir que os requerimentos essenciais sejam encontrados logo e que o projeto mantenha-se na direção certa com relação a estes requerimentos.
e) Patrocinador Executivo é a pessoa da organização que
tem autoridade e responsabilidade financeira.
Figura 5 – Diagrama de Processos do MDSD
Fonte: 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 princípios da DAS deriva da pesquisa de Highsmith em métodos iterativos de desenvolvimento. O DAS é antecessor do desenvolvimento radical de software.
O DAS foca-se principalmente em problemas de desenvolvimento complexo e grandes sistemas. O método encoraja o desenvolvimento iterativo e incremental, com prototipação constante.
Ele é composto por três fases: Especular, Colaborar e Aprender. Especulação é usada no lugar de planejamento, pois um plano é visto como algo que demanda
alguma incerteza que pode ocasionar uma falha. Similarmente, Colaborar realça a importância do trabalho de equipe. Aprender enfatiza a necessidade de reconhecer e reagir a erros e o fato que os requerimentos podem mudar durante o desenvolvimento.
Na iniciação do projeto define-se a missão do projeto, que se destina a descobrir as informações para se fazer o projeto. As observações importantes da missão são definidas em três itens: Project vision charter, Project data sheet e product
specification outline. A iniciação do projeto fixa todo o cronograma e objetivos para os
ciclos de desenvolvimento. Os ciclos tipicamente duram de quatro a oito semanas. O DAS é explicitamente orientada a componentes (figura 6). Na prática, isto significa que o foco é mais em resultados e em sua qualidade, ao contrário do que seria se o foco fosse em tarefas ou processos usados para produzir resultados. O modo como o DAS viabiliza este ponto de vista, é através de ciclos de desenvolvimento adaptativos, contido na fase colaboração onde vários componentes podem está sendo desenvolvido concorrentemente. O planejamento dos ciclos é parte do processo iterativo e as definições dos componentes são continuamente refinadas para refletir qualquer nova informação.
Na fase de aprendizagem, a qualidade é revista de forma repetitiva, com o foco na demonstração da funcionalidade do software desenvolvido durante o ciclo. Um fator importante de performance nas revisões é a presença do cliente.
Os principais papéis da DAS são: Patrocinador executivo, pessoa que possui responsabilidade completa pelo desenvolvimento do produto, facilitador para planejar e liderar as sessões, um escrivão para marcar os minutos, gerente de projeto e cliente.
Figura 6 – Diagrama de fases do DAS
4.
eXtreme Project Management (XPM)
(BECK, 2001)XPM consiste em uma abordagem ágil de gerenciamento de projetos cuja característica principal está na sua relação à mudança: diferentemente da abordagem tradicional, na qual o planejamento é direcionado aos resultados, ao contrário da ágil, onde os resultados direcionam o planejamento, sendo necessário facilitar a mudança, e não desencorajá-la por meio de processos complexos, que restringem e diminuem a criatividade.
O XPM visa melhorar o gerenciamento de projetos, em especial aos projetos de software para os quais o tempo e o custo para tornar o produto disponível no mercado são críticos, não sendo possível elaborar um cronograma detalhado e uma especificação de requisitos em um estágio preliminar do processo, e mostra-se necessária uma avaliação diária do projeto para adequá-lo à situação de mercado. A meta é a entrega do resultado desejado, e não necessariamente o resultado inicialmente planejado. Ela é definida por um conjunto de 11 regras e cinco ferramentas, descritas a seguir, que possuem como missão dar suporte à mudança, planejando critérios de sucesso para stakeholders, citando cenários e eventos principais, definindo benefícios esperados e como atingi-los e estabelecendo acordos com parceiros e em relação à qualidade exigida.
4.1 Regras
4.1.1 XPM Regra 1: A gerência de pessoas e processos criativos demanda processos criativos.
Não existe uma forma única e ideal para gerenciar projetos na dinâmica atual do mercado. Tanto gerente quanto equipe precisam ser criativos no desenvolvimento de um produto inovador, com alto valor para o negócio e maior qualidade. É necessário considerar não só as expectativas e os requisitos dos clientes, mas também o contexto e as estratégias da própria organização, em busca de um planejamento, monitoramento e controle mais tangível do projeto.
4.1.2 XPM Regra 2: Quanto menos o gerente souber sobre questões técnicas do projeto, melhor.
O gerente de projeto vai ter que se responsabilizar em analisar o número de variáveis complexas para poder desenvolver um plano realístico que não somente identifique as expectativas dos clientes, requerimentos funcionais especificados, riscos e custos, mas também devem focar-se e entender o contexto organizacional dentro a qual o projeto está sendo desenvolvido.
Para entender e gerenciar um projeto, o gerente deve fazer distinção entre os aspectos gerenciais e técnicos.
O gerenciamento tradicional freqüentemente confunde o gerenciamento de projeto com o gerenciamento técnico. O processo de gerenciamento técnico requer um entendimento detalhado do processo de desenvolvimento de sistema: análise, design, programação e teste e consiste em assistência ao time técnico. O gerente técnico é um “guru”, pessoa que detém profundas habilidades técnicas.
O gerente de projeto tem um foco diferente e é direcionado por um conjunto diferente de informações que não são técnicas, elas trazem em seu contexto, informações gerenciais sobre o projeto. Os aspectos técnicos e gerenciais são integrados através do escopo, objetivos, estratégias e requerimentos de qualidade do cliente.
Com a freqüente mudança da tecnologia e a complexidade envolvendo as mais variadas técnicas de desenvolvimento, torna-se difícil, se não impossível para o gerente de projeto ter todas as habilidades técnicas necessárias para torná-lo responsável pelo gerenciamento técnico do projeto.
O escopo, objetivos, estratégia e qualidade são um elo de ligação entre o gerenciamento técnico e o de projeto. O gerente de projeto deve definir e concordar com o escopo e objetivos do projeto como requerido pelo cliente. O analista de sistema deve então se focar neste escopo e objetivos acordados para realizar sua análise e
4.1.3 XPM Regra 3: O que ocorre depois do projeto é mais importante do que ocorre durante o projeto
No gerenciamento tradicional de projeto, após o desenvolvimento, poucas empresas rastreiam seus custos ou os benefícios realizados. A ausência destas informações no ciclo de produção deixam o alto escalão sem evidências do valor agregado através dos novos produtos ou sistemas de informação, o que tem também contribuído para o se ter uma visão errada da Tecnologia de Informação como um centro de custo.
4.1.4 XPM Regra 4: O planejamento de projeto desenvolvido sem a participação completa dos stakeholders não é mais que a fantasia de uma única pessoa
Para ser um sucesso, o planejamento dos e-projects em um contexto organizacional contemporâneo o gerente de projeto deve identificar os stakeholdes1 chaves relacionados ao projeto e com os
membros do time de projeto realizar um processo de planejamento de maneira aberta e colaborativa.
Este conceito de gerenciamento de projeto aberto garante que todos os provedores de serviço para o gerente de projeto e todos os gerentes de projetos nos projetos relacionados estejam preparados para suportar sua tabela de horários previamente estabelecida.
As complexidades internas e externas dos e-projects podem simplesmente sobrecarregar uma única pessoa. Um time tem uma capacidade maior para garantir que tudo que foi planejado seja completado e preciso.
Deve ser enfatizado que a abordagem do planejamento aberto é baseada em consenso, o gerente de projeto é ainda a pessoa responsável. Freqüentemente o time envolvido não vai chegar a um consenso e nestes casos, cabe ao gerente de projeto
1
Stakeholders são indivíduos ou as organizações que estão ativamente envolvidos em um projeto cujos interesses podem afetar positivamente ou negativamente o resultado da execução do projeto
juntamente com o dono ou patrocinador do projeto resolver o impasse.
O conceito de um encontro de um grande grupo de pessoas para planejar o projeto pode ser visto como risco e custo, mas experiências mostram que o processo aberto é mais rápido, tem menos custo e mais preciso. A XPM usa o Planejamento Rápido (RAP) para produzir planos de projeto – um conceito semelhante ao Desenvolvimento Rápido de Aplicação (RAD)
Quadro 03 : Etapas do Planejamento Rápido (RAP)
Etapa Descrição
Definir Sucesso Estabelecer as expectativas que cada participante tem para o sucesso. Definir escopo, objetivos, stakeholders e
projetos relacionados
Analisar o escopo e objetivos do projeto
Analisar os benefícios do projeto Analisar os benefícios gerados ao negócio com o produto, sistema ou serviço sendo desenvolvido
Analisar a qualidade do projeto Analisar a qualidade do produto que está sendo gerado
Analisar cenários / estratégias do projeto Definir as estratégias que devem ser tomadas ao longo do projeto
Analisar risco do projeto e desenvolver um plano de gerenciamento de risco
Estabelecer os riscos para o projeto, a probabilidade e impacto dos mesmos e um plano de respostas a estes riscos. Desenvolver a lista de tarefas do projeto Estabelecer a lista de tarefas do projeto Estimar as tarefas do projeto Estimar o tempo de conclusão para cada
uma das tarefas.
Desenvolver cronograma do projeto Elaborar o cronograma das tarefas do projeto.
Fonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)
4.1.5 XPM Regra 5: Quanto mais tempo o gerente de projetos permanecer com os stakeholders melhor
A XPM está envolvida com o contexto do projeto (ambiente organizacional, social, político e financeiro no qual o projeto está sendo desenvolvido), logo a gerência do contexto trata do gerenciamento das expectativas de um conjunto complexo e variado de stakeholders. O gerenciamento do contexto preocupa-se com o time de projeto e processos internos envolvendo o desenvolvimento do produto.
4.1.6 XPM Regra 6: Se o sucesso do projeto não for definido no começo, ele nunca será alcançado no final
Para muitos gerentes de projetos e analistas de sistemas, expectativas são simplesmente aqueles elementos requeridos que não foram especificados pelos clientes. Para outros, expectativas são a diferença entre o que o cliente quer e o que eles realmente precisam. Em uma batalha dura para o gerente de projeto, as expectativas são uma lista de desejo que inicia uma serie de negociações difíceis para reduzir estas expectativas. As expectativas ansiadas pelos clientes são relativas a satisfação dos
stakeholders, atendimento dos objetivos / requerimentos funcionais,
a permanência dentro do orçamento, a manutenção dos prazos, agregar valor ao negócio, assegurar uma boa qualidade ao produto e deixar os membros da equipe satisfeitos. A ferramenta sugerida para o acompanhamento é composta por sliders de sucesso, um indicador que representa o grau de atendimento aos critérios de sucesso.
4.1.7 XPM Regra 7: Mostre-lhes o lucro: nada mais importa
Mais do que facilitadora de processos, a força atual da TI reside em tornar o negócio mais lucrativo e competitivo. Uma análise cuidadosa do negócio permitirá identificar o valor agregado pelo produto e priorizar funcionalidades a serem desenvolvidas, visando empregar menos esforço na obtenção de mais benefícios. As ferramentas utilizadas são:
a) O modelo O3 (Objective, Output, Outcome), que cria uma cadeia de valores para o projeto, permitindo modelar e perceber os benefícios associados aos objetivos. Ele parte do princípio de que a organização só será capaz de alcançar seus resultados se o projeto tiver sucesso na produção de resultados relevantes. Ele está baseado no modelo IRACIS (Increase Revenue, Avoid Costs and
Improve Services), Thomsett (2002), que possibilita identificar se os
b) Um Acordo de Qualidade que, a partir dos objetivos do produto, estabelece os critérios para definir sua qualidade e os processos presentes no desenvolvimento que irão assegurá-la, uma vez que a melhoria de um atributo de qualidade pode causar impacto negativo em outro.
4.1.8 XPM Regra 8: Os Stakeholders do projeto podem ser seus melhores aliados ou seus piores inimigos
Depois do principal papel do projeto, o patrocinador, a segunda causa mais comum de falha de projeto é o papel de
stakeholders do projeto e projetos relacionados. Em muitos e-projects há um conjunto complexo de interdependências entre o
projeto e seu contexto organizacional.
Existe risco de um stakeholder (como um fornecedor de recursos) ser deslocado para outro projeto, o que geralmente causa impacto negativo. Na tentativa de evitar tais situações, o XPM sugere ao gerente a utilização de Acordos de Parceria, uma ferramenta que documenta os serviços requeridos, o tempo e o custo estimado para sua realização e a identificação de pessoas em condições de fornecer um retorno sobre os serviços para o stakeholder. Manter os stakeholders informados sobre os resultados ajuda a manter uma boa relação no projeto.
4.1.9 XPM Regra 9: Se você não pode prever o futuro, não planeje em detalhe
O XPM abrange planejamento e re-planejamento diários, como parte do processo da equipe e dos stakeholders. Todas as alterações relativas a contexto, externas e internas. Riscos, escopo, objetivos, valor agregado, etc. . são identificadas e avaliadas diariamente, o que se ajusta extremamente bem aos conceitos de XP. Na sessão de RAP os principais eventos e cenários relacionados à entrega do produto são identificados, e somente tarefas que visem atingir um evento específico são detalhadas e incluídas no cronograma. A ferramenta de planejamento em tempo real de eventos e cenário é uma extensão simples das práticas de desenvolvimento utilizadas em XP.
