[敏捷开发实践]（1）认识敏捷开发

[敏捷开发实践]（1）认识敏捷开发

1，提要

软件开发是一个系统工程，包括最初的可行性分析、再到设计、开发、测试、维护等整个生命周期。在这个过程中某些阶段的失误或说是变化，都可能增加整个软件项目的风险。

如何在保证效率的基础上还能安计划、保证质量的完成软件项目？于是产生了软件开发的一些方法，这个方法不是指具体有编码阶段的各种设计模式和技巧，而是在整个软件开发策略层面的方法。

传统瀑布模式和新型的敏捷开发就是其中最常用的方法，后面着重讨论敏捷开发的优缺点和敏捷开发的基础知识。

2，常用的开发模式

（1）传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到交付大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。下面就是典型的瀑布模型。

（3）原型模型， 原型化模型第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。

（3）螺旋模型，将瀑布模型和快速原型模型结合，并特别强调项目风险。通常分为四个阶段组成：制定计划、风险分析、实施工程和客户评估。一般第一个原型只是双方交流的参考，随着后面的版本完善，最终达到目标。比较适合大型项目。

（2）新型的敏捷开发，即迭代式开发，不要求非常完美的需求分析、设计、文档，而是在最短时间内完成一个框架，然后不断迭代，不断测试，直至交付。

但它并不是不需要文档，不需要从需求、设计、开发、测试这样一个过程，在每个迭代过程中仍然需要做这样的事情。

但是敏捷开发更加注重人的因素，不像瀑布式开发那样，由专门的需求人员采集用户需求，由设计师完成设计文档。敏捷开发每个人都是需要了解项目的需求，并不断的进行小会议，不断的测试修改，直到提交。

敏捷开发则是以测试驱动开发，而瀑布式开发是以文档驱动开发。

下图是Scrum(敏捷开发的一种)敏捷开发模式

3，传统开发模式和敏捷开发的优缺点

主要对比比较常用的瀑布模型和敏捷开发。

(1)瀑布式开发：

a.讲求阶段明确，严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。软件生命周期前期造成的Bug的影响比后期的大的多。

b.特别强调文档，在开发的后期才会看到软件的模样。在这种情况下，文档的重要性仿佛已经超过了代码的重要性。

c.流水式的开发，瀑布模型把开发人员定义为流水线上的工人。由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等。对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。当然好的方面就是按一定规范开发，如果有人员流失，短时间内可以补上去，除了核心的东西有文档参考外，开发过程本身就是在一定框架内的。

d.进度一目了解，瀑布模型产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度情况（只有能看懂百分比就行），很适合向领导汇报用。所以管理人员比较喜欢瀑布模型，但是开发人员不喜欢，因为它束缚了开发人员的创造性。

（2）敏捷开发

a.唯快不破，敏捷即是快之意，不仅思维快节奏，而且行为也是快节奏，因上受到当今快节奏社会的喜爱。

b.以人为本，和瀑布开发对应的文档为主来说，在敏捷开发中更强调人，在细节开发上个人可以发挥主观性，使用自己善长的技术和模式开发，而非机器式的开发，容易激发团队成员兴趣和创造力。除了项目参与者，人的因素中更考虑到与客户的沟通。每个成员都需要从沟通中，会议交流中，不断实现迭代。

c.结果第一，不强调文档，突破束缚，软件的最终结果才是重点，文档等都是为软件开发本身服务的，完成了一个优秀的、质量可靠的软件才是敏捷开发的重中之重。

d.迭代开发，迭代是敏捷开发的核心，不断迭代测试的过程，实际上就是精益求精的过程，正和现在这个社会的工匠精神相吻合。

e.整合不易，快速迭代，就需要分割整体业务，对于复杂的客户需求，如何兼顾分割与整体，并不容易，这个需要在项目设计之初考虑到。

4，敏捷开发管理方法

敏捷开发的管理方法有很多种，比较广泛应用的有XP、Scrum等。既然都是敏捷开发，他们都有共同点，强调高速响应变更、以人为主重视团队成员自身发展，倾向采用迭代式的软件开发生命周期模型。

敏捷开发中，XP和Scrum的区别：

a.迭代周期不同,XP的每个Sprint(冲阶)的长度大概为1~2周，而Scrum为2~4周。
b.迭代周期内专一性不同，XP在一个迭代中，如一个User Story(用户素材，也就是一个用户需求)还未实现，可以考虑另外需求替换，原则是时间当量相等。而Scrum不允许这样，一旦迭代开发会毕，任何需求不允添加进入，并有Master严格把关，使团队不受干扰。
c.User Story优先级机制不同,XP必须遵守优先级（当然需要先确实优先级），Scrum更灵活，可以不遵循优先级。比如依赖关系中，虽然 US-A高于US-B，但由于要完成A需依赖B，则需要先开发B。
d.实施中是否采用工程方法问题两者做法不同，Scrum这点上没有工程实践处方，体现的是以人为本，自我创造；而XP必须严格按TDD,自动测试，结对编程，简单设计，重构等约束团队，似乎看起来XP的方式束缚了团队，但需要看这个约束的程度，过细则会让人感觉与“以人为本，自我创新”思想不符，但优点就是一定程度上的规范更有利于保证软件质量。
一个让人困惑的矛盾, 因为xp的理念，结合敏捷模式，表达给团队的信息是“你是一个完全自我管理的组织，但你必须要实现TDD, 结对编程, ...等等”

通过区别，看出： Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束