Bom, sei que algumas discussões como estas ficam polêmicas e muitas vezes são travadas pelos moderadores do fórum, mas vamos lá…
Discordo completamente. São estes projetos que se beneficiam mais das práticas ágeis. Aliás, só consegui justificar o uso de tais práticas em projetos grandes, onde havia um grande número de requisitos (necessidade de um backlog priorizado), uma grande lack de entendimento de requisitos (entregas contínuas, retrospectiva), uma estimativa não tão precisa (sprint planning), equipes grandes e distribuídas (reunião diária e kanban) além de outras práticas de engenharia, como TDD, pair programming, etc
Se você consegue ser ágil com projetos grandes, por que cascatear nos pequenos? Cascata não é metodologia, aliás isto nunca sequer nasceu, foi uma prática comentada no famoso artigo do Royce e condenada no mesmo artigo. O problema é que tendemos achar que desenvolvimento de sw é como engenharia civil, que temos o planejamento, o projeto, a construção, o teste e a entrega. Eu me incluo nisso , já pensei muito assim
Não entendi muito bem o que significa “RUP com espiral”. Muita gente diz que usa RUP mas faz mesmo é cascata. Aliás, o RUP é mais próximo a XP e Scrum do que cascata. Se começássemos a desenvolver com processo iterativo e incremental (cartilha do RUP) já estaríamos bem melhores. Ah, outro dia descobri que não posso dizer que uso RUP na minha empresa senão tenho que pagar à IBM. Então uso OpenUP.
Concordo com quem diz que utilizar práticas ágeis em softwares produtos (prateleira) seja um pouco mais fácil, pois neste caso normalmente já há uma cultura de roadmap e releases do produto, o que podemos facilmente aliar aos sprints. Mas isto por causa da cultura e do costume das pessoas porque dá pra ser ágil em qualquer projeto.