产品
协作&沟通
看板
思维导图
在线文档
企业微信集成
规划&跟踪
敏捷需求规划
迭代计划&跟踪
缺陷跟踪管理
测试计划&用例
任务&工时管理
构建&交付
代码集成
持续集成&交付
应用&扩展
T魔方
第三方集成
解决方案
轻量协作
敏捷研发
DevOps持续交付
客户案例
支持
在线帮助
上手视频
帮助文档
使用手册
新鲜Show
服务支持
客户服务
小微扶持
合作伙伴
95716
中文
中文
English
Beta
登录
注册
行业案例
black;微信团队;微信研发的蜕变
扫一扫分享此案例
扫一扫分享此案例
扫一扫分享此案例
每月一个迭代，每迭代一次发布，稳定的开发节奏是灵活创新的微信团队现在的研发状态。没有延期，没有争抢资源，团队充分沟通，这在一个100多人的大团队中实属不易。 然而在半年以前，微信的版本发布节奏并非如此。 ## !!#2f58b8 微信版本节奏历经的三个阶段!! ### __第一阶段：初创期，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中来，团队合作实现可视化。迭代周期稳定在一个月。固定节奏让团队目标更明确，凝聚力更强。 ## !!#2f58b8 节奏，定好团队TimeBox!! 节奏是一个团队研发的心跳。当团队从10人扩大到50人时，团队会面临需求管理混乱、变更频繁、交付延期等各种问题。 __微信团队最终选择了一个月作为稳定的迭代周期。这是一个TimeBox，团队称之为“搭车制”。__ 每个迭代提前确定迭代的目标，到期交付，延期的需求将不会等待不予发布，统一延后到下个迭代进行发布。 有的稳定的节奏，有每个迭代的共同目标，团队所有角色成员都会为了这一目标而奋斗，不会在长期的开发中迷茫，不会在延期中迷失，团队更高效，产品反应更迅速。 ## !!#2f58b8 需求统一管理，进展可追溯!! 微信的需求来源很多，除了本身APP的需求，还有各合作部门（如微信支付、开放平台、游戏等）的集成需求；有老板需求，也有用户反馈需求。面对需求来源复杂，变化频繁的特点，Excel和邮件的管理方式已经不能满足团队透明进展、追根溯源的要求。于是团队在TAPD上建立了需求池（Backlog），统一记录和跟踪需求（User Story）。  有了需求池，该做什么，什么时候做，是由团队共同决定。 __在每个迭代的最后一周，项目经理召集产品经理、开发人员、测试人员，共同决定下个迭代的需求范围（IPM会议），他们根据需求的用户价值分析需求，进行评估。__ 这样做的好处是，团队的所有角色能够充分了解迭代的目标，了解用户价值，同时规避风险。测试人员可以更早地开始进行测试场景设置与测试用例准备。 ## !!#2f58b8 Feature Team并行开发!! 微信Android的开发团队目前有30+人，开发团队拆分成三个Feature Team：基础开发组、业务开发组、基础优化组（创新小组）。在确定大迭代范围后，每个小组分别规划各自的迭代（时间小于1个月），到了迭代最后一周再合入联调。 __Feature Team并行开发，既保证了大的迭代目标和节奏，也保证了各小组运作的独立灵活创新，资源分配与迭代跟进更加便利。__   ## !!#2f58b8 拥抱变化，高效沟通!! 这个世界上，唯一不变的就是变化。由于内外环境的因素，一个迭代的范围可能会面临多次调整，老板临时加入一个高优先级需求，必须加入迭代；一个需求开发延期了，赶不上迭代deadline，不能参加合入等，诸如此类。 __微信团队保证每周两次的沟通，用来了解迭代进度、调整迭代范围，并及早透明风险。__ 沟通会的参与人是项目经理、产品人员、开发leader、测试人员。 虽然有沟通，但迭代也不能随时变更，特别是在迭代的后期。为了保证测试发布质量，微信团队规定，从迭代的第三周开始，不允许再进行迭代内需求范围的变更。 __拥抱变化是研发团队在互联网时代必须具备的能力。__  ## !!#2f58b8 灰度发布，用户参与!! 灰度发布是快速验证版本的最好方式，在每个迭代的最后一周，微信为会小部分用户开放α版本进行灰度验证。灰度阶段用户的crash信息会同步为TAPD的缺陷（使用TAPD的接口实现），便于开发测试跟进。产品经理也会在灰度期间充分收集用户的反馈，追求极致体验。 ## !!#2f58b8 总结，为了再出发!! 在一个版本结束后，团队成员会统计分析各类数据，帮助团队了解版本质量，回顾迭代中的问题，以便在新迭代中进行改进。再出发时，团队会越来越自适应，越来越敏捷。  
