在中国应如何改良 Scrum 框架

本文源自吴穹博士 CSDN 博客，部分内容有删改。原博文撰写于 2011 年 11 月，所代表的亦是 10 年前的观点。目前，Agilean 已推出了一套更适合中国企业、更易于落地的规模化敏捷框架 Adapt，本文末段亦有介绍。

首先，何为改良 Scrum 框架？Scrum Guide 开宗明义，Scrum 不是一个具体技术或流程，而是一个可以和其他流程和技术相结合来保证项目成功的框架。因此，将 Scrum 与其他技术相结合不是改良，而就是 Scrum 预设的用法，就想装修好的房子里面，再摆上家具一样。而所谓改良就是修改 Scrum 核心框架的内容，就想打掉一个屋子的一面墙一样。Scrum 框架的核心内容包括团队的角色定义，时间箱，交付物和规则，下面我们就一一看看应如何改造。

在改造之前，同时也需要了解哪些框架是 Scrum 的本质，因为如果修改了这些本质内容，那么就不是改良Scrum ，而是推翻 Scrum 了，这就好像装修不能打掉承重墙一样。Scrum 的三个支柱是透明，审视和适应。透明强调团队之间通过透明来加强新人，应对变化；审视和适应是指在过程中，通过不断审视来不断进行适应性改善 。好了，找到了承重墙，避开它们，然后就开始干吧！

1

角色定义 – Manager/Lead

首先，我们来看一下角色定义，Scrum 当中设定了三种角色：

• Product Owner

• Scrum Master

• Team

Team 当中由参与交付的 Developers、Testers 等角色组成，注意这里是没有给 Manager 和 Lead 留出位置，Scrum 框架当中隐含了团队应该是自管理的要求。这其实和欧美的实际情况有关，在那里你能看到大把的白头发程序员，而在国内，则非常稀少。

而在中国，在我帮客户实施敏捷的过程中，发现在许多组织中由于研发团队都很年轻，并不敢真正实施自组织，而 Manager 或 Lead 又没有了位置，于是纷纷伪装成了Scrum Master，然后一切照旧，而真正该做 Scrum Master 的人反而没有位置了。这造成了许多Scrum实施的失败。

其实，管理人是最难的一件事情，自组织只是一种可能的管理方式，而这种管理方式恰恰是在中国现在的软件企业里很难成功的管理方式。因此，我认为，应该改良 Scrum框架剥离自组织管理方式，而去强调 Manager as Coach。

“Manager as Coach”这一思想可以在敏捷的另一个流派-精益(Lean)当中找到，而且是Lean的基础，我觉得这种思维很可能更适合中国的现状，因为大多数团队中的成员都非常年轻缺乏经验，因此，他们需要的很可能并不是自组织，而是真正能 Coach 他们的 Manager 或者 Lead 。即使现在 Manager 和 Lead 还不称职，那么企业的重点也更可能应该是尽快提升这些 Manager 和Lead 的 Coach 能力，转变他们的思想，而并不是去推行自组织。

还有一点需要注意，这里说的Manager/Lead，不是只哪些只管人不干活的，Lean的思想建议，Manager/Lead 必须是有动手能力的领域专家，这样才能真正能做到 Coach 一线研发人员，否则就只能纸上谈兵了。另外，最近在微博上的讨论中，大家往往将信任和自组织画上等号，其实，有 Manger、Lead 并不代表不信任，这种非黑即白的看法是错误的。

综上所述，我建议，团队在应用Scrum框架时，如果认为应该采用Manager as Coach这种管理方式，那么就应该在Scrum框架的角色定义当中，明确加入Manager/Lead这个角色，也可以修改团队（Team）的定义，将Manager/Lead也作为团队的一部分。

2

活动 - Time Box

Scrum 框架的另一个大问题是对架构的忽视，而在中国，现在最大的问题不是过度设计，而是设计不充分。而Scrum更助长了这种轻视设计的风气。当然，强调架构设计并不一定意味要写很厚的架构设计文档，或者进行复杂的UML建模，如何进行架构设计，做到什么程度，应有团队自己决定。下面就看一下应该如何改进Scrum框架：

Scrum框架当中的活动有几个：

• Release Planning Meeting

• Sprint

• Sprint Planning Meeting

• Sprint Review

• Sprint Retrospective

• Daily Scrum

Release Planning meeting 基本上是一个目标计划会，与架构设计无关。而在每个 Sprint 的 Planning Meeting 上，会有两个部分，第一部份澄清需求，第二部分进行设计，但时间太短，往往无法承载架构设计。

因此，严格的照搬 Scrum 框架，在一些大量应用现成框架的产品开发过程中，或在一个产品的维护阶段，还可能成功。但是，对于大型复杂产品开发而言，不进行架构设计，结果基本上是灾难性的。

综上所述，建议团队在实施 Scrum 的过程中，在 Release Planning Meeting 之后，增加一个 Release Architecture Design Workshop 来进行架构设计，时间长度和 Release Planning Meeting 一样，当然，这个 Workshop 和 Release Planning Meeting 一样，也是可选的。

