软件开发方法之敏捷开发，你用了么？

1.几种开发方法

1.1瀑布式开发——瀑布模型（Waterfall Model）

1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型要求软件开发严格按按照需求→分析→设计→编码→测试的阶段进行，每一个阶段都可以定义明确的产出物和验证准则。瀑布模型在每一个阶段完成后都可以组织相关的评审和验证，严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过后才能够进入到下一个阶段。遵循自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型式是最典型的预见性的方法。

瀑布模型的优点仍然是可以保证整个软件产品较高的质量,保证缺陷能够提前的被发现和解决.采用瀑布模型可以保证系统在整体上的充分把握,使系统具备良好的扩展性和可维护性

瀑布式的主要的问题是它的严格分级导致的*度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

1.2 迭代式开发

迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，在需求被完整地确定之前就能启动开发工作，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

1.3螺旋开发——螺旋模型（Spiral Model）

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于强调其他模型所忽视的风险分析，螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。。

通常螺旋模型由四个阶段组成：制定计划、风险分析、实施工程和客户评估。

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型适用于庞大并且复杂，高风险的项目，需求不明确的情况下，便于风险控制和需求变更。

2.敏捷开发

2.1 敏捷开发的诞生

程序员说，要有敏捷

于是就有了敏捷。

敏捷这个词被用的过于泛滥了，大家都在讨论它，可以把它视为一种宗教。

美国在计算机行业已经走了几十年，瀑布流、螺旋模型、快速迭代…各种各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善，但互联网的加速发展让传统方法显得笨重，难以快速适应变化。有十七个程序员（程序员改变世界）在美国犹他州盐城湖的一个风景区开了个碰头会，找到了一个团队耦合度高，流程极其灵活的方法，他们把它称为敏捷开发（Agile program development）。

2.2 敏捷开发宣言

• 个体和交互重于过程和工具

敏捷方法认为，人是软件开发中最重要的因素，开发团队要能做到团结协作，人与人面对面的交流、沟通，是最快速、最有效的途径。

• 可以工作的软件重于面面俱到的文档

文档的意义在于为程序服务，过多的文档需要开发人员花费大量的时间去维护，而且还要确保文档与代码的实时性，否则就失去了文档的意义。而问题也就在于，开发人员没有把时间、精力放到最重要的任务上，能力、资源没有最大化的发挥效能。敏捷方法认为，文档应当短小精悍、易于维护，而且主题突出。

• 客户协作重于合同谈判

做过软件开发的人都知道，客户对产品的需求是不断变化的，试图一开始就规定项目的细节和进度，显然是不现实的，只有开发团队和客户彼此精诚合作，常与沟通，频繁的客户反馈，才能促使项目的成功。

• 随时响应变化重于循规蹈矩

客户的需求在产品的开发阶段是不断变化的，即使谈判时确定的需求，也可能会根据某些因素而发生巨大的改变。因此，敏捷方法认为，在制定计划时应尽可能的简洁、灵活，以适应技术和需求方面的变动。当然，所有的未知的因素是不可能考虑周全的，这就要求我们在制定计划时，留出一定的缓冲期，来应对这些未知情况。

• 适应变化

传统的软件开发强调的是，足够清晰的需求，制定详细的文档，按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化，无法应对客户对需求的实时更改，后续的维护必将会付出巨大的代价。

而敏捷方法则是以最简的方式来迎接变化，客户在整个开发过程中都是参与者，开发团队能够在最短的时间内得到客户的反馈，不断适应需求的变更，从而使得最终的产品能够充分的符合客户的要求。

2.3敏捷开发

敏捷开发是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发可以说是在迭代开发的基础上发展形成的，它额外强调了沟通合作、以人为本的思想。敏捷开发的缺陷可能在于团队不能过大，一般少于20人，且要求成员都是精干，有互相信任的基础。

3.敏捷开发方法：

3.1 Scrum

Scrum 是当前最流行的敏捷软件开发方法论和实施框架。

Scrum 是一种团队管理工作的方式，其将工作分解为较小的工作单元，并在周期性固定的时间段内持续地交付工作单元

上面描述的周期性固定的时间段，称为迭代（Iteration）或者冲刺（Sprint）。

上面描述的较小的工作单元，称为用户故事（User Story）。

用户故事可以使用特定的格式来描述，其描述了一个对于客户有价值的工作，而且可以在一个迭代周期内完成。

Scrum 框架结构

Scrum敏捷开发流程主要包括：三个角色、三个物件和四个会议。

三个角色：

• 产品经理（Product Owner）：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

• 敏捷教练（Scrum Master）：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

• 开发团队（Scrum Team）：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右。

