Scrum敏捷软件开发过程.docx
- 文档编号:27575424
- 上传时间:2023-07-03
- 格式:DOCX
- 页数:46
- 大小:875.21KB
Scrum敏捷软件开发过程.docx
《Scrum敏捷软件开发过程.docx》由会员分享,可在线阅读,更多相关《Scrum敏捷软件开发过程.docx(46页珍藏版)》请在冰豆网上搜索。
Scrum敏捷软件开发过程
Scrum 敏捷软件开发过程
•什么是敏捷软件开发?
•敏捷方法的项目计划
•敏捷项目管理和传统项目管理
•为什么使用敏捷?
•Scrum 概述
•Scrum 的角色
•Scrum 实践和工作产品
•敏捷开发中的估计方法
•测试驱动开发
•Scrum 应用
•支持工具和模版
•一些常见的误解
敏捷开发方法
什么是敏捷软件开发?
•敏捷软件开发是软件项目的一个概念框架.
•有许多建立在敏捷概念上的方法,如 Scrum 和 Extreme Programming (XP).
•与僵化的、重量级的、官僚式的方法形成对照,比如瀑布模型(指纯粹形式的)
•最大限度地降低短期固定时间的迭代式软件的开发风险.
敏捷宣言(2001 年)
•人和交互胜过过程和工具.
•Individuals and interactions over processes and tools
•可以工作的软件胜过完备的文档.
•Working software over comprehensive documents
•客户协作胜过合同谈判.
•Customer collaboration over contract negotiation
•随时应对变化胜过遵循计划.
•Responding to change over following a plan
敏捷过程的限制
•敏捷软件开发过程包含过程、原则、工具,和最重要的-人
•因此:
诚信是基础
•没有过程能够对诚信进行有效地约束,诚信与否是有效实施敏捷过程的最大限制
1
使用敏捷方法的项目计划
“Sprintful” of top-
priority PBL to the
next Sprint
Sprint
Backlog
More accurate
estimates
as man hours
8
Short term planning (commitment by
May be
5
2
1
3
8
5
8
∑32
Long term planning (best guess at the moment):
Initial Size
Estimates
As Story Points
32 SP of functionality, Team Velocity 8 SP/Sprint 4 Sprints
Target Sprint for each PBL item set, feasible implementation
Order.
敏捷项目管理和传统项目管理
•传统项目管理:
•事先对整个项目进行估计、计划、分析
•反对变更; 变更需要重新估计、重新规划
•严密的合同来减少风险, 如果改变需求要走 CR 流程.
•项目作为一个“黑盒子”,对客户与供应商的可视性差.
•产品化和测试阶段是分离的.
•文档和计划驱动的方法.
•软件交付时间晚, 意识到风险的时间晚.
•敏捷项目管理:
•对整个项目做一个粗略的估计,每一次迭代都有详细的计划.
•鼓励变化, 客户价值驱动开发.
•信任和赋予权力;合约使变更变得简单,增加价值.
•客户和开发人员之间是紧密的连续的合作关系
•每次迭代都产生可交付的软件
•专注于交付软件.
•第一次迭代就可交付能工作的版本,风险发现的早.
为什么采用敏捷?
–预期的收益
•采用敏捷方法得当的话,可以:
•更加透明; 随时跟踪项目的状态和进展情况,及早发现问题和风险 .
•快速交付, 每次迭代都能交付可运行的软件.
•最高风险和最高优先级的需求,最优先进行开发.
•改善应对变更能力, 减少大量的重计划.
•改善项目沟通.
•更好的客户参与, 避免错误的假设.
•总之:
•提高了生产率; 减少“浪费”(不需要的文档,重复工作等),项目的每次迭代都有明
2
确的目标.
•提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结束产生可以运行的
软件.
•改善员工的满意度; 团队精神,减少官僚,能够规划和管理自己的工作,减少“恐慌”
,稳定的工作量(可持续的步伐).
敏捷方法何时有效?
•公司和客户一致认为应当使用敏捷方法,双方都能理解敏捷方法.
•敏捷方法对需求不完整以及经常变换的项目比较有效.
•项目可以划分成固定时间间隔的迭代, 并且可以冻结正在进行的迭代的范围
•公司和客户都有能力担当角色尤其是 Product Owner 和 Scrum Master.
•项目的人员结构能够分成 6 到 10 人的团队,最好每个工作地点一个小组.
•团队成员能够以自组织的方式工作.
•项目的合同允许变更.
•固定价格的项目可以使用敏捷,但应当尽量避免。
•最好在按时间和材料付费或者按月付费的项目中进行使用
•变更项目的范围不需要高级管理层的批准.
Scrum 概述
Scrum 概述(1/3)
•Scrum 是管理软件项目的一个轻量级的敏捷方法, 名字来源于橄榄球运动中的 scrum 过程
•简单,但高度的纪律性
•依赖迭代和增量的敏捷方法.
•Scrum 是一种工作管理的方法,不仅仅限于软件开发,可以用来管理其它活动.
•Scrum 不包含技术方法或实践.
Scrum 概述 (2/3) – 项目的阶段
•项目分成增量的迭代过程,在 Scrum 中称为迭代任务清单, 通常持续 2-4 周的时间.
•Sprint 的时间是限定好的; 不能从外部改变正在进行中的 sprint 持续时间和范围.
•每个 sprint 都可以产生可交付的迭代, 即测试过并具备文档的的功能点
•原则上, 当产品开发到一定程度时,如实现了足够的客户价值,项目可以在任何一个
sprint 后结束.
•如同任何项目,敏捷的项目有三个主要阶段:
•产品定义 (规划); 运行 Sprints 所需要的准备、规划、技术分析.
•执行 Sprints (执行):
在增量时间段内实现需求(产品需求清单).
•结束:
准备最终发布,结束项目
Scrum 概述 (3/3)
3
Daily Scrum meetings :
What did you do yesterday你昨天做了什
么
What will you do today?
你今天会做什么
What obstacles are in your way?
有什么障
碍在你的方式
Daily
Sprint Planning Meeting:
Next Sprint Goal下一个Sprint目标
Shippable
Product Increment
可交付的产品增量
Sprint
Retrospective
Sprint回顾
Sprint Backlog
Updated Product Backlog更新Product Backlog
Scrum 的流程
1、 将整个产品 Backlog 分解成 Sprint Backlog ,按照目前的人力物力条件可以完成的。
2、 召开 Sprint 计划会议,划分、确定这个 Sprint 内需要完成的任务,标注任务的优先级并分配给
每个成员。
注意这里的任务是以小时计算的,并不是按人天计算,长度不超过 8 小时。
3、 进入 Sprint 开发周期,每个 Sprint 迭代周期为连续 30 个日例日(2-4 周)。
在这个周期内,每天
需要召开每日 Scrum简会,时间为 15分钟。
在会议中每个团队成员仅就以下三点发言:
自上次
Scrum 会议后你做了什么?
从现在到下次 Scrum 会议的时间里你准备做什么?
你在工作中遇到了哪
些困难?
4、 整个 Sprint周期结束,召开 Sprint评审会议(Sprint review meeting),将成果演示给 Product
Owner ,该会议限定时间为 4 小时。
5、 团队成员最后召开冲刺回顾会议( Sprint retrospective meeting) ,总结问题和经验,该会议限定
时间为 3 小时。
6、这样周而复始,按照同样的步骤进行下一次 Sprint 。
Scrum 角色、实践和工作产品
Scrum 中的三种角色
•Product Owner- 产品所有者
•个人:
代表所有的干系人
•Scrum Master:
•个人:
负责指导过程的执行
•Scrum Team – Scrum 团队:
•承诺完成工作,向干系人交付产品价值
◆ Scrum 角色 – Scrum 团队
4
•Scrum 团队是 Scrum 的中心角色, 产品交付要依靠团队.
•Scrum 团队自我组织、自我管理
•Scrum 团队是职能交叉的, 包含产品交付的所有角色:
开发人员、测试人员、build managers,
文档编写, 界面设计人员.
•Scrum 团队中的角色是不分等级的; 不应当出现“我是开发人员我不作测试”.
•团队按照最有利于项目的原则来分担责任 (如组件的所有权等 ).
•敏捷是建立在信任和授权的基础上,因此团队是自发组织的,组员选择自己的任务,而不是
别人强制加以分配的.
•另一方面,Scrum 团队有交付的责任,他们需要能够自我激励和对工作目标进行承诺.
•团队最佳规模:
6-10 人
•主要职责
•参与迭代任务清单的创建
•执行为干系人创造价值的工作
•根据团队的承诺完成所需的各项任务
•将工作中的各项障碍迅速与 Scrum Master 进行沟通
•全面参与所有的各项会议
•更新任务状态
•自发选择任务
•标识任务的完成
•标识发现的新的任务
•与其它团队共同进行工作
◆ Scrum 角色 – Scrum Master
•Scrum Master 不是一个管理者,而是一个教练和推动者 - Scrum 团队是一种自发的组织,是
自我管理的.
•Scrum Master 的角色通常由项目组的成员担当,组长或者项目经理。
Scrum Master 应当是项
目中的成员.
•主要职责:
•评价过程的健康状况
•加强过程
•消除障碍
•促进过程改进
•支持团队开发
•Scrum Master 的主要工作是做决策、消除障碍,保证团队能顺利交付产品
•Scrum Master 还有如下责任
•与其它角色配合.
•训练团队,提高生产率.
•培训产品所有者和干系人,确保 Scrum 流程的执行
•确保一切工作按照既定的规范来运行.
•规划并进行必要的改进.
•推动会议的召开.
•维护障碍列表
•维护 Scrum 过程改进列表
•优秀的 Scrum Master 应当是专注的,、有决心的、有领导才能.
◆ Scrum 角色– Product Owner
•产品所有者代表投资方的利益,确保交付的产品与期望的一致 (提供更好的投资回报).
•Product Owner 决定产品具有哪些功能.
5
•Product Owner’s 的主要责任是创建和维护产品需求清单, 即管理项目的范围.
•Product Owner 不断的把产品需求清单按优先级进行排序,使得最重要的功能能优
先实现.
•对于团队来说,只有一个需求集。
所有的需求申请都归口到 Product Owner
•管理商业价值(投资回报)
•Product Owner 还有如下责任:
•计划项目的发布,什么时间、向什么人等.
•对每次 Sprint 的结果进行评审和批准
•参与 Scrum 会议
•迭代计划会议
•团队进展跟踪会议
•迭代评审和回顾会议
•能够随时回答团队工作中产生的各项和产品/业务相关的问题
•Product Owner 的角色一般由客户担当,作为服务提供商的公司无法设定优先级.
◆ Scrum 角色 – 客户与管理层
•客户和管理的角色是可选的,需要时才设立
•客户:
•是产品的最终用户
•通过 Product Owner 来设定对产品的期望
•把当前的业务传达给项目.
•管理层:
•公司高级管理层,代表公司在项目中的利益.
•通过 Product Owner 来传达公司的利益和优先级(priorities )
产品需求清单 Product Backlog
概论
•基本上,产品需求清单是为了实现产品的功能所需要的工作的列表,包括:
•功能方面的需求; 功能点.
•非功能方面的需求, 如性能改进.
•要修改的 Bug; 上一版本的已知错误.
•新技术, 如支持新的操作系统或者平台.
•问题; 日后的不确定项, 如新的功能.
•产品需求清单是不断完善的.
•Product Owner 在项目进行过程中可以随时更新:
增加、删除、修改功能,变更优先
级等.
•下一次迭代中要包含较高优先级的需求.
•产品需求清单也可称为 User Stories (用例) ,因为它们能够给产品的用户带来价值.
•在一次迭代中要能够实现产品需求清单,如果不能全部实现要进行分解.
构成
•Product Owner 负责创建最初的产品需求清单,一开始是不完整的.
•最初的清单应当包含足够的需求.
•清单应当包含多少需求, 取决于定价模型 (black-box, 更多的计划时间).
•产品需求清单来源于:
•客户; 标书, 需求规格说明等.
•Scrum 团队的想法; 增强型新功能等.
•现有产品的迭代增量; 已知错误, 技术问题等.
6
•比较好的做法是 Product Owner 、Scrum 团队、客户/管理以及其它相关方(如相关的 Scrum
团队)举行一次或者多次研讨会
•Scrum Master 或者 Product Owner 来促成会议的召开,必须要有人来做.
•要有效率、要围绕主题、 沟通良好 、避免不同的假设,
•承诺并且共通合作,确定优先级.
估计
•Scrum 团队对产品需求清单的每一项的规模提供初步的估计,通常采用事件点作为单位 Story
Points (模糊的).
•也可采用人天或者人小时作为单位,但容易混淆:
a) 实际的规模 b) 时间的单位.
•精确的估计值可以在 Sprint 规划时给出, 当前阶段没有足够的信息.
•规模的相对值才有意义.
•这个估计值有助于确定优先级;
优先级
•优先级是产品需求清单中的主要问题.
•优先级不但反映了客户的价值也反映了风险.
•产品所有者-PO 设定优先级.
•清单中的每一项的优先级是唯一的, 但可以对它们进行分类
•优先级可以在项目的任何时候进行更改; 如新的重要的功能可以直接给较高的优先级.
•确定优先级考虑:
•价值
•风险
•依赖关系
示例
ID, like in any
requirements
Priority
These will likely end
up in the first Sprint
版本发布计划
•在 Scrum 中,不是 每个 Sprints 都要发布一个版本.
•迭代的结果主要是要实现功能的演示, 不一定就是发布的版本.
•版本发布计划决定了每次迭代应当包含产品需求清单的哪些功能.
•根据现有的信息制定的项目总体的长期的计划.
•根据产品需求清单和团队的进度来决定 (实施的范围/迭代, e.g. in Story Points).
•Scrum 团队参与版本发布计划的制定; 架构、风险、依赖性决定了可行的实现顺序.
•版本发布计划很大程度上依赖于客户的时间表和发布周期,即什么时候客户的产品需要包含
我们的模块(交付物).
•版本发布计划不是一成不变的;每个迭代结束后都可以更改.
完成的定义
7
•当迭代任务清单上的任务都完成时,变为“已完成”状态
•定义“已完成”的含义是非常重要的, 例如:
•如何记录软件的变化.
•使用什么样的代码分析工具 ,发现的问题应当如何处理.
•进行了什么样的测试, 结果是如何记录的, 通过标准(如覆盖率、修正的错误)是什
么.
•定义“已完成”意味着定义质量上的需求.
•“已完成”是 0/1 变量:
完成或者未完成. 所有的任务(task)都完成了迭代任务才算完成.
•在第一个迭代开始之前应该定义好,因为它会影响工作量,而且必须文档化,这样团队和产
品所有者的理解是一致的.
•完成的范围随着团队的成熟程度会逐渐发生变化
计划
分析
架构
性能指标
试运行
代码评审
验收
设计
开发
测试
支持文档
集成
用户文档
完成的定义 - Example
•完成的定义
•遵循编码规范
•能在模拟器上演示
•使用 PCLint 进行静态代码分析
•具有 EUnit 测试套件的通过率 和执行率.
•或者使用结对编程,或者进行代码走查
迭代任务清单 Sprint Backlog
总论
•迭代任务清单规划的主要目的是从产品任务清单中挑选高优先级的任务包含在下一次迭代中,
即确定迭代的范围.
•至于能够包含多少产品任务清单中的任务取决于 Scum 团队能够承诺完成多少.
•承诺总是来自于内部,不能从外部强加.
•迭代不应当有空闲时间, 因此规划迭代范围时要保证工作量是稳定的 (进度是持续的
速度).
•依赖多个因素; 团队的能力, 技术的成熟度, 当前迭代增量的情况等.
•迭代的范围在迭代任务清单中描述; 团队设定优先级.
•产品所有者 PO 定义每个迭代的任务说明(mission statement),目标(sprint goal),使迭代更
具有针对性,如. “实现一个可扩展的列表控件,其项目是可以选择的”
输入和输出
8
Product
Team
Business
Technology
Current
Product Owner CustomersManagement
Sprint Planning
Meeting
Sprint Goal
Sprint Backlog
逻辑
•迭代任务清单规划 是“铁三角”法则的另一个例子
•在 Scrum, 边界是一个变量,因为:
•资源 (Scrum 团队) 是确定的.
•进度表(迭代的时间)是不能变的.
•质量是无法协商的
•团队在一个迭代内能完成的任务,可以用团队进度来衡量 (Story Points / Sprint).
•如果可能的话利用同一个团队上个迭代的进度, “yesterday’s weather”.
30-day sprint 20 work days
1 day for planning, 1 for review/retrospective
= 18 work days
5 persons in team 90 theoretical man days
7.5-hour working day, average 85% to project
work
90*7.5*0.85 = 574 man hours
5% reserved for re-estimation and re-planning
规划会议
•召开迭代任务清单规划会议的目的是确定迭代的边界.
•时间是限定的, 最长时间是一个工作日 (对持续 4 个星期的迭代, 迭代持续的时间越
短,用在规划上的时间也应该越少.
•由 Scrum Master 推动会议.
•由于会议时间有限,Product Owner 和 Scrum 团队都应该事前进行准备.
•前提:
产品需求清单是有效的(valid); 最新的, 标注了优先级并且表述清楚.
•规划会议要解决两个问题:
•下次迭代要做什么.
•确定迭代的目标,包含产品需求清单上高优先级的功能.
•给 Bug 修改留一定的余地
•怎么样实现下次增量所需要的功能.
•改进设计以实现产品需求清单上的功能.
9
工作流程
•产品所有者向团队介绍起草的产品需求清单和迭代目标.
•产品所有者传达迭代的起止日期.
•Scrum 团队 从产品需求清单中选取高优先级的功能作为迭代的任务,如果有必要,更新其
规模估计.
•Scrum 团队改进架构和设计以便能够实现提出的产品需求.
•Scrum 团队把 产品需求清单的每一项划分成小的任务,并估算每个任务要花费的小时数.
•“扑克规划”方法是估算工作量的有效方法.
•Scrum 团队决定一个迭代中能够实现产品需求清单的多少功能
•产品所有者和 Scrum 团队明确了各自要承担的义务.
Sprint Backlog 示例
Persons
working
on
Effort
Sprint
estimate
Meets the
definition of
Description of
the task
Task blocked
by an
执行迭代任务清单
•执行迭代任务清单意味着 团队在迭代期间自行开发.
•团队清楚要达到什么的目标以及怎样达到目标.
•每人每一时间只有一个任务
•团队是自发组织的;成员自己挑选任务, Scrum Master 提供指导并清除障碍.
•不能从外部改变迭代的范围或者迭代的周期.
•为了达到迭代的目标,团队可以增加、删除任务或者改变其优先次序.
•如果要重新设定迭代的范围时需要产品所有者的配合.
•迭代周期短,意味着工期紧;应该把重点放在剩余的工作和风险的消除,要
区分任务的优先级,重要的事情应当先做.
•迭代应当达到项目的质量要求 (definition of “done”);没有独立的测试阶段.
迭代进度图- Burndown Chart
•Scrum 注重成果,它关心的是要花多少时间达到目标,而不是已经花费的时间;.
10
•团队能否在既定的时间达到迭代的目标,可以查看要完成产品需求清单的功能所剩余的工作
•Remaining work = Estimate to Complete (ETC).
•描述剩余工作量和时间关系的图表称为 Sprint Burndown 图, 是 Scrum 中非常重要的控制方法
(control measure).
•给 Scrum 团队和产品所有者提供直观的信息.
•术语 burndown 表明 Scrum 团队在迭代过程中消耗剩余工作的能力; 迭代结束时其值为 0.
•每个任务 ( task )的工作量由 Scrum 团队来估计.
•每天都要进行估计,以便进行跟踪.
•可以使用电子表格或者专门的工具(如 ScrumWorks )
Remaining work
increasing Tasks
underestimated
and/or work
remaining
Initial estimate (752 h)
In the be
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Scrum 敏捷 软件 开发 过程