Você está na página 1de 37

PLANEJAMENTO DE

PROJETO
PROF. RAUL SIDNEI WAZLAWICK
UFSC-CTC-INE
2010

CONTEXTO


Modelo de Processo (ciclo de vida)




Processo


Projeto

Como planejar um projeto no contexto de um


processo.

PLANO DE PROJETO


O objetivo do planejamento de projeto criar um


plano para o projeto como um todo


possivelmente mais detalhado para a fase ou ciclo


inicial.

Entre outras coisas, importante que o


responsvel por este planejamento utilize as
melhores ferramentas possveis para avaliar a
quantidade de esforo a ser despendido no projeto
como um todo e, possivelmente tambm, nas
atividades iniciais.
 Tal estimativa poder dar origem tanto ao
cronograma do projeto quanto estimativa de
custo total do projeto.


Com o plano de projeto em mos, o gerente de


projeto poder ento atribuir responsveis s
tarefas previstas e verificar se so executadas nos
prazos produzindo os artefatos esperados.

Dependendo do ciclo de vida adotado, o plano de


projeto poder ser:
altamente detalhado j no incio (modelos estilo
Cascata)
 ou um plano genrico de fases e um plano detalhado
apenas para o prximo ciclo ou iterao (mtodos
geis e Processo Unificado).


ATIVIDADES DE PLANEJAMENTO DO
PROJETO


Estabelecer os objetivos do projeto ou iterao.

De acordo com o processo definido e caractersticas do projeto


especfico, fazer o inventrio das tarefas necessrias para atingir
os objetivos, estimando o tempo para a realizao de cada tarefa.

De acordo com a descrio da tarefa dada pelo processo,


identificar os responsveis por cada tarefa (equipe).

Da mesma forma, identificar os recursos necessrios para realizar


cada tarefa.

De acordo com o workflow das tarefas, identificar as dependncias


entre elas. Essas dependncias usualmente ocorrem quando as
entradas de uma tarefa so as sadas de outras.

Construir o diagrama PERT para o projeto ou iterao,


encontrando o caminho crtico.

Construir o cronograma do projeto, usualmente com um diagrama


Gantt.

Estimar o custo de cada tarefa e do projeto ou iterao como um


todo.

OBJETIVOS DO PROJETO OU ITERAO


Inicialmente o planejador de um projeto deve
estabelecer quais so os objetivos finais do
projeto.
 O produto nem sempre apenas o software
funcionando.
 Outros elementos podem ser necessrios ou
desejveis.
 Sem definir claramente onde o projeto vai chegar
muito difcil estabelecer um bom plano.


Como escolher o caminho se no se sabe onde se quer


estar?
 Infelizmente, muitos planejadores de projetos
esquecem-se desta importante etapa.


O objetivo de um projeto ou iterao deve ser


sempre um conjunto de artefatos, ou seja, coisas
palpveis, que se possa pegar e dizer isso
aqui.
 Um objetivo no pode ser descrito como executar
tal ao, porque isso no define um artefato
palpvel.
 Gerar tal diagrama ou tal relatrio, seria muito
mais adequado neste sentido, ou ainda
implementar este e aquele requisitos.


OBJETIVOS NOS MTODOS GEIS




Se estiver trabalhando com um mtodo gil, os


objetivos da iterao sero definidos pelas
histrias de usurio ou requisitos a serem
implementados.

TIPOS DE OBJETIVOS NO UP:


Implementar total ou parcialmente um ou mais
casos de uso.
 Mitigar um risco conhecido, gerando ou
executando um plano de reduo de
probabilidade, reduo de impacto ou ainda de
recuperao de desastre.
 Implementar total ou parcialmente uma ou mais
modificaes solicitadas.


A medida que a arquitetura do sistema evolui nas


iteraes, modificaes podero ser solicitadas em
funo da no adequao aos requisitos ou ainda
mudana destes.
 Incorporar ao software estas solicitaes de mudana
pode ser ento um dos objetivos de uma iterao.


INVENTRIO DAS TAREFAS (WBS)


A WBS (Work Breakdown Structure) uma
estrutura que apresenta as tarefas que devem ser
executadas para atingir os objetivos
determinados para o projeto ou iterao
(Tausworthe, 1980).
 Vrias resolues de trabalho do Governo Norte
Americano exigem a apresentao de uma WBS
para a execuo de um projeto.


Se for usado um ciclo de vida prescritivo, os


workflows vo indicar quais as tarefas a serem
executadas e quais as dependncias entre elas.
 Dependendo do processo adotado o workflow