3

交付物 - Artifacts

Scrum 框架中的交付物有四个：

• Product Backlog

• Release Burndown

• Sprint Backlog

• Sprint Burndown

Product Baclog 比较简单，就是所有需要做的事情。这里特意没有明确 Product Backlog Item 是以什么方式定义的，以便可以集成这方面不同的实践（如用户故事，用例，FDD等）。

而在 Spring Backlog 的内容方面则有些问题，不太一致，细节就不在这里展开了，具体大家可以去看我的博客。我赞同最后在 Release Notes 当中的提法，Scrum Backlog 就是由本迭代希望完成的 Product Backlog Item 组成，这些 Item 可以进一步拆分成任务来追踪。

4

实施 Scrum 应保的态度

看到这里，我想读者对 Scrum 框架应该有一个初步的了解。在正式实施 Scrum 框架之前，首先需要看透 Scrum 框架的商业本质，对它抱一个正确的态度。

Scrum 框架其实可以被理解成是敏捷的商标，就象一个果农要卖苹果，卖一个两个那就卖了，但是如果要卖的多，那就需要有一个商标了。Scrum 框架也是一样，许多敏捷大师都有自己的敏捷理念，很难统一，于是，大家选定了这个形而上，空空的 Scrum 框架作为大家共同的商标，这样哪个大师也不会反对。

所以，你去上一节 Scrum Master 的培训，你得到了什么？一个证书，对 Scrum 框架的基本了解和许多许多培训师自己的敏捷实践经验。因此，能不能值回票价完全取决于培训师的个人能力而已，而那张证书可以肯定一定不证明你就是一个合格的 Scrum Master 了。

因此，在实施 Scrum 时，不要抱过高的期望，不要期冀银弹，而要抱着务实、开放、轻松的态度，根据企业的实际情况定制或扩展 Scrum 框架。

如何在中国实施改良 Scrum

改良 Scrum 框架根据中国的实际情况已经强化了管理者的作用，强化了架构的作用，但是在中国实施改良 Scrum框架还是会经常遇到一些阻碍，针对这些障碍，则必须克服才能取得成功：

1. 职能性组织、模块组织

由于实施 CMMI 的影响、团队年轻、人员流动等各种原因，许多企业都慢慢转向用职能性组织（如开发部，测试部，架构设计部，需求分析部，或者，如前端开发组，应用服务器组等等），实施改良 Scrum 框架，可以暂不改变现有的职能性管理架构，但必须要求 Scrum 团队的成员是跨职能、跨模块的，而且是在一起办公的，这个要求不可妥协。

2. 客户的参与信任关系的建立

在国内，有时客户不太愿意参与到 Scrum 过程中，参与了有时还不太适应他们手中排优先级的权利，这个可以慢慢培养，但是，必须要求客户和开发团队一起办公，共同参与 Scrum 过程，这样才能逐步建立起互信的关系。这在软件开发当中非常重要，因为，所有估算方式都只是一种拍脑袋的方式而已，只有让和客户建立起较强的互信关系，才能共同面对不断变化的开发交付过程，而没有比一起办公更透明的方式了。

3. 变革之心与QA的正确作用

在国内，交付压力都非常大，要求团队既能交付又要不断思考可以如何优化、变革是一个非常高的要求。我认为，这里应该正确发挥 QA 人员的作用，QA 需要放弃那种只是简单比对流程要求，不符合就开 NC（Non-Compliance）的粗暴做法，而真正做到参与到 Scrum 流程当中，冷静旁观，不断挑战现状、发现问题、和团队一起探索解决方案。因此，在我心目中，好的 QA 其实是 Scrum Master 的理想人选，有了变革的驱动者，每个迭代的回归会议才可能真正落到实处。

4. 增量交付价值

在国内，看到许多号称做 Scrum 的团队每个 Sprint 都在交付功能点，但是这些功能点并不能真正运行，这其实是伪 Scrum，很可能还不如不迭代。因此，做好 Scrum，就必须坚持不断交付客户可见的业务价值。也就是说，交付的代码必须是可执行，可以给客户演示的。对于复杂系统而言，这对划分 Backlog Item 提出了很高的要求，但是，是可以解决的，本文就不在这里展开了，未来再写文章详细解释。

5. 测试的全程参与

以前看到另一种伪 Scrum，号称开发在前，测试之后一个 Sprint。这种做法其实完全破坏了 Scrum 团队，开发测试无法形成合力。因此，必须坚持 A-TDD 和验收测试自动化，这又是一个很大的话题。

因此，大家可以看到，Scrum 虽然简单，但是真正做好 Scrum 需要在组织、人力、技术上有许多的储备才行，所谓功夫棋外，最好，愿大家掌握改良 Scrum 框架的精髓，灵活应用，在实际工作取得好的效果。

中国的规模化敏捷框架Adapt

Adapt 是 Agilean 十余年咨询成功的总结，是一套比 Scrum 更适合中国企业进行规模化敏捷的框架，点击阅读原文，详细了解 Adapt 框架。