【摘要】：软件项目开发流程有很多种,瀑布式开发和SCRUM敏捷开发是其中的两种。作为集成产品的软件项目,选择一种合适的开发流程显得尤为重要。通过研究两种流程的优缺点,进一步了解两种流程的本质,可以根据自己产品的特点选择合适的开发流程,甚至优化流程,从而能够最大化地利用资源,使开发项目顺利进行。

从去年我一直设想能够在公司的整个开发部门有机会在成型开发团队尝试中小范围的敏捷开发.这个想法其实也是由来已久.或者是说源自于自己在工作中深受传统瀑布开发模型一些弊端的切身感受.

作为一个软件工程师不断重复努力开发出高质量的软件.希望我们的用户能够使用到无Bug最佳的应用程序和良好的用户体验.而构建一个稳定可靠的软件是在软件开发流程中其实一件很困难的工作.而仅仅吧软件质量的责任归咎于程序员是不公平的. 软件开发流程是需要来自不同领域人或Team参与一个过程. 而软件质量在这个整个开发流程也是息息相关的.

针对开发流程.业界早已衍生出一些相对成熟. 可控. 能够预估软件开发模型. 本篇你能够了解如下两个方面内容: A:如果你是一个开发人员.还停留传统瀑布开发模型中.想了解软件开发的敏捷方法? B:软件质量控制在传统瀑布开发模型与敏捷方法不同之处,有何优劣?

软件开发流程是一个很大的命题.所以本篇我不会对此进行泛泛而谈.我要说的所有内容都会围绕着，如何在传统瀑布开发和敏捷开发方法之间进行软件质量控制? 二者有何差异和不同? 两个问题展开.

瀑布[Waterfall Model]开发方法.相信对于大多数开发人员来说都是很熟悉的.可能很多人和Team现在依然还停留在这个开发方法中进行日常开发工作. 瀑布方法是由Winston W.Royce 博士在1970年代发表的一篇论文中“管理大型软件系统开发[]”提出的.很多人都认为瀑布开发方法都是源之于这篇论文. 其实如果你仔细的阅读这篇论文.你会发现在最初的文章中，Royce提倡重复地使用瀑布模型，以一种迭代的方式. Royce实际在论文中试图拿这种Waterfall Model开发方法来论证说明这种开发模式是存在缺陷的.而且可能导致项目失败. 而Royce没有料到的是Waterfall Model却意外的成为业界大多数软件开发的最早标准.

瀑布模型[Waterfall Model]最早强调系统开发应有完整生命周期，且必须完整的经历周期中每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，因此瀑布模型又可以称为‘系统发展生命周期’[System Development Life Cycle, SDLC]。由于该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，因此能有效的确保系统品质

Waterfall Model瀑布开发模型强调的是软件开发周期中每一个阶段都是线性的向下进行的:

至于这个流程相信很多开发人员已经是非常熟悉了.但在实际开发流程瀑布模型存在哪些问题、>?

首先第一点不得不说的就是在瀑布模型每个步骤都必须要按照顺序执行.直到整个软件开发周期完成. 最关键的是每个阶段在完成之前不能开始下一个阶段. 每一步的执行则是完全依赖于上一个阶段. 另外相信很多人会说在瀑布模型里说明问题是需要文档来记录的. 而且文档在这个过程每个阶段都需要详细文档来维系.

很多人会问 如何在瀑布模型中保证软件质量?>

相信很多在实际项目中完整执行过该流程开发人员。应该清楚我们确定需求需要做持续做在文档做出软件概要设计和详细设计. 其实瀑布模型这样做要求在设计分析阶段尽可能多发现纰漏. 才能在开发阶段避免错误. 这有什么问题呢?

相信很多人发现.这种要求在设计分析阶段就能发现整个软件开发周期要发现所有可能出现的问题. 基本是不可能的. 而很多关键的细节如果不到具体的实现阶段是不可能发现的.

而由于这个模型.强制要求在编码开始之前要冻结规范文档. 也就是说很难在发布阶段将早起用户以及测试反馈的问题包含进来. 这样一来就降低开发团队响应客户需求的能力. 特别在发布周期要求比较高时.开发团队不能持续想客户交付有效功能点.

至于测试则是整个编码结束后拖到整个开发周期的最后. 这就是集成化测试的开始阶段.为交付有效功能点和软件质量照成一定风险.

