敏捷方法学给客户交付更多价值
不管软件开发中使用什么样的开发方法学，最终交付的软件是只有给客户产生尽可能多的商业价值，软件项目才能说是成功的。
对于传统的形式化的、戒律森严的软件工程方法学，不仅其要求生成的文档数目和种类，而且需要的管理资源投入、QA评审的程度和开发人员被要求遵守的严格流程1，都极大地偏离了“给客户交付价值”这个核心目标。因此，国际上一些著名的软件工程专家将传统的这些软件方法称之为“重（heavy）”方法，强调方法学对过程的极度严格要求。
与这些“重”方法不同，敏捷方法学就是以“给客户交付价值”为核心原则之一，而不是强调对过程的过度严格的管理。不仅在敏捷价值和原则里面紧扣“客户价值”，而且其所有实践都是客户价值驱动的。
对于软件开发来讲，客户关心的价值在哪些方面呢？在Amr Elssamadisy的Agile Adoption Patterns一书中，定义了如下的客户价值：
1. 短的软件交付周期
2. 及时的响应用户反馈
3. 高的软件质量
4. 软件的灵活性
5. 项目团队的透明性
6. 低的软件成本
7. 高的投资回报率（ROI）
这些客户价值都是紧密联系在一起的，这里我们就只针对第1、3、7等三个方面来做一些相关的阐述。
1.短的软件交付周期
软件交付得越早，交付周期越短，客户就能越早通过使用软件产品来创造自己的价值，特别是商业软件：这是很显然的。即使你交付的软件只包括了完整功能列表里的一部分，但因为那对客户而言是价值最高的部分，而且软件是可以运转的，客户也就得到了更多的价值。不仅仅是完整周期的缩短，更频繁的交付、增进的发布也能给客户带来商业价值。
在传统软件方法学里面，只有到软件交付期限才能交付给客户可用的软件版本。整个软件开发过程里面，客户得不到一个可运行的版本来使用。这样，就严重损害了客户的价值。
在敏捷方法学里面，项目团队通过INVEST的user story划分，保证了客户价值的周期性交付；通过简单设计来保持关注对客户而言优先级最高的user story，避免了对低价值的其他方面的付出；而通过持续集成来保证每个构建出来的版本都是客户可用的候选发布版本……这样，通过多种紧凑的实践，敏捷方法学保证了项目团队对客户价值的关注和尽早实现，并随时提供能满足一定客户价值的可用的软件版本。
2.高的软件质量
软件质量越高，也就意味着软件的缺陷越少，提供的功能更加符合客户真正想要的要求。而且，即使商业需求上发生了变化，高质量的软件也容易进行扩展和修改。
在传统软件方法学里面，也有通过详尽的user case设计、代码评审、QA测试用例等方式来减少软件可能出现的缺陷。但因为分析、设计、开发和测试等环节的脱节，不同环节之见的理解不同，沟通不畅，很难挖掘客户真正的需求和适应需求变化，从而导致大部分最后的软件要么是缺陷多多，要么是功能不能满足客户需求，只能留到二期三期来解决。
在敏捷方法学里面，项目团队通过co-location，打破不同部门之间的隔板，让所有的项目成员坐在一起，减少了软件需求在沟通过程中的失真。如果有现场客户，就更是让这种信息失真问题减到最低。
在开发过程中，敏捷团队会使用TDD、简单设计和持续集成等实践来保证软件的简单，让可能存在的问题尽早的暴露出来；再通过小型sign off，来保证开发人员做出的软件是满足分析人员和测试人员的要求。
3.高的投资回报率（ROI）
作为投资方，客户最关心的莫过于投资回报率(ROI)了。除了前面分析的软件质量和软件成本之外，对ROI有直接影响的因素就是软件生命周期了。软件生命周期是指软件的产生直到报废的整个生命周期。生存周期越长，说明软件能满足用户要求、能被使用的时间周期越长。而软件生命周期又与软件的可维护性和灵活性息息相关。那么，如何保证软件的可维护性和灵活性，就是影响到客户的ROI的关键因素。
在传统软件开发学里面，基本上只有靠一开始的软件设计来提供软件的灵活性。虽然开发过程上游的软件设计的设计方案可能非常优雅，但由于中间过程没有足够的验证和约束，等到软件交付的时候，软件最后实现的可维护性和灵活性完全不能保证。这样，客户就只能祈祷软件的生命周期不要那么短了。
而在敏捷方法学里面，很多的开发实践可以提升软件产品的可维护性和灵活性，比如前面分析的TDD、持续集成和增进设计等等，从而使软件的生命周期得到了极大的延长。因此，这些影响产品生命周期的实践对客户的投资回报率都是有直接或间接的影响。
从上面对三个特定的客户价值的分析可以看出，敏捷方法实践就是以“交付更多客户价值”为出发点提出来的，始终体现了敏捷方法学的价值观：“个体和交互胜过流程和工具，可工作的软件胜过面面俱到的文档，客户合作胜过合同谈判，响应变化胜过遵循计划”，和以 “尽早、持续的交付有价值的软件来使客户满意”原则为首的敏捷原则。
