最近,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才碰到的,如果你纵观自管理团队的过去以及相关资料,其实管理者角色的改变也是同样的问题。不过,就像是很多其他事情,当被告知不再需要当下的一些事务的时候,很容易就会被解释成“反”。