Planejamento e Gerenciamento Iterativo de Projetos de Software

Transcrição

1 Planejamento e Gerenciamento Iterativo de Projetos de Software 1

2 1. Introdução Motivação e Conceitos Básicos 2

3 Preocupações do Gerente de TI Melhorar a qualidade do desenvolvimento de software Principais riscos e incertezas no desenvolvimento de sistemas 3

4 O que faz um gerente de projetos? Aloca recursos Define prioridades Coordena as interações com clientes e usuários Procura manter a equipe de projeto focada na meta do projeto Resolve conflitos Gerencia riscos Estabelece um conjunto de práticas para assegurar a qualidade dos artefatos do projeto 4

5 Qual é o objetivo do gerente de projetos? Desenvolver o produto esperado dentro do prazo, custo e nível de qualidade desejados 5

6 Algumas estatísticas 31% dos projetos são abortados 53% dos projetos extrapolam o prazo em mais de 50% % de projetos que são finalizados dentro do prazo e custo esperados em grandes empresas: 9% em empresas medianas: 16% em pequenas empresas: 28% Fonte: Standish Group,

7 Planejamento e gerenciamento é para torná-lo parte do % de sucesso!!! Fator Humano Engenharia de Software Estratégias do Negócio 7

8 Parkinson s effect O trabalho se expande de modo a preencher todo o tempo disponível para executá-lo Se a equipe sentir que tem tempo disponível vai gastá-lo, contribuindo para elevar os riscos do projeto! 8

9 2. Considerando os Riscos 9

10 Não se preocupe; eu vou pensar em algo, Indiana Jones 10

11 Gerenciamento de riscos Relaciona-se com a análise de aspectos desconhecidos do projeto são esses aspectos que podem fazer com que o projeto fracasse! Risco fator, elemento, acontecimento, qualquer coisa que, se concretizada, pode interferir no sucesso do projeto 11

12 Gerenciamento de riscos Identificação Análise Acompanhamento e controle 12

13 Identificação dos riscos Para levantar os riscos podemos usar: o conhecimento do negócio estudo de viabilidade, documento de requisitos e plano do projeto brainstormings checklists Os riscos podem ser classificados de acordo com sua natureza em: riscos de projeto riscos do negócio riscos técnicos 13

14 Riscos de projeto Normalmente ameaçam o plano de projeto, prejudicando o cronograma e/ou custo Estão relacionados ao uso de recursos organizacionais financiamento ambiente de desenvolvimento processo de desenvolvimento humanos equipe cliente/usuários tempo cronograma escopo 14

15 Riscos do negócio Normalmente ameaçam a distribuição ou implantação do produto, prejudicando o retorno do investimento Muitos são riscos indiretos 15

16 Riscos técnicos Normalmente ameaçam a qualidade do produto, prejudicando o tempo de conclusão do projeto São relacionados ao uso da tecnologia necessária para implementar o sistema 16

17 Análise dos riscos Encontrados os riscos, é preciso decidir o que fazer com eles Para tanto, vamos considerar a magnitude ou prioridade do risco e criar a lista dos 10 mais Magnitude = probabilidade * impacto 17

18 Estratégias para tratar os riscos Evitar reorganizar o projeto de modo que ele não seja afetado pela concretização do risco Transferir reorganizar o projeto de modo que outra pessoa/instituição fique responsável pelo risco Aceitar decidir conviver com o risco 18

19 Aceitando riscos Determinar um Plano de contingência (Plano B) Estabelecer ações para mitigar ou atenuar o risco Muitas vezes, resume-se a uma melhor investigação de algum ponto específico. Por exemplo: Risco: o protocolo escolhido para comunicação com o servidor pode não atender aos requisitos de desempenho do sistema Ação: implementar a comunicação com o servidor e testar o seu desempenho 19

20 Acompanhamento e controle dos riscos Definir um responsável por cada risco ou pelo grupo de riscos do projeto o pessimista Monitorar os indicadores relatórios de status dos riscos Deixar o caminho livre para notícias ruins Revisitar a lista de riscos periodicamente semanalmente ao final de cada iteração A gerência de riscos deve ser uma atividade contínua! 20

21 Os riscos no planejamento das iterações 21

22 Riscos e casos de uso A realização dos casos de uso é usada para eliminar riscos Para facilitar a visualização do relacionamento entre casos de uso e riscos, pode-se usar uma matriz de riscos 22

23 Matriz de Riscos UC 1 UC 2 UC 3 UC 4 Risco X Risco Y Risco Z 23

