Gerenciamento de Projeto Auxiliado Pelo Scrum

7/21/2019 Gerenciamento de Projeto Auxiliado Pelo Scrum

http://slidepdf.com/reader/full/gerenciamento-de-projeto-auxiliado-pelo-scrum 1/74

PÓS-GRADUAÇÃO LATO SENSU EM PRODUÇÃO E SISTEMAS

MARCOS DA SILVA GOMESWELLINGTON DA MATTA GOMES

GERENCIAMENTO DE PROJETO AUXILIADO PELO SCRUM:Flexibilizando o Gerenciamento Tradicional

Campos dos Goytacazes2009





Monografia apresentada ao InstitutoFederal Fluminense – Campus Centro,como requisito parcial para conclusão docurso de pós-graduação lato sensu emProdução e Sistemas.

Orientador: Prof. DSc. Sérgio MartinsVasconcellos. Doutor em Engenharia deProdução

Campos dos Goytacazes2009



Dados de Catalogação na Publicação (CIP)

G633g Gomes, Marcos da Silva.Gerenciamento de projeto auxiliado pelo Scrum:

flexibilizando o gerenciamento tradicional. / Marcos da SilvaGomes, Wellington da Matta Gomes – Campos dosGoytacazes, RJ : [s.n.], 2009.

72 f. : il.

Orientador: Sérgio Martins de Vasconcellos.Monografia (especialização). Instituto Federal de

Educação, Ciência e Tecnologia Fluminense. Campos dosGoytacazes, RJ, 2009.

Bibliografia: f. 65 - 67.

1. Administração de projetos. 2. Scrum (Programa decomputador). I. Gomes, Wellington da Matta. II.Vasconcellos, Sérgio Martins, orient. III. Título.

CDD – 658.404





Monografia apresentada ao InstitutoFederal Fluminense – Campus Centro,

como requisito parcial para conclusão docurso de pós-graduação lato sensu emProdução e Sistemas.

Aprovada em ____ de _______ de 2009

Banca Avaliadora:

............................................................................................Profº DSc. Sérgio Martins Vasconcellos (orientador)

Doutor em Engenharia de ProduçãoInstituto Federal Fluminense

............................................................................................Prof o MSc.Flávio Nassur Espinosa

Mestre em Engenharia de ProduçãoInstituto Federal Fluminense

............................................................................................Prof o MSc. Henrique Rego Monteiro da Hora

Mestre em Engenharia de ProduçãoInstituto Federal Fluminense



Dedico este trabalho ao meu grandeamor minha esposa, Jaqueline, que soubeentender minha ausência e que semprerespeitou minha escolha profissional.

Wellington



Dedico este trabalho aos meus filhosMateus e Filipe e principalmente a minhaamada esposa Cecília, que de forma sábiae terna, tem nos conduzidos a marestranqüilos.

Marcos



AGRADECIMENTO

Agradeço,

A Deus que conduziu-me todo tempo na busca do saber. Sem a fé

depositada nele e a certeza de sua companhia, nada seria, nada teria e nada faria...

Aos meus amigos para que junto com minha família me perdoem, por toda

minha ausência.

Ao companheiro Marco Antônio por sua compreensão e paciência no

transmitir o saber.

Ao Colega de Trabalho Carlos Alberto S. Alves, que não mediu esforços

trocando serviço, para possibilitar minha presença nas aulas.

Ao Doutor Sérgio Vasconcellos por sua ajuda e compreensão para

concretização dessa jornada.

A todos que direta ou indiretamente colaboraram para a conclusão desta

jornada. Meu carinho e respeito.



"Não existe nada mais difícil, de seexecutar, nem de sucesso mais duvidosoou mais perigoso, que dar início a umanova ordem das coisas. Pois o reformadortem como inimigos todos os que ganhamcom a ordem antiga e conta apenas comdefensores tímidos entre aqueles queganham com a nova ordem. Parte dessatimidez vem do medo dos adversários,

que têm a lei a seu favor; e parte vem daincredulidade da humanidade que nãodeposita muita fé em qualquer coisa nova,até que a experimente".

O Príncipe, MAQUIAVEL



RESUMO

Em prol da melhoria dos seus processos, as organizações estão buscando ferramentas que

contribuam para redução de custos e prazos, o aumento da antecipação da tendência domercado e maior satisfação de seus clientes com menor número de retrabalho e maiores

resultados em seus negócios. O Gerenciamento de Projetos está intimamente ligado aos

interesses das empresas. Porém, apresenta algumas lacunas que precisam ser solucionadas.

Com isso, este trabalho apresenta a Ágile Project Management (APM), ou Gerenciamento de

Projetos Ágil, que preenche algumas brechas deixadas pelo Gerenciamento de Projeto

Tradicional e os indicadores de desempenho relacionados ao prazo de entrega, qualidade e

satisfação desses projetos. Utilizando a metodologia Scrum conseguimos liberar o processo de

algumas barreiras dando uma avaliação correta do ambiente em constante mudança. Como umpoderoso framework essa metodologia dirá exatamente o que fazer. O Scrum não tem a

pretensão em liquidar todos os problemas mais facilitará sua identificação.

Palavras-chaves: Gerenciamento Ágil; Gerenciamento Tradicional; Scrum



ABSTRACT

For the sake of improving their processes, organizations are looking for tools that

help to reduce costs and time, the increase in anticipation of market trends and

increased customer satisfaction with fewer rework and greater results in their

businesses. Project management is closely linked to business interests. However, it

has some shortcomings that need to be addressed. Therefore, this paper presents

the Agile Project Management (APM), Project Management and Agile, which fills

some gaps left by the Project Management Traditional and performance indicators

related to the delivery, quality and satisfaction of these projects. Using the Scrummethodology can release the process of some barriers giving a correct assessment

of the changing environment. As a powerful framework methodology that tell you

exactly what to do. Scrum does not purport to settle all problems will facilitate their

identification.

Keywords: Agile Management; Traditional Management, Scrum



LISTA DE ILUSTRAÇÕES

Figura 1- Situação dos Projetos em relação das falhas e conclusões ....... ..............14

Figura 2 - Evolução do Escritório de Projetos(Fonte: Rogério S. Leitão) ............... ..27

Figura 3 - O Modelo Cascata atrasa a resolução de riscos ...................................... 37

Figura 4 - O Modelo Iterativo antecipa a resolução de riscos .................................. 38

Figura 5 - As entregas no Modelo Iterativo .............................................................. 38

Figura 6 - Ligações entre os grupos de processos do PMBOK ............................... 39

Figura 7 - Ligações entre grupos de processos segundo as metodologias ágeis ... 40Figura 8 - Áreas de Conhecimento do PMBOK(PMI,2004) mais afetadas em APM 41

Figura 9 - Ciclo de Vida SCRUM . ............................................................................. 55

Figura 10 - Macro estrutura do Scrum (Yoshima 2007, p. 12).................................. 56

Quadro 1-Influência da Estrutura Organizacional nos Projetos (Fonte: PMBOK – PMI

2004 p. 44) ............................................................................................................... 29

Quadro 2 - Características das equipes Ágil e Tradicional. ...................................... 54



LISTA DE SIGLAS

PMBOK ....................... Project Management Body of Knowledge (Guia do Conjunto

de Conhecimentos em Gerenciamento de Projetos)

PMI ..................................Project Management Institute (Instituto de Gerenciamento de

Projetos)

TI ................................. Tecnologia da Informação

UML ............................. Unified Modeling Language (Linguagem de Modelagem

Unificada)



SUMÁRIO

1 INTRODUÇÃO ....................................................................................... 13

1.1 PROBLEMATIZAÇÃO ............................................................................. 13

1.2 JUSTIFICATIVA DO TRABALHO............................................................ 16

1.3 OBJETIVO .............................................................................................. 16

1.4 METODOLOGIA APLICADA ................................................................... 17

1.4.1 Caracterização da pesquisa ............................................................................. 19

1.5 LEIAUTE DO TRABALHO ....................................................................... 19

2 GERENCIAMENTO DE PROJETOS ...................................................... 212.1 CULTURA NA ORGANIZAÇÃO .............................................................. 24

2.2 ESCRITÓRIO DE PROJETOS ................................................................ 26

2.2.1 O papel do EGP nas estruturas organizacionais ..................................... 28

2.2.2 O perfil do EGP no Brasil ........................................................................ 30

2.3 GERENCIAMENTO DE PROJETOS ÁGIL ............................................. 32

2.3.1 O manifesto Ágil ...................................................................................... 34

2.3.2 Princípios do gerenciamento de projetos ágil .......................................... 352.3.3 Desenvolvimento iterativo ....................................................................... 36

2.3.4 PMBOK (PMI, 2004) Versus Ágil............................................................. 39

2.3.5 Áreas de conhecimento do gerenciamento de projetos aplicáveis .......... 41

2.3.5.1 Gerenciamento dos Recursos Humano ..................................................42

2.3.5.2 Gerenciamento da Qualidade .................................................................43

2.3.5.3 Gerenciamento da Integração .................................................................43

2.3.5.4 Gerenciamento de Escopo e Tempo .......................................................433 DESENVOLVIMENTO DO ESTUDO ...................................................... 45

3.1 SCRUM ................................................................................................... 46

3.1.1 Definições ............................................................................................... 47

3.1.2 Conceitos ................................................................................................ 48

3.1.2.1 Sprint ...................................................................................................... 48

3.1.2.2 Product Backlog ......................................................................................49

3.1.2.3 Planing Meeting.......................................................................................50

3.1.2.4 Dailly Meeting ......................................................................................... 51

3.1.2.5 Review ....................................................................................................51



3.1.2.6 Retrospective ..........................................................................................51

3.2 PAPÉIS RESPONSABILIDADES DO SCRUM .......................................52

3.2.1 Product Owner (proprietário do produto) ................................................. 52

3.2.2 Scrum Master (gerente do projeto).......................................................... 52

3.2.3 Developers (equipe) ................................................................................ 52

3.3 CICLO DE VIDA SCRUM ........................................................................54

3.4 IMPLANTANDO SCRUM ........................................................................57

4 CONSIDERAÇÕES FINAIS .................................................................... 59

4.1 A VIABILIZAÇÃO DO ESCRITÓRIO DE PROJETO ÁGIL ...................... 60

4.2 PROPOSTA DE PESQUISAS FUTURAS ............................................... 62

4.3 O TRABALHO ......................................................................................... 635 REFERENCIAS BIBLIOGRÁFICAS ....................................................... 65

ANEXO A: Visão geral da Metodologia de Gestão de Projetos .............. 68



1. INTRODUÇÃO

A gestão de projeto é uma ferramenta muito útil quando se reporta à

concepção de produtos voltados para área tecnológica. A adoção das ferramentas

de gestão de projeto poderá definir a viabilidade de um trabalho de conclusão de

curso acadêmico aos diferentes segmentos até mesmo aos que não tem

obrigatoriedade de entender a tecnologia analisada.

Prado (2003, p. 38) afirma que as empresas brasileiras estão demonstrando

maior sensibilidade para a importância do gerenciamento de projetos para sua

sobrevivência e progresso. E ainda, Phillips (2003, p. 1), comenta sobre asdiferenças existentes nos projetos da área de tecnologia da informação (TI),

afirmando que o profissional experiente que for gerenciar projetos de TI observará

que trata-se de algo totalmente diferente em gerenciar qualquer outro projeto com o

qual já tenha trabalhado.

Para o autor Phllips o mundo da tecnologia da informação atua nas

necessidades de negócio que sempre mudam compatibilidade de hardware,

pequenas falhas no software, brechas na segurança e largura de banda da rede,posturas e políticas de administração.

Entre as afirmações de Prado e Phillips, pode-se entender que a gestão de

projetos para a área de TI é necessária, totalmente dinâmica, dependente de

ferramentas e metodologias que de mesma forma apresentem soluções dinâmicas e

rápidas.

Dentro deste contexto e que se insere este trabalho, as justificativas que

motivaram sua realização, demonstrando a importância atual do tema.

1.1. PROBLEMATIZAÇÃO

Apesar do evidente aumento da utilização do gerenciamento de projetos por

parte das empresas, ainda se observam (FORMAM, apud RAD & RAGHAVAN,

2000) altos índices de falhas em projetos. Um estudo realizado pelo Standish Group

-2005 relata que, dentre 8.380 projetos de Tecnologia de Informação (TI), 31,1%



continham falhas que impediam totalmente que os objetivos fossem atingidos, 52,7%

estavam em processo de recuperação de falhas ocorridas recentemente e,

possivelmente, seriam completados fora do prazo e atingindo apenas parcialmente

os objetivos e 16,2% foram completados no prazo, dentro do orçamento e de acordo

com as especificações.

Recuperando-

se das falhas

(52,7%)

Dentro da

espectativa

16 2%

Falhas total

(31,1%)

Figura 1 - Situação dos Projetos em relação das falhas e conclusões

Observando a imagem podemos entender que a gestão de projetos está em

três patamares dois totalmente indesejáveis e que somam 83, 8% e, apenas 16,2%

está dentro do esperado. Sendo mais da metade (52,7%), está dentro de um padrão

que pode ainda ter recuperação, mesmo ocorrendo anormalidades.

CRAWFORD (2000), justifica esta aparente ineficiência no gerenciamento de

projetos dizendo que a maioria dos problemas relativos aos projetos ocorrem devido

à falta de processos adequados e padronizados de gerenciamento, ou seja, a maior

causa das falhas nos projetos não são as especificidades do que efetivamente deu

errado, mas sim a falta de procedimentos, metodologias e padrões flexíveis e ágeis.

As equipes de TI das organizações sofrem uma pressão crescente para

reduzir orçamentos, melhorar a qualidade de seus produtos e realizar entregas mais

rapidamente. Essas exigências se deparam com as atuais práticas de TI:

complicados requisitos de gestão, nebulosos e fracos na gestão de projetos,

arquiteturas complexas, lentas e ciclos de testes demorados. Em resposta a estas

pressões, as equipes de TI estão cada vez mais olhando para as práticas que torne

os processos práticos e mais gerenciáveis com soluções rápidas e esperadas. Isto



porque elas destilam a essência de TI em uma coleção eficiente de técnicas e

oferecem uma forma de trabalhar intuitivamente atraente.

Mudar a cultura de uma empresa não é algo simples, ao contrário, pode

requerer muito tempo, uma vez que tais práticas contradizem muitos

comportamentos.

Na abordagem tradicional do gerenciamento de projetos, existem longas e

distintas fases de atividade, incluindo análise, programação, testes e implantação.

Estas fases são ligadas entre si por artefatos como casos de uso, codificação, ou

casos de teste.

O desenvolvimento ágil de software é realmente uma mudança nos métodos

de trabalho e uma mudança no estilo de gestão, e este estilo está voltado para aspessoas e a base de experiência existente, mais do que a própria engenharia,

devendo constituir-se em uma verdadeira tendência, uma mudança nos métodos de

trabalho e mudança paradigmática na maneira como o software é produzido

(ANDERSON, 2003).

