Gestão de Projetos de Software. Fabrício Sousa

Transcrição

1 Gestão de Projetos de Software Fabrício Sousa

2 Problemática Projetos atrasados Orçamento estourado Equipe grande Difícil gerenciamento

3 Solução: Gerenciamento Princípios básicos de gestão de projetos Métricas Técnicas estimar prazo Técnicas estimar prazo e custo

4 Gestão de projeto de software Planejamento Monitoração Controle do pessoal Processos eventos

5 Gerenciamento: 4 P s Pessoal Produto Processo Projeto

6 Pessoal Organizado para realizar o projeto de software efetivamente Comunicação com o cliente Requisitos e escopos Importância: criação Modelo de Maturidade de Gestão de Pessoal (People Management Capability Maturity Model) PM-CMM

7 Modelo de Maturidade de Gestão de Pessoal Para melhorar a capacidade de organizações de software desenvolverem aplicações cada vez mais complexas, ajudando-as a atrair, desenvolver, motivar, dispor e reter o talento para necessário para melhorar sua capacidade de desenvolvimento de software

8 PM-CMM Define as seguintes áreas: Recrutamento Seleção Gestão de desempenho Treinamento Remuneração Desenvolvimento de carreira Organização e projeto do trabalho Desenvolvimento de equipe/cultura

9 PM-CMM Empresa Alto nível de maturidade na gestão de pessoal Grande probabilidade de implementar práticas efetivas de ES

10 Produto Antes do planejamento Estabelecer os objetivos e escopo do produto Soluções alternativas Restrições técnicas e gerenciais Sem essas informações Impossível definir estimativas de custo razoáveis (e precisas) Avaliações efetivas do risco Cronograma

11 Produto Soluções alternativas Selecionar uma abordagem melhor Restrições impostas Prazo de entrega Restrições orçamentária Disponibilidade pessoal Interfaces técnicas Outros fatores

12 Processo Forma como o software é desenvolvida Algumas atividades são aplicadas independentes do seu tamanho ou complexidade Atividades adaptáveis Atividades guarda-chuva Independente do processo e ocorre em qualquer parte Garantia de qualidade Gestão de configuração Medição

13 Projeto Dados da indústria em % dos projetos falharam de imediato 46% Ultrapassaram os custos e os prazos Embora a taxa de sucesso aumentou em parte, nossa taxa de falhas de projeto permanece maior do que deveria

14 Projeto: Gerente Para evitar falhas de projeto Evitar um conjunto de sinais de alerta comuns Entender os fatores críticos de sucesso Desenvolver uma boa abordagem Planejar Monitorar Controlar

15 Pessoal Estudo publicado no IEEE para três engenheiros de software Qual o fator mais importante para um projeto ser bem sucedido? P1-...As pessoas...e não as ferramentas P2- Pessoal competente..mais importante é selecionar a equipe P3- Pessoal bom...e desenvolver pessoal bom

16 Os interessados Gerentes seniores Aspectos do negócio Influência significativa sobre o projeto Gerentes de projeto (técnicos) Devem planejar, motivar, organizar e controlar os profissionais que fazem o trabalho de software Profissionais Aptidões técnicas necessários para desenvolver a aplicação

17 Os interessados Clientes Especificam os requisitos Usuários finais Interagem com o software depois de pronto

18 Líderes de Equipe Profissionais competentes se tornam líderes de equipe fracos Não são hábeis para lidar com pessoas...pessoas viram gerente de projeto por acidente...

19 MOI de Liderança Motivação Habilidade de encorajar o pessoal técnico a produzir o melhor de sua capacidade Organização Habilidade de moldar processos existentes (ou inventar novos) Idéias ou inovação Habilidade de encorajar o pessoal a criar e se sentir criativo, mesmo quando se trabalha dentro de limites rígidos.

20 Líderes de projeto bem sucedidos......aplicam um estilo de gestão de solucionar problemas Concentrar no entendimento do problema a ser resolvido Gerir o fluxo de idéias Conscientizar a equipe que a qualidade conta...e não deve ser comprometida

21 Gerente de software efetivo... Solução de problemas Diagnosticar os aspectos técnicos e organizacionais, que são relevantes Identidade Gerencial Passar confiança ao assumir ao controle Passar segurança para que o pessoal o siga

22 Gerente de software efetivo... Realização Otimizar a produtividade de uma equipe Premiar a iniciativa Sinergia (1+1 2) x Entropia Mostrar que assumir uns risco controlado não implica punição Influência e construção de espírito de equipe Deve ver as pessoas, entender os sinais verbais e não-verbais e reagir às suas necessidades

23 Equipe de Software Nem todo grupo é uma equipe e nem toda equipe está preparada Glenn Parker A melhor equipe depende... Estilo de gestão Quantidade de pessoas Níveis de aptidão Dificuldade geral do problema

24 Equipe de Software Sete fatores que devem ser levados em conta: A dificuldade do problema Tamanho do programa Linhas de código Pontos por função Período de vida da equipe Grau de Modularização A qualidade e a confiabilidade do sistema A rigidez do prazo de entrega Grau de sociabilidade (comunicação) exigido pelo projeto