24 Riscos e iterações Lista de riscos Planejamento das iterações Atenuação dos riscos 24

25 3. Planejamento Iterativo Planejando as Fases e Iterações 25

26 Fluxos de atividades Planejamento e Gerenciamento Contratante Iniciar Projeto Aprovar Projeto Atestar Conclusão do Projeto Desenvolver Estudo de Viabilidade Identificar Riscos Executar Plano de Iteração Desenvolver Plano de Projeto Desenvolver Plano de Iteração Avaliar Iteração Finalizar Projeto Gerente de Projeto Reavaliar Riscos Arquiteto Priorizar casos de uso 26

27 Como definir a quantidade e duração das iterações? Iterar é bom, mas acrescenta certo overhead! planejamento avaliação sincronização de atividades A agilidade para iterar depende basicamente de: tamanho da equipe experiência com o processo A complexidade e conhecimento do produto também pesam padrões de ciclo de vida 27

28 Padrões de ciclo de vida Ferramenta para auxiliar no planejamento das fases Dependem das características do projeto Exemplos: Incremental Entrega incremental Evolucionário Híbridos 28

29 Para começar, não esqueça! Concepção Escopo, objetivos Elaboração Arquitetura Construção Operacionalidade (beta-releases) Transição Release (produtos) 29

30 Ciclo de vida incremental O domínio do problema é conhecido, familiar Os riscos estão bem entendidos e razoavelmente controlados A equipe é experiente C E Co Co Co Co T T 30

31 Ciclo de vida evolucionário O domínio do problema é novo ou desconhecido A equipe é inexperiente C E E E E Co T T 31

32 Entrega incremental O domínio do problema é conhecido, familiar Os requisitos e a arquitetura podem ser estabilizados bem cedo, durante o desenvolvimento (não existe muita novidade no sistema) A equipe é experiente É preciso liberar Releases incrementais do produto C E Co T T T T T 32

33 Grande Projeto Um pequeno conjunto de funcionalidades vai ser adicionado a um produto já estável As novas funcionalidades são bem conhecidas e entendidas A equipe é experiente, tanto no domínio do problema quanto no produto já existente E C Co T T 33

34 Estratégias Híbridas Na prática, poucos projetos seguem apenas uma dessas estratégias de ciclo de vida A regra geral é para sistemas: onde existe alto risco associado ao negócio do desenvolvimento: Ênfase na Concepção complexos ou onde não se tem domínio do problema: Ênfase na Elaboração onde se espera maior complexidade/esforço na produção de código: Ênfase na Construção onde é preciso entregar o produto em uma série de releases incrementais: Ênfase na Transição 34

35 Quantidade de iterações Projetos simples: 3/4 iterações [0/1, 1, 1, 1] Projetos típicos: 6 iterações [1, 2, 2, 1] Projetos grandes: 10 iterações [2, 3, 3, 2] Resumindo Em geral, planeja-se de 3 a 10 iterações! Na maioria dos casos temos de 6 a 8 iterações! 35

36 Duração das iterações Normalmente variam de fase para fase, de acordo com as características do projeto Iterações pequenas são típicas da Construção, com pouca ou nenhuma atividade formal de análise e projeto Iterações grandes demandam marcos (milestones) intermediários O tamanho da equipe e sua experiência com o processo é um dos fatores determinantes 36

37 Duração das iterações Alguns dados da Rational: Linhas de código Equipe Duração de 1 iteração semana mês meses ano 37

38 O quanto realizar de cada fluxo de atividades em cada fase/iteração? De maneira geral, em cada iteração um subconjunto do trabalho total é realizado levantado/especificado analisado e projetado implementado testado preparado para a distribuição/distribuído Como escolher esse subconjunto? conhecimento da equipe no domínio do problema e arquitetura a ser adotada necessidade de liberação de releases / deadline restrito 38

39 Estratégias para as iterações Larga e superficial Todo o domínio do problema é analisado, sem muitos detalhes Casos de uso: todos são definidos e a maioria é detalhada Arquitetura: definida amplamente todas as interfaces, serviços, etc. Pouca implementação até a Construção, onde fica o maior número de iterações Estreita e profunda Um pedacinho do domínio é analisado em detalhes Os casos de uso relacionados com este pedacinho são detalhados A arquitetura necessária para suportar esse pedacinho é definida Esse pedacinho é implementado, testado e possivelmente implantado Híbrida 39