三个物件：

1、product Backlog ： 产品Backlog指根据初始需求分解出的任务列表，包括功能性和非功能性的所有功能。

2、Sprint Backlog ，这是一个迭代计划会议的输出，包含开发团队在迭代周期内所要完成的工作列表。 如果说产品backlog是以story为单位，文档归属为PM团队，那么Sprint Backlog 是以小时（时间）为单位的，文档归属为开发团队。

3、燃尽图。

燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。（引自百度百科）

scrum基本流程（四个会议）：

1.产品负责人负责整理user story，形成左侧的product backlog。

2.产品发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。

3.spring计划会议：在每个迭代之初，开发团队和 Product Owner 共同来计划在迭代周期内要完成的工作。Product Owner 负责向团队讲解要完成的工作的内容，开发团队负责对工作进行估计。

4.spring每日立会：每天，开发团队和产品负责人都要进行一个短暂的沟通。团队成员回答昨天做了什么？今天计划做什么？遇到了什么问题？

5.spring演示会议：在迭代周期结束时，开发团队向产品负责人及所有干系人进行演示，并接受反馈。

6.spring回顾会议：在迭代周期结束时，Scrum 团队通过会议来对迭代的过程进行总结，以促使团队自我持续改进。

3.2其他开发方法介绍

水晶方法，Crystal ，是由 Alistair Cockburn 和 Jim Highsmith 建立的敏捷方法系列，其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷团队可以根据其项目和环境选择最合适的 Crystal 家族成员。

透明水晶方法，适合于一个小团队来进行敏捷开发，人数在6人以下为宜。

七大体系特征：

• 1. 经常交付

任何项目，无论大小、敏捷程度，其最重要的一项体系特征是每过几个月就向用户交付已测试的运行代码。如果你使用了此体系特征，你就会发现，“经常交付”的作用还是很让人吃惊的。

项目主办者根据团队的工作进展获得重要反馈。用户有机会发现他们原来的需求是否是他们真正想要的，也有机会将观察结果反馈到开发当中。开发人员打破未决问题的死结，从而实现对重点的持续关注。团队得以调整开发和配置的过程，并通过完成这些工作鼓舞团队的士气。

• 2.反思改进

在我们的开发中，时常会出现这样那样的问题，技术难题、各种烦心事等等，这会在很大的程度上影响项目的进展。而且，如果其他任务对这项任务有依赖的话，那么其他的任务也会被推迟，这就很可能会导致项目的失败。

换句话说，如果，我们能够经常在迭代会中及时的反思和改进，那么，这种事情应该是不会发生的，或者说发生了，也能够很快的找到解决方案去应对它。事实上，从慌乱的日常开发中，抽出一点时间来思考更为行之有效的工作方法就已经足够了。

• 3.渗透式交流

渗透交流就是信息流向团队成员的背景听觉，使得成员就像通过渗透一样获取相关信息。这种交流通常都是通过团队成员在同一间工作室内工作而实现的。若其中一名成员提出问题，工作室内的其他成员可以选择关注或不关注的态度，可以加入到这个问题的讨论当中来，也可以继续忙自己的工作。

• 4. 个人安全

个人安全指的是当您指出困扰您的问题时，您不用担心受到报复。个人安全非常重要，有了它，团队可以发现和改正自身的缺点。没有它，团队成员们知而不言，缺点则愈发严重以致于损害整个团队。个人安全是迈向信任的第一步。有了信任，团队协作才能真正的实施，开发效率也就会直线上升的。

• 5.焦点

所谓“焦点”，就是确定首先要做什么，然后安排时间，以平和的心态开展工作。确保团队成员清楚的了解他们自己最重要的任务是什么，确保他们能够有充分的时间去完成这些任务。

• 6.与专家用户建立方便的联系

与专家用户持续建立方便的联系能够给团队提供：对经常交付进行配置以及测试的地方，关于成品质量的快速反馈，关于设计理念的快速反馈，最新的（用户）需求。

• 7.配有自动测试、配置管理和经常集成功能的技术环境

自动测试可以为开发人员在代码修改后就可以进行自动测试，并且能够发现存在的一些bug，以至开发人员能够及时的进行修改，对于他们来说，节省了时间，提高了效率，而且还不用为烦人的测试而苦恼。

总结：

基于敏捷指导思想 ，形成了不少敏捷软件开发方法 (例如XP、scrum、水晶方法等 )，它们大都强调适应性而非预测性、强调以人为中心，而不以流程为中心 ，以及对变化的适应和对人性的关注。

纵观所有敏捷开发方法，其基本都具备轻载、基于时间、Just Enough、并行并基于构件的迭代和增量的特点 。