25 Paradigmas organizacionais para equipes de ES Paradigma fechado Paradigma aleatório Paradigma aberto Paradigma síncrono

26 Paradigma fechado: pioneiro Chief Programmer Team (equipe do programador-chefe) Engenheiro sênior (programador- chefe) Grupo técnico Engenheiro de retaguarda

27 Boa equipe Membros das equipes devem confiar uns nos outros Distribuição de aptidões deve ser adequada ao problema Estrelas podem ter que ser excluídas da equipe, se a coesão tiver que ser mantidas

28 Livro Peopleware, de DeMarco e Lister Uma equipe aglutinada é um grupo de pessoas tão fortemente unidas que o todo é maior que a soma das partes... Quando uma equipe começa a se aglutinar, a probabilidade de sucesso cresce muito...fica difícil ser contida...não precisa ser gerida de modo tradicional e certamente não precisa ser motivada. Adquire energia de movimento

29 Intoxicação da equipe 1. Intoxicação de trabalho frenética Não acesso as informações e mudanças a todo vapor 2. Alta frustação que causa fricção entre membros Não poder decidir 3. Processo de software fragmentado ou mal coordenado 1. Trabalho desnecessário 2. Equipe não pode escolher o processo 4. Definição imprecisa de papéis 5. Exposição a falhas contínuas e repetidamente

30 Equipe de Software Diferenças de personalidade Extrovertidos Introvertidas Alguns colhem informações intuitivamente outros não. Etc..

31 Equipes Ágeis Incentiva a satisfação do cliente Entrega incremental de software desde o início Pequenas equipes altamente motivada Métodos informais Simplicidade em todo o desenvolvimento Ex.: Scrum

32 Produto No início do projeto é exigido estimativas quantitativas, mas não se tem informação necessária suficiente ainda. Análise detalhada dos requisitos Requer semanas ou meses

33 Escopo do software Contexto Como um software se encaixa no contexto de outro Objetivos da informação As informações saídas para o usuário Quais as entradas? Função e desempenho Como a entrada é transforma em saída

34 Decomposição do Problema A funcionalidade que precisa ser entregue O processo que será usado para entregá-lo Dividir para conquistar

35 Processo Gerente do projeto Deve selecionar o processo de software que será aplicado no desenvolvimento Qual é o mais apropriado para...?...o cliente que solicitou o produto e os pessoal técnico As características do produto apropriado O ambiente no qual a equipe trabalha

36 Fusão do Produto e do Processo Planejamento do projeto tem início com a fusão do produto e do processo Ex: Comunicação, planejamento, modelagem, construção e implantação

37 Qual o modelo escolho? Depende... Projeto pequeno, semelhante a esforços anteriores Abordagem seqüencial linear Restrições severas de tempo RAD Prazo de entrega apertado Modelo incremental

38 Decomposição do processo Desenvolva uma lista de pontos a esclarecer Reúna-se com o cliente para discutir os pontos a esclarecer Desenvolva conjuntamente uma declaração de escopo Reveja a declaração de escopo com todos os interessados Modifique a declaração do escopo na medida do necessário

39 Projeto Para fazer uma boa gestão com sucesso precisamos entender o que pode dar errado.

40 Dez sinais que indicam que o projeto está comprometido O pessoal de software não entende as necessidades de seus clientes 2. Escopo mal definido 3. Modificações mal gerenciadas 4. Tecnologia escolhida sofre modificações 5. As necessidades do negócio modificam-se (ou estão mal definidas)

41 Dez sinais que indicam que o projeto está comprometido Prazos irreais 7- Usuários resistentes 8 - Patrocínio é perdido 9 - Equipe com aptidões não adequadas 10 -Gerentes evitam as melhores práticas e as lições adquiridas

42 Como o gerente pode evitar esses problemas? 1. Comece com o pé direito Trabalho duro para entender o problema Boa equipe, autonomia, autoridade Boa equipe, autonomia, autoridade e tecnologia necessária. 2. Mantenha a energia de momento Providenciar incentivos para reduzir a rotatividade de pessoal Enfatizar a qualidade em toda tarefa

43 Como o gerente pode evitar esses problemas? 3- Acompanhe o progresso Modelos, código-fonte, conjunto de casos de testes Produzidos e aprovados (revisões técnicas) 4 - Tome decisões adequadas Manter as coisas simples Uso de componentes Evite interfaces sob medidas Identifique riscos e evite-os

44 Como o gerente pode evitar esses problemas? 5- Faça uma análise a posteriori Extraia lições aprendidas em cada projeto Avalie cronogramas planejados e cumpridos Colete e análise métricas Feedback da equipe e dos clientes Registre as descobertas por escrito

45 Príncipio W 5 HH Por que (Why) o sistema está sendo desenvolvido? Validade das razões comerciais Justifica o investimento pessoal, tempo e dinheiro? O que (What) vai ser feito? Quando (When) será feito? Cronograma Marcos

46 Principio W 5 HH Quem (Who) é responsável por uma função? Onde (Where) estão localizados na organização? Como (How) o trabalho será conduzido técnica e gerencialmente? Quanto (How much) é necessário de cada recurso?