Gesto de

projetos

Aplicada Web

Professor
Joo Carlos Carib
caribe@entropia.blog.br
Introduo 4
Histria da Gerncia de Projeto 5

Gesto de projetos na prtica 6

Anatomia de um projeto 7
Variveis controlveis e incontrolveis 8
Variveis controlveis ou previsveis 8

Variveis incontrolveis ou imprevisveis 8

As variveis do tringulo de gerncia de projeto 9

Tempo ou prazo 9

Custo 9

Escopo ou contexto 9

Caminho crtico 10
Relacionamento entre tarefas 10

Plano de contingncia 11
Princpio de Pareto 12

Etapas de um projeto 12
Ciclo de monitoramento e controle 13

Abordagens em gesto de projeto 13

Abordagem tradicional 13

Desenvolvimento gil de software 15

SCRUM 15

Caractersticas de Scrum 16
Backlog de produto e backlog de sprint 17

Planejamento de sprint 17

Scrum simplificado 17

Algumas caractersticas de Scrum 18

 Agendando discusses dirias 18

Scrum Solo 18

Gesto do conhecimento em gesto de projetos 19

Mind maps 19

Tecnologias disponveis 20
Para uso no computador 20
Microsoft Project 20

Serena Open Project 20

Para uso online 20

Serena Projects on demand 20

dotProject 20

Tecnologias auxiliares 20
Mindmeister 20
Introduo
Gerncia de projetos ou gesto de projetos a aplicao de conhecimentos,
habilidades e tcnicas na elaborao de atividades relacionadas para atingir um
conjunto de objetivos pr-definidos. O conhecimento e as prticas da gerncia de
projetos so mais bem descritos em termos de seus processos componentes.

Esses processos podem ser classificados em cinco grupos de processo (iniciao,

planejamento, execuo, controle e encerramento) e nove reas de conhecimento
(gerncia de integrao de projetos, gerncia de escopo de projetos, gerncia de
tempo de projetos, gerncia de custo de projetos, gerncia de qualidade de projetos,
gerncia de recursos humanos de projetos, gerncia de comunicaes de projetos,
gerncia de riscos de projetos e gerncia de aquisies de projetos).

Reduzida sua forma mais simples,

a gerncia de projetos a disciplina
de manter os riscos de fracasso em
um nvel to baixo quanto
necessrio durante o ciclo de vida do
projeto. O risco de fracasso aumenta
de acordo com a presena de
incerteza durante todos os estgios
do projeto. Um ponto-de-vista
alternativo diz que gerenciamento
de projetos a disciplina de definir e
alcanar objetivos ao mesmo tempo
em que se otimiza o uso de recursos
(tempo, dinheiro, pessoas, espao,
etc).

A gerncia de projetos freqentemente a responsabilidade de um indivduo

intitulado gerente de projeto. Idealmente, esse indivduo raramente participa
diretamente nas atividades que produzem o resultado final. Ao invs disso, o
gerente de projeto trabalha para manter o progresso e a interao mtua
progressiva dos diversos participantes do empreendimento, de modo a reduzir o
risco de fracasso do projeto.

pgina 4
Histria da Gerncia de Projeto
Como uma disciplina, a gerncia de projeto foi
desenvolvida de diversos campos de aplicao
diferentes, incluindo a construo, a engenharia
mecnica, projetos militares, etc. Nos Estados
Unidos, o 'pai da gerncia de projeto Henry Gantt,
chamado o pai de tcnicas do planejamento e do
controle, que conhecido pelo uso do grfico de
'barra' como uma ferramenta de gerncia do
projeto, para ser um associado as teorias de
Frederick Winslow Taylor da administrao
cientfica, e para seu estudo do trabalho e da
gerncia do edifcio do navio da marinha.

Seu trabalho o precursor a muitas ferramentas de

gerncia modernas do projeto, tais como a WBS Grfico de Gantt
(work breakdown structure) ou EAP1 (estrutura
analtica do projeto) de recurso que avalia o
trabalho.

Os anos 50 marcam o comeo da era moderna da gerncia de projeto. Outra vez, nos
Estados Unidos, antes dos anos 50, os projetos foram controlados basicamente se
utilizando os grficos de Gantt, tcnicas informais e ferramentas. Nesse tempo, dois
modelos programando do projeto matemtico foram desenvolvidos:

1) de 'Program Evaluation and Review Technique' ou o PERT 2, desenvolvido como

a parte programa do mssil do submarino Polaris da marinha dos Estados
Unidos' (conjuntamente com o Lockheed Corporation); e o

2) 'Critical Path Method' (CPM) desenvolvido em conjunto por DuPont Corporation