40 Larga e superficial Apropriada quando: o time é inexperiente no domínio do problema ou nas tecnologias que serão usadas a arquitetura é inédita, ou é um requisito chave para as funcionalidades do sistema Possíveis problemas: analysis paralysis falta de credibilidade e confiança da equipe riscos técnicos não expostos devido a falta de detalhes (visão apenas de alto nível) 40

41 Estreita e profunda Apropriada quando: precisa-se de resultados muito rápido (para obter suporte, provar viabilidade ou eliminar certos riscos) os requisitos estão continuamente evoluindo o deadline é obrigatório existe alta reusabilidade Possíveis problemas: dificuldades de integração desenvolvimento de software integrado verticalmente, mas incompatível horizontalmente muito retrabalho devido a falta de uma visão geral do problema 41

42 Estatégia híbrida Na Concepção: larga e superficial para obter bom entendimento do escopo estreita e profunda para verificar a viabilidade de alguma tecnologia construção de um protótipo Na Elaboração: na maior parte do tempo, larga e superficial, para garantir que a arquitetura cobre todas as necessidades estreita e profunda em alguns pontos para atacar riscos específicos Na Construção: estreita e profunda, para implementar as funcionalidades do sistema, com alto grau de paralelismo e incrementalmente Na Transição: completar o que falta, de acordo com o feedback do usuário e bugs encontrados 42

43 Cronogramas iterativos e incrementais Bem mais complexos que os tradicionais cronogramas em cascata Normalmente organizados por fases e iterações 43

44 Cronogramas iterativos e incrementais Concepção Iteração 1 atividade X atividade Y atividade Z Elaboração Iteração 2 Iteração 3 Construção Iteração 4 Iteração 5 Iteração 6 Transição Iteração 7 O cronograma não é feito todo de uma vez! Lembre-se: o processo é iterativo! 44

45 Cronogramas iterativos e incrementais Concepção Iteração 1 atividade A atividade B atividade C Elaboração Iteração 2 atividade D atividade B atividade E Iteração 3 Construção Iteração 4 Iteração 5 Iteração 6 Transição Iteração 7 Devido a natureza do processo, várias atividades vão ficar repetidas As atividades serão as mesmas, mas com escopos/objetivos diferentes 45

46 Exemplo Planejamento do Innovative Rental System (IRS) 46

47 Características do projeto 1 Prazo total: 16 semanas Equipe de 5 pessoas, experiente no domínio do problema Equipe relativamente inexperiente no uso da metodologia Um dos objetivos do projeto é treinar os desenvolvedores no uso da metodologia Apoio de consultoria externa Estão previstos 2 releases do produto 47

48 Planejamento do projeto 1 Concepção Iteração preliminar de 2 semanas, larga e superficial, para iniciar o projeto Elaboração 1 iteração, de 5 semanas, para eliminar os principais riscos Estratégia híbrida: larga e superficial para modelar a arquitetura e estreita e profunda para eliminar o risco de alguns cenários Construção 2 iterações de 2 semanas cada, estreitas e profundas, para produzir a versao beta do sistema Transição 1 iteração de 2 semanas para finalizar a primeira versão do sistema, com parte das funcionalidades previstas 1 iteração de 3 semanas para incorporar as funcionalidades restantes e lançar a versão completa do IRS 48

49 Características do projeto 2 Prazo total: 16 semanas Equipe de 5 pessoas, experiente no domínio do problema, com pouco domínio tecnológico Equipe relativamente inexperiente no uso da metodologia Um dos objetivos do projeto é treinar os desenvolvedores no uso da metodologia Apoio de consultoria externa Estão previstos 1 releases do produto 49

50 Planejamento do projeto 2 Concepção Iteração preliminar de 2 semanas, larga e superficial, para iniciar o projeto Elaboração 1 iteração, de 3 semanas, para eliminar os principais riscos e modelar a arquitetura 1 iteração, de 2 semanas, para confirmar a arquitetura e a eliminação dos riscos Estratégia híbrida: larga e superficial para modelar a arquitetura e estreita e profunda para eliminar o risco de alguns cenários Construção 3 iterações de 2 semanas cada, estreitas e profundas, para produzir a versão beta do sistema Transição 1 iteração de 3 semanas para finalizar o sistema, com todas as funcionalidades previstas (versão completa do IRS) 50

51 Conclusão Planejamento Iterativo Conheça os riscos Planeje as fases duração e marcos (milestones) quantidade de iterações Planeje a primeira iteração em detalhes atividades, recursos, tempo, Durante a execução da primeira iteração, planeje a segunda em detalhes E assim por diante 51

52 Exemplo Plano de Iteração C1 52

53 Exemplo Plano de Iteração E1 53