把大象放进冰箱——技术型复杂项目的特性裂解

在刚刚结束的 QCon 杭州 2011 大会上，来自腾讯的高级项目经理黄志斌，进行了名为“把大象放进冰箱——技术型复杂项目的特性裂解”的演讲。特性裂解是一个能提升快速交付能力的敏捷实践。在 QCon 演讲上，黄志斌主要讲述了对技术型复杂项目，如何通过对业务、技术和组织的调整，实现快速交付的目的。

演讲结束后，InfoQ 中文站对黄志斌进行了采访，以下是主要的采访内容：

InfoQ：实行业务层面的裂解，以达到“业务划分清晰”，具体有哪些要求？需要哪些人员参与到这个过程中，各自的职责是什么？

黄志斌：特性裂解的要求：要有价值点、要可以独立交付，要足够的小（能放进迭代窗口），技术上的可行性，可测性等（详细参考 INVEST 原则）。产品人员、开发人员、测试运维人员都需要参与：产品人员考察特性裂解后特性的价值点，以及是否是可独立交付的；技术人员考察裂解的可行性；测试运维人员考察裂解的结果是否具备可测性、可运维性。

InfoQ：运用虚拟特性团队后，开发团队会变多，相应的团队间的沟通需求会增多、需求变更的传递也可能受到影响。您是如何处理多个组之间的关系、如何解决沟通问题的，有哪些经验能介绍给广大 InfoQ 的读者？

黄志斌：是这么看待这个问题的，我所在的团队，当时出现的问题是跨组之间沟通得太少导致的，虚拟特性团队这个实践正好是对沟通、协作的补充。为什么这么说呢？因为我们之前的管理模式是单一的，以组件为界线来区分行政组。而引入虚拟特性团队之后，管理的模式是矩阵式的，一横一纵，横向为实体组，面向系统；纵向为虚拟组，面向交付。各个虚拟组之间的特性是相互独立的，而且有邮件组、IM 群来保证信息的同步。因此，引入了虚拟特性团队之后，其实是对原先模式在沟通、协作上的补充，并没有加重沟通的负担。当然啦，PM 的沟通压力是增多了，因为 PM 需要面向实体组，也要面向虚拟组。

InfoQ：采用“虚拟特性团队”这个敏捷实践后，各个虚拟小组的分工任务量不同，如何控制各小组工作的饱和度和整体工作的进度，另外各小组人员的投入和退出如何控制？

黄志斌：的确会有每个虚拟小组的工作量不同的问题，因为每个虚拟小组是面向跨组特性的，而特性本身有大有小。但是因为虚拟小组人员是复用的，所以工作量不同的问题最终体现在每个实体组（组件组）的工作量的不同。我们怎么解决这个问题的呢？我们解决这个问题的方法是特性分级，特性分跨组特性、组内特性。每个迭代会为每个跨组特性组建虚拟小组，优先安排跨组特性的工作，实体组的小组 PM 再根据自身团队的工作量安排组内特性的工作。虚拟特性团队的生命周期是以迭代为单位的，特性交付给用户了，虚拟特性团队的使命就结束了。

InfoQ：从组织架构上说，谁来承担整个产品 owner 的角色？其中产品人员与团队的关系是怎样的？

黄志斌：我们在北京有一个专门的产品团队来负责项目产品方面的事务，这个团队的负责人就是整个产品 Owner。我们每个跨组特性均有指定的产品负责人、技术负责人。

需求阶段是产品负责人为主，技术负责人为辅，目的是明确需求内容和技术方案；开发阶段是技术负责人为主，产品负责人为辅，目的是把特性生产出来，交付给最终用户。

就如我 QCon 现场分享的时候提到，我们的产品跟开发团队是跨地域的，也是这个项目的难点之一，这种产品负责人、技术负责人的配合方式，刚好可以弥补一下产品人员在开发阶段不在开发现场的问题，算是一种补充方式吧。

InfoQ：据您的经验，要运用“业务划分清晰、纵向架构支持、虚拟特性团队”这些招式，项目组可能会遇到哪些问题？通过什么方式来解决这些问题？

黄志斌：我讲一下虚拟特性团队这个敏捷实践的产生过程吧。一路过来不容易啊，解决了几个关键的问题才有今天大家看到的这个实践。

最开始的时候，我们发现各个组（这里是指实体组）的开发同学特别忙，基本上跨组的需求都排不上开发，于是我们提出特性分级和跨组特性优先排期（详见刚才第 3 个问题）等方法来保证跨组特性的交付。这个问题解决之后，我们很快发现，跨组特性到了联调阶段，出现问题就没有人推进了，为了解决联调的问题，我们提出特性 Owner 的概念。然而，特性 Owner 的概念提出后，我们很快又碰到了问题，特性 Owner 是个苦力活，各个组都不会主动来承担这个职责，特性 Owner 如何来选定呢？为了解决这个问题，我们又提出，跨组特性开发中，工作量最大的模块 Owner 来做特性 Owner，因为这个特性的交付最能反映该模块的工作成果。后来，经过了若干个迭代的试跑之后，团队慢慢把这种约定固化下来，并且配套的建立邮件组、IM 群等等。最后才有我们看到的现在的“虚拟特性团队”的敏捷实践。

InfoQ：如果在读者想借鉴上述这些招式，也期望实现对技术复杂项目的特性裂解，以达到快速交付的目的，您建议的步骤是什么？

黄志斌：通过我刚才讲述的产生过程，大家不难看到整个过程不是一步到位，而是持续改进的结果，这个很符合敏捷的价值观。每往前一步，都解决了团队遇到的问题，同时也让团队明白了为何需要这么做。所以，如果一开始就拿出这个实践来，在团队推广，我相信团队会有抵触，实践的落地不会顺利的。所以建议大家可以参考我讲到的历程，再结合团队目前的问题，一步步推进，找到一个适合于自己团队的解决方案。

InfoQ：腾讯经常会有一些新的名词出现，如“大象模型”和“虚拟特性团队”。你们是通过什么样的过程，将项目中的问题总结成了具体的招式，有哪些可供读者学习的方法？

黄志斌：回答这个问题就得从腾讯敏捷项目管理的历程说起，早期我们是以敏捷教练的方式在运作，在公司各个业务线选取了若干具有代表性的项目尝试敏捷。经过四年的苦心研修，可以说已经掌握敏捷方法的“形”，但是“神”还掌握得不够，于是开始新一轮的学习。为了让内部项目对敏捷的理解更进一步，达到融会贯通的程度，我们开始以派驻项目经理的方式运作，一般参与的项目都是公司内部门级重点项目。再经过两年进一步的研习，敏捷运用已经有些得心应手了，为了得到进一步发展，于是开始了第三个阶段，这个阶段目前尚在进行中，目标是形成自己的敏捷流派，并将敏捷方法发扬光大。这个阶段一般参与的项目都是公司级的重点项目。

在整个历程中，你可以看到，我们的项目经理是有一个良好的环境去公司内各个项目去轮岗锻炼的，同时，每个合作项目结束后，我们非常强调沉淀总结，项目经理会有一到两个月的时间来把刚结束的合作项目的经验，利用我们内部的知识管理平台 KM 平台总结沉淀下来，这些宝贵的经验最终通过我们内部的腾讯大讲堂、敏捷俱乐部、TAM（Tencent Agile Master）训练营或者一些外部的技术大会例如本次杭州 QCon 等，把我们对敏捷的思考分享出来。

关于腾讯敏捷项目管理的探索历程，可以通过我们之前发表的文章《企鹅快跑——腾讯敏捷历程揭秘》了解更多。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。