e Remington Rand Corporation para projetos da manuteno de planta.

Estas tcnicas matemticas espalharam-se rapidamente em muitas empresas. Em

1969, o Project Management Institute (PMI3) foi dando forma para servir ao
interesse da indstria da gerncia de projeto.

A premissa de PMI que as ferramentas e as tcnicas da gerncia de projeto so

terra comum mesmo entre a aplicao difundida dos projetos da indstria do
software indstria de construo. Em 1981, os diretores do PMI autorizaram o
desenvolvimento de o que se transformou em um guia de projetos o 'Project
Management Body of Knowledge'4, contendo os padres e as linhas mestras das
prticas que so usados extensamente durante toda a profisso.

1 http://pt.wikipedia.org/wiki/EAP
2 http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique
3 http://www.pmi.org
4 http://pt.wikipedia.org/wiki/PMBOK
pgina 5
Gesto de projetos na prtica
Embora no percebamos, estamos o tempo todo planejando. Planejar faz parte da
existncia humana, qualquer um planeja, vejamos:

Atravessar a rua exige planejamento?

Pegar nibus exige planejamento?
Paquerar exige planejamento?

Sendo voc um ser racional, voc planeja, ou por acaso atravessa a rua sem prestar
ateno no sinal, ou sem avaliar a distncia e velocidade dos carros? Voc pega
qualquer nibus? E na hora de paquerar, chega de qualquer jeito ou prefere antes
observar e ver como vai chegar junto?

Estamos o tempo todo avaliando

risco, e avaliar riscos significa
avaliar os riscos e as chances.
Apesar do nome avaliar riscos
tambm avaliar as chances.
Estamos o tempo todo avaliando
diversos fatores em nossas
tomadas de deciso, na paquera
avaliamos o contexto, as pessoas
que esto prximas a nossa
vitima. Depois e em geral
tentamos um gesto que sirva para
sondar a nossas chances. Se tudo
der certo tentamos uma
abordagem direta.

Veja que isto esta no nosso DNA,

somos seres planejadores, quando
deixamos de planejar o fazemos
por puro livre arbtrio, ou na pior
das hipteses por pura
imaturidade, desconhecimento ou
limitaes.

Crianas abaixo de dez anos no conseguem avaliar elementos variveis como a

velocidade e distncia dos carros, por isto nunca devem atravessar a rua sozinhas,
mas agem assim por imaturidade. Um portador de deficincia visual, no consegue
pegar um nibus sozinho porque possui limitaes fsicas que o impedem de fazer
isto sozinho. Um analfabeto tambm no consegue distinguir duas linhas de nibus
da mesma empresa de transportes, pois lhe falta conhecimento para identificar as
siglas numricas que representam cada linha, mas mesmo assim conseguem
contornar esta limitao decorando o smbolo numrico que representa a linha de
nibus.

pgina 6
Anatomia de um projeto
Para explicar um pouco mais sobre projetos e gesto de projetos, vamos fazer uma
analogia didtica usando como exemplo a atividade de pegar nibus.

Responda algumas perguntas:

Voc pega qualquer nibus?

Se o nibus estiver lotado voc esperar o prximo?
O dinheiro esta trocado? Separado?
Onde existe mais chance de ter um lugar livre?
Meu ponto esta chegando, preciso me dirigir saida?

Provavelmente voc no pega qualquer nibus,

decide o nibus a pegar em funo de diversas
variveis como por exemplo:

Qual nibus pegar depende do trajeto, pode ser

para onde voc deseja ir s tenha uma linha de
nibus ou pode ser que praticamente todos
passem no seu destino.

Se voc for uma pessoa com hbitos pr-

ativos5, deve estar com tempo suficiente para
ch e g a r a o s e u d e s t i n o a t o h o r r i o
programado e pode se dar ao luxo de aguardar
o nibus mais vazio passar.

Quem utiliza dinheiro para pagar a passagem,

costuma ter mo dinheiro trocado, e
separado para pagar a passagem, assim evita
que a fila fique engarrafada esperando voc Pintura de Joo Werner
pagar, e no costuma chamar ateno para o
dinheiro que tem em sua carteira.

Ao entrar no nibus, caso ele esteja cheio, voc costuma se deslocar para o fundo 6,
prximo sada de forma que fique mais fcil para descer, e onde existe maior
probabilidade de algum levantar e voc conseguir sentar.

Estas variveis dependem de diversos fatores, inclusive caractersticas fsicas do

nibus e o fato de conhecer as pessoas que pegam diariamente, assim fica mais fcil
saber quem desce onde e quando, e se posicionar com preciso prximo pessoa
onde existe maior chance de voc sentar.

