课件

传统的软件开发模式

随着互联网技术和应用的迅速发展，软件开发面临着需求频繁变化和快速交付的挑战，在这种情况下，人们开始尝试一种新型的敏捷开发方法。敏捷方法采用增量和迭代的开发过程，强调团队紧密的协作，这种方法已经取代了传统的瀑布模型，被众多的软件企业广泛的应用。

传统的瀑布模型是最典型的预见性开发方法，它要求需求在开发初期就完全确定，并且在整个过程中很少变化，整个开发过程是计划驱动的，严格按照需求、设计、编码、测试、维护的步骤，顺序展开。

软件开发之道

软件开发是否可以实现一个完整、详尽的计划，软件项目能否预见考虑到所有的风险呢？由于软件是要解决从未解决的问题，因此项目中存在难以预知的所有内容和风险！

需求是不确定的，如果一开始我们是一个预想的结果，并且是按照详尽的计划来执行的话，那么最终产生的产品往往不是用户需要的。软件开发应该是一个逐步认知和明晰的活动，通过不断的逼近，最终产生用户满意的产品。

软件开发到底是要获取一些更有价值的交付产品，还是只是按照计划完成工作内容？显然应该更专注于交付的价值，也就是说：

高质量的交付产品是最重要的；
这个产品不是一次构建形成的，而是需要经过迭代演进来形成的；

互联网时代的软件开发

互联网时代是一个快鱼吃慢鱼的时代，快速地推出产品才能够占领市场的先机。

在互联网时代，软件开发具有以下特点：

用户的变化和对创新的要求是非常高；
软件的产品要追求创新；
要快速地响应用户的变化；
需求不确定性高；
要关注用户行为；

敏捷开发方法

敏捷开发是一种基于更紧密的团队协作，能有效应对快速变化需求，快速交付高质量软件的迭代和增量的新型开发方法。

它强调：

更紧密的团队协作；
关注可工作的软件产品；
基于实践而非基于理论的开发方法；

敏捷方法强调适应而非预测，由于软件需求很难预测，按预测产生的结果往往不是用户需要的产品，所以软件开发应该是一个自适应的跟踪过程。通过适应和逼近，最终产生角户满意的产品。

敏捷宣言

2001 年 2 月，17 位软件从业者，在美国的一个滑雪圣地举行了为期三天的会议，主要是讨论广大开发人员对软件开发的共同见解，这次会议的主要成果是决定使用敏捷这个术语来表达共同性。相对于瀑布模型的僵硬化的过程，敏捷更加强调灵活和快速。会议制定了敏捷宣言及其 12 项准则。

敏捷宣言只有短短的四句话：

「个体和交互」胜过「过程和工具」
「可以工作的软件」胜过「面面俱到的文档」
「客户合作」胜过「合同谈判」
「响应变化」胜过「遵循计划」

在 20 世纪 80 年代到 90 年代中期，过程改进的活动非常盛行，当时推出了 CMM 等诸多的质量标准体系，虽然这个体系在一定程度上改善了软件过程的质量，但是也造成了软件开发管理越来越僵化。实际上软件开发是一种创造性的活动，没有优秀的个人和团队的协作，再强大的方法和工具都是摆设。

传统的瀑布模型强调文档的作用，但是文档对于用户来说是不是真的有价值，应该说面面俱到的文档对于客户来说并不重要，用户需要的是一个能够运行起来、能够解决实际问题的、可以工作的软件。

面面俱到的文档对开发来说也不重要，谁也不愿意去读非常厚的上百页的文档。对开发来讲，最好的文档就是代码和团队。

第三句话客户合作胜过合同谈判，软件开发的目标是提供给客户满意的软件，只有客户才清楚什么样的产品是满足他的要求的，敏捷开发提倡客户和开发团队在一起密切地合作，经常性地提供反馈，通过短期的迭代尽早地沟通和反馈，把问题及早地暴露出来，从而避免了在后期造成更大的影响。

第四句话响应变化胜过遵循计划，计划赶不上变化，敏捷项目承认开发过程中具有不确定性，因此不会在开发的初期制定长期复杂的完美计划，所有的开发过程都是建立在现实的反馈基础上，敏捷方法依据一些简单的实践和规则，通过经验性的一个过程控制来处理开发中的复杂问题，通过迭代和不断地响应变化来消除开发中的不确定性。

