标签：快速开发 并且 等等 检验和 个人 透明 规模 设计 发包
大家都知道软件工程实在上个世纪60年代末因为软件危机，人们提出的一种软件的开发和管理的方法。自从瀑布式开发模式提出之后，软件工程就走上了规范化的道路。对于一些功能强大，规模较大的软件，人们可以将开发过程工程化，做好每个阶段的规划，制定相应的标准，这样可以创造出功能齐全，而且十分安全的软件。
然而随着时代的进步和发展，随着软件工程的发展，逐步衍生出各种各样的软件开发模式。其中最受瞩目的就是敏捷开发模式。敏捷开发在短期的发展后，逐步从传统开发模式中脱离出来，逐渐占据了软件开发行业的半壁江山。然而这两种开发方式究竟谁更强，谁更加优秀呢。
一、首先我们来了解一下两种开发模式。
（一）传统软件工程
含有不同种开发模型。其中很常见的就是瀑布式开发模式。其他的还有RAD模型，增量过程模型，原型模型，螺旋模型，并发开发模型，面向对象开发，形式化开发等等。
这是一种老旧的开发模式，在现在的软件开发环境中已经显得略有过时。瀑布式开发的核心思想就是将功能的设计与实现分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。在瀑布式模型中，软件生命周期被划分为需求分析、系统设计、程序设计、程序编写、联合测试、系统测试、兼容测试和运行维护这几个模块。这几项活动是自上而下的，上一级如果不被完成将无法进行下面的后动甚至会返回上一级的活动。
这种开发模式的特点是要求几项活动有着严格的顺序，并且每个阶段的成果要进行评审，而且需求不允许有不确定性。开发过程难免会有一些阻塞的情况发生，因此要求顾客有着足够的耐心。所以面对一些经常更改需求，需要短期内完成程序设计的需求，瀑布式开发并不适用。
这个模型是基于构件的一种快速开发的模型。人们根据软件的构件分成足够多的组，每组开发一个构件。没一个构件都分为业务建模、数据建模、处理建模、应用生成和测试及反复5个步骤。这样可以在短期内（60-90天）的时间内同时完成不同的构件，进而组成一个完整的软件工程。但是对于大型的项目来说，这个模型要求的人力十分庞大，而且对于不能够合理的划分模块的程序，并不适用。
这三种都属于演化软件过程模型。他们更加体现软件的变化特征，突出迭代的思想。增量过程模型力图尽早占领市场，逐步发布新的版本。QQ和各种大型网游都是很好的例子。螺旋模型则致力于不同版本以不同形式的不断变化，而且需要高水平的风险评估技术。并发开发模型则由用户要求、管理决策和评审结果驱动。没一个软件工程活动都会触发活动网络的状态变迁。
（二）敏捷开发
敏捷开发是本世纪提出来的一种开发理论。这种理论遵循的理念是：个体和交互胜过、过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。虽然传统软件工程提出的观点很有价值，但是我们认为在某些情况下，敏捷开发追求的一些东西会更加的有用。敏捷开发包括了SCRUM、XP（极限编程）、crystal、PPD等体系方法。
这种开发模型要求有
三个角色：流程管理员、产品负责人和开发团队。
三种工件：产品列表、迭代列表和燃尽图。
四个会议：sprint plan meeting、daily scrum meeting、sprint review meeting和sprint retrospective meeting。
五个步骤：
1) 项目人员根据需求的优先级确定排序好的product backlog（按需排列的产品需求表）
2) Scrum team 根据列表选出要迭代的目标。完成这个目标需要大约4周
3) Scrum team 每天进行daily scrum meeting。每个人汇报完成情况以及问题。完成sprint burn down图。
4) 完成所有的迭代目标之后，进行sprint review meeting，所有人员参加，并根据产品负责人员的需求进行调整。
5) 进行sprint retrospective meeting，总结本次sprint，为下一次sprint做准备。
XP开发相对于Scrum开发整体思维并没有太多的差距，但是两者之间还是有一些细小的差别。XP开发没一个迭代目标完成的时间设定的更加短，大约1到2周。此外，在XP开发中，如果一个小需求还没有完成，则可以选择用等量工作量的需求替换他。相对于Scrum更加的灵活。还有一点，XP开发必须要遵守优先级的顺序，而scrum则考虑人员因事耽误或这低优先级是高优先级的基础等方面的因素，并不要求一定按照之前约定好的优先级进行开发。同时，XP是有着严格的管理，自动测试，结对变成等约束团体的行为。而scrum则是完全靠人员的自觉性来保证整个团队的开发进程。
二、谈完了两种开发方式的一些模型，接下来谈一下传统软工和敏捷开发两者之间的区别。
敏捷开发的优点是轻量级、简单、可快速交付、最大的特点是高度透明、检验和适应，注重开发团队之间以及开发团队与客户的及时沟通，主张响应需求变化，但是不够系统。
传统软件架构的优点在于预见性和系统性，能在正式开发前预见软件的功能需求和非功能需求，最大的特点是重视文档和结构明显，主张固定的流水开发，很难响应客户需求的变化，难以保证开发的灵活性。
说白了，就是字面意思，敏捷开发注重的是敏捷，快速。而传统软工注重的是工程化的方法，更加注重系统开发，以及保证其完整性和安全性。
而现如今，计算机科学越来越发达，软件工程的两种开发方式更应该互取优点，力求在软件开发方面做出更大的进步。我认为可以将软件工程的架构方法移植到敏捷开发的没一个阶段，将软件进行颗粒化，并使每一个颗粒都有一个架构。这样可以使软件工程既有传统软工的可预见性，又有敏捷开发的便利性和适应性。
当然这种方法也不是绝对的。我们应该学会在不同的情况下考虑究竟是使用这两种方法中的哪一个。对于一个大型的工程，可能会花费很长的时间才能完成的工程，其中甚至可能会有人员的更换，这种情况下，我们应该果断的采用传统软件工程方法，这样可以保证工程的预见性和系统性，在长时间的开发过程中，不至于出现过多的因为交流不通畅或者人员变动所导致的错误，或者整个工程的失败。
而如果我们作为一个小型的团队，在一个实验室或者办公室中进行一些小型的开发，而且软件的需求方又随时有可能更改软件需求，那么敏捷开发便再合适不过了。随时开发，发现问题能随时更改，需求变更也可以随时跟上进度，由于沟通便利，工程的质量也不会出现问题。
根据上面的分析，我认为现如今这两种方法都会有各自的生命力。两者不存才谁优谁劣的关系，在选择开发模式的时候，根据自己的需求，人员的配置，工作的环境等等进行判断，到底哪种开发方式更加适合自己，这才是最重要的。
标签：快速开发 并且 等等 检验和 个人 透明 规模 设计 发包
原文地址：http://www.cnblogs.com/pocky/p/5989961.html