其实对用瀑布模型这种臃肿不堪.要求严格.而无法适应软件开发周期变化开发模型.业界渐渐可是兴起向更轻型的软件开发方法演化。在90年代时提出好几种轻型方法.强调专注于软件自我管理的团队. 提倡面对面的交流. 轻型文档和迭代发布等概念.

敏捷方法是试图通过小型的. 自我管理的团队用短小的合作发布周期来鼓励迭代式软件开发方法.软件的质量贯穿敏捷软件开发每一个阶段.且非常重要.,并提出很多关键的规则[例如: 结对编程. Test Driver Development测试驱动开发.,重构和持续集成]来保证能在每一个迭代周期内及早是的发现并及时相应消灭开发过程中出现错误.

Scrum大概是目前敏捷方法里面最出名. 至少也是各位实行听说敏捷方法最熟悉一个.

其实冲本质上来说Scrum本身并不是所谓方法论.而是一组实践和为其过程参与者制定角色框架.其实它和其他敏捷方法是殊途同归.Scrum鼓励小型的,自我管理的团队在短的开发周期完成一系列定义良好的开发任务.

Scrum虽然提供了一个很有价值的框架. 但实际上和XP TDD不同的是它并没有定义明确可行的方法来管理开发出来的软件的质量.但其实这没有问题.Scrum的做法只是这个工作下放到Scrum团队每一个人.让开发团队自己决定选择实现什么样的质量控制实践.

在这一点上和XP TDD提出关注项目的框架.Scrum则淡化这一部分.而是更多对管理代码质量做出很多实践规定.

Scrum周期如何执行的?

每一个Scrum项目周期都被看做一个Sprint.它用来标识完成一组功能开发所需要的时间.Sprint即从Scrum团队打算把精力放在一组功能上开始.而这组功能是由Scrum团队在源自于Product Backlog的计划阶段期间选择的. Produc Backlog其实是指一张关于软件开发所有可能功能点优先级列表.

其中在计划阶段的末尾.所有从Product Backlog里选出来的功能都会被加入Sprint Backlog里执行跟踪.Sprint Backlog表示团队要开发的具体功能的细节.或者就是需求表现出来的功能点.一旦Sprint Backlog定义完成整个Sprint周期就开始.

通畅在一个Sprint周期会持续30天.在Sprint期间团队成员会聚在一起检查工作进展并帮助每一个队员保持工作效率.而在这个Sprint末尾。在Sprint Backlog里定义的功能点将全部完成并可用.

而这个过程就如上图.Scrum优缺点在那?

Scrum相对传统瀑布模型.在构建真个开发活动前.思考并记录下来真个流程.,按照具体的计划实施，保持各项事务尽可能的有组织性.另外可以从整个Sprint周期来看到.Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化.使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低:

Scrum模型和传统模型的对比:

Programming，极限编程）不同，Scrum并没有提供核心的价值观与指导原则，也缺乏具体的实践方法，例如结队编程、测试驱动开发。Scrum仅仅规定了实施的基本流程与检查表，它是一个开放的管理框架，重心在于项目管理，而不是指导团队成员如何进行开发。它很灵活，能够适应大多数场景，也可以兼容并包地引入其他方法学所提倡的实践.这既是Scrum的优点.

但在实际执行中也存在缺陷缺陷，使得它难以被实践。如果没有一位优秀的Scrum Master，而团队成员又缺乏自我组织和管理的能力，就会让开发过程变得混乱无法达到预期效果.

Scrum的核心在于迭代。团队首先浏览开发需求，考虑可用技术，并对自身技术及能力做出评估。然后共同确定构建功能的方案，并每日调整方法，以应对新的复杂问题、困难和出乎意料的情况。团队找出并选择最佳方案去完成任务。此创造性过程便是Scrum生产力的核心[1]。Scrum的所有实践就是围绕着一个迭代和增量的过程开展的

中文名：《》  作者：
《Scrum敏捷软件开发》是及创始人之一、及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作，也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考

《用户故事与敏捷方法》：敏捷大师Mike Cohn的软件需求方法圣经，小型团队(项目)不可或缺的敏捷开发宝典，亚马逊五星级长销图书，敏捷社区重点推荐，结合精髓和实例，充分演绎用户故事的智慧。

上海：世界图书出版公司，2007：