O caminho da adoção das práticas ágeis está bem encaminhado, mas mal

iluminado. Os processos de trabalho ágeis devem ser suficientemente específicos

para serem compreensíveis, definidos o suficiente para serem repetitivos, maleáveiso suficiente para mudanças com experiência, e suficientemente flexíveis para

acomodar uma ampla gama de operações reais. As práticas ágeis devem ser

suficientemente amplas para suportar diversas situações ou trarão poucos

benefícios. As pessoas envolvidas com estas práticas devem dominá-las

rapidamente ou a alteração do processo será entendida como resultado de valor

limitado.

Quando estão em processo de transição para as práticas ágeis, os gestoresdevem estar sintonizados com vários processos alheios. Ao efetuar a mudança, as

práticas estão sendo suficientemente empreendidas, ou é um caso de tentar fazer

demasiadamente mais rápido? Fazer as pessoas abordarem a mudança com

ceticismo saudável, ou elas estão passivamente agressivas em direção a mudança?

A transparência na execução expõe problemas ou faz as equipes jogarem com os

resultados para esconder desempenho? O reconhecimento por estes pequenos

detalhes separam o sucesso da adoção de abordagens ágeis de uma falha na

iniciativa por mudança.



O desafio para os gerentes iniciantes nas práticas ágeis é converter as

forças que resistem à mudança naquelas que permitam mudar.

1.2. JUSTIFICATIVA DO TRABALHO

O Escritório de Gerenciamento de Projetos surge, então, como um elemento

organizacional responsável pela minimização dos problemas de falta de processos

bem definidos e padronizados, pela divulgação das melhores práticas de

gerenciamento de projetos para toda a organização e pelo fornecimento da infra-

estrutura necessária para um gerenciamento corporativo de projetos, possibilitandoa diminuição dos índices de falhas e garantindo que os projetos mais importantes

para a organização sejam os mais priorizados.

Agile Project Management (APM - Gerenciamento de Projeto Ágil) está

voltado para a rapidez de adequação às mudanças e as situações voláteis do

ambiente, com um grau de informalidade em seu processo que é merecedor de

várias críticas.

Desta forma, torna-se bastante relevante um aprofundamento em estudos decaso que permitam averiguar a aplicabilidade dessa nova abordagem de gestão de

projetos.

O gerenciamento de projeto com práticas ágeis, ainda é pouco divulgado no

Brasil, e pior, pouco mencionado no meio literário e conseqüentemente nos “bancos

acadêmicos”. Esta falta de divulgação em nossas línguas pátria, e as respostas que

esta ferramenta traz, também é a intenção deste trabalho de conclusão de curso.

1.3. OBJETIVO

Por meio de pesquisa bibliográfica elaborar uma análise conjunta dos

princípios da Agile Project Management em projetos utilizando a ferramenta SCRUM

e incorporando-a nas ações do escritório de gerenciamento de projetos. E ainda,

gerar um documento acadêmico para viabilização do emprego da ferramenta ágil.



1.4. METODOLOGIA APLICADA

Segundo Minayo (1993, p. 23), a pesquisa é uma atividade básica das

ciências que, através da investigação e da descoberta da realidade, constitui-se de

um processo inerentemente inacabado e permanente. O autor diz que “é uma

atividade de aproximação sucessiva da realidade que nunca se esgota, fazendo uma

combinação particular entre teoria e dados”. Desta forma, não se deve atribuirverdade absoluta ao resultado de uma pesquisa, uma vez que descobertas estão

sempre sendo renovadas. As análises decorrentes de uma pesquisa apresentam

várias implicações, cabendo ao pesquisador evidenciar o que está enquadrado no

conhecimento empírico e explicar suas descobertas através do conhecimento

científico. Desta forma, normalmente uma pesquisa inicia-se com um problema ou

indagação e torna-se necessária a utilização de procedimentos científicos.

Em seu trabalho, Kerlinger (1980, p. 33) contraria parcialmente este enfoque.Referente a esta questão, diz que nem todo problema é passível de tratamento

científico e apresenta, dentre outros exemplos de sua afirmação, o tema “como

aumentar a produtividade no trabalho?”. O autor diz ainda que esses problemas são

considerados como “problemas de engenharia", ou seja, referem-se a como fazer

algo de maneira eficiente e, devido à forma de proposição dos mesmos, tornam

inviável a investigação segundo os métodos próprios da ciência. Outro ponto

enfatizado pelo autor refere-se a problemas de valor. Questões que avaliam se algoé bom ou mau, desejável ou indesejável, certo ou errado, melhor ou pior, se deve ou

não ser feito também não podem ser considerados como científicos. Sua justificativa

é que "a pesquisa científica não pode dar respostas a questões de engenharia e de

valor porque sua correção ou incorreção não é passível de verificação empírica"

(Kerlinger 1980, p. 33).

Há inúmeras formas de classificação de pesquisas apontadas por vários

autores quando se busca identificar uma associação entre problema de pesquisa e

tipo de pesquisa, bem como identificar os tipos de pesquisa que se enquadram



como não-científicas. Esta seção busca posicionar, dentro das inúmeras formas de

classificação, aquelas que se aplicam ao presente trabalho.

Método, conforme diz Ferreira (2002), “é o caminho pelo qual se atinge um

objetivo” ou ainda ”o programa que regula previamente uma série de operações que

se deve realizar, apontando erros evitáveis, em vista de um resultado determinado”.

Método, segundo Lakatos e Marconi (LAKATOS & MARCONI, 1983, p. 42-43), "é o

conjunto de atividades sistemáticas e racionais que, com maior segurança e

economia, permite alcançar o objetivo – conhecimentos válidos e verdadeiros –

traçando o caminho a ser seguido, detectando erros e auxiliando as decisões do

cientista". Em um sentido mais amplo, é a ordem que se deve impor aos diversos

processos necessários para atingir um fim ou resultado desejado.O método científico é um instrumento para descobrir relações, verdades e leis

referentes aos diversos objetos de investigação, ou seja, é um conjunto de

procedimentos sistemáticos para obter o conhecimento adequado do problema que

se propõe resolver. O desenvolvimento do método científico faz-se por processos ou

técnicas de observação, hipótese, demonstração, indução da lei ou teoria. Além

disso, e simultaneamente aos processos referidos, o pesquisador sempre estará

usando as técnicas de análise, síntese e dedução (ANDRADE, 1996).Este trabalho aborda temas bastante novos, cujos conceitos são

considerados ainda em evolução. Sendo conceitos sem base sedimentada tanto

conceitual quanto prática, a consideração de um método que utilize a investigação

aplicada, puderam tornar o processo mais adequado a proposições mais seguras.

Dado um problema específico, ou seja, como as empresas podem gerenciar seus

projetos de maneira eficiente sem temer a complexidade imposta pelo mercado.

Utilizando a observação ativa, ou seja, o pesquisador não como um agente passivo,mas participante no processo, as experiências vividas através de casos práticos

foram os instrumentos que levaram à definição de necessidades a serem supridas.

Assim, este trabalho baseia-se em objetivos, não em hipóteses, e tem

aplicação do método de pesquisa indutivo, no qual a observação de fatos

particulares leva a conclusões gerais. Através do método indutivo, procura-se

observar os fenômenos e descobrir a relação entre eles para a generalização destas

relações. Em suma, parte-se do estudo de caso para chegar às leis gerais

(ANDRADE, 1996). Segundo Ferreira (2002), a indução é o “raciocínio cujas

premissas têm caráter menos geral que a conclusão” ou, ainda, “o raciocínio pelo



qual se estabelece uma proposição universal a partir do exame de alguns dos

objetos de uma classe”. Pode-se considerar que a indução é uma generalização da

experiência.

1.4.1. Caracterização da Pesquisa

Salomon (1974, p. 229) diz que uma das regras para a definição do tema de

um trabalho científico é “a descoberta de um problema relevante que mereça ser

investigado cientificamente e tenha condições de ser formulado e delimitado

tecnicamente em função da pesquisa". Esta introdução do trabalho apresenta a

visão sobre a importância do tema e sua relevância.Sob o ponto de vista de sua natureza, este trabalho pode ser considerado

como uma pesquisa aplicada, uma vez que objetiva gerar conhecimentos para

aplicação prática dirigida à solução de problemas específicos. Do ponto de vista da

forma de abordagem do problema, e apesar de ter sido definido anteriormente que o

método de pesquisa indutivo foi utilizado, ela pode ser enquadrada como uma

pesquisa qualitativa. Considera que há uma relação dinâmica entre o mundo real e

o objeto de pesquisa, que não pode ser traduzida em números. Como ainterpretação dos fenômenos e a atribuição de significados são básicas no processo

de pesquisa qualitativa, ela não requer o uso de métodos e técnicas estatísticas.

Neste caso, o processo e seu significado são os focos principais desta abordagem.

Do ponto de vista de seus objetivos pode ser classificada como pesquisa

exploratória, pois visa proporcionar maior familiaridade com o problema com vistas

a torná-lo explícito. As exploratórias são aquelas que habitualmente realizam os

pesquisadores preocupados com a atuação prática. São também as mais solicitadaspor organizações como instituições educacionais, empresas comerciais, etc. No

caso deste trabalho, estão envolvidos levantamento bibliográfico e análise de

exemplos que levem à compreensão da melhor forma para a solução dos problemas

encontrados.

1.5. LEIAUTE DO TRABALHO



A introdução teve por objetivo apresentar ao leitor os objetivos desta

pesquisa. A seguir, no próximo capítulo, é apresentado o estado da arte, enfatizando

a literatura voltada para proposta de gerenciamento de projeto, de forma literária,

pelo foco de emprego das ferramentas e o escritório de projeto. No terceiro capítulo

o assunto abordado é a ferramenta SCRUM , definindo conceitos, processos e os

agentes que orbitam esta ferramenta. No último capítulo, encontram-se as

considerações e propostas de continuidade de pesquisa e estudos.

Formulando um facilitador, informações adicionais encontram-se em formato

de anexo deste trabalho. As informações objetivam um esclarecimento das

tecnologias abordadas de forma superficial. Não sendo pretensão resolver a partir

dos anexos, dúvidas para aqueles que possuem pouco ou nenhum conhecimentosobre o assunto. Apenas, objetiva-se realizar apresentação das ferramentas sem

aprofundamento.



2. GERENCIAMENTO DE PROJETOS

O objetivo deste capítulo é apresentar de forma consistente o gerenciamento

de projetos, ressaltando o pensamento de alguns autores reconhecidos, bem como

os principais conceitos relacionados ao gerenciamento de projetos ágil de forma a

fundamentar à pesquisa aqui apresentada.

Nas últimas décadas do século XIX, o mundo dos negócios já se mostrava

complexo o suficiente para exigir alguma disciplina útil para seus processos. As

primeiras iniciativas surgiram dentro de governos e empresas bem organizados e

tiveram grande influência dos assuntos abordados pela teoria da AdministraçãoGeral. No início do século XX, Frederick Taylor e Henry Gannt proveram importantes

conceitos para o mundo dos negócios, já mais exigente, contribuindo para a ciência

de gerenciar projetos (Corrêa 2007, p.30).

Já em meados da década de 60, muitas metodologias, técnicas e

ferramentas passaram a ter reconhecimento dentre os assuntos até então

estudados, devido principalmente a crescente complexidade dos projetos e

exigências do mercado. Começava-se então a normalizar e aglomerarconhecimentos importantes para o alcance de eficácia e qualidade nos projetos,

independente de sua natureza, o que resultou na criação da disciplina Gerência de

Projetos. Neste estágio inicial, sua aplicabilidade era visível na indústria bélica e

aeroespacial norte-americana, seguida pela engenharia, principalmente à civil.

Nesse período cria-se, então, o PMI1. Com a árdua tarefa de regulação e

distribuição de todo conhecimento até então estudado para esta disciplina e vem

organizando-o durante todos esses anos através do Project Management Body ofKnowledge (PMBOK - Guia do Conjunto de Conhecimentos em Gerenciamento de

Projetos), um guia padronizado para a orientação em práticas do gerenciamento de

projetos.

Valeriano (2001, p. xv) na apresentação de seu livro observa a mudança no

ambiente, entrelaçando os pensamentos de Heráclito2 (500 a.C.): “nada é

permanente, exceto a mudança” e Bill Gates (A empresa na velocidade do

1 Project Management Institute. www.pmi.org. 2 Pensador da escola Jônica (500 a.C.), da estrutura contraditória e dinâmica em constante modificação.



pensamento, 1999): “Os negócios vão mudar mais nos próximos dez anos do que

mudaram nos últimos cinqüenta”.

Nos últimos anos, o mundo tem enfrentado um incrível dinamismo em suas

relações intra e inter empresariais. As empresas passam, agora, a serem

reconhecidas por sua flexibilidade, capacidade de atender a seus clientes internos e

externos.

A competição entre as empresas exigiu que o Brasil também aprimora-se na

arte do gerenciamento de projetos. Prado (2003, p. 38) faz a seguinte afirmação:

A partir de 1997, as empresas brasileiras estão demonstrando maiorsensibilidade para a importância do gerenciamento de projetos parasua sobrevivência e progresso. Está havendo um movimento intensonas organizações para utilizarem melhor estas técnicas e estratégias.Treinamentos e programas de certificação, tanto de profissionaiscomo de organizadores, estão na ordem do dia. Diversasrepresentações (chapters) do PMI foram criadas e, ao final de 2002havia cerca de 1.200 associados no Brasil. Está crescendo aconsciência de que, para competir no mundo globalizado, não é maispossível cuidar apenas da produção e deixar que importantesprojetos sejam tocados de formas superadas.

Nos países de primeiro mundo, a estratégia das organizações aponta no sentido

da inovação de produtos e de processos e permanentes lançamento de novos produtos. O

Brasil não caminha na mesma velocidade, apesar de honrosas exceções (exemplo

siderurgia). Esta é uma área nobre e fundamental para a verdadeira soberania do País.

A forma planejada, o nível de detalhamento e a disciplina aplicada aos seus

processos permitem a medição e o controle de todas as suas etapas, permitindo que

os membros da equipe conheçam claramente os seus papéis e que a evolução doprojeto venha a ser demonstrada pelos artefatos gerados em cada uma destas

fases.

A característica de unicidade dos projetos lhes confere um determinado grau

de incerteza e por isso geralmente eles são divididos em fases para facilitar seu

gerenciamento. O conjunto de fases de um projeto é conhecido como ciclo de vida

do projeto. Basicamente, o ciclo de vida do projeto serve para definir seu início e seu

fim e ainda para ligar o projeto aos processos operacionais contínuos daorganização.



Cada uma das fases de um projeto normalmente inclui um ou mais

resultados definidos para estabelecer um controle gerencial adequado, e

comumente todas têm nomes relacionadas aos seus objetivos, tais como:

levantamento de necessidades, especificação de requisitos, implementação,

documentação, entre outras. Uma nova fase normalmente é iniciada depois da

aprovação dos resultados da fase anterior. No entanto, se os riscos forem

considerados aceitáveis, a nova fase pode ter seu início antecipado, e isto é

