UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO FACULDADE DE TECNOLOGIA CAMPUS REGIONAL DE RESENDE PS-GRADUAO EM ENGENHARIA DE PRODUO COM NFASE EM GESTO

DE PROJETOS

TRABALHO FINAL DE CURSO

SCRUM e XP: Aderentes ou Divergentes ao PMBOK?

Anderson Moyss de Arajo Diego da Silva Marcato

Resende - RJ Novembro / 2010

SUMRIO

1.Introduo...............................................................................................................4 2.Reviso da Literatura..............................................................................................5 2.1. Guia do Conhecimento em Gerenciamento de Projetos (PMBOK)...................5 2.2. SCRUM...............................................................................................................6 2.3.Extreme Programming (XP)................................................................................7 3.Metodologia............................................................................................................8 4.Projetos de Softwares ............................................................................................8 5.reas Divergentes................................................................................................10 5.1.Gerenciamento de Escopo ...............................................................................10 5.2.Gerenciamento do Tempo.................................................................................12 5.3.Gerenciamento de Recursos Humanos............................................................13 5.4.Gerenciamento da Comunicao......................................................................15 Concluso................................................................................................................18 Referncias Bibliogrficas.......................................................................................20

1. Introduo
O processo gradativo de evoluo da humanidade se deu atravs de vrios projetos. No incio desse processo, os feitos que hoje podemos conceituar de projetos, foram realizados de maneira totalmente emprica. No sculo XIX com os ensaios de Auguste Comte o mtodo cientfico e o positivismo mudaram o rumo da nossa sociedade, onde agora o empirismo passou a ser substitudo pela observao dos fatos e de prticas j utilizadas. Com o passar do tempo os feitos agora j no sculo XX sendo chamados de projetos, foram se tornando cada vez mais complexos. Existem as mais variadas metodologias de projetos para os mais diversos segmentos da sociedade. Este trabalho ir apresentar trs metodologias de gerenciamento de projetos (PMBOK, SCRUM e XP), sendo duas ltimas conhecidas como metodologias geis, que prezam por fatores como indivduos e as suas interaes, constante aproximao e feedback dos clientes alm de resposta imediata a mudanas. Dentre as metodologias geis uma voltada especificamente para o setor de TI (Tecnologia da Informao), desenvolvimento de software, e a outra apresentam utilizaes em outros segmentos. Aps apresent-las, este estudo confronta seus pontos fortes e prticas utilizadas por cada uma delas alm de extrair o que h de melhor, a fim que atendam as necessidades de gestores que buscam gerenciar projetos de forma efetiva com o mnimo de prazo possvel, utilizando de princpios apresentados inicialmente pelos autores do Agile Manifest (2001), que prezam por: Indivduos e interaes mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; Responder a mudanas mais que seguir um plano. (Agile Manifest, 2001).

Devido alta complexidade que exigida no gerenciamento de projetos, uma grande dose de experincia e assertividade, so fundamentais para aos gerentes de projetos. Para tal temos uma enorme gama de metodologias a serem aplicadas em projetos. Com isso gerentes de projeto tendem a ter dificuldades em definir qual a melhor metodologia a ser aplicada em seu projeto. Alguns gerentes optam pela metodologia que ele possui mais experincia, outros optam pela metodologia de acordo com o perfil do projeto e das premissas reportadas no contrato, alegando que muitas metodologias no podem ser aplicadas simultaneamente. Diante da dificuldade apresentada anteriormente, o presente artigo se prope a observar as prticas do PMBOK, SCRUM e XP, e apontar quais so as melhores ferramentas e mtodos de cada uma das metodologias, a fim de refinar o processo de gerenciamento de projetos eliminando possveis erros decorrentes da falta de experincia O estudo foca em projetos de Tecnologia de Informao, mais precisamente, projetos de desenvolvimento de software. Alm do uso de casos de sucesso, sero adotados artigos cientficos de relevncia sobre o assunto.

2. Reviso da Literatura 2.1. Guia do Conhecimento em Gerenciamento de Projetos (PMBOK)

O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK) uma norma reconhecida para a profisso de gerenciamento de projetos. Um padro, um documento formal que descreve normas, processos e prticas estabelecidas. Assim como em outras profisses como advocacia, medicina e contabilidade, o conhecimento contido nesse padro evoluiu a partir das boas prticas reconhecidas de profissionais de gerenciamento de projetos que contriburam para o seu desenvolvimento. (PMI, 2008) Segundo o PMI, o objetivo do PMBOK :
O principal objetivo do Guia PMBOK identificar o subconjunto do conjunto de conhecimentos em gerenciamento de projetos que amplamente reconhecido como boa prtica. Identificar significa fornecer uma viso geral, e no uma descrio completa. Amplamente reconhecido significa que o conhecimento e as prticas descritas so aplicveis maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relao ao seu valor e sua utilidade. Boa prtica significa que existe acordo geral de que a aplicao correta dessas

