为什么说Scrum并不适用于软件开发？

1、由于全部产品决策权皆归“产品拥有者”所有，因此 Scrum 不允许工程师们在产品方向的各个层级当中作出任何产品决策，且严格控制其产品管理权。

2、Scrum 以紧密管理方式占用了工程师们的全部时间，因此会阻碍大多以自发形式出现、且无法匹配任何具有良好可预测性的时间表或系统的创新活动。

3、Scrum 鼓励“尽可能减少工作量”类解决方案，旨在满足严格的可预测性要求。

4、通过将每项任务拆分成理论上可由团队中任何成员完成的小型项目，Scrum 实际上并不鼓励工程师们对自己的工作内容形成自豪感或所有权。这种所有权的缺失将导致：

5、Scrum 对修改任务极度不友好，而这一理念的支持者们在实现当中往往采取全有或全无的态度。

“Scrum 的角色、工作内容、事件以及规则是不可改变的，且尽管可以仅采用 Scrum 的部分理念，但结果却与 Scrum 无关。Scrum 只存在于其中 ，并充当其它技术、方法及实践的容器。”

6、Scrum 对于自我反省的低容忍态度贯穿于其全部实践当中。只有在 Scrum 框架内部运行的流程才能够进行修改——而就 Scrum 本身而言，其基本规则可谓“神圣不可侵犯”。

7、Scrum 是一种重度管理工具。典型的团队当中需要具备产品拥有者、Scrum Master 以及团队负责人。但实际上，创新且积极的团队要求更少干涉、更好管理——Scrum 显然恰恰相反。

8、Scrum 通常使用非常差劲的任务管理工具（例如 Jira、tfs 等等），这些工具会对 Scrum 的执行作出非常官僚化的解释，因此导致开发人员的时间被大量浪费。此外，无论效能多么低下，Scrum 都会将工程师们牢牢锁定在这一种运营模式当 。

9、Scrum 不鼓励修正 bug、减少技术债务或者冒险，这是因为其极为狭隘地仅关注执行产品负责人认为有价值的项目。

10、Scrum 具有虚伪性：

11、Scrum 作出大量错误的假设：

12、Scrum 故事点被广泛认定为毫无意义，但其仍在组织内的各个层级中被加以追踪、记录与展示，且继续作为团队绩效的惟一指标（即速度）。

13、Scrum 的设计目标在于管理能力最为低下的工程师，但这会令更杰出的人才遭到束缚。

14、Scrum 与初始敏捷宣言中提出的许多观点正好相反：

15、Scrum 忽略了一项事实，即软件开发领域当中任何已经完成的任务皆可以复用方式再次起效，而无需重新构建。这意味着在 Scrum 的范围之内，任何新的软件任务都属于从零开始的工作，导致我们很难对其加以预估。