Rup (da IBM, ou UP o processo unificado), não é cascata, mas também não se enquadra no manifesto ágil, mas foi concebido para ser um processo versátil, no qual pode-se adaptá-lo a pequenos, médios e grandes projetos com muito sucesso.
Além do mais, é possível usar Rup em conjunto com metologias Ágeis, elas se auto complementam.
Porém Rup se não for bem aplicado, pode acabar se tornando muito formal, prescritivo, muito centrado nos modelos e nos casos de uso.
No RUP há um grande enfoque na definição do escopo na primeira fase dessa metolologia que é a de Concepção, o que foge das características de uma metodologia ágil.
Metodologias ágeis (Scrum) colocam como prioridade o cliente como um componente da equipe.
Rup é mais que uma metodologia, é um framework, um conjunto de ferramentas, de documentos, técnicas de documentação, de elaboração e análise, Scrum é mais uma metodologia bem conceitual.
Rup formaliza os modelos, o sistema precisa ser o que está escrito, tudo que ele precisa já deve ter sido especificado, documentado.
As metologias ágeis tratam os modelos mais como um esboço e não como o molde para o sistema, elas pregam que é mais barato desenvolver pedacinhos e entregá-los para avaliar do que elaborar toda uma documentação e depois só implementar.
Apesar de RUP ser incremental, o motivo para tal não é esse e sim mitigar riscos principalmente de arquitetura.
No RUP há uma ênfase em se elaborar um projeto detalhado do sistema como uma fase distinta do processo.
E embora se prevejam entregas parciais (chamadas "liberações") elas em geral não estão destinadas a entrar em produção (são mais para colher feedback).
Desde a fase de Elaboração, o RUP já prevê atividades de teste e entrega. Aliás a ideia toda dessa fase é ter uma arquitetura executável para mitigar os maiores riscos do projeto cedo.
O Scrum como outras metodologias ágeis possuem declarações de idéias utópicas a se aspirar.
São diversas idéias, algumas aproximam-se mais que outras da realidade, mas a agilidade absoluta nunca poderá ser alcançada na prática.
Processos ágeis como o Scrum começam com uma burocracia mínima e pode-se acrescentar ao processo o que for necessário.
Frameworks como o RUP trazem um arsenal de papéis, atividades, artefatos e você precisa retirar os que você não vai usar.
Após passar por um processo de adaptação, o RUP pode tornar-se um tanto parecido com o Scrum.
Frameworks de processos como o RUP foram concebidos como ferramentas aos gerentes.
Metodologias ágeis como o Scrum focam na auto-organização da equipe.
RUP é um framework "Top-Down", começa pelas necessidades dos superiores, é bem forte no quesito "controlar o que está sendo feito".
Scrum é uma metodologia "de baixo para cima", focado em eliminar qualquer entrave no andamento do projeto, agilizar ao máximo.
Em empresas, ambos acabam sendo de alguma forma necessários, um para ajudar os gestores, a controlar melhor, a documentar e mitigar riscos de arquitetura, enquanto o outro a mitigar entraves e falhas de comunicação.
Both methodologies approach project activities in the iterative way.
However, RUP methodology calls for a formal definition of scope and major project milestones are associated with specific dates.
SCRUM methodology uses project backlog instead of scope and allows the backlog to be redefined at the end of each iteration
(usually about every 4 weeks).
In addition, RUP subdivides the project lifecycle into 4 major phases (Inception, Elaboration, Construction, Transition).
Even though it encourages concurrent workflows across the entire cycle,
the general understanding is that certain activities will peak during certain phases
(for instance, requirements analysis will spike during the elaboration phase).
On the contrary, SCRUM dictates that the entire “traditional” lifecycle fits into one iteration.
In other words, a workload for one iteration at a time is determined and then the entire cycle occurs within one iteration
(e.g. the requirements for a particular feature are collected, documented as a user story, then coded, tested and presented for the user review).
| Differences | RUP | SCRUM |
|---|---|---|
| Approach | Iterative | Iterative |
| Cycle | Formal Cycle is defined across 4 phases, but some workflows can be concurrent. | Each sprint (iteration) is a complete cycle. |
| Planning | Formal project plan, associated with multiple iterations, is used. The plan is end-date driven and also has intermediate milestones. | No end-to-end project plan. Each next iteration plan is determined at the end of the current iteration (NOT end-date driven). Product Owner (Key Business User) determines when the project is done. |
| Scope | Scope is predefined ahead of the project start and documented in the Scope document. Scope can be revised during the project, as requirements are being clarified, but these revisions are subject to a strictly controlled procedure. | Instead of scope, SCRUM uses a Project Backlog, which is re-evaluated at the end of each iteration (sprint). |
| Artifacts | Vision/Scope Document, Formal functional requirements package, system architecture document, development plan, test plan, test scripts, etc. | The only formal artifact is the operational software. |
| Type of Project/Product | Recommended for large, long- term, enterprise-level projects with medium-to-high complexity. | Recommended for quick enhancements and organizations that are not dependent on a deadline. |
Links:
https://www.thoughtworks.com/pt/insights/blog/agile-theory-vs-practice