Question

每个公司都有自己的开发迭代周期，有4周的，有2周的，也有1周的。也不好判断究竟哪个开发节奏更好，只能说各家有各家的打法，各家有各家的烦心事。下面就让我来逐一介绍一下这几种开发流程。

10.3.1　四周时间的开发流程

1.巧妙安排迭代间隙

敏捷开发的周期，包括从需求准备、排期、开发、测试到上线、发版，可长可短。

在一个月迭代周期开始之前，我先介绍一下，我们都干些什么？

这期间，通常会有1~2天时间，除了让团队休整，该约会的约会，该学车的学车，还要做以下这些事情：

1）总结上次迭代的若干问题。也就是所谓的post mortem，这个总结会议很重要，需要把上次迭代做得好的和不好的，都列举出来。好的，我们下次迭代要继续遵守；不好的，要在下次迭代想办法解决，落实到具体的负责人。

2）修复上次迭代来不及处理的bug。每次迭代都会有一些bug遗留下来，之所以不修复，是因为改动这个bug可能会导致很大的隐患，或者测试团队没有时间去验证，或者需求不清楚，需要产品经理将其细化，在下期迭代作为一个Task来完成。

3）做一些代码上的重构工作。包氏法则之一：永远以产品需求为最高优先级的Task，在想方设法完成了需求之后，再利用剩余的时间来做代码优化、项目重构的事情。重构工作一般放在迭代前期进行，这样测试人员才可以将其也作为一个测试任务去评估时间。此外，在项目前期完成重构，可以通过接下来长达4周的迭代时间来发现重构所带来的各种问题并及时修复。

4）讨论新需求，划分到具体的开发人员和测试人员，评估出工时和工期。这时要求产品经理的需求文档已经到位了。

项目经理召开一次全部人员参加的需求确认会，由产品经理讲解每个需求。为此，要确保每个模块都有1~2名开发负责人，从而保证该模块有需求时至少有1个人立刻能上，当该模块需求过多时，迅速把第2个人也补上来。同时，也降低了项目对人的依赖，以确保任何一个人都有备胎。这是团队建设必须做、并持之以恒去做的一件事。

把需求划分到人，听产品经理讲完需求之后，就该评估工时了。当收集到所有开发人员报上来的工时后，你会发现：

·有人工时过多，超过了2周，有人则不足2周，这时项目管理者就要局部调整Task，以确保每个人员的工时都控制在2周以内。对此，我称之为“拆东墙补西墙”。开发工作控制在2周是绝对有必要的。2周之后不再做额外的需求（除非很紧急），不再做任何重构（除非问题很严重），以确保测试阶段项目的稳定性。

·一个简单的Task，却需要3天才能做完。有的程序员喜欢给自己多留一些buffer，以确保各种天灾人祸所导致的Task延期，但作为项目管理者，则更希望每个Task的buffer控制在半天以内，这样才能制定出比较准的迭代计划。有的程序员则属于偷奸耍滑的类型，他们会把工时估的很宽裕，从而每天有充足的时间去逛淘宝、QQ聊天。这时，项目管理者所要做的是，拎起笔记本，到每一个开发人员座位上，对有水分的Task，一起分析需求，重新评估工时，把“水分”挤出来。

如果绞尽脑汁排出来的开发工时还是超过2周，项目经理这时就要联系产品经理，砍掉一些不必要的需求，从而踩住2周code complete那个时间点，以确保本次迭代不会有太大风险。

我们漏了一个环节，那就是测试团队的测试工时。有时候，即使是开发能在这2周把所有需求都做完，测试资源不足，也会需要产品经理适度砍掉一些需求，以确保测试时间够用，保证那些重要的功能点。或者把那些只涉及UI改动的需求转给产品经理来验收。

工时安排妥当之后，接下来需要每个开发人员为自己分到的Task制定工期，即先做哪个、后做哪个。

要想把工期排好，首先要解决App对原型图、MobileAPI的依赖性：

·有些需求需要美工给出原型图和切图，什么时候给出，对工期有很大影响。

·有些需求需要后端MobileAPI提供数据，什么时候MobileAPI能完工，或者退而求其次，事先制定好MobileAPI接口，给出假数据也能接受。

·如果MobileAPI的进度比App的进度能提前一个迭代周期，那么就能避免App和MobileAPI并行开发所带来的风险。

以上都是项目管理者所要去协调沟通的。

5）在迭代正式开始的前一天，开一个冲刺会，标志着本次迭代正式开始。

如果前戏都做得很充分了，这个冲刺会其实就是走个形式，开发人员、测试人员、产品经理聚在一起，然后宣布下期迭代从明天起正式开始，上线时间点是哪一天。

