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

　　本文写作目的是对当前两种主要的软件开发模式，即敏捷软件开发和传统软件工程进行简单的介绍。

　　1 传统软件工程

　　1.1 产生背景　

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

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

　　导致软件危机的一个重要原因，是由于软件研制和维护本身是工程性的任务，但软件人员采取的方式却未能工程化。为了克服软件危机，人们开始考虑工程化方法和工程途径来研制和维护软件，软件工程就这样诞生了。

　　1.2 传统软件工程概述

　　传统软件工程是基于“瀑布模型”[1]的传统软件开发方法，以软件架构(software architecture)为核心，采用结构化的设计和分析方法将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并规定它们自上而下，相互衔接的顺序，如同瀑布的流水一般。开发的各个阶段的通过文档相互流通，每个阶段结束时要进行严格的审查，检查功能设计和实现是否符合上阶段的文档的要求，如果不符合就逆流到上个阶段检查并修正，直到流到最后阶段产品通过测试。

 

　　2 敏捷软件开发

　　2.1 产生背景

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

　　2.2 敏捷软甲开发概述

　　敏捷软件开发是一组重视人的主观能动性和开发人员、管理层和产品负责人的沟通，通过迭代式和增量式软件，追求便捷，可快速交付，及时响应客户需求变动的软件开发管理方法。

　　敏捷软件开发方法体系主要包括：SCRUM[3]、XP（极限编程）、CRYSTAL（水晶编程）、PPD（特性驱动开发）等。敏捷软件开发的一个精髓就是“刚刚够”思想。用逐步实现的思想替代完整架构，每一步的需求和人员及其沟通、开发成本都刚刚好，通过不断地迭代，在迭代过程中响应客户需求的变化，实现最紧致成本，体现“刚刚好”思想。同时对每次迭代的反馈进行讨论和思考，总结经验和吸取教训。

 

　　3 总结

　　3.1 敏捷开发与传统软件开发的比较

　　敏捷开发的优点是轻量级、简单、可快速交付、最大的特点是高度透明、检验和适应，注重开发团队之间以及开发团队与客户的及时沟通，主张响应需求变化，但是不够系统。

　　传统软件架构的优点在于预见性和系统性，能在正式开发前预见软件的功能需求和非功能需求，最大的特点是重视文档和结构明显，主张固定的流水开发，很难响应客户需求的变化，难以保证开发的灵活性。

　　3.2 敏捷开发与传统软件工程的融合

　　将具有系统性和预见性的传统软件工程架构嵌套到敏捷开发的每次轻量级的迭代中，将软件架构颗粒化，嵌套到整个敏捷开发，使软件工程兼具软件架构的预见性和敏捷开发的适应性，根据项目的大小来调整嵌套的程度，根据每次迭代项目的大小来选择不同的架构，实现敏捷开发与软件架构融合的双赢。

 

　　4 附录

　　[1]瀑布模型：

　　瀑布模型是Winston Royce在1970年提出的一种软件开发模型，瀑布式开发是一种传统的计算机软件开发，是最经典的预见性软件开发方法，严格遵守计划、分析、编码、测试、维护的步骤。阶段之间通过文档流通，每个阶段结束时要进行严格的审查，检查功能设计和实现是否符合上阶段流下了的文档的要求，如果不符合就逆流到上个阶段检查并修正，以此往复，直到流到最后阶段产品通过测试后进行发布及运行期间的维护。

 三个阶段：定义阶段、开发阶段和维护阶段。开发阶段架构师要有预见性地分析客户现在的需求以及以后可能变动的需求，设计规划好大量的功能需求和非功能需求，尽可能多地满足客户后面需求的变动，避免日后重构软件框架带来的成本亏损。设计包括UML图，API接口，数据库表等。开发阶段开发人员根据架构师的对客户需求分析以后设计的蓝图进行软件的开发和测试，实现用户的需求。运维阶段开发团队根据用户使用软件的体验、反馈、软件存在的bug和新增功能需求对软件进行维护，保证软件在保证鲁棒性的前提下尽可能地满足客户的需求。

　　六个流程：制定计划、需求分析、软件设计、程序编写、软件测试和运行维护。

　　瀑布模型的特点：强调文档：瀑布模型每个阶段之间的沟通和交流就是文档，上一个阶段的输出就是下一个阶段的输入，文档就是前后阶段衔接的介质。缺少开发人员之间面对面的沟通和交流，造成文档臃肿现象。结构明显：按需求分析将整个工程划分为完整的阶段集合，每个阶段都有明确的检查点，当出现问题可以使用顺藤摸瓜式往上检查。当一个阶段结束后通过严格审查，就可以只关注下一个阶段，出现问题再逆流检查。

瀑布模型有以下优点：1）为项目提供了按阶段划分的检查点。2）当前一阶段完成后，您只需要去关注后续阶段。3）可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。瀑布模型有以下缺点：

1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。4）瀑布模型的突出缺点是不适应用户需求的变化。

 

[2] 《The Manifesto for Agile Software Development》:

 

Manifesto for Agile Software Development

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 planThat is, while there is value in the items on
the right, we value the items on the left more.

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划 也就是说，尽管右项有其价值，
我们更重视左项的价值。

 

[3] SCRUM:

　　Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。Scrum流程如下图：

 

SCRUM框架包括3个角色、3个工件、5个活动、5个价值

3个角色

1. 产品负责人（Product Owner）
2. Scrum Master
3. Scrum团队

3个工件

1. 产品Backlog（Product Backlog）
2. SprintBacklog
3. 燃尽图（Burn-down Chart)

5个活动

1. Sprint计划会议（Sprint Planning Meeting）
2. 每日站会（Daily Scrum Meeting）
3. Sprint评审会议（Sprint Review Meeting）
4. Sprint回顾会议（Sprint Retrospective Meeting）
5. 产品Backlog梳理会议（ Product Backlog Refinement）

5个价值

1. 承诺 – 愿意对目标做出承诺
2. 专注– 把你的心思和能力都用到你承诺的工作上去
3. 开放– Scrum 把项目中的一切开放给每个人看
4. 尊重– 每个人都有他独特的背景和经验
5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

SCRUM理论基础

Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：

第一：透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

第二：检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

第三：适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

 

 

 

　　参考文献：

[1]http://blog.csdn.net/u012755393/article/details/52790887

[2]构建之法.邹欣

[3]http://baike.baidu.com/link?url=PKzcWINR_04Bg_wCvmsjyW13_zXQswcXfaV3uD5NGep18d8MTwEeZaH5iFnOy7C23ZpW3qRNe2AwK_sLOXhEWK

[4]http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html

[5]http://agilemanifesto.org/iso/zhchs/manifesto.html

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2016-10-20