从宣言不等式看敏捷开发与传统开发

在正式讨论之前，我们先来首先简单了解下这两者。

传统软件开发方法有瀑布模型、螺旋模型、喷泉模型、RUP(Rational Unified Process)四类，它们注重文档的完整，程序的易读性，结构的完整性，属于重型软件开发方法，被泛的用在公司的软件开发中。随着经济的全球化和技术的迅速发展，对软件开发的生产率和满足客户需求的不确定性和多变性方面提出了更高的要求。

传统方法一般是要求把前期调研分析工作做细、做完整，并以合同的形式与客户确认需求，进行“需求冻结”。客户要补充或更改需求就得补充合同。开发中要以文档记录开发的各项事宜。事实上，在开发前期很难一次性挖掘和确定客户的所有需求。高层管理员虽了解全局工作流程和业务管理方式，但不熟悉具体业务的操作细节;底层业务虽精通自己的业务的操作过程，但对全局又缺乏了解。许多需求是在原型演示、试用、测试，甚至在实际使用过程中才挖掘和确定的。另外，在传统开发方法中，客户很少几乎不参与开发过程。从分析、设计、编码一直到内部测试，整个开发过程对客户几乎是透明的，客户在测试或培训时才见到“庐山真面目”。过程的不透明性一般会造成最后系统的工作模式和操作界面与客户的要求存在一定的距离，甚至会截然相反，这对整个系统的开发会带来灾难性的后果。（需要注意这里的提出的一些传统方法的特点，这也是后面提到的敏捷开发宣言里价值观的启发，例如交流的偏少，合同确认需求，文档记录等）

 

于是，在2001年年初，一批业界专家聚集在一起，提出了一种“更好的”的软件开发方法——敏捷开发。

敏捷开发(Agile Development)是指一种以人为核心、迭代、循序渐进的软件开发方法。这一方法以微小增量的方式建构软件，使得软件具有灵活性，可维护性和可重用性的良好的“敏捷”(agile)特性，因此提高了软件开发的效率并且能够有效的应对开发过程中用户需求的变化。为了达到这种敏捷性，我们需要使用一些实践提供必要的准则和反馈，需要使用一些设计原则使软件保持灵活且可以维护，还需要理解一些已经被证明在特定问题中可以权衡这些原则的设计模式。

他们在2001年成立的敏捷联盟(Agile Alliance)，发表了一份敏捷开发宣言。宣言中，用四个不等式声明出敏捷开发的价值观。

 

敏捷软件开发宣言：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

人和交互重于过程和工具。

可工作的软件重于面面俱到的文档。

客户合作重于合同谈判。

随时应对变化重于遵循规则。

也就是说，尽管右项有其价值，我们更重视左项的价值。

 

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
　　Individuals and interactions over processes and tools
　　Working software over comprehensive documentation
　　Customer collaboration over contract negotiation
　　Responding to change over following a plan
　　That is, while there is value in the items on the right, we value the items on the left more.^[2]

 

敏捷开发宣言提出了四条价值观。

这四条价值观体现了敏捷开发与传统开发的哪些差异呢？我们一条一条来看。

 

先看第一条，人和交互重于过程和工具。

严格的方法学及业务过程在传统的软件开发学中强调过程重于人。而敏捷开发将这一条反过来，相信每个人都是独一无二的，那么应该过程融入团队和个人，而不是反过来。

在传统开发中，合适的工具诸如编译器，IDE和源码控制系统等对于团队开发者完成工作很重要。在敏捷开发中依然如此。不过敏捷开发方法要求工具的作用不能过分的被夸大，使用过多庞大、笨重的开发工具就像缺乏工具一样，不值得提倡。敏捷开发建议从小的工具开始，尝试一个工具，直到发现它无法适用时才去更换更强大的工具。在团队购买最好的 CASE 工具许可证前，先适用白板和方格纸，知道证明的确是需要更多的功能时再去购买工具。更大的功能更全的工具在为团队带来帮助的同时也会造成不必要的障碍。

过程和工具虽然很重要，但人之间的交流才更重要。

 

第二条，可工作的软件重于面面俱到的文档。

传统的开发认为，没有文档的软件是一种灾难。实际上这也是有道理的，代码不是交流系统原理和结构的理想媒介，因此团队需要编写易于阅读的文档，来对系统及其设计的依据进行描述。

但是在实践过程中，过多的文档反而造成了极大的麻烦。一是文档本身费时费力，二是在保持文档与代码同步的过程中又要耗费时间，而如果不这么做，文档本身对于后来的开发者来说，就会是极大的误导了。

