O método Waterfall é certamente viável e é tão filosoficamente correto quanto qualquer outra abordagem. Lembre-se que o Waterfall tem estado muito mais tempo do que o Agile, mas note que este não é um argumento para afirmar se uma metodologia é melhor do que outra.
Você usa o método Cascata quando tem um entendimento muito claro sobre todo o domínio do problema e o que o cliente deseja alcançar em um pacote de software. Você provavelmente citou um preço fixo ao aceitar o contrato, e seu cliente entende que não pode se desviar de quaisquer requisitos acordados. Seu processo é estritamente um que flui através de uma série de assinaturas entre os vários estágios de desenvolvimento, e é frequentemente o caso que cada estágio é completado por uma equipe diferente - às vezes até uma empresa diferente - cada qual não necessariamente em contato com os outros. Você vê frequentemente que a Waterfall é aplicada com bons resultados em projetos militares e governamentais quando são oferecidos a contratados externos. Onde a Waterfall e outras abordagens similares obtêm uma má reputação é quando os desenvolvedores se deparam com problemas, tais como estimativas precárias, cronogramas planejados sem tempo de contingência ou uma compreensão deficiente ou incompleta do domínio do problema. A questão nunca é verdadeiramente uma falha da metodologia, mas na aplicação dela.
A comparação entre o Agile e qualquer metodologia é falsa. Agile não é uma metodologia, é uma filosofia, ou talvez seja melhor dizer que é um termo abrangente que representa uma maneira diferente de ver como você desenvolve o software. Uma metodologia é meramente uma ferramenta e, como tal, seu valor sempre será menor do que os indivíduos e as interações que estão no centro do o que significa ser Ágil .
Does anyone really think that minimizing change in software is a viable option for those that desire to deliver valuable software?
Todas as oportunidades para minimizar a mudança são valiosas para o desenvolvedor e para o cliente. As alterações podem fazer com que um cronograma escorregue ou que os recursos sejam deixados de fora para cumprir um cronograma. É como você gerencia os efeitos da mudança que impactam no valor de seus projetos.
Or is the question really about what sort of practices work best in our situations to manage the inevitable change?
Suas práticas podem ajudar no gerenciamento de mudanças, ou elas podem ignorar mudanças completamente. O que importa é a combinação de suas práticas de desenvolvimento e o gerenciamento de seu relacionamento com seus clientes, e se essas coisas funcionam juntas de maneira eficaz para todas as partes envolvidas.
Aqueles de nós que são, para todos os efeitos, Ágil entendem que você escolhe um método que funcione para você. Se você gosta de uma abordagem particular, siga-a. Se não se encaixa perfeitamente às suas necessidades, altere-o. O modo como você trabalha na criação de software realmente se resume a tentar fazer o melhor uso dos recursos disponíveis e minimizar as práticas que podem levar o projeto à falha, e você geralmente acha que precisa mudar o método para se adequar ao software. projeto específico em mãos.
É realmente uma coisa dizer "Ok, então agora somos Ágeis", e totalmente outra é realmente viver e trabalhar pela filosofia que o Agile é. Se você usa Cascata, Incremental, Espiral, SCRUM, XP, FDD ou qualquer outro método, você é basicamente Ágil onde você valoriza:
- Indivíduos e interações sobre processos e ferramentas
- Software de trabalho sobre documentação abrangente
- Colaboração do cliente sobre negociação de contratos
- Respondendo para mudar depois de um plano
e onde você coloca suas ferramentas, método e sua experiência juntos para aplicar esses valores com êxito.