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 uma primeira iteração precisa cumprir. Por exemplo, organizar o processo, formar equipes, compreender um novo domínio, familiarizar-se com novas ferramentas e outros. 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. Os cenários "arquiteturalmente significativos" 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 \endash também conhecidas como Pedidos de Mudança de Software ou SCOs (Software Change Orders) \endash começam a orientar o processo de iteração. Os SCOs resultam do seguinte:

• 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.
• 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. Há 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

Na estratégia Limitada/Detalhada, uma fatia do domínio do problema é cuidadosamente analisado. Os Casos de Uso relacionados a essa fatia limitada 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 outras fatias 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 final é 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 do sistema.
• 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

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

  Para situações em que a exploração de uma nova tecnologia é essencial para a viabilidade fundamental do projeto. Muitos projetos de e-business requerem 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 simplesmente a viabilidade do conceito do projeto.

• 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.

• 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.

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

  As iterações de 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. {\lang1033 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 de evolução.
• Construção: após a baseline de arquitetura, no máximo 10% por iteração e 25% no total.
• Transição: menos de 5%.

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 'delimitado por tempo' 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 arbitrária de equipe em uma tentativa desesperada de atender a um planejamento, a execução de um projeto com uma constante escassez de equipe - 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 (consulte [BOE00]) podem ser úteis. Com cada iteração, um projeto cria um histórico de realizações, tanto de produtividade como de qualidade. No planejamento da próxima iteração, um forte indicador para um Gerente de Projeto é o que foi alcançado na iteração anterior.

Nível de Planejamento

Quando o plano de iteração do primeiro segmento estiver concluído, os líderes das equipes, talvez em conjunto com o coordenador de projeto, poderão refiná-lo em um plano de trabalho no nível de tarefa. Os Gabaritos de Projeto da Microsoft® (no nível de tarefa) mostram como isso apareceria. Observe, entretanto, que esses planos de trabalho são resultantes do plano de iteração; não são produtos de trabalho independentes, produzidos separadamente. É importante, se o coordenador de projeto for exercer o controle, que os planos de trabalho possam ser acumulados para refletir o status do plano de iteração dele.