| Tarefa: Calcular o Impacto de Esforço das Solicitações de Mudanças |
| |
 |
| Em uma reunião com representantes dos principais papeis técnicos do projeto que compõem o Comitê de Mudanças, deverão ser analisadas todas as solicitações de mudanças afim de determinar qual o impacto, em termos de esforço,para se realizar as mudanças solicitadas para o projeto. |
| Disciplinas: Requisitos |
|
Objetivo
-
Determinar se a solicitação de mudança é um erro ou realmente uma mudança.
-
Determinar todos os itens de trabalho afetados pela mudança, permitindo uma implementação mais segura em caso
de aprovação.
-
Calcular o esforço necessário para realizar a mudança, informação utilizada como entrada para se determinar se a
mesma deverá ser inserida ou não no projeto.
|
Relacionamentos
| Funções | Executor Primário:
| Executores Adicionais:
|
| Entradas | Obrigatório:
| Opcional:
|
| Saídas |
|
Descrição Principal
Qualquer solicitação de mudança em um projeto possui impactos. A análise incorreta deste impacto é uma das
grandes causas de insucesso em projetos de software. Uma mudança mal planejada pode deixar de alterar um ou
mais produtos de trabalho que deveriam sofrer alguma alteração em função da mudança e gerar consequências graves
em termos de qualidade, custo e prazo de um projeto. Sendo assim, toda a equipe envolvida na análise de impacto
deve ter ciência de que mesmo uma mudança aparentemente simples pode afetar vários produtos de trabalho do projeto e,
portanto, deve ser tratada com muita atenção.
Toda solicitação de mudança deve ter o seu impacto avaliado e o esforço de realização relativo calculado antes de
sua realização. Com isto, o cliente possuirá informações suficientes para decidir se aquela mudança deverá ou não
ser inserida no projeto. A equipe técnica também ganha com esta avaliação, uma vez que os pontos de alteração no caso
da mudança ser aprovada já foram estudados e registrados.
Esta tarefa é a mais importante do processo de solicitação de mudança. Em uma reunião com representantes dos principais
papeis técnicos do projeto, deverá ser analisado todos os produtos de trabalho que deverão ser alterados e como deverão
ser alterados caso a mudança seja incorporada ao projeto. A rastreabilidade é uma grande aliada neste sentido, pois
permite que os membros do comitê de mudanças avaliem com mais precisão e velocidade os produtos de trabalho que serão
impactados a partir de suas amarrações.
|
Etapas
|
Repassar as mudanças em aberto para o comitê da mudanças
Reunir os membros do comitê de mudanças
A presença de todos os membros é indispendável pois a maioria das mudança impacta em produtos de
trabalhos de todos os níveis do projeto.
Deve ser definido um redator e um condutor da reunião. O condutor da reunião deve analisar o tempo disponível para a
reunião e conduzí-la de forma a analisar todas as mudanças dentro do tempo disponível.
|
Analisar se a solicitação é uma mudança ou um erro.
A análise de cada solicitação de mudança inicia-se com esta filtragem.
Muitas vezes nem o cliente nem o Gerente do Projeto conseguem distinguir uma mudança de um erro.
Um erro é o comportamente ou a descrição de um produto de trabalho inconsistente com o que já foi
aprovado. Exemplos: uma interrupção da navegação do software não prevista no cenário desse caso de uso, uma ambiguidade
na especificação de requisitos do software, etc.
Se a equipe determinar que uma solicitação de mudança na verdade é um erro, deve-se iniciar o processo de tratamento de
erros e finalizar a análise.
Uma mudança é uma alteração em um item de trabalho do projeto previamente aprovado. Uma mudança
pode existir em todas as fases, níveis de detalhamentos e produtos de trabalho.
Muitas vezes as mudanças são confundidas com o refinamento do requisitos. Para isto, deve ser analisado se o nível de
refinamento considerado já havia sido validado pelo cliente e inserido no escopo do projeto.
Exemplo 1: A fase de elaboração inicia requisitos de negócios do projeto definidos e aprovado no Documento de Visão.
Durante as demais fases novos requisitos de negócios podem ser solicitados, como o escopo do projeto é alterado, esta é
uma solicitação de mudança.
Exemplo 2: Na fase de elaboração todas as telas do software são validadas, no entanto, os cenários dos casos de uso a
partir da segunda iteração ainda não foram detalhados. Neste caso, no detalhamentos destes casos de uso na construção,
pode, surgir a necessidade de um novo campo na tela. Por já terem sido validadas, a alteração da tela é uma solicitação
de mudança, no entanto, estas são solicitações de mudanças que podem ser aprovadas pelo próprio gerente do
projeto, sem impacto financeiro, pois o processo de desenvolvimento aqui considerado reconhece que a criação das telas
na fase de elaboração estão em um nível de detalhamento superior a validação das telas junto a especificação dos casos
de uso da próxima iteração.
|
Entender a mudança solicitada
Realize o entendimento correto das mudanças segundo os Critérios de Entendimento, Validação e Aceitação dos Requisitos. Note que uma
mudança por si só é um requisito a ser validado.
Para cada mudança, repasse o checklist dos critérios apresentados e confirme se todos eles são atendidos.
Caso exista alguma inconformidade, contacte o solicitante, corrija a declaração da mudança e revise-a até o atendimento
completo dos critérios.
Preencha os campos relacionados ao checklist no artefato, confirmando a realização desta etapa.
|
Listar quais produtos de trabalho serão alterados e como será a mudança.
Estimar o esforço da mudança
Para cada produto de trabalho listado, definir qual o tempo médio de cada área envolvida (testes, análise,
desenvolvimento, etc) para realizar a mudança.
No caso de novos requisitos, a estimativa deve ser feita utilizando-se a Análise de Pontos de Função e os parâmetros de produtividade conhecidos. Caso não seja possível utilizar a técnica, a
estimativa deve ser baseada na opinião de ao menos dois membros do comitê.
Para que a informação não seja visível ao cliente que poderia neste caso fazer um julgamento de valor sobre o tempo
demandado, os campos devem ser preenchidos de forma codificada como mostra o exemplo abaixo.
Exemplo: Mudança gera esforço de 8:15 de análise de négocio, 0:35 de arquiteto,16:00 de desenvolvimento, 4:30 de testes
e 1:00 de gerência de projetos.
AN: 815 AR: 35 DE: 1600 AT: 430
GP: 100
|
|
Considerações de Teclas
Sugere-se que esta reuião seja periódica no projeto (por exemplo, semanal), evitando o acumulo de mudanças em aberto e
sem impacto calculado.
Além dos esforços apresentados pela equipe técnica referente a mudança, o Gerente do Projeto deve considerar o seu
esforço relativo a alteração do cronograma do projeto.
|
|
