在开发节奏上，前两周的时间用于开发，然后截取分支准备发布，接下来两周进行测试，同时进行另一个开发，每一个迭代都控制在两周之内。相对而言，服务端的发布比较好操作，可以做很多的回归测试和自动化测试，不太需要手工的测试来做发布，但是 Windows 和 Android 都会有一些测试版的发布，在内部很难模拟用户的使用场景和用户的环境，所以在发布之后的过程中一般会抽样1%、5%、10% 这样一个节奏来做验证，主要是看某些指标是否达标。

     这个流程刚开始执行的时候问题特别多。比如在这周开发完成以后，测试发现根本测试不了，有很多很多的 Bug，工程师只好利用第二个研发周期去修 Bug，然后又会影响第二周期的开发，这样问题越来越多，就会导致流程很难进行，然后进入恶性循环。为了解决这个问题，首先在操作层面上一开始先用一个月的迭代来让大家适应，同时要求每个分支必须是可用的（比如某人提交了代码跑不起来，或者没有经过测试，给其他同事带来了阻碍，就会被要求请全团队喝咖啡）。其次加强单元测试和回归测试，确保每个迭代的研发质量是可控的，后面的测试主要是回归和校验，减轻相互重叠的压力问题。一个月的迭代跑顺了之后，再跑到两周、一周的节奏，整体来看，差不多用了半年的时间，豌豆荚就完全跑顺了这个流程，想快可以快，想慢也可以慢。

    工欲善其事必先利其器，为了提升产品研发效率，豌豆荚内部开发了一款项目管理工具作为内部的沟通工具，它主要用来做跨团队沟通，全公司所有员工都会使用。重要的路径必须在这里登记，登记了以后，一个项目需要多少设计师、需要多少营销、每个阶段是什么样以及工程师的发布状态都可以在这里看得到。

    对于重要的发布，豌豆荚有三个最基本的要求：

    第一要获得 Product／Design Review的批准。一个功能开发以后，无论是界面还是整个美工UI，如果会影响到用户的操作，或者影响到商户的收入，比如我们的广告系统或者和合作伙伴的一些策略调整，这就需要做Design Review。Design Review 在豌豆荚里面的时间大概是每周的周一、周三和周六，每次持续 1-2 个小时，包括Product（Review）、Design（Review）或Business（Review）。Product Design指的就是 PD，主要的视觉设计师或产品设计师必须全员参加。

    第二要获得 EngineeringTech Review的批准。这更接近于传统上的技术设计，主要是看某个功能在工程设计上是怎么做的。做这个设计的团队和所有工程师必须全员参加，也会有一个人来主持，还需要几个指标的回顾。这个过程是帮助相关的工程师把设计考虑更全面，包括流量、游戏的带宽压力的需求等等。

    第三要获得 Marketing Review的批准。主要是看产品上需要如何引入营销和运营团队的配合，需不需要做一些传播，需不需要注意公关策略等等。同时对于更小的一些测试则不强制要求。这些回顾实际上是帮助整个团队、整个公司去理解当前最重要是什么，其实也是建立一个高标准的过程。