敏捷软件开发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 总结

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/linkrl=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

相关资源:晶体学查看软件_晶体结构查询-软件测试其他资源-CSDN文库

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2016年9月18日
下一篇 2016年9月18日

相关推荐