敏捷宣言的价值观就是自组织团队，与客户紧密协作，通过高度迭代式、增量式的软件开发过程，来响应变化，并在每次迭代结束时，交付经过测试的有价值的软件，胜过与客户确定合同后在初期制定并遵循基于活动的完整计划。在重量级过程和工具的指导下，通过完成大量文档进行知识传递，最后交付需求。

敏捷宣言的 12 个基本原则：

我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更一一即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交淡。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发速度，项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
坚持不解地追求技术卓越和良好设计，这将提升敏捷能力。
要做到简单，即尽最大可能减少不必要的工作，这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

传统开发 vs 敏捷开发

上图是瀑布模型与敏捷方法的主要区别。

瀑布模型假设需求是固定不变的，根据这个需求来估计所需要的资源和时间，制定完美的计划，整个的开发过程是完全按照计划来驱动的。

敏捷方法是认为需求是不确定的，它是在固定的时间和资源范围内，来估计出所需要实现的产品特性，通过价值的驱动来实现用户需要的功能。

好的架构（产品）是长出来的，而不是设计出来的。传统的开发方法虽然产生了很多设计的文档，但最终交付的产品是很难满足客户需求的。而敏捷开发方法是在开发过程中构建、演化，逐渐地逼近最终交付的用户满意的产品。

敏捷开发方法

应该说，敏捷方法是一组轻量级开发方法的总称，它包含了许多具体的开发过程和方法，在这里面最有影响的两个方法就是极限编程和 Scrum 开发方法。

Scrum 方法更加偏重项目管理实践，它规定了产品订单、各种会议以及开发这个人员的角色。

极限编程则是偏重编程的一些实践活动，包括重构、测试驱动的开发、结对编程等。这些实践在后面的课程中讲解。

Scrum 方法

Scrum 于 1995 年由 Ken Schwaber 和 Jeff Sutherland 博士共同提出，是一种应用很广泛的敏捷开发方法，目前已被众多软件企业广泛使用，如 Yahoo、Microsoft、Google、Motorola、SAP、IBM 等。

这个单词的英文含义是橄榄球运动中的一个专业术语，表示争球的动作。把一个开发过程命名为 Scrum，就是形容开发团队在开发一个项目的时候，所有的这个团队成员能够像打橄榄球一样，迅速、富有战斗的激情，你争我抢的完成进攻，通过一个逐步逼近的方式取得最后的胜利。

Scrum 框架

Scrum 是一种兼具计划性与灵活性的敏捷开发过程，它把整个开发过程划分为若干个更小的迭代，每一个迭代周期称为一个冲刺（Sprint）。

首先产品经理根据用户需求和市场需要，提出一个按照商业价值进行排序的客户需求列表，也就是产品订单。在每一个迭代的开始，迭代规划会议要从这些产品订单中挑选出一些优先级最高的故事，形成迭代的冲刺任务，一般一个冲刺周期是两到四周。在迭代过程中，会进行每日战略会议，检查每天的进展情况，在迭代结束的时候就会产生一个可运行的交付版本，由项目的多方人员参加这个版本的演示和回顾的会议，最终决定这个版本是否达到了发布的要求。

Scrum 迭代开发

Scrum 迭代开发是把整个软件生命周期分成多个小的迭代（一般 2~4 周），每一次迭代就是一个小的瀑布模型，包括需求分析、设计、实现和测试等活动，结束时都要生成一个稳定和被验证过的软件版本。

强调一下迭代开发的关键要点：

每一次迭代都建立在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。
每次迭代要邀请用户代表验收，提供需求是否满足的反馈。
在一次迭代中，一旦团队作出承诺，就不允许变更交付件和交付日期，也就是说，在一次迭代中需求是不发生变化的；如果发生重大变化，产品负责人可以中止当次迭代。
在迭代中可能会出现“分解”和“澄清”，但是不允许添加新工作或者对现有的工作进行“实质变更”。
对于“分解”和“澄清”，如果存在争议，那么将其认定为变更，放到产品订单中，下一次迭代再考虑。

敏捷开发应用

敏捷开发方法已经成功地应用于诸多的软件企业之中，ISO 9000 (09版) 标准、2000年美国军方软件开发标准 (DOD 5000.2) 和 2013 年发布的新版 PMBOK 也把敏捷方法作为新增内容，应该说，敏捷方法正在走向成熟，并在实践的基础上获得了进一步的更大的发展。