从按版本发布走向按需求发布

在传统企业应用开发中，大家都是按版本进行发布

客户意见收集 》形成需求文档 》 需求评审 》 系统设计 》 开发 》 测试 》发布 》 客户验收。。。第二轮。。。第三轮；
在这种背景下，一般版本的发布时间是固定死的，比如签合同的时候就约定了几月几日进行项目的上线。而且这个时间基本都是很赶的，合同一签订下来，就意味着开始没完没了的加班，大家天天都是忙得天昏地暗的，谁还管发布几个中间版本，做几个里程碑。。。

而做互联网产品，天生就要求按需求发布

做产品开发的在版本发布方面的自主性会好一些，毕竟来自公司内部的压力比来自客户的压力还是要小很多的。然而对版本更新的频次要求就高很多，甚至是没有上限的，道理很简单，谁先最先面向市场推出了一个新功能，谁就是整个市场的No1，谁就在这个功能上深深的打上自己的烙印。从各大公司的情况看，MIUI是每周一次（黑色星期五）；同程每周四发布；亚马逊是每天几十次版本更新；（这里的对比数据并不是说明亚马逊比小米牛逼几个档次，这里的情况是由产品特点决定的）

一提起按需发布，各位开发团队的老大们首先要面对的至少有以下方面的挑战：

1. 测试压力会很大：这个应该是我们还是在按版本发布的主要原因，每一次需求的上线，意味着至少要经历开发自测、测试人员测试环境测试、业务人员开发环境验收三个阶段，而其中“测试人员测试环境测试”这个步骤需要考虑当前代码的影响范围，范围内的进行深入测试，范围外的也需要进行冒烟测试。这个时间成本是很大的。
2. 频繁部署耗时、易出错：开发自测环境的部署、测试环境的部署、生产环境的部署，每一次部署都需要时间，都可能导致生产故障。出的故障次数多了，大家潜意识就想离部署远一点；
3. 升级影响正常业务运行：线上的频繁启停可能会临时性的中断业务访问。

但是带来的好处更是意味深长：

1. 抢占市场先机：尽可能快速的响应市场需求，对抢占市场具有战略意义；快速的更新意味着可以第一时间得到用户的反馈，并进行优化后快速推出，形成良性循环；
2. 能充分发挥研发的价值：研发出来的东西是丢仓库一段时间，还是马上就卖出去，这个意义是大不一样的；这还涉及到丢仓库一段时间后，开发人员自己都忘记当初的需求和设计了，一旦出现问题，开发人员需要苦苦追忆过往，个中烦躁，谁经历谁知道。。。
3. 降低团队管理的复杂度：这里的降低是相对于按照版本发布来说的，每一次版本的开发计划安排，都意味着需要平衡不同开发人员的进度，因为不同开发人员的经验、解决难题的能力、学习的能力等都是不一样的，导致任务的安排很难面面俱到。任务安排后，同样要每天去了解大家的开发进度，确认是不是有人的计划延迟了，会不会导致A程序员等B程序员的情况发生等。在测试阶段，为了保证改bug的时间，又不能放新的需求进来，部分bug少的程序员就会处于waiting状态。当然以上三个阶段，在真实情况下，都会协调程序员之间相互协助，但这个协调本身就是导致管理复杂的原因之一。
4. 降低开发团队管理的技术门槛：国内的开发团队管理者（或者是项目经理）基本都是开发出身，而且是属于学而优则仕的那种。原因也很简单，非这样的人没法把控项目的进度，因为开发任务安排、工时评估、协调资源解决技术难题、面向需求提出技术解决方案等，都需要深厚的技术根底。但是按需求发布可以弱化这方面的要求，只要有一定开发经验、擅长沟通协调的人即可担任管理工作。技术方案方面的事情可以以“专家评审会”的形式来解决。
5. 打造面向创造价值的团队文化：作为开发人员，谁也不想整天被领导站在后面监督，毕竟大家做的是创造性的工作，天天被人监督的话，连起码的尊重都得不到，刚入职的小伙子还能操两年，经验丰富的老鸟们呢？面向需求的发布，可以把大家的关注点都集中到完成了多少需求的开发、以及该需求产生了多少价值上来，团队的领导者也和大家一样是一个需求的开发者，而不仅仅是一个监督者。至于团队的管理者，那更是为大家服务的，团队内部并没有对立点。共同的价值取向就会把大家紧紧团结在一条船上。

既然好处有这么多，而且都有着不可抗拒的诱惑力，那就只能尽力去克服困难了：

1. 测试压力大：

• 最终极的解决办法肯定是提高自动化测试覆盖的范围，减少人工测试的工作量。各大互联网公司的流水线开发为什么这么牛B，自动化测试应该说是首功。
• 但是小公司没法一下就打造这么完善的自动化测试体系出来，只能说前期先用人力顶上，这部分的人力成本投入相对廉价，但是可以提高开发的输出，还是比较合算的。另一方面，逐渐提高自动化测试的覆盖范围。

2. 频繁部署耗时、易出错：

• 规范代码管理，按需求开分支，专人合并，提高代码质量；
• 增量发布，只有增量发布，才能减少影响范围，减少线上业务验收的范围，当然就会减少出错的可能性；
• 搭建自动发布平台，增量发布会导致发布更复杂，自动发布平台能大大减少这部分工作。

3. 升级影响业务：

• 这个问题其实在引入集群、分布式session后已经影响很小的，只有在数据库表发生变更时必须停机发布以外，其他情况都可以做到用户无感知；
• 接口做版本，接口有变化需求时，升级版本，以免影响调用者。

总结：只要有了明确的方向，每天进步一点，目标并不是那么遥不可及！

各位开发团队的带头大哥们，你们也不想整天盯着小伙子们有没有在卖力干活，整天揪心版本能不能按时发布，整天干着这些毫无技术含量的事吧；你们也想和大家一起去创造实实在在价值（做开发），也想研究一下最新最前沿的技术（提升技能），也想消除和团队的对立点融为一个整体吧！那还等什么，按需求发布走起来！