Cruise一周发布一次——精益软件开发原则应用之快速交付

自从去年开始，Cruise团队就坚持一周至少更新自己使用的Cruise服务器一次，更新其它团队使用的Cruise服务器一次。四个月前，我们又建了一个Personal build CI server，而这个server的部署频率更高，只要每次提交到团队持续集成服务器上后单元测试通过，Cruise就会将其自动部署到这个Server上。效果非常不错，因为这个持续集成服务器是每个开发人员做pre-commit用的，如果它工作不正常的话，开发人员第一时间就会知道（因为他们的pre-commit测试可能通不过，嘿嘿）,也算是build quality in的一个实践吧。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

 

在整个软件生命周期中，有一个非常重要的部分，那就是系统上线后的运维期。这个软件运维期的长短最终证明软件是否真的成功。

 

然而，事实是：很多软件在经过半年的开发和半年的调试试运行后才上线，可没多久就被列入了升级改造项目之列。这又是什么原因呢。

 

让我们先想一想客户为什么要开发软件？用户一定是要完成他的一个任务，而这个任务需要这个软件的帮助，才能完成的更好。换一句话说，如果没有这个软件，用户的任务也能完成，而且与有软件帮助的效果相同，那用户为什么要付钱来开发这个软件呢？

 

所以，软件一定是向用户交付业务价值的商品。假如这个任务在软件还没有上线时就被取消了的话，那么这个软件的价值也就没有了。

 

而上面提到的升级改造恰恰就是这种情况。即正当承包方花费很长时间来开发软件时，发包商的业务目标如果发生了变化。此时会发生什么呢？发包商一定会通知承包商，“我的业务要生变化了，你看我们的软件是否能做成这个样子的呢？”“我们的软件架构已经搭好啦，就差细节啦。如果现在改变的话，我们需要修改软件架构，几乎可以说是从头开始。”

 

结果可想而知，这个软件要延期交付（三个月）啦。假如两个月后用户的需求再变化，那接下来会发生什么呢？

 

这里反映出来的问题就是：我们还没有交付的软件或框架就是生产仓库中的库存。如果市场的需求发生了变化，不再需要这样的产品时，就成了积压产品，也就是“浪费”啦！我们常做的事情就是“向用户倾销这些积压产品，条件是让用户再多给点儿钱，顺代着把他的新需要做完，再一并交付”。

 

 

假如我们能够把用户的业务目标做为目标，把软件看做是完成业务目标的工具，就可以把这个工具的功能按用户的业务目标进行分解。通过这种业务目标的分解，就可以发现分解后子目标的业务优先级。这样在与用户的协商中，就可以有效地说服客户将项目划分成多个release来进行，而双方都会降低风险。

 

这种多个release的快速交付即可以让用户及早使用软件工具来完成他的业务目标，也让开发商进一步了解用户的真正需求，从而验证自己的软件，减少今后的发布风险。

 

设想一下，如果能够做到每周一次发布的话，发布就不再那么可怕了。

 

一周一次发布并非不可能做到，问题在于你是否认真地想过这个问题没有？

 

如果能够每周一次发布的话，上线试运行就没什么可担心的了。