因此敏捷开发主张，只需要编写一份短小，主题突出的关于系统原理和结构方面的文档就可以了，开发的重点一定要在最终产品—工作软件上。就是说，每一个项目组必须自己决定，哪些文档在交付工作软件时是非有不可的。摆在开发者和发起人面前的工作软件说明了实质—哪些地方与当初的承诺是不同的。工作软件可以被包装、修改、分析，但却是真实的。虽然直接从代码中提取系统的原理和结构信息是困难的，但是代码是唯一没有二义性的信息源，从这个角度上说：代码即是设计。可工作的软件本身就是很靠谱的进度量尺。

可工作的软件是衡量进度的主要指标，这也是敏捷开发的十二条准则之一。(Working software is the primary measure of progress. )

 

来看第三条，客户合作重于合同谈判。

代码设计中的功能设计，不会像日常购物那样清晰，一目了然。客户不会，有时也是不能写下自己清楚的功能需求。因此，相对于事先商量好的合同里的规定去实现，不如在于客户的协同工作中去完成。

成功的项目需要定期而且频繁的客户反馈，而不是依赖与固定的合同描述。在开发期间，开发人员和客户密切联系，定期的吧软件提交给客户，然后客户返回一份关于软件变更的列表，开发人员把这些反馈的变更排定优先级别并安排在随后的工作任务中。这样客户一直跟踪软件的进度，同时验收和测试功能模块。在这个过程中，需求随着进度持续的变化，有些是小的更改，有些甚至是大的改动，甚至一些先前的大的功能模块被发现是无效的而别删除，另外一些新的模块则被加入，替换。这些改进都是和客户密切的合作中实现的，合同并没有能未卜先知。然而合同和项目都应对了这些变更，保持了项目的进度和软件的质量。成功的关键在于客户协作。

 

最后是第四条，随时应对变化重于遵循规则。

如在文章开头所提，在传统开发方法中，客户要知道在测试或培训时才真正接触到软件。过程的不透明性一般会造成最后的成品与客户的要求存在一定的距离。这就造成相比于遵循规则，随时应变显得更加重要。随时应对变化的能力常常决定一个软件项目的成败。当构建计划时，应该确保计划是灵活的，并且适应商务和技术方面的变化的。

敏捷开发认为较好的计划策略是：为下一周做详细的计划，为下三周做粗略的计划，下周是可以精确计划的，但是未来就充满了变数，有一个模糊的想法就可以了。计划中逐渐降低的细致度，意味着我们仅仅对于迫切的认为才做详细的计划，开发团队就按计划启动并开始了任务，而其余的部分任然保持灵活性。^[3]

 

当然了，任何的开发方法都不能说在任何情况下都是最好的。

美国有一个软件体系结构的专家Bailar采取敏捷方式组建团队，他将项目拆分，从旧的“瀑布式”开发转变为“并列式”开发，形成了“敏捷开发”所倡导的精干而灵活的开发团队，并将开发阶段分成 30 天一个周期，进行“冲刺”。每个冲刺始于一个启动会议，到下个冲刺前结束。

最后的结果显示，“敏捷开发”使得开发时间减少了30%~40%，提交的产品质量也有提高。但Bailar也承认，"敏捷开发"也有局限性，比如对那些不明确、优先权不清楚的需求或处于“较快、较便宜、较优”的三角架构中却不能排列出三者优先级的需求。此外，他觉得大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式。

 

知乎上有人对敏捷有一个不错的定义。

“敏捷”(Agile)代表的是一种方法，是在“以人为核心驱动”(Human-Driven)的“复杂系统”(Complex System)背景下，一个具有适应性的“经验性过程控制方法”(Adaptive Empirical Process Control)。^[4]

所以说，敏捷是一种方法论，敏捷开发方法是一种方法，是将理论具体实践的的方法。

需要注意的是，不能刻意追求，不是为了敏捷而敏捷，而是以对生产和目标有积极帮助为目的。不能强行运用敏捷方法，反过头来却违反了敏捷开发的第一条准则：

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
　　最重要的是通过尽早和不断交付有价值的软件来满足客户需要。

 

我的理解与想法也有不足和不妥之处，欢迎大家讨论与指正。

 

参考文献与资料：

[1] 彭志楠.敏捷开发在软件开发中的应用研究[D].电子科技大学.2009

[2] 敏捷软件开发 Agile software Development: http://kb.cnblogs.com/page/107587/

[3] Beck, Kent. Extreme Programming Explained. Addison-Wesley, 2000

[4]什么是Agile Software Development（敏捷软件开发）？: http://www.zhihu.com/question/23429937yu