不要再自作多情，2020版Scrum框架和软件研发没有关系，甚至和IT都没有关系

Posted 2021-04-25 软件质量报道

刘先生：一个小孩要健康茁壮成长，专家说要营养均衡，多吃健康食品，但是家长忙，没有时间，但是有钱，就买各种高油、高糖、高热量的套餐/快餐，结果经常吃，天天吃，小孩得病了，快餐店赚了大钱了，然后还全世界开了连锁店......

钢豆豆：最近我们在搞认证，我就是觉得这个东东开始走ISO9000、CMM、CMMI等这些形式主义花架子的老路了。会不会以后认证完就是挂在墙上的一个摆设，开发测试还是那样

蔡先生：SM群众基础已经很大了吧？大到反正我是不好意思提自己是CSM了[呲牙]

张先生：谈到敏捷的历史和未来时，Robert C. Martin指出，敏捷——Kent Beck及其他发明者最初设想的一种方法——长期以来被一大批通过认证的Scrum master和不了解软件怎么开发的业务人员所劫持（就好比城市里的孩子不知道土豆怎么变成薯片）。[敏捷]认证变成了这个“诱人的歌声”；坦率地说，它吸引了所有不该吸引的人。敏捷是由技术人员开发的。它是软件行业的产物——程序员坐在那个房间里，搞出了《敏捷宣言》和敏捷原理。随后出现了认证。通过认证，成群结队的项目经理开始获得认证。他们会在课堂里坐上两天，拿来一张纸，觉得敏捷很重要。而他们实际上接管了敏捷运动……敏捷运动朝着项目管理方面急剧转移。

不要再自作多情，这次发布的 2020版Scrum框架和软件研发没有关系，甚至和IT都没有关系，我从头到尾看了指南，通篇没有发现 “软件”、“代码”等。也正如2020 版指南第6项修改内容所指出 “ 为更广泛的受众而全面简化语言” 更彰显了这一点：着重删除所有与 IT 工作相关的推断 (例如测试、系统、设计、需求，等等)，所以它越来越不是软件的研发框架。

其实本来它就不是，Scrum 原来就没有包含什么优秀的软件研发实践，如果你把它和极限编程（XP）一对比，就更加明显，XP倒是有比较多的适合敏捷开发的优秀实践，如代码规范、系统隐喻 ( System Metaphor )、简单设计、集体代码所有制、持续集成和小型发布等。而之前的Scrum框架中，几乎找不到和软件研发有直接关系的优秀实践。

只是两位创始人现在更加明确地宣布它不是软件研发框架，而是“针对一切复杂问题的自适应解决方案”，这也许暴露了两位创始人的野心，想一统世界各个领域？如果是这样，其实这不是他们的专利，他们也不是创始人，见文章 ，而只是二道贩子。 

当年，Rational 建立了Unified Process（RUP）想一统软件开发模式，结果今天几乎没有什么团队在用RUP，已经失败。Scrum想统治更大的世界，几乎不可能。普适性和有效性往往是矛盾的，越普适就越不有效，每个公司有不一样团队、不一样的产品、不一样的环境，需要找到更适合自己的开发框架，更何况软件研发有自己的特色？

从 2017 版到 2020 版指南的另外六项变更，其实也没多大意义： 

1. 规定性更低，例如删除了 Daily Scrum 三个提问，淡化了关于 PBI 属性的相关描述等，但还是保留了“Daily Scrum 是一个属于 Scrum Team 的 Developers 的 15 分钟的事件”、“以一个月的 Sprint 来说最多为 8 个小时”，规定这样的时间，其实是不合适的，也是违反了这次修改的意图。

2. 一个团队专注于一个产品，其实很难，看如何定义“产品”。产品其实比较大的概念，特别是今天的产品更复杂、规模更大，许多时候，团队只能专注一个组件、一个微服务，或者说，专注一个共同的目标，这是本次修改的重点，特别强调 “Goal”，但这就没有新意，我们之前定义团队时，就是强调团队共同拥有一个目标，大家为实现目标发挥各自的作用，缺一不可。 

3. “Product Goal” 提出并不一定是好事情，容易往特定目标引导，而忽视了用户真实的需求。目标和价值又有什么关系呢？

4. 为了给 Sprint Goal 、 Definition of Done 和 Product Goal 安家而安家吗？有了它们，产品研发的透明度真有改进吗？难道 “product backlog” 和 “sprint backlog” 不是承诺？

5. “自管理胜过自组织” 感觉就是在玩文字游戏，其实这样的改动也没有意义，世界上也很难存在自管理、自组织的团队，除了少数卓越的团队，对绝大多数的团队这很难，这也说明Scrum不具有普适性。 

6. 2020 版 Scrum 指南还强调了第三个话题“为什么”，即 Sprint Goal ，难道之前我们没想这个问题？在列product backlog items时，就是从对用户价值去考虑、去排序，谈用户价值，就是思考“为什么”。增加 Sprint Goal其实是多此一举，无论是release planning还是sprint planning，任何计划，首先要考虑的都是目标、为什么做这个（产品/迭代/项目），这是常识。

Scrum 作为一个轻量的框架，其实慢慢脱离敏捷研发模式的轨道，滑向深渊，例如太强调Scrum Masters的作用，说他是真正的领导者。这是为了更好地销售“Scrum Masters”的认证？

新版指南，里面也是矛盾重重 ，例如，一方面要求大家原封不动地去尝试，另方面又说Scrum 框架故意不完整，那如何原封不动地去尝试？“通过遵循 Definition of Done（DoD） 来注入质量”，DoD成了规则？不需要设计规范、实施规范、流程规范吗？

Scrum Master 对 Scrum Team 的效能负责 ，为什么不是Developers对效能负责？ 效能主要靠开发人员，效能不仅来自流程，而且可以来自于技术，更取决于developers的能力。文中还提到Developers对质量负责，只对质量负责，而不对效能负责，真有意思。

“ Scrum Team 是跨职能的(cross-functional)，这意味着团队成员具有在每个 Sprint 中创造价值而 所需的全部技能 ”，这种提法容易误导大家，Scrum Team拥有全部技能，团队成员其实可以各有特长，包括架构设计、编程、UI设计、测试、SCM等不同的专向能力。团队分工还是必要的，否则也没有必要定义Product Owner、Scrum Masters，或者说，谁又合适担任这样角色（PO、SM）呢？

“ 前一个Sprint结束后，下一个新的Sprint紧接着立即开始 ”，这种提法也是有问题的，原始的Scrum方式是希望迭代有overlap（重叠），这是对资源更好的使用，而且有利于缩短研发周期，大家想想Product Owner所做的工作和developers是完全同步吗？

“ Sprint Planning 处理以下话题: 话题一:为什么这次 Sprint 有价值? ” 其实到Sprint Planning再来回答这个问题，其实太迟了，为什么不是在product backlog item中就要问这样的问题吗？即为什么不在release planning就问这样的问题？

帮助 Scrum Team 专注于创建 符合 Definition of Done 的高价值 Increment，为什么不是帮助 Scrum Team 专注于创建符合客户需求的高价值 Increment？

还有许多问题值得质疑：

1. Sprint期间不能降低质量，为什么不是不断改进质量的？

2. 尽管被证明是有用的，然而这些实践并不能用来取代经验主义的重要性？

3. “整个 Scrum Team 将共同制定一个 Sprint Goal，用以沟通当前 Sprint 对利益攸关者有价值的原因”， Sprint Goal成了价值的原因？

4. 作为专业人士对彼此负责，为什么不是对自己负责？ 

5. 检视使适应成为可能，为何不是反省？

6. ......