【腾讯敏捷转型No.3】Scrum有什么好？

（图二）

Scrum

√迭代规划会议

√产品Backlog

√每日站立晨会

√故事墙

√迭代回顾

×焚烧图

XP

√重构

√持续集成

√自动测试

√代码规范

×结对编程

×集体所有权

腾讯独有实践

√灰度放量

√showcase

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

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

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

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

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

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

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

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