我觉得我们沉迷于Daily Shipping已经不止三年五载了。
code-to-ship的时间长短，每次ship的时间间隔已经成了考核KPI的重要指标。
时间越短，你的团队就被认为是越有效率的，team间和group间还要比较哪个时间更短，同比，环比，你们team这个月时间比上个月时间长是怎么回事，怎么提高，等等。
纯粹是在浪费时间。
Daily Shipping是怎么回事呢，我跟老板说我们Daily Shipping已经做到了极极高的水平，今天写的代码今天就能上线，老板乐开了花。事情真的是这样吗？
今天写的代码上线是能上线，但不一定能起作用，不一定能被跑到啊。
很多时候我们都是在改code，但是很多code是需要作为一个功能必须等它们全写完以后同时一起启用的。
给正在飞驰不能停下来的汽车换轮胎，我们得先把备用轮胎全部造好，然后“咔哒”一下子电光火石之间就给又快又准的换了上去，而不是今天换1/8个轮胎，明天再换1/8个。
所以我们平时写的code尽管发布上线了，但是根本不会被启用。
相反我们为了能确保发布上去的code能不被意外的启用而造成bug，需要为此做许多额外的工作。
Daily Shipping完全是在降低生产效率，帮倒忙。
每日构建，平时经常说的每日构建，翻译过来是Daily Build，不是Daily Shipping，不是每日发布。
每日构建是为让你能每天跑UT, FT，让你能及早发现今天代码里的bug，及早修复。
但每日发布又有什么意义呢。
以前IBM有一个release manager的角色，专门负责为发布排序，什么时候发布你这个功能，什么时候发布他那个功能。我们为什么不能借鉴呢。
code写完，不要马上ship嘛，给段code freeze的时间，这段时间不能有大的change，不能添加新功能，大家一起来测试查bug，只能fix bug。
然后大家感觉差不多了，就发布，直接启动新功能。
On Demand Shipping.