usualmente chamado de fast-tracking 3.

Por estar baseado em processo, o gerenciamento depende muito do apoio

da alta gerência, da comunicação e da estrutura organizacional, tornando-se estes

os requisitos que garantirão o sucesso do empreendimento.BOEHM & TUNER (2003), em seu artigo Observations on Balancing

Discipline and Agility (Observações sobre balanceamento de disciplina e agilidade),

diz que, a força do método tradicional de gerenciamento de projetos está na base

histórica criada pela repetição e comparação decorrentes da padronização

estabelecida pelo processo e, este método é conduzido pela identificação das

variações do ambiente e que estas podem ser eliminadas pelas medições e

refinamentos contínuos do processo. A partir das informações históricas e darepetição obtém-se a melhoria da capacidade do processo através da padronização,

medição e controle do projeto.

Alguns dos conceitos mais importantes deste método tradicional de

gerenciar projetos estão relacionados com a utilização e aplicação do processo

estabelecido e escolhido pela organização. O primeiro conceito define quanto a

contribuição do processo definido é importante para a obtenção dos resultados

esperados – capacidade do processo. O segundo está voltado para o grau depreocupação da empresa como um todo na aplicação destes processos –

maturidade da organização. O processo deve, ainda, ser monitorado e as melhorias

incorporadas, a fim de manter estes processos atualizados em relação às

características do ambiente de realização destes projetos – melhoria dos processos.

Contudo, o método tradicional apresenta problemas para aqueles projetos

onde devam existir situações críticas que envolvam prazos restritos e com mudança

de requisitos, não conseguindo responder com facilidade e rapidez às mudanças

3 fast-tracking – T ermo utilizado na literatura de Gerência de Projetos, em referência ao paralelismo na realizaçãode qualquer atividade e desta forma obtendo a compressão do cronograma.



impostas pelos clientes, sejam pessoas organizações ou imposições legais o que

exige uma atuação mais forte e centralizada por parte do gerente de projetos, vindo

este a ser o principal responsável pelo sucesso do projeto. Cada membro da equipe

tem a definição clara do seu papel e de suas atividades, limitando a influência e uma

maior colaboração durante a execução do projeto.

O cliente externo tem sua participação concentrada nas fases iniciais do

projeto quando ocorre o levantamento de requisitos, vendo sua participação diminuir

na medida em que o projeto evolui, passando então a realizar apenas as validações

das entregas geradas pelo projeto.

A fase de planejamento é extensa e detalhada. Nela que é definido toda a

etapa do projeto. Essa fase é utilizada para medir o progresso durante a fase deexecução do projeto e está sujeito às alterações ocorridas com a evolução do

trabalho. A comunicação a que é submetida a equipe do projeto está baseada na

documentação gerada ao longo das etapas do processo.

2.1. CULTURA NA ORGANIZAÇÃO

O PMBOK (2004, p. 27), afirma que a maior parte das organizações

desenvolve sua própria cultura. Ela é refletida em seus valores, normas, crenças e

expectativas, em suas políticas e procedimentos, em sua visão das relações de

autoridade e em diversos outros fatores.

Cada organização tem uma visão e uma forma de agir convencionada entre

os indivíduos que a compõem. A cultura organizacional é influenciada diretamentepelos indivíduos, mas, por outro lado, a própria organização influi na forma que cada

indivíduo atua no seu cotidiano. A cultura organizacional perpassa toda a

organização, sendo sua essência a relação entre as pessoas, tanto no ambiente

interno como no ambiente externo à organização. Segundo Chiavenato (2004, p. 24)

o termo cultura organizacional, apresenta uma infinidade de definições e tem suas

bases na antropologia e na sociologia, que foram depois estendidas para outras

áreas de interesse, como a psicologia e a administração.

É inegável a influência da cultura organizacional na gerência de projetos. No

entanto, mais ainda, deve ser considerada sua influência em projetos que visam



transformar o foco da organização para os clientes em detrimento da abordagem

tradicional de produtos e serviços. Neste sentido, um desafio ao qual este trabalho

monográfico propõe-se, é a concepção de que também a cultura organizacional

pode ser afetada pela introdução de novos conceitos como o de projetos ágeis. Os

resultados a serem alcançados por um ou mais projetos podem não ser um produto

ou serviço, e sim um conjunto de iniciativas para a criação de uma nova consciência

que pode alterar de fato a cultura organizacional relativa ao papel do cliente para a

sobrevivência das organizações.

Toda mudança organizacional pode vir a ameaçar grupos dentro das

organizações. Os motivos da necessidade de transformação passam a ser

questionado pelas empresas, e pelas pessoas, a partir do momento em que tenhamexistido mudanças difíceis e não muito bem sucedidas, achando que elas trarão

conseqüências negativas e sem agregar valores, sendo esta uma das principais

causas de resistência.

Toda mudança tende a ser dificultada na medida em que existirem culturas

centradas internamente, processos burocráticos, pouca confiança, falta de trabalho

em equipe, falta de liderança e o medo que o ser humano tem do desconhecido.

Segundo KOTTER (2001, p. 52), o sucesso está na neutralização de barreiras ondenão se pode negligenciar as atividades preparatórias, sob pena de não se

estabelecer uma base sólida para continuar o processo e, sem passar por todas as

etapas, nunca se atingirá a linha de chegada, ou seja, será impossível implementar

a mudança.

A cultura deve ser compreendida como um processo contínuo, pró-ativo da

construção da realidade e que dá vida ao fenômeno da cultura em sua totalidade.

Quando compreendida desta forma, a cultura pode não mais ser vista como umasimples variável que as sociedades ou as organizações possuem. Em lugar disto,

ela deve ser compreendida como um fenômeno ativo, vivo, através do qual as

pessoas criam e recriam os mundos dentro dos quais vivem.



2.2. ESCRITÓRIO DE PROJETOS

O conceito de Escritório de Gerenciamento de Projetos encontra-se bem

definido desde meados dos anos 60, nos grandes projetos militares, aeroespaciais e

da construção civil. Mesma época em que surge às metodologias para gerar os

projetos, conforme mencionado no início do capítulo. Pode-se denominar esses

escritórios como Escritório de Controle de Projetos; pois, os especialistas em

projetos da época possuíam apenas a função de controle e de ações corretivas, ou

seja, o foco era a detecção e correção de problemas.

No final da década de 70, até meados da década de 80, com o surgimentodos primeiros softwares de gestão “amigáveis”, o escritório mudou para expandir sua

cobertura inicial para outros projetos de áreas diferentes, porém, ainda isolados.

Para isso, membros das áreas funcionais, não especialistas em projetos, foram

alocados nos escritórios que assumiram a função de suporte aos projetos.

No final da década de 80 e meados da década de 90, as ferramentas de

gestão (e todas as demais ferramentas computacionais) sofreram uma verdadeira

revolução, facilitando o controle e suporte dos escritórios projetos. Com isso,gradativamente, o foco de atuação dos escritórios foi mudando de projetos

relativamente simples e isolados para um ambiente de multiprojetos e projetos

complexos, de funções de controle e suporte para um gerenciamento global e

alinhado com as estratégias organizacionais.

O conhecimento individual deverá ser convertido em conhecimento

organizacional. Os modelos tradicionais não deverão atender mais às necessidades

das organizações. As metodologias deverão ser facilmente adaptadas aos conceitosde flexibilidade e competição global. Desse modo, abre-se uma lacuna,

gradativamente crescente, para incorporação das metodologias ágeis que, deverão

firmar-se como alternativas e tenderem a se concretizar na medida em que estas

mesmas empresas decidam compartilhar seus valores e estimulem a interação entre

seus membros, um dos princípios destas metodologias. Tornando-se necessário,

portanto, a adequação e evolução do escritório de projetos às respectivas

metodologias.



Figura 2 – Evolução do Escritório de Projetos

Fonte: Rogério S. Leitão

Dentre as diversas estruturas de gerenciamento de Projetos existentes nos

dias de hoje, provavelmente o PMO (Project Management Office – Escritório de

Gerenciamento de Projeto) é a de maior sucesso e a mais estudadas pelas

empresas, podendo variar de acordo com o nível de maturidade da organização. A

maneira como estes Escritórios de Projetos são estruturados em uma organização

normalmente varia de uma organização para outra. No entanto, dependendo da

forma como estes escritórios são implantados nas empresas, poderão ainda

proporcionar suporte à metodologia e coaching 4 aos próprios gerentes de projeto.

Entre as funções dos escritórios de projeto, existem três principais áreas:

desenvolvimento, suporte e controle.

As funções de desenvolvimento envolvem o recrutamento, o treinamento e o

desenvolvimento dos gerentes de projeto. As funções de suporte são aquelas que

ajudam os gerentes de projeto a fazerem seu trabalho de uma maneira melhor

através do oferecimento de assistência e clareza com os processos do

gerenciamento de projetos. As funções de controle são aquelas da gerência

funcional e incluem: a avaliação de gerentes de projeto, a alocação de gerentes de

4 Coaching – O termo foi criada recentemente na área da gestão / liderança e representa as atuações do lídervoltadas para o ajudar os seus subordinados a trilharem o seu próprio caminho de autodesenvolvimento.

Especialistas em controlede projetos

reas funcionais participamdo gerenciamento de projetos

Processos de gerenciamentode projetos

Especialistas Primeiros softwares Software de gerenciamento

Escritório deControle de Projetos

Escritório deSuporte a Projetos

Escritório deGerenciamento de

Projetos

Foco em controle/reativo Foco estratégico/pró ativo

1960 1970 1980 1990 2000

Grandes ProjetosMilitares

AeroespaciaisConstrução Civil

Projetos dediferentes áreas e

isolados

Multi projetosIntegração Projetos

Complexos



projeto a projetos, a garantia de que as entregas dos projetos são produzidas e se

apresentam com uma qualidade adequada e, o estabelecimento de padrões. As

organizações, grandes, médias e pequenas, estão percebendo os benefícios de um

controle consistente sobre seus projetos. Porém, deve-se tomar cuidado para não

transformamos o PMO de uma empresa em um departamento puramente

burocrático.

O PMO não deve se transformar em um mero e degradante acumulador e

distribuidor de papéis. Existem muitos aspectos que deveriam ser analisados depois

que a decisão de implementação do PMO foi tomada. Alguns destes aspectos são: o

envolvimento da alta gerência, dos gerentes funcionais e dos gerentes de projeto da

organização, o compromisso da organização com a metodologia de gerenciamentode projetos e os benefícios que a nova estrutura irá trazer à organização.

O PMO consiste em uma estrutura voltada para a aplicação dos conceitos

de gerenciamento de projetos dentro de uma organização, podendo assumir

diferentes funções junto à mesma: desde um simples setor para o auxílio no controle

de projetos, até um departamento da empresa por onde passam todos os projetos

gerenciados pela organização.

2.2.1. O papel do EGP nas estruturas organizacionais

A implantação de um Escritório de Gerenciamento de Projeto (EGP) pode

trazer muitos benefícios para a organização. Enquanto os modelos de Escritório

variam de organização para organização, os benefícios são comuns dentro de todas

as várias formas encontradas. Alguns dos benefícios podem ser observados em umperíodo curto de tempo outros somente serão observados no longo prazo.

Segundo o PMBOK (2004, p. 43), mesmo quando o projeto é externo ( joint

ventures5, parcerias), ele ainda será influenciado pela organização ou organizações

que o iniciaram. A maturidade da organização em relação ao seu sistema de

gerenciamento de projetos, sua cultura, seu estilo, sua estrutura organizacional e

seu escritório de projetos também pode influenciar o projeto.

5 Join t venture ou empreendimento conjunto é uma associação de empresas, que pode ser definitiva ou não,comfins lucrativos, para explorar determinado(s) negócio(s), sem que nenhuma delas perca sua personalidade

jurídica.

http://pt.wikipedia.org/wiki/Empresa



http://pt.wikipedia.org/wiki/Lucro


http://pt.wikipedia.org/wiki/Personalidade_jur%C3%ADdica









Assim como todo e qualquer projeto, a implantação do EGP também é um

projeto e certamente um dos passos mais importantes é definir seus objetivos e a

razão que levaram a organização a implantá-lo. É preciso também que os

stakeholders6 estejam cientes sobre os papéis e responsabilidades atribuídos ao

EGP, que tipos de serviços estarão sendo prestados, a quem ele estará

subordinado, sua abrangência e, principalmente, quem é seu patrocinador.

A importância do EGP nas estruturas organizacionais reside no fato de que

existem várias razões de insucesso na sua implantação e que uma delas está

diretamente associada à escolha incorreta de onde ele estará posicionado na

estrutura organizacional. Algumas vezes o EGP é criado por áreas que geralmente

estão ligadas a projetos voltados para atender capacidades internas da empresa,usando-o como instrumento de defesa contra a pressão de outros grupos que os

culpam sistematicamente pelos atrasos e a falta de qualidade prometida.

O PMBOK (2004, p. 44) afirma, ainda, que “a estrutura da organização

executora geralmente limita a disponibilidade de recursos em um espectro de uma

estrutura funcional a uma estrutura por projeto, com diversas estruturas matriciais

intermediárias”. O Quadro 1, a seguir apresenta características importantes que

estão relacionadas a projetos nos principais tipos de estruturas organizacionais,além de mostrar que um pode existir em qualquer uma das estruturas

organizacionais, inclusive nas que apresentam uma organização funcional, sendo

que a probabilidade de ocorrência aumenta na direção das colunas mais à direita do

quadro.

Quadro 1 – Influência da Estrutura Organizacional nos ProjetosFonte: PMBOK – PMI 2004 p. 44

6 Stakeholder (em português, parte interessada ou interveniente), é um termo usado em administração que refere-se a qualquer pessoa ou entidade que afeta ou é afetada pelas atividades de uma empresa.

http://pt.wikipedia.org/wiki/Administra%C3%A7%C3%A3o






A falta de padronização que possa reportar o desempenho dos projetos da

organização faz com que os gerentes de projetos estejam sobrecarregados e sem

tempo para análise de dados e tomada de decisão, as lições aprendidas de outros

projetos não são registradas / documentadas, reconhece que a gerência de projetos

como competência crítica para o seu sucesso. Assim, o EGP assume um papel

importante nas Estruturas Organizacionais, podendo existir em qualquer uma das

estruturas organizacionais, inclusive nas que apresentam uma organização

funcional.

Os membros da equipe do projeto se reportarão diretamente ao gerente de

projetos ou ao EGP. O gerente de projetos se reporta diretamente ao EGP, neste

caso dizemos reportar diretamente a alta organização da empresa, além daflexibilidade do gerenciamento centralizado oferecer ao gerente de projetos maior

oportunidade de promoção dentro da organização.

2.2.2. O perfil do EGP no Brasil

O EGP no Brasil surgiu em 1999 com a demanda por uma metodologiapadronizada de gerenciamento de projetos. Cada unidade de negócio ou até

mesmo, cada gerente de projeto tinha sua própria metodologia e o esforço para a