Isto se aprende no ciclo de projetos, no caso andar de nibus, e onde os

conhecimentos so transformados e registrados, confirmando a mxima de que a
prtica leva perfeio.

5 pr-ativo aquele que toma as iniciativas, que procura formas de resolver um problema de forma positiva
6 No Rio de janeiro a maioria dos nibus possui a sua sada na parte traseira.
pgina 7
Variveis controlveis e incontrolveis
Dentro de um ambiente de projetos, e at mesmo no seu dia-a-dia existem variveis
que podem ser controladas e/ou previstas e outras que no podem ser previstas e/
ou controladas. Um bom planejamento leva ambas em considerao.

Variveis controlveis ou previsveis

Existem variveis previsveis e controlveis no seu ciclo de projeto, so variveis

que voc conhece claramente. Por controlvel entendemos que algo que voc
possa prever e/ou medir.

Por exemplo tempo, valores, recursos so variveis controlveis. Voc no tem

controle sobre o tempo, mas pode considera-lo em seus planejamentos, possvel
calcular o tempo necessrio para executar uma tarefa, mas no se pode extende-lo
por exemplo.

possvel prever os recursos financeiros, e atravs do controle possvel at

mesmo redimensiona-los. possvel aumentar a produtividade de uma tarefa,
otimizando os mtodos e processos utilizados e/ou alocando mais recursos humanos
tarefa.

No nosso exemplo, o valor da passagem e o tempo so variveis controlveis ou

previsveis.

Variveis incontrolveis ou imprevisveis

So variveis que no podemos controlar, em geral

imprevistos, ou atividades que dependam de
terceiros. No nosso exemplo por exemplo no
podemos controlar a hora exata em que o nibus
vai passar no ponto, isto depende por exemplo da
habilidade do motorista e de fatores imprevisveis
do trnsito e do prprio nibus que pode por
exemplo enguiar.

Num planejamento de projeto, levamos em conta

os recursos humanos partindo do principio de que
eles estaro sempre disponveis para trabalhar e
sempre com o mesmo nvel de produtividade, o que no verdade, funcionrios
podem estar desmotivados, e podem faltar, e isto precisa ser levado em conta.

Pode acontecer uma catstrofe, um recurso material pode ser danificado e/ou
utilizado equivocadamente para outra tarefa, isto pode acontecer, assim como pode
faltar determinado material, mas neste caso a falta pode se dar por diversos fatores:

Pode ser que a entrega esteja atrasada, ou que ele tenha sido mal dimensionado, ou
ainda que tenha sido providenciado tarde demais. Mas isto previsvel, voc pode
se informar de todo o processo e considerar o prazo necessrio no seu
pgina 8
planejamento. O que seria imprevisvel neste caso por exemplo seria o roubo ou
danificao de materiais.

Controlar todas as variveis em todas as atividades de um projeto extremamente

trabalhoso, prev-las muito mais difcil, por mais experiente que o gestor de
projetos seja, ele sempre encontrar novas variveis em novos projetos.

As variveis do tringulo de gerncia de projeto

Alguns empreendimentos necessitam ser executados e entregues sob determinadas
variveis. As variveis principais tambm podem ser denominadas como
tradicionais. So eles o escopo, o tempo e o custo. Isto conhecido tambm como
"tringulo da gerncia de projeto", onde cada lado representa uma varivel. Um lado
do tringulo no pode ser mudado sem impactar no outro.

A restrio do tempo influencia o prazo at o termino do projeto. A restrio de

custo informa o valor monetrio includo no oramento disponvel para o projeto. J
a restrio do escopo designa o que deve ser feito para produzir o resultado de fim
do projeto. Estas trs variveis esto freqentemente competindo: o escopo
aumentado significa tipicamente o tempo aumentado e o custo aumentado, uma
restrio apertada de tempo poderia significar custos aumentados e o escopo
reduzido, e um oramento apertado poderia significar o tempo aumentado e o
escopo reduzido. A disciplina da gerncia de projeto sobre fornecer as ferramentas
e as tcnicas que permitem a equipe de projeto (no apenas ao gerente de projeto)
organizar seu trabalho para se encontrar com estas variveis .

Tempo ou prazo

O tempo requerido para terminar as etapas do projeto, normalmente influenciado

quando se pretende baixar o tempo para execuo de cada tarefa que contribui
diretamente concluso de cada componente. Ao executar tarefas usando a
gerncia de projeto, importante cortar o trabalho em diversas partes menores de
modo que seja fcil definirmos condies de criticidade e de folga.

Custo

