本文将对敏捷软件开发以及传统软件工程这两种软件开发模式进行介绍，并针对它们的不同之处做出比较。

1.传统软件工程

1.1产生

上个世纪六十年代，随着计算机的发展，人们对软件的需求越来越大，人们开始意识到“软件危机”存在的事实：

• 软件生产不能满足日益增长的需求
• 软件开发成本和开发进度估计往往不准确
• 软件开发人员和用户之间信息交流不充分，用户对完成的软件满意度很低
• 软件价格昂贵，软件成本在整个计算机系统中所占的比例急剧上升，软件已经成为许多计算机系统中花钱最多的项目。
• 软件质量难以保证。
• 软件可维护性差，程序中的错误很难改正，适应性或完善性维护都极其困难。

导致软件危机的一个重要原因，是由于软件研制和维护本身是工程性的任务，但软件人员采取的方式却未能工程化。

为了克服软件危机，人们开始考虑工程化方法和工程途径来研制和维护软件，软件工程就这样诞生了。

1.2瀑布模型

瀑布模型首次出现于Royce在1970年的文章中，尽管当时他并没有使用“瀑布”这一词。讽刺的是，他当时认为这是一种有缺陷的，不可用的模型。而“瀑布模型”一词最早出现于1976年Bell和Thayer的论文里。

 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。它的过程是从上一项活动接收活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动，否则返回前面，甚至更前面的活动。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型分为以下六个活动：

1. System and software requirements: captured in a product requirements document（系统和软件需求：在产品需求文档中显示）
2. Analysis: resulting in models, schema, and business rules（分析：反应在模型，模式和业务规则中）
3. Design: resulting in the software architecture（设计：反映在软件架构中）
4. Coding: the development, proving, and integration of software（编写代码：软件的开发，校对以及整合）
5. Testing: the systematic discovery and debugging of defects（测试：系统地发现和修正不足）
6. Operations: the installation, migration, support, and maintenance of complete systems（运行：完整系统的安装、迁移、支持和维护）

2.敏捷开发

2.1产生

2001年2月，17个软件开发人员聚集在犹他州的snowbird resort一起讨论轻量级软件开发的方法，他们发表了《The Manifesto for Agile Software Development》。由此，敏捷开发诞生了。

在《The Manifesto for Agile Software Development》中，他们提出：

• Individuals and interactions: self-organization and motivation are important, as are interactions like co-location and pair programming.（个体和互动：自我管理和动力十分重要，与互动，如结对编程和co-location同等重要）
• Working software: working software is more useful and welcome than just presenting documents to clients in meetings.（可运行的软件：比起在会议中只向客户展示文档来说，展示可运行的软件更加有用也更受欢迎）
• Customer collaboration: requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.（客户合作：需求不可能在软件开发周期的一开始被完全收集，因此用户和股东的持续参与是非常重要的）
• Responding to change: agile methods are focused on quick responses to change and continuous development.（应对变化：敏捷方法专注于对变化的快速响应以及持续开发）

2.2敏捷开发的原则

敏捷开发有如下十二个原则：

1. Customer satisfaction by early and continuous delivery of valuable software（不断地尽早交付有价值的软件来使客户满足）
2. Welcome changing requirements, even in late development（欢迎需求的变化，即使在开发的后期）
3. Working software is delivered frequently (weeks rather than months)（频繁地交付能够工作的软件，几个星期一次而不是几个月一次）
4. Close, daily cooperation between business people and developers（业务人员和开发人员每天密切合作）
5. Projects are built around motivated individuals, who should be trusted（项目是由有动力的，值得信任的人员开发的）
6. Face-to-face conversation is the best form of communication (co-location)（面对面的交流是最好的交流方式）
7. Working software is the principal measure of progress（可以工作的软件是进度的主要度量标准）
8. Sustainable development, able to maintain a constant pace（可持续的开发，能够保持稳定的进展）
9. Continuous attention to technical excellence and good design（持续注意卓越的技术以及好的设计）
10. Simplicity—the art of maximizing the amount of work not done—is essential（简化-使不需要做的工作最大化的艺术-至关重要）
11. Best architectures, requirements, and designs emerge from self-organizing teams（最好的架构，需求和设计源于自我组织的队伍）
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly（团队要定期总结如何变得更加高效，并相应地调整）

2.3scrum方法

scrum是一种为管理软件开发项目而开发的敏捷软件开发框架，scrum在英语是橄榄球运动中争球的意思。

Scrum是一个包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括：

1. ‘Scrum Master‘是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍；
2. 产品负责人，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投資報酬率负责；
3. 开发团队，一个跨职能的小团队，人数5-9人，团队拥有交付可用软件需要的各种技能。

在每一次冲刺或迭代（一个15到30天的周期，其长度由开发团队决定）当中，开发团队创建可用的（可以随时推出）软件的一个增量。每一个迭代所要实现的功能来自产品订单。产品订单按照优先级排列工作需求。在迭代计划会议中，产品负责人告诉开发团队需要完成产品订单中的哪些订单项。开发团队决定在下一次迭代中他们能够承诺完成多少订单项。[4] 在迭代的过程中，没有人能够变更迭代订单，这意味着在一个迭代中需求是被冻结的。
管理Scrum过程有很多实施方法，如即时贴、白板、甚至软件包。Scrum最大的好处之一是它非常容易学习，而且启动Scrum应用并不需要太多的投入。

3.传统软件工程与敏捷开发的比较

传统软件工程的特点是稳扎稳打，适合需求明确，不会轻易改变的大规模软件。整个过程的初期就设计好整个软件的框架，以此指导之后进程的逐步推进。六个活动相互衔接，每次进行到下一个阶段之前都要经过严格的审查，若发现不符合文档的要求就要返回上个阶段检查并修正。这样的过程保证了软件的质量，同时也带来了弊端，那就是无法适应经常变动的用户需求。软件的框架一旦定下来就很难再改变了，若是需求发生变化就会导致前功尽弃。敏捷开发的诞生则弥补了传统软件工程的这些弊端。敏捷开发注重开发人员、管理人员和产品负责人员之间的沟通，通过不断地迭代，及时响应用户需求的变动。敏捷开发强调可用的产品，要求尽早，尽可能频繁地交付可用的产品，这使产品周期变短。在现在软件开发成本高，需求变化频繁的环境下，敏捷开发是软件开发的很好选择。

敏捷软件开发vs传统软件工程