Diretrizes: Plano de Iteração
Tópicos
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 uma primeira iteração precisa cumprir.
Por exemplo, organizar o processo, formar equipes, compreender um novo domínio,
familiarizar-se com novas ferramentas e outros. 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.
Os cenários "arquiteturalmente significativos" 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:
- solicitações de melhoria
- solicitações de mudança cujo escopo ultrapasse a classe ou o pacote individual.
- mudanças nos objetivos e no escopo da iteração.
- mudanças efetuadas nos requisitos propondo que a baseline de requisitos seja alterada ou acomodando uma mudança aceita na baseline de requisitos.
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.
Há 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:
- A Equipe é inexperiente em relação ao domínio do problema ou a uma área de tecnologia (incluindo metodologia ou processo).
- Uma arquitetura estável é um requisito fundamental para a capacidade futura e a arquitetura em questão é inédita.
No entanto, a estratégia apresenta algumas possíveis armadilhas:
- A equipe pode ser vítima da paralisia de análise (O sentimento
ilógico de que, se o design não estiver perfeito, não será possível fazer nenhuma implementação).
- Em geral, os resultados iniciais são necessários para dar confiança e credibilidade; quanto mais tempo a equipe do projeto ficar sem produzir algo executável, menos confiante ela se sentirá sobre a capacidade de fazê-lo.
- Não são mostrados desafios e detalhes técnicos suficientes da arquitetura para que se possa ter uma idéia dos verdadeiros riscos técnicos.
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:
- Resultados iniciais precisam ser demonstrados para superar um risco predominante, obter suporte ou provar a viabilidade.
- Os requisitos evoluem continuamente, dificultando a definição completa de todos eles antes do início do design detalhado e do trabalho de implementação.
- O prazo final é obrigatório, fazendo com que o início antecipado do
desenvolvimento seja fundamental para uma liberação bem-sucedida.
- Um alto grau de reutilização é possível, permitindo um grau maior de liberação gradativa.
A estratégia possui suas desvantagens:
- Com essa estratégia, há uma tendência para que cada iteração desenvolva software integrado verticalmente, mas incompatível horizontalmente.
Às vezes,
isso é conhecido como síndrome da chaminé e dificulta a integração
do sistema.
- Ela não é adequada para desenvolver sistemas em um domínio de problema completamente novo ou baseado em uma arquitetura inédita, já que grande parte da funcionalidade de um sistema precisa ser testada para conseguir uma arquitetura equilibrada.
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.
- Estratégia Limitada/Detalhada usada na Iniciação
Para situações em que a exploração de uma nova tecnologia é essencial para a
viabilidade fundamental do projeto. Muitos projetos de e-business requerem
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.
- Estratégia Ampla/Superficial usada na Iniciação
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.
- Estratégia Ampla/Superficial usada na Elaboração
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.
- Estratégia Limitada/Detalhada usada na Construção
As iterações de 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:
- Iniciação: 40%-100% - esta é a fase em que você poderá desenvolver protótipos descartáveis e exploratórios
- Elaboração: 25%-60% nas iterações iniciais; menos de 25% nas iterações subseqüentes ou para um ciclo evolutivo.
- Construção: após a baseline de arquitetura, no máximo 10% por iteração e 25% no total.
- Transição: menos de 5%.
O retrabalho é inevitável.
Suspeite quando ninguém achar que ele é necessário.
Isso pode ser decorrente de:
- Cronograma com pressão excessiva.
- Ausência de testes ou avaliações reais.
- Ausência de motivação ou foco.
- Percepção negativa do retrabalho como sendo um desperdício de recursos ou uma admissão de incompetência ou falha.
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 'delimitado
por tempo' 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 arbitrária de equipe em uma tentativa
desesperada de atender a um planejamento, a execução de um projeto com uma constante escassez de equipe
- 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 (consulte [BOE00])
podem ser úteis. 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 incluídos (no nível de atividade) mostram como isso pode aparecer. Observe, entretanto, que esses planos de trabalho são resultantes do plano de iteração; não são artefatos independentes, produzidos separadamente.
É importante, se o coordenador de projeto for
exercer o controle, que os planos de trabalho possam ser acumulados para refletir o
status do plano de iteração dele.
|