当前课程知识点：软件工程 > 第6章 敏捷开发与配置管理 > 6.1 敏捷开发之Scrum > 敏捷开发之Scrum
Scrum是目前最流行
也是最有效的一种敏捷项目
管理方法
已经被许多知名的软件企业
所采用
这个英文单词的意思
是橄榄球运动的一个专业术语
表示争球的动作
用在软件开发上
它象征着开发团队
在开发软件的时候
所有的人都像打橄榄球一样迅速
而富有战斗激情
你争我抢 完成任务
并且通过逐步逼近的方式
取得最后的胜利
在Scrum框架中
整个开发过程是由若干个
很短的迭代周期所组成
一个短的迭代周期
称为一个Sprint
Scrum是通过以下过程
来实现产品的迭代开发
首先产品经理
根据用户需求和市场需要
提出一个按照商业价值
进行排序的客户需求列表
在每一个迭代的开始
开发团队要召开迭代计划会议
从这个列表中
挑选出一些优先级最高的条目
形成迭代的任务
在迭代开发过程中
要进行每日站立会议
检查每天的进展情况
在迭代结束的时候
就会产生一个可运行的交付版本
由项目的相关人员
参加产品的演示和回顾会议
来决定这个版本
是否达到了发布的要求
一个Sprint是指一个
1到4周的迭代
现在很多的团队采用2周
作为一次迭代
像一些市场变化快
竞争激烈的领域
比如说互联网或移动互联网领域
有可能使用一周的迭代
Sprint在整个开发过程中
是保持固定的时间长度
结束的时候
会产生一个完成的
可运行的潜在可发布的产品增量
在一个迭代的执行过程中
它的实现目标 质量和验收标准
都是不允许变化的
除非迭代的目标
失去了价值和意义
比如说 公司的发展方向
或者市场技术等情况发生了变化
这个时候就应该取消迭代
不过由于迭代的周期非常短
这种情况一般也很少发生
Scrum框架包括三个部分
开发团队角色
开发制品和开发活动
首先来看开发团队角色
主要包括产品负责人
Scrum主管和团队成员三种类型
产品负责人代表客户
决定产品的需求和优先级
它是开发团队
对于需求的唯一诉求人
产品负责人的主要职责包括
确定产品的功能
负责维护产品的需求列表
决定产品的发布日期和发布内容
为产品的投资回报负责
要根据市场价值
确定需求的优先级
在每个迭代开始前
调整功能和功能优先级
在迭代结束的时候
要验收开发团队的工作成果
Scrum主管作为团队领导
与产品负责人密切合作
及时为团队成员提供帮助
使得团队免予外界的干扰
它的主要职责是直接管理项目
要知道什么任务已经完成
哪些任务已经开始
哪些新的任务被发现
以及哪些估算可能已经发生变化
要保证开发过程按照计划进行
组织每日站立会议
迭代计划会议 迭代评审会议
和迭代回顾会议
要引导团队正确地应用敏捷实践
保证团队资源完全使用
和高效运作
要促进团队成员之间的良好合作
解决团队开发中的障碍
作为团队和外部的接口
屏蔽外界对团队成员的干扰
Scrum团队
负责在每个迭代中
把产品需求转化为潜在的
可交付的功能增量
它的特点是
团队的规模控制在5到9人
如果小于5人
团队的生产力会下降
有可能会受到技能的限制
从而导致无法交付
可发布的产品模块
如果成员多于9人
那么成员之间
就需要太多的协调和沟通
对于大型项目来说
可以采用多个小的Scrum团队
每个团队派出代表
进行团队之间的协调和沟通
团队是跨职能的
团队成员必须具备交付产品增量
所需要的各种技能
比如说编程 质量控制 业务分析
架构 用户界面设计
或数据库设计等
在Scrum团队中
没有头衔的概念
每一个人
都必须尽心尽力完成迭代目标
团队成员要全职工作
而且是自我组织和管理的
成员之间协调配合
提高整个开发效率
最终保证每一个迭代的成功
自组织团队
是敏捷软件开发的基本观念
它是指团队被授权自己管理
他们的工作过程和进度
并且由团队决定如何完成工作
具体说来
就是团队自己进行任务分配
自己做技术决策
在确保目标的前提下
制定自己的行为准则
团队要有义务保持过程的透明性
要监督和管理自己的过程和进度
Scrum制品主要包括产品订单
也称产品待办事项
迭代订单和燃尽图
产品订单
是一个从客户价值角度理解的
有优先级顺序的产品功能列表
产品订单中
包含开发和交付成功产品
所需要的所有条件和因素
产品订单的条目
可以是功能需求
也可以是非功能需求
还可以是主要的技术改进目标
比如说 用java代替C++重写系统
以及已知的缺陷
比如说 分析并修复
订单处理脚本的错误等等
迭代订单是团队承诺的
在当前迭代要完成的任务列表
这些任务是通过选取产品订单项
并进一步细化和分解形成的
其目的是将产品订单项
转化为潜在的可交付的产品增量
对于简单情况
可以直接把订单项作为任务分配
在复杂情况下
就需要进一步把订单项
分解成一系列
更细致的开发任务
如何选择产品订单项
取决于它的优先级
以及开发团队
完成开发所需要花费的时间
选择哪些订单项
以及多少项是由开发团队
自己来决定
可工作产品
是迭代开发的产出结果
它是一个可以交付的产品增量
可交付的标准是在迭代初期
提前设定的
每一次迭代都应该是一个
可运行的版本
产品负责人
负责产品订单的内容 可用性
和优先级
产品订单永远都不会是完整的
最初它只是列出一些最基本的
和非常明确的需求
这些需求
至少要足够一个迭代的开发
随着开发团队
对产品和用户的了解
产品订单在不断演进
所以产品订单是动态的
它经常发生变化
以保证产品更加合理
更具有竞争性和更有用
产品订单条目
是按照优先级进行排序
优先级主要是由商业价值
风险和必要性来决定
优先级高的条目
需要优先进行开发
优先级越高 条目就越详细
越低就越概括
使用用户故事
来描述产品订单条目
是一个非常有效的实践
用户故事是从用户的角度
来描述他所期望得到的功能
这个表列出了一些
关于网上订购商品的用户故事
这些故事描述了作为顾客
注册 搜索 浏览和购买商品的
一系列功能
以及作为工作人员维护商品信息
和查看订单的功能
对于迭代过程中
所有要完成的任务
可以使用任务板直观地进行展现
在迭代开发中
任务板是在不断地更新的
如果某个开发人员
想到了一个任务
他就可以把这个任务写下来
放在任务板上
在每日站立会议期间或者之后
如果估计发生了变化
任务会根据变化
在任务板上进行相应的调整
任务板有电子和实物两种形式
对于远程开发团队来说
电子版是一个有效的方式
对于集中在一起
面对面工作的团队来说
实物板更利于沟通
燃尽图是以图形方式
显示迭代过程中
累计剩余的工作量
它是一个反映工作量
完成状况的趋势图
其中Y轴代表的是剩余工作量
X轴代表的是迭代的工作日
在迭代开始的时候
开发团队会标识和估计
这一个迭代需要完成的详细任务
所有这一个迭代中需要完成
但是没有完成的任务工作量
是累计的工作量
Scrum主管
会根据进展的情况
每天更新累计工作量
如果在迭代结束时
累计工作量降低到0
迭代就成功地结束
现在图上显示了三条曲线
绿色线 代表这个团队计划良好
所有的故事都已经完成
接近理想情况
紫色的线表明该团队
也完成了目标
但是有可能没有主动地
去更新数字
也有可能是前期有点拖延
后期比较赶工
蓝色线表明该团队执行不太理想
在迭代时间截止时
并没有完成所有任务
Scrum是通过以下活动
来管理整个项目开发过程的
迭代计划会议
是计划即将开始的迭代开发
每日站立会议
用来检查迭代过程的工作进展
迭代评审会议
用来检验所发布的工作成果
迭代回顾会议是回顾和总结
已经完成的迭代过程
Scrum项目包括两级规划
一个是发布规划
它对整个产品发布过程进行展望
定义用户故事
并进行优先级划分
估算开发的规模
以及评估开发团队的速度
制定出整个产品的发布计划
另一个是迭代规划
只对一次迭代进行展望
确定迭代的目标
并且选择用户故事
把故事分解和细化成任务
并进行时间估算
迭代计划会议
是在每次迭代开始时召开
它的目的
是选择和估算本次迭代的工作项
整个会议分成两个部分
第一部分
是以需求分析为主
确定到底要做什么
也就是从产品订单中
选择和排序本次迭代
需要实现的订单条目
第二部分
是以设计为主
确定要怎么做
由开发团队决定系统的设计方案
和工作内容
迭代计划会议需要整个团队参加
产品负责人逐条讲解
最重要的产品功能
开发团队共同来估算
故事所需要的工作量
直到本次迭代的工作量
达到饱和为止
产品负责人参与讨论
并回答与需求相关的问题
但是并不干涉估算的结果
在迭代开发过程中
开发团队通过每日站立会议
来确认他们的工作进展情况
评估是否可以实现迭代的目标
这个会议每天在同样的时间
和同样的地点召开
每个团队成员
都需要回答三个问题
上次例会之后完成了什么
遇到了什么困难
下次例会之前计划要做什么
每日站立会议中
可能有简要的问题澄清和回答
但是不应该有任何话题的讨论
讨论可以下去单独进行
这个会议并不是向任何人做汇报
而是开发团队
内部的一个沟通会议
来帮助大家快速地发现问题
促进团队的自组织和自管理
每日站立会议要求简短
通常不超过15分钟
迭代评审会议
是在迭代结束的时候召开
开发团队和相关人员
一起来评审迭代产出的结果
一般情况下
开发团队会演示产品的增量
让用户代表
尝试使用这些新功能
来听取用户
对产品功能的一个反馈
整个小组也会讨论
他们在迭代中观察到了什么
有哪些新的产品想法
产品负责人会对未来
做出一个最终的决定
并适当地调整产品订单条目
在每次迭代完成之后
还要举行一个迭代总结会
会上所有团队成员
都要反思这个迭代过程
要识别出哪些做得好
哪些做得不好
找出潜在的可以改进的事项
为将来的改进制定计划
需要注意的是
要抓重点问题
每次也就是1-3个关键问题
做出可行的解决方案
这里可行的含义
是方法简单 影响范围小 见效快
再一个目标不要太激进
要现实可行 积少成多
好 Scum方法的主要内容
就介绍到这里
对于参加课程实验项目的团队
希望能够尝试着使用这种方法
来管理自己的项目
体会和掌握敏捷开发管理方法
-1.1 软件无处不在
--讲课视频
-1.2 软件的本质特性
--讲授视频
-1.3 软件工程的产生与发展
--讲授视频
-1.4 软件工程的基本概念
--讲授视频
-1.5 软件质量实现
--讲授视频
-1.6 业界人士谈软件工程
-测验题--作业
-讨论题
--讨论题
-作业题
--第一张 作业题
-2.1 编程过程与规范
--讲课视频
-2.2 良好的编程实践
--讲课视频
-2.3 Python集成开发环境
--讲课视频
-2.4 代码静态检查
--讲课视频
-2.5 代码性能分析
--讲课视频
-2.6 结对编程实践
--讲课视频
-2.7 刘贺谈软件工程
--讲课视频
--讨论
-测验题--作业
-作业题
--第二章 作业题
-3.1 单元测试概述
--讲课视频
-3.2 黑盒测试方法
--黑盒测试方法
-3.3 白盒测试方法
--基本概念
--代码覆盖标准
--基本路径测试
-3.4 单元测试工具
--单元测试工具
--html
-测验题--作业
-作业题
--第三章 作业题
--作业题附件
-4.1 软件过程
--讲课视频
-4.2 软件过程模型
--讲课视频
-4.3 敏捷开发过程
--讲课视频
-4.4 微软公司开发过程
--邹欣经理自我介绍
--微软开发过程之一
--微软开发过程之二
-测验题--作业
-5.1 团队组织与管理
--讲课视频
-5.2 项目沟通管理
--讲课视频
-5.3 软件项目计划
--讲课视频
-5.4 软件项目估算
--讲课视频
-测验题--作业
-讨论题
--讨论
-6.1 敏捷开发之Scrum
-- 敏捷开发之Scrum
--html
-6.2 用户故事与估算
--讲课视频
-6.3 团队协作工具Tower
-6.4 配置管理
--讲课视频
-6.5 配置管理工具Git
--讲课视频
-测验题--作业
-作业题--作业
-7.1 需求工程师
--讲课视频
-7.2 需求定义
--讲课视频
-7.3 需求的类型
--讲课视频
--讲课视频（2）
-7.4 需求工程过程
--讲课视频
-7.5 需求的主要来源
--讲课视频
-7.6 需求获取技术
--讲课视频
--讲课视频二
--讲课视频三
-7.7 撰写需求文档
--讲课视频
-测验题--作业
-讨论题
--讨论
-8.1 用例建模概念
--讲课视频
-8.2 用例建模过程
--讲课视频
-8.3 用例建模精讲
--讲课视频
-8.4 建模工具介绍
--讲课视频
-8.5 微信抢票应用案例
--讲课视频
-测验题--作业
-讨论题
--讨论
-9.1 面向对象分析
--讲课视频
-9.2 CRC卡片分拣法
--讲课视频-1
--讲课视频-2
-9.3 面向对象设计
--讲课视频-1
--讲课视频-2
-9.4 类图建模
--讲课视频-1
--讲课视频-2
-第9章 面向对象分析与设计--测验题
-讨论题
--讨论
-10.1 顺序图概念
--讲课视频
-10.2 顺序图建模
--讲课视频
-10.3 顺序图风格
--讲义视频
-10.4 状态建模
--讲课视频
-10.5 状态图
--讲课视频
-10.6 状态图精讲
--讲义视频
-测验题--作业
-讨论题
--讨论
-11.1 软件体系结构概念
--讲授视频
-11.2 软件设计原则
--讲授视频
-11.3 软件体系结构风格（一）
--讲授视频
-11.4 软件体系结构风格（二）
--讲授视频
-11.5 软件体系结构风格（三）
--讲授视频
-11.6 软件设计过程
--讲授视频
-11.7 Web系统架构设计
--讲授视频
-11.8 数据库选择策略
--讲授视频
-测验题--作业
-作业题
--html
--html
--html
-作业题--作业
-12.1 交互设计概述
--讲授视频
-12.2 交互设计目标
--讲授视频
-12.3 GUI设计原则
--讲课视频
-12.4 KLM效率模型
--Video
-12.5 Fitts定律
--讲授视频
-12.6 交互设计过程
--讲授视频
-测验题--作业
-13.1 软件测试概念
--讲课视频
-13.2 软件测试类型
--讲课视频
-13.3 软件功能测试
--讲课视频
-13.4 软件性能测试
--讲课视频
-测验题--作业
-14.1 软件部署与交付
--讲课视频
-14.2 软件演化与维护
--讲课视频
-测验题--作业
-第一部分：基础知识
-第二部分：编程与测试（选做）
