Determinando a Duração de cada Iteração

Uma iteração é definida como um mini-projeto completo, que passa por todas as principais disciplinas e resulta, na maioria dos casos, em um sistema executável, porém incompleto: um release. Embora o ciclo (edição, compilação, teste, depuração) pareça uma iteração, o significado aqui não é esse. Os builds diários ou semanais, que integram e testam gradativamente cada vez mais elementos do sistema, também podem parecer uma iteração, mas são apenas parte dela, conforme o uso do termo neste contexto.

A iteração inicia com planejamento e requisitos e termina com um release interno ou externo.

A rapidez da iteração depende, principalmente, do tamanho da organização de desenvolvimento.

Por exemplo:

• Cinco pessoas podem fazer um planejamento na segunda-feira de manhã, almoçar juntas todos os dias para monitorar o andamento do planejamento, realocar tarefas, iniciar o build na quinta-feira e concluir a iteração na sexta-feira à noite.
• Mas esse procedimento será muito difícil de ser executado por vinte pessoas. Mais tempo será gasto distribuindo o trabalho, sincronizando os subgrupos, integrando todos os elementos etc. Uma iteração poderá demorar três ou quatro semanas.
• Com 40 pessoas, leva-se uma semana para que o "influxo nervoso vá da cabeça até as extremidades do corpo". Há níveis intermediários de gerenciamento, mas as noções básicas comuns do objetivo necessitarão de uma documentação mais formal. Três meses, geralmente, é um tempo de iteração razoável.

Outros fatores entram em jogo: o grau de familiaridade da organização com a abordagem iterativa, incluindo uma organização experiente e estável, o nível de automatização utilizado pela equipe para gerenciar códigos (por exemplo, CM distribuído), para distribuir informações (por exemplo, Web interna), para automatizar testes etc.

Preste atenção também porque há uma sobrecarga fixa em uma iteração, em relação a planejamento, sincronização, análise dos resultados e assim por diante.

Portanto, por um lado, convencido dos enormes benefícios da abordagem iterativa, você pode ficar tentado a iterar constantemente, porém os limites humanos de sua organização diminuirão sua vontade.

Alguns dados empíricos:

• Iterações com mais de 6 meses provavelmente precisarão ter marcos intermediários incorporados para manter o projeto sob controle. Considere a redução do escopo da iteração para diminuir o tempo da iteração e garantir um enfoque mais nítido.
• Iterações com mais de 12 meses são por si só arriscadas já que a iteração se estende pelo ciclo de fundos anual. Um projeto que aparentemente não produziu nada nos últimos doze meses corre o risco de perder seus fundos.
• Iterações com menos de 1 mês precisam ter o escopo definido com cuidado. Em geral, as iterações de curta duração são mais adequadas à fase de Construção, caracterizada pela inclusão de poucas funções novas e inovações. Essas breves iterações poderão gerar pouca ou nenhuma análise ou design formal, podendo simplesmente estar aprimorando gradativamente a funcionalidade já bem compreendida.
• As iterações não precisam ter o mesmo tempo: o tempo varia de acordo com seus objetivos. Em geral, as iterações de elaboração serão mais demoradas do que as de construção. Em uma fase, as iterações têm geralmente o mesmo tempo (facilitando o planejamento).

Quando tiver idéia do número de iterações no esboço de plano, você precisará definir o conteúdo de cada iteração. Recomenda-se inclusive dar um nome ou um título para qualificar o produto no fim de cada iteração, o que ajudará as pessoas a obter um melhor enfoque.

Exemplo Iterações para um Comutador Telefônico Privado

• Iteração 1: chamada local.
• Iteração 2: incluir chamadas externas e gerenciamento de assinantes.
• Iteração 3: incluir correio de vos e chamadas de conferência.

Determinando o Número de Iterações

Um projeto bem simples pode ter apenas uma iteração por fase:

• Uma iteração na fase de iniciação produzindo, talvez, um protótipo de prova de conceito ou um modelo de interface de usuário ou nenhuma iteração, no caso, por exemplo, de um ciclo de evolução.
• Uma iteração na fase de elaboração para produzir um protótipo de arquitetura.
• Uma iteração na fase de construção para construir o produto (até uma liberação "beta").
• Uma iteração na transição para conclusão do produto (release de todo o produto).

Para obter um projeto mais substancial, a norma a ser seguida no ciclo de desenvolvimento inicial deve ser:

• Uma iteração na fase de iniciação (possivelmente com a produção de um protótipo).
• Duas iterações na fase de elaboração; uma para um protótipo de arquitetura e a outra para a linha de base de arquitetura.
• Duas iterações na fase de construção para expor um sistema parcial e amadurecê-lo.
• Uma iteração na fase de transição para passar da capacidade operacional inicial para o release de todo o produto.

No caso de um grande projeto, com várias questões desconhecidas, novas tecnologias etc., é possível que haja um caso para:

• uma iteração adicional na fase de iniciação, para permitir mais tempo para a produção de um protótipo.
• uma iteração adicional na fase de elaboração, para permitir a exploração de diferentes tecnologias.
• uma iteração adicional na fase de construção devido ao tamanho total do produto.
• uma iteração adicional na fase de transição para permitir comentários sobre a operação.

Portanto, durante um ciclo de desenvolvimento haverá:

• Baixo: 3 iterações [0,1,1,1]
• Típico: 6 [1, 2, 2, 1]
• Alto: 9 [1, 3, 3, 2]
• Muito Alto 10 [2, 3, 3, 2]

Em geral, planeje de três a dez iterações. Contudo, observe que os limites superior e inferior indicam circunstâncias fora do comum. Conseqüentemente, a maioria dos desenvolvimentos utilizará de seis a oito iterações.

São possíveis diversas variações, dependendo dos riscos, do tamanho e da complexidade:

• Se o produto for destinado a um domínio totalmente novo, poderá ser necessário incluir algumas iterações na fase de iniciação para consolidar os conceitos, mostrar diversos modelos para uma seção cruzada de clientes ou usuários ou para construir uma resposta sólida a um pedido de proposta.
• Se uma nova arquitetura tiver que ser desenvolvida ou se houver uma grande quantidade de modelagens de casos de uso, ou muitos riscos desafiadores, planeje duas ou três iterações na fase de elaboração.
• Se o produto for grande, complexo e desenvolvido durante um longo período de tempo, planeje três ou mais iterações na fase de construção.
• Planeje várias iterações na fase de transição se, para agilizar a comercialização, você tiver que liberar o produto com um conjunto menor de funções ou se achar que talvez precisará fazer várias pequenas adaptações na base de usuários finais após um período de uso.

Alinhando a Seqüência de Revisão Em Cascata Tradicional à Abordagem Iterativa

A seqüência de revisão padrão de um projeto de ciclo de vida em cascata passa por uma única grande revisão após a conclusão dos produtos de trabalho importantes. Por exemplo:

• SRR (Revisão de Requisitos do Sistema), realizada após a conclusão da especificação do sistema;
• SSR (Revisão da Especificação de Software), realizada após a conclusão da especificação dos requisitos de software;
• PDR (Revisão Preliminar de Design), realizada após a conclusão das seções de design de arquitetura da descrição de design do software;
• CDR (Revisão Crítica de Design), realizada após a conclusão das seções detalhadas de design da descrição de design do software.