habilidades, ferramentas e tcnicas podem aumentar as chances de sucesso em uma ampla srie de projetos diferentes. Uma boa prtica no significa que o conhecimento descrito dever ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos responsvel por determinar o que adequado para um projeto especfico (PMI, 2008, p. 9).

O conceito de projeto do PMBOK est ligado diretamente ao esforo despendido de carter temporrio, havendo assim um incio e fim. Durante o perodo de vida do projeto este conjunto de boas prticas busca controlar o bom andamento do projeto atravs de nove competncias (Integrao, Escopo, Tempo, Custos, Qualidade, Recursos Humanos, Comunicaes, Riscos e Aquisies) de maneira que na falta de uma delas pelo menos outra competncia seja afetada.

2.2. SCRUM
O SCRUM no uma tcnica, ou processo para o desenvolvimento de um produto, e sim uma espcie de ambiente, onde tcnicas e processos podem ser empregados, transparecendo eficincia e eficcia, na melhoria do desenvolvimento de determinado produto. Segundo Neto (2008), sua origem ocorreu na segunda metade da dcada de 80, em um artigo escrito por Takeuchi e Nonaka, que apresenta as dez melhores e mais inovadoras prticas em empresas japonesas, denominado The New New Product Development Game, Harvard Business Review (NETO, 2008). Com nome originado em uma jogada do rgbi, que os jogadores planejam a jogada seguinte, assim como na conduo de um projeto, onde utiliza de pequenos ciclos, mas com um foco, que ganhar o jogo. Conforme Soares (2009) esclarece a respeito do SCRUM:
um processo gil que permite manter o foco na entrega do maior valor de negcio, no menor tempo possvel. As necessidades do negcio que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade. (SOARES, A.P., 2009, p.28)

Chapiewski (2009) diz que as prticas do SCRUM podem ser aplicadas em qualquer contexto onde pessoas precisem trabalhar juntas para atingir um objetivo comum. SCRUM recomendado para projetos de outras reas alm de software principalmente para projetos de pesquisa e inovao; A filosofia SCRUM, como chamada por alguns seguidores, sustenta sob trs importantes pilares, que prezam: a transparncia, a inspeo e a adaptao. Estes sempre devem permanecer em harmonia, cada um com sua designao para que haja a garantia de uma eficaz utilizao (SCHWABER, 2009). Outras importantes vertentes so as Equipes/Times (flexveis, produtivos, autoorganizveis, interdisciplinares e iterativos), Time-Boxes (Eventos com durao fixa), Artefatos (itens de controle necessrios para o desenvolvimento) e as Regras (elo entre os eventos com durao fixa (Time-Boxes), a equipe e os artefatos) (SCHWABER, 2009). Dentre os papis da Equipe SCRUM, h dois que se diferem das tradicionais formas de Gerenciamento de Projeto, so eles:
O ScrumMaster responsvel por garantir que o Time SCRUM esteja aderindo aos valores do SCRUM, s prticas e s regras. O ScrumMaster ajuda o Time SCRUM e a organizao a adotarem o SCRUM. O ScrumMaster educa o Time SCRUM treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda o Time SCRUM a entender e usar autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster no gerencia o Time SCRUM; o Time SCRUM auto-organizvel. (SCHWABER, K., 2009, p. 6)

O outro papel o de Product Owner, representa os interesses de todos os envolvidos, define e prioriza as funcionalidades do produto que ser desenvolvido. Toda essa estrutura do SCRUM est sob importantes itens que no poderiam deixar de serem abordados. De acordo com Soares (2009), os mesmos so Product Backlog (uma lista de funcionalidades desejadas para o produto), Sprint (que se julga possvel desenvolver num ciclo/iterao) e Burndown Chart (Grfico de Consumo, que utilizado para acompanhar o progresso e a velocidade da equipe de desenvolvimento).

2.3.Extreme Programming (XP)

