Gestao Projetos - Aula 01

6,828 views
6,593 views

Published on

Published in: Technology, Travel
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,828
On SlideShare
0
From Embeds
0
Number of Embeds
143
Actions
Shares
0
Downloads
630
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Gestao Projetos - Aula 01

  1. 1. GESTÃO DE PROJETOS Aula 01 Prof. Cleuber Moreira Fernandes Mestre em Ciência da Computação - UnB Cleubermf@yahoo.com.br http://br.groups.yahoo.com/group/GP-2008
  2. 2. 1. Conceitos de Gestão de Projetos 1.1 Perguntas e respostas importantes a) O que é? Uma atividade importante quando sistemas de computadores são construídos. Envolve o planejamento, a monitoração e o controle de recursos, processo e eventos que ocorrem à medida que o software evolui de um conceito prelimiar para uma implementação operacional. b) Quem faz? Todos gerenciam em uma certa medida, mas o escopo das atividades de gestão varia com a pessoa que as executam. Um engenheiro de software gerencia suas atividades do dia-a-dia, planejando e controlando tarefas técnicas. Gerentes de projeto planejam, monitoram e controlam o trabalho de uma equipe composta por analistas, arquitetos, programadores, testadores etc. Gerentes seniores coordenam a interface entre o negócio e os profissionais de software. c) Por que é importante? Construir software é uma atividade complexa, principalmente se o escopo do produto é grande e envolve tecnologias de ponta. d) Quais são os passos? Precisa-se entender os 4 P’s – Pessoas, Produto, Processo e Projeto. Pessoas precisam ser organizadas para realizar o trabalho de software efetivamente. A comunicação com o cliente precisa ocorrer para que o escopo e os requisitos do produto sejam entendidos. Um processo precisa ser selecionado a fim de se adquar ao pessoal e ao produto. O projeto precisa ser planejado, estimado o esforço e o tempo para executar as tarefas de trabalho: definição de produtos de trabalho, estabelecimento de marcos de qualidade e estabelecimento de mecanismos para monitorar e controlar o trabalho definido pelo plano. e) Qual o produto do trabalho? O plano de projeto, que é produzido à medida que as atividades de gerência são iniciadas. O plano define os processos e as tarefas a serem conduzidos, o pessoal que executará o trabalhoe os mecanismos para avaliar riscos, controlar modificações e avaliar qualidade. f) Como garanto que fiz corretamente? Não se pode ter completa certeza de que o plano de projeto está correto até que se tenha entregue um produto de alta qualidade, pontualmente e dentro do orçamento. 1.2 Os 4 P’s a) Pessoal O fator pessoal é tão importante que o Software Engineering Institute desenvolveu um modelo de maturidade da capacidade de gestão de pessoal (People-CMM), para orientar organizações de software a atrair, desenvolver, motivar, empregar e reter o talento necessário para melhorar sua capacidade de desenvolvimento de software. 1
  3. 3. Esse modelo define as seguinte práticas-chave para pessoal de software: recrutamento, seleção, gestão de desempenho, treinamento, remuneração, desenvolvimento de carreira, organização e projeto do trabalho, e desenvolvimento de equipe. b) Produto Para se planejar um projeto, devem ser estabelecidos os objetivos e o escopo do produto, as soluções alternativas devem ser consideradas e as restrições técnicas e gerenciais devem ser identificadas. Sem essas informações é impossível definir estimativas de custo razoáveis e “precisas”, avaliações efetivas de risco e cronogramas que proporcione uma indicação significativa do progresso. Pode iniciar como engenharia de processo do negócio e terminar na engenharia de requisitos de software. c) Processo Fornece o arcabouço a partir do qual pode ser estabelecido um plano abrangente para o desenvolvimento de software. Vários conjuntos diferentes de tarefas, produtos de trabalho, papéis e pontos de controle, permitem adaptação às características do projeto e às necessidades da equipe de projeto. Por fim, atividades guarda-chuva – garantia da qualidade, gerenciamento de configurações e mudanças, medição – cobrem o modelo de processo. c) Projeto A única forma conhecida de gerir a complexidde é por meio de projetos de software planejados e controlados. 1.3 Pessoal Em pesquisa realizada pelo IEEE com os vice-presidentes de 3 importantes empresas de tecnologia, todos consideraram as pessoas o fator mais importante de um projeto de tecnologia. Apesar de reconhecerem isso, as ações empreendidas nessa áreas nem sempre condizem com seu valor. 1.3.1 Os participantes (stakeholders) • Gerentes seniores – cuidam dos aspectos do negócio que influenciam o projeto; • Gerentes de projeto (técnicos) – planejam, motivam, organizam e controlam os profissionais que fazer o trabalho; • Especialistas – fornecem o conhecimento técnico necessário à engenharia; • Clientes – Especificam os requisitos; • Usuários – interagem com o software após implantado. 1.3.2 Líderes de equipe Com frequência, pessoas caem na posição de gerência de projeto e viram gerentes por acidente! Um gerente de projetos deve possuir as seguintes características: a) Solução de problemas – diagnosticas os aspectos técnicos e organizacionais mais relevantes, estruturar sistematicamente uma solução e motivar outros profissionais a desenvolver a solução, aplicar lições aprendidas e ser flexível para mudar o rumo se as tentativas iniciais não frutificarem. 2
  4. 4. b) Identidade gerencial – deve assumir o encargo do projeto. c) Realização – otimizar a produtividade da equipe premiando a iniciativa e a realização e demonstrar, com suas próprias ações, que assumir risco controlado não implica punição. d) Influência e construção de espírito de equipe – um gerente de projeto eficiente deve conseguir ver as pessoas, entender os sinais verbais e não verbais e reagir às suas necessidades. Deve manter o controle em situações de alta tensão. 1.3.3 Equipe de Software a) Democrática Descentralizada Não possui líder permanente, sendo substituídos periodicamente. A comunicação entre os membros da equipe é horizontal. b) Controlada Descentralizada Possui um líder definido e líderes secundários (responsáveis por sub-tarefas) 3
  5. 5. c) Controlada Centralizada Possui um gerente sênior que planeja e revê todas as atividades técnicas das equipes. Um engenheiro de retaguarda que apóia o gerente sênior nas suas atividades e pode substituí-lo, com perda mínima da continuidade do projeto. • A estrutura Democrática Descentralizada resulta em moral elevada e satisfação no trabalho • A estrutura Democrática Descentralizada é adequada para tratar problemas mais difíceis. • Quando a modularização é alta, a estrutura Controlada Centralizada ou a Controlada Descentralizada funcionarão bem. • As estruturas Controlada Descentralizada e Controlada Centralizada produzem menos falhas. É importante notar que o reconhecimento de diferenças humanas é o primeiro passos na direção de criar equipes que se aglutinam. 1.3.4 Problemas de coordenação e comunicação Uma equipe de engenharia de software precisa estabelecer métodos específicos para coordenar o pessoal que faz o trabalho e lidar efetivamente com as características modernas do software: escala, incerteza e interoperabilidade. Para conseguir isso, mecanismos para comunicação formal e informal precisam ser estabelecidos entre os membros da equipe e entre diferentes equipes. • Abordagens formais e impessoais – documentos escritos, reuniões estruturadas, documentos de engenharia de software, momorandos técnicos, marcos de projeto, cronogramas, pedidos de modificação, relatórios de detecção de erros. • Procedimentos formais e interpessoais – atividades de garantia da qualidade aplicadas aos produtos do trabalho de engenharia, como reuniões de revisão e inspeções do projeto e código. • Procedimentos informais e interpessoais – reniões de grupo para disseminação da informação e solução de problemas. • Comunicação eletrônicas – email, documentos digitais, vídeo-conferências. • Redes Interpessoais – discussões informais com membros da equipe e estranhos ao projeto. 4
  6. 6. 1.4 Produto O gerente de projeto tem um dilema no início de um projeto. São necessárias estimativas quantitativas e um plano organizado, mas não há informação sólida disponível. Assim sendo, é preciso examinar o produto e o problema que ele pretende resolver no início do projeto. 1.4.1 Escopo do software A delimitação do escopo é a primeira atividade de um projeto. • Contexto – sistema maior, negócio, restrições. • Objetivos da informação – que objetos de dados são necessários como entrada e saída • Função e desempenho – transformação dos dados de entrada em saídas. Características especiais de desempenho. 1.4.2 Decomposição do problema Conhecida pela estratégia “dividir para conquistar”, é uma atividade de análise de requisitos que visa particionar um problema complexo em problemas menores, mais gerenciáveis. Esse refinamento é necessário para que as estimativas de custo e prazo sejam mais realístas. 1.5 Produto As fases genéricas que caracterizam o processo de software – definição, desenvolvimento e manutenção – são aplicáveis a todo software. O problema é selecionar o processo que é mais adequado para um software específico a ser trabalhado por uma equipe de engenharia. Um conjunto de paradígmas pode ser escolhido. • Sequêncial Linear • Prototipagem • Espiral • Iterativo e Incremental O gerente de projeto deve decidir qual modelo é mais apropriado para: a) o cliente que solicitou e as pessoas que executarão o trabalho; b) as características do produto; c) o ambiente de projeto. 5
  7. 7. 1.5.1 Fusão do Produto e do Processo Funcio- Comunicação Planejamento Análise de Engenharia Construção e Avaliação pelo nalidade com Cliente Risco Implantação Cliente Cadastrar Datas e produtos Datas e produtos Datas e Datas e Datas e Datas e Produtos trab. trab. produtos trab. produtos trab. produtos trab. produtos trab. Emitir Datas e produtos Datas e produtos Datas e Datas e Datas e Datas e Pedidos trab. trab. produtos trab. produtos trab. produtos trab. produtos trab. 1.5.2 Decomposição do Processo As tarefas reais variam com o projeto. A decomposição é a determinação de como as atividades da estrutura geral (comunicação com o cliente, planejamento, ...) serão realizadas. A comunicação com o cliente num projeto pequeno pode ser realizada com as seguintes tarefas: 1. Desenvolva uma lista de pontos a resolver; 2. Reuna-se com o cliente para discutir esses pontos; 3. Desenvolva conjuntamente uma declaração de escopo; 4. Revise a declaração com todos os interessados; 5. Modifique a declaração na medida do necessário. Mas num projeto mais complexo, com escopo mais amplo, pode exigir uma série de outras tarefas que garantam maior confiabilidade abrangência. 1.6 Projeto Para gerir com sucesso um projeto de software é preciso entender o que pode dar errado e como fazer para dar certo. Seguem 10 sinais que indicam que um projeto está comprometido: 1. O pessoal de software não entende as necessidades de seus clientes; 2. O escopo do produto está mal definido; 3. As modificações são mal gerenciadas; 4. A tecnologia escolhida sobre modificações; 5. As necessidades do negócio modificam-se; 6. Os prazos são irreais, inexequíveis; 7. Os usuários são resistentes; 8. O patrocínio é perdido; 9. A equipe de projeto não tem pessoal com as aptidões adequadas; 6
  8. 8. A seguir estão algumas recomendações de como um gerente deve agir para evitar os problemas mencionados: 1. Comece com o pé direito – entender bem o problema para depois estabelecer objetivos e expectativas realísticas a todos envolvidos no projeto. Isso é reforçado pela estruturação correta da equipe e pela atribuição da autonomia, autoridade e tecnologia necessárias a conduzir o trabalho. 2. Mantenha a energia de momento – providenciar incentivos para evitar a rotatividade de pessoal ao mínimo. A equipe deve enfatizar a qualidade em toda tarefa que executar. 3. Acompanhe o progresso – à medida que produtos do trabalho (especificações, código-fonte, casos de teste) são produzidos e aprovados usando revisões técnicas formais como parte da atividade de garantia da qualidade. 4. Tome decisões adequadas – essencialmente as decisões devem ser no sentido de “manter a coisa simples”. Sempre que possível optar pelo software comercial em uso ou componentes existentes. Evitar interfaces sob medida, quando padrões estão disponíveis. Decida identificar e evitar riscos e atribuir mais tempo do que se acha necessário às tarefas complexas ou arriscadas. 5. Faça uma análise a posteriori – Estabelecer um mecanismo consistente para extrair e registrar as lições aprendidas em cada projeto. Avaliar cronogramas planejados e cumpridos, coletar e analisar métricas de projeto, obter realimentação dos membros da equipe e dos clientes. 1.7 O Princípio W5HH Este princípio apresenta uma série de questões que levam à definição das características-chave do projeto e do plano de projeto resultante: 1. Por que (Why) o sistema está sendo desenvolvido? A razão que justifica o gasto de pessoal, o tempo e o dinheiro. 2. O que (What) vai ser feito, quando (When)? As respostas ajudam a equipe a estabelecer um cronograma do projeto pela identificação de tarefas-chave e prazos exigidos pelo cliente. 3. Quem (Who) é responsável pela função? Definir o papel e responsabilidade de cada membro da equipe de software. 4. Onde (Where) estão localizados na organização? Nem todos os papéis e responsabilidades estão na própria equipe. O cliente, usuários e outros também têm responsabilidades. 5. Como (How) o trabalho será conduzido técnica e gerencialmente? Uma vez estabelecido o escopo do produto, uma estratégia gerencial e técnica deve ser definida. 6. Quanto (How much) é necessário de cada recurso? A resposta é obtida pelo desenvolvimento de estimativas baseadas nas respostas às questões anteriores. 7

×