manutenção deste grande número de metodologias era muito grande. Fazendo-se

assim a necessidade da unificação. Essa surgiu com a criação de uma metodologia

abrangente. Isso levou as empresas a perceberem que o desenvolvimento de

competência em gerenciamento de projetos era um fator diferencial. Assim, o EGP

surgiu na empresa como uma forma de implementar uma metodologia única deprojetos e de criar e difundir suas competências.

As empresas multinacionais de grande porte que possuem atuação global

são as mais atualizadas em termos de Escritório de Gerenciamento de Projeto

instalado. Apesar de sermos levados a pensar que as empresas deveriam sofrer

modificações a ponto de torná-las projetizadas7, ainda se observa uma

7 Na estrutura projetizada não existem departamentos: a empresa é totalmente dividida pelos projetos que estãoocorrendo e toda a autoridade é concentrada nos gerentes destes projetos.



predominância de empresas funcionais8. No entanto, as empresas que possuem um

Escritório de Gerenciamento de Projetos instalado são, em sua maioria, projetizadas

ou matriciais9. Ou seja, quanto mais a empresa é voltada para projetos, mais é

sentida a necessidade de uma entidade responsável pela qualidade de seu portifólio.

Quando falamos de maturidade, os Escritórios de Gerenciamento de Projetos

encontram-se implementados nas empresas situadas nos níveis médio e alto.

O que mais se espera de um Escritório de Gerenciamento de Projeto é o

alinhamento com o que há de melhor no mercado.

Quanto á estrutura, a grande maioria das empresas aposta em uma

estrutura interna para ser a responsável pela condução do Escritório de

Gerenciamento de Projeto. Nestes casos, os tempos de implementação poderãovariar muito, de acordo com a resistência cultural e a falta de conhecimento dos

conceitos existentes em um Escritório de Gerenciamento de Projeto, e a

comunicação passa a ser fator preponderante para uma implementação vitoriosa.

Não basta, também, que os patrocinadores sejam a alta administração. É preciso

que os executivos da organização tenham um grande envolvimento ao longo de todo

o processo de implantação.

Fato interessante é que as consultorias externas não figuram como osprincipais parceiros. Muitas das empresas preferem fazer uso de seu quadro de

colaboradores em função da característica estratégica dos Escritórios de

Gerenciamento de Projetos. As grandes organizações apostam na valorização da

carreira do gerente de projetos. O perfil destes profissionais deve ser voltado para o

conhecimento das práticas de gerenciamento de projetos, orientação à processos e

boa comunicação. A maioria dos responsáveis por Escritório de Gerenciamento de

Projeto possui o cargo de Gerente e tem salário fixo, e esta remuneração poderiaser incentivada na medida em que exista uma boa performance do portifólio de

projetos.

A estrutura de gerência de projetos encontra-se, ainda, em um determinado

departamento ou setor específico, não sendo notada a sua disseminação por toda a

empresa.

8 A empresa funcional é aquela claramente dividida em áreas de conhecimento ou departamentos, e que defineuma hierarquia clara nessas áreas.9 A estrutura matricial também é dividida em departamentos, como a funcional, mas essa divisão não é tãorígida: na matricial, encontramos representantes de alguns departamentos alocados em outros.



Mas, é preciso saber como se deve proceder, para medir o sucesso dos

Escritórios de Gerenciamento de Projetos e, neste aspecto, as empresas estão

focando as abordagens quantitativas e qualitativas. Após a implantação dos

Escritórios de Gerenciamento de Projetos a lucratividade dos projetos melhorou, a

quantidade de projetos terminados no prazo aumentou e os orçamentos foram

mantidos. É preciso observar, também, o crescimento no nível de aceitação dos

projetos pelos clientes após a montagem do Escritório de Gerenciamento de Projeto

e que a implementação trouxe benefícios diretos para os executivos das empresas,

do ponto de vista de informação e controle.

A partir destas considerações, podemos concluir que é preciso consultar

outras organizações que possuam estrutura organizacional parecida e que seja domesmo porte da organização onde será implantado o Escritório de Gerenciamento

de Projeto, a fim de que possamos minimizar riscos, otimizar o funcionamento e,

conseqüentemente, economizar tempo e dinheiro. Os processos, métodos e padrões

de gerência de projetos melhoram como um todo na organização, além do aumento

de maturidade por parte deste gerenciamento. Deve existir um processo de melhoria

contínuo para que as necessidades e a evolução de maturidade10 da organização

sejam beneficiadas.

2.3. GERENCIAMENTO DE PROJETOS ÁGIL

Uma nova abordagem para desenvolvimento de software tem despertado

grande interesse entre as organizações de todo o mundo. Estamos vivendo umatendência para o desenvolvimento ágil de aplicações devido ao ritmo acelerado de

mudanças na tecnologia da informação, pressões por constantes inovações,

concorrência acirrada e grande dinamismo no ambiente de negócios.

Apesar de existir a algum tempo, apenas recentemente a expressão

“Métodos Ágeis” vem se tornando mais popular no Brasil por usar uma abordagem

10 As organizações modernas tendem a crescer em escopo e metas – pedindo que as equipes de projetos

entreguem projetos ainda mais complicados. Á esta capacidade de uma organização de coordenar esses esforços – entregar projetos ao mesmo tempo em que direciona sua estratégia – define sua maturidade em gerenciamentode projetos organizacionais. Ou seja, maturidade é o processo de melhoria de uma organização, com base em um

parâmetro.



simplificada. Na verdade, ser simples, ter agilidade, é fazer a diferença e, ao

contrário do que parece, exige muita disciplina e organização.

Segundo Larman (2004, p. 25) agilidade quer dizer “a habilidade de criar e

responder a mudanças, buscando a obtenção de lucro em um ambiente de negócio

turbulento”; ou ainda, a capacidade de balancear a flexibilidade e a estabilidade.

Larman (2004, p. 26) enfatiza que a ausência de estrutura ou estabilidade pode levar

ao caos, mas que a estrutura em demasia gera rigidez.

As organizações têm buscado a melhoria de seus processos nos últimos

anos, objetivando a redução de custos e prazos, o aumento da previsibilidade e

maior satisfação dos clientes, com um menor número de defeitos no produto final e

melhores resultados em seus negócios. As transformações do ambiente tambémsão acompanhadas pelo gerenciamento de projetos.

O PMBOK (2004) é um guia de melhores práticas de gerenciamento de

projetos que aplicados adequadamente permitem a realização de um projeto com

sucesso. Os processos de gerenciamento de projetos são divididos em nove áreas

de conhecimento (escopo, prazo, custo, qualidade, riscos, comunicação, recursos

humanos, aquisição e integração) que organizam a aplicação das técnicas e

ferramentas necessárias a realização de um projeto.Os gerentes de projetos falam de uma “restrição tripla” - escopo, tempo e

custo do projeto - no gerenciamento de necessidades conflitantes do projeto. A

qualidade do projeto é afetada pelo balanceamento desses três fatores. Projetos de

alta qualidade entregam o produto, serviço ou resultado solicitado dentro do escopo,

no prazo e dentro do orçamento. A relação entre esses fatores ocorre de tal forma

que se algum dos três fatores mudar, pelo menos um outro fator provavelmente será

afetado. Segundo Salles Júnior (2006, p. 26), os gerentes de projetos tambémgerenciam projetos em resposta a incertezas. Um risco do projeto é um evento ou

condição incerta que, se ocorrer, terá um efeito positivo ou negativo em pelo menos

um objetivo do projeto.

O método tradicional está voltado para o processo seqüencial e preocupado

com a qualidade do produto a ser entregue. O método ágil volta-se para uma maior

rapidez de adequação à estas mudanças e mantém o cliente integrado à equipe,

além de proporcionar ciclos mais curtos de desenvolvimento, o que faz com que os

especialistas em gerenciamento de projetos travem grandes discussões.



Contudo, o gerenciamento de projetos está inserido em um contexto de

freqüentes falhas ocasionadas pelo não cumprimento dos prazos de entrega dos

produtos que vão desde a falta de conhecimento dos métodos e técnicas até uma

má utilização das práticas de Gestão de Projeto. Neste cenário, APM ( Agile Project

Management – Gerenciamento de Projetos Ágil) vem preencher o espaço deixado

entre a Gerência de Projetos e os indicadores de desempenho relacionados ao

prazo de entrega e qualidade desses projetos. APM é uma abordagem relativamente

nova, o que tornam necessários estudos mais detalhados e a aplicação de casos

reais para a confirmação de sua real contribuição no gerenciamento de projetos.

2.3.1. O Manifesto Ágil

O Manifesto for Agile Software Development 11 (2001) realizado em fevereiro

de 2001, por um grupo de 17 pensadores independentes, autores e representantes

das técnicas e metodologias ágeis sobre desenvolvimento de software (Kent Beck,

Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin

Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, BrianMarick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave

Thomas), e às vezes concorrentes entre si, discutiu, coletou e documentou idéias

comuns sobre o desenvolvimento de software, identificando uma abordagem ágil

aplicada ao desenvolvimento de projetos, estabelecendo um padrão comum para

processos ágeis.

O Manifesto fornece algumas idéias concretas, ao mesmo tempo em que

discute que é preciso definir um conjunto de valores baseados na confiança erespeito mútuos e de promover modelos organizacionais baseados em pessoas,

colaboração e construção de uma comunidade de organizações em que gostariam

de trabalhar.

O movimento ágil não é contra as metodologias. Na realidade, muitos de

seus integrantes desejam restaurar a credibilidade da palavra metodologia, querem

restabelecer um equilíbrio, abraçam a modelagem, através da Unified Modeling

11 Manifesto para o desenvolvimento ágil de software



Language12 (UML – Linguagem de Modelagem Unificada) devido a sua simplicidade

de entendimento e manuseio. A documentação é abraçada por eles, mas não em

centenas de páginas de rara manutenção e utilização. É preciso planejar, mas

reconhecer os limites deste planejamento em ambientes turbulentos. É preciso

entregar produtos ágeis, capazes de serem adaptados de forma fácil e de se ter

equipes com características semelhantes.

O “Manifesto Ágil” não rejeita os processos e ferramentas, a documentação,

a negociação de contratos ou o planejamento, mas simplesmente mostra que eles

têm importância secundária quando comparado com os indivíduos e interações, com

o software estar executável, com a colaboração do cliente e as respostas rápidas a

mudanças e alterações. Esses conceitos aproximam-se melhor com a forma quepequenas e médias organizações trabalham e respondem a mudanças.

Os valores considerados pelo Manifesto for Agile Software Development

(2001) são: (i) A valorização dos indivíduos e as interações sobre a importância dos

processos e ferramentas; (ii) O software funcionando sobre uma extensa

documentação; (iii) A colaboração dos clientes sobre a negociação em contratos; e,

(iv) As respostas ás mudanças sobre o cumprimento de um plano.

2.3.2. Princípios do Gerenciamento de Projetos Ágil

O gerenciamento de projetos é constituído de doze princípios que juntos

criam um ambiente que encoraja a surgir os resultados no projeto (HIGHSMITH,

2004). Isolados, eles podem contribuir no andamento do projeto. Estes princípios

tratam do valor do produto e do estilo de gerenciamento baseado na liderança ecolaboração. No primeiro, são focadas as entregas iterativas e baseadas nas

funcionalidades que gerem valor para o cliente, sempre com a busca da excelência

técnica. No segundo princípio, torna-se claro a necessidade de se encorajar a

exploração, construir equipes que possuam elevada capacidade de se adaptar e que

simplifiquem o processo.

12 UML é uma linguagem de modelagem não proprietária de terceira geração, desenvolvida para orientação áobjetos. O que significa que ela não diz para você o que fazer primeiro e em seguida, ou como projetar seusistema, mas auxilia a visualizar seu desenho e a comunicação entre objetos do sistema.



Os princípios do Gerenciamento de Projetos Ágil, segundo o Manifesto for

Agile Software Development (2001) são:

I. A satisfação do cliente a partir de entregas rápidas e contínuas de um

software valioso, que agregam valor;

II. Garantir a vantagem competitiva com a mudança de requisitos, mesmo

em desenvolvimento bastante avançado;

III. Entregar freqüentemente software funcionando em prazos curtos de

algumas semanas;

IV. Pessoas responsáveis pelo negócio e desenvolvedores devem trabalhar

juntas diariamente durante todo o projeto;

V. Construir projetos em torno de indivíduos motivados, dando-lhes oambiente e confiança de que necessitam para fazer o trabalho.

VI. O método mais eficiente e eficaz de transmitir informações em uma

equipe é a comunicação pessoal através da conversa “cara-a-cara”;

VII. A medida mais importante sobre o progresso do projeto são as entregas

de código que funcionam;

VIII. Processos ágeis promovem o desenvolvimento sustentável.

Patrocinadores, desenvolvedores e usuários devem ser capazes de manter o ritmoconstante indefinidamente;

IX. Atenção contínua para a excelência técnica e bom projeto, reforça a

agilidade;

X. Simplicidade - a arte de maximizar o valor de trabalho não feito - é

essencial;

XI. As melhores arquiteturas, requisitos, e projetos emergem de equipes

auto-organizadas;XII. Em intervalos regulares, a equipe reflete sobre como se tornar mais

eficaz e, em seguida, ajusta o seu comportamento.

2.3.3. Desenvolvimento Iterativo



Uma iteração é caracterizada por uma seqüência distinta de atividades com

baseline13 e critérios de avaliação planejados. Cada iteração incorpora atividades de

modelagem de negócio, requisitos, análise e projeto, implementação, testes e

implantação à medida que, o projeto vai evoluindo em suas fases. A cada iteração

um conjunto de produtos é gerado.

Neste sentido, uma medida boa do progresso é ter o software funcionando

no final de cada iteração. Os benefícios do desenvolvimento iterativo podem residir

no fato do desenvolvimento lidar com mudanças, o sistema ser integrado contínua e,

progressivamente e os riscos serem atacados mais cedo, porque os elementos são

integrados progressivamente. É possível realizar um aprendizado e melhoria

contínua do processo, gerando produtos mais robustos com o aumento defuncionalidades.

O desenvolvimento baseado no modelo cascata, conforme apresentado no

modelo em Cascata (figura 3), é um modelo de desenvolvimento de software

seqüencial através das fases que o compõe.

O modelo em cascata demanda uma substancial integração e esforço de

teste para alcançar o fim do ciclo de vida, um período que pode se estender por

vários meses ou anos. Os requisitos de sistema identificados demoram muito tempoaté serem implementados e testados podendo atrasar a resolução de problemas,

sendo uma das causas das falhas do projeto em cascata.

Figura 3 - O Modelo Cascata atrasa a resolução de riscos

FONTE: http://www.wthreex.com/rup/manuals/intro/im_bp1.htm

13. Baseline - parâmetros, padrão de valor, dados de referência, linha de base; comparativo, básico, de base.



No método ágil, ao contrário, deve-se produzir um desenvolvimento

completo e teste num período de 4 semanas. Enfatiza-se a obtenção de pequenos