会议控制在10分钟。也许有人会问，10分钟够吗？通常会有团队在冲刺会上把项目分配、评估、工时和工期也一起讨论，所以开一天才能结束。其实大可不必，只要在会前把这些工作做足了，和每个开发人员都充分够通过，有了结论，那么在动员大会上，只要宣布这些结论就可以了，不需要再讨论。

从以上5点看出，迭代开始前的这几天，是项目经理最忙碌的日子，他们要使尽浑身解数，在迭代开始前把这些准备工作都做好。稍有延迟，项目进度就会受到影响，10多个开发和测试人员就会等你，项目经理耽误1个小时，整个团队耽误就是10多个小时。

项目经理切记，永远不要让自己成为瓶颈。

接下来的4周就是真刀真枪的迭代时间了。

2.控制4周迭代的节奏

在这4周的迭代时间里，要干的事情很多，把这些事情标注在时间轴上，如图10-1所示。

图10-1　4周迭代流程

1）开始两周，是开发时间。

在这两周时间内，初期会有一个测试用例评审会，根据我的经验，就是需求二次确认会。一般而言，第一次需求确认会，开发和测试只是了解需求，当时提不出太多的意见。只有经过几天的沉淀，才会发现，有些需求并不合理，所以我们每次开测试用例评审会，就会发现这也有问题，那也有问题，于是这个会议就变成了需求二次确认会。我们在评审测试用例的时候，也把需求最终确认了下来。

在这2周的开发时间里，会遇到各种狗血的事情：

·上一个版本发现了重大bug，要紧急修复并发版。

这个是比较费开发和测试团队时间和精力的一件事。我每次的处理方式是调整1个Task延期到下期迭代完成，以此来解决资源的不足。

·陆陆续续发现一些线上的bug，虽然不是很严重，但要放到本次迭代内修复。

作为项目经理，我一般将此当作正常迭代中的bug来修复，不会影响迭代的工期，但是遇到架构上的问题导致的bug，可能就要排到下期迭代来完成了。

·产品经理经常插入一些紧急的需求。

如果开发团队和测试团队都能消化掉这类紧急需求，那么就排到2周开发的工时中；如果测试团队时间不够，就开新分支来完成，下期迭代合并进来再进行测试；如果开发团队时间不够，那么就把还没开始的一个低优先级Task放到下期迭代，以优先完成这个新需求。

·一些需求，临时决定本次迭代不做。

这样开发人员就有额外时间了，我一般安排他们去做之前一直拖欠的Task，或者去做一些重构，但是考虑到测试资源的问题，所以每次都是做在新分支上，本次迭代并不上线，放到下次迭代去测试。

在这两周里，随着新需求一个个的提交测试，测试工作也慢慢展开了，并开始报了一些bug。

第二周周五，所有功能都已经开发完成了，也就是所谓的Code Complete。

2）第三周，测试工作进入全面测试阶段，每天的测试包都比前一天更加稳定。开发人员的日常工作是修bug。

第三周要把高优先级的bug全都修复，不然难以确保下周bug日清。

此外，本周可以跑Monkey了，每天要有专人对Crash日志进行分析、归类，然后指派给相应的开发人员去修复。

另一项开发人员需要做的是，修复线上的Crash。需要有专人对线上每天的Crash进行分析、归类，然后分配给相应的开发人员去修复。我的经验是，每天的Crash种类，其实差不多，昨天的某个Crash，接下来一周都会出现，所以我每次只会分析连续三天的线上Crash，基本能囊括线上的90%的Crash。

为了确保开发质量，开发人员每天还会集中坐在一起进行冒烟测试。即每天集中测试一个模块，把发现的问题及时修复。

第三周的最后一天，应该确保所有的高优先级bug都修复了，可以进行正常的下单支付流程。这时我们要打一个正式包，用于：

·发给全国各地的分公司同事，请他们帮忙进行测试。我主要想知道全国各地是否都可以登录，包括WiFi、2G、3G和4G网络环境。

·发布小流量包。有关小流量包的介绍参见11.3节的内容。

3）第四周，这周主要是测试人员进行集中测试、探索性测试和全功能回归测试。

前三天是集中测试，他们会集中所有测试人力，对所有新功能一起测试一遍。开发人员则要保证bug日清。与此同时，测试团队这几天需要每天组织探索性测试，及早发现bug及早修复，要逐个模块推进探索性测试工作。

第三天晚上是Code Freeze。我们认为这个版本是比较稳定的，除非发现很严重的bug，否则，不再改动代码。

