Scrum是在这些方面‘被失败’

最近，Bob大叔就采纳Scrum/Agile是否有短板的疑问作出了其“七宗罪”的回应。他说到，总的来说Scrum是有些严重的缺陷，并且也就大多数已经采用了Scrum的团队提出了避免这些问题的建议：

技术上没有建设：Scrum是个项目管理的框架，却没有针对技术做出任何建议。Bob建议团队“需要借鉴其他敏捷的方法学，比如XP（极限编程）。XP在技术方面的这套实践是很有帮助的：TDD（测试驱动开发）、持续集成、验收测试、结对编程、重构。”

太长的30天的Sprint:很多培训师建议一到两周的sprint，而且大多数团队接受了为期2周的。

Scrum大师（Scrum Master）有时候摇身成了项目经理：有些Scrum Master认为Scrum就是小型项目管理的方案。“总的来说，相比Scrum本身的问题，这更像人们有时候使用scrum的习惯所带来的问题。可能是因为不幸使用了‘大师’一词吧。”

CSM（Certified Scrum Master）认证：在那些有Scrum Master 认证或是经过训练的SCM的团队中，这些人带来的意义好像就是只有他们才可以扮演这个角色。Bob大叔更推荐XP的方式，就是把教练的角色融入到团队之中去。

Product Backlog在介绍上的不足：“经过这么多年的实践，从中我们学习到了backlog可以水平划分为epics，themes, stories等等。我们知道了如何科学的度量它们。我们知道了何时应该将高层级的实体切分为低层级的。Epics->Themes->Stories->Tasks。“

Scrum掀起了反管理的潮流：“Scrum过于的强调了团队的自我管理，自我组织。团队能实现自我管理是个好事儿，但这是有局限性的…对此问题，Scrum没有给出足够的弹性。”

多团队：Scrum和泛Agile很少提到该如何去做规模调整。很多实践家发展出了自己的观点，但在更广泛的层次上都还没有达成共识。

Steve Ropa，MX Logic的软件开发总监评论说：“以我个人的经验来说，团队以及成员需要一些决定权。有时候领导力会从团队之中涌现出来，也有不能的时候。Bob大叔提到团队成员在项目中会遇到交互的局限性问题，这点与我的个人经验完全吻合。”

Mark Woyna评论说：“如果团队负责周期性的交付高质量的产品，并且满足客户的需求，那么管理团队的需要从何而来呢？如果团队无法交付产品，并且自我调整不奏效，团队就该去寻求外面的帮助。”

Ron Jefferies, 《C#极限编程探险》的作者说：“大多数的scrum团队是在有管理者的组织中使用的。实际情况是过于活跃的管理者不仅仅没有帮到忙，反而更有可能作出不符合Scrum的行为。”

设计和测试工程师Matt Heuster建议说：‘“可能更准确的来形容CSM就是‘新开发模式的入门’，因为跳出开发的层次，这会帮助到整个软件开发团队成员，而不仅仅是团队中的某一、两个人。最后你会把‘认证’抛在一边，也不会用‘认证的’一词。”

“Scaling Lean & Agile Development”的合著者Bas Vodde重申说：“不想说是缺陷，不过想指出Scrum需要其它实践方法的支持。”并且，他并不把Scrum看作是反管理的潮流，相反：我觉得很多人纠结的问题是如何适应Scrum所带来的管理者角色的改变。自管理团队将责任下移到团队之中，所以管理的角色就会改变。更常见的是，管理者认为Scrum是个框架，‘他们’不用改变就可以用（‘你去Scrum吧’，意思是就快要完蛋了）。我不认为这是Scrum才碰到的，如果你纵观自管理团队的过去以及相关资料，其实管理者角色的改变也是同样的问题。不过，就像是很多其他事情，当被告知不再需要当下的一些事务的时候，很容易就会被解释成“反”。