敏捷已成为软件开发领域的潮流，但单纯为迎合潮流去实施敏捷是不负责任的。开发方法和实践必须服务于业务成功，作为业务导向的敏捷实施成功的前提，首先必须问的问题是：通过敏捷实施要达成的业务目标是什么？为达成这些目标需要做到什么？如何做到？本文将从业务目标出发，分别从这三个方面展开讨论。

　　提高组织的响应能力

　　每一次软件产品的开发都是一个创造的过程，预知一切是不可能完成的任务。

　　首先，商业环境和市场的需求处于变化之中。Jonathan Rasmusson在The Agile Samurai一书中陈述了三个关于需求的简单事实：

　　一、不可能在项目开始的时候收集到所有的需求；

　　二、不管你收集到什么样的需求，它一定会发生变化；

　　三、要做的功能，一定会超过时间和金钱允许的范围。加之，商业环境的不断变化，在项目的初始阶段固定所有需求，只是一个有害无益的幻觉。

　　其次，技术环境以及团队对技术的认识处于变化之中。软件产品的开发是一个探索和发现的过程。项目启动时，团队不可能建立对业务领域、遗留代码、实现技术、工具等方面的完整认知，处于对项目最无知的状态。随着开发的进展，团队不断积累关于业务和技术的知识，并做出相应调整，加之技术环境的不断变化，使得在项目的初始阶段就确定所有的技术方向和实现方案，既不合理也不经济。

　　不确定性是软件开发的固有属性。这既是一个挑战，也是一个机会。传统的管理和技术手段不再适用，不能把握不确定性，适应用户的需求，就会被市场抛弃；同时，不确定性也意味着无限的可能性，掌控不确定性就意味着把握了赢得市场竞争的机会。敏捷软件开发正是要构建组织适应不确定性的能力。《精益和敏捷开发大型应用指南》一书的作者Bas Vodde曾经这样定义敏捷软件开发的完美愿景—“构建组织能够随时在没有额外成本的前提下、交付产品或改变方向的能力”。在本文中，这被称作“响应能力”，并把它定义为：

　　响应能力—软件开发组织在尽量小的额外开销的前提下，通过随时交付，或改变方向来准确、即时地响应市场变化的能力。

　　“响应”是组织对外部（市场和用户）所做出的反应，具体包括：交付产品，当市场需要时向客户交付已完成的工作；改变方向，当市场需要，或组织策略发生变化时，做出针对性的调整。

　　“响应能力”指做出这种反应的能力，具体指标有：即时，在用户需要时随时做出反应；准确，应对市场的真实需求；低额外开销，不应该产生过多正常开发之外的成本，如返工和额外测试或牺牲产品质量等。

　　在网络社会，话语权越来越多地为用户所掌握，不确定性正在从事物背后的规律，变成被市场供需双方普遍接受的事实。面对不确定性，拒绝和避免它不再是一个选项，唯有打造适应它的响应能力，对于软件开发这类创造活动尤其如此。从业务角度来看，实施敏捷软件开发的首要目标正是要打造组织的响应能力。

　　改善协作

　　想象一个软件开发组织，它和市场紧密连接，可以随时交付完成的工作或调整方向，对市场做出准确的反应，这样的组织必然会在市场竞争中占据优势。响应能力是所有软件开发组织所期望具备的，但真正能做到的却很少。究竟是什么影响了组织的响应能力。从内部看，主要是堆积的“在制品”，和技术及学习“债务”。从外部看主要是和市场的连接程度，也即研发团队和业务人员、用户的协作。以下将分别分析这三个方面对组织响应能力的影响。

　　“在制品”是响应外部变化的负担

　　所谓“在制品”（Work In Progress，WIP），是指已经开始但未完成（可以向最终用户交付）的工作。主要包括：未实施的决策、未实现的设计、未集成的编码和未验证的系统。

　　图1是一个典型的瀑布开发模型，需求阶段产出系统的全部需求规格说明；分析设计阶段产出整个系统的架构和详细设计；测试验证前完成所有的代码。这些都属于不可交付的“在制品”，在整个开发过程中，都无法交付软件以响应客户的需求。另外，在项目开发过程中，任何需求的变更，都意味着对“在制品”的返工，例如在编码结束时需求发生了变化，意味着前期的需求分析、架构和详细设计，以及编码都要进行返工，这引入了需求变更的额外成本。因为这些原因，团队无法在较低额外开销的情况下，随时向客户交付产品或改变方向，其响应能力必然是受限的。

图1 瀑布模型下的在制品及其影响