1, 由于全部产品决策权都归 "产品所有者" 所有, 因此 Scrum 拒绝工程师做任何产品决策, 并在产品方向上减少任何级别对产品管理的卑躬屈膝.
2,Scrum 用紧凑的管理方式占用工程师所有的时间, 抑制了创新 -- 这些创新向来不由自主地发生, 并且超出了任何时间表或者有良好预测性系统的范畴.
3,Scrum 鼓励 "尽可能减少工作量" 的解决方案 -- 来满足它严格的可预测性的需求.
4, 将每个任务都拆分成小项目, 团队中的任何人理论上都能完成. Scrum 劝阻工程师对自己的工作产生自豪感或者所有权. 这种所有权的缺失会导致:
设计质量不高
缺乏积极性("这不是我的事","我开始做之前就出问题了")
5,Scrum 对修改是非常不能容忍的, 它的拥护者在实施的过程中通常秉着全有或者全无的态度. 在所有的实践中都体现了以这种不宽容态度的自我反省. 只对运行在 Scrum 框架层内部的进程开放修改 -- 就 Scrum 自己而言, 这被视为神圣而不可侵犯的.
"Scrum 的角色, 工件, 事件和规则都是不可修改的, 并且尽管可以只实现 Scrum 的某些部分, 但是其结果并不是 Scrum.Scrum 的存在感仅仅在于作为其它技术, 方法及实践的容器时它的完整性和功能尚佳."
Scrum 官方指南, http://scrumguides.org/scrum-guide.html
6,Scrum 是一个重型的管理工具. 典型团队有产品拥有者, Scurm 控制者, 和团队领导. 伴随更少管理的创新能促进团队做的更好, 而不是更多的管理.
7. Scrum 通常是使用 HORRIBLE 任务管理工具 (Jira,tfs 等) 实现的, 这些工具对 Scrum 做了非常官僚化的解释, 浪费了大量的开发人员时间. 此外, 无论多么无效, 它们都可以有效地将你限制在一种操作模式中.
8. Scrum 不鼓励修复 bug, 减少技术债务和承担风险, 这全都是因为其狭隘并排他地专注于只做产品负责人认为有价值的项目.
9.Scrum 是虚伪的
管理人员或产品所有者是否需要跟踪和评估他们所从事的每项任务?
他们是否需要出示燃尽图表来显示他们的目标是完成的?
他们是否需要进行两周的抛售会议来证明他们的行为是正当的?
10.Scrum 有很多错误的假设.
它假定工程师没有任务跟踪系统, 他们已经使用这些系统来管理他们的时间, 因此需要细致得时间管理.
它假定工程师们不能被信任来指导他们自己的工作.
它假定工程师们不能在没有严格监督的情况下, 使自己符合本组织的最佳利益.
它假设工程师不能在没有主持人的情况下有效地进行会议(Scrum Master)
它假定你仅仅可以通过在 sprint planning 或者 backlog grooming 中谈论它来计划一个软件任务的每个方面.
它假设所有的工程师都以同样的方式工作.
11.Scrum 的描述点是毫无意义的, 然而它们在一个组织的很多级别中都会被跟踪, 记录和体现, 而且它们经常作为唯一的度量标准, 以此来度量一个团队所体现出来的业绩.
12.Scrum 是为管理菜鸟工程师而设计的, 也因此将更好的工程师拒之门外.
13. Scrum 与原始敏捷宣言中提出的许多观点相左:
个人与流程和工具之间的相互作用
通过全面的文档处理软件
客户协作通过合同谈判
根据计划做出响应
http://www.agilemanifesto.org/
14. Scrum 忽略了在软件中以前完成的任何任务都不需要重做的事实, 因为它可以很容易地复制并重用. 因此, 根据定义, 新的软件任务是真正的新领域, 因此很难预估.
来源: http://www.mzh.ren/why-scrum-is-the-wrong-way-to-build-software.html