No RUP (Rational Unified Process), partes dos produtos de trabalho equivalentes são revistos assim que são concluídos em cada iteração, mas os marcos principais (e, portanto, as revisões) estão alinhados à conclusão das fases, iniciação, elaboração, construção e transição. Um Coordenador de Projeto que deseje adotar o RUP talvez tenha que encontrar uma maneira de reconciliar esse conflito aparente por causa das obrigações contratuais. O ideal seria que ele convencesse o cliente de que a abordagem baseada em fases e iterações, na verdade, permite uma visibilidade real maior do andamento do projeto, além de reduzir riscos, tornando desnecessária uma SRR, uma SSR etc. Entretanto, isso nem sempre é possível, e o Coordenador de Projeto precisa programar essas revisões nos pontos apropriados. No RUP, é possível localizar os pontos em que esses importantes produtos de trabalho (na verdade, seus equivalentes no RUP) estão basicamente completos, embora isso nem sempre esteja perfeitamente de acordo com as fases ou as iterações.

Isso é feito aqui considerando que o esforço relativo que será gasto em requisitos, design e assuntos do gênero será aproximadamente o mesmo no RUP que no ciclo de vida em cascata (ideal), mas que o esforço será distribuído de modo diferente. O resultado é este:

• a SRR (que lida principalmente com a Visão) pode ser planejada no fim da fase de iniciação;
• a SSR (que lida principalmente com a Especificação de Requisitos de Software) é realizada em aproximadamente 1/3 do caminho para a fase de elaboração;
• a PDR (que lida principalmente com o Documento de Arquitetura de Software) é realizada no final da fase de elaboração;
• a CDR (que lida principalmente com o Modelo de Design) é realizada em aproximadamente 1/3 do caminho para a fase de construção.

Para obter eficiência, o Coordenador de Projeto e o cliente deverão trocar idéias e tentar combinar essas revisões com as revisões prescritas do RUP. Isso é claramente possível para a SRR e a PDR, que podem ser combinadas com a Revisão dos Marcos de Objetivos do Ciclo de Vida  e a Revisão da Arquitetura do Ciclo de Vida , respectivamente.

Organização do Projeto

Assim como o processo de software é influenciado pelas características do projeto, a organização do projeto também sofre essa influência. A estrutura padrão, aqui apresentada (consulte a figura abaixo), precisa ser adaptada para refletir os efeitos de alguns fatores, como os que aparecem listados:

• Contexto dos Negócios
• Tamanho do Esforço para Desenvolvimento do Software
• Grau de Inovação
• Tipo de Aplicativo
• Processo de Desenvolvimento Atual
• Fatores Organizacionais
• Complexidade Técnica e Gerencial

Estes são os principais fatores distintivos ao analisar como toda a organização deve adotar um novo processo de desenvolvimento. Aqui, examinaremos seu efeito na escolha da estrutura do projeto. A figura a seguir apresenta uma organização de projeto padrão, que mostra como as responsabilidades são atribuídas à estrutura de equipe.

Figura que mostra a Organização Padrão do Projeto. Observe que não há valor em termos de maturidade ou autoridade na classificação dos papéis.

Essa figura é um ponto de início que orienta como as responsabilidades e os papéis no nível do projeto devem ser mapeados em uma estrutura de equipes. A figura também serve para destacar que as funções (mostradas nas caixas amarelas) não representam indivíduos, mas "chapéus" que um indivíduo (ou uma equipe) pode usar durante o projeto. É por esse motivo que alguns papéis (o de Coordenador de Projeto, por exemplo) aparecem mais de uma vez. Isso indica que, em algum momento, a função de Coordenador de Projeto, conforme definido no RUP, poderá aparecer em mais de uma equipe. Por exemplo, em um grande projeto, a tarefa de preparação de um relatório de status em uma Estrutura de Divisão de Trabalho pode ser delegada a um indivíduo da Equipe de Administração. No entanto, essa é uma responsabilidade que o RUP designa à função denominada Coordenador de Projeto.

Em um pequeno projeto, é provável que um indivíduo indicado como Coordenador de Projeto execute todas as atividades da função denominada Coordenador de Projeto. Nesse caso, a Equipe de Administração funde-se na Equipe de Gerenciamento de Software. A seleção da estrutura da equipe será influenciada pela natureza e pelo tamanho do projeto, mas deve ser conciliada com algumas regras de grande senso comum:

• pequenas equipes geralmente são mais produtivas; entretanto, em um grande projeto, deve haver um equilíbrio em relação à freqüência de interação entre as equipes
• hierarquias complexas devem ser evitadas
• a extensão de controle de qualquer gerente ou chefe de equipe deve ser limitada a mais sete ou menos dois
• a estrutura da equipe de desenvolvimento de software deve ser orientada pela arquitetura do software; uma arquitetura apropriada, de alta coesão e pouco acoplamento entre os subsistemas, permitirá que as equipes trabalhem paralelamente
• é ideal que os testes, exceto o teste unitário, sejam realizados por uma equipe diferente da equipe de desenvolvimento. Observe, porém, que isso pode não ser econômico em um projeto muito pequeno
• a estrutura deve permitir que sejam atribuídas autoridades e responsabilidades claramente definidas a todas as equipes e indivíduos. Isso é particularmente importante quando a hierarquia ultrapassa três níveis. Os gerentes e os chefes de equipe, no meio dessas estruturas, precisam entender quais são suas funções para equilibrar as tarefas técnicas e gerenciais.
• a estrutura deve suportar os recursos, a experiência e as motivações da equipe: por exemplo, se uma única equipe deverá executar a análise, o design e a implementação, sem qualquer entrega intermediária, ela precisará de todas as competências necessárias. Analistas experientes não são necessariamente bons implementadores;
• as estruturas de equipe não devem ser inflexíveis: os indivíduos migrarão entre as equipes durante toda a vida útil do projeto e as responsabilidades das equipes serão alteradas à medida que a ênfase do projeto passa de uma fase para outra.

Os fundamentos da organização padrão serão descritos detalhadamente em [ROY98]. Em particular, as responsabilidades de implementação designadas para a equipe de avaliação de software reconhecem que, entre todas as equipes em um projeto de desenvolvimento, a equipe de avaliação de software tem a maior exposição ao software como o usuário irá vê-lo.

Durante a vida útil de um projeto, a organização se desenvolverá a fim de suportar a estrutura de divisão de trabalho capturada no plano de projeto. Isso é mostrado na figura a seguir, extraída de [ROY98].

Essa evolução enfatiza um conjunto diferente de tarefas em cada fase:

• a equipe de Iniciação: uma organização com foco no planejamento, com suporte suficiente das outras equipes para garantir um consenso dos planos de todas as perspectivas;
• a equipe de Elaboração: uma organização com foco na arquitetura; as forças incentivadoras do projeto estão associadas à equipe de arquitetura de software e com suporte das equipes de desenvolvimento de software e de avaliação de software, quando necessário, para atingir uma linha de base de arquitetura estável;
• a equipe de Construção: uma organização equilibrada em que a maior parte das tarefas está associada às equipes de desenvolvimento de software e de avaliação de software;
• a equipe de Transição: uma organização com foco no cliente na qual o feedback de uso orienta as tarefas de implementação.

A migração entre as equipes durante essa evolução permitirá manter o conhecimento e a capacidade dentro do projeto. Por exemplo, quando a elaboração estiver concluída, alguns membros da equipe de arquitetura poderão ser transferidos para as equipes de desenvolvimento, podendo atuar como chefes de equipe ou transmitindo a 'visão' de arquitetura para o desenvolvimento. Por último, quase no final da fase de construção, o foco será na equipe de avaliação, e o pessoal passa da equipe de desenvolvimento para a equipe de avaliação. Nesse estágio, também é importante evitar a perda da integridade arquitetural, que se encontra no auge da construção, e evitar que a influência da equipe de arquitetura não se perca como 'centro de gravidade' à medida que o projeto for evoluindo. Mudar alguns membros da equipe de arquitetura para a equipe de avaliação é uma maneira de fazer isso.