poder at indicar formas de estimao de esforo
para cada tarefa.


Se for usado um mtodo gil, recomenda-se que a


equipe decida sobre as tarefas a serem
desenvolvidas.
 Isso no impede que equipes usando mtodos
geis se baseiem em workflows existentes, se o
grupo entender que isso poder ser til ao
projeto.


Seja qual for o modelo de processo adotado, a


WBS pode ser definida em uma reunio de
planejamento com toda a equipe, para que as
vrias vises do projeto sejam pesadas no
momento de estabelecer tarefas e estimar esforo.

importante que cada tarefa caracterize muito


bem o produto de trabalho ou artefato de sada a
ser entregue ao seu final.
 Se um processo for usado, o prprio processo j
vai estabelecer quais artefatos so estes.


A WBS uma estrutura exaustiva, ou seja, ela


deve incluir todas as tarefas necessrias para a
execuo do projeto ou iterao.
 A WBS poder ser estruturada com uma rvore,
sendo que tarefas podem ser aglutinadas ou
detalhadas e estabelecendo uma rvore de
decomposio entre elas.
 As tarefas nas folhas desta rvore so as tarefas
terminais e estas devem seguir a regra 8-80
especificada adiante.


PLANEJE ARTEFATOS, NO AES


muito importante que o planejador do projeto
planeje artefatos de sada e no meramente
aes.
 Tarefas devem necessariamente produzir algo
fsico e no apenas a execuo de aes por parte
do responsvel ou participantes.
 Tentar modelar um projeto baseado em aes vai
necessariamente levar a um detalhamento
excessivo das atividades e conseqentemente
impossibilidade de gerenciar adequadamente o
trabalho.


Estilos de WBS que prevem diferentes estgios


de um artefato (por exemplo, verso inicial,
verso intermediria e verso final), devem
caracterizar exatamente o que esperam de cada
uma destas verses.

REGRA 8-80


Tarefas que se estima, levaro muito tempo para serem


completadas, devem ser quebradas em tarefas menores.
 No se deve ter tarefas com durao muito longa porque
fica muito difcil gerenci-las e acompanhar seu
andamento.
Tarefas que se estima levaro pouco tempo, devem ser
aglutinadas com outras.
 No se deve ter tarefas muito curtas porque
microgerenciar essas tarefas minsculas pode provocar
um overhead de gerenciamento que ao invs de ajudar
vai atrapalhar o projeto.
A Regra 8-80 estabelece que nenhuma tarefa deve durar
mais de 80 horas (duas semanas, ou dez dias de trabalho
ideais), nem menos de 8 horas (um dia de trabalho ideal).

REGRA DOS NVEIS




A estruturao de uma boa WBS no deve ter


mais de 3 ou 4 nveis de decomposio.

REGRA DO NMERO DE TAREFAS




O nmero total de tarefas terminais em uma


WBS no deve ultrapassar o limite de 100 a 200
elementos.

TAMANHO MXIMO DE PROJETO


GERENCIVEL


Considerando-se que cada tarefa poder ter no mximo 80 horas,


essa regra estabelece que um projeto gerencivel dever ter no
pior dos casos 80x200 = 16000 horas de trabalho.

Qualquer projeto com carga horria maior do que essa deve


necessariamente ser subdividido em projetos menores.

Neste sentido, as iteraes de duas semanas dos mtodos geis e


do UP garantem que o nmero de horas total nunca seja muito
grande.
 Sero apenas 80 horas de atividade por funcionrio.
 Seriam necessrios 200 funcionrios trabalhando numa
iterao para se atingir tal limite.
 Neste caso tambm seria altamente recomendvel a
subdiviso da equipe em equipes menores.
 Os mtodos geis usualmente no operam bem com equipes
to grandes.

REGRA DOS 100%


A regra dos 100% estabelece que uma WBS deve
incluir 100% de todo o trabalho que deve ser feito
no projeto ou iterao.
 Nenhum artefato ser produzido se no estiver
definido como sada de alguma das tarefas da
WBS e nenhuma tarefa deixar de produzir
algum artefato de sada.
 A regra dos 100% vale em todos os nveis da
hierarquia de decomposio da WBS.


Alm disso, quando uma tarefa se decompe em


subtarefas, o trabalho definido pela tarefa ser
exatamente igual a 100% do trabalho definido nas
subtarefas.

IDENTIFICAO DE RESPONSVEIS POR


TAREFAS


Um processo usualmente define que o responsvel por uma