pedaços de funcionalidades executáveis para agregar valor ao negócio cedo,

antecipando a resolução de riscos ao projeto, conforme observado no Modelo

Iterativo (figura 4), e continuamente agregar novas funcionalidades através do ciclo

de vida do projeto.

Figura 4 - O Modelo Iterativo antecipa a resolução de riscos.

FONTE: http://www.wthreex.com/rup/manuals/intro/im_bp1.htm

Na figura 5 pode-se observar como o ciclo de vida do desenvolvimento

iterativo é dividido em fases e iterações. Por fase podemos entender como sendo o

espaço de tempo entre dois marcos significativos do projeto, durante o qual objetivos

são atingidos, artefatos elaborados e decisões sobre passar ou não para a próxima

fase são tomadas. As fases indicam a maturidade do sistema. Cada uma das fases

é dividida em iterações. Mudanças de requisitos e táticas são acomodadas, sendo

mais fácil melhorar e refinar o produto, aumentando sua robustez, inclusive com a

realização de testes e integrações acontecendo muito mais cedo, contribuindo para

um maior aprendizado das organizações a medida em que o ciclo de vida evolui.



Figura 5 - As entregas no Modelo Iterativo

FONTE: Figueiredo 2007

A filosofia ágil está voltada para o desenvolvimento iterativo. Ou seja, obter

as exigências iniciais e criar um código que funcione, seguidos por mais exigências

e por mais códigos que funcione, identificando uma iteração como um “pacote de

tempo” que possui um custo fixo e um conjunto de funcionalidades que pode variar,

onde estas funcionalidades serão priorizadas pelo cliente e comporão a iteração.

A flexibilidade é identificada na medida em que funcionalidades priorizadaspelo cliente poderão ser descartadas, se classificadas no final da lista. Assim, é

possível existir funcionalidades que sejam perdidas, mas nunca as datas.

2.3.4. PMBOK Versus Ágil

A gerência de projetos, conforme já mencionado, pode ser definida como umconjunto de processos integrados. Os processos da gerência de projetos, segundo o

PMBOK são divididos em cinco grupos: iniciação, planejamento, execução, controle

e fechamento. A figura 6 representa esta visão

Por outro lado, nas metodologias ágeis, os grupos de processos,

denominados também de práticas são, da mesma forma que as tradicionais,

divididas em cinco grupos: previsão, investigação, exploração, adaptação e

fechamento. A figura 7 representa esta visão.



Figura 6 – Ligações entre os grupos de processos do PMBOK

FONTE: PMBOK – PMI, 2000

Em uma análise comparativa entre as duas abordagens, percebe-se que,

apesar de apresentarem diferenças significativas referentes a sua consecução, a

visão dos processos que compõem a gerência de um projeto não se modifica

substancialmente. Além da nomenclatura distinta, o conjunto de setas em cada um

dos gráficos também apresenta diferenças significativas. A principal delas não está

relacionada, no entanto, a ausência de uma seta – no sentido Adaptação –

Exploração na figura 7 – e sim relacionada ao que ela representa nos modelos. Nocaso da proposta do PMBOK as setas representam a troca de documentação e de

itens documentáveis. Já na proposta ágil, apesar de as setas poderem indicar fluxo

de documentos, estas não se restringem a estes. Como princípio das metodologias

ágeis, deve haver um balanceamento entre as informações explícitas e tácitas,

privilegiando a comunicação interpessoal e diminuindo a documentação. Esta

diminuição, no entanto, significa que deve ser documentado apenas o que

efetivamente é considerado importante para o andamento do projeto e para agarantia do seu sucesso, ou seja, informações úteis.



Figura 7 – Ligações entre os grupos de processos segundo as metodologias ágeis

FONTE: (HIGHSMITH, 2003 p.25)

Cada uma das etapas definidas na figura 6 é colocada em prática através de

um conjunto de atividades de gerências de projetos relacionadas ao escopo, tempo,

custo, qualidade, risco, recursos humanos, comunicação, integração e aquisições.

Independentemente do paradigma empregado, estas atividades devem ser

realizadas com maior ou menor nível de detalhamento e foco de atenção. Assim, o

que distingue uma abordagem da outra é a concentração de esforços. Nas

metodologias tradicionais, particularmente analisando o PMBOK, a concentração

está localizada na etapa de planejamento de projetos. No paradigma tradicional o

planejamento deve determinar o que poderá ou deverá acontecer durante a

execução do projeto, caracterizando um processo onde a flexibilidade é tratada;

mas, não facilitada.

As práticas relacionadas ao gerenciamento ágil de projetos dão ênfase as

etapas de execução e de controle de um projeto, descritas inclusive por outras

denominações: Exploração e Adaptação.

2.3.5. Áreas de Conhecimento do Gerenciamento de Projetos Aplicáveis

A possibilidade de mudança do gerenciamento de projetos tradicional para o

gerenciamento de projetos ágil requer uma atenção especial em cinco áreas de

conhecimento definidas pelo PMBOK (PMI, 2004), são elas: Gerenciamento de



Recursos Humanos, Gerenciamento da Qualidade, Gerenciamento da Integração,

Gerenciamento do Escopo e Gerenciamento do Tempo.

Tanto a abordagem ágil quanto a abordagem tradicional identificam as três

restrições de um projeto como sendo: custo, tempo (agenda) e escopo. Para a

abordagem tradicional, no entanto, o escopo do projeto deve ser fixado para que

tempo e custo possam ser estimados. Já as abordagens ágeis se manifestam

acreditando que o escopo estará em constante mudança, então tempo e custo

devem ser fixados. Em abordagens ágeis a estratégia de Comando-controle deve

ser substituída por facilitação, colaboração e suporte, conforme demonstra a figura a

seguir.

PMBOK

Gerenciamento das

Aquisições

Gerenciamento das

Comunicações

Gerenciamento dos

Riscos

Gerenciamento

dos Recursos

Humanos

Gerenciamento da

Qualidade

Gerenciamento da

Integração

Gerenciamento do

Escopo

Gerenciamento doTempo

Gerenciamento do

Custo

Figura 8 - Áreas de Conhecimento do PMBOK (PMI, 2004) mais afetadas em APM

FONTE: Adaptação do PMBOK (PMI, 204)

Uma abordagem segundo as áreas do conhecimento do PMBOK (PMI,2004) nos leva a perceber que: (i) a preocupação está na definição do escopo em

um alto nível que permita o entendimento do trabalho, inclusive com a participação

do cliente para a priorização das funcionalidades; (ii) o cronograma é orientado ao

produto que será produzido em iterações curtas que contribuem para uma redução

dos conflitos pela cumplicidade no processo; (iii) as alterações são incorporadas

dentro da iteração mais apropriada e de comum acordo com o cliente, podendo

elevar o custo final; (iv) os padrões a serem seguidos devem ser estabelecidos no

início do projeto e estarem concentrados na programação em pares; (v) a

monitoração e o controle dos riscos ocorrem durante todo o processo de



desenvolvimento; (vi) a comunicação é colaborativa e direta entre todos os membros

da equipe, o que exige um certo grau de maturidade por parte da organização, do

cliente e da equipe; (vii) todos os participantes do projeto executam suas tarefas,

planejam e tomam decisões em conjunto, compartilhando suas experiências; o

processo de aquisição deve ser evitado em função da volatilidade dos requisitos;

(viii) a atuação colaborativa da equipe com o cliente favorece um maior grau de

informalidade e o conhecimento implícito é privilegiado; (ix) o papel do gerente de

projetos é voltado para o papel de facilitador ou coordenador das atividades.

2.3.5.1. Gerenciamento dos Recursos Humano

O PMBOK (2004, p. 199) define o planejamento organizacional como oprocesso onde papéis e responsabilidades são atribuídos; o PMBOK (2004) define

desenvolvimento de time como o desenvolvimento do conjunto de competências e

habilidades apropriadas para cada membro do time.

A forma ágil de se fazer isso é estabelecer times cross-functional 14 e permitir

que eles sejam auto-gerenciados. Com times auto-gerenciados muitos imaginam

que o papel de gerente de projeto passa a ser ameaçado. Ao contrário, este passa a

ser muito mais importante para o projeto e para o time, agindo como um “líderservidor” descrito na década de 80 por Robert Greenleaf, e não mais como o gerente

“comando controle”.

2.3.5.2. Gerenciamento da Qualidade

Pelo fato do código ser incrementado durante o desenvolvimento de cada

iteração, a abordagem ágil traz o controle de qualidade novamente para dentro daanálise e desenvolvimento do produto, estando a qualidade agora presente desde as

primeiras fases do projeto ao invés de ficar aguardando “o pior” no final do projeto.

Todo o time tem seu papel no controle de qualidade em práticas ágeis, todos estão

envolvidos em garantir que a entrega valorizará o retorno do investimento (ROI15) do

cliente.

14 Cross-functional - Trata-se de equipes envolvendo empregados de diversas funções, de diversas áreas dentrode uma organização.15 ROI em finanças, retorno sobre investimento (em inglês, return on investment ou ROI), também chamado taxade retorno.

http://pt.wikipedia.org/wiki/Finan%C3%A7as



http://pt.wikipedia.org/wiki/L%C3%ADngua_inglesa







2.3.5.3. Gerenciamento da Integração

Em Gerenciamento de Integração um entregável chave é o documento de

Plano do Projeto que é elaborado e mantido pelo gerente de projeto. Em abordagens

ágeis este entregável é substituído por uma série de atividades de visão e

planejamento que são executadas em ciclos iterativos. O controle de mudanças

também é algo que sofre mudanças bem grandes nas abordagens ágeis, pois aqui

este é integrado nas rotinas diárias de um time ágil. As mudanças do produto são

gerenciadas através de um repositório de funcionalidades que é gerenciado pelo

gerente de produto do cliente. Este é responsável por manter esta lista com

funcionalidades priorizadas de acordo com o valor de negócio que elas representam

para o cliente. Isto é o que garante o ROI.No final de cada iteração, o time realiza as reuniões de revisão e

retrospectiva para colher as percepções de cada membro da equipe. O time (cliente,

desenvolvedores, arquitetos, gerente de projeto, testadores...) é o Change Control

Board .

2.3.5.4. Gerenciamento de Escopo e Tempo

A abordagem ágil trabalha com tempo (agenda) e custo fixo, paraimplementar as funcionalidades de alto valor para o negócio do cliente.

O escopo do projeto pode, e deve ser fixo se: clientes não necessitassem de

novas funcionalidades, não houvesse mudanças de mercado nem mudanças de

tecnologia e se o cliente realmente conhecesse tudo que precisa no início de um

projeto: Planejamento, definição, verificação e controle de escopo são matérias que

recebem grande atenção no PMBOK (2004).

Abordagens ágeis também fornecem uma grande atenção para estasmatérias, mas com uma filosofia de gerenciamento de escopo bem diferente.

A abordagem tradicional, trabalha duro para prevenir e evitar as mudanças

de escopo, enquanto abordagens ágeis aguardam e “abraçam” estas mudanças.



3. DESENVOLVIMENTO DO ESTUDO

O termo Scrum é o nome de um tipo de jogada que acontece no jogo de

rugby16. O termo foi utilizado pela primeira vez, no contexto de processo de

desenvolvimento ou manufatura, por Ikujiro Nonaka e Hirotaka Takeuchi em seu

artigo chamado “The New Product Development Game” publicado na Harvard

Business Review em 1986. Por isto várias ações ou etapas desta ferramenta nos

volta ao jogo de forma rápida e alguns termos.

SCRUM foi criado no início de 1990 por Ken Schwaber e Jeff Sutherland

para ajudar as organizações a lutar com complexos projetos de desenvolvimento. Otrabalho de Jeff Sutherland com as primeiras idéias do SCRUM e de Ken Schwaber

com metodologias transformados em vários anos de conversa, colaboração e

pesquisas culminaram em um documento que ambos apresentaram no OOPSLA 17

96 descrevendo SCRUM .

Cinco anos mais tarde, Ken Schwaber e 16 outros se juntaram em Utah, em

Fevereiro de 2001, descobriram o que tinham em comum e escreveram o Manifesto

Ágil. Eles fundaram a Agile Alliance, uma organização sem fins lucrativos dedicada àcriação de software ágil.

Scrum aplica-se a projetos tanto pequenos como grandes. Esforçando-se

para liberar o processo de quaisquer barreiras, o seu principal objetivo é conseguir

uma avaliação correta do ambiente em evolução, adaptando-se constantemente ao

“caos” de interesses e necessidades, indicadas e utilizadas para o desenvolvimento

de softwares em ambientes complexos, onde os requisitos mudam com certa

freqüência, sendo o caminho utilizado para aumentar produtividade nesses tipos desistemas.

O objetivo deste capítulo é descrever de forma sucinta a ferramenta Scrum

que é um dos métodos ágeis e sugerir de forma consistente um modelo de escritório

de gerenciamento de projetos capaz de planejar, executar e controlar os projetos

que necessitem de uma maior agilidade, além dos aspectos organizacionais

16 O Rugby é disputado de futebol de origem na Inglaterra, por duas equipes de quinze jogadores, numa partidade duas partes de quarenta minutos contínuos, o relógio só para quando algum jogador necessita de cuidados

médicos. O objetivo do jogo é marcar o maior número de pontos.17 OOPSLA - Object Oriented Programming, Systems, Languages and Appl icati ons é uma conferência anualque abrange temas sobre sistemas de programação object-oriented, linguagens e aplicações.



envolvidos neste ambiente de gerenciamento. Para Veras (2009) o Scrum Master da

Pitang, o Scrum é considerado um poderoso framework .

O Scrum pode ser considerado um poderoso framework para aorganização de times de desenvolvimento de Software. No entanto, épreciso tomar algumas precauções para maximizar esse poder. Umadas grandes preocupações que deve ser considerada é no que dizrespeito à comunicação entre as pessoas envolvidas. A forma e oambiente criado para que as informações possam circular entre aspessoas de um projeto é tão importante quanto os aspectos técnicosnecessários para o seu bom andamento. Entretanto, não há um guiaperfeito ou um conjunto de regras capaz de garantir que acomunicação seja tão ágil quanto esperamos. Pelo contrário, osaspectos psicológicos envolvendo o modo como cada pessoa secomunica com as outras nos deixa um amplo cenário para que novasexperiências sejam postas em prática e posteriormente avaliadas.

3.1. SCRUM

Scrum é bastante objetivo, com papéis bem definidos, de fácil adaptação e

ainda, sua curva de aprendizado é relativamente baixa.

Segundo Larman (2004, p. 109), o Scrum não é um processo previsível, ele

não define o que fazer em toda circunstância. Ele é usado em trabalhos complexos

nos quais não é possível prever tudo o que irá ocorrer e oferece um framework 18 e

um conjunto de práticas que torna tudo visível. Isso permite aos praticantes do

Scrum saber exatamente o que está acontecendo ao longo do projeto e fazer os

devidos ajustes para manter o projeto se movendo ao longo do tempo visando

alcançar os seus objetivos.

Logo, o Scrum não vai dizer exatamente o que fazer, não irá resolver todos

