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 simplicado 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-denidos. O conhecimento e as prticas da gerncia de
projetos so mais bem descritos em termos de seus processos componentes.
Esses processos podem ser classicados 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 n ve l t o b a i xo q ua nt o
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 proj eto. Um ponto-de-vista
alternativo diz que gerenciamento
de projetos a disciplina de denir 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 nal. 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 grco de
'barra' como uma ferramenta de gerncia do
projeto, para ser um associado as teorias de
Frederick Winslow Taylor da administrao
cientca, 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
(work breakdown structure) ou EAP
1
(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 grcos 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 (PMI
3
) 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 prosso.
pgina 5
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
Grco de Gantt
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 signica
avaliar os riscos e as chances.
Apesar do nome avaliar riscos
tambm aval i ar as chances.
Estamos o tempo todo avaliando
di versos 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
d e r c e r t o t e n t a mo s u ma
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
d a s h i p t e s e s p o r p u r a
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 decincia 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 identicar 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-
ativos
5
, deve estar com tempo suciente para
chegar ao seu desti no at o horri 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 la que engarrafada esperando voc
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 que 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 ca 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, conrmando a mxima de que a
prtica leva perfeio.
pgina 7
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.
Pintura de Joo Werner
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 nanceiros, 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 danicado 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
danicao 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 inuencia 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 m
do projeto. Estas trs variveis esto freqentemente competindo: o escopo
aumentado signica tipicamente o tempo aumentado e o custo aumentado, uma
restrio apertada de tempo poderia signicar custos aumentados e o escopo
reduzido, e um oramento apertado poderia signicar 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 inuenciado
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 denirmos 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 especicadas para o resultado m, ou seja, o que se pretende, e o
que no se pretende realizar. A qualidade do produto nal 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 signica 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
entre pegar o pri mei ro
nibus e o segundo uma
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
Pegar o primeiro nibus Pegar o segundo nibus
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 desaadora, dando o seu tempero.
Em gesto de projetos no poderia ser diferente, existe a famosa Lei de Murphi
7

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 denidas 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 nal 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 que parada
por exemplo.
pgina 11
7
http://pt.wikipedia.org/wiki/Lei_de_Murphy
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 identicou 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 ca 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
identicar 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 brieng, 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 grco 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.
pgina 12
8
http://en.wikipedia.org/wiki/Pareto_principle
Ciclo de monitoramento e controle
Na verdade as cinco etapas do projeto no acontecem como uma seqncia linear,
anal como j vimos existem problemas no previstos, existem ajustes serem
feitos. E estes ajustes so feitos on the y, ou seja, durante a execuo do projeto,
congurando um ciclo claro que passa por execuo, controle e planejamento.

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"
identicam uma seqncia de passos a serem completados. Essas abordagens
contrastam com a abordagem conhecida como desenvolvimento gil de software
9
,
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
pgina 13
9
http://en.wikipedia.org/wiki/Agile_Project_Management
Iniciao planejamento
execuo controle concluso
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, denida 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 denir a
soluo nal 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 diram de indstria para indstria, os estgios reais tipicamente seguem os
passos comuns resoluo de problemas (problem solving): denir 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 denem 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 nais 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 denidos
por contrato.
Para manter o controle sobre o projeto do incio ao m, 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 m 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 ecazes 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 denio 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 cientca, 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 xo 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 cam em p).
Uma breve sesso de planejamento, na qual os itens do backlog para uma
sprint (iterao) so denidos;
Uma retrospectiva, na qual todos os membros da equipe reetem 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 rewall entre a equipe e qualquer inuncia 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 Scrum o reconhecimento de que desaos
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 denido,
focando na maximizao da habilidade da equipe de responder de forma gil aos
desaos emergentes.
Um dos grandes defeitos do Scrum, porm, a abordagem de "receita de bolo" do
gerenciamento de projetos exemplicado 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 simplicado
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 z 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 signica "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 eciente de fazer
estas reunies seria car em p e em frente a um quadro negro. Como as pessoas
tendem a car 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 beneciar 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 diculdade 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 prossionais para gerenciar qualquer tipo de
informao. Este mtodo de registro cada vez mais usado por uma srie de
prossionais 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 brieng e organizao de idias.
pgina 19
Tecnologias disponveis
Existem diversas tecnologias disponveis on e ofine para gesto de projetos, a
grande maioria esta disponvel gratuitamente. So elas:
Para uso no computador
Microsoft Project
http://ofce.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
especicaes 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