从计算机诞生开始，软件开发工作，作为一项以单个人脑力劳动为基础的工作，经历了从最初简单单一到现在繁重复杂的发展历程。现今，软件开发往往是一个，涉及到的知识领域广，参与方和参与人员多，项目周期长，复杂程度非常高的工作。比如应用于金融行业和电信行业的软件系统，往往涉及到相关应用行业的专业知识，国家的政策法规，计算机专业知识，数学等众多学科和领域，参与方涉及客户，软件开发商，第三方软件开发商，硬件系统供应商，政府部门等，参与软件设计和开发的人员往往达到几百人，并可能同时分布在多个不同城市/国家，使用不同的语言进行交流，项目周期达到几年也很常见。这其中设计到的问题通常有：
（1）软件开发人员对系统应用领域的专业知识不甚了解，
（2）开发人员技术能力参差不齐，
（3）开发过程的分工合作极为复杂，
（4）软件系统的需求不断变化，
（5）开发周期无限期延长，
等等。
为了有效的组织各种相关资源，科学有序的进行开发工作，确保软件产品质量和按时交付使用，在软件开发过程中，人们不断总结和尝试，衍生出了多种软件工程方法。其中典型的有瀑布模型，螺旋模型，迭代模型等等。现在众多的软件开发商或者遵循其中的一种或者结合几种，按照工程流程进行软件开发。为了便于后面分析对比，我们先对应用瀑布模型的开发过程做简要介绍。瀑布模型分为以下几个阶段依次进行：需求分析（产生需求分析报告），概要设计（产生概要设计报告），详细设计（产生详细设计报告），编码（产生可运行代码），测试（产生测试报告）等。每个阶段必须等到上一个阶段结束后才能开始，每个阶段以上一个阶段的产出物作为起点，最后提交一个产出物供后续阶段使用。
以上典型软件工程方法的特点是：
（1）对开发工作和流程的划分十分细致。整体工作被分为调研，设计，开发，测试等多个环节，而且必须依次进行。
（2）开发人员的工作安排十分严格。（1）中各个阶段的参与人员一般不能重复，而且不同阶段均可能需要客户方人员协作，这就使得交流工作十分繁重。
（3）软件开发的中间产物非常多，各个阶段的设计文档，技术研究报告，评审报告，软件使用说明等必须一一提供。
使用以上典型软件工程方法（或称为传统软件工程方法），对软件开发的方方面面进行了严格的管理：开发工作的划分，人员的安排，项目进度的预设，软件质量和成本的控制。这在很大程度上，对建立在单个人脑力劳动基础上的软件开发工作起到了很好的帮助。典型软件工程方法的特点注定了使用其规范进行的软件开发工作都是一件大规模的工作，在一些大型软件应用系统的开发中具有很好的实用价值。这些方法还在不断得到发展，特别是到最近几年，产生了CMMI体系，从一个更高的层次对软件开发工作进行全面指导。
但是，软件开发和软件应用发展到最近几年，又产生了许多新特点：
（1）软件应用的多样型。应用于各个行业的中小型软件系统，游戏软件大量产生。
（2）交付时间的急迫性。很多系统由于其应用环境特点，要求在很短的时间内完成并交付使用。
（3）软件开发工作的多样性。软件开发技术和工具的大量出现，第三方软件的大量使用。
显然，典型的软件工程方法并不适用于这些情况。于是，在传统软件工程方法的基础上，人们结合近年软件行业出现的特点，不断对其改进，提出了敏捷开发技术。
敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，不再依照传统的软件工程方法逐步深入进行（传统方法下，管理的重点是开发工作逐步深入的个个环节），而是在项目开始的最初，将软件项目的构建切分成多个子项目（这种情况下，管理的重点是开发工作被平行分割后的各个子项目），然后以各个子项目为基础进行开发，各个子项目的成果都经过测试，具备集成和可运行的特征。简而言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。并在整个过程中，对子项目不断集成，在此过程中软件一直处于可使用状态（但可能不具备最终的全部功能）。各个子项目完成后，整个项目也就完成。在敏捷开发内部，其实也借鉴了大量软件工程中的方法。迭代与增量开发，这两种在传统软件工程中常用到的方法，在敏捷开发模式中也扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子。
接下来，我们从一个实例上，分析敏捷开发技术的过程要要点。
敏捷开发概念从2004年初开始广为流行。作为倡导人的Bailar非常支持这一理论，他采取了”敏捷方式”组建团队：Capital One的”敏捷团队”包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导（实际上是业务部门和IT部门之间的”翻译者”）；另外，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过”敏捷开发”的培训，具备相关的技能。
每个团队都有自己的敏捷指导（Bailar聘用了20个敏捷指导），他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿，在9周开发过程中停顿3～4次，以评估过程及决定需求变更是否必要。在Capital One，大的IT项目会被拆分成多个子项目，安排给各”敏捷团队”，这种方式在”敏捷开发”中叫”蜂巢式（swarming）”，所有过程由一名项目经理控制。
为了检验这个系统的效果，Bailar将项目拆分，从旧的”瀑布式”开发转变为”并列式”开发，形成了”敏捷开发”所倡导的精干而灵活的开发团队，并将开发阶段分成30天一个周期，进行”冲刺”，每个冲刺始于一个启动会议，到下个冲刺前结束。
在Bailar将其与传统的开发方式做了对比后，他感到非常兴奋，”敏捷开发”使开发时间减少了30%～40%，有时甚至接近50%，提高了交付产品的质量。”不过，有些需求不能用敏捷开发来处理。” Bailar承认，”敏捷开发”也有局限性，比如对那些不明确、优先权不清楚的需求或处于”较快、较便宜、较优”的三角架构中却不能排列出三者优先级的需求。此外，他觉得大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困难的事，但经过阵痛之后，需求处理流程会让CIO受益匪浅。敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
当然，我们不得不面对的现实是，模式与方法的优化并不意味着问题的终结。作为一种开发模式，敏捷开发同样需要面对众多挑战。
大项目的拆分意味着更多子项目的出现，协调这些同步或异步推进的子项目，合理的资源调配都将变得更加复杂。另外，在当前项目和项目组普遍“增容”的情况下，遇到的问题同样成倍增长。人的重要性被提到了更高的高度，而缺乏有效协调手段，减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战。新方法带来众多便利的同时，也相应引发了几乎同样多的问题。这同时，敏捷开发技术也在得到不断的发展，这些问题也在得到不断的改进。
参考文献
[1]冀乃庚. 软件开发人员绩效考核体系研究[D].西北农林科技大学，2012.
[2]张友生，李雄. 软件开发模型研究综述[J]. 计算机工程与应用，2006，03：109-115.
[3]高禹，毕振波. 软件开发过程模型的发展[J]. 计算机技术与发展，2008，07：83-86.