O Custo para desenvolver um projeto depende de diversas condies iniciais que

possumos para o desenvolvimento de cada projeto tais como: custo de mo de obra,
custos de materiais, gerncia de risco, planta (edifcios, mquinas, etc.),
equipamento, e lucro.

Escopo ou contexto

So as exigncias especificadas para o resultado fim, ou seja, o que se pretende, e o

que no se pretende realizar. A qualidade do produto final pode ser tratada como
um componente do escopo. Normalmente a quantidade de tempo empregada em
cada tarefa determinante para a qualidade total do projeto.

pgina 9
Caminho crtico
Existem atividades em um projeto que so mais importantes que as outras, muitas
dependem de outras de alguma forma e precisam ser executadas porque afetam
sensivelmente a execuo do projeto, estas tarefas so as chamadas tarefas do
caminho crtico.

Relacionamento entre tarefas

Estas dependncias entre as tarefas pode se dar entre uma tarefa e outra, ou entre
vrias tarefas e uma unica tarefa sucessora, ou entre diversas tarefas. Usando a
lgica booleana, as relaes entre as tarefas podem ser de uma para uma, muitas
para muitas, uma para muitas e muitas para uma.

Basicamente existem quatro tipos de relacionamento entre tarefas:

Termino para Inicio (TI) - O inicio de uma tarefa depende da concluso de

outra, ou seja, para que a tarefa inicie, preciso que a outra seja
concluda.
Inicio para Inicio (II) - O inicio de uma tarefa esta relacionada ao inicio de
outra, ou seja, para iniciar a tarefa precisamos que outra inicie tambm.
Termino para Trmino (TT) - O trmino de uma tarefa depende do
trmino de outra. Ou seja as duas tarefas precisam terminar juntas.
Incio para Trmino (IT) - Esta a relao mais rara, mas possvel de
acontecer, ou seja, uma tarefa s pode terminar se outra for iniciada.

Existe ainda a chamada latncia, que significa um tempo adicional nos

relacionamentos de tarefa acima. Por exemplo, na pintura de uma parede, existem
trs tarefas: Aplicao da massa, lixamento da massa e pintura, entretanto existe a
necessidade da massa secar, por exemplo ela precisa de 48 horas para secar
completamente a ponto de ser lixada. Ento o relacionamento entre aplicao da
massa e o lixamento da massa uma relao TI com latncia de 48 horas, ou seja
aps terminar a aplicao da massa preciso esperar 48 horas para lixa-la.

Voc pode aplicar a latncia em todos os tipos de relacionamento de tarefas, por

exemplo pode usar uma relao II com uma latncia de 24 horas, de forma a que
uma tarefa deve iniciar no dia seguinte ao inicio de sua predecessora.

No nosso exemplo do nibus, supondo que tenhamos de pegar dois nibus para
completar o trajeto, pegar o primeiro nibus uma tarefa predecessora para pegar
o segundo, ou seja, a relao
e n t r e p e ga r o p r i m e i r o
nibus e o segundo uma Pegar o primeiro nibus Pegar o segundo nibus
relao TI (trmino para
incio).

As tarefas que no possuem nenhum relacionamento, e isto normal de acontecer,

no fazem parte do caminho crtico e podem ser executadas no momento que for
mais conveniente para o gestor de projetos, em geral so programadas para serem

pgina 10
executadas em momentos de baixa atividade do projeto, para melhor
aproveitamento da mo de obra.

Plano de contingncia
Seria timo se tudo na vida acontecesse como planejado, viveramos num mundo
perfeito, onde tudo daria certo, tudo aconteceria no tempo programado, utilizaria os
recursos alocados, e dentro do custo previsto... Que saco !

A vida seria um tdio, que graa teria? Muitas vezes sonhamos com um mundo
perfeito, mas nos esquecemos que so as imperfeies do mundo que o torna
interessante, que torna a vida desafiadora, dando o seu tempero.

Em gesto de projetos no poderia ser diferente, existe a famosa Lei de Murphi7

que quer dizer o seguinte: Se algo tiver de dar errado, vai dar errado!

Lembre-se das variveis incontrolveis ou imprevisveis, elas esto ai para dar o

tempero do seu projeto. Gestores de projetos costumam considerar margens de
segurana definidas com o apoio de gestores tcnicos que iro executar o projeto.
Por exemplo, aplica-se uma margem de segurana na mo de obra, para cobrir
eventuais faltas e atrasos, e para prover o projeto uma certa margem de manobra
para que atividades de emergncia sejam executadas sem um impacto muito grande
no prazo final do projeto. Aplica-se uma margem de segurana nos recursos
materiais prevendo desperdcios e eventuais danos ou extravios, mas as margens
neste caso devem ser aplicadas com critrio para que a excessiva margem de
segurana em materiais no seja um prejuzo no projeto.

