讲课视频在线视频

第二周第三节 敏捷开发过程

随着互联网技术

和应用的迅速发展

软件开发面临着需求频繁变化

和快速交付的挑战

在这种情况下

人们开始尝试一种

新型的敏捷开发方法

敏捷方法采用增量

和迭代的开发过程

强调团队紧密的协作

这种方法已经取代了

传统的瀑布模型

被众多的软件企业

广泛地应用

传统的瀑布模型

是最典型的预见性开发方法

它要求需求在开发初期

就完全确定

并且在整个过程中

很少变化

整个开发过程是计划驱动的

严格按照需求 设计

编码 测试 维护的步骤

顺序展开

那么软件开发是否可以实现

一个完整详尽的计划

软件项目能否预见考虑到

所有的风险呢

由于软件

是要解决从未解决的问题

因此项目中存在

难以预知的所有内容和风险

需求是不确定的

如果一开始

我们是一个预想的结果

并且是按照详尽的计划

来执行的话

那么最终产生的产品

往往不是用户需要的

软件开发应该是一个逐步认知

和明晰的活动

通过不断地逼近

最终产生用户满意的产品

软件开发到底是要获取一些

更有价值的交付产品

还是只是按照计划

完成工作内容

显然 应该更专注于交付的价值

也就是说

高质量的交付产品

是最重要的

而这个产品

不是一次构建形成

是需要经过迭代演进来形成

互联网时代

是一个快鱼吃慢鱼的时代

快速地推出产品

就能够占领市场的先机

在互联网时代

用户的变化和对创新的要求

是非常高的

软件的产品要追求创新

要快速地响应用户的变化

敏捷开发

就是一种有效应对快速变化需求

快速交付高质量软件的迭代

和增量的新型开发方法

它强调更紧密地团队协作

关注可工作的软件产品

这是一种基于实践

而非基于理论的开发方法

敏捷方法

强调适应而非预测

由于软件需求很难预测

那么按照预测产生的结果

往往不是用户需要的产品

所以软件开发

应该是一个自适应的跟踪过程

通过适应和逼近

最终产生用户满意的产品

2001年2月 17位软件从业者

在美国的一个滑雪圣地

举行了为期三天的会议

主要是讨论广大开发人员

对软件开发的共同见解

这次会议的主要成果

是决定使用敏捷这个术语

来表达共同性

相对于瀑布模型的僵硬化的过程

敏捷更加强调灵活和快速

会议制定了敏捷宣言

及其12项准则

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

个体和交互 胜过过程和工具

可以工作的软件

胜过面面俱到的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

在20世纪80年代

到90年代中期

过程改进的活动非常盛行

当时推出了CMM等

诸多的质量标准体系

虽然这个体系在一定程度上

改善了软件过程的质量

但是也造成了软件开发管理

越来越僵化

实际上软件开发

是一种创造性的活动

没有优秀的个人和团队的协作

再强大的方法和工具都是摆设

传统的瀑布模型强调文档的作用

但是文档对用户来说

是不是真的有价值

应该说面面俱到的文档

对于客户来说并不重要

用户需要的是一个能够运行起来

能够解决实际问题的

可以工作的软件

面面俱到的文档

对开发来说

也不重要

谁也不愿意去读非常厚的

上百页的文档

对开发来讲

最好的文档就是代码和团队

第三句话客户合作

胜过合同谈判

软件开发的目标

是提供给客户满意的软件

只有客户才清楚什么样的产品

是满足他的要求的

敏捷开发

提倡客户和开发团队

在一起密切地合作

经常性地提供反馈

通过短期的迭代

尽早地沟通和反馈

把问题及早地暴露出来

从而避免了在后期

造成更大的影响

第四句话

响应变化胜过遵循计划

计划赶不上变化

敏捷项目承认

开发过程中具有不确定性

因此不会在开发的初期

制定长期复杂的完美计划

所有的开发过程

都是建立在现实的反馈基础上

敏捷方法

依据一些简单的实践和规则

通过经验性的一个过程控制

来处理开发中的复杂问题

通过迭代和不断地响应变化

