从产生的过程来说

对于水晶方法论或轻量RUP，其产生过程始终是老的偏重的方法论的裁剪和优化，其理论支撑基础仍然是传统软件工程，因此不管如何轻量我们仍然可以看到这些方法论有比较明确的过程和阶段，产出要求，岗位角色，过程和配置管理等等基本内容。所以是一个重过程裁剪为轻过程。

而对于scrum，这个词语最早是橄榄球里面的争球，最好引入到了软件开发中，scrum核心思想是敏捷，是借鉴外来的团队协同，敏捷，可视化多方面的经验新构建的一套方法论，是一种从无到有的创新，这套方法并不会一开始就受到传统工程哪些必备的约束，完全根据目标和价值驱动来选择关键活动和最佳实践。

从目标，假设和约束来说

对于水晶方法论或轻量RUP，其基本假设仍然是遵循一定过程可以带来好的产品，即使裁剪后仍然保留软件生命周期的影子，是重过程而弱化人，这些方法论为了适应变化对传统方法进行了调整，但是并没有碰触到传统方法的根源，工程+过程仍然是核心，可以做到适应变化，是偏被动的心态。

而对于scrum，其驱动的目标是客户和价值，是由该目标驱动我们应该如何做，所有的最佳实践也仅仅是参考，关键是满足客户目标实现产品价值。scrum本身核心是重视人而轻过程，过程为人和产品价值服务，人+客户是核心，不仅仅可以做到适应变化，而通过自适应调整做到拥抱变化，是一种主动积极的心态。

从方法论的内容上来看

对于水晶方法论或轻量RUP，其方法论的核心是软件工程，中间兼顾少来的项目管理和过程管理的内容，所以更多的是对软件生命周期过程，阶段步骤，产出验证，角色分工，过程质量等方面的内容。而对于项目管理本身的内容在方法论中谈及的比较少。

而对于scrum，其方法论的核心是团队管理和项目管理，然后才是软件工程。包括看板可视化，站立会议，燃尽图，在backlog中引入的估算和任务直接分解等都属于项目管理方面的内容。而对于需求究竟要如何做，设计要如何做？需求，设计开发有哪些明确的边界并不太在意。scrum是期望客户目标和项目目标来驱动开发过程，而不是已经有一套软件工程方法模板再来考虑项目如何管?

从系统分析和架构设计来看

对于水晶方法论或轻量RUP，基本会保留总体架构设计的影子，或者说RUP本身就很强调以架构为核心，架构设计的概念完整性。在高层的系统分析和建模，在轻量的RUP中有时候很难去迭代。我们一直在讲架构包括了业务分解，业务抽取，系统分解和系统集成四个关键步骤，如果真有了这四个步骤，那么就难以实现所有业务需求按user story的全程条目化贯穿和跟踪。

而对于scrum方法论，其假设是架构设计工作也是一个迭代的过程，同时将架构设计的工作融入到已有的backlog的user story中。这虽然有一些问题，但是真正可以实现全程的条目化估算，跟踪和执行。这个往往是我们后面所说的可视化跟踪，集成，燃尽图实践的基础。