12月27日QClub深圳活动要点速报

2008年12月27日在深圳举办的活动是QClub第一次走进华南地区，50多位同行聚集在华为互联网业务部漂亮的新办公区里，与王速瑜和周代兵两位嘉宾一起分享腾讯公司在开发互联网产品过程中的经验和体会，以及华为软件公司的敏捷之路。

腾讯公司在开发互联网产品过程中的经验和体会

主讲是腾讯公司的R&D研发总监王速瑜。腾讯的互联网产品要求新求快，需求不确定的程度很高，必须快速适应变化。

用QQ漫画形式推介敏捷

在腾讯敏捷产品开发流程TAPD（Tencent Agile Product Development）中，结合了类似FDD的做法，由产品经理归纳的特性去驱动开发，过程上借鉴Scrum，具体实践借鉴XP。迭代计划会议强调所有人员都参与，包括UI、QA等等部门，共同探讨各种困难，评估工作量。每开发完一个需求，都要根据用户调研、会员测试等途径得到的数据做回顾。互联网应用用户基数大、产品分发容易，而且他们可以很容易地根据后台数据分析用户行为，以之判断新特性是否成功。利用以上特点，他们通过逐步增加新特性的用户量、多个版本交叉升级的“灰度发布”方式，做到早发布、常发布。

通过明星产品QQMail的实践，观察到团队成员的心情在逐步向好，同时用户量也有10倍以上的增长，这些效果坚定了他们继续推行的信心。

腾讯很重视工具建设，比如有内部门户帮助团队间的交流研讨，有类似Mingle的迭代计划工具等等。王速瑜还提到一个“团队股市”的有趣应用，可以反映出团队的敏捷能力上升情况，帮助衡量团队能力，也起到激励的作用。

实践中也遇到一些困难。比如站立会议对于二三十人的较大团队负担较大，时间长了之后变得形式化和呆板。为此他们采取了轮流主持等方式加强参与感和增加刺激，但结果还不能令人满意。有的团队改用虚拟方式增进效率，也更适合分布式团队。

结对编程的推行也不太成功。开始的时候效果很好，因为看到质量提高，团队成员也愿意去做，但逐渐由于项目压力大而放弃。

其他困难还有每年上千毕业生要融入团队，大型产品QQ客户端发布周期长达半年以上，诸多问题尚在探索之中。

华为软件公司的敏捷之路

第二位分享的是周代兵，华为软件公司软件工程部经理。华为的转变经历了很长的过程。首先是引入IPD（Integrated Product Development）改变了游击队做法，成功将企业从自行摸索的技术导向转变为市场导向。接着引入CMM(I)，大大提高产品质量。IPD+CMM形成的项目管理、质量保证体系确保了企业的正常运作。

然而,在华为的传统做法中，过于偏重对过程的控制，忽视了人与工具的因素。流程控制使得产品质量可控，进度有保证，管理层亦较容易了解进度。但软件开发不同于生产线上的重复劳动，是创造性的工作。严守流程能完成任务，但其成效是未知的。片面追求运作规范，结果是完美的报告的背后，可能是质量完全不相称的交付物。

华为还引入了RUP，尝试用迭代去解决瀑布方法交付周期长的问题，但发现RUP虽然全面、完善，但并不能切合需要。于是Scrum和XP进入了他们的视野。

复习了一遍Scrum和XP

在实施中，他们利用精益思维去发现需要改进的地方，有选择地采纳一些XP实践，并以Scrum去补足XP在管理上的弱点。举例来说，他们用结对去代码复审和沟通的问题；用TDD去“做刚好够用的事情”，避免在无用的产品功能上浪费资源（曾有产品高达50%的功能无用）；用看板和ScrumWorks等软件工具去维持项目进度的可视化；整合原先按照开发、测试等阶段划分的团队，消除“停工等活”的浪费。

在转变的过程中，他们并非全盘放弃传统做法，而是将IPD移到上层用在决定投资决策方面。然后用敏捷团队逐渐代替CMM团队。团队被赋予对自身采用何种方式的选择权，运作良好的项目可以继续下去。同时他们观察到以前所谓的“烂项目”会主动选择变化，正说明这些项目不适合瀑布方法。

他们也认识到改变需要很长的时间，从关注过程到对人的关注牵涉到文化的转变，而习惯根深蒂固，利益不同更是会产生以邻为壑的做法。为此他们用“一体化团队”去打破部门之间由于利益不同造成的 “部门墙”，将交付成功与所有人的利益关联起来；帮助成员做角色的转变，比如将过去充当警察角色的QA变成教练和Scrum Master的角色；重新设计办公室布局以促进交流。

周代兵将华为的敏捷之路形容为“一夜的引入，长时间的改变”，他们还在“Moving”之中。

Q&A

以下是部分Q&A（根据编辑笔记整理要点，非原话）：

• Q：开发与测试如何配合分工？
  王：测试不是某一部分人的责任，也不是到后期才做，从迭代计划就已经提出目标。需要平台工具才能保证。
• Q：FDD如何实现对程序员的质量约束，TDD放在什么位置？
  王：FDD、TDD使用到不同阶段。FDD的目的在于让成员关注产品目标，鼓励成员提出想法。没有做FDD的建模部分，更接近于产品Backlog。Web产品对建模的要求低，因为很容易得到用户反馈，第二天就可以发布新版本给一部分用户。TDD处理编码部分的问题。有了持续集成之后，才将所有实践贯穿起来。
• Q：结对的目的？
  王：把培训放到结对中，还有代码复审的作用。
• Q：是否轻文档、重代码？
  王：不是没有文档，关键文档仍然是必须的要求。但文档写到什么程度，团队成员达成一致意见即可。团队之间交换成员，把人员放到不同项目中去，也有助于发现哪些文档是沟通中不可缺少的。

• Q：推行敏捷是否“一把手工程”，如何使领导觉得敏捷是成功之路？
  周：绝对是，没有管理层的认可不可行。推动者有教育管理层的任务，可以借助外力推广理念，可以用标杆项目增加说服力。不打旗号地去传播经验。
• Q：绩效考核如何适应敏捷方法？
  周：华为过去非常重视可度量化，现在也仍然如此。曾经根据很细致的数据去做度量，但发现过程性的东西对产出的结果没有太大关系。因此现在改为关注结果，只用很少、很粗的数据去量化。由于传统的惯性还需要做很多说服工作才能扭转。
• Q：测试人员的绩效如何衡量？
  周：过去用测试发现的问题量去衡量；现在用客户反馈的问题量去衡量绩效。
• Q：计划时如何确定功能点数量？
  周：先确定迭代周期，一般为2~4周，根据在此期间能完成多少来确定。开始的时候不熟悉会少一些，后期可多一些。
• Q：生产力提高多少？
  周：差不多。但明显改变交付能力，客户满意度增加。不同团队的生产力数据离散度增加了，可能与团队能力参差有关，还有待研究。
• Q：实在多次迭代之后重构，还是每次都重构？
  周：重构有不同的维度。小范围的重构，个人编程的时候就会频繁进行。在增加许多功能之后可能发现架构上不适应，需要做大层面的重构。

分组讨论

谢谢大家

PPT和现场视频正在制作之中，还要晚一些才能呈现给各位热心读者。