敏捷开发

瀑布式开发

瀑布式开发的基本流程是 需求 → 设计 → 开发 → 测试 ， 是一个更倾向于严格控制的管理模式 。 要求有明确的需求，大家按照需求一步步做好规划，每一阶段工作的完成是下一阶段工作开始的前提，每一阶段都要进行严格的评审，保证各阶段的工作做得足够好时才允许进入下一阶段。这种模式一般适用于需求比较明确、to B 端的项目。

不得不说瀑布项目失败率会比较高，因为它有一个很大的缺陷， 就是受各种条件的制约。当产品研发完成后， 到了产品测试阶段 万一发现问题 ，或者发现其无法满足市场需求， 那么就需要重新开发，甚至需要重新规划产品，这 间接导致了产品延期发布的高发性 与不确定性。

微软 的瀑布式开发模式就是个很好的例子。随着用户对软件的需求越来越苛刻，微软的软件产品曾经遭受了大家的不满，原因并非是产品的使用问题，而是其更新周期太过漫长 。

比如微软Office 、 Windows 等主打产品的更新周期长达 3 年左右，软件延期发布实属家常便饭，此时微软的瀑布式开发模式已经难以满足新型软件的开发要求，不得不改变产品的研发策略。

随着网络的逐渐兴起，软件交付模式发生了巨大变化，也正是在 那 个时候，“敏捷开发”模式被国外的软件先行者们探索出来了。

敏捷式开发

简单的说，敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把 用户（客户 ）最关注的软件原型做出来，交付或上线，在实际场景中去 快速 修改弥补需求中的不足，再次发布版本。通过一些敏捷实践方式，细化story ，提供更小的迭代。如此循环，直到用户（客户）满意。适用于需求不明确、创新性或者需要抢占市场的项目。

还是拿微软来说，微软的Visual Studio 2010是公司内部首个因敏捷开发模式而受益的Visual Studio版本，该软件发布于2010年4月，耗费了两年的时间完成开发，但随后研发团队发现软件中的许多模板对于敏捷开发者来说太过笼统，几乎没有太大的实际意义，微软的软件研发策略也就从此开始发生了巨大变化。以往的产品更新周期为两到三年，目前的版本更新速度已经缩短至一个季度左右，这在瀑布式开发模式下是难以想象的。

Scrum

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。

【Scrum开发流程中的三大角色】

产品负责人（Product Owner）

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

流程管理员（Scrum Master）

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

开发团队（Scrum Team）

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

如何进行Scrum开发？

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

TDD 测试驱动开发

TDD，所谓测试驱动开发，那么一定是测试现行。TDD的过程中，我们需要的是专注于一个需求的开发，直到测试通过。这里我说针对一个需求，我想强调的，这里的测试，应当是不依赖于实现的系统测试，而不是单元测试。否则，TDD将难以展开。

大多数情况下，开发者会先开发再测试，很可能出现的一种情况是，过程中一系列的单元测试都是通过的，但最终的功能依旧无法保证，这时再开展系统测试，可以说是比较耗费时间的，毕竟，原本你的目标可以变成：通过眼前这一项测试。

先这么多吧~期待后面会有更多不一样的感受。