在中国应如何改良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, theSprint 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框架

原文转自：http://www.ltesting.net