Planejamento e Gerência de Projeto Gerência de Projetos Planejamento e Gerência de Projeto Projeto Planejamento Um Plano de Projeto Wesley Peron Seno

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.

“Mas parece que nunca há tempo o bastante!” Planejamento 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!”

Um conceito importante História sobre as Pedras Grandes e o Vaso Tempo Um conceito importante História sobre as Pedras Grandes e o Vaso

Planejamento “À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

Um Plano de Projeto de Software 1) Introdução Objetivos 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

1 - Objetivos do Projeto Deve ser o mais específico possível Facilitar um melhor planejamento exemplo:

2 - Estimativas de Projeto Esforç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”.

2 - Métodos de Estimativas de Esforç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

3 - 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”.

3 - 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”.

3 - 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

3 - 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

3 - 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.

3 - Gerenciamento dos Riscos

Infelizmente a 1ª é encontrada mais freqüentemente! 4 - 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!

4 - 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

4 - Recursos e Pontos de Controle

5 - Recursos do Projeto Pessoas Equipamentos Instalações 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.

5 - 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.

5 - 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.

5 - O que fazem os programadores?

6 - 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?

6 - Estruturas de Equipe Convencional Democrática Centralizada Hierárquica

6 - 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.

6 - 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

6 - Estrutura Centralizada Chief 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écnicos

6 - 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.

7 - 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