第四章 交付用户想要的软件

没有任何计划在遇敌后还能继续执行。

---------- Helmuth von Moltke(德国陆军元帅,1848—1916)

广告:个人专属 VPN,独立 IP,流量大,速度快,连接稳定,多机房切换,每月最低仅 5 美元

客户把需求交给你了,要你几年后交付这个系统。然后,你就基于这些需求构建客户需要的系统,最后按时交付。客户看到了软件,连声称赞做得好。从此你又多了一个忠实客户,接着你很开心地进入了下一个项目。你的项目通常都是这样运作的,是这样的吗?

其实,大部分人并不会遇到这样的项目。通常情况是:客户最后看到了软件,要么震惊要么不高兴。他们不喜欢所看到的软件,他们认为很多地方需要修改。他们要的功能不在他们给你的原始需求文档中。这听起来是不是更具有代表性?

Helmuth von Moltke曾说过:“没有任何计划在遇敌后还能继续执行。”我们的敌人不是客户,不是用户,不是队友,也不是管理者。真正的敌人是变化。软件开发如战争,形势的变化快速而又剧烈。固守昨天的计划而无视环境的变化会带来灾难。你不可能“战胜”变化—无论它是设计、架构还是你对需求的理解。敏捷—成功的软件开发方法—取决于你识别和适应变化的能力。只有这样才有可能在预算之内及时完成开发,创建真正符合用户需求的系统。

在本章中,我们会介绍如何达到敏捷的目标。首先,要介绍为什么用户和客户参与开发如此重要,以及为什么让客户做决定(从第45页开始)。设计是软件开发的基础,没有它很难做好开发,但你也不能被它牵制。从第48页开始,将介绍如何让设计指导而不是操纵开发。说到牵制,你应确保在项目中引入合适的技术。你需要合理地使用技术(第52页介绍)。

为了让软件符合用户的需求,要一直做下面的准备工作。为了降低集成新代码带来的破坏性变化,你要提早集成,频繁集成(第58页)。当然,你不想破坏已有的代码,想让代码一直保持可以发布(从第55页开始)。

你不能一次又一次为用户演示新功能,而浪费宝贵的开发时间,因此你需要提早实现自动化部署(第61页)。只要你的代码一直可用,并且易于向用户部署,你就能使用演示获得频繁反馈(第64页)。这样你就能经常向全世界发布新版本。你想通过使用短迭代,增量发布来帮助经常发布新功能,与用户的需求变化联系更紧密(从第69页开始介绍它)。

最后,特别是客户要求预先签订固定价格合约时,很难通过敏捷的方法让客户与我们同坐一条船上。而且,事实上是固定的价格就意味着背叛承诺,我们会在第73页了解如何处理这种情况。