página 1 gerência de projetos planejamento e gerência de projeto projeto planejamento um plano de...
TRANSCRIPT
Página 1
Gerência de ProjetosGerência de Projetos
•Planejamento e Gerência de Projeto
•Projeto•Planejamento
•Um Plano de Projeto
Wesley Peron SenoWesley Peron Seno
Página 2
O que é Projeto ?O que é Projeto ?
“É uma sequência bem definida de eventos com um início e um fim, que se destina a atingir um objetivo
claro, sendo conduzida por pessoas dentro de parâmetros estabelecidos como tempo, custo,
recursos e qualidade”.
A extensão do planejamento de um projeto depende da sua complexidade, quanto mais complexo mais você
tem de planejar.
Página 3
PlanejamentoPlanejamento
Tempo -
– É o mais valioso bem disponível a um engenheiro de software.
Se houver suficiente tempo disponível::
– um problema pode ser adequadamente analisado;
– uma solução compreensivamente projetada;
– um código-fonte cuidadosamente implementado;
– um programa minuciosamente testado.
“Mas parece que nunca há tempo o bastante!”
Página 4
TempoTempo
Um conceito importanteUm conceito importante
História sobre as Pedras Grandes e o VasoHistória sobre as Pedras Grandes e o Vaso
Página 5
PlanejamentoPlanejamento
• “Às vezes parece que em nossa ansiedade para começar, não despendemos tempo para “organizar nossas ações”
• O planejamento obriga gerentes e profissionais a despender esse tempo.
• Antes de começar:– Desenvolver uma estratégia para atacar o problema
– Estabelecer um mecanismo para avaliação do progresso
– Organizar o pessoal
Página 6
Um Plano de Projeto de SoftwareUm Plano de Projeto de Software
1) IntroduçãoObjetivos do projeto
2) Estimativas de projeto
3) Riscos de projeto
4) Cronograma
5) Recursos do projeto
6) Organização do pessoal
7) Mecanismos de controle
8) Apêndices
Página 7
1 - Objetivos do Projeto1 - Objetivos do Projeto
• Deve ser o mais específico possível• Facilitar um melhor planejamento exemplo:
Genérico Específico
Implantar o novo sistemade relatórios financeiros
Treinar o departamento financeiroe os chefes de departamento paratrabalhar com o novo sistema de
preparação de relatóriosfinanceiros, até o segundo
trimestre, na fase-piloto. Treinartoda a empresa até o final do ano.
Página 8
2 - Estimativas de Projeto2 - Estimativas de ProjetoEsforço, Prazo e CustoEsforço, Prazo e Custo
• Uma das tarefas mais cruciais para um gerente de projeto.
• Uma das máximas em Gerência de Projetos é que: “Negociar prazos e recursos para um projeto sempre deve acontecer quando do seu planejamento, jamais no meio ou no fim do projeto”.
Página 9
2 - Métodos de Estimativas de 2 - Métodos de Estimativas de Esforço, Prazo e Custo de Projetos de SistemasEsforço, Prazo e Custo de Projetos de Sistemas
• Para auxiliar o gerente de projeto, existem diversos métodos de estimativas:
• FPA - Function Point Analysis (IBM)• COCOMO e COCOMOII - Constructive Cost Model
(Barry Bohem)“Todos os modelos de estimativas necessitam ser calibrados para
o ambiente específico da organização. É necessário coletar dados históricos dos projetos a fim de que os modelos sejam
calibrados às condições locais”. Kemerer
Página 10
3 - Análise dos Riscos3 - Análise dos Riscos
• O risco preocupa-se com acontecimentos futuros.• Risco envolve mudanças, tais como:
– de mentalidade;
– de opinião;
– de ações ou
– de lugares.
“Paradoxalmente, o risco, como a morte e os impostos, é uma das poucas certezas da vida”.
Página 11
3 - Análise dos Riscos3 - Análise dos Riscos
• A análise dos risco é, de fato, composta por 4 atividades:
– Identificação,
– Projeção,
– Avaliação e
– Administração dos riscos.
“Embora seja fútil tentar eliminar o risco, e questionável tentar eliminá-lo, é fundamental que os riscos assumidos sejam os
riscos certos”.
Página 12
3 - Identificação dos Riscos3 - Identificação dos Riscos
• Riscos de Projeto identificam:– problemas orçamentários, cronograma e pessoal
• Riscos Técnicos identificam– problemas de projeto, implementação, interface, verificação e manutenção
• Riscos de Negócios– são insidiosos e podem destruir o projeto
– 1) construir um produto excelente que não é usado
– 2) construir um produto que não se encaixa mais à estratégia da empresa
– 3) construir um produto que a equipe de venda não sabe como vender
– 2) perder o apoio da alta adm. Devido à mudança de enfoque ou de pessoas
– 3) perder compromisso orçamentário
Página 13
3 - Projeção dos Riscos3 - Projeção dos Riscos
• Também chamada de estimativas dos riscos, tenta classificar cada risco de duas maneiras, caso ele ocorra:– a probabilidade de que o risco seja real e
– as consequências dos problemas associados ao risco.
• O que fazer?– estabelecer uma escala que reflita a probabilidade de
ocorrência dos riscos
– delineamento das conseqüências dos riscos
– estimativas do impacto dos riscos
Página 14
3 - Avaliação dos Riscos3 - Avaliação dos Riscos
• Etapas durante a avaliação:– Definir os níveis de risco referentes para o projeto
– Prever o conjunto de pontos referentes que define uma região de encerramento do projeto.
• Charrette e Rowe - Matemática utilizada para apoiar a avaliação.
Página 15
3 - Gerenciamento dos Riscos3 - Gerenciamento dos Riscos
Gerenciamentodos riscos
Risco 1
Risco 2
Risco n
Dados da Análise
Passos deAdministração
dos Riscos
Dados da Análise
Dados da Análise
Passos deAdministração
dos Riscos
Passos deAdministração
dos Riscos
Plano deadministração emonitoração dos
riscos
ooo
Página 16
4 - Cronograma4 - Cronograma
A determinação de um cronograma para projeto pode ser vista a partir de duas perspectivas:
• 1ª - Uma data final para entrega já foi definida. Devemos distribuir o esforço dentro do tempo previsto.
• 2ª - O esforço é distribuído para se tirar o maior proveito dos recursos e uma data final é definida após cuidadosa análise pela equipe de desenvolvimento.
Infelizmente a 1ª é encontrada mais freqüentemente!
Página 17
4 - Cronograma4 - Cronograma
• As técnicas de determinação de cronogramas podem ser implementadas com ferramentas automatizadas.
• Métodos comumente utilizados:
– PERT - Program Evaluation and Review Technique (método de avaliação e revisão de programa)
– CPM - Critical Path Method (método do caminho crítico)
• Exemplo de Ferramenta: MS-Project
Página 18
4 - Recursos e Pontos de Controle4 - Recursos e Pontos de Controle
Página 19
5 - Recursos do Projeto5 - Recursos do Projeto
• Pessoas– Identificar pessoas ou grupos (usar tipos genéricos como
analista, programador, eng. de software ...)
• Equipamentos– Verificar se existe equipamentos disponíveis ou se há
necessidade de aquisição e deve constar do planejamento.
• Instalações– Considerar os requisitos de espaço para a quantidade de
pessoas ou materiais envolvidos.
Página 20
5 - Pessoas5 - Pessoas
• O mais importante recurso em projetos de sistemas (às vezes o único além do tempo)
• É fundamental que engenheiros de software entendam de fatores humanos, porque pessoas julgarão a utilidade do software que eles constróem.
• Pontos Chaves:
• trabalho em grupos pequenos (no máximo sete),
• liderança técnica por competência e
• local de trabalho adequado.
Página 21
5 - Fatores Humanos5 - Fatores Humanos
• Grupos democráticos tendem a ter mais sucesso que grupos autocráticos.
• Interação do grupo deve ser estruturada de modo que o número de elos de comunicação seja minimizado.
• Ergonomia: o local de trabalho tem efeitos importantes mas não quantificáveis na produtividade de software.
Página 22
5 - O que fazem os programadores?5 - O que fazem os programadores?
Escrevem programas
13%
Comunicação de trabalho
32%
Pessoal13%
Miscelânea (deslocamento
s fora do local...)
15%
Correios, doc administrativos
5%
Treinamento6%
Lêem programas
16%
Página 23
6 - Estrutura Organizacional6 - Estrutura Organizacional
• Motivação Básica da Organização/Coordenação– Necessidade de cooperação quando as metas não podem ser
realizadas por uma única pessoa num tempo razoável.• Qual o melhor papel para cada indivíduo?
• Como as responsabilidades devem ser dividas?
• Modelos como o COCOMO permitem estimar o número necessário de pessoas num projeto em função da complexidade do sistema.– Como dividir em equipes?
Página 24
6 - Estruturas de Equipe6 - Estruturas de Equipe
• Convencional
• Democrática
• Centralizada
• Hierárquica
Página 25
6 - Estrutura Convencional6 - Estrutura Convencional
• Reúnem-se analistas e programadores, designa-se um gerente e começa-se a trabalhar.
• Cada um é responsável pelo design e implementação de sua parte.
Página 26
6 - Estrutura Democrática6 - Estrutura Democrática
• Controle descentralizado, decisões por consenso
• O trabalho é considerado trabalho em grupo
• Para projetos longos, por causa do volume de comunicação intragrupos
• Não é adequada para equipes grandes– sobrecarga de comunicação
– risco de perfeccionismo
EstruturaGerencial
Padrões deComunicação
Página 27
6 - Estrutura Centralizada6 - Estrutura CentralizadaChief Programmer TeamChief Programmer Team
• Único responsável técnico por todas as fases do projeto
• Apropriada para projetos de curto prazo e problemas bem entendidos por um único indivíduo
• Problemas: políticos, dependência de líderes técnicosProgramador chefe
Documentador
Programadores Especialistas
Página 28
6 - Equipe Hierárquica6 - Equipe Hierárquica
• Líder dirige grupo de programadores experientes
• Cada programador experiente, por sua vez dirige um grupo de outros menos experientes
• Cada chefe de subgrupo atua como transmissor de informações para o seu subgrupo e como ligação entre os chefes de outros grupos.
Gerente
Pessoal Senior
Pessoal Junior
Página 29
7 - Mecanismos de Controle7 - Mecanismos de Controle
• ditado: “Os projetos de software atrasam-se em seu cronograma um dia de cada vez”.
• Um dos papéis da gerência é rastrear e controlar o projeto. Para isso deve-se definir mecanismos como:– Reuniões periódicas
– Avaliação dos resultados
– Determinação de marcos do projeto
– Comparação das datas reais e planejadas
– Reuniões informais para obter opiniões sobre problemas futuros