A Extreme Programming (XP) uma metodologia gil para equipes de pequeno e mdio porte onde os requisitos de um software so vagos ou esto em constante mudana. A sua premissa maior o contato com o cliente atravs de reunies dirias, afim de que haja um constante ajuste da necessidade real do cliente. O cliente descreve as funcionalidades predizendo o que ser feito para os desenvolvedores. A idia que de posse desses formulrios a equipe de desenvolvedores possa entregar um produto que o cliente efetivamente tenha condies de usar (BECK, 2004). Esta metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da dcada de 90. Tem por objetivo ajudar a criar sistemas de melhor qualidade, que so produzidos em menos tempo e de forma mais econmica que o habitual. Tais objetivos so alcanados atravs de um pequeno conjunto de valores, princpios e prticas, que diferem substancialmente da forma tradicional de se desenvolver um software (TELES, 2005).

3. Metodologia
O processo de construo deste trabalho ser baseado nas reas de conhecimento do PMBOK onde haja pontos com vises e forma de atuao divergente entre as trs metodologias citadas. Divergncias essas que sero apresentadas dentro das reas de conhecimento do PMBOK, que sofrem os maiores impactos em projetos de software (Escopo, Tempo, Recursos Humanos e Comunicaes). Haver uma seco para que os projetos de softwares sejam apresentados, mostrando suas principais caractersticas e diferenas em relao aos demais tipos de projetos com os da construo civil e projeto das da rea de defesa, dos quais originaram o PMBOK. Para a obteno das informaes necessrias para a construo deste trabalho, sero utilizados os mais diversos tipos de literatura, como livros, trabalhos acadmicos, peridicos especializados e at sites que apresentem informaes contextualizadas e confiveis. Atravs de todo esse estudo poder ser feito um correto cruzamento das caractersticas do PMBOK, SCRUM e XP.

4. Projetos de Softwares

O projeto de um sistema de software tem muitas caractersticas em comum com projetos de engenharia, do ponto de vista do mapeamento dos requisitos funcionais em solues

tecnolgicas (PIMENTEL, 2007). Apesar de se tratar de um servio prestado, o dito produto de um projeto de software possui caractersticas e processos especficos. Segundo Falbo (2009):
No que se refere ao produto, a primeira coisa a se fazer definir o escopo do projeto. Para tal, necessrio fazer um levantamento de requisitos inicial. A idia decompor o problema, em uma abordagem dividir para conquistar. Inicialmente, o sistema deve ser decomposto em subsistemas que so, por sua vez, decompostos em mdulos. Os mdulos podem, ainda, ser recursivamente decompostos em submdulos ou funes, at que se tenha uma viso geral das funcionalidades a serem tratadas no projeto. (FALBO, 2009)

Segundo Sommerville (2007), o gerenciamento eficiente de software depende de um planejamento minucioso do progresso do projeto. Os gerentes devem prever os problemas que podem ocorrer e preparar solues experimentais para esses problemas. Um plano elaborado no incio de um projeto deve ser usado como guia, Esse plano inicial deve ser o melhor possvel em face de das informaes disponveis. Ele deve evoluir medida que o projeto progride e melhores informaes se tornem disponveis. Em projeto de software o escopo normalmente trabalhado de forma fechada, onde so feitas reunies iniciais com cliente, a fim de se definir com ele o tempo necessrio a ser utilizado no planejamento e execuo do projeto. Este processo traz para a equipe de projeto todo o risco decorrente das mudanas de escopo, aumentando as chances de mudanas de escopo, a em casos mais extremos, paralisao do projeto. de suma importncia a participao do cliente. Para Teles (2005), ao colocar as pessoas com as necessidades de negcio em contato direto com os desenvolvedores facilita a compreenso dos requisitos, alm de acelerar o feedback. O usurio que participa da equipe pode dar um feedback rpido e ajudar a definir prioridades. Outro grande desafio no projeto de software alocao de recursos humanos no projeto. Voc pode precisar montar sua equipe usando engenheiros relativamente inexperientes. Isso pode trazer problemas, pois os membros da equipe no compreendem o domnio da aplicao ou tecnologia. Entretanto, em um projeto de longo prazo, a compreenso de conceitos e de domnio da aplicao mais importante que o conhecimento especfico, particularmente de linguagens de programao e mtodos. (SOMMERVILLE, 2007). Pimentel (2009) cita que estimar e calcular a complexidade de um sistema de software um parmetro importante para o desenvolvimento com qualidade. importante ter-se uma estimativa do tamanho do sistema para se conseguir estimar o esforo necessrio na sua

10