os seus problemas, mas com certeza os problemas serão mais facilmente

identificados. Por ser um framework , irá servir como um guia de boas práticas para

atingir o sucesso. Entretanto, as decisões de quando e como usá-lo, quais táticas e

estratégias seguir para obter produtividade e realizar as entregas ficam por conta de

18 Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio deum subsistema da aplicação.



quem estiver aplicando. O conhecimento das suas práticas permite a aplicação das

mesmas de forma variada e este é um dos aspectos positivos do Scrum, a

adaptabilidade.

Vale ressaltar que as práticas 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 além de software e

principalmente para projetos de pesquisa e inovação.

3.1.1. Definições

A ferramenta Scrum, segundo Ken Schwaber (2001), estabelece um

conjunto de regras e práticas de gestão que devem ser adotadas para garantir o

sucesso de um projeto. Centrado no trabalho em equipe, melhora a comunicação e

maximiza a cooperação, permitindo que cada um faça o seu melhor, se sentindo

motivado profissionalmente, proporcionando um aumento de produtividade.

Englobando processos de engenharia, este método não requer nem fornece

qualquer técnica ou método específico para a fase de desenvolvimento de software.Dentre as práticas definidas por Ken Schwaber (2001) e sugeridas durante o

ciclo de vida da Scrum, pode-se destacar:

A entrega de “software funcionando” ao final de cada Sprint : onde a meta

é, ao final de cada Sprint , entregar algo que agregue valor para o Product

Owner ;

Daily Scrum: Reuniões diárias e de pé, de no máximo 15 minutoscomposta pelo Product Owner, o Scrum Master e o time de

desenvolvimento. A fim de avaliar o andamento do Sprint e sanar qualquer

problema que possa estar ocorrendo;

A elaboração de um Product Backlog : que consiste em listar as

histórias/funcionalidades do sistema, juntamente com o esforço necessário

para concluí-las, bem como se devem indicar também em que Sprints

serão desenvolvidas tais histórias/funcionalidades;

A elaboração de Sprints Backlogs: que consiste em listar todas as

histórias/funcionalidades selecionadas para aquele Sprint e controlar os



prazos estipulados para cada item, bem como preenchendo seu estado,

por exemplo, se ela está concluída. Nesta etapa também, é gerado um

gráfico de Burndown que indica o esforço que está levando para

conclusão do Sprint .

3.1.2. Conceitos

O SCRUM define conceitos importantes referentes à aplicação do processo

no período do projeto. Esses conceitos fundamentam práticas importantes para

definir a estratégia de inspeção e adaptação do projeto, fornecendo uma excelentevisibilidade do andamento dos trabalhos, juntamente com uma importante

previsibilidade do que acontecerá no futuro.

3.1.2.1. Sprint

No Scrum o progresso do projeto é baseado em uma série de iterações bem

definidas chamadas Sprints. A recomendação é de que a duração da Sprint fique

entre 2 a 4 semanas. Esse período é chamado de Time-box .O Scrum é baseado em entrega de produto a cada Sprint , logo é

recomendável que durante o desenvolvimento do produto, exista um padrão, um

mesmo time-box , para todas as Sprints. Isto é importante para se conseguir medir o

progresso e a produtividade da equipe no projeto.

Para Kniberg (2007, p. 23 et seq) o Sprint só começa após a definição do

que será feito, pois trata-se de um evento muito importante para o processo com

vários pontos definidos:

Tenha certeza de que o product backlog está organizado e fechadoantes da reunião de planejamento do sprint .E o que isso significa? Que todas as estórias estão perfeitamentebem definidas? Que todas as estimativas estão corretas? Que todasas prioridades devem permanecer fixas? Não, não e não! O que issosignifica(...)

O planejamento de sprint é uma reunião crítica, provavelmente oevento mais importante no Scrum (na minha opinião, claro). Umencontro de planejamento de sprint mal feito pode bagunçartotalmente um sprint.



(...)Possuir algum tipo de cronograma para a reunião de planejamentodo sprint reduzirá o risco de ultrapassar o espaço de tempo previsto.(...)O objetivo do sprint deve responder a pergunta fundamental “Porque nós estamos fazendo este sprint? Porque não saímos de fériasao invés de fazê-lo?”. De fato, uma maneira de extrair o objetivo deum sprint do product owner é literalmente fazer esta pergunta.

3.1.2.2. Product Backlog

Um dos conceitos mais importantes é o Backlog do produto (ou Product Backlog ), e

o Backlog de Impedimentos ( Impediment Backlog ), ambos considerados o coração do Scrum.

O Product Backlog contém uma lista de itens priorizados que incluem tudo o que precisa ser

realizado, que possa ser associado com valor de negócio, para a finalização do projeto, sejamrequisitos funcionais ou não. É importante ressaltar que cada item no Backlog do produto

deve ter um valor de negócio associado ( Business Value), onde podemos medir o retorno do

projeto e priorizar a realização dos itens.

Para Kniberg (2007, p. 19) o product backlog é o coração do Scrum. Pois é a partir

deste que tudo começa. O product backlog é a lista de requisitos, estórias, coisas que o cliente

deseja, descritas utilizando a terminologia do próprio cliente.

Kiniberg (op cit ) define uma lista de itens para identificar o product backlog;

ID – Uma identificação única, apenas um número com auto-incremento. Issoé para evitar que percamos o controle sobre as estórias quando nós mudamosseus nomes.Nome – Um nome curto e descritivo para a estória. Por exemplo, “Ver ohistórico de transações”. Suficientemente claro para que os desenvolvedorese o product owner entendam mais ou menos sobre o que estamos falando, eclaro o bastante para distingui-la das demais estórias. Normalmente de 2 a 10

palavras.Importância – a pontuação de importância dessa estória para o productowner . Por exemplo 10 ou 150. Mais pontos = mais importante.Eu tento evitar o termo “prioridade” já que prioridade 1 é tipicamenteinterpretado como “prioridade mais alta”, o que fica feio se mais tarde vocêdecidir que algo é ainda mais importante. Qual pontuação de prioridade esseitem deveria receber? Prioridade 0? Prioridade -1?Estimativa inicial – As estimativas iniciais da equipe sobre quanto tempo énecessário para implementar aquela estória, se comparada a outras estórias.A unidade é pontos por estória e geralmente corresponde mais ou menos a“relação homem/dias” ideal. 1. Pergunte à equipe “se vocês puderem ter o número ideal de pessoas para

esta estória (nem muitas, nem poucas, normalmente duas), e se trancarem emuma sala cheia de comida e trabalharem sem distúrbio algum, após quantosdias vocês apresentarão uma implementação pronta, demonstrável e testada?



Se a resposta for “com 3 pessoas trancados em uma sala levaráaproximadamente 4 dias” então a estimativa inicial é de 12 pontos porestória.2. O importante não é ter estimativas absolutamente precisas (por exemplo,dizer que uma estória com 2 pontos deverá gastar 2 dias), mas sim obterestimativas relativas corretas (por exemplo, dizer que uma estória com 2 pontos gastará cerca da metade de uma estória com 4 pontos).Como demonstrar – Uma descrição em alto nível de como a estória serádemonstrada na apresentação do sprint. Isso é simplesmente uma simplesespecificação de teste. “Faça isso, então faça aquilo e então isso deverá

acontecer.” o Se você pratica TDD (desenvolvimento orientado a testes) essadescrição pode ser usada como pseudo-código para o seu código de teste deaceitação.Notas – quaisquer outras informações, esclarecimentos, referências a outrasfontes de informação, etc. Normalmente ágil bem breve.

O Impediment Backlog contém todos os itens que impedem o progresso do

projeto e geralmente estão associados a riscos. Estes itens não possuem uma

priorização, mas está geralmente associado a algum item do Backlog do produto ou

as tarefas dos itens, Exemplo “instalar ambiente para desenvolvedores” , “Instalação

de banco de dados do projeto”, etc. O controle desses itens é muito importante e o

Scrum Master é o grande responsável pela liberação desses impedimentos, abrindo

caminho para o time de desenvolvimento executar a realização dos itens do Backlogdo produto. Existem muitas formas para gerenciar o Product Backlog e o Impediment

Backlog todas elas precisam que cada item seja identificado e estimado, em tempo

ou tamanho, e que a sua ordem de importância seja estabelecida pelo cliente. Com

esses atributos é possível ter os itens em uma ordem de priorização.

3.1.2.3. Planing Meeting

É a reunião de planejamento do Sprint . Ela ocorre no início de cada Sprint epode ser composta por qualquer pessoa, além da equipe do projeto, que poderá ser

convidada a participar da reunião a fim de agregar valor à reunião desde que tenha

sido aprovada a sua participação pelo proprietário do produto.

Em um primeiro momento o proprietário do produto e o time fazem a revisão

do Product Backlog , com a intenção de discutir o propósito e as metas de cada item.

O time, então, define os itens que serão desenvolvidos na próxima Sprint e a meta.

Em seguida, o proprietário do produto deverá detalhar algum item ouesclarecer dúvidas quanto ao objetivo do mesmo. O time elabora a estratégia de



desenvolvimento para que a meta da Sprint seja atingida. Ao final desta reunião eles

devem saber responder como construirão as funcionalidades do produto durante o

Sprint . Essas estratégias são geradas a partir do detalhamento dos itens do Product

Backlog . As tarefas geradas através desse detalhamento é chamado de Sprint

Backlog , onde os membros do time deverão escolher suas tarefas e estimá-las em

horas.

3.1.2.4. Dailly Meeting

Reunião diária iniciada a partir do início da Sprint , que é realizada sempre no

mesmo local e horário, com o facilitador e os membros do time, com duração exata

de 15 minutos, para que cada um dos membros possa relatar os progressos eobstáculos que forem surgindo em seu caminho.

No dailly meeting cada membro em ordem apresenta o que executou desde

a ultima reunião.

3.1.2.5. Review

Momento do dailly meeting em que os membros da equipe identificam se

existe diferença entre o que deveria ser entregue e o que está sendo entregue.

3.1.2.6. Retrospective

Representa a ferramenta mais importante para que o sucesso seja

alcançado, pois o time comenta tudo aquilo que funcionou e não funcionou dentro da

Sprint . O time visualiza os itens citados, discute sobre cada um deles e planeja

ações para a próxima Sprint .

3.2. PAPÉIS RESPONSABILIDADES DO SCRUM



O SCRUM como qualquer outra metodologia é baseada em papéis e

responsabilidades, porém, os papéis do SCRUM são bem abrangentes e

direcionados para garantir o sucesso do projeto.

3.2.1. Product Owner (proprietário do produto)

É o responsável por definir as funcionalidades do produto e decidir as datas

de lançamento e conteúdo, assumindo a responsabilidade pela rentabilidade (ROI) e

priorizando as funcionalidades de acordo com o valor de mercado. Ajustafuncionalidades e prioridades e aceita ou rejeita o resultado dos trabalhos.

O Escopo e a importância são definidos pelo product owner. Estimativa é

definida pela equipe. Durante uma reunião de planejamento do sprint , estas três

variáveis são refinadas continuamente por diálogo “cara-a-cara” entre equipe e

product owner.

3.2.2. Scrum Master (gerente do projeto)

Representa a gerência para o projeto. É o responsável pela aplicação dos

valores e práticas do SCRUM , devendo remover obstáculos e garantir a plena

funcionalidade e produtividade da equipe. Garante, ainda, a colaboração entre os

diversos papéis e funções, servindo de escudo para interferências externas.

3.2.3. Developers (equipe)

Sua composição está voltada para um grupo entre 5 e 9 pessoas, formada

por programadores, testadores, desenvolvedores de interfaces, etc, que atuam em

tempo integral. O administrador de base de dados, por exemplo, é uma função que

constitui exceção à este grupo. A equipe Scrum é auto-organizável e as trocas entre

seus membros só ocorre na mudança de “Sprints”.



A produtividade da equipe deriva de fazer as coisas certas da primeira vez, a

partir de uma lista priorizada pelo proprietário do produto das atividades a serem

realizadas e, fazer estas coisas de forma muito eficaz. A maximização desta

produtividade está diretamente relacionada às medições de linhas de código por dia

ou pontos-de-função por pessoa/mês, que são definidos pela própria equipe. É a

equipe que define o planejamento e execução das atividades que estão sob sua

responsabilidade.

O Gerente do Projeto ou qualquer outro membro pode orientar, aconselhar e

informar a equipe, mas é da responsabilidade da equipe gerir a si própria. O trabalho

da equipe é concentrado em um período de 30 dias, onde haverá muita integração e

disseminação de informações entre os seus membros. A equipe faz o que fornecessário para cumprir o seu compromisso. Cada um de seus membros possui

várias qualificações, o que facilita o trabalho de seleção própria por parte de cada

membro das atividades a serem executadas. A equipe tem que descobrir o seu

próprio trabalho.

O quadro 2 traduz algumas das principais características citadas acima

sobre a equipe ágil em relação às equipes de desenvolvimento tradicional.

A transição de uma equipe que é gerida de uma equipe que gere a si própriaé difícil, mas a recuperação da produtividade e o prazer pelo trabalho tornam-se

impressionante. O trabalho de Gerente do Projeto é o de conduzir a equipe através

do presente transitório.

Ágil Tradicional



Voltado para o cliente Voltado para o gerenciamento

Equipe multi-qualificada Equipe de especialistas isolados

Informação amplamente

compartilhada Informação limitada

Poucos níveis de gerenciamento Muitos níveis de gerenciamenmto

Pouca descrição do trabalho Muita descrição do trabalho

Metas Compartilhadas Metas segregadas

Aparentemente caótico Aparentemente organizado

Equipe altamente compromissada Equipe altamente gerenciada

Melhoria contínua Melhoria incremental

Auto-organizada Auto-gerenciado

Baseado em valores e princípiosBaseada em políticas e

procedimentos

Quadro 2: Características das equipes Ágil e Tradicional.

3.3. CICLO DE VIDA SCRUM

No final dos anos 90, com a virada do milênio surgiu um novo cenário para

desenvolvimento de software, com vários métodos ágeis, entre eles: Adaptive

Software Development, Dynamic Systems Development, eXtreme Programming

(XP) e Scrum. Todos esses métodos empregam princípios ágeis, tais como ciclos

iterativos, entrega rápida de software funcionando e simplicidade, como definido noManifesto para Desenvolvimento Ágil, publicado em 2001. A essência desse

movimento é a definição de novo enfoque de desenvolvimento de software, calcado

na agilidade, na flexibilidade, nas habilidades de comunicação e na capacidade de

oferecer novos produtos e serviços de valor ao mercado, em curtos períodos de

tempo.

No Scrum, os projetos são organizados em ciclos (iterações), tipicamente

mensais (Sprint ). O Sprint representa um Time Box , dentro do qual é executado um

conjunto de atividades.



O Scrum define conceitos importantes referentes à aplicação do processo no

período do projeto. Esses conceitos fundamentam práticas importantes para definir a

estratégia de inspeção e adaptação do projeto, fornecendo uma excelente

