Guia: Determinando o Escopo de Acordo com a Fase
Tópicos
Ao se determinar o escopo da iteração, durante o seu planejamento,
deve-se levar em conta a fase em que o projeto se encontra, para que seus
objetivos sejam cumpridos. Este guia apresenta fatores que devem ser utilizados
em cada fase, na determinação do escopo de suas iterações.
Para maiores detalhes sobre o planejamento da iteração,
veja Atividade: Planejar Próxima
Iteração.
Existem três principais fatores para definir os objetivos de uma
iteração na elaboração:
- Risco
- Criticidade
- Cobertura
O principal fator para definir os objetivos da iteração
são os riscos. Você precisa mitigar ou eliminar os
riscos o mais cedo possível. Este é o caso principalmente
da fase de elaboração, onde a maioria dos riscos deve ser
mitigados, mas pode continuar a ser um elemento importante na fase de
construção, se alguns riscos ainda forem altos ou novos
riscos forem descobertos. Mas, uma vez que o objetivo da fase de elaboração
é estabelizar uma arquitetura, outras considerações
devem ser levadas em conta, como ter certeza que a arquitetura trata todos
os aspectos do software a ser desenvolvido (cobertura). Isto é
importante, já que a arquitetura será usada para o planejamento
posterior: organização da equipe, estimativa do código
a ser desenvolvido, etc.
Por fim, apesar de ser importante focar nos riscos, deve-se lembrar qual
a é a missão principal do sistema. Resolver todas as questões
difíceis é bom, mas isto não deve ser feito em detrimento
da funcionalidade principal: esteja certo de que as funcionalidades e
serviços críticos do sistema são cobertos de fato
(criticidade), mesmo que não tenham sido percebidos riscos
neles.
A partir da Lista de Ricos, para os maiores riscos, identifique cenários
em algum caso de uso que forçariam a equipe a "confrontar"
o risco.
Exemplos
- se existe um risco de integração, como "o banco
de dados D deve trabalhar bem com o SO Y", inclua um cenário
que involva alguma interação com o banco da dados, mesmo
que de maneira simples.
- se existe um risco de performance, como "o tempo para calcular
a trajetório da aeronave", inclua um cenário que
faça esse cálculo, mesmo que para o caso mais óbivio
ou freqüente.
Para criticidade, tenha certeza de incluir as funções
e serviços mais fundamentais do sistema. Selecione alguns cenários
dos casos de uso, que representem os serviços mais comuns do sistema,
ou a forma mais freqüente de oferecê-los. O Documento de Arquitetura
de Software é usado para guiar esta escolha. Além disto,
é muito importante a participação do cliente ou de
um especialista no domínio do negócio, que saiba determinar
os serviços e funcionalidades de maior valor para o usuário.
Exemplo
- para um comutador telefônico, uma chamada entre duas centrais,
é obviamente uma funcionalidade obrigatória para as
primeiras iterações. É muito mais importante
que isto funcione corretamente do que os complicados modos de falha
da configuração do operador, no subsistema de tratamento
de erros.
Para a cobertura, no final da fase de elaboração,
inclua cenários de áreas do sistema que irão necessitar
de desenvolvimento, mesmo que não sejam críticas ou de grande
risco.
Em alguns casos, é econômico criar cenários que ataquem
múltiplas questões de uma só vez. O perigo é,
geralmente, que os cenários fiquem muito carregados, isto é,
que tentem cobrir muitos aspectos, variantes e casos de erro diferentes
(veja Guias: Plano de Iteração)
Também na fase de elaboração, tenha em mente que
alguns dos riscos pode ser de natureza mais humana: cultura do time, treinamento,
seleção das ferramentas, novas técnicas, etc. Somente
trabalhando durantes a iterações estes riscos serão
mitigados.
Exemplos
- Criar um assinante em uma estação cliente,
para ser armazenado no banco de dados do servidor, incluindo interface
com o usuário, mas sem incluir todos os campos e assumindo
que nenhum erro é detectado.
Combina uma função crítica com alguns
riscos de integração (banco de dados e comunicação)
e questões de integração (lidar com duas plataformas
diferentes). Também força os designers a se tornarem
familiares com a ferramenta de criação de interfaces.
Finalmente produz um protótipo que pode ser demostrado ao usuário
final, para se obter feedback.
- Ter certeza de que mais de 20.000 assinantes pode ser criados,
e que o acesso não demora mais que 200 milissegundos.
Ataca questões de performance (volume de dados, tempo
de resposta), que podem afetar dramaticamente a arquitetura se não
forem cumpridas.
- Desfazer a alteração no endereço de
um assinante.
Uma funcionalidade simples que força os designers
a pensarem sobre o projeto de todas as funções "desfazer".
Isto pode disparar alguma renegociação junto aos usuários
finais para saber o que pode ser desfeito a um custo razoável.
- Completar todos os casos de uso relativos ao gerenciamento
da cadeia de fornecedores.
O objetivo da fase de elaboração também
é completar a captura de requisitos, possivelmente.
À medida que o projeto caminha para a fase de construção,
os riscos continuam sendo um fator chave, especialmente os novos riscos
descobertos. Entretanto, a finalização dos casos de uso
começa a também ser um fator de determinação
do escopo. As iterações podem ser planejadas funcionalidade
por funcionalidade, na tentativa de completar logo algumas das mais críticas,
para que possam ser testadas durante mais de uma iteração.
Ao final da fase de construção, o principal objetivo é
a robustez dos casos de uso que já foram completamente implementados.
Exemplo
- Implementar todas as variantes do encaminhamento de chamadas,
incluindo as de erro.
Este é um conjunto de funcionalidades relacionadas.
Uma delas deve ter sido implementada durante a fase de elaboração,
e servirá como modelo para o resto do desenvolvimento.
- Alcançar 5.000 transações por hora
em uma configuração com 2 computadores.
Isto pode aumentar a performance necessária em relação
ao que foi atingido na iteração anterior, por exemplo,
2.357 por hora.
- Integrar a nova versão do Sistema de Informações
Geográficas.
Esta pode ser uma pequena mudança na arquitetura,
devido a algum problema descoberto anteriormente.
- Consertar todos os defeitos de níveis 1 e 2
Consertar os defeitos descobertos durante os testes da iteração
passada que ainda não foram corrigidos.
Finalizar a geração do produto é o principal objetivo.
Os objetivos da iteração são definidos em termos
de que erros que são corrigidos e de que melhorias de performance
e usabilidade são incluídas. Caso funcionalidades tenham
sido descartadas para cumprir a data final da fase de transição
(o lançamento da versão "beta" do sistema), elas
podem ser desenvolvidas ou completadas agora, desde que não atrapalhem
o que já foi alcançado até agora.
Exemplos
- Corrigir todos os problemas de severidade 1 descoberto
pelos usuários "beta".
Um objetivo em termos de qualidade, relacionado com a credibilidade
com o mercado
- Eliminar todas as falhas de iniciação devido
a dados corrompidos.
Outro objetivo em termos de qualidade.
- Atingir 2.000 transações por minuto.
Ajuste de performance, envolvendo alguma otimização:
mudanças na estrutura de dados, uso de cache ou algoritmos
mais eficientes.
- Reduzir o número de caixas de diálogos diferentes
em 30%.
Melhorar a usabilidade através da redução
da poluição visual.
- Produzir versões em alemão e inglês.
Caso só tenha sido produzia uma versão beta
em inglês, devido à falta de tempo.
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|
Artefatos > 
Artefatos de Gerenciamento de Projeto
> 
{Mais
Artefatos de Gerenciamento de Projeto} > 
Plano de Iteração > 
Guias 
