如何3倍速提高产品迭代效率，来自咪咕的敏捷转型实践|EGO精华分享
我先介绍一下咪咕阅读的情况，咪咕数媒的前身是浙江移动手机阅读基地。2009年正式起启动建设，2010年正式商用，图1展示了咪咕发展至今的一些重要阶段。
图1：咪咕发展的重要阶段
咪咕的主要产品包括：纸质出版、电子出版、海外版、政企阅读、有声出版、视频出版以及一些衍生出版，图2是咪咕数媒整个的产业生态。
图2：咪咕数媒产业生态
我们说回到咪咕阅读，咪咕阅读的开发团队有300人，平台特性超过2000个，部件总数超过100个，听起来特别繁琐复杂，接下来将与大家分享咪咕阅读如何从九周一个迭代缩减为三周一个迭代，以及向敏捷转型过程中的心路历程和踩过的坑。
2009年我们最开始建设的时候是属于运营商性质的，主要采用的模式还是外包，我们自己主要做一些开发管理。到2013年，我们每个版本的迭代周期在八到九周，也就是两个月到两个半月之间，那个阶段领导、市场人员、需求人员都感觉到很痛苦。一个功能，从提出需求到上线要半个月之久，上线之后还会有问题，用户真正能用要到半年以后，所以我们提出要有一些技术变化，要压缩迭代的周期以实现快速交付。
一、开发外包存在的问题
2009年刚刚开始合作的时候，用户、业务量都比较小，没那么痛。但到了2013年，我们发展快速，业务不断膨胀，系统也越来越复杂，整个平台的代码量已经有几百万行。但我们这个时候还主要靠外包，而且外包只有华为一家，存在很多问题。比如近期需求比较多，想让华为加人，根本加不上来。此外，华为考虑成本因素，不可能增加华为自有人员，要加可能加的是外包的厂商，但是二次外包的流动性非常大，这样它的代码质量只能依靠它自有的十几二十个人来掌控，所以他们没法加人。
为了提高开发质量，我们对华为有一个质量考核。华为为了保证质量，测试周期会设置很长，一个九周的版本测试可能要三轮到四轮，代码发布现场以后，我们还会有两周的验收，产品上线的周期会拉得很长。另外，华为的开发环境都是封闭的，我们的人参与不进去，也没有办法看到代码。甚至到后来，除了周期设置长以外，对工作量的估算也非常大。对华为来讲，它只计算一个人一天多少钱，根本不管真正的效率和质量，甚至会出现一个按钮需要50人的情况，我们非常被动。
当时我们自有人员又非常少，最开始整个技术部只有五、六个人，分管的还特别多，开发、测试、运维、规划，都在技术部，五、六个人根本没办法实现，这就导致钱花出去了，市场需求却得不到满足。到最后，领导也下定决心要把华为一家独大的模式给打破，同时也要增加自有技术，把里面的黑盒子给打开。
二、需求决策流程及开发流程过长
除了外包的问题之外，我们的开发流程也存在一些问题。第一个问题是整个需求决策流程非常长。各业务部门需求分散提交，没有统一入口及价值评估，所有需求需要公司领导层CCB会议决策，从收集到决策需一个月时间，部分低价值需求浪费分析人力。需求决策好后转到华为，又要开始华为的开发周期，那个链条也很长，他们有SA接需求，SE做需求的整体分析，分析完之后再分给各个团队、各个模块的MDE，MDE做分析设计，然后由SE、MDE给各个开发人员、测试人员做讲解，开发完了之后，再一轮一轮的测试，最终的结果就是战线拉的特别长。第二个问题是需求开发工具，没有从需求提出到上线的全流程跟踪管理工具，各个环节使用不同的工具，管理脱节，即增加人力投入，而且效率低、容易出错。质量数据也难以关联到需求，个人质量数据难以度量，为持续改进增加了难度。
三、架构老化
我们跟外部的一些互联网公司不太一样，我们最开始是依托于中国移动，各个省的移动又有各种各样特殊的需求，这样导致我们后端的业务逻辑非常复杂，再加上几年的积累，各种业务特性也不断的叠加，它的耦合程度非常高，这样也导致哪怕后续去加人，效率也提不上去，当时觉得这个架构老化的特别厉害。
图3 架构老化
2014年7月份左右，我们对整个系统平台做了一个重构，后面会做一个比较详细的介绍。敏捷转型、持续集成是我们向互联网公司转型的必经之路，但是华为对这块不关心，它关心的只是收益，这块东西他们没有那么强烈的意愿去完善。自动化测试也是一样，它只要测试人员的成本能收回并且还能有收益就行，它并没有要提升测试效率、减少人员的意愿。所以当时我们开发要三周，开发之后要进行三轮的集成测试，时间需要两周，验收测试要测三轮，测试时间也要两周，加起来就是八到九周。但即便这样，上线之后问题还会比较多，所以开发周期长。这样带来的后果就是：我们的需求实现周期非常长，一个业务从提出需求到上线真正能用，可能需要花费半年甚至更长的时间，根本没办法赶上市场的变化。
以上是我们遇到的痛处和问题，接下来要讲我们是怎么从九周缩短到三周的。2013年整个开发管理已经到了一个领导和技术部门都无法忍受的地步，于是开始跟一些互联网公司，像百度文学、腾讯QQ、阿里去交流，看看他们的开发管理是怎么做的。另外，近两年也有一些敏捷的峰会，我们也去参加，去看看人家是怎么做的。
2014年我们增加了自有的人，逐步加到开发团队里去，深入到每个环境、每个细节，去看整个开发过程当中存在的问题。到2015年上半年，平台重构服务化以后，我们就从华为手里逐步把一些模块接过来自己做，在自己做的团队里，我们就拿这些模块和团队来做试点，寻找适合我们自己特色的开发流程。整个过程当中我们主要做这五个方面的工作：流程梳理、持续集成、工具开发、度量建立和自动化测试。
参考敏捷的模型，结合我们自己整个开发管理，包括系统的特点、团队的特点，同时考虑自有人员编制的有限，对于外协的依托，我们自己制定了一个三周迭代的开发模型。
持续集成方面：最开始完全华为开发的时候，从华为环境部署到我们的环境里，要花费两到三天的时间，后面我们使用了一些开源软件搭建一套持续集成工具以后，原来要几个人花费几天的时间做的事情，几个小时就可以完成了，而且每天可以持续集成发布，到第二天来看运行的结果就可以了。
自动化测试方面：一些接口、Web的自动化我们都逐步在做，但我们现在资源有限，有一些模块会做得比较快一些，自动化程度能达到60%，甚至更高一点，但有的可能是10%左右。
工具开发方面：我们自己找人开发了一套开发需求管理平台，从提需求到最后上线，包括缺陷的管理，端到端的都串起来了。每个开发人员只要看他自己名下的任务就可以了，还有一些需求管理、项目管理的规范和管理办法都会制定出来。
度量体系方面：我们整个团队可能会横跨几个合作伙伴，团队人员和模块都比较多，在100人以上。怎么来衡量每个团队的负荷情况、工作质量情况、效率情况？为此，我们配置了两个质量管理员建立了一套质量度量体系。
正常而言，敏捷对文档输出的要求比传统开发模式会降低一些，但是我们因为有各种各样的审计，必须要求有一些设计文档、测试报告等的输出，所以我们相对于其他的互联网敏捷团队来讲，可能会要求重一些。我们敏捷框架采用的是Scrum框架，从整个管理上来讲，敏捷所采用的计划会、迭代任务分解、评审会、反思会这些都经常用在我们整个开发过程管理当中。
我们根据自己特点梳理了3周迭代模型（参考图4），主要目的就是把每一个环节关键点、时间结点、里程碑结点都定下来。迭代相关的各个角色要明白他的时间点，这样就能有效控制版本节点的时间跟节奏。
图4：三周迭代模型
从端到端流程来看，同一时间可能至少有两个版本的动作是并行启动的。对于需求分析人员来讲，可能这个版本的需求在开发，同一时间下一个版本的需求也已经在分析，因为一个版本上线的同时，下一个版本的需求开发范围、设计全部都要出来。
我们根据自己的特点开发了工具跟平台（参考图5），主要是我们的需求管理平台，把上下游从需求到开发到测试到上线整个流程串起来，把开发过程通过数据来展现，包括需求的提出、需求的分析、需求的实现、Bug缺陷等都通过这个来展现，这样可以对整个团队进行有效的统筹管理。
图5：开发适配的工具平台
我们还建立了配套的度量体系（参看图6）：
图6：建立配套的度量体系
我们自己做了一个自动化发布跟持续集成（参看图7），使用自动化发布持续集成之后，原来人工发布耗时要5人/天，现在只需要1人10分钟左右就可以完成，效率的提升非常高，部署效率至少提升了五倍。
图7：自动化发布跟持续集成
图8是我们整个平台重构的项目过程和成果：从九周到三周。
图8：平台重构时间计划
我们在做这个事情之前还面临一个问题，就是与华为合作的探讨，因为当时代码还在华为手里，我们没有拿到。为了能把开发从华为手里接过来，我们另外招了几个厂家协同我们把整个平台逐步的、一块一块的接过来。刚开始是把手机报模块先接过来，手机模块运转了三个月之后，再逐步的接我们咪咕阅读主平台模块，从后端服务引擎这块，再接上门户，再能力中心一块块的把它交接过来，到现在已经交接的差不多了。
通过一年多的时间，虽然我们现在已经从九周降到了三周，但是我们发现这个过程当中还是存在一些问题，因为我们链条还是比较长。后面的嘉宾会[hz1] 介绍我们整个平台的架构，整个团队开发下来至少有四层，四个团队之间的相互沟通和磨合，效率还是会存在问题。
从敏捷的角度来讲还是不够，我们整个团队现在可能有六、七十人，按照敏捷的思路，一个团队五到九个人最多了，因为人多了之后沟通效率势必会下降，所以我们在自动化、包括代码质量上会做进一步的改进。另外，敏捷跟团队人的能力关系非常大，我们要逐步的去筛选一支相对稳定、对系统模块比较熟悉的开发团队。同时我们看看能不能从三周再进到两周甚至一周。从质量和过程来讲，这个度量体系才刚开始建不久，还有很多数据不够准确，不够完善，后面也要在这个度量体系上进一步去优化和完善，以上就是我的分享内容，谢谢大家。
Q：现在我们的研发团队都是自建的吗？
蒋海滨：开发和测试加起来有40个人左右，我们自有的人分布在团队，主要承担一些关键角色，比如PL，包括设计分析、测试TC等，团队的骨干基本上用我们自己的人，具体的编码还是在用外协，我们自有人员编制还是不够。我们有一部分的模式还是参照原来与华为的开发模式，因为我们最开始去接华为工作时间比较短，就招了几个厂家大规模的进来，人员质量还不是特别好。我们当时考虑的就是设计、分析、团队管理采用我们自己的，这样整个团队的重心能够掌握在自己手里。我比较理想的状态是：希望团队不再分设计和开发，开发人本来就应该是需求分析和设计人员，这样效率最高，甚至测试和开发也不再分，自己开发完了，最多加一个端到端的解决方案，这可能是比较理想的状态。
Q：刚刚好像讲的大部分是服务端，客户端业务是什么团队在开发呢？
蒋海滨：客户端是另外一个部门，产品部做的开发，他们也是自有加一家外协东软。
Q：大概也是三周一个迭代？
蒋海滨：他们是四周，一个月一版。我们现在还有一个客户端跟平台之间的拉通的问题：我们在平台进入测试阶段时候，客户端版本还没有最终成型，所以既使给了一个Demo测试，也可能是比较粗的版本。所以在客户端真正测试的时候，又发现问题，但这时候，主平台已经进入下一个版本的开发了，所以对问题的响应上就存在问题了。
Q：服务端和客户端是分开来规划的吗？
蒋海滨：客户端有单独的版本规划，我们平台这边也是单独的，因为我们节奏不一样，没办法等他。而且好多工作要等到我平台这边具备了之后，他才去基于我的接口开发的。
A：那产品经理是分开的？
蒋海滨：我们有一个总的版本经理，每个需求都对应有一个产品经理，客户端安卓跟iOS各有一个版本经理。
Q：产品会先拆分好分给产品经理？
蒋海滨：对。
Q：你们那个灵犀语音助手的语音技术是自己开发的吗？
蒋海滨：灵犀语音助手的语音技术是用了科大讯飞的，因为本身跟科大合作。