visibilidade do andamento dos trabalhos, juntamente com uma importante

previsibilidade do que acontecerá no futuro. Finalmente, é realizada uma Sprint

Retrospective - retrospectiva para identificar o que funcionou bem durante um Sprint ,

o que poderá ser melhorado e quais as ações deverão ser tomadas para esta

melhora. A equipe, então, parte para a definição de um novo Sprint , reiniciando o

ciclo.

Essa dinâmica é possível porque o produto software nos permite que o

tratemos dessa forma. O custo para ajustar os conceitos no software não segue opadrão de um produto de processo prescritivo. A tecnologia nos permite construir o

software neste formato. A seguir vemos o ciclo de vida do projeto com as iterações

do Scrum:

Figura 9: Ciclo de Vida SCRUM .

FONTE: Figueiredo 2007

Um problema corriqueiro em empresas de software é o tempo investido para

conseguir obter o esforço e o prazo. É importante ressaltar que no início do projeto

as incertezas são grandes, porém, durante o projeto os riscos vão sendo resolvidos

sempre através de prototipações com desenvolvimento do software e de seu

funcionanmento.

Investir duramente na fase de requisitos com o objetivo de refinarestimativas não funciona, pois requisitos são abstrações com grande incerteza!





Owner e o feeling para o time. Nesta fase são planejadas as equipes e suas

atribuições e são definidos os processo de comunicação entre as equipes; e, (iii)

Nível Operacional, nesta fase são realizadas as tarefas de engenharia de sistemas

para desenvolver o software. As equipes são reunidas com tempos e tarefas

definidas (Dailly Meeting ), assim tornando mais dinâmico as atividades do projeto.

3.4. IMPLANTANDO SCRUM

A implantação de qualquer metodologia (ou prática ou padrão) requer um pré-

requisito principal para funcionar: o apoio da direção.

De nada adianta nossa boa vontade, nossa motivação, iniciativa e conhecimento

técnico se os maiores patrocinadores da mudança não demonstrarem pelo menosmetade disso.

A Globo.com implantou o Scrum com a finalidade de desenvolver produtos

para a internet principalmente por se tratar de uma empresa sujeita a grandes

modificações de requisitos e ao ambiente inovador a que está inserida.

A implementação começou com uma equipe de quinze pessoas,

desenvolvendo um projeto de ampla visibilidade com um grande potencial de acesso

por parte do usuário final. Como não existia nenhuma outra equipe utilizando o

Scrum o processo gerava uma certa desconfiança por parte dos participantes da

equipe, mesmo que a maioria deles estivesse extremamente comprometida com o

objetivo do projeto.

No intuito de minimizar essa desconfiança sugerimos que a implantação do

SCRUM seja aos poucos. De forma que, em pouco tempo, a implantação completa

seja só um pequeno passo.

Não pretendemos impor um único método para implantar o conceito de ágile e

SCRUM. Pois, esse está sendo o meio pelo qual a TSL Engenharia Ambiental está

implantando no setor de manutenção / atendimento ao cliente.

Os Passos são:

1) DAILY MEETINGS - Reúna a sua equipe diariamente e comece a fazer as três

famosas perguntas: O que você fez ontem? O que fará hoje? O que pretende fazer

para amanhã? Quais seus impedimentos? Essa é uma poderosa forma de

maximizar a comunicação da sua equipe, e tem como bônus, a vantagem de que

pelo menos uma vez por dia todos irão estar reunidos em um horário certo.



2) SPRINTS. Tente criar o conceito de sprints, definindo "deadlines" a cada 2

semanas ou 1 mês e mantenha fixo até a implantação por completo.

3) PRODUCT BACKLOG. Defina o seu primeiro product backlog. Tente levantar as

funcionalidades que precisam ser feitas, priorize e discuta cada uma, criando

estimativas e definições de finalizado.

4) CRIE UM TASKBOARD. Um simples local onde você tem as suas tarefas em

"todo", "doing" e "done" já é um bom começo para ter o seu termômetro do status do

projeto. Agregue valor com o tempo (stories, burndown, impedimentos, tarefas nãoplanejadas, etc).

5) RETROSPECTIVAS. Ao final de um sprint, use o taskboard como repositório e

faça uma retrospectiva com sua equipe. Veja o que foi bom, o que poderia ser

melhorado e no que vocês irão focar para melhorar. Detalhe: faça dessa reunião

algo bem informal, compre uns salgadinhos e refrigerantes.

A implantação do SCRUM pode ocorrer de dois modos: pelo jeito "bottom-up"

ou pelo jeito "top-down". Bottom-up seria você começando diretamente com a sua

equipe e com isso mostrando ao seu chefe os resultados das práticas ágeis. Top-

down é o inverso, ou seja, você vende a idéia para o seu chefe e depois tenta

vender para sua equipe.

Ambas são eficientes, e dependem do seu ambiente de trabalho. A TSL optou

pelo Top-down.



4. CONSIDERAÇÕES FINAIS

É notório que método tradicional de projetos está consolidado no mercado e

os resultados de sua aplicação são evidentes nos diversos ambientes. Para as

organizações mais conservadoras, existe a possibilidade de mesclar as

características dos métodos tradicionais e ágeis permitindo uma avaliação gradativados pontos positivos e negativos das duas abordagens.

Um dos desafios das metodologias ágeis deve ser o de implementar

estratégias de gestão de riscos sem tornar a metodologia complexa e pesada. Outro

desafio é fazer com que as metodologias ágeis possam ser utilizadas em grandes

empresas e equipes, eliminando os problemas de comunicação interna às equipes e

existentes de forma comum em grandes empresas onde os funcionários estejam

dispersos geograficamente. Apesar de verificar-se um crescimento no uso das metodologias ágeis, ainda

não puderam ser verificados casos de sucesso de seu uso em projetos grandes e

críticos. Torna-se necessário, então, uma maior adoção das organizações na sua

utilização, para que melhores sejam os resultados empíricos em termos de

vantagens, desvantagens e riscos.

Por ser um ambiente de desenvolvimento dinâmico, em constantes

mudanças e menos orientado a documentação, a Web torna-se mais adequada paraa utilização das metodologias ágeis do que as metodologias tradicionais. A utilização

de SCRUM em projetos ajuda a construir tão somente aquilo que o cliente valoriza,

contribuindo para que os produtos sejam criados mais adaptados ao cliente.

As equipes tornam-se mais efetivas na definição das atividades, gerando

maior comprometimento, motivação e confiança. Há um maior estímulo à

colaboração entre os membros da equipe, o que permite que o time esteja mais

coeso, na medida em que cada membro sabe o que os demais estão fazendo, torna-

se natural o compartilhamento e disseminação do conhecimento, cada pessoa da

equipe escolhe o que vai fazer, as responsabilidades estão visíveis, existe



transparência e alinhamento para atender o objetivo do projeto. Toda a equipe passa

a ter conhecimento daquilo que está sendo construído e com que finalidade.

O uso de SCRUM não é difícil. Contudo, torna-se mais importante fazer com

que o time, o cliente e a organização estejam prontos para as mudanças de

paradigmas que a metodologia ágil é capaz de proporcionar. A ausência ou a falta

de uma cultura organizacional que esteja comprometida com o planejamento e

acompanhamento de projeto pode prejudicar a qualidade no produto final dos

projetos.

Este trabalho apenas introduziu brevemente alguns comentários sobre os

métodos tradicional e ágil de gerenciamento de projetos com o intuito de permitir que

parâmetros que auxiliem na definição da melhor estratégia venham a serestabelecidos e aplicados no gerenciamento de projeto, permitindo às organizações

atender as necessidades e expectativas do cliente.

4.1. A VIABILIZAÇÃO DO ESCRITÓRIO DE PROJETO ÁGIL

As organizações visualizam no Project Management Office (PMO –

Escritório de Gerenciamento de Projetos) a solução dos seus problemas. É bem

verdade que o PMO pode vir a assumir muitos produtos e serviços potenciais,

porém, esta posição estará sempre relacionada às necessidades da organização e

da visão e comprometimento de seu patrocinador. O PMO é responsável por adquirir

e implementar a metodologia de gerenciamento de projetos que será utilizada por

toda a organização durante a execução de cada um de seus projetos.O Escritório de Gerenciamento de Projetos acrescenta valor significativo e

traz vários benefícios, basta observarmos o item 2.3, deste. Sob esta ótica, é

interessante observar que “os projetos reúnem e vendem conhecimento”, ficando

facilitada a centralização dos conhecimentos adquiridos ao longo dos projetos, e que

as melhores práticas de um projeto específico podem ser reutilizadas em projetos

futuros.

Os tradicionais escritórios de gerenciamento de projetos são responsáveis

por prover controles e equilíbrio para o desenvolvimento e organizações de TI

quanto aos orçamentos e calendário dos projetos. A supervisão e gestão que vem



do PMO direciona determinados comportamentos em gestores de projetos e,

portanto, no projeto.

Do mesmo modo, um PMO Ágil prevê certos controles e equilíbrio, mas

incide principalmente sobre o bem-estar global do projeto. Esta diferença de "tom",

não só direciona diferentes comportamentos, mas também pode contribuir para

apoiar a transformação radical no seio da organização. A força motriz torna-se

encapsulada na diferença de perspectiva entre tradicionais ganhos de valor

inquiridos e do valor inquirido pela agilidade alcançada.

A diferença chave é estabelecida em uma visão centrada no projeto para a

abordagem tradicional em oposição a uma visão centrada no produto para a

abordagem ágil. A visão tradicional refere-se ao ato de completar o plano do produtoe a visão ágil obviamente refere-se ao produto. Para entender melhor esta diferença

é preciso garantir que compreendemos as motivações por trás das ações e decisões

que cada PMO possui. Por isso, é preciso olhar para algumas das características

específicas de cada escritório de projetos (tradicional e ágil).

Nas organizações que utilizam metodologias tradicionais dirigidas ao

planejamento para executar seus projetos, há geralmente um PMO para

proporcionar uma fonte de controle e equilíbrio. Nestas organizações, o PMO torna-se a força mais influente da organização com relação à execução de programas e a

abordagem por que são realizadas. No sentido clássico de “você é o que você

mensura”, quando o PMO solicita que os gerentes de projeto cheguem à revisão

preparados para discutir orçamento, o progresso e os trabalhos realizados até à data

- as variáveis essenciais para cálculos de valor agregado – os gerentes de projeto

começarão a centrar suas atividades e suas equipes sobre estas medidas.

É notório que o papel do escritório de projeto não deve ser limitado pelaestrutura da empresa. No entanto, conforme afirmado no tópico 2.3.1, deste, as

organizações possuem suas estruturas “enxutas” e não tendem “incharem” seus

quadros para que um determinado projeto, ou seja, um grupo de tarefa temporária e,

que será desfeito após – característica do projeto. Porém, quando tratamos de uma

empresa com maturidade e que possui um escritório de projeto a adequação aos

valores do projeto ágil torna-se interessantes mesmo quando não trata-se de

desenvolvimento de software.

Em última análise, o resultado do cálculo que será agregado, e do efeito

desta metodologia para uma empresa onde as tarefas do PMO, podem ser



visualizadas com boa rentabilidade. O ciclo de vida ágil para um PMO, onde

normalmente tendem a acúmulo de funções, favorece a organização com benefícios

relacionados ao tempo dos seus recursos humanos, do quadro administrativos, bem

como na organização como um todo.

4.2. PROPOSTA DE PESQUISAS FUTURAS

Por motivos anteriormente apresentados neste trabalho, torna-se necessário

a continuidade da pesquisa e avaliação de vários outros ambientes em que

poderiam ser implementadas as metodologias aqui estudadas. É preciso validar a

aplicabilidade e viabilidade das práticas aqui apresentadas em organizaçõesdesenvolvedoras de software pelo regime de contratação de mão-de-obra

especializada e externa às organizações.

Este trabalho de conclusão de curso concentrou-se em entender os

fundamentos teóricos entre o PMBOK e a metodologia SCRUM , entende-se então,

que é necessário primeiramente identificar e fundamentar as ferramentas ágeis em

nossa língua pátria pela literatura. Posteriormente é necessário entender as práticas

ágeis e seus reflexos nas organizações. Assim sendo, após as ferramentas serem bem definidas, seus aspectos

documentados e ainda adotados na nossa literatura, caberá a viabilidade de

entender as diferenças possíveis em nossa cultura e entender os casos de sucesso

como a Globo.com, Microsoft, Google, Nokia, BBC, UOL, entre outras (SILVEIRA,

2009).

Dentre as propostas também é viável a possibilidade de entender como as

ferramentas orientadas á objeto como a UML (Unified Modeling Language), poderádesenvolver informações de framework no processo de gerenciamento com Scrum.

Apesar de consciência que as ferramentas para área de TI são como o ideal

de um projeto: único e temporários. Cabe ainda, ressaltar que em desenvolvimento

de software deve-se lembrar da motivação que levaram a criação de metodologias e

modelos de desenvolvimento, bem como o populismo do modelo cascata. Muitos

desenvolvedores de software, sejam por experiência própria ou ainda, por terem

aprendido nos banco acadêmicos, trazem consigo o conceito do “codifica -remenda”,

onde saía-se desesperadamente programando ao longo do projeto. Pois por muitas

vezes por alteração de escopo ou por novas iterações, fez necessário repensar todo



o projeto e conseqüentemente o software. Com isso não se tinha muita

previsibilidade e os projetos estouravam orçamento, prazo, escopo, etc

frequentemente.

Nesta época, não existia uma boa definição de “papéis” e todos faziam um

pouco de tudo - às vezes uma única pessoa analisava, codificava e testava um

módulo inteiro. Tudo com o objetivo e excluir problemas causados pelo famoso

método “codifica-remenda”. Após esta fase é que foram criadas as metodologias

conhecidas como “tradicionais”. Cabe então, além de documentar e entender,

quanto à relação com a nossa cultura, para posteriormente debater se a metodologia

ágil terá os mesmos problemas de 1995 (muito re-trabalho, alto custo de

manutenção, falta de lisura no processo, faz aqui e estraga ali, etc). Neste ponto devista, pode-se também abrir outra linha de pesquisa que poderá verificar quanto a

área de atuação da engenharia de software, a metodologia ágile, mais

especificamente o Scrum traz ou não re-trabalho? Ou ainda, poderia repensar em

um processo não tão dinâmico, porém, com uma estrutura mais rápida como é a

proposta do Scrum?

4.3. O TRABALHO

A ausência de material impresso em nossa língua pátria representou uma

dificuldade a mais, fazendo com que o autor tivesse que recorrer à busca na Internet

por material em língua estrangeira, o que também foi um dos fatores para este

trabalho.

Dentre as constatações dos objetivos, pode-se evidenciar que não hánenhuma referencia no PMBOK que proíba o uso de práticas ágeis, conforme fora

identificado no capitulo 2, deste não existe uma única forma de vida ideal do projeto

e para a própria organização (PMBOK, 2004, p. 20).

Na abordagem ágil as exigências de desenvolvimento podem mudar em

