在敏捷转型的过程中，除了敏捷宣言中的四个价值观和十二条原则以外，并没有太多比较权威的理论实践。

如图一，敏捷宣言中的四个价值观：

（图一）

四条敏捷核心价值观指出了敏捷的核心思想，但是并没有仔细说明具体的实践方法。所以这四个价值观看上去比较抽象，很难理解。下面我分享亲身经历腾讯敏捷转型所遇到的案例，足以说明敏捷宣言中工作的软件高于详尽的文档这条价值观（其余的价值观我会在另外文章里面解释）。

“工作的软件”高于“详尽的文档”。举个例子：“如果买一个崭新的洗衣机回家后，有多少人会看完使用说明书再使用洗衣机洗衣服呢？”对于这个问题，我想，不管男女老少，答案都是一致的：根本不会。因为洗衣机的使用大家都比较熟悉，而且家电行业发展很成熟，所以很多人即使不看说明书，一样懂得如何去操作洗衣机。

而“工作的软件”高于“详尽的文档”也就是这个意思。这里的软件就等同洗衣机，详尽的文档等同于使用说明书，软件的可用性是第一位的，详尽的文档是其次的。同样，在软件开发中，开发团队的重心应该是放在如何保证软件的可用性，而不是思考如何写一个完美的文档。例如：增加软件异常行为监控，增加crash的上报，不断分析用户的行为等。

2007年，腾讯公司在内部推行敏捷，团队不可能仅仅以四条敏捷价值观就开展工作，团队就面临着怎么实施具体可行的工程实践的问题。经过一段时间的对比和考察，最终大家选中了Scrum+XP的混合体（如图二），做出了以下这套方案。

（图二）

Scrum

√迭代规划会议

√产品Backlog

√每日站立晨会

√故事墙

√迭代回顾

×焚烧图

XP

√重构

√持续集成

√自动测试

√代码规范

×结对编程

×集体所有权

腾讯独有实践

√灰度放量

√showcase

如上图列表，带√的是最终采纳的，带×是最终放弃的实践。

团队实践敏捷的采用Scrum+XP方法中，Scrum整体采纳的比较多，个人认为主要原因是：第一，Scrum的一些措施更偏团队管理和沟通管理，对于早期的敏捷实践，这两个层面的实践容易实行，而且见效比较快。第二，XP实施的措施都是偏代码实践的，对技术要求比较高，实施成本也比较高。当然，结合腾讯的海量运营业务，成功实践敏捷肯定需要一些独门秘笈。

说说我对Scrum的理解，Sprint是组成Scrum的关键因素，翻译的意思是迭代，也就是研发周期为一周、二周、三周或者四周的时长，就必须有一个交付的版本，而且发布版本最长周期不允许超过四周。迭代引入一个Timebox的概念，可以类比集装箱的概念。集装箱这个发明出现在航运后，彻底改变了世界航运的版图，目前全球非散货运输的90%都是依赖集装箱的。集装箱的使用有严格的规定，从而容易组合运输，并且方便各种运输工具匹配。集装箱广泛的使用就是因为它能够极大的减少了运输期间的损耗，提升运输时的效率。类比咱们Sprint概念，也是通过引入固定的迭代周期可以减少软件研发过程中团队的内耗，提升版本交付的效率。凡事有例外，曾经有一个著名的故事：如果要运输一头大象，一个集装箱容纳不下怎么办？答案下一篇文章揭晓。

关于最终放弃的三个实践。

焚烧图——这个实践方法在当年也使用了一段时间，最终发现效果不好。因为在团队开发互联网软件产品的过程中，需求变更非常频繁，而焚烧图是通过每个迭代后还剩下需求个数来展现的，导致这个图展现的数字没有实际意义。因为多次迭代需求实在是太频繁，效果很不精确，所以失去意义。需要用到焚烧图的前提是要么需求没有太大的变化，或者用来做每天的bug焚烧图。

结对编程——当年有部分团队使用这种方法之后，实在是太耗损内耗，最终放弃。如果都是用来编写代码的话，员工受不了，劳动强度很大。一直在思考，而且团队成员互相监督，导致大家都没有喘气的时间。而如果是用来编写测试用例的话，老板又受不了，感觉浪费了一半的编程力。最终这个方法没有大规模推广起来。

集体所有权——这个所有权思想其实一直都在提倡，但是很难做到。毕竟团队中每个人都想有一个自己全权负责的业务，很多程序员对待自己的代码就像对待自己的女朋友一样，不喜欢其它人动手动脚的，自己怎么看都喜欢。然后对待别的程序员的代码都像对待一坨shit一样，看都不想看，喜欢按照自己的Style重新设计一遍。这是一个非常有效消减技术债的方式，但是却很难实现。

就这样，腾讯敏捷转型在不断的探索和实践中，找到了独特的敏捷方法。