敏捷软件开发（Agile Software Development）的上位史
所谓敏捷，最常见的用法，便是用来形容动作的迅速与思维的活跃了，但若是给“软件开发”这个计算机行业的术语强行戴上一个“敏捷”的帽子，读者见了十有八九会一脸懵逼：厉害了我的哥，软件开发怎么还能“敏捷”了？
从上面的漫画可以看出，“敏捷软件开发”并不是要求开发人员练出像猴一样的敏捷身手（当然如果读者真的是一位身手敏捷的程序“猿”，那就更好不过了），而是一种在最近十几年才开始慢慢流行起来的新型的软件开发的理念，下面将分版块对其进行介绍，并将其与传统的软件工程在多方面的比较穿插其中。
<目录>
一、 何为传统的软件工程
- 出现背景
- 思想根基
- 瀑布模型
二、 何为敏捷软件开发
- 思想根基
- 组织背景
- 开发原则
三、 各自的优势领域是什么
- 传统软件工程的优势领域
- 敏捷开发的优势领域
四、 总结
<一>何为传统的软件工程
<1>出现背景
进入上个世纪60年代，“软件危机”的说法开始盛行，存在着软件生产不能满足市场需要、开发成本和开发进度估计不准确、开发人员之间交流不充分、客户对软件的满意度低、软件可维护性差等亟待解决的问题，而这些问题出现的重要原因之一，便是软件人员的开发模式未能工程化，因此传统的软件工程在人们的千呼万唤中诞生了。
<2>思想根基[1]
传统的软件工程要求在开发过程中，应该根据不同时期的需要，将工程划分为前后有序的明确步骤，并在强有力的管理下依次完成。一般包含以下八个阶段：可行性研究与计划、需求分析、概要设计、详细设计、实现（包括单元测试）、组装测试（即集成测试）、确认测试、使用维护。并且在工程的进行过程中，需要撰写大量的文档，例如：可行性研究报告、项目开发计划、软件需求说明书、用户手册、操作手册、测试分析报告、项目开发总结报告等。这些文档有效地串通了业务人员、开发人员与管理人员，并且显著降低了每个开发步骤的错误率，即使存在错误，也能够通过分析文档进行快速的定位修改，因此工程的开发过程更加条理化、系统化、工程化，生产出来的产品也更加稳定。
<3>瀑布模型
瀑布模型是一种典型的传统软件工程的开发思想，由W.Royce在1970年提出。下面以瀑布模型为例来简要说明一下传统软件工程的应用。瀑布模型的开发过程是有固定顺序的，并且每一阶段的的输入是由上一阶段的输出得来，因此也就意味着之前的工作没有完成，是不能够继续进行下一阶段开发的。因此，应用瀑布模型思想进行开发，虽然比较稳定，而且需求明确，但是由于其耗时长、任务顺序固定、越往后越难纠错、不能应对需求变化等缺点，使得开发人员开始找寻一条新的、适合于当今社会背景的开发之路。
<二>何为敏捷软件开发
<1>思想根基
敏捷软件开发思想的根基在于将大的项目划分为多个相互联系、可以独立运行的小项目，并且在项目期间加强与客户的交流合作，实时反馈并根据反馈内容实时修改开发计划。比起传统的软件工程，它更加强调面对面的沟通、频繁交付新的软件版本、更好地适应需求的变化以及重视人在软件开发中的作用。
<2>组织背景
随着客户需求的变化日益频繁，敏捷开发的本质使得它的出现几乎成为了一件板上钉钉的事情。2001年，全世界范围内的敏捷开发的爱好者聚集在了美国犹他州的雪鸟，组成了敏捷联盟，并提出了自己的开发原则。自此，敏捷开发者正式拥有了一个像模像样的组织
<3>开发原则[2]
下面是敏捷开发的12条英文原则，以及自己在细读原则后的几点分析（其中包含了敏捷开发与传统软件工程的对比）：
1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
我们应该根据客户对功能的需求，首先为客户提供最有价值的功能。这也就是说，敏捷开发能够在开发的每一步看到并且运行已有的成果，而并不是像传统的软件工程那样，只有等到整个工程结束后才可以看到成果如何，通过频繁的迭代能够在早期与客户形成良好的合作，并得到反馈来及时调整自己的开发计划。
2.Welcome changing requirements, even late in development. Agile processes harness change for the customer‘s competitive advantage.
敏捷开发的参与者不怕需求的变化，相反地，他们认为有需求变化是好事，因为这能够充分发挥敏捷开发的优势，毕竟传统的软件工程是不支持频繁改变的需求的，因此这既是挑战，也是机遇。
3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
减小迭代的时间间隔，并将阶段性的成果频繁交付给客户，让客户在每一阶段都能够有软件可用，这样能够使得用户提前体验到已有的功能，增加客户对开发人员的信赖程度，并且便于客户根据现阶段能够看到的功能，对软件的未来提出新的期许。
4.Business people and developers must work together daily throughout the project.
业务人员和开发人员应该每天都在一起工作，正所谓隔行如隔山，开发人员懂得如何开发，却不懂得业务人员的使用习惯。这样，每当程序员实现一个功能之前，都去吸收一下业务人员的建议，这样能够使得最终设计出来的软件，受到更广泛的业务人员的欢迎概率大大增加。
5.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
比起传统的软件工程，敏捷开发更加注重以人为本，认为给开发人员提供一个适宜的环境，相信他们的工作并且在他们需要的时候提供强有力的支持，更能够鼓舞人心，在这种积极的环境中，能够想象到的最终结果一定是皆大欢喜的“提前N天结束，并超额完成任务”！
6.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
面对面的交流比起其他的方式更有效率。敏捷开发的人员数量一般不会很多，因此比起通过文档交流，凑在一起唠个嗑会是更有效率的交流方式（当然，大家都得克制自己，在工作的时候少说或者不说题外话，否则，一天过去了，只写了一个HelloWorld也不是没有可能）。
7.Working software is the primary measure of progress.
比起传统软件工程不好计量工作进度的特点，敏捷开发由于能够在不同的开发阶段实现新的功能，因此更容易计量，在进度能够量化的体系中，员工的效率更容易保持在一个较高的水平。
8.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
开发者应该被允许在一个比较恒定的速度上开发。这个问题在国内的某些企业尤其严重，过多的加班使得员工的身体和精神随时处于崩溃的边缘，并且养成了“突击”的意识。实际上，为了提前做完工程而使员工一直超负荷工作是不明智的，因为这样会大大降低他们的工作兴趣，并且产生一些消极的抵抗心理。
9.Continuous attention to technical excellence and good design enhances agility.
这句话正好验证了中国的一句老话：活到老，学到老。作为一名开发人员，永远不能自大，因为没人敢说自己已经精通了所有的技能，或者能够解决所有的问题，一定要怀着一颗谦逊的心，多看书，看好书。
10.Simplicity--the art of maximizing the amount of work not done--is essential.
在构建某一阶段的工作模型的时候，不要过于复杂，实现最初期望实现的功能就好，因为客户的需求是可能随时改变的，一开始就构建一个完整的框架很可能会拖慢整体的进度。像是两个在火灾现场逃生的人，其中一个只以当前最迫切的逃生为目的，而另一个顾虑的比较多，想着逃生的同时，却还想着拿点财物出去方便今后的生活。相比较而言，前者更容易逃生，后者能逃出来固然是好的，如果逃不出来，那之前的所有“为了未来更好生活”的计划便真的是一点意义也没有了。
11.The best architectures, requirements, and designs emerge from self-organizing teams.
自组织团队是敏捷开发的标志性特征之一，自组织团队比起传统的软件开发团队来说相对自由，团队的凝聚不是靠管理者的管理，而是靠团队文化对每个成员潜移默化的影响。自组织团队的成员能够更加自由地发表自己的见解，当然这条原则也经常是敏捷开发反对者们攻击的对象，毕竟在他们看来，没有的管理层的团队更像是一盘散沙。
12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
反思是进步的前提工作，由于敏捷开发提高了软件开发中人的作用，因此软件项目在开发时，受成员的主观影响非常大，出现错误的地方也是千差万别。因此，团队成员应该习惯在一个阶段结束的时候，反思之前的工作，并为今后的开发提供更加合理的建议，以此来保持团队的敏捷性。
<三>各自的优势领域是什么
<1>传统软件工程的优势领域
在上世纪六七十年代，软件行业从无到有地慢慢发展起来，但是由于当时尚处于启蒙阶段，落后的制造技术、复杂的操作以及高昂的成本使得软件还无法面向普通民众推广，而是只能用在某些大型的、国家控制的行业中，像是宇航业、导弹业等等，而这些行业的第一要素显然是高准确度与高安全性，因此，传统的以瀑布模型为代表的软件开发理念以其比较稳健的、不易改变的特性而备受青睐。直到现在也是这样，对软件的可靠性与质量有极高要求，而且需求固定（或者不频繁变化）的行业，还是以传统的软件工程设计思想为主。
<2>敏捷开发的优势领域
随着时代的发展，如今家家户户都有自己的电子设备，开发面向大众的软件已是众望所归。比起之前所说的那些国家组织开发的高精度项目，这些面向大众的软件在复杂程度的层级上一般要远远低于前者，安全性要求也没有那么高，但是突出了客户的个性化需求，并且存在着客户在开发的不同阶段变更要求的可能性。因此，相比较而言，更经常与客户进行交流，且对客户的需求变化也能积极应对的敏捷软件开发在此类情景中更占优势。
<四>总结
敏捷软件开发与传统的软件工程都有各自的优缺点与适用范围，因此开发团队可以根据自己的需要来选择应用哪个开发思想，但是在选择之前一定要根据自己团队的现实情况来做充分的评估。
近些年，一股“敏捷热”席卷而来，很多人甚至把敏捷开发狂热化了。在我看来，这确实有些过了，因为技术与市场发展到一定程度，随之产生新的思想是一种正常的规律，而新的思想也会被多年后更加新颖的思想所取代，只要社会还是发展的，更新便会永无止境。因此，在看待一个新兴事物时，务必要多方面去看待，并从自己的角度去理解新技术、新思想的本质，切不可道听途说。
引用：
[1]百度文库《传统软件工程概述》
http://wenku.baidu.com/link?url=V8U0ajvchEcDhAK-EMImWHHxAbkn7EeQ4WoVAOgqL9jvpM-z0YMhvYAKwfsqctm8mBAQCtkrblCXTScC-_f8qc6zbhYeDNjM8epjFypLNg_
[2]wikipedia:Agile software development
https://en.wikipedia.org/wiki/Agile_software_development
[3]所有图片来源于必应
http://cn.bing.com/images/trending?FORM=ILPTRD
2016-10-18 22:07:47