construo. Para tal so usadas mtricas especficas para a medio de esforo de desenvolvimento de software. Estas mtricas avaliam o tamanho e a complexidade do produto/software desenvolvido, tendo como objetivo servir de base para estimativas de esforo para futuros desenvolvimentos e para avaliar a produtividade das equipes. As mtricas de software so quantitativas e, por este motivo, no tem como dizer se um conjunto de classes e objetos o mais adequado para satisfazer um determinado conjunto de requisitos funcionais, mas apenas dizer se um conjunto de classes mais complexo que outro.

5. reas Divergentes 5.1.Gerenciamento de Escopo

O Gerenciamento do Escopo do projeto definido com muita propriedade por Sotille (2010):
O Gerenciamento do escopo do projeto o processo que garante que o projeto inclui todo o trabalho requerido, e somente o trabalho requerido, para complet-lo com sucesso. O gerenciamento do escopo a base para o planejamento do projeto e para a criao de sua linha base, e deve ser conduzido de forma precisa, uma vez que forma a base do trabalho a ser desenvolvido no projeto. (SOTILLE et. al, 2010, p. 19).

Assim como todas as reas de conhecimentos do PMBOK trabalham baseadas em processos, que muitas vezes so rgidos, e de difcil aceitao s mudanas, com o escopo, no seria diferente, este processos so: Coletar os requisitos O processo de definio e documentao das necessidades das partes interessadas para alcanar os objetivos do projeto. Definir o escopo O processo de desenvolvimento de uma descrio detalhada do projeto e do produto.

11

Criar o EAP1 O processo de subdiviso das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciveis. Verificar o escopo O processo de formalizao da aceitao das entregas terminadas do projeto. Controlar o escopo O processo de monitoramento do progresso do escopo do projeto e escopo do produto e gerenciamento das mudanas feitas na linha de base do escopo. (PMI, 2008, p. 92). Dentro do SCRUM, o Product Backlog (Backlog do Produto), assume o papel do escopo, como explanado por Schwaber (2009):
O Backlog do Produto representa tudo que necessrio para desenvolver e lanar um produto de sucesso. uma lista de todas as caractersticas, funes, tecnologias, melhorias e correes de defeitos que constituem as mudanas que sero efetuadas no produto para verses futuras. Os itens do Backlog do Produto possuem os atributos de descrio, prioridade e estimativa. A prioridade determinada por risco, valor e necessidade. H diversas tcnicas para dar valor a esses atributos. (...) Os requisitos nunca param de mudar. O Backlog do Produto um documento vivo. Mudanas nos requisitos de negcios, condies do mercado, tecnologia e equipe causam mudanas no Backlog do Produto. Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados. (SCHWABER, K., 2009, p. 17).

No XP, o processo de gerenciamento do escopo, passa diretamente pela rea de comunicao, pois conforme Arajo [1] (2009), o planejamento funciona de forma iterativa, ou seja, atravs de ciclos/loopings, o que garante e exige uma maior proximidade dos usurios (solicitantes), forando para que haja uma validao e priorizao a cada entrega. Toda essa proximidade com os usurios vem antes mesmo do desenvolvimento, inicia-se no planejamento do projeto, pois so os solicitantes quem escreve as estrias de usurios, que descreve todos os cenrios com situaes de utilizao, na qual o projeto dever realizar aps sua concluso.
1

Estrutura Analtica de Projetos, ingls Work Breakdown Structure (WBS) uma ferramenta de decomposio do trabalho do projeto em partes manejveis

12

5.2.Gerenciamento do Tempo
O bom desenvolvimento do projeto est relacionado com um planejamento de tempo coerente com a expertise dos recursos e a complexidade do projeto. Segundo o PMBOK (2008), o gerenciamento de tempo do projeto inclui os processos necessrios para gerenciar o trmino pontual do projeto. So eles: Definir as atividades O processo de identificao das aes especficas a serem realizadas para produzir as entregas de projeto. Sequenciar as atividades O processo de identificao e documentao dos relacionamentos entre as atividades do projeto. Estimar os recursos da atividade O processo de estimativa dos tipos e quantidades de material, pessoas, equipamentos ou suprimentos que sero necessrios para realizar cada atividade. Estimar as duraes da atividade O processo de estimativa do nmero de perodos de trabalho que sero necessrios para terminar as atividades especficas com os recursos estimados. Desenvolver o cronograma O processo de anlise das sequncias das atividades, suas duraes, recursos necessrios e restries do cronograma visando criar o cronograma do projeto. Controlar o cronograma O processo de monitoramento do andamento do projeto para atualizao do seu progresso e gerenciamento de mudanas feitas na linha de base do cronograma. (PMI, 2008, p. 181). Esses processos interagem entre si e com os de outras reas de conhecimento. Podem envolver esforos de um grupo ou de uma pessoa, com base nas necessidades de projeto. Cada processo ocorre pelo menos uma vez em todo projeto e em uma ou mais fases do mesmo, se dividido em fases (PMI, 2008, p. 112). O processo de definio de datas e prazos no XP normalmente definido semanalmente atravs do Planning Game. Nestes encontros a equipe de desenvolvimento se rene com o cliente onde so priorizadas as funcionalidades a serem desenvolvidas alm de neste momento

