腾讯TAPD合作微信：研发的蜕变

518次阅读

(1)客户介绍

每月一个迭代，每迭代一次发布，稳定的开发节奏是灵活创新的微信团队现在的研发状态。没有延期，没有争抢资源，团队充分沟通，这在一个100多人的大团队中实属不易。

然而在半年以前，微信的版本发布节奏并非如此。

(2)项目背景

第一阶段：初创期，2010年到2012年初

这是微信的初创阶段，当时iOS和Android团队的开发人员分别只有10人左右，主要通过Excel和邮件往来跟进版本需求。每个版本发布的时间极不稳定，有时2周，有时一个月，有时两个月，发布时间随着开发进度不断延期，常常出现为了等某个功能，让其他所有准备好的功能等待1-2周才发布的情况。由于团队规模少，不存在跨团队合作，团队沟通也进行地有条不紊，先后发布了语音通话、查看附近的人、摇一摇、漂流瓶等核心功能，依靠快速创新迅速占领了市场。

第二阶段：磨合期，2012年初到2014年

2012年3月，微信用户突破1亿大关，微信团队也日益壮大，和外团队或外部门合作日益增多。简单地依靠Excel和邮件管理已经不能满足研发需求。微信开始使用TAPD平台。最早使用TAPD的是测试团队，他们使用TAPD的“缺陷”模块来管理测试中的问题。缺陷管理帮助测试人员和开发人员建立了很好的关联，流程灵活，定制化强，开发同学再也不会遗漏一个bug了。慢慢的，项目经理也将TAPD中的迭代、需求等模块用起来，但只为记录，简单使用。迭代的周期慢慢随着产品的稳定而稳定，到2014年底，基本稳定在1个半月一个迭代版本。

第三阶段：稳定期 2015年至今

随着团队人员的增加以及跨部门合作的增多，对TAPD的依赖逐步加强。微信团队各角色共同融入TAPD中来，团队合作实现可视化。迭代周期稳定在一个月。固定节奏让团队目标更明确，凝聚力更强。

(3)解决方案

节奏是一个团队研发的心跳。当团队从10人扩大到50人时，团队会面临需求管理混乱、变更频繁、交付延期等各种问题。 微信团队最终选择了一个月作为稳定的迭代周期。这是一个TimeBox，团队称之为“搭车制”。 每个迭代提前确定迭代的目标，到期交付，延期的需求将不会等待不予发布，统一延后到下个迭代进行发布。

有的稳定的节奏，有每个迭代的共同目标，团队所有角色成员都会为了这一目标而奋斗，不会在长期的开发中迷茫，不会在延期中迷失，团队更高效，产品反应更迅速。

需求统一管理，进展可追溯

微信的需求来源很多，除了本身APP的需求，还有各合作部门（如微信支付、开放平台、游戏等）的集成需求；有老板需求，也有用户反馈需求。面对需求来源复杂，变化频繁的特点，Excel和邮件的管理方式已经不能满足团队透明进展、追根溯源的要求。于是团队在TAPD上建立了需求池（Backlog），统一记录和跟踪需求（User Story）。

有了需求池，该做什么，什么时候做，是由团队共同决定。

在每个迭代的最后一周，项目经理召集产品经理、开发人员、测试人员，共同决定下个迭代的需求范围（IPM会议），他们根据需求的用户价值分析需求，进行评估。这样做的好处是，团队的所有角色能够充分了解迭代的目标，了解用户价值，同时规避风险。测试人员可以更早地开始进行测试场景设置与测试用例准备。

Feature Team并行开发

微信Android的开发团队目前有30+人，开发团队拆分成三个Feature Team：基础开发组、业务开发组、基础优化组（创新小组）。在确定大迭代范围后，每个小组分别规划各自的迭代（时间小于1个月），到了迭代最后一周再合入联调。 Feature Team并行开发，既保证了大的迭代目标和节奏，也保证了个小组运作的独立灵活创新，资源分配与迭代跟进更加便利。