Planejamento e Gerenciamento Iterativo de Projetos de Software

1

1. Introdução

Motivação e Conceitos Básicos

2

Preocupações do Gerente de TI

Melhorar a qualidade do desenvolvimento de software

Principais riscos e incertezas no desenvolvimento de sistemas

3

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

Qual é o objetivo do gerente de projetos?

5

Desenvolver o produto esperado dentro do prazo, custo e nível de

qualidade desejados

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%

6

Fonte: Standish Group, 1995.

7

Planejamento e gerenciamento é para torná-lo parte do % de

sucesso!!!

Engenharia de Software

Fator Humano Estratégias do Negócio

Parkinson’s effect

O trabalho se expande de modo a preencher todo o tempo disponível para executá-lo

8

Se a equipe sentir que tem tempo disponível vai gastá-lo,

contribuindo para elevar os riscos do projeto!

2. Considerando os Riscos

9

“Não se preocupe; eu vou pensar em algo…”, Indiana Jones

10

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

Gerenciamento de riscos

12

Identificação

Análise

Acompanhamento e controle

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

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

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

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

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”

17

Magnitude = probabilidade * impacto

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

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:

19

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

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

20

A gerência de riscos deve ser uma atividade contínua!

Os riscos no planejamento das iterações

21

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

Matriz de Riscos

UC 1 UC 2 UC 3 UC 4

Risco X

Risco Y

Risco Z

23

Riscos e iterações

24

Lista de riscos

Planejamento das iterações

Atenuação dos riscos

3. Planejamento Iterativo

Planejando as Fases e Iterações

25

Fluxos de atividades Planejamento e Gerenciamento

26

Contratante

Aprovar Projeto

Iniciar Projeto Atestar Conclusão

do Projeto

Gerente de Projeto

Identificar Riscos

Desenvolver Plano de Projeto

Desenvolver Plano de Iteração

Executar Plano de Iteração

Avaliar Iteração

Reavaliar Riscos

Finalizar Projeto

Arquiteto

Priorizar

casos

de uso

Desenvolver Estudo de Viabilidade

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

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

Para começar, não esqueça!

29

Concepção

Elaboração

Transição

Escopo, objetivos

Construção

Arquitetura

Operacionalidade (beta-releases)

Release (produtos)

Ciclo de vida incremental

O domínio do problema é conhecido, familiar

Os riscos estão bem entendidos e razoavelmente controlados

A equipe é experiente

30

C E Co Co Co Co T T

Ciclo de vida evolucionário

O domínio do problema é novo ou desconhecido

A equipe é inexperiente

31

C E E E E Co T T

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

32

C E Co T T T T T

“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

33

E C Co T T

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:

complexos ou onde não se tem domínio do problema:

onde se espera maior complexidade/esforço na produção de código:

onde é preciso entregar o produto em uma série de releases incrementais:

34

Ênfase na Concepção

Ênfase na Construção

Ênfase na Elaboração

Ênfase na Transição

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…

35

Em geral, planeja-se de 3 a 10 iterações!

Na maioria dos casos temos de 6 a 8 iterações!

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

Duração das iterações

Alguns dados da Rational:

37

Linhas de código

Equipe Duração de 1 iteração

10.000 5 1 semana

50.000 15 1 mês

500.000 45 6 meses

1.000.000 100 1 ano

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

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

39

Híbrida

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

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

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

Cronogramas iterativos e incrementais

Bem mais complexos que os tradicionais cronogramas em cascata

Normalmente organizados por fases e iterações

43

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!

44

Lembre-se: o processo é iterativo!

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

45

As atividades serão as mesmas, mas com escopos/objetivos

diferentes

Exemplo – Planejamento do Innovative Rental System (IRS)

46

Características do projeto1

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

Planejamento do projeto1 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

Características do projeto2

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

Planejamento do projeto2 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

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

51

E assim por diante…

Exemplo Plano de Iteração C1

52

Exemplo Plano de Iteração E1

53