13

estim-las. Segundo Leonel et. al. (2007), a cada comeo de semana o escopo do projeto reavaliado, girando em torno de um contrato de escopo negocivel, que diferente das formas normais de contratao de desenvolvimento de software. Ao final de cada semana, os desenvolvedores entregam resultado desenvolvido durante a semana, podendo assim o cliente j colocar as funcionalidades desenvolvidas em ao. De acordo com Decarlo (2004), para a realizao da estimativa do esforo requerido a cada interao, devem ser levadas trs consideraes: Incertezas que possam vir a ocorrer no projeto e que devem ser revisadas pela equipe atravs o arquivamento de incertezas para acompanhamento dos riscos; Levantar o nvel de qualidade requerido para condies vencedoras. Sem essa diretriz o projeto pode vir a ser um fracasso. Esteja certo de que as mtricas definidas por voc tenham sido aceitas pela equipe. Definir para cada entrega o esforo melhor, pior e o razovel levando em considerao para cada recurso 6 horas/dia, j que apesar do dia ter 8 horas teis, parte de este tempo ser gasto em outras atividades Arajo [2] (2009) cita que no SCRUM a equipe de projeto junto com o cliente deve colaborar para definir o cronograma, a sua sequncia e a forma de controle adequada enquanto no PMBOK a confeco do cronograma uma responsabilidade inerente ao gerente de projetos. As abordagens do SCRUM e do PMBOK no tocante a confeco do so semelhantes nas definies de atividades e processos de estimativas. Para o SCRUM, estimativa de esforo combinada com velocidade igual ao oramento e cronograma de um projeto, sendo ele desenvolvido de forma iterativa atravs do sprint e gerenciado atravs do grfico de burndown (SEVERINO, 2009).

5.3.Gerenciamento de Recursos Humanos

No possvel falar de Recursos Humanos, sem fazer algumas definies prvias, conceitos que podem parecer simples, mas algumas vezes acabam passando despercebido ao longo dos estudos, definies como as de grupo e equipe por exemplo. Conforme Macdo (2010) explana, um grupo uma reunio de pessoas com um ou mais objetivos comuns e que se percebem como seus integrantes. J uma equipe so grupos que evoluram, ou seja, quando este

14

grupo em questo passa a prestar ateno sua prpria forma de operar e procura resolver problemas que impactam suas atividades, aplicando assim habilidades e experincias. Segundo o PMI (2008), o gerenciamento dos recursos humanos do projeto composto por processos (que organizam e gerenciam a equipe de projeto), equipes (que so as pessoas com papis e responsabilidades designadas). Ainda no PMBOK, pode-se observar os processos: Desenvolver o plano de recursos humanos O processo de identificao e documentao de funes, responsabilidades, habilidades necessrias e relaes hierrquicas do projeto, alm da criao de um plano de gerenciamento pessoal. Mobilizar a equipe do projeto O processo de melhoria de confirmao da disponibilidade dos recursos humanos e obteno da equipe necessria para concluir as designaes do projeto. Desenvolver a equipe de projeto O processo de melhoria de competncias, interao da equipe e ambiente global da equipe para aprimorar o desempenho do projeto. Gerenciar a equipe do projeto O processo de acompanhar o desempenho de membros da equipe, fornecer feedback, resolver questes e gerenciar mudanas para otimiza o desempenho. (PMI, 2008, p. 181). Para as equipes de projeto, deve-se definir os papis, autoridade, responsabilidades e competncias que so necessrias para a concluso de um projeto: Papel A designao que descreve a parte de um projeto pela qual uma pessoa responsvel e responde pelos resultados. (...) A clareza do papel em relao a autoridade, responsabilidades e limites deve ser documentada. Autoridade O direito de aplicar recursos do projeto, tomar decises e assinar aprovaes. Responsabilidade O trabalho que se espera que um membro da equipe do projeto execute para concluir as atividades do projeto. Competncia A habilidade e a capacidade necessrias para concluir atividades do projeto. (PMI, 2008, p. 187).

