Discussão  

Existem várias obrigações subjacentes a esse princípio. A primeiro é que precisamos fornecer o valor incremental para ativar o feedback inicial e contínuo. Isso é feito conduzindo nosso projeto dentro de conjunto de iterações. Em casa iteração, executamos alguns requisitos, design, implementação e teste de nosso aplicativo, produzindo assim uma distribuível, que é a etapa mais próxima da solução final. Isso permite demonstrar o aplicativo aos usuários finais e a outros investidores, ou permite a eles utilizarem o aplicativo diretamente, possibilitando que forneçam um rápido feedback sobre como estamos indo. Estamos na direção certa? Os investidores estão satisfeitos com o fizemos até agora? Precisamos alterar os recursos implementados até agora?   E finalmente, quais recursos adicionais precisamos implementar para aumentar o valor comercial? Respondendo satisfatoriamente a todas as perguntas, é mais provável que possamos criar confiança entre os investidores que o sistema que estamos desenvolvendo atenderá suas necessidades. Será também menos provável precisar sobre-arquitetar nossa abordagem ou incluir capacidades que não são tão úteis ao usuário final.

A segunda obrigação é alavancar demonstrações e feedback para adaptar nossos planos. Em vez de contar com a avaliação das especificações, como as especificações dos requisitos, modelos do design ou planos, precisamos avaliar o quanto e como o código desenvolvido assim realmente funciona até aqui. Isso significa que precisamos testar resultados e demonstrações do  código de trabalho aos investidores para determinar como estamos indo. Isso fornece um bom conhecimento sobre onde estamos, como a equipe está progredindo e se precisamos fazer correções para concluir com sucesso o projeto. Poderemos então utilizar essas informações para atualizar o plano geral para o projeto e desenvolver planos detalhados para a próxima iteração.

A terceira obrigação subjacente é adotar e gerenciar alterações. Os aplicativos de hoje são muito complexos em requisitos, design, implementação e teste para alinhar-se perfeitamente logo na primeira vez. Entretanto, os métodos de desenvolvimento de aplicativo mais eficientes adotam inevitáveis alterações. Através de um feedback inicial e contínuo, aprendemos como melhorar o aplicativo, e a abordagem repetitiva nos oferece a oportunidade de implementar essas alterações incrementalmente. Todas essas alterações precisam ser gerenciadas tendo os processos e as ferramentas corretas de forma que possamos gerenciar efetivamente sem retardar a criatividade.

A quarta obrigação subjacente é que esse princípio é necessário paraconduzir os principais riscos inicialmente no ciclo de vida, conforme ilustrado no diagrama abaixo... Precisamos endereçar os principais riscos técnicos, comerciais e programáticos o mais cedo possível, em vez de adiar a resolução dos riscos para o final do projeto. Isso é feito através de contínua avaliação dos riscos que precisamos enfrentar, e conduzindo os principais riscos restantes na próxima iteração. Em projetos bem-sucedidos, inicialmente as iterações envolvem a aquisição do investidor em uma visão com requisitos de alto nível, incluindo design arquitetural, implementação e teste para eliminar os riscos técnicos. É importante também manter as informações necessárias para forçar decisões em torno dos principais ativos reutilizáveis ou software COTS (commercial-of-the-shelf) a ser utilizado.

Perfis de Redução de Riscos para Desenvolvimento Repetitivo e em Cascata.

Um objetivo principal com o desenvolvimento repetitivo é reduzir risco logo no início. Isso é feito analisando, priorizando e atacando os principais riscos em casa iteração (consulte: Material de Suporte: Desenvolvimento Repetitivo).  Orientação Adicional sobre como ajudar a organizar o ciclo de vida do desenvolvimento em torno das iterações é oferecida em  Conceito: Iteração e  Conceito: Fase.