为什么说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作出大量错误的假设：其假设工程师们不具备任务追踪系统（但实际情况恰恰相反），因此需要时间管理手段以约束其时间分配方式。其假设工程师们无法指导自己的工作内容。其假定工程师们在未经严格监督的情况下，无法与组织的最佳利益保持一致。其假设工程师们无法在缺少协调员（Scrum Master）的前提下高效进行会议讨论。其假设可以通过在冲刺阶段 / 库存清理阶段通过讨论规划软件任务中的各方面问题。其假设所有工程师都以同样的方式工作。

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

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

14、Scrum与初始敏捷宣言中提出的许多观点正好相反：个人与流程及工具间的相互作用通过全面的文档进行软件构建通过合同谈判实现客户协作根据计划作出变更回应

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