15

As prticas de XP impactam diretamente no gerenciamento de recursos humanos de um projeto e at mesmo de uma organizao como um todo conforme Teles (2008) apresenta:
Projetos XP afetam as prticas de recursos humanos de uma organizao, em particular no que se refere a contrataes e avaliaes peridicas dos funcionrios. O fato de os programadores trabalharem em pares, por exemplo, leva necessidade de pessoas que no apenas tenham boas habilidades tcnicas, mas tambm saibam interagir socialmente com naturalidade. Portanto, a contratao no pode se basear apenas em critrios tcnicos e as avaliaes individuais se tornam complexas porque difcil isolar o rendimento do trabalho individual quando se trabalha em par a maior parte do tempo. (...) Papis em uma equipe XP no so fixos e rgidos. O objetivo fazer com que cada um contribua com o melhor que tem a oferecer para que a equipe tenha sucesso. Em princpio, papis fixos podem ser teis para se aprender novos hbitos, como por exemplo, fazer com que as decises tcnicas sejam deixadas para o pessoal tcnico e decises de negcio, com pessoas de negcio. (TELES, 2008).

Conforme Pacheco (2010), o SCRUM prov, atravs de um mtodo simples - uma instncia do PDCA -, uma forma de forar a conversao na equipe e a reflexo dos atos das pessoas, integrando assim duas reas, Comunicao e Recursos Humanos, que na grande maioria dos projetos so crticas. Alm disso, percebe-se sob a viso de Severino (2009), que o gerenciamento de Recursos Humanos dentro do SCRUM, preza que as equipes sejam multidisciplinares, ou seja, necessita que todos tenham a conscincia e a liberdade para fazer um pouco de tudo.

5.4.Gerenciamento da Comunicao
Comunicao muito bem definida por Eischen (2002):
Como os socilogos sabem, comunicao intrinsecamente difcil, mediadas por cdigos que so sempre contextuais, normas, culturas e percepes. (...)

16

A construo de requisitos bsicos, por exemplo, envolve um processo de comunicao de conhecimento tcito, o que explica grande parte da dificuldade no desenvolvimento de software. Traduzir conhecimento de um contexto para outro, como traduzir qualquer lngua, no envolve apenas gramtica bsica e regras sintticas, mas tambm questes de significado e inteno que so contextuais e subjetivas. (EISCHEN 2002, apud TELES, 2005, p.60).

A partir da definio e do dimensionamento da comunicao num projeto, seja qual for a rea de desenvolvimento, do mesmo, sabe-se h diversas formas e canais para a execuo desta tarefa que no das mais simples, mas conforme Teles (2005), projetos XP procuram envolver ativamente seus usurios(representantes/clientes), tornando-os parte integrante da equipe de desenvolvimento, deixando presente muita das vezes no mesmo ambiente onde o projeto est sendo feito, possibilitando que o acesso aos especialistas seja mais rpido, direto e consistente. Dentro do XP h diversas outras prticas que otimizam o processo de comunicao dentro do projeto, dentre as principais prticas esto a Programao em Par e o Feedback. A primeira conforme explanado por Warden et al. (2003 apud URDANGARIN, R.G., 2008, p.31), o objetivo principal da programao em par disseminar o conhecimento, a experincia e as idias. Atravs de dois desenvolvedores trabalhando juntos em uma mesma atividade, em um mesmo computador, simultaneamente. J a segunda prtica citada anteriormente o feedback, que conforme Teles (2005), o mecanismo fundamental que permite que o cliente conduza o desenvolvimento diariamente e garanta que a equipe direcione as suas atenes para aquilo que ir gerar mais valor. Mas para que haja um bom feedback, o ideal que a uma boa comunicao interpessoal seja realizada, assim como explica Macdo et al.(2010):
A comunicao interpessoal face a face considerada a mais completa de todas, visto que propicia uma troca instantnea, feedback em caso de eventuais dvidas e vrias pistas que vo muito alm das palavras: gestos, expresses faciais, tom de voz etc. (MACDO et al., 2010, p.80)

Como uma prtica do PMBOK, o quesito gerenciamento de comunicao, composto por processos necessrios para assegurar que as informaes sejam geradas, coletadas distribudas, armazenadas, recuperadas e organizadas de maneira oportuna e apropriada. (PMI, 2008). O PMBOK (2008) apresenta os seguintes processos para o gerenciamento da comunicao:

17

