Diretrizes:
|
 Plano de Iteração |
Um conjunto de atividades e tarefas divididas por seqüências de tempo, com recursos atribuídos e dependências de tarefas, para a iteração; um plano sofisticado. |
Na Iniciação, os maiores riscos geralmente são de negócios ou técnicos. No início, o principal risco de negócios normalmente é garantir o financiamento do projeto. Assim, um protótipo de prova de conceito costuma ser o resultado da fase de iniciação. Esse protótipo demonstra a funcionalidade básica ou alguns aspectos de tecnologia essenciais.
A primeira iteração de um novo produto costuma ser a mais difícil. Além de produzir o software, existem muitos novos aspectos que a primeira iteração precisa cumprir; por exemplo, organizar o processo, formar equipes, compreender um novo domínio, familiarizar-se com novas ferramentas, e assim por diante. Seja cauteloso em suas expectativas sobre quanto da arquitetura pode ser aprimorada ou sobre o grau de funcionalidade usável que pode ser alcançado. Se você for exigente demais nas expectativas, correrá o risco de adiar a conclusão da primeira iteração e reduzir o número total de iterações, diminuindo assim a vantagem de uma abordagem iterativa. As primeiras iterações devem se concentrar na obtenção da arquitetura adequada. Por isso, é preciso envolver os arquitetos de software no processo de planejamento das iterações iniciais.
Na Elaboração, o foco das iterações é definir uma arquitetura estável, projetar e implementar o comportamento essencial do sistema e explorar as questões técnicas de arquitetura através de uma série de protótipos de arquitetura. Cenários "relevantes do ponto de vista da arquitetura" são subfluxos que testam a arquitetura do sistema ao definir caminhos.
Um pouco antes do término da Elaboração e durante a Construção e a Transição, as solicitações de mudança - também conhecidas como Pedidos de Mudança de Software ou SCOs (Software Change Orders) - começam a orientar o processo de iteração. As SCOs são provenientes de:
Essas SCOs são confrontadas em relação ao plano de projeto existente, aos planos de iteração e à lista de riscos existentes. Elas podem fazer com que a prioridade de requisitos seja reavaliada ou orientar a nova priorização de riscos. É necessário gerenciá-las com cuidado para não perder o controle do projeto.
Durante a Construção e a Transição, o mais importante é aprimorar a arquitetura e implementar todos os requisitos restantes.
Ao contrário do modelo Cascata, no qual o sistema inteiro é considerado de uma só vez, aqui consideramos apenas uma parte da funcionalidade do sistema em cada iteração. Durante cada iteração, um subconjunto de todo o sistema é analisado, projetado e implementado. A escolha do que o subconjunto deverá representar e o grau de profundidade da análise são vitais para reduzir riscos nas iterações subseqüentes. Existem duas estratégias básicas: Ampla/Superficial e Limitada/Detalhada.
Na estratégia Ampla/Superficial, todo o domínio do problema é analisado, mas apenas os detalhes superficiais são considerados. Todos os Casos de Uso são definidos e a maioria deles é aprimorado para obter uma noção exata do problema. A arquitetura também é definida genericamente, e são definidos os principais mecanismos e serviços oferecidos pelos componentes de arquitetura. As interfaces de subsistemas são definidas; mas seu funcionamento interno é detalhado apenas em situações nas quais seja necessário gerenciar incertezas ou riscos significativos. Não há muitas implementações até a fase de Construção, quando ocorrem a maioria das iterações.
A estratégia Ampla/Superficial é apropriada quando:
No entanto, a estratégia apresenta algumas possíveis armadilhas:
Na estratégia Limitada/Detalhada, um corte do domínio do problema é cuidadosamente analisado. Os Casos de Uso relacionados a esse corte limitado são definidos e aprimorados intensamente a fim de obter uma noção exata do problema. A arquitetura necessária para suportar o comportamento desejado é definida e o sistema é projetado e implementado. As iterações subseqüentes se concentram na análise, no projeto e na implementação de outros cortes verticais.
A estratégia Limitada/Detalhada é apropriada quando:
A estratégia possui suas desvantagens:
Em geral, as iterações iniciais seguirão uma estratégia mais do tipo Ampla/Superficial, enquanto as iterações posteriores (nas quais uma arquitetura estável terá sido desenvolvida) tendem a seguir a estratégia Limitada/Detalhada.
A primeira iteração costuma ser a mais difícil, pois requer que todo o ambiente de desenvolvimento e grande parte da equipe do projeto estejam posicionados. A integração de ferramentas e a formação da equipe tornam a primeira iteração ainda mais complexa. Concentrar-se nas questões de arquitetura pode ajudar a manter o foco e evitar que a equipe se atole em detalhes cedo demais.
É recomendável em situações nas quais explorar uma nova tecnologia é essencial para a viabilidade do projeto. Muitos projetos de comércio eletrônico exigem que novas tecnologias sejam exploradas em um grau bem maior do que o explorado tradicionalmente. O protótipo de prova de conceito ainda é considerado "descartável" e explora apenas a viabilidade do conceito do projeto.
Essa estratégia é utilizada para obter uma noção do escopo do sistema e testar a amplitude da funcionalidade do sistema, a fim de garantir que a arquitetura seja capaz de suprir a capacidade desejada.
Essa abordagem pode ajudar a desenvolver uma arquitetura estável, com foco Limitado/Detalhado seletivo para lidar com riscos técnicos específicos. Na Construção, com uma arquitetura estável estabelecida, o foco pode voltar a ser Limitado/Detalhado, quando a funcionalidade será desenvolvida e apresentada em uma série de incrementos integrados.
As iterações da Construção são sempre Limitadas/Detalhadas, com equipes trabalhando paralelamente para desenvolver e apresentar a funcionalidade necessária.
Em geral, as novas equipes são excessivamente otimistas no início com relação ao que podem realizar. Para combater isso e evitar possíveis problemas de ânimo que ocorrem quando os verdadeiros resultados não alcançam as expectativas otimistas, seja modesto na quantidade de funcionalidade que pode ser obtida na primeira iteração. Tente ganhar experiência e, ao mesmo tempo, criar um senso de realização e momento do projeto.
Se o ambiente de desenvolvimento e/ou os métodos forem novos para a equipe, reduza a funcionalidade da primeira iteração ao mínimo. Concentre-se na integração e no ajuste do ambiente, bem como no domínio das ferramentas. Aumente então o conteúdo da funcionalidade nas iterações subseqüentes.
Até certo ponto, o retrabalho é válido. Uma das principais vantagens de um desenvolvimento iterativo é permitir erros e experimentações cedo o suficiente para que possam ser tomadas ações corretivas. No entanto, o pessoal técnico costuma 'banhar a ouro' ou refazer o trabalho até a perfeição entre as iterações.
No final de cada iteração, durante a avaliação, a equipe deverá decidir qual parte do release atual será refeita. Espere que o retrabalho seja alocado entre as fases nas seguintes porcentagens, em relação ao sistema como um todo:
O retrabalho é inevitável. Suspeite quando ninguém achar que ele é necessário. Isso pode ser decorrente de:
O excesso de retrabalho é alarmante. Ele pode ser proveniente de uma atitude perfeccionista ou de um nível inaceitável de mudanças de requisitos. Um caso de negócio deverá ser criado para avaliar a necessidade de retrabalho.
Observe que não incluímos o trabalho removido do escopo da iteração anterior (em decorrência da abordagem do tipo timebox em relação ao gerenciamento de iterações) na categoria de 'retrabalho'. O Gerente de Projeto deverá incluir esse trabalho removido do escopo no conjunto de funcionalidades a partir do qual será definido o conteúdo da próxima iteração. É óbvio que esse trabalho certamente terá alta prioridade. O Gerente de Projeto também deverá descobrir e considerar com cuidado os motivos da falha da iteração anterior para alcançar as metas planejadas. Por exemplo, apesar de não recomendarmos a inclusão aleatória de pessoal em uma tentativa desesperada de cumprir um cronograma, a condução de um projeto com uma constante escassez de pessoal - e a elaboração, ao mesmo tempo, de planos ambiciosos para cada iteração - também não é nada sensata. Isso geralmente diminui o ânimo da equipe e deixa o cliente enfurecido. É necessário encontrar o equilíbrio adequado. Para isso, modelos de estimativa como o COCOMO II (Construct Cost Model) podem ser úteis (consulte [BOE00]). Com cada iteração, um projeto cria um histórico de realizações, tanto de produtividade como de qualidade. No planejamento da próxima iteração, um forte indicador para um Gerente de Projeto é o que foi alcançado na iteração anterior.
Quando o plano de iteração do primeiro segmento estiver concluído, os líderes das equipes, talvez em conjunto com o gerente do projeto, poderão transformá-lo em um plano de trabalho no nível de atividade. Os Microsoft® Project Templates (no nível de atividade) incluídos mostram exemplos desse processo. Observe, entretanto, que esses planos de trabalho são resultantes do plano de iteração; não são artefatos independentes, produzidos separadamente. Se o gerente do projeto for exercer o controle, é importante que os planos de trabalho possam ser acumulados para refletir o status do plano de iteração dele.
|
Rational Unified Process
|
