1.5 敏捷开发方法在线视频

大家好 我是北京理工大学计算机学院车海莺

今天来给大家一起分享一下关于敏捷开发的相关内容

今天 我们会先看一下敏捷开发的相关概念

然后以scrum模型敏捷开发的

一个模型为代表

来看一下敏捷开发模型是怎么样进行的

首先 我们看一下敏捷开发相关的一些概念

在看敏捷开发之前

我想跟大家一起回顾一下瀑布模型

大家都知道瀑布模型从

计划 需求分析 设计 开发 测试

这样子顺序下来

那么 敏捷开发强调了哪些样的原则呢

敏捷开发模型强调

个人和他们之间的交流

胜过了开发过程和文档

可运行的软件胜过了宽泛的文档

客户合作胜过了合同谈判

对变更的良好响应

胜过了按部就班的遵循计划

虽然右边的各项开发过程和工具

文档 合同谈判 遵循计划都很有价值

但是敏捷开发的

倡导者认为左边的各项具有更大的价值

那么 什么是敏捷呢

敏捷是有效的 快速 灵活的响应变化

利益相关者包括经理客户

最终用户之间的有效沟通

将客户作为开发团队的一部分

充分的参与到整个项目的开发过程

另外 敏捷强调要组建高度自主的项目团队

最重要的是 敏捷开发 强调于

敏捷开发强调 快速交付给客户可运行的

软件增量

在敏捷开发中的变更成本

这张图显示了纵轴 显示的是开发成本

横轴是开发进度的日程

那么我们的敏捷开发的变更成本

粉色的曲线

显示了使用敏捷过程的变更成本

其中

黑色显示的是使用传统软件过程的变更成本

还有一个虚线显示的是

使用敏捷开发的理想的变更成本

随着开发进度的时间的推移

我们对软件进行变更的时候

如果我们使用传统的软件过程

先进行计划 需求分析 设计

都做好之后才进行开发

那么在后期

我们进行变更的时候 代价就非常大

因为我要对前期的

需求分析 设计都要进行变更

而且 局部的变更

可能还会影响到其他部分

所以 图中的黑色实线的曲线

显示的是使用传统的软件过程

比如瀑布模型

进行变更的时候

随着时间的越向后发展

变更的代价

变更的开发成本就越高

那我们使用敏捷开发的理想的变更成本是

随着开发的推移

我们的变更成本会

保持在一个相对稳定的水平上

但是 真实的敏捷开发变更成本

也同样会随着时间的向后进展

软件的逐步完成

软件后期进行变更的成本

也会逐渐的增加

只不过跟传统的软件过程相比

敏捷开发在后期的变更成本

要远远低于传统过程开发的

变更成本

在敏捷过程中

由用户所需的应用场景来驱动

从认识一个问题到计划

这个时间比较短

而且敏捷开发全部都使用增量式的开发策略

强调交付多个软件增量的版本

而且能做出适应性的变更

在敏捷开发当中

强调有很多敏捷的原则

首先 我们优先先要做的是

要通过尽早

持续交付有价值的软件来使客户满意

即使在开发的后期

也是要欢迎需求的变更

我们要通过敏捷的过程

使得客户通过变更来取得竞争的优势

敏捷开发经常是交付可运行的软件

交付的间隔可以从几个星期到几个月

交付的时间间隔越短越好

另外 在整个项目开发期间

业务人员 开发人员必须天天都在一起工作

另外 要围绕着有个性的个人

来构建项目 给他们提供所需的

敏捷开发的环境和支持

并且信任他们能够完成工作

在团队内部

最富有效果和效率的信息沟通和传递的方式

就是面对面的交谈

另外 可运行的软件是进度的首要度量标准

敏捷过程倡导可持续的开发速度

责任人 开发者和用户

应该能够长期保持稳定的开发速度

而且我们要不断的关注

优秀的技能和好的设计来增强敏捷的能力

另外 我们要强调简单是不必要做的

工作

最大化的艺术就是必要的

比如 当某个问题我们已经沟通清楚的时候

我们完全可以减少不必要的文档工作

使得我们不必要的工作最大限度的降低

另外

最好的架构需求和设计出自于自组织的团队

出自于有自我能动性的团队

来不断的优化我们的架构

和需求 还有设计

另外 还有一点重要的是 每隔一段时间

敏捷团队会自我反省

如何才能改进我们的工作

如何才能更有效的工作并相应调整自己的行为

在敏捷开发方法当中

我们非常重视人的因素

因为所有的软件都是由人的智慧所创造的

那么我们要是可以

充分发挥人的主观能动性和创造性

那我们的软件的质量就会有保障

构造可以满足人员及团队需求的过程模型

而非其他的可选的过程模型

也就是说

我们并不强调严格的按照什么过程模型

而是根据

人员和团队需求的特点来设计适合的过程模型

另外 团队成员以及团队本身

必须要具备以下的一些特点

首先 他要具备完成任务的基本能力

另外 团队要有共同的目标

在共同的目标下 团队要能够精诚合作

并且团队要有决策能力

当遇到一些模糊的问题的时候

要有自我的解决能力

并且团队要相互信任和尊重

这样才能增加团队的创造力和生产力

另外 团队需要自组织

减少不必要的组织和管理所带来额外的时间

和其他成本

那么 下面我们了解了这些概念之后

我们看一个典型的敏捷开发的模型

scrum模型

scrum这个词本身是职业橄榄球赛中

列阵争球的意思

像这张图中所显示的职业橄榄球赛中