Identificar as partes interessadas O processo de identificao de todas as pessoas ou organizaes que podem ser afetadas pelo projeto e de documentao das informaes relevantes relacionadas aos seus interesses, envolvimento e impacto;

Planejar as comunicaes O processo de determinao das necessidades de informao das partes interessadas no projeto e definio de uma abordagem de comunicao;

Distribuir informaes O processo de colocar as informaes necessrias disposio das partes interessadas no projeto, conforme planejado; Gerenciar as expectativas das partes interessadas O processo de comunicao e interao com as partes interessadas para atender s suas necessidades e solucionar as questes medida que ocorrem;

Reportar o desempenho O processo de coleta e distribuio de informaes sobre o desempenho, incluindo relatrios de andamento, medies do progresso e previses.

(PMI, 2008, p. 204). Ainda no PMBOK (2008), cabe a observao, que todos esses processo explanados anteriormente, interagem entre si, e com ou com processos de outras reas de conhecimento. Quando se trata de SCRUM, fica praticamente impossvel no falar de comunicao, que encontra as reunies como principal forma de contato entre os integrantes da equipe e os interessados no projeto. H o mais variado tipo de reunio, mas segundo Schwaber (2009) as principais so: Reunio de planejamento da verso para entrega, Reunio de planejamento da SPRINT, Reviso da SPRINT, Retrospectiva da SPRINT e Reunio diria. Ordenando por ocorrncias (necessidades), primeiramente vem Reunio de planejamento da verso para entrega:
O propsito do planejamento da verso para entrega o de estabelecer um plano e metas que o Time SCRUM e o resto da organizao possam entender e comunicar. O planejamento da verso para entrega responde s questes: Como podemos transformar a viso em um produto vencedor da melhor maneira possvel? Como podemos alcanar ou exceder a satisfao do cliente e o Retorno sobre Investimento (ROI) desejado? (SCHWABER, K., 2009, p. 9).

18

Em seguida, vem a Reunio de planejamento da SPRINT, que simplesmente define a iterao (grupo de tarefas) em questo. Acompanhando as ocorrncias (necessidades), vem Reviso da SPRINT, que verifica como foi o andamento de tudo que foi planejado na reunio de planejamento. J a Retrospectiva da SPRINT:
A finalidade da Retrospectiva inspecionar como correu a ltima Sprint em se tratando de pessoas, das relaes entre elas, dos processos e das ferramentas. A inspeo deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composio do time, preparativos para reunies, ferramentas, definio de pronto, mtodos de comunicao e processos para transformar itens do Backlog do Produto em alguma coisa pronta. No final da Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de melhoria factveis que ele implementar na prxima Sprint. Essas mudanas se tornam a adaptao para a inspeo emprica. (SCHWABER, K., 2009, p. 14).

Por fim a Reunio diria:

Cada time se encontra diariamente para uma reunio de 15 minutos chamada Reunio Diria. Essa reunio sempre feita no mesmo horrio e no mesmo local durante as Sprints. Durante a reunio, cada membro explica: O que ele realizou desde a ltima reunio diria; O que ele vai fazer antes da prxima reunio diria; e Quais obstculos esto em seu caminho.

(SCHWABER, K., 2009, p. 15).

Concluso

Conclumos que as metodologias geis SCRUM e XP muito aderem e pouco divergem em relao ao PMBOK. Nas reas de conhecimento do PMBOK como Custos, Qualidade e Risco na realidade tm por objetivo quantificar e qualificar os pontos a serem desenvolvidos pelo gerente de projeto. A proposta do desenvolvimento gil est diretamente ligada proposta de ganho na fase de execuo do projeto, integrando vrias reas de conhecimento atravs de um processo de comunicao conciso e eficaz envolvendo todos os interessados no projeto ao nvel de

19

recurso. Desta maneira, envolvendo o usurio, reduz-se o risco ligado dificuldade de entendimento por parte da contratao de um projeto de software, decorrente do alto seu nvel de abstrao. Diferente do PMBOK, as metodologias geis focam no planejamento iterativo, pois no esto focadas no quesito prazo (este passa ser uma conseqncia j que o nvel de retrabalho do projeto diminui), e sim na aderncia do usurio em relao ao escopo definido e qualidade esperada. Desenvolver softwares em que o usurio no conhece bem o escopo algo muito complexo. Para tal a mescla entre o PMBOK, SCRUM e o XP facilita muito o processo de gerenciamento do ciclo de vida do software por parte do gerente de projeto, j que ele tem um processo de desenvolvimento baseado na efetividade da comunicao entre os envolvidos, e por trs disso existindo o arcabouo dos processos do PMBOK, como o de aquisies e custos para medir os rudos que inviabilizariam o projeto, garantindo assim que as metodologias geis atuem de forma complementar ao PMBOK. Assegurando que de forma implcita ao projeto as demais reas de conhecimento (Custo, Qualidade, Riscos, Integrao e Aquisies) sejam aplicadas.

