Atividade:  Agendar e Atribuir Trabalho

O Plano de Iteração, preparado no início da iteração, só pode selecionar o que é conhecido naquele momento, ou seja, um incremento da funcionalidade total requerida (requisitos funcionais e não-funcionais) , e Requisições de Mudança remanescentes das iterações anteriores. O Gerente de Projeto pode então determinar os recursos e o cronograma para a iteração. Deve-se prever o conserto de defeitos no plano para a iteração implicitamente, no esforço alocado para a produção de um artefato, ou explicitamente, como uma atividade em separado. É recomendado adotar este último método. O Rational Unified Process contém atividades que tornam isto possível (como a Atividade: Consertar Defeito na disciplina de Implementação).

Apesar da prioridade das correções ser decidida pelo Gerente de Controle de Mudanças, o Gerente de Projeto pode ter alguma prudência no planejamento decidindo quando as correções devem ser feitas - em geral, deve-se tentar corrigir os defeitos na iteração em que eles são descobertos, e deve ser possível fazer isso com os recursos planejados no início da iteração. Inevitavelmente, haverá alguns defeitos descobertos que não serão solucionados até o final da iteração (pois a iteração deve ter duração fixa), mas, para que a iteração seja considerada um sucesso, é preciso a maioria deles não sejam considerados severos ou de alta prioridade.

Deve-se dar pouca permissão para requisições de melhorias triviais que cheguem inesperadamente. Se uma Requisição de Mudança deste tipo para uma melhoria substancial é aceita para a iteração atual, o Gerente de Projeto certamente terá que replanejá-la, seja adiando funcionalidades planejadas para a iteração seguinte, seja encontrando recursos extras para fazer a mudança proposta. Em geral, tais requisições de melhoria serão deixadas para a próxima iteração, ou até mesmo para as seguintes, fazendo parte do ciclo regular de planejamento da iteração.

Alocar Requisição de Mudança em uma Iteração

A Requisição de Mudança é examinada e o Gerente de Projeto, juntamente com um representante do cliente ou especialista do negócio da aplicação, decide em qual iteração a Requisição de Mudança será feita, baseado no seu tipo, prioridade e severidade. Se a Requisição de Mudança pode ser adiada para uma iteração posterior, o Gerente de projeto simplesmente replaneja as futuras iterações (no Plano de Desenvolvimento de Software), de maneira que o impacto dela seja entendido agora e as atividades de aquisição de recursos possam ser iniciadas o mais cedo possível, para evitar surpresas desagradáveis mais tarde.

Atribuir Responsabilidade

Durante o encontro diário, o Gerente de Projeto deve apresentar a nova atividade e um dos membros da equipe deve candidatar-se a ela. Caso ninguém se candidate a ela, o Gerente de Projeto deve chegar no consenso com a equipe sobre quem será o responsável por implementar aquela requisição de mudança.

Estimar Esforço e Outros Recursos

O responsável pela mudança, em conjunto com o Gerente de Projeto, estima o esforço e outros recursos necessários para implementar a mudança. É importante que haja um comprometimento em cumprir estas estimativas.

Elaborar Cronograma

Se a Requisição de Mudança for implementada na iteração atual, o Gerente de Projeto, com o auxílio do responsável por efetuá-la, refará o cronograma da iteração, definindo as datas de início e fim para a nova atividade. Caso seja necessário trocar a nova atividade por outras já planejadas, para acomodar a nova atividade no cronograma da iteração atual, o representante do cliente deve ser envolvido na decisão de que atividades serão postergadas, para que escolha o que considera mais importante: o que havia sido inicialmente escolhido ou a nova modificação.

Replanejar

Se necessário, o Plano de Iteração atual é revisado, e qualquer impacto nas iterações futuras deve ser refletido no Plano de Desenvolvimento de Software. Como resultado do replanejamento, o Gerente de projeto pode invocar a Atividade: Tratar Problemas e Exceções, para alinhar o estado do projeto com os novos planos, particularmente se a iteração atual é afetada por uma falta de recursos ou pelo adiamento de funcionalidades para iterações posteriores.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process