Um projeto bem planejado leva em conta o imprevisto, se alguma coisa der errado, o
projeto vai parar? Pode-se executar outra tarefa enquanto resolvemos o problema
que impede o andamento do projeto? E este problema pode ser simplesmente uma
etapa de aprovao do cliente por exemplo. Neste caso as tarefas que no fazem
parte do caminho crtico podem ser executadas para que a equipe no fique parada
por exemplo.

7 http://pt.wikipedia.org/wiki/Lei_de_Murphy
pgina 11
Princpio de Pareto

O principio de Pareto 8, tambm conhecida pela regra 80-20 se resume em que 80%
dos efeitos so provenientes de 20% das causas. O estudioso de Administrao
Joseph M. Juran identificou o principio que ganhou este nome aps o economista
Italiano Vilfredo Pareto ter observado que 80% da renda Italiana proveniente de
20% da populao. Esta uma regra comum nos negcios, em geral 80% das suas
vendas so provenientes de 20% de seus clientes.

O princpio de Pareto um bom critrio para voc usar no planejamento e anlise do

seu projeto. No estamos falando que a relao ser precisamente 80-20, pode-se
variar entre 90-10 e 70-30, mas geral fica nesta faixa.

Por exemplo 80% do custo do seu projeto esta relacionado 20% das tarefas, ou
80% do prazo esta relacionado 20% das tarefas, e por ai vai. O importante mesmo
identificar no seu projeto quais as tarefas que fazem parte destes 20% e dedicar
uma ateno especial elas.

Etapas de um projeto
Todo projeto desenvolvido em cinco etapas: Iniciao, planejamento, execuo,
controle e concluso

Iniciao a etapa onde tomamos conhecimento do projeto a ser feito, o momento

da confeco do briefing, ou de sua leitura equipe, nesta hora onde surgem
diversas dvidas do projeto. Em geral uma etapa que deve ser desenvolvida em
uma reunio de brainstorm.

Planejamento onde o projeto detalhado, se aplicarmos o principio de Pareto,

onde investimos 80% do nosso tempo. o momento em que detalhamos as
atividades, pesquisamos, determinamos prazos, alocamos recursos e custos. O
resultado do planejamento uma lista de tarefas e/ou um grfico de Gantt.

Execuo o objetivo do projeto, a hora da verdade, quem executa o gestor

tcnico, a hora de colocar o projeto em prtica.

Controle, o gestor do projeto faz o controle da execuo, registrando tempo e

recursos, e gerenciando as possveis mudanas.

Concluso, bom concluso dispensa mais comentrios, a hora em que o projeto

termina.

8 http://en.wikipedia.org/wiki/Pareto_principle
pgina 12
Ciclo de monitoramento e controle

Na verdade as cinco etapas do projeto no acontecem como uma seqncia linear,

afinal como j vimos existem problemas no previstos, existem ajustes serem
feitos. E estes ajustes so feitos on the fly, ou seja, durante a execuo do projeto,
configurando um ciclo claro que passa por execuo, controle e planejamento.

Iniciao planejamento

execuo controle concluso

Geralmente na hora da execuo que o planejamento posto a prova, o controle

o acompanhamento que o gestor de projetos faz junto ao gestor tcnico, ele registra
os tempos e uso de recursos. Este controle pode apontar tanto uma tendncia
economia de recursos quando necessidade de utilizar recursos alem do planejado.
atribuio do gestor de projetos revisar seu planejamento para avaliar os
impactos destas variaes e tomar as devidas providncias.

Abordagens em gesto de projeto

Na indstria de informtica, geralmente h dois tipos de abordagens comumente
utilizadas no gerenciamento de projetos. As abordagens do tipo "tradicional"
identificam uma seqncia de passos a serem completados. Essas abordagens
contrastam com a abordagem conhecida como desenvolvimento gil de software9,
em que o projeto visto como um conjunto de pequenas tarefas, ao invs de um
processo completo. O objetivo desta abordagem reduzir ao mnimo possvel o
overhead. Essa abordagem bastante controversa, especialmente em projetos
muito complexos. Mesmo assim, tem conquistado adeptos em nmeros crescentes.

Nas ltimas dcadas, emergiram uma srie de abordagens na indstria em geral.

Dentre essas abordagens se destaca a abordagem do PMBOK, que tem se tornado
um padro de fato em diversas indstrias.