来消除开发中的不确定性

敏捷宣言的价值观就是

自组织团队 与客户紧密协作

通过高度迭代式

增量式的软件开发过程

来响应变化

并在每次迭代结束时

交付经过测试的有价值的软件

胜过与客户确定合同后

在初期制定并遵循基于活动的

完整计划

在重量级过程和工具的指导下

通过完成大量文档

进行知识传递 最后交付需求

敏捷宣言的12个基本原则强调

尽早和持续的交付有价值的软件

欢迎对需求提出变更

交付的周期越短越好

用户应该和开发人员

在一起工作

要善于激励团队成员

要面对面地进行交流

可用的软件

是衡量进度的主要指标

要保持恒久稳定的进展速度

坚持不懈地追求技术卓越

和良好的设计

要做到简单

团队应该是自组织的

要定期的反省

并相应地调整其行为

这里给出了瀑布模型

与敏捷方法的主要区别

瀑布模型假设需求是固定不变的

根据这个需求

来估计所需要的资源和时间

制定完美的计划

整个的开发过程

是完全按照计划来驱动的

敏捷方法是认为

需求是不确定的

它是在固定的时间和资源范围内

来估计出所需要实现的产品特性

通过这个价值的驱动

来实现用户需要的功能

好的产品是长出来的

不是设计出来的

传统的开发方法

虽然产生了很多设计的文档

但最终交付的产品

是很难满足客户需求的

而敏捷开发方法

是在开发过程中构建 演化

逐渐地逼近最终交付的

用户满意的产品

应该说敏捷方法

是一组轻量级开发方法的总称

它包含了很多具体的开发过程

和方法

在这里面最有影响的两个方法

就是极限编程和Scrum开发方法

Scrum方法

更加偏重项目管理实践

它规定了产品订单

各种会议

以及开发这个人员的角色

极限编程

则是偏重变成的一些实践活动

包括重构 测试驱动的开发

结对编程等

这些实践我们会在后面的课程中

进行详细地介绍和练习

Scrum是一种应用很广泛的

敏捷开发方法

这个单词的英文含义

是橄榄球运动中的一个专业术语

表示争球的动作

把一个开发过程命名为Scrum

就是形容开发团队

在开发一个项目的时候

所有的这个团队成员

能够像打橄榄球一样

迅速富有战斗的激情

你争我抢完成进攻

通过一个逐步逼近的方式

取得最后的胜利

Scrum是一种兼具计划性

与灵活性的敏捷开发过程

它把整个开发过程

划分为若干个更小的迭代

每一个迭代周期称为一个冲刺

Sprint

首先产品经理

根据用户需求和市场需要

提出一个按照商业价值

进行排序的客户需求列表

也就是产品订单

在产品迭代的开始

迭代规划会议

要从这些产品订单中

挑选出一些优先级最高的故事

形成迭代的冲刺任务

一般一个冲刺其周期是两到四周

在迭代过程中

会进行每日战略会议

检查每天的进展情况

在迭代结束的时候

就会产生一个可运行的交付版本

由项目的多方人员

参加这个版本的演示

和回顾的会议

最终决定这个版本是否达到了

发布的要求

应该说

Scrum迭代开发

是把整个软件生命周期

分成多个小的迭代

每一次迭代

就是一个小的瀑布模型

它包括了需求 设计 实现

和测试等活动

在每一次迭代的时候

是要生成一个稳定的

和被验证过的软件的版本

那么需要强调的是

每一个迭代都要建立在

稳定的质量基础之上

在一次迭代的过程里面

是不允许变更交付的产品

和交付的日期的

也就是说在一次迭代中

需求是不发生变化的

如果产生了相应的变化

那么就要进行分解和澄清

如果存在这个很大的争议

就把它看成一个变更

放到下一个产品的订单

再进行考虑

敏捷开发方法已经成功地

应用于诸多的软件企业之中

ISO9000

美国军方软件开发标准

和2013年发布的新版PMBOK

也把敏捷方法作为新增的内容

应该说

敏捷方法正在走向成熟

并在实践的基础上

获得进一步的更大的发展