1

Gerenciamento de Projeto: Visão Geral

Introdução

O Gerenciamento de Projeto de Software é a arte de confrontar os objetivos da concorrência, gerenciar riscos e superar obstáculos para liberar com êxito um produto que atenda às necessidades dos clientes (que pagaram por ele) e dos usuários. O fato de que tão poucos projetos sejam indiscutivelmente bem-sucedidos é o comentário suficiente sobre a dificuldade da tarefa.

Finalidade

A meta desta seção é facilitar a tarefa fornecendo algum contexto para o Gerenciamento de Projeto. Não se trata de uma receita de sucesso, mas apresenta uma abordagem para gerenciar o projeto que melhora notadamente a desigualdade da liberação de software bem-sucedido.

2

A finalidade do Gerenciamento de Projeto é:

• Fornecer um framework para gerenciar projetos intensivos de software. • Fornecer diretrizes práticas para planejar, montar a equipe, executar e monitorar os

projetos. • Fornecer um framework de gerenciamento de risco.

Entretanto, essa disciplina do Rational Unified Process (RUP) não tenta cobrir todos os aspectos do gerenciamento de projeto. Por exemplo, ela não cobre problemas como:

• Gerenciamento de pessoal: contratação, treinamento, ensino • Gerenciamento de orçamento: definição, alocação etc. • Gerenciamento de contratos, com fornecedores e clientes

Essa disciplina enfatiza principalmente os aspectos importantes de um processo de desenvolvimento iterativo:

• Gerenciamento de risco • Planejamento de um projeto iterativo, por meio do ciclo de vida e de uma iteração

particular • Monitoramento do progresso de um projeto iterativo, métrica

Conceber Novo Projeto

3

Avaliar Escopo e Risco do Projeto

Elaborar Plano de Desenvolvimento de Software

4

Planejar Próxima Iteração

Gerenciar Iteração

5

Monitorar e Controlar o Projeto

Finalizar Fase

6

Finalizar o Projeto

Visão Geral das Atividades

7

Artefatos

Fontes de Custos

Normalmente, os custos de desenvolvimento estão mais associados a despesas diretas de desenvolvimento, mas outras fontes também geram despesas relacionadas com o projeto:

• Coleta de requisitos • Gerenciamento do projeto • Teste • Gerenciamento do sistema, incluindo sistemas de desenvolvimento, de teste e de

implantação • Hardware e software iniciais para sistemas de desenvolvimento, de teste e de

implantação • Suporte à produção • Volumes de dados ou de transações que aumentaram o investimento em hardware para

suportá-los • Custos iniciais de implementação

o hardware o pacote de software o custos de instalação o custos de desenvolvimento e de teste o custo de execução de um piloto ou de um teste de aceitação o custos de implantação

• Custos operacionais contínuos o Custos da equipe operacional e de suporte o Custos de manutenção do sistema o Manutenção de hardware e software o Comunicações o Licenças de software o Custos ambientais

• Custos de expansão e de crescimento

8

o Hardware o Retrabalho/melhorias no software.

Lista de Riscos

"É fundamental estar sempre alerta." - Hamlet V:ii:215

Um projeto, como a vida, é incerto. Os riscos não são simplesmente identificados; eles devem ser identificados para que sejam previstos e diminuídos, se possível, ou para que sejam controlados quando houver poucas estratégias para a sua diminuição.

O risco controla os planos de iteração; as iterações são planejadas considerando riscos específicos na tentativa de limitar o risco ou reduzi-lo. A lista de riscos é revista periodicamente para avaliar a eficácia das estratégias de diminuição de riscos e, conseqüentemente, orientar as revisões no plano de projeto e nos planos de iteração subseqüentes.

O segredo do gerenciamento de risco é não esperar até que haja risco (e isso passe a ser um problema ou uma falha) para decidir o que fazer em relação a ele. Uma mudança de alguns graus no percurso de um vôo transcontinental produz um efeito significativo no local de aterrissagem do avião; de modo semelhante, gerenciar o risco antecipadamente é quase sempre menos dispendioso e penoso do que tentar solucioná-lo depois que virar um fato.