algum ponto. Isto é bom em um ponto de vista de desenvolvimento, mas o

gerenciamento de mudanças do escopo é também utilizado para beneficiar o cliente.

O patrocinador do cliente concordou em financiar o projeto, baseado em receber

uma determinada solução, por um determinado custo em uma determinada data. Se

a equipe do projeto continuar a aceitar as mudanças do escopo por conta própria, o



projeto poderá requerer mais tempo e um custo muito mais elevado do que o

concordado pelo patrocinador.

Sobre os trabalhando com projetos SCRUM tem as seguintes fases/etapas

identificadas: (i) Visão do Produto; (ii) Product Backlog ; (iii) Estimativa do Product

Backlog ; (iv) Planning Meeting I e II; (v) Execução da Sprint ; (vi) Reunião Diária; (vii)

Reunião de Revisão; e, (viii) Reunião de Retrospectiva. Ao constatar estas fases

pode-se correlacioná-las com o PMBOK, tendo que entender as ferramentas

existentes e adaptá-las a sua realidade, para que o valor entregue ao cliente, não

seja inalcançados.



5. REFERÊNCIAS BIBLIOGRÁFICAS

ANDERSON, D. J; SCHRAGENHEIM, E. Agile Management for SoftwareEngineering: Applying the Theory of Constraints for Business Results. Prentice Hall,2003.

ANDRADE, M. M. de. Introdução à Metodologia do Trabalho Científico. São Paulo: Atlas, 1996.

BOEHM, B. W; TURNER R. Balancing Agility and Discipline. Boston; Addisonwesley, 2002.

CORRÊA, Henrique L; CORRÊA, Carlos A. Administração de Produção e Operaçõesmanufaturas e Serviços: Uma abordagem estratégica. 2 ed. – São Paulo: Atlas 2007 – 2ª Reimpressão. 690p.

CHIAVENATO, Idalberto. Introdução Geral da Administração: uma visão abrangenteda moderna administração das organizações. 3 ed. rev. e atualizada. – Rio deJaneiro: Elsevier, 2004 – 2ª Reimpressão. 494p.

FIGUEIREDO, A.M., Gerenciamento de Projetos Ágeis, Golden Cross, 2007.

HIGHSMITH, J., Agile Software Development Ecosystems, 1.ed., Boston, Addison

Wesley, 2002. 467p. Agile Project Management, Creating Innovative Products, Addison Wesley, 2004.385p.

KERLINGER, Fred N. Metodologia da pesquisa em ciências sociais: um tratamentoconceitual. São Paulo: EPU/EDUSP, 1980.

KERZNER, H. Project Management: A system approach to planning scheduling andcontrolling. John Wiley & Sons, 2002. 331p.

KOTTER, J.P. (2001) - The New Rules: How to Succeed in Today’s Post-Corporate

World. 204p.

LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Metodologia Científica. 1. ed.São Paulo: Atlas, 1983.

LARMAN, Craig. Agile and iterative development: a manager`s guide. 1ª ed. Boston, Addison Wesley, 8ª reimpressão. 2007. 342p.

LEWIS, James P..Como Gerenciar Projetos com Eficácia. Rio de Janeiro: Campus,2000. 150p.

MANSUR, Ricardo. Escritório Avançado de Projetos na Prática: Plano de negócio: amáquina de fazer dinheiro. 1ª ed. – Rio de Janeiro: Brasport, 2009. 420p.



MENEZES, Luis César de Moura. Gestão de Projetos. 2ª ed. São Paulo; Atlas, 2003.246p.

MINAYO, Maria Cecília de Souza. O Desafio do Conhecimento. São Paulo:

Hucitec,1993.

PHILLIPS, Joseph. Gerência de Projetos de Tecnologia da Informação. Rio deJaneiro, Elsevier, 2003. 480p.

PRADO, Darci Santos do. Gerência de Projetos nas organizações. Belo Horizonte.Editora de Desenvolvimento Gerencial, 2003. 258p.

PROJECT MANAGEMENT INSTITUTE (2004) – A Guide to the Project ManagementBody Of Knowledge – PMBoK Guide. 3ª ed. Pennsylvania, USA. 405p.

ROCHA, Klinger Menezes de Holanda. Gerência de Projetos: uma visão emconformidade com o PMI – PMBOK Guide 2000 . Dez 2003.

SALLES JÚNIOR, Carlos Alberto Correa. Et al. Gerenciamento de Risco emProjetos. 5ª reimpressão 2008. – Rio de Janeiro: Editora FGV, 2006. 160p.

SALOMOM, Délcio Vieira. Elementos de Metodologia do Trabalho Científico. 4. ed.Belo Horizonte: Intervivos, 1974.

SHORE, James; WARDEN, Shane. A Arte do Desenvolvimento Ágil. 1ª ed. – Rio deJaneiro. Editora Alta Books. 2008. 420p.

VARGAS, R. (2005) – Gerenciamento de Projetos: Estabelecendo DiferenciaisCompetitivos. BRASPORT. 6ª Edição. Rio de Janeiro. 276p.

5.1. REFERÊNCIAS ELETRÔNICAS

BEHRENS, P., Trail Ridge Consulting. Agile Project Management (APM) ToolingSurvey Results. Disponível em : <http://www.trailridgeconsulting.com/files/2006.AgileToolingSurveyResults.pdf>.2006, acessado em Jun. 2009.

FERREIRA, Aurélio Buarque de Holanda. Dicionário da Língua Portuguesa. 2002.Disponível em: http://www2.uol.com.br/aurelio/, acessado em Dez. 2009.

http://www2.uol.com.br/aurelio/






GELBWAKS, M. The Agile PMO. Disponível em : <http://www.agilejournal.com/articles/articles/the-agile-pmo.html>. Agile Journal,acessado em Fev. 2009.

HIGHSMITH, Jim. Agile Project Management: Principles and Tools. 2003.Disponível em: <http://www.cutter.com/offers/APM.html>. Acessado em: Fev 2009.

LESSA, L., PMI-MG. O Papel do PMO nas Estruturas Organizacionais. Disponível em: <http://www.pmimg.org.br/Geral/visualizadorConteudo.aspx?cod_areaconteudo=423>. 2006, acessado Jan. 2009.

Manifesto for Agile Software Development. Agile Manifesto. Disponível em :http://www.agilemanifesto.org/. 2001, acesso em Dez 2008.

QUELHAS, O.; BARCAUI, A. B. Escritórios de Gerenciamento de Projetos emOrganizações Atuantes no Brasil. Disponível em : <http://www.bbbrothers.com.br/scripts/Artigos/Artigo%20Perfil%20PMO.pdf>. 2004,acessado em Maio 2008.

SILVEIRA, Antonio Carlos. Agile Software Development . Disponível em:<http://www.slideshare.net/acarlos1000/Scrum-agile-development-intro-campus-party-2009-presentation>,acesso em OUT 2009.

STANDISH GROUP INTERNACIONAL. Disponível em : <http://findarticles.com/p/articles/mi_m0EIN/is_2003_March_25/ai_99169967>.Latest Standish Group chaos report shows project success rates have improved by50%. 2003, acessado em nov. 2008.

VERAS, Ronaldo Cisneiros. Comunicação Ágil com Scrum. Disponível em :<http://www.infoq.com/br/articles/comunicacao-com-Scrum>, acesso em: Out 2009

VersionOne. Development’ Survey. Disponível em : <http://www.versionone.com/agilesurveyresults.asp>, 2 ND Annual ‘State of Agile.2007, acessado em Dez. 2008.

WTHREEX. Melhor Prática: Desenvolva Iterativamente. Disponível em : <http://www.wthreex.com/rup/manuals/intro/im_bp1.htm>, acessado em Set. 2008.



ANEXO A - Visão geral da Metodologia de Gestão de Projetos

Convém ressaltar que o gerente de projetos por si só, não garante o sucessode nenhum projeto, porém, sua competência e habilidade para aplicar boas técnicas

induzem a resultados mais sólidos. Pode-se afirmar que as habilidades do gerente

são inerentes não só à reunião de conhecimentos adquiridos com o tempo, ou seja,

à experiência empírica do profissional, mas também à capacidade para utilizar a

metodologia e as ferramentas da gestão de gerência de projeto.

Sobre as áreas de conhecimento de gerência de projeto o PMBOK (2000),

define as seguintes áreas: (i) Gerência de integração do projeto; (ii) Gerenciamentodo escopo do projeto; (iii) Gerenciamento dos tempos do projeto; (iv) Gerenciamento

dos custos do projeto; (v) Gerenciamento da qualidade do projeto; (vi)

Gerenciamento de recursos humanos do projeto; (vii) Gerenciamento das

comunicações do projeto; (viii) Gerenciamento dos riscos do projeto; (ix) e,

Gerenciamento de aquisições do projeto.

Figura: Áreas de conhecimento (fonte: ROCHA, 2003)

Iníci o d e um proj eto

Iniciar um projeto, nada mais é do que o reconhecimento oficial da

necessidade de ser implementado um produto ou tecnologia nova ou aprimoramentodo existente, por imposição legal ou do mercado consumidor. De acordo com o

PMBOK (2000 apud ROCHA, 2003), os projetos acontecem como resultados de

uma dentre as necessidades ou demandas: (i) demanda do mercado; (ii)

necessidade empresarial; (iii) avanço tecnológico; (iv) exigência legal; e/ou (v)

necessidade social.

Este processo de reconhecimento faz parte da área do conhecimento

“ESCOPO”, onde são definidas as metas do projeto. Rocha (2003) afirma que nestafase, devemos seguir a regra “SMART” (Specifc – especifico, Measurable –

Escopo TempoIntegração

Custo RHQualidade

Comunicação Risco Aquisição





A “QUALIDADE” é planejada mesmo antes do início do processo do projeto,

para que se satisfaça a expectativa dos patrocinadores e dos stakeholders.

Os “RECURSOS HUMANOS” que serão necessários para atender aos

objetivos, devem ser identificados na fase de planejamento, para evitar

qualquer problema com questões como alteração no custo e atrasos no

projeto.

Por último, não menos importante, devem-se identificar os “RISCOS”. Ao fixar

o planejamento é possível identificar um possível impacto negativo. Este

impacto poderá desestabilizar o projeto e esta fase deverá principalmente

descobrir como extirpá-lo, ou caso não seja possível amenizar qualquer

impacto.

Determinando o planejamento, são iniciadas as “AQUISIÇÕES” ou contratos

necessários para que o projeto possa transcorrer dentro de uma normalidade

possível.

Execução do pro jet o

A execução do projeto resume-se em colocar o planejamento em ação,

visando a atender aos objetivos. Na fase de execução, a área de conhecimento deintegração, qualidade, recursos humanos, e comunicação são essenciais.

Entre as etapas da execução Rocha (2003) comenta:

A “INTEGRAÇÃO” deve ligar as outras áreas para que tudo possa

ocorrer dentro do previsto.

Os “RECURSOS HUMANOS” formam as equipes dispondo de

habilidades diferentes uns dos outros, são focos e pensamentos

diferenciados o que torna esta uma etapa de grande complexidade degerenciamento para o Gerente de Projeto.

A “COMUNICAÇÃO” cumpre, nesta fase, seu principal papel, pois

dependerá da comunicação a fim de que os patrocinadores do projeto

fiquem sabendo do andamento e de um possível desvio de meta que

possa vir a comprometer ou não o resultado do projeto. A comunicação

também manterá os stakeholders envolvidos informados em tempo

hábil, para que não haja nenhum problema com fornecimento de

material ou decisão atrasada em relação à falta de dados. Isso poderá



acontecer utilizando-se desde a forma verbal até relatórios em mídia ou

formal.

A “AQUISIÇÃO” trata-se de uma fase de cumprimento de propostas e

contratos, obtendo as respostas dos fornecedores, sejam de produtos

e/ou serviços.

Cont ro le do pro jeto

O projeto deve ser monitorado de forma integral, principalmente quanto à

questão prazos, e ainda para que o tempo não passe a ser mais importante de que

outra área. Um exemplo que se pode relatar dos fatos comuns a projetos, é que

quando este tende a atrasar, o gerente para cumprir os prazos estipulados, tendetambém a ultrapassar o custo com novas contratações ou aquisições.

Controlar consiste em coletar dados para fiscalizar o desempenho em relação

ao planejamento. Isto poderá ser feito analisando variações do plano do projeto,

decidindo se as ações corretivas se fazem necessárias para que o desempenho

aconteça de acordo com o planejado, e decidir principalmente se o plano necessita

de ajustes (ROCHA, 2003).

Sobre a fase de controle Rocha (op. cit.) cita:1- A “INTEGRACÃO” faz parte desta fase com o propósito de

implementar as políticas organizacionais e seus relacionamentos

dentro da estrutura do projeto e da empresa. A preocupação principal

da integração é coordenar as mudanças através do ciclo do projeto.

2- Nesta fase deve existir também um controle implícito dos “RISCOS”,

para “virtualizar” os impactos antes que estes ocorreram. A atividade

de controle do risco deve ser voltada ao controle do conhecimento daárea do “ESCOPO”, para não haver mudanças no custo ou tempo e

principalmente no próprio produto do projeto.

3- O “TEMPO” e o “CUSTO” são etapas verificadas com maior f acilidade

na fase de controle, pois estes conhecimentos, normalmente são

demonstrados por intermédios de ferramentas gráficas, que facilitam

muito o controle.

4- A “COMUNICAÇÃO” na fase de controle é um instrumento de grande

valia, pois através dela é possível precisar o andamento dos processos

do escopo, cronograma, custo e a qualidade.



5- A “QUALIDADE” é um processo técnico de acordo com o produto que

é na verdade o escopo do projeto, que deve ser mensurado em seus

atributos e características, relatando a probabilidade de algo acontecer.

6- A gestão de “RISCO” é um processo para manter a equipe informada

sobre qualquer anormalidade, seja esta negativa ou ainda uma

oportunidade residual ou não, envolvendo plano de contingência,

ações corretivas ou replanejamentos.

Encerramento d o pro jeto

Normalmente esta fase acaba sendo negligenciada pelas equipes de

gerenciamento de projeto, tornando-se o novo produto rotineiro dentro da empresa.O encerramento, no entanto, é uma fase importante onde as maiorias dos

stakeholders tomam conhecimento oficialmente desta etapa e poderão desfrutar do

novo produto na sua integridade.

A fase de encerramento deve acontecer com uma “COMUNICAÇÃO” oficial e

bem documentada revelando o encerramento administrativo. Também ocorre o

encerramento dos possíveis contratos em andamento e das “AQUISIÇÕES”

realizadas. Alguns contratos têm condições específicas e devem ser encerradosoficialmente, principalmente os que envolvem os “RECURSOS HUMANOS”.

Fonte BIBLIOGRÁFICA

ROCHA, Klinger Menezes de Holanda. Gerência de Projetos: uma visão em

conformidade com o PMI – PMBOK Guide 2000 . Dez 2003.

Documents

Gerenciamento de Projeto Auxiliado Pelo Scrum