Abordagem tradicional
Na abordagem tradicional, a que vimos at agora, distinguimos cinco grupos de
processos no desenvolvimento de um projeto:

1. Iniciao
2. Planejamento

9 http://en.wikipedia.org/wiki/Agile_Project_Management
pgina 13
 3. Execuo
4. Monitoramento e Controle
5. Encerramento

Nem todos os projetos vo seguir todos estes estgios, j que projetos podem ser
encerrados antes de sua concluso. Alguns projetos passaro pelos estgios 2, 3 e 4
mltiplas vezes.

O projeto ou empreendimento visa a satisfao de uma necessidade ou

oportunidade, definida no texto acima como fase inicial na qual existem muitas
reas e/ ou pessoas envolvidas. Em geral sempre existe mais que uma soluo ou
alternativas para atender s mesmas necessidades. A tcnica usada para definir a
soluo final passa pelo desenvolvimento de alternativas extremas. A primeira de
baixo custo que atende as necessidades mnimas para ser funcional. A segunda
tenta atender a maior parte das as exigncias das diversas reas envolvidas no
escopo que resulta num projeto com custo muito maior e pouco competitivo. A
partir de ambas as alternativas desenvolvida uma soluo intermediria entre as
mesmas, que atende a uma boa parte das exigncias com um custo competitivo.

Vrios setores utilizam variaes destes estgios. Por exemplo, na construo civil,
os projetos tipicamente progridem de estgios como Pr-planejamento para Design
Conceitual, Design esquemtico, Design de desenvolvimento, construo de
desenhos (ou documentos de contrato), e administrao de construo. Embora os
nomes difiram de indstria para indstria, os estgios reais tipicamente seguem os
passos comuns resoluo de problemas (problem solving): definir o problema,
balancear opes, escolher um caminho, implementao e avaliao.

O gerenciamento de projetos tenta adquirir controle sobre trs variveis:

tempo
custo
escopo

Algumas literaturas definem como quatro variveis, sendo qualidade a quarta

varivel, contudo a qualidade uma das principais componentes do escopo. Estas
variveis podem ser dadas por clientes externos ou internos. O(s) valor(es) das
variveis remanescentes est/esto a cargo do gerente do projeto, idealmente
baseado em slidas tcnicas de estimativa. Os resultados finais devem ser
acordados em um processo de negociao entre a gerncia do projeto e o cliente.
Geralmente, os valores em termos de tempo, custo, qualidade e escopo so definidos
por contrato.

Para manter o controle sobre o projeto do incio ao fim, um gerente de projetos

utiliza vrias tcnicas, dentre as quais se destacam:

Planejamento de projeto
Anlise de valor agregado
Gerenciamento de riscos de projeto
Cronograma
Melhoria de processo

pgina 14
Desenvolvimento gil de software
O desenvolvimento gil de software rene uma srie de metodologias de baixo
overhead. Reconhecem que software algo difcil de controlar. Essas metodologias
minimizam riscos garantindo que os engenheiros de software foquem em unidades
menores de trabalho.

Os mtodos geis diferenciam-se de outras metodologias mais "pesadas" (como por

exemplo, o Modelo Cascata) na nfase que do a valores e princpios, ao invs de
processos.

Ciclos tpicos so de uma semana ou um ms, e no fim de cada ciclo h uma

reavaliao das prioridades do projeto - caracterstica que ele compartilha com
metodologias de desenvolvimento iterativas, e com a maioria das teorias modernas
de gerenciamento de projetos.

SCRUM
um dos mtodos da metodologia gil para gerenciamento de Projetos. Scrum vem
sendo amplamente adotado por empresas como o porta Terra e a Globo.com,
justamente por atender com preciso s necessidades do desenvolvimento de
software e sites.

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos

em empresas de fabricao de automveis e produtos de consumo, por Takeuchi e
Nonaka no artigo "The New New Product Development Game" (Harvard Business
Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes
pequenas e multidisciplinares (cross-functional) produziram os melhores
resultados, e associaram estas equipes altamente eficazes formao Scrum do
Rugby (utilizada para reincio do jogo em certos casos). Jeff Sutherland, John
Scumniotales, e Jeff McKenna documentaram, conceberam e implementaram o
Scrum, como descrito abaixo, na empresa Easel Corporation em 1993, incorporando
estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken
Schwaber formalizou a definio de Scrum e ajudou a implant-lo em
desenvolvimento de software em todo o mundo.

Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka

Takeuchi e Ikujiro Nonaka.

A funo primria do Scrum ser utilizado para o gerenciamento de projetos de

desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim
como Extreme Programming e outras metodologias de desenvolvimento. Porm,
teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas
necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma
escola pequena, projetos de pesquisa cientfica, ou at mesmo o planejamento de um
casamento.

Mesmo que o Scrum tenha sido idealizado para ser usado em gesto de projetos de
desenvolvimento de software, ele tambm pode ser usado para gerenciar equipes de

pgina 15
manuteno, ou como uma abordagem para gesto de programas: Scrum de
Scrums.

Caractersticas de Scrum
Cada sprint uma iterao que segue o ciclo PDCA e entrega um
incremento de software pronto.
Um backlog um conjunto de requisitos, priorizado pelo Product Owner
(cliente);
H entrega de um conjunto fixo de itens do backlog em uma srie de
iteraes curtas ou sprints;
Uma breve reunio diria ou scrum, onde cada participante fala sobre o
progresso conseguido, o trabalho a ser realizado e/ou o que o impede de
seguir avanando (tambm chamado de Standup Meeting, j que os
membros do time geralmente ficam em p).
Uma breve sesso de planejamento, na qual os itens do backlog para uma
sprint (iterao) so definidos;
Uma retrospectiva, na qual todos os membros da equipe refletem sobre a
sprint passada.

O Scrum facilitado por um Scrum Master, que tem como funo primria remover
qualquer impedimento habilidade de uma equipe de entregar o objetivo do sprint.
O Scrum Master no o lder da equipe (j que as equipes so auto-organizadas)
mas atua como um firewall entre a equipe e qualquer influncia desestabilizadora.
Outra funo extremamente importante de um Scrum Master o de assegurar que
a equipe esteja utilizando corretamente as prticas de Scrum, motivando-os e
mantendo o foco na meta da Sprint.

Scrum permite a criao de equipes auto-organizadas, encorajando a comunicao

verbal entre todos os membros da equipe e entre todas as disciplinas que esto
envolvidas no projeto.

Um princpio chave do Scr um o reconhecimento de que desafios

fundamentalmente empricos no podem ser resolvidos com sucesso utilizando uma
pgina 16
abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem
emprica, aceitando que o problema no pode ser totalmente entendido ou definido,
focando na maximizao da habilidade da equipe de responder de forma gil aos
desafios emergentes.

Um dos grandes defeitos do Scrum, porm, a abordagem de "receita de bolo" do

gerenciamento de projetos exemplificado no Project Management Body of
Knowledge ou Prince2, que tem como objetivos atingir qualidade atravs da
aplicao de uma srie de processos prescritos.

Backlog de produto e backlog de sprint

Um backlog uma lista de itens priorizados a serem desenvolvidos para um

software. O backlog de produto mantido pelo Proprietrio do Produto e uma lista
de requisitos que tipicamente vm do cliente. O backlog de sprint uma
interpretao do backlog do produto e contm tarefas concretas que sero
realizadas durante o prximo sprint para implementar alguns dos itens principais
no backlog do produto. O backlog de produto e de sprint so, ento, duas coisas
totalmente diferentes, o primeiro contendo requisitos de alto-nvel e o segundo
contendo informaes sobre como a equipe ir implementar os requisitos.

Planejamento de sprint

Antes de todo sprint, o Proprietrio do Produto, o Scrum Master e a Equipe decidem

no que a equipe ir trabalhar durante o prximo sprint. O Proprietrio do Produto
mantm uma lista priorizada de itens de backlog, o backlog do produto, o que pode
ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo
do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem
executar para terminar. A Equipe ento planeja a arquitetura e o design de como o
backlog do produto pode ser implementado. Os itens do backlog do produto so
ento destrinchados em tarefas que se tornam o backlog do sprint.

Scrum simplificado

Muitas organizaes tm sido resistentes s metodologias introduzidas em baixos nveis

da organizao. Porm, a adaptabilidade do Scrum permite que ele seja introduzido de
forma invisvel ("stealth"), usando os trs passos:

3. Agende uma demonstrao do software com seu cliente em um ms a partir de

agora;
4. Como equipe, tome um ms para deixar o software pronto para uma demo,
com funcionalidades prontas, no simplesmente telas;
5. Na demonstrao, obtenha feedback e use-o para guiar o seu prximo ms de
trabalho de desenvolvimento.

pgina 17
Algumas caractersticas de Scrum

Clientes se tornam parte da equipe de desenvolvimento (os clientes devem

estar genuinamente interessados na sada);
Entregas freqentes e intermedirias de funcionalidades 100% desenvolvidas;
Planos freqentes de mitigao de riscos desenvolvidos pela equipe;
Discusses dirias de status com a equipe;
A discusso diria na qual cada membro da equipe responde s seguintes
perguntas:
O que fiz desde ontem?
O que estou planejando fazer at amanh?
Existe algo me impedindo de atingir minha meta?
Transparncia no planejamento e desenvolvimento;
Reunies freqentes com os stakeholders (todos os envolvidos no processo)
para monitorar o progresso;
Problemas no so ignorados e ningum penalizado por reconhecer ou
descrever qualquer problema no visto;
Locais e horas de trabalho devem ser energizadas, no sentido de que
"trabalhar horas extras" no necessariamente significa "produzir mais".

Agendando discusses dirias

Um momento bom para as discusses dirias depois do almoo. Durante a manh pode
ser complicado. Estas discusses de status no demoram e uma forma eficiente de fazer
estas reunies seria ficar em p e em frente a um quadro negro. Como as pessoas
tendem a ficar cansadas depois do almoo, ter uma viva reunio em p nessa hora
permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando
durante a manh, suas mentes esto focadas no trabalho e no em questes pessoais.

Scrum Solo

Scrum baseado em pequenas equipes. Ele permite a comunicao entre os membros

da equipe. Entretanto, h uma grande quantidade de softwares desenvolvidos por
programadores solos. Um software sendo desenvolvido por um s programador pode
ainda se beneficiar de alguns princpios do Scrum, como: um backlog de produto, um
backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo uma verso
adaptada para uso de programadores solo.

pgina 18
Gesto do conhecimento em gesto
de projetos
Mind maps
Mind maps so excelente ferramentas para planejamento e organizao de idias.
Partem do conceito de que o ser humano tem dificuldade de lidar com listas, apesar
de usa-las diariamente. Mind maps utilizam o mesmo conceito de conexes e
interconexes de ideias que utilizamos naturalmente para gerenciar nosso
conhecimento, desta forma torna-se quase intuitivo para usar.

Mapa mental, mind map ou mapa semntico o nome dado para um tipo de
diagrama, sistematizado pelo ingls Tony Buzan, voltado para a gesto de
informaes, de conhecimento e de capital intelectual; para a compreenso e
soluo de problemas; na memorizao e aprendizado; na criao de manuais, livros
e palestras; como ferramenta de brainstorming (tempestade cerebral); e no auxlio
da gesto estratgica de uma empresa ou negcio.

Os desenhos feitos em um mapa mental partem de um nico centro, a partir do qual

so irradiadas as informaes relacionadas. Eles podem ser feitos com um
programa de computador adequado ou com canetas coloridas e um bloco de papel, e
podem ser usados por todos os profissionais para gerenciar qualquer tipo de
informao. Este mtodo de registro cada vez mais usado por uma srie de
profissionais de todas as reas de conhecimento humano.

Existem diversos programas para construo de mind maps, e inclusive um online

e colaborativo, o Mind Meister em http://www.mindmeister.com.

Em nosso curso utilizaremos mind maps para o planejamento de projeto,

construo de briefing e organizao de idias.

pgina 19
Tecnologias disponveis
Existem diversas tecnologias disponveis on e offline para gesto de projetos, a
grande maioria esta disponvel gratuitamente. So elas:

Para uso no computador

Microsoft Project
http://office.microsoft.com/pt-br/project/FX100487771046.aspx

a verso comercializada pela Microsoft e o padro do mercado. O Microsoft

project proporciona todas as ferramentas para gesto de projetos de acordo com as
especificaes do PMI, e conta com a possibilidade de compartilhamento utilizando
o Microsoft project server.

Serena Open Project

http://openproj.org/openproj

O Serena Open Project muito semelhante ao Microsoft Project, em praticamente

todas as suas funcionalidades, e inclusive l arquivos do Microsoft Project. Alem
disto completamente gratuito e possui verses para Windows, Linux e Mac OS 10.

Para uso online

Serena Projects on demand
http://openproj.org/pod

uma verso online compatvel com o Serena Open Project, esta verso online
permite mltiplos usurios. Para utilizar a verso online o usurio paga uma taxa
mensal.

dotProject
http://www.dotproject.net/

O dotProject uma soluo online totalmente gratuita, necessrio um servidor

com suporte a PHP e MySQL para sua instalao. Ele apresenta uma interface um
pouco mais complexa que a dos demais gerenciadores e totalmente focado no uso
colaborativo, contendo inclusive um forum de discuso, lista de links e arquivos
dentro do ambiente de gesto de projetos.

Tecnologias auxiliares
Mindmeister
http://www.mindmeister.com/

O Mindmeister uma ferramenta online para criao de mapas mentais, muito til
na organizao de idias para o planejamento do projeto.
pgina 20