周一到周三这三天中，产品经理要进行验收工作，把问题及时反馈给开发人员，及时修复。

周四周五是全功能回归测试，又名Regression Test。这是最后一轮测试，这期间发现的任何bug，我们（开发、测试和产品经理）都要评估，如果不是很严重，我们本期迭代就不修复了。可以按照先iOS后Android的顺序，每个App使用一天的时间进行全功能回归测试。

这周，我们还要密切观察小流量包发布后的线上Crash情况和安装新版本体验包的同事的反馈，对发现的严重问题进行评估和修复。

10.3.2　两周时间的开发流程

敏捷是什么？敏捷就是为了按时交付，不断调整策略，做到资源利用率最优化。至少我是这么认为的。

上一节我们介绍了4周一次迭代的敏捷开发流程。还能不能更快一些？可以，那就是接下来我要介绍的2周一次迭代的敏捷开发流程，如图10-2所示。

图10-2　2周迭代流程

时间少了，那就意味着每次迭代的功能也减少了，也不会有休整时间。每次迭代都是从周一开始，下周五晚上发版作为结束。

1）第一周的工作安排：

周一用于产品经理讲解需求、开发人员和测试人员分Task、评估工时、排工期。此外，周一开发人员会比较空，一般用来修复线上的Crash。

周二到第二周的周三，共计7天，所有需求都必须排在这7天完成。同时，要求MobileAPI在这天完成全部联调工作。

周四或周五，测试用例评审会。在这之前，测试团队编写测试用例。

2）第二周的工作安排：

开发工作持续到第二周周三下班前。周三晚上这个时间点，我们称之为Code Complete。这个点延期了，后面的工作都要顺延。

周三起，项目经理组织开发人员进行冒烟测试，周三是Android和iOS各测各的，周四是两个团队交叉测试。

周四一天，产品经理对功能进行验收，如果可能，这一天尽量提前，以便于产品经理不满意，开发人员有更多时间进行修改。

周四要求开发人员bug日清。同时测试人员要对周三开发人员提测的功能进行测试。

周五上午测试人员验证bug是否全都修复。

周五下午测试人员进行全功能回归测试工作。

对于周五发现的所有bug，我们只修那些严重程度高的bug，bug是否严重，由产品经理说了算。

周五晚上封版。我们称之为Code Freeze。iOS会提交AppStore审核，为保证iOS和Android同时发布，Android当天是不能发布的，因此只是在主干上新建一个分支，该分支用于Android发版。一般来说，AppStore审核通过iOS新版本要1周时间，在此一周内，Android发现紧急bug还有机会修复，但原则上不再修改代码。

按照这个节奏，我们能确保每隔两周就能提供一个新的App版本，如果有延期，就需要周末加班补齐。

10.3.3　一周时间的开发流程

随着无线团队的急速扩充，我们会把无线团队按照业务线拆分到各个部门，你会发现，无论是4周还是2周的迭代，都难以协调各个部门，让他们按时完成功能，以保证准时发版。

我们不妨每周五App发一次版本，这是雷打不动的节奏。但是各个部门可以自行安排自己的发版时间，比如有些大功能要做两周，那就两周之后再发布这个新功能，而对于那些零零散散的小功能或者bug修复，则放到每周的发版中，不至于让用户等很久。

这就好比在地铁站等地铁，每3分钟都会开过去一趟，永远不会等乘客。而乘客有赶上第一班的，也有赶上第二班的，这取决于他们的到达站台时间和着急程度。

App一个月发4次版是很恐怖的，这会让竞争对手永远跟不上你的节奏。但缺点是用户不胜其烦，每周都要提示更新。

10.3.4　即时更新策略

还有没有更短的迭代流程？比1周还要短？有，那就是随时开发测试完成，随时提交到线上，而不借助于发版。

那就要用到插件化编程和脚本编程技术了。插件化编程仅限于Android，这是一个庞大的主题，本书不会涉及这门技术。脚本编程就同时适用于Android和iOS了。目前业界普遍使用Lua，以手机游戏行业用得最多。他们等不了iOS漫长的审核期，因为手游可能随时新增或修改地图、装备和剧情，所以他们会在已经审核通过的App中用Lua脚本做这些事情。其实应用类App也可以这么干，我接下来就准备招几个Lua程序员到iOS团队从事这方面的工作。

如果能做到上述的插件化编程或脚本编程技术，那么就可以随时发布新功能了。这是一件梦里都会笑醒的事。由此而回顾我们的敏捷开发流程，就没有迭代周期这样的概念了，我们将实现真正的敏捷流程，把所有Task都贴到白板上，做完哪个就发布哪个到线上。