Atividade:  Desenvolver Plano de Iteração

A iteração é um conjunto de tarefas que devem ser executadas em um período de tempo fixo (entre duas e quatro semanas), focado em produzir um executável. Para todas as iterações, exceto a última da fase de transição, este executável é um produto que contém apenas um subconjunto das funcionalidades requeridas. O foco na produção de um executável força a integração contínua do produto e permite que o projeto ataque cedo os riscos técnicos, diminuindo assim outros riscos associados a eles.

Trabalhar iterativamente implica uma certa quantidade de retrabalho dos artefatos existentes e, juntamente com isso, uma mudança de atitude em relação ao retrabalho. Uma certa dose de retrabalho é necessária para entregar um produto de qualidade: construindo produtos intermediários e avaliando a adequação da arquitetura do produto cedo e freqüentemente, aumenta-se a qualidade do produto final e mudanças são menos custosas e mais fáceis de implementar.

Determinar o Escopo da Iteração

A equipe, em conjunto com representantes do cliente ou especialistas do negócio, deve escolher os casos de uso e requisitos não-funcionais que serão trabalhados durante a iteração. Esta escolha deve ser guiada por cinco fatores:

• Riscos do projeto: um dos objetivos do desenvolvimento iterativo é diminuir os riscos do projeto. Isto é feito atacando-se os riscos o mais cedo possível, pois, quanto mais cedo os riscos forem eliminados, maiores as chances do sucesso. Por isso, é importante escolher casos de uso cujo desenvolvimento force a equipe a enfrentar os maiores riscos existentes.
  
  
• Valor para o negócio: além dos riscos, é extremamente importante levar em consideração que funcionalidades do sistema oferecem maior valor para o usuário. Este fator muitas vezes conflita com o fator Riscos do projeto, pois o cliente priorizará os casos de uso que mais agregam valor ao negócio, e a equipe do projeto, os que apresentam maior risco técnico. É necessário chegar a um meio-termo entre estes fatores. A equipe tem obrigação de manter o cliente ciente dos eventuais riscos que está assumindo, caso decida adiá-los em detrimento de funcionalidades menos arriscadas, mas deve aceitar a escolha feita por ele. Satisfazer as necessidades do cliente deve ser o objetivo principal.
  
  
• Velocidade da equipe: a quantidade de casos de uso a serem desenvolvidos em uma iteração depende da velocidade da equipe, ou seja, quantos casos de uso e de que complexidade a equipe é capaz de desenvolver em uma iteração. É importante saber qual a real capacidade de desenvolvimento, para que não sejam assumidos compromissos que não serão cumpridos. As medições possuem um papel fundamental neste ponto. É extremamente importante acompanhar quanto a equipe consegue produzir, em média, por iteração, e não se comprometer com mais trabalho do que se consegue realizar.
  
  
• Cobertura dos casos de uso: outro fator que deve ser levado em conta, principalmente nas iterações iniciais, é a cobertura do sistema, ou seja, desenvolver casos de uso que lidem com as mais variadas partes do sistema possível, ainda que em cenários simples. Isto é importante para se ter uma idéia do todo e descobrir eventuais riscos que não tenham sido levantandos ou novas necessidades que não tenham sido descobertas na disciplina de Requisitos..
  
  
• Os objetivos da fase atual: dependendo da fase em que o projeto se encontra, alguns objetivos devem ser cumpridos. Estes objetivos também devem ser levados em conta na escolha dos casos de uso. Na fase de Elaboração, por exemplo, deve-se procurar estabelecer uma arquitetura robusta para o sistema. Para maiores detalhes, veja o Guia: Definindo o Escopo de Acordo com a Fase

Definir Atividades da Iteração

Com base nos objetivos da iteração, deve-se determinar que atividades devem ser executadas para cumpri-los. Tipicamente, cada iteração irá passar, ainda que parcialmente, por todas as atividades do processo de desenvolvimento, por exemplo:

• Casos de uso e cenários que representam a funcionalidade requerida são escolhidos;
• O comportamento do caso de uso (ou cenário) é pesquisado e documentado;
• O comportamento é analisado e alocado entre os subsistemas e classes que provêem o comportamento necessário;
• As classes e subsistemas são projetados, implementados e testados unitariamente;
• O sistema é integrado e testado como um todo;
• Para releases externo, o produto é preparado e é feita sua transição para o ambiente do usuário.

O grau em que estas atividades são executadas varia conforme a iteração e a fase do projeto. Cada uma das disciplinas (Requisitos, Análise e Projeto, Testes, etc.) define atividades genéricas, que devem ser adaptadas para a organização durante a configuração do processo.

Identificar Atividades Envolvidas e Artefatos Afetados

Após ter escolhido os cenários ou casos de uso (mais os defeitos a serem consertados), o Gerente de Projeto precisa determinar que atividades serão necessárias e que artefatos serão afetados:

• Que classes precisam ser revistas?
• Que subsistemas serão afetados ou criados?
• Que interfaces provavelmente serão modificadas?
• Que documentos devem ser atualizados?

Para fazer isto, toda a equipe deve estar reunida e realizar um brainstorming das atividades necessárias para desenvolver cada caso de uso ou cenário escolhido.A participação de todos no planejamento é importante para garantir que nenhuma atividade será esquecida, já que quem realmente as realiza está presente, e para aumentar a motivação da equipe e o comprometimento com o plano, pois todos participam ativamente de sua construção e têm direito a expressar sua opinião.

As atividades devem ser determinadas com base no processo utilizado pela equipe. Caso seja detectado que uma atividade necessária não está no processo, deve-se registrar uma Requisição de Mudança para a melhoria do processo, que será avaliada na Atividade: Avaliar Iteração.

Algumas atividades, como esta, são realizadas uma vez a cada iteração. Outras, como Modelar Interface com o Usuário, podem ser realizadas para cada caso de uso, ou cada subsistema. Se houver uma atividade muito abrangente, ou seja, que irá envolver um grande número de passos ou de artefatos, ela pode ser dividida em atividades menores. Isto facilita tanto as estimativas quanto a divisão de responsabilidades.

Além das atividades de desenvolvimento dos casos de uso, podem haver outras que não estão relacionadas diretamente a um caso de uso específico, como "configurar o servidor de aplicação" ou "atualizar o banco de dados". Elas também devem ser levadas em conta no planejamento.

Estimar Tarefas e Dividir Responsabilidades

Uma vez definido o conjunto de atividades da iteração, é preciso estimar a duração de cada uma e dividi-las entre a equipe do projeto. Estes dois passos são feitos em paralelo. Cada membro da equipe escolhe uma tarefa que deseja realizar e diz quanto tempo levará para completá-la. Isto é repetido até que todos os membros da equipe estejam com o máximo de trabalho que possam realizar ou até que não haja mais tarefas.

No primeiro caso, onde nota-se não haverá tempo para realizar todas as tarefas, deve-se reduzir o escopo da iteração em vez de estender sua duração, pois as iterações devem ter a duração fixa (timeboxing), ditando o ritmo do desenvolvimento. Depedendo da fase em que o projeto se encontra, torne os cenários mais simples ou elimine algumas funcionalidades. No segundo caso, menos provável de acontecer, deve-se incluir mais casos de uso na iteração atual, retornando-se ao primeiro passo desta atividade.

Ao final da divisão das atividades, deve-se verificar se não há ninguém da equipe sobrecarregado. Caso haja, deve-se remanejar as tarefas para desenvolvedores menos ocupados. Atividades que não foram escolhidas por ninguém também devem ser distribuídas entre as pessoas que estão mais livres. De preferência, elas devem escolher, dentre as que restaram, as que preferem realizar.

Como resultado da divisão de tarefas, cada membro da equipe deve ter sua Ordem de Trabalho, que irá listar as atividades  de sua responsabilidade e  as respectivas estimativas. Dependências externas e de outras tarefas também pode estar listadas.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process