Estratégias de Gerenciamento de Riscos

Há três estratégias principais [Tipos de Riscos

É importante fazer a distinção entre riscos diretos e indiretos. Em poucas palavras, um risco direto é aquele que permite um certo grau de controle e o indireto é o que não pode ser controlado.

Embora não se possa ignorar os riscos indiretos, sua conseqüência é pequena no sentido prático: já que não é possível modificá-los, não perca tempo se preocupando com eles. O mundo pode acabar amanhã, mas também pode não acabar. Então, se não acabar, é melhor que o trabalho não pare.

Algumas vezes, um risco indireto pode realmente ser um risco direto disfarçado. Por exemplo, a dependência de um fornecedor externo em relação a um ou mais componentes. Isso parece ser um risco indireto, mas se forem desenvolvidos planos de contingência para esses componentes, será possível controlar o risco. Por exemplo, outros fornecedores alternativos podem ser escolhidos, ou a funcionalidade pode ser desenvolvida por conta própria. Em vários casos, temos mais controle do que imaginamos.

No caso dos riscos indiretos, você deve tentar obter algum tipo de controle sobre eles ou simplesmente reconhecê-los e continuar o trabalho. Não adianta se preocupar com uma situação que você não pode mudar.

Riscos dos Recursos

Organização

9

• Há um compromisso suficiente neste projeto (incluindo gerenciamento, testadores, QA e outras partes externas, porém envolvidas)?

• Este é o maior projeto desta organização? • Existe algum processo bem definido para a engenharia de software? Há captura e

gerenciamento de requisitos?

Fundos

• Os fundos estão disponíveis para a conclusão do projeto? • Os fundos foram alocados para treinamento e atuação como mentor? • Existe alguma limitação em termos de orçamento, por exemplo, existe algum custo

fixo estipulado para o sistema ou o sistema está sujeito a cancelamento? • As estimativas de custo são precisas?

Pessoal

• Há pessoal suficiente disponível? • Eles possuem capacidades e experiência apropriadas? • Eles já trabalharam juntos antes? • Eles acreditam no sucesso do projeto? • Há representantes dos usuários disponíveis para as revisões? • Há especialistas de domínio disponíveis?

Tempo

• A programação é realista? • A funcionalidade pode ser gerenciada pelo escopo para cumprir as programações? • Quando é a data de liberação? • Há tempo suficiente para "fazer tudo corretamente"?

Riscos do Negócio

• E se um concorrente conseguir obter primeiro a liderança no mercado? • E se os fundos para o projeto estiverem comprometidos (uma outra forma de fazer esta

pergunta é: "o que pode garantir fundos adequados")? • O valor projetado para o sistema é maior que o custo projetado? (não se esqueça de

considerar o valor temporal do dinheiro e o custo de capital). • E se não puderem ser feitos contratos com os principais fornecedores?

Riscos Técnicos

Riscos de escopo

• É possível medir o sucesso? • Existe algum consenso sobre como medir o sucesso? • Os requisitos são relativamente estáveis e foram bem compreendidos? • O escopo do projeto é estável ou continua sendo expandido? • As escalas de tempo de desenvolvimento do projeto são curtas e inflexíveis?

Riscos de tecnologia

10

• A tecnologia foi aprovada? • Os objetivos de reutilização são razoáveis?

o O artefato deve ser usado uma vez antes de ser reutilizado. o É possível que, somente após vários releases, um componente esteja estável o

suficiente para ser reutilizado sem causar mudanças significativas. • Os volumes de transações nos requisitos são razoáveis? • As estimativas de taxa de transação merecem crédito? Elas são muito otimistas? • Os volumes de dados são razoáveis? Os dados podem ser mantidos nos mainframes

atualmente disponíveis ou, se os requisitos levarem a crer que uma estação de trabalho ou um sistema departamental fará parte do design, os dados podem ser mantidos nesse local de forma razoável?

• Há requisitos técnicos diferentes ou desafiadores que exijam que a equipe de projeto resolva problemas com os quais não está familiarizada?

• O sucesso depende de produtos, serviços ou tecnologias novas ou não experimentadas, ou de hardware, software ou técnicas novas ou não aprovadas?

• Existem dependências externas das interfaces com outros sistemas, inclusive com os localizados fora da empresa? As interfaces necessárias existem ou devem ser criadas?

• Há requisitos de disponibilidade e segurança extremamente inflexíveis (por exemplo, "o sistema nunca deve falhar")?

• Os usuários do sistema são inexperientes em relação ao tipo de sistema que está sendo desenvolvido?

• Há um risco crescente devido ao tamanho ou à complexidade do aplicativo ou à inovação da tecnologia?

• Existe algum requisito para suporte ao idioma nacional? • É possível projetar, implementar e executar este sistema? Alguns sistemas são muito

grandes ou complexos para funcionarem apropriadamente.

Risco de dependência externa

• O projeto depende de outros projetos de desenvolvimento (paralelos)? • O sucesso depende dos produtos prontos ou dos componentes desenvolvidos

externamente? • O sucesso depende da integração bem-sucedida das ferramentas de desenvolvimento

(ferramentas de design, compiladores etc.), das tecnologias de implementação (sistemas operacionais, bancos de dados, mecanismos de comunicação entre processos etc.). Há algum plano de backup para liberar o projeto sem essas tecnologias?

Riscos de Programação

A experiência mostra que 85% dos riscos causam um impacto direto ou indireto na programação e, portanto, causam implicitamente um impacto no custo. É possível que 5% causem apenas um impacto no custo. O restante não causa impacto direto no custo nem na programação, mas, na qualidade, por exemplo.

Se o prazo de entrega for considerado um empecilho, faça liberações gradativamente. Evite fazer uma libreação maciça na tentativa de cumprir a programação.

Alguns projetos apresentam prazos realmente "inalteráveis". Um software usado para analisar "ao vivo" o resultado de uma eleição durante uma noite de eleição, por exemplo, terá pouco valor se for lançado na semana seguinte à eleição. O seu software também pode ser

11

engolido pelos concorrentes: eles lançam um produto melhor que o seu enquanto você ainda está no meio da construção do produto. De repente, você não está mais no jogo e não pode fazer quase nada em relação a isso. Entretanto, normalmente poucos projetos têm um prazo de entrega tão crítico. Os atrasos na maioria das vezes afetam o custo.

Em geral, faça com que o compromisso com a programação seja igual à melhor estimativa e considere alguma contingência razoável.

compromisso = estimativa + contingência

Algumas pessoas sugerem definir as expectativas de programação do mesmo modo que a estratégia de recuo, ou seja, baseá-las nos planos de contingência, porém isso é um pouco pessimista demais, pois nem todos os riscos irão realmente se concretizar.

Os riscos de programação são integrados a algumas ferramentas de estimativa e custo. Por exemplo, no modelo COCOMO (Constructive Cost Model), vários geradores de custo, como:

• complexidade (cplx) • restrições de tempo real (time) • restrições de armazenamento (stor) • experiência (Vexp) • disponibilidade de ferramentas apropriadas (tool) • pressão de programação (sced)

são fatores de risco reais.

Várias técnicas sofisticadas para o gerenciamento de riscos envolvem o uso da simulação de Monte Carlo, em que um número enorme de "cenários" são executados por uma ferramenta de simulação para calcular

Métricas

• As métricas devem ser simples, objetivas, fáceis de coletar, fáceis de interpretar e difíceis de interpretar incorretamente.

• A coleta das métricas deve ser automatizada e não-intrusiva, ou seja, não deve interferir nas atividades dos desenvolvedores.

• As métricas devem contribuir para a avaliação da qualidade no início do ciclo de vida, quando os esforços para melhorar a qualidade do software são eficazes.

• Tendências e valores absolutos de métricas devem ser usados ativamente pelas equipes de gerenciamento e de engenharia para informar o andamento e a qualidade em um formato consistente.

• A seleção de um conjunto mínimo ou mais extenso de métricas dependerá das características e do contexto do projeto. Se ele for grande ou tiver requisitos rigorosos de confiabilidade ou segurança e as equipes de desenvolvimento e avaliação tiverem um ótimo conhecimento sobre métricas, talvez seja útil coletar e analisar as métricas técnicas. O contrato pode exigir que determinadas métricas sejam coletadas ou a organização pode estar tentando aperfeiçoar habilidades e processos em áreas específicas. Não há uma resposta simples que se adapte a todas as circunstâncias. O Gerente de Projeto deve selecionar o que é apropriado quando o Plano de Métricas for

12

produzido. No entanto, quando você apresentar um plano de métricas pela primeira vez, convém manter a simplicidade, em vez de se arriscar e cometer erros.

Uma Taxonomia de Métricas

As métricas para determinados aspectos do projeto incluem:

• Andamento em termos de tamanho e complexidade. • Estabilidade em termos de taxa de mudança nos requisitos ou implementação,

tamanho ou complexidade. • Modularidade em termos do escopo de mudança. • Qualidade em termos da quantidade e do tipo de erros. • Maturidade em termos da freqüência de erros. • Recursos em termos de despesas do projeto versus despesas planejadas

As tendências são importantes e de alguma forma mais importantes de serem monitoradas do que qualquer valor absoluto no tempo.

Plano de Desenvolvimento de Software

O Plano de Desenvolvimento de Software é um artefato composto e abrangente que reúne todas as informações necessárias ao gerenciamento do projeto. Ele inclui vários artefatos separados, desenvolvidos durante a Fase de Iniciação, e é mantido durante todo o projeto.

• Determinação do Tempo de Cada Iteração

Uma iteração é definida como um mini-projeto completo, que passa por todas as principais disciplinas e resulta, na maioria dos casos, em um sistema executável, porém incompleto: um release. Embora o ciclo (edição, compilação, teste, depuração) pareça uma iteração, o significado aqui não é esse. Os builds diários ou semanais, que integram e testam gradativamente cada vez mais elementos do sistema, também podem parecer uma iteração, mas são apenas parte dela, conforme o uso do termo neste contexto.

A iteração inicia com planejamento e requisitos e termina com um release interno ou externo.

A rapidez da iteração depende, principalmente, do tamanho da organização do desenvolvimento.

Por exemplo:

• Cinco pessoas podem fazer um planejamento na segunda-feira de manhã, almoçar juntas todos os dias para monitorar o andamento do planejamento, realocar tarefas, iniciar o build na quinta-feira e concluir a iteração na sexta-feira à noite.

• Mas esse procedimento será muito difícil de ser executado por vinte pessoas. Mais tempo será gasto distribuindo o trabalho, sincronizando os subgrupos, integrando todos os elementos etc. Uma iteração poderá demorar três ou quatro semanas.

• Com quarenta pessoas, leva-se uma semana para "que o influxo nervoso vá da cabeça até as extremidades do corpo". Há níveis intermediários de gerenciamento, mas as

13

noções básicas comuns do objetivo necessitarão de uma documentação mais formal. Três meses, geralmente, é um tempo de iteração razoável.

Outros fatores exercem influência: o grau de familiarização da organização com a abordagem iterativa, incluindo uma organização experiente e estável, o nível de automação usado pela equipe para gerenciar códigos (por exemplo, CM distribuído), para distribuir informações (por exemplo, web interna),para automatizar testes etc.

Preste atenção também porque há uma sobrecarga fixa em uma iteração, em relação a planejamento, sincronização, análise dos resultados e assim por diante.

Portanto, por um lado, convencido dos enormes benefícios da abordagem iterativa, você pode ficar tentado a iterar constantemente, porém os limites humanos de sua organização diminuirão sua vontade.

Alguns dados empíricos:

SLOCs Número de desenvolvedores Duração de uma Iteração

10.000 5 1 semana

50.000 15 1 mês

500.000 45 6 meses

1.000.000 100 1 ano

• As iterações que duram mais de seis meses provavelmente precisarão de marcos intermediários para manter o projeto sob controle. Considere a redução do escopo da iteração para diminuir o tempo da iteração e garantir um enfoque mais nítido.

• As iterações que duram mais de doze meses são por si só arriscadas já que a iteração ultrapassa o ciclo de fundos anual. Um projeto que aparentemente não produziu nada nos últimos doze meses corre o risco de perder seus fundos.

• As iterações que duram menos de um mês requerem uma elaboração cuidadosa do escopo. Em geral, as iterações de curta duração são mais adequadas à fase de Construção, caracterizada pela inclusão de poucas funções novas e inovações. Essas breves iterações poderão gerar pouca ou nenhuma análise ou design formal, podendo simplesmente estar aprimorando gradativamente a funcionalidade já bem compreendida.

• As iterações não precisam ter necessariamente o mesmo tempo: o tempo varia de acordo com os objetivos. Em geral, as iterações de elaboração serão mais demoradas do que as de construção. Em uma fase, as iterações têm geralmente o mesmo tempo (facilitando o planejamento).

Quando tiver idéia do número de iterações no esboço de plano, você precisará definir o conteúdo de cada iteração. Recomenda-se inclusive dar um nome ou um título para qualificar o produto no fim de cada iteração, o que ajudará as pessoas a obter um melhor enfoque.

Exemplo: Iterações para um Comutador Telefônico Privado

• Iteração 1: chamada local.

14

• Iteração 2: acrescentar chamadas externas e gerenciamento de assinantes. • Iteração 3: acrescentar correio de voz e chamadas de conferência.

Determinação do Número de Iterações

Um projeto bem simples pode ter apenas uma iteração por fase:

• Uma iteração na fase de iniciação produzindo, talvez, um protótipo de prova de conceito ou um modelo de interface de usuário ou nenhuma iteração, no caso, por exemplo, de um ciclo de evolução.

• Uma iteração na fase de elaboração para produzir um protótipo de arquitetura. • Uma iteração na fase de construção para a criação do produto (até o release "beta"). • Uma iteração na transição para conclusão do produto (release de todo o produto).

Para obter um projeto mais substancial, a norma a ser seguida no ciclo de desenvolvimento inicial deve ser:

• Uma iteração na fase de iniciação (possivelmente com a produção de um protótipo). • Duas iterações na fase de elaboração; uma para um protótipo de arquitetura e a outra

para a baseline de arquitetura. • Duas iterações na fase de construção para expor um sistema parcial e amadurecê-lo. • Uma iteração na fase de transição para passar da capacidade operacional inicial para o

release de todo o produto.

No caso de um grande projeto, com várias questões desconhecidas, novas tecnologias etc., é possível que haja um caso para:

• uma iteração adicional na fase de iniciação, para permitir mais tempo para a produção de um protótipo.

• uma iteração adicional na fase de elaboração, para permitir a exploração de diferentes tecnologias.

• uma iteração adicional na fase de construção devido ao tamanho total do produto. • uma iteração adicional na fase de transição para permitir comentários sobre a

operação.

Portanto, durante um ciclo de desenvolvimento haverá:

• Baixo: 3 iterações [0,1,1,1] • Típico: 6 [1, 2, 2, 1] • Alto: 9 [1, 3, 3, 2] • Muito Alto: 10 [2, 3, 3, 2]

Em geral, planeje de três a dez iterações. Contudo, observe que os limites superior e inferior indicam circunstâncias fora do comum. Conseqüentemente, a maioria dos desenvolvimentos usará de seis a oito iterações.

São possíveis diversas variações, dependendo dos riscos, do tamanho e da complexidade:

• Se o produto for destinado a um domínio totalmente novo, será necessário acrescentar algumas iterações na fase de iniciação para consolidar os conceitos,

15

apresentar diversos modelos para uma seção cruzada de clientes ou usuários finais ou para obter uma resposta segura a uma solicitação de proposta.

• Se uma nova arquitetura tiver que ser desenvolvida ou se houver uma grande quantidade de modelagens de casos de uso, ou muitos riscos desafiadores, planeje duas ou três iterações na fase de elaboração.

• Se o produto for grande, complexo e desenvolvido durante um longo período de tempo, planeje três ou mais iterações na fase de construção.

• Planeje várias iterações na fase de transição se, para agilizar a comercialização, você tiver que liberar o produto com um conjunto menor de funções ou se achar que talvez precisará fazer várias pequenas adaptações na base de usuários finais após um período de uso.

Padrões de Iteração

Iterações de Iniciação

Na Iniciação, os maiores riscos geralmente são de negócios ou técnicos. No início, o principal risco de negócios normalmente é garantir o financiamento do projeto. Assim, um protótipo de prova de conceito costuma ser o resultado da fase de iniciação. Esse protótipo demonstra a funcionalidade básica ou alguns aspectos de tecnologia essenciais.

A primeira iteração de um novo produto costuma ser a mais difícil. Além de produzir o software, existem muitos novos aspectos que a primeira iteração precisa cumprir; por exemplo, organizar o processo, formar equipes, compreender um novo domínio, familiarizar-se com novas ferramentas, e assim por diante. Seja cauteloso em suas expectativas sobre quanto da arquitetura pode ser aprimorada ou sobre o grau de funcionalidade usável que pode ser alcançado. Se você for exigente demais nas expectativas, correrá o risco de adiar a conclusão da primeira iteração e reduzir o número total de iterações, diminuindo assim a vantagem de uma abordagem iterativa. As primeiras iterações devem se concentrar na obtenção da arquitetura adequada. Por isso, é preciso envolver os arquitetos de software no processo de planejamento das iterações iniciais.

Iterações de Elaboração

Na Elaboração, o foco das iterações é definir uma arquitetura estável, projetar e implementar o comportamento essencial do sistema e explorar as questões técnicas de arquitetura através de uma série de protótipos de arquitetura. Cenários "relevantes do ponto de vista da arquitetura" são subfluxos que testam a arquitetura do sistema ao definir caminhos.

Iterações de Construção e de Transição

Um pouco antes do término da Elaboração e durante a Construção e a Transição, as solicitações de mudança - também conhecidas como Pedidos de Mudança de Software ou SCOs (Software Change Orders) - começam a orientar o processo de iteração. As SCOs são provenientes de:

• solicitações de melhoria • solicitações de mudança cujo escopo ultrapasse a classe ou o pacote individual. • mudanças nos objetivos e no escopo da iteração.

16

• mudanças efetuadas nos requisitos propondo que a baseline de requisitos seja alterada ou acomodando uma mudança aceita na baseline de requisitos.

Essas SCOs são confrontadas em relação ao plano de projeto existente, aos planos de iteração e à lista de riscos existentes. Elas podem fazer com que a prioridade de requisitos seja reavaliada ou orientar a nova priorização de riscos. É necessário gerenciá-las com cuidado para não perder o controle do projeto.

Durante a Construção e a Transição, o mais importante é aprimorar a arquitetura e implementar todos os requisitos restantes.

Estratégias de Iteração

Ao contrário do modelo Cascata, no qual o sistema inteiro é considerado de uma só vez, aqui consideramos apenas uma parte da funcionalidade do sistema em cada iteração. Durante cada iteração, um subconjunto de todo o sistema é analisado, projetado e implementado. A escolha do que o subconjunto deverá representar e o grau de profundidade da análise são vitais para reduzir riscos nas iterações subseqüentes. Existem duas estratégias básicas: Ampla/Superficial e Limitada/Detalhada.

Ampla e Superficial

Na estratégia Ampla/Superficial, todo o domínio do problema é analisado, mas apenas os detalhes superficiais são considerados. Todos os Casos de Uso são definidos e a maioria deles é aprimorado para obter uma noção exata do problema. A arquitetura também é definida genericamente, e são definidos os principais mecanismos e serviços oferecidos pelos componentes de arquitetura. As interfaces de subsistemas são definidas; mas seu funcionamento interno é detalhado apenas em situações nas quais seja necessário gerenciar incertezas ou riscos significativos. Não há muitas implementações até a fase de Construção, quando ocorrem a maioria das iterações.

A estratégia Ampla/Superficial é apropriada quando:

• A Equipe é inexperiente em relação ao domínio do problema ou a uma área de tecnologia (incluindo metodologia ou processo).

• Uma arquitetura estável é um requisito fundamental para a capacidade futura e a arquitetura em questão é inédita.

No entanto, a estratégia apresenta algumas possíveis armadilhas:

• A equipe pode ser vítima da paralisia de análise (o sentimento ilógico de que, se o design não estiver perfeito, não será possível fazer nenhuma implementação).

• Em geral, os resultados iniciais são necessários para dar confiança e credibilidade; quanto mais tempo a equipe do projeto ficar sem produzir algo executável, menos confiante ela se sentirá sobre a capacidade de fazê-lo.

• Não são mostrados desafios e detalhes técnicos suficientes da arquitetura para que se possa ter uma idéia dos verdadeiros riscos técnicos.

Limitada e Detalhada

17

Na estratégia Limitada/Detalhada, um corte do domínio do problema é cuidadosamente analisado. Os Casos de Uso relacionados a esse corte limitado são definidos e aprimorados intensamente a fim de obter uma noção exata do problema. A arquitetura necessária para suportar o comportamento desejado é definida e o sistema é projetado e implementado. As iterações subseqüentes se concentram na análise, no projeto e na implementação de outros cortes verticais.

A estratégia Limitada/Detalhada é apropriada quando:

• Resultados iniciais precisam ser demonstrados para superar um risco predominante, obter suporte ou provar a viabilidade.

• Os requisitos evoluem continuamente, dificultando a definição completa de todos eles antes do início do design detalhado e do trabalho de implementação.

• O prazo de entrega é obrigatório, fazendo com que o início antecipado do desenvolvimento seja fundamental para uma liberação bem-sucedida.

• Um alto grau de reutilização é possível, permitindo um grau maior de liberação gradativa.

A estratégia possui suas desvantagens:

• Com essa estratégia, há uma tendência para que cada iteração desenvolva software integrado verticalmente, mas incompatível horizontalmente. Às vezes, isso é conhecido como síndrome da chaminé e dificulta a integração de sistemas.

• Ela não é adequada para desenvolver sistemas em um domínio de problema completamente novo ou baseado em uma arquitetura inédita, já que grande parte da funcionalidade de um sistema precisa ser testada para conseguir uma arquitetura equilibrada.

Lições Aprendidas com a Experiência

Em geral, as iterações iniciais seguirão uma estratégia mais do tipo Ampla/Superficial, enquanto as iterações posteriores (nas quais uma arquitetura estável terá sido desenvolvida) tendem a seguir a estratégia Limitada/Detalhada.

A primeira iteração costuma ser a mais difícil, pois requer que todo o ambiente de desenvolvimento e grande parte da equipe do projeto estejam posicionados. A integração de ferramentas e a formação da equipe tornam a primeira iteração ainda mais complexa. Concentrar-se nas questões de arquitetura pode ajudar a manter o foco e evitar que a equipe se atole em detalhes cedo demais.

Estratégias Híbridas

o Estratégia Limitada/Detalhada usada na Iniciação

É recomendável em situações nas quais explorar uma nova tecnologia é essencial para a viabilidade do projeto. Muitos projetos de comércio eletrônico exigem que novas tecnologias sejam exploradas em um grau bem maior do que o explorado tradicionalmente. O protótipo de prova de conceito ainda é considerado "descartável" e explora apenas a viabilidade do conceito do projeto.

18

o Estratégia Ampla/Superficial usada na Iniciação

Essa estratégia é utilizada para obter uma noção do escopo do sistema e testar a amplitude da funcionalidade do sistema, a fim de garantir que a arquitetura seja capaz de suprir a capacidade desejada.

o Estratégia Ampla/Superficial usada na Elaboração

Essa abordagem pode ajudar a desenvolver uma arquitetura estável, com foco Limitado/Detalhado seletivo para lidar com riscos técnicos específicos. Na Construção, com uma arquitetura estável estabelecida, o foco pode voltar a ser Limitado/Detalhado, quando a funcionalidade será desenvolvida e apresentada em uma série de incrementos integrados.

o Estratégia Limitada/Detalhada usada na Construção

As iterações da Construção são sempre Limitadas/Detalhadas, com equipes trabalhando paralelamente para desenvolver e apresentar a funcionalidade necessária.

Considerações Especiais para Novas Equipes

Em geral, as novas equipes são excessivamente otimistas no início com relação ao que podem realizar. Para combater isso e evitar possíveis problemas de ânimo que ocorrem quando os verdadeiros resultados não alcançam as expectativas otimistas, seja modesto na quantidade de funcionalidade que pode ser obtida na primeira iteração. Tente ganhar experiência e, ao mesmo tempo, criar um senso de realização e momento do projeto.

Se o ambiente de desenvolvimento e/ou os métodos forem novos para a equipe, reduza a funcionalidade da primeira iteração ao mínimo. Concentre-se na integração e no ajuste do ambiente, bem como no domínio das ferramentas. Aumente então o conteúdo da funcionalidade nas iterações subseqüentes.

Retrabalho Esperado

Até certo ponto, o retrabalho é válido. Uma das principais vantagens de um desenvolvimento iterativo é permitir erros e experimentações cedo o suficiente para que possam ser tomadas ações corretivas. No entanto, o pessoal técnico costuma 'banhar a ouro' ou refazer o trabalho até a perfeição entre as iterações.

No final de cada iteração, durante a avaliação, a equipe deverá decidir qual parte do release atual será refeita. Espere que o retrabalho seja alocado entre as fases nas seguintes porcentagens, em relação ao sistema como um todo:

• Iniciação: 40%-100% - esta é a fase em que você poderá desenvolver protótipos descartáveis e exploratórios

• Elaboração: 25%-60% nas iterações iniciais; menos de 25% nas iterações subseqüentes ou para um ciclo evolutivo.

• Construção: após a baseline de arquitetura, no máximo 10% por iteração e 25% no total.

• Transição: menos de 5%.

19

O retrabalho é inevitável. Suspeite quando ninguém achar que ele é necessário. Isso pode ser decorrente de:

• Cronograma com pressão excessiva. • Ausência de testes ou avaliações reais. • Ausência de motivação ou foco. • Percepção negativa do retrabalho como sendo um desperdício de recursos ou uma

admissão de incompetência ou falha.

O excesso de retrabalho é alarmante. Ele pode ser proveniente de uma atitude perfeccionista ou de um nível inaceitável de mudanças de requisitos. Um caso de negócio deverá ser criado para avaliar a necessidade de retrabalho.

Observe que não incluímos o trabalho removido do escopo da iteração anterior (em decorrência da abordagem do tipo timebox em relação ao gerenciamento de iterações) na categoria de 'retrabalho'. O Gerente de Projeto deverá incluir esse trabalho removido do escopo no conjunto de funcionalidades a partir do qual será definido o conteúdo da próxima iteração. É óbvio que esse trabalho certamente terá alta prioridade. O Gerente de Projeto também deverá descobrir e considerar com cuidado os motivos da falha da iteração anterior para alcançar as metas planejadas. Por exemplo, apesar de não recomendarmos a inclusão aleatória de pessoal em uma tentativa desesperada de cumprir um cronograma, a condução de um projeto com uma constante escassez de pessoal - e a elaboração, ao mesmo tempo, de planos ambiciosos para cada iteração - também não é nada sensata. Isso geralmente diminui o ânimo da equipe e deixa o cliente enfurecido. É necessário encontrar o equilíbrio adequado. Para isso, modelos de estimativa como o COCOMO II (Construct Cost Model) podem ser úteis.

Quando o plano de iteração do primeiro segmento estiver concluído, os líderes das equipes, talvez em conjunto com o gerente do projeto, poderão transformá-lo em um plano de trabalho no nível de atividade.