20

Referncias Bibliogrficas
Agile Manifest. Manifesto para Desenvolvimento gil de Software. [S.l.], 2001. Disponvel em: <http://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: 18 nov. 2010. CHAPIEWSKI, G. Como estamos indo com a adoo de SCRUM na Globo.com. [S.l.], 2008. Disponvel em: <http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-adocao-de scrum-na-globocom>. Acesso em: 13 nov. 2010. TELES, V. Extreme Programming, XP: metodologia desenvolvimento gil. [S.l.], 2008. Disponvel em: <http://www.improveit.com.br/xp>. Acesso em 28 out. 2010.
PACHECO, D. Scrum e a gesto de pessoas. [S.l.], 2009.

Disponvel

em:

<http://imasters.com.br/artigo/12620/agile/scrum_e_a_gestao_de_pessoas>. Acesso em 25 nov. 2010. PMI - PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento do Gerenciamento de Projetos (Guia PMBOK), 4. ed. 2008. 337 p. BECK, K. Programao extrema (XP) explicada: acolha as mudanas. 1. ed. Porto Alegre: Bookman, 2004. 182 p. SOMMERVILLE, I. Engenharia de Software. Xx. ed. So Paulo: Pearson, 2007. xx p. SOTILLE et al., Gerenciamento do escopo em projetos. 2. ed. Rio de Janeiro: Editora FGV, 2010. xx p. MACDO et al. Aspectos comportamentais de gesto de pessoas. 9. ed. Rio de Janeiro: Editora FGV, 2010. xx p. WARDEN, S. Extreme Programming Pocket Guide. 1 ed. Sebastopol: OReilly, 2003. 83p.
EISCHEN, K. Software development: an outsider's view. IEEE. Computer, v. 35, n. 5, 2002. p. 36-44.

21

ARAUJO [2], L. Estudo Comparativo da Compatibilidade entre as melhores prticas do PMI e SCRUM. 2009. xx f. Trabalho de Concluso de Curso (Graduao em xxxxxx), Faculdade de Informtica e Administrao Paulista, So Paulo, 2009. SEVERINO, L. O poder do PMBOK no gerenciamento de um projeto SCRUM. 2009. xx f. Trabalho de Concluso de Curso (Graduao em xxxxxxxxxxx), Universidade Estadual de Londrina, Londrina, 2009. SOARES, A. Processo gil de Desenvolvimento de Software para Equipes Separadas Remotamente que Utilizam Ferramentas de Software Livre como Suporte ao Desenvolvimento. 2009. xx f. Trabalho de Concluso de Curso (Graduao em Engenharia da Computao), Universidade Federal de Pernambuco, Recife, 2009. ARAJO [1], R. Anlise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva
gil. 2009. xx f. Estudo Bibliogrfico (Bacharelado em Sistemas de Informao), So Leopoldo, 2009.

TELES, V. Um Estudo de Caso da Adoo das Prticas e Valores do Extreme Programming. 2005. 179 f. Dissertao (Mestrado em Informtica) Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2005.
URDANGARIN, R. Uma Investigao sobre o Uso de Prticas Extreme Programming no Desenvolvimento Global de Software. 2008. 118 f. Dissertao (Mestrado em Cincia da Computao) Pontifca Universidade Catlica do Rio Grande do Sul, 2008

PIMENTEL, A. Uma Abordagem para o projeto de software orientado a objetos baseado na teoria de projeto axiomtico. 2007. 189 f. Tese (Doutorado em Cincias) - Universidade Tecnolgica Federal do Paran, Paran, 2007. FALBO, R. Engenharia de Software. 2005. 99 f. Notas de Aula (Disciplina de Engenharia de Software) Universidade Federal do Esprito Santo, Esprito Santo 2005. SCHWABER, K., GUIA DO SCRUM. 2009. (Traduo)

22

NETO, E.I., Scrumming: Ferramenta Educacional para Ensino de Prticas do SCRUM., 2008. LEONEL, L.S., et. al., Gesto da Produtividade: Extreme Programming, So Paulo - 2007. DECARLO, D. Extreme Project Management. San Francisco, California: Jossey-Bass, 2004.