在中国应如何改良Scrum框架

 

在中国应如何改良Scrum框架

 

@吴穹Adam (新浪微博)

 

在我的CSDN博客（http://blog.csdn.net/adwu73）上面，我发表了一个“为什么纯粹的Scrum在中国很难落地”系列，其中通过解读新版的Scrum Guide来分析如果在中国严格照搬Scrum会遇到哪些困难，有兴趣的读者可以去看看，而在本文中将在总结Scrum框架缺陷的基础上，讨论应如何改良Scrum框架，以保证实施成功。

 

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

 

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

 

角色定义 – 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也作为团队的一部分。

活动 - Time Box

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

 

Scrum框架当中的活动有几个：Release Planning Meeting, the Sprint, the Sprint Planning Meeting, the Sprint Review, the Sprint Retrospective, and the Daily Scrum.”

 

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

 

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

 

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

 

交付物 - Artifacts

Scrum框架中的交付物有四个：Product Backlog, the Release Burndown, the Sprint Backlog,和 the Sprint Burndown. Product Baclog比较简单，就是所有需要做的事情。这里特意没有明确Product Backlog Item是以什么方式定义的，以便可以集成这方面不同的实践（如用户故事，用例，FDD等）。

 

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

 

改良总结

综上所述，可以将改良之后的Scrum框架总结在一张图里面，如下：

 

 

实施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匡计的精髓，灵活应用，在实际工作取得好的效果！