O escopo de uma iteração é orientado por cinco fatores: 

• os principais riscos do projeto
• a funcionalidade necessária ao sistema
• o tempo alocado para a iteração no Plano de Projeto
• a fase e seus objetivos específicos (Consulte Conceito: Fase)
• o valor criado no projeto

No planejamento inicial de uma iteração, um volume suficiente de trabalho é selecionado para preencher o tempo já planejado para a iteração - embora o Coordenador de Projeto tenha alguma liberdade para explicar as restrições de recursos e outras questões táticas no momento em que o Plano de Iteração está sendo desenvolvido. Obviamente, o trabalho planejado para a iteração anterior e que ainda não foi concluído (porque o escopo da iteração anterior foi reduzido para atender à programação) terá alta prioridade.

O escopo do trabalho também tem que ser definido por uma abordagem que aproveite ao máximo o nível da equipe durante a iteração. Por exemplo, em geral, não é possível duplicar o trabalho concluído por uma iteração dobrando a equipe, mesmo que esses recursos estejam disponíveis. O número aproximado de membros da equipe que podem ser utilizados com eficiência é determinado pelo tamanho geral do software e sua arquitetura e modelos de estimativa, como COCOMO II (consulte [BOE00]) podem fornecer essa informação.

A execução de uma iteração é, então, gerenciada por timeboxing - , ou seja, o escopo e a qualidade (em termos dos defeitos descobertos não corrigidos) são ativamente gerenciados para atenderem a data de encerramento.

Na Fase de Elaboração:

Três drivers principais definem os objetivos de uma iteração na fase de elaboração:

• Risco
• Importância (criticalidade)
• Cobertura

O driver principal para a definição de objetivos da iteração são riscos. É preciso diminuir ou eliminar os riscos o mais cedo possível. Essa é, em geral, a questão principal da fase de elaboração, quando a maioria dos riscos deve ser diminuída. No entanto, ela pode continuar sendo um elemento-chave durante a fase de construção, já que alguns riscos permanecem altos e outros novos são descobertos. Entretanto, o objetivo da fase de elaboração é criar a linha de base da arquitetura, algumas outras considerações devem ser feitas, como garantir que a arquitetura englobe todos os aspectos do software a ser desenvolvido (cobertura). Isto é importante, pois a arquitetura será usada para planejamento adicional: organização da equipe, avaliação do código a ser desenvolvido, etc.

Finalmente, apesar da importância de concentrar-se nos riscos, não se esqueça das missões principais do sistema; solucionar todos os problemas severos é aconselhável, mas isto não deve ser feito em detrimento da funcionalidade núcleo: certifique-se de que as funções ou os serviços críticos do sistema estejam realmente cobertos (criticalidade), mesmo que nenhum risco associado a eles seja percebido.

Na Lista de Riscos, para os riscos que causam maiores danos, identifique algum cenário em alguns casos de uso que force a equipe de desenvolvimento a "confrontar" o risco.

Exemplos

• se houver algum risco de integração, como "banco de dados D funcionando corretamente com S.O. Y", certifique-se de incluir um cenário que envolva alguma interação do banco de dados, mesmo que seja bem reduzida.
• se houver algum risco de desempenho, como "tempo para calcular a trajetória da aeronave", certifique-se de ter um cenário que inclua esse cálculo, pelo menos para o caso mais óbvio e freqüente.

Quanto à criticalidade, garanta que as funções ou os serviços mais fundamentais fornecidos pelo sistema sejam incluídos. Selecione algum cenário no caso de uso que represente a forma mais comum e freqüente do serviço ou da característica oferecidos pelo sistema. Para auxiliar na determinação da escala de criticalidade entre as funcionalidades e serviços a serem implementados, devem ser levadas em consideração as proposições de valor levantadas entre os interessados.

O Documento de Arquitetura de Software é utilizado para orientar esse esforço, fornecendo um conjunto priorizado de Casos de Uso ou subfluxos de casos de uso, selecionado pelo Arquiteto de Software, para refletir os casos de uso ou cenários significativos de forma arquitetural.

Exemplo

• no caso de uma central telefônica, uma chamada comum estabelecida entre estações é o elemento óbvio para uma iteração inicial. O estabelecimento correto dessa condição inicial é mais importante do que os modos complexos de falha na configuração do operador do subsistema de tratamento de erros.

Para a cobertura, ao final da fase de elaboração, inclua cenários que abordem as áreas que precisarão de desenvolvimento, embora elas não sejam críticas nem apresentem riscos.

Costuma ser mais econômico criar cenários longos, de ponta a ponta, que englobem várias questões de uma vez.

Em geral, o perigo consiste em cenários muito "densos" , ou seja, aqueles que tentam cobrir demasiados aspectos, variantes e casos de erros diferentes (Consulte Plano de Iteração)

Além disso, na fase de elaboração, lembre-se de que a natureza de alguns riscos pode ser mais humana ou programática: cultura de equipe, treinamento, seleção de ferramentas, técnicas novas e outros. O prosseguimento da iteração consiste na diminuição desses riscos.