tarefa um perfil, ou seja, uma pessoa com uma ou mais
habilidades desejveis.
Quando um projeto for instanciado a partir deste processo
deve-se ento atribuir as tarefas a pessoas reais que
atendam a este perfil desejado sempre que possvel.
Cada tarefa do WBS dever ser atribuda a um ou mais
responsveis.
Essas atribuies podero ter efeito sobre o cronograma de
projeto, pois embora certas tarefas possam ser executadas
em paralelo, no possvel faz-lo assim caso estejam
atribudas ao mesmo responsvel.

IDENTIFICAO DO RECURSOS E CUSTO


possvel que a maioria das tarefas a serem
executadas, alm de recursos humanos
(responsveis e participantes) tambm tenham
recursos fsicos consumveis ou no consumveis a
serem alocados.
 No momento do planejamento do projeto
necessrio prever o uso destes recursos.
 O custo de uma tarefa individual ser ento o
custo das pessoas que se dedicam a ela somado ao
custo dos recursos alocados.
 Somando-se os custos de todas as tarefas pode-se
estimar o custo total do projeto ou iterao
tambm.


ESTUDO DE VIABILIDADE
A partir da estimativa de custos pode-se decidir
se vale a pena desenvolver o projeto, ou seja, se
os benefcios a serem obtidos justificam os custos
com que se vai ter que arcar.
 Se o estudo de viabilidade concluir que o projeto
impraticvel, pode-se cancel-lo ou ainda muda
seus objetivos, de forma a chegar a um projeto
mais enxuto e mais vivel.


IDENTIFICAO DE DEPENDNCIAS ENTRE


TAREFAS
A partir da estimativa de custos pode-se decidir
se vale a pena desenvolver o projeto, ou seja, se
os benefcios a serem obtidos justificam os custos
com que se vai ter que arcar.
 Se o estudo de viabilidade concluir que o projeto
impraticvel, pode-se cancel-lo ou ainda muda
seus objetivos, de forma a chegar a um projeto
mais enxuto e mais vivel.


REDE PERT
O grafo de dependncias entre tarefas com a
durao prevista para cada tarefa constitui-se na
rede PERT do projeto ou iterao.
 H vrias ferramentas que permitem a
elaborao quase automtica de um diagrama
PERT.
 Nos exemplos adiante os grficos foram gerados
com a ferramenta free OpenProj.


http://openproj.org/

WBS NO OPENPROJ

WORKFLOW QUE DEU ORIGEM AO WBS


ANTERIOR

REDE PERT PARA A WBS

CAMINHO CRTICO





Um conceito importante no diagrama PERT o caminho


crtico, que consiste no mais longo caminho que leva do
incio ao fim do projeto.
Esse caminho crtico importante porque se qualquer
atividade prevista nele atrasar, por algum motivo, todo o
projeto ir atrasar.
Este o caminho sem folga.
As tarefas, entretanto, que no pertencem ao caminho
crtico podem atrasar at um certo limite sem prejuzo ao
projeto como um todo.
Na figura anterior as atividades do caminho crtico so
mostradas em vermelho.
As atividades que no esto no caminho crtico so
mostradas em azul.

Quando uma tarefa do caminho crtico atrasa


necessrio acelerar alguma atividade posterior no
caminho crtico para manter o projeto dentro do
cronograma.

FORMAS DE RECUPERAR UM CRONOGRAMA


ATRASADO


Aumentar a jornada da equipe (o que no pode se


transformar em rotina).
Aumentar o tamanho da equipe (o que pode causar
transtornos de gerncia em funo da colocao de pessoas
novas no projeto, possivelmente com menos experincia).
Eliminar algumas atividades ou tarefas inteiras do projeto
(nem sempre possvel devido s dependncias, mas s
vezes possvel reduzir a quantidade de elementos
abordados em uma tarefa. Por exemplo, ao invs de
implementar 3 casos de uso, caso haja atrasos, implementase apenas 2, deixando para outra iterao a implementao
do terceiro).

CRONOGRAMA DO PROJETO
O cronograma do projeto usualmente mostrado
em um diagrama Gantt, que consiste em uma
visualizao do tempo linear transcorrido e a
ocorrncia das diferentes tarefas ao longo deste
tempo.
 Em relao ao diagrama PERT, o diagrama
Gantt apresenta o andamento das atividades ao
longo de uma linha de tempo permitindo
visualizar claramente quais atividades devem
estar sendo executadas a cada dia.


DIAGRAMA GANTT

BIBLIOGRAFIA


Tausworthe, R. C. (1980). The Work Breakdown


Structure in Software Project Management.
Journal of Systems and Software. 1(1979-1980):
181-186. Elsevier.