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

接收程序员的技术早餐

作者 | Adam Ard

编辑 | Alice

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、减少技术债务或者冒险，这是因为其极为狭隘地仅关注执行产品负责人认为有价值的项目。

经理或产品拥有者往往并没有对所开发的产品进行全程追踪及评估，也很少提供指导性意见。

并未要求他们以每两周一次的频率组织会议以证明当前工作的正确性。

并未要求他们提供详尽图表以证明目标是否已经阶段性完成。

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

其假设工程师们不具备任务追踪系统（但实际情况恰恰相反），因此需要时间管理手段以约束其时间分配方式。

其假设工程师们无法指导自己的工作内容。

其假定工程师们在未经严格监督的情况下，无法与组织的最佳利益保持一致。

其假设工程师们无法在缺少协调员（Scrum Master）的前提下高效进行会议讨论。

其假设可以通过在冲刺阶段 / 库存清理阶段通过讨论规划软件任务中的各方面问题。

其假设所有工程师都以同样的方式工作。

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

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

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

个人与流程及工具间的相互作用

通过全面的文档进行软件构建

通过合同谈判实现客户协作

根据计划作出变更回应

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