Exemplos

1. Crie um registro de assinante em uma estação de trabalho cliente, a ser armazenado no banco de dados do servidor, incluindo diálogo do usuário, mas não incluindo todos os campos e assumindo que nenhum erro foi detectado.
   Combina alguma função crítica com alguns riscos de integração (banco de dados e software de comunicação) e questões de integração (trabalhar com duas plataformas diferentes). Também força os designers a se familiarizarem com a nova ferramenta de design da interface gráfica do usuário. Por fim, produz um protótipo que pode ser demonstrado ao usuário para feedback.
2. Certifique-se de que até 20.000 assinantes possam ser criados e de que o acesso a um deles não dure mais do que 200 milissegundos.
   Aborda algumas questões fundamentais de desempenho (volume ou dados e tempo de resposta), que podem afetar dramaticamente a arquitetura se não forem solucionadas.
3. Desfazer uma alteração do endereço do assinante.
   Um simples recurso que força os designers a elaborarem um design de todas as funções "desfazer". Por outro lado, também pode apresentar alguma desvantagem para os usuários, no sentido do que pode ser desfeito por um custo razoável.
4. Complete todos os casos de uso relativos ao gerenciamento da cadeia de suprimentos.
   O objetivo da fase de elaboração também é concluir a captura de requisitos, que pode ser feita conjunto a conjunto.

Na Fase de Construção:

À medida que o projeto passa para a fase de construção, os riscos continuam sendo um impulsionador importante, principalmente porque riscos novos e imprevisíveis são descobertos. No entanto, a conclusão do caso de uso começa a ser também um impulsionador. Cada característica das iterações pode ser planejada, na tentativa de concluir as mais críticas antes, para que possam ser totalmente testadas durante mais de uma iteração. Próximo ao fim da fase de construção, a resistência de casos de uso completos será o principal objetivo.

Exemplo

1. Implemente todas as variantes de encaminhamento de chamada, inclusive as erradas.
   Esse é um conjunto dos recursos relacionados. Uma delas pode ter sido implementada durante a fase de elaboração e servirá como protótipo para o resto do desenvolvimento.
2. Complete todas as características do operador telefônico, exceto o serviço noturno.
   Mais um conjunto de recursos.
3. Obtenha 5.000 transações por hora em uma configuração de dois computadores.
   Isto pode progredir até o desempenho necessário relativo ao que foi realmente obtido na iteração anterior (somente 2.357/hora)
4. Integrar nova versão do Geographical Information System.
   Essa pode ser uma pequena mudança arquitetural, exigida por algum problema descoberto anteriormente.
5. Corrija todos os defeitos dos níveis 1 e 2
   Corrige os defeitos descobertos durante os testes na iteração anterior e que não foram corrigidos imediatamente, mas adiados.

Na Fase de Transição:

O objetivo principal é a conclusão da construção do produto. Os objetivos de uma iteração são definidos em termos dos bugs que serão solucionados, das melhorias de desempenho ou de utilização que serão incluídas. Se recursos precisaram ser eliminados (ou desativados) para manter o prazo final da construção (marcos de IOC ou "beta"), eles poderão ser concluídos agora ou ativados, caso não comprometam o que já foi obtido até o momento.

Exemplos

1. Corrija todos os problemas de gravidade 1 descobertos em locais beta do cliente.
   Um objetivo em termos de qualidade pode estar relacionado à credibilidade no mercado.
2. Elimine todos os travamentos de inicialização devido à incompatibilidade de dados.
   Outro objetivo expresso em termos de qualidade.
3. Alcance 2,000 transações por minuto.
   Ajuste de desempenho, envolvendo alguma otimização: mudança de estrutura de dados, armazenamento em cache e algoritmos mais inteligentes.
4. Reduza em 30% o número das diversas caixas de diálogo.
   Melhore a utilização reduzindo a interferência visual
5. Produza versões em alemão e japonês.
   A versão beta foi produzida apenas para os clientes do idioma inglês por falta de tempo e para reduzir a carga de retrabalho.

Cada iteração resulta em um release executável. Em geral, o release não é de alta qualidade (exceto no final da iteração de Transição), mas, ainda assim, pode ser avaliado.

Avaliando Iterações de Iniciação

Em geral, a iteração de Iniciação enfoca a prova de conceito do produto e a criação do suporte necessário à aprovação de fundos para o projeto. Como conseqüência, o release da Iteração é, geralmente, um protótipo de prova de conceito, que ainda não teve um verdadeiro código de implementação sob uma camada superficial da interface com o usuário. Os critérios de avaliação são orientados para a aceitação do usuário e medidas qualitativas.

Além disso, a perspectiva de criação de valor pelo projeto deve estar bem clara. Nesse sentido, cabe verificar se:

• A análise de realização dos benefícios esperados deve ter sido realizada, de forma a se confirmar a inserção do projeto, de acordo com seu macro-escopo definido, na estratégia de negócios da organização.
• As proposições de valor para o produto final, percebidas pelos interessados, devem estar identificadas e conflitos entre as proposições devem ter sido conciliados.

Em algumas circunstâncias, questões técnicas importantes devem ser solucionadas na fase de abertura, antes da liberação do financiamento do produto. Nesse caso, os critérios de avaliação devem refletir esse aspecto.

Avaliando Iterações de Elaboração

As Iterações de Elaboração enfatizam a criação de uma arquitetura estável. Conseqüentemente, os critérios da avaliação da fase de Elaboração devem enfocar a avaliação da estabilidade da arquitetura. As medidas que podem ser usadas são:

• Estabilidade (ou quebra) da interface
• A taxa de mudanças efetuadas na Arquitetura (comparadas a uma linha de base arquitetural)
• Desempenho de funcionalidade-chave

O objetivo-chave é garantir que as mudanças efetuadas durante a fase de Construção não se propaguem pelo sistema, causando excesso de retrabalho. Para isso, as decisões arquiteturais devem contemplar critérios como a ponderação utilidade dessas decisões em relação aos interessados, de forma a selecionar as alternativas que agreguem mais valor no que se refere à estabilidade da arquitetura. 

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

As iterações de Construção e Transição são medidas durante os testes tradicionais de software e dimensões de gerenciamento de mudanças, como quebra, densidade do defeito e taxas de detecção de falhas. A ênfase dessas iterações está em encontrar erros para que eles possam ser solucionados.

Os erros são descobertos de diversas maneiras: inspeções e revisões de código, testes funcionais, testes de desempenho e testes de carga. Cada técnica é orientada para a descoberta de determinado conjunto de defeitos e cada uma tem seu espaço. As especificações dessas técnicas serão abordadas na disciplina Teste do Rational Unified Process (RUP).

Baseado nas metas da iteração, o conjunto de tarefas a serem realizadas durante a iteração deve ser selecionado. Normalmente, cada iteração percorrerá parcialmente todas as tarefas do ciclo de vida do software:

• Os casos de uso e os cenários selecionados que testam a funcionalidade requerida
• O comportamento do caso de uso (ou do cenário) é pesquisado e documentado
• O comportamento é analisado e alocado entre os subsistemas e classes que apresentam esse comportamento necessário
• As classes e os subsistemas são projetados, implementados e testados por unidade
• O sistema é integrado e testado como um todo
• Para os releases externos (alfa, beta e disponibilidade geral), o produto é empacotado em uma forma apresentável e que pode ser utilizado no ambiente do usuário.

O grau de realização dessas tarefas varia de acordo com a iteração e a fase do projeto. As disciplinas individuais (Requisitos, Análises & Design, Testes, etc.) definem as tarefas genéricas que, por sua vez, são adaptadas à organização durante a configuração do processo.

Identificar os Produtos de Trabalho Afetados e as Tarefas Envolvidas

Depois que os cenários ou os casos de uso completos que serão desenvolvidos (e os defeitos que serão corrigidos) forem selecionados e rapidamente esboçados, será preciso identificar os produtos de trabalho que serão afetados:

• Que classes serão revistas?
• Que subsistemas serão afetados ou mesmo criados?
• Que interfaces serão provavelmente modificadas?
• Que documentos têm que ser atualizados?

Em seguida, retire das disciplinas de processo as tarefas envolvidas e insira-as em seu plano. Algumas tarefas são realizadas uma vez por iteração (exemplo), outras têm que ser realizadas uma vez por classe, por caso de uso, por subsistema (exemplo). Conecte as tarefas às suas dependências óbvias e aloque algum esforço estimado. A maioria das tarefas descritas para o processo são pequenas o suficiente para serem realizadas por uma pessoa ou por um pequeno grupo em um período que pode variar de algumas horas a alguns dias.

É provável que o caso descoberto não tenha tempo suficiente para ser completamente desenvolvido na fase de iteração. Em vez de estender a iteração (e, portanto, adiar o prazo final de liberação ou reduzir o número de iterações), reduza os objetivos da iteração. Dependendo da fase em que você está, simplifique cenários, elimine ou desative características.

Depois de definido o conjunto de tarefas para a iteração, ele deve ser designado a membros individuais da equipe do projeto. Dependendo dos recursos da equipe disponíveis e do escopo da iteração, as tarefas podem ser realizadas por uma única pessoa ou por uma equipe. Naturalmente, Revisões e Inspeções são tarefas de equipe. Outras tarefas, como a autoria de casos de uso ou o design e a implementação de classes são inerentemente isoladas (exceto no caso em que um membro júnior da equipe trabalhe com um sênior que atue como mentor).

Em geral, cada produto de trabalho deve ser de responsabilidade de uma única pessoa, mesmo que o trabalho seja feito por uma equipe:

• Casos de uso
• Subsistemas
• Classes
• Testes e planos de teste
• etc.

Sem um único ponto de contato, garantir a consistência torna-se quase impossível.