两队球员正在进行列阵争球

那么由

Schwaber and Beedle提出的scrum

这个模型的基本特征是

开发活动由工作单元packets组成

测试和文档编制的工作要贯穿始终

发生于一个过程模式中的工作任务

我们称为一个冲刺

叫做sprint

这个冲刺的来源 来源于

我们待定项backlog中定义的一系列需求

在backlog中

我们要定义一系列要为客户开发的需求

其中每一个Sprint

就要完成一个或者几个需求

来构成的一个工作任务的单元

另外 scrum中要求例会时间要短

不要浪费会议的时间

另外 我们甚至可以站立着开会

为了节省时间并达到面对面的有效沟通

在规定的时间段内

把演示可演示的软件交付给用户

是敏捷开发模型最好的一个衡量办法

下面我们看一个视频

来介绍scrum模型

scrum模型和

瀑布模型进行对比

我们来看一下瀑布模型有哪些不足

我们知道瀑布模型是从

计划plan到构建 build

然后到测试test 然后到review

然后到deploy部署

也就是瀑布模型经历了

plan build test review和deploy这样一个过程

那么瀑布模型的不足是

通常我们需要数月甚至是数年

才能完成产品的交付

而且 在瀑布模型的最开始是计划阶段

所有的计划必须要在任何工作开始之前

就完成

那么我们在计划的时候

在项目的最开始阶段

我们还没有完全理解项目的

内容和项目的真正的要做的工作

我们就要进行计划

那么这样的计划通常也是不是十分准确的

那么我们的scrum方法

产品被分为几个小的部分

每一个部分大概需要1-3周的时间

每一个部分都要经过

plan build test和review

这样的一系列活动

那么每一系列活动就完成一个sprint

一个产品被分为很多个sprint

那么每完成一个sprint就

完成了一个软件增量

那么 通过刚才的视频

大家看到在scrum模型中

有三个重要的角色

product owner

它是需要在产品中需要定义产品的关键特征

第二个是leader in the team

是项目的领导

他要保护整个团队和过程

他还要负责召开会议

保证整个scrum的过程顺利进行

第三个角色就是

整个团队成员构成的team

团队由开发人员 测试人员等人员组成

大家精诚合作 共同来实现产品的交付

scrum模型有三个角色

还有三个artifact

有三个要完成的项目

第一个是产品经理要创建特征优先级列表

产品经理要列出所有的特征

在系统开发要完成的功能特征

也就是要完成的功能

这些功能要按照它的优先级

重要程度进行排序

这是第一个artifact

第二个artifact是

user story是用户故事

用户故事通常是按照这样的结构来构成的

作为一个用户

我需要什么什么什么功能

因为什么什么

按照这样的模板来描述用户故事

撰写用户故事

允许产品经理为团队确定细节的合适的数量

信眼来评估这个任务的规模

和描述特征的集合的方式

第三个artifact的呢

是我们的所有的sprint

在整个任务中待完成事项的进展

随着项目接近完成

接近尾声

我们要完成的

sprint的数量是慢慢的下降 趋近于零的

所以这个图叫做burndown chart

就是纵轴

描述了带完成的sprint的数量的变化

除了有三个角色 三个artifact

还有三个ceremonies

也就是在scrum过程当中

要做的三个形式化的会议

第一个是product owner

和scrum master

和整个team要开会来讨论用户故事

来讨论清楚用户故事的时候

我们才能够评估每个用户故事

和每个功能对应的规模

第二个ceremonies是日常会议

和团队进行简单的站立的日常会议

来讨论上次会议以来

我们已经完成了哪些工作

还有哪些工作正在进行

还有哪些遇到了障碍

遇到了困难

需要什么样的帮助来解决这些障碍和困难

这是第二个日常会议

最后一个就是在sprint快结束的时候

我们要做一个sprint的回顾和反省

sprint回顾和反省是

向 product owner 来展示

已经完成的工作的成果

并且讨论一下

下一步我们怎么做可以把过程进行改进

可以做得更好

所以我们整个的scrum的工作流程里面

包括三个重要的角色

三个重要的artifact

和三个ceremonies

那么现在这张图让我们回顾一下

整个scrum的工作流程

首先 我们的product owner

要定义一些个产品特征列表

然后根据我们的产品特征列表

生成了backlog

然后我们把backlog

定义一个一个的sprint backlog

然后我们会

以1-3周为一个周期来完成sprint

完成sprint之后

我们就把整个sprint交付给客户

最后 在sprint结束的时候

我们还要进行

回顾和反省

在回顾和反省当中

我们首先要向

product owner展示

我们已经完成的sprint是否满足了需求

另外 我们还要总结和分析

在这个sprint的开发过程当中

我们是否有一些个环节和地方

可以进一步的进行优化和改进

以便在下一个sprint和后期的工作当中

我们可以一种更高效 更优化 更合理的方式

进行sprint的开发

所以这张图就展示了整个scrum的这个过程模型

开始于一些backlog的这样的待定项

然后通过一轮又一轮的

sprint的完成

最终完成多个软件增量

然后完成整个产品的开发过程

在每一个sprint的冲刺的过程当中

每天24小时都要进行一个

daily meeting这样的会议

来讨论上一次会议到这次我们完成了什么

正在进行什么

还有哪些要完成 存在着哪些障碍

这个dailymeeting会议

也是一个很重要的环节

那么我们今天

关于scrum和敏捷开发的分享

关于scrum和敏捷开发的分享

就到这里 谢谢大家