深度理解：敏捷开发方法-Scrum
2023-02-17 16:47:04 2 举报AI智能生成
登录查看完整内容
【深度理解：敏捷开发方法-Scrum】敏捷开发的总体目标是通过"尽可能早地，持续地对有价值的软件的交付"使客户满意。通过软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。
作者其他创作
大纲/内容
1986年，竹内弘高 (Hirotaka Takeuchi) 和野中郁次郎 (Ikujiro Nonaka) 发表《The New New Product Development Game》，该方法意在提高新产品开发的速度和灵活性，文章中采用了橄榄球运动的隐喻
1990年，Ken Schwaber在其公司使用了被称之为Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum
1993年，Jeff Sutherland 在Easel公司开发了一种类似的方法，并首次称之为Scrum
1995年，在奥斯汀举办的OOPSLA’95上，Jeff Sutherland 和Ken Schwaber联合发表了论文首次提出了Scrum概念；并在接下的几年里共同合作，形成我们现在所知的Scrum
2001年，Jeff Sutherland和Ken Schwaber参与发布了《敏捷宣言》；Ken Schwaber与Mike Beedle合著了《敏捷软件开发-使用Scrum过程》
2002年，Ken Schwaber和Mike Cohn创办了Scrum Alliance
Scrum历史
敏捷已经成为软件开发方法的主流
Scrum是应用最广泛的敏捷方法
Scrum实践在敏捷实践中应用比例最大
Scrum应用现状
创建带有优先级的产品功能列表（Product Backlog）
持续演化Product Backlog（基于用户反馈，新的想法、信息或机会）
在每个迭代中与团队沟通和澄清需求，验收需求
构建和传达产品的愿景
定义产品路线图
决定发布计划
Product Owner
指导团队：确保团队理解和遵循Scrum过程和实践
服务团队：促进团队内外沟通，帮助团队移除障碍，达成迭代目标
保护团队：保护团队不受外部干扰、拒绝不合理的要求
不是团队经理或项目经理，是团队的服务型领导（Servant Leader）
建议Scrum Master与Product Owner不是同一人担任
Scrum Master
共享目标，共担责任
坐在一起
通常5 – 9 人
交付需求（特性，而不是组件）
跨职能：包含交付所需要的所有能力（UI、架构、编码、测试等）
稳定的、长期的
团队成员拥有某项专长，并学习多技能
团队
Scrum角色
敏捷方法的一个共同特点是以增量方式完成工作；对于Scrum而言，在一个迭代周期内完成一个产品增量
冲刺长度通常1-4周，一个研发小组的冲刺长度要保持固定
在每个冲刺初，团队承诺要交付的功能
在每个冲刺内，团队完成产品增量的交付
在每个冲刺内，团队保持专注，尽量不被干
Sprint（冲刺）是Scrum的迭代，保持Scrum的基本节奏
外框
冲刺
（DoD: Definition of Done ），即在宣布Sprint完成之前，Scrum团队所要完成的各项工作
完成的定义
代码设计经过评审
代码符合编程规范
代码重构完成
代码已检查
代码已提交
代码要求
单元测试完成
集成测试完成
系统测试完成
回归测试完成
无重大缺陷
测试要求
用户文档已更新
过程文档已更新
部署包已完成
业务已验收
Jira中故事已关闭
其它要求
DoD
就绪的定义（Definition of Ready）是某项工作是否可以开展的一组条件，只有这些条件都得到满足了，才可以进行后续的工作。
DoR – 就绪的定义
故事的业务价值清晰（Why）
故事的验收标准明确（What）
故事的技术可行（技术风险被消除或者可以接受）
故事大小合适（可以在一个迭代内完成）
故事的规模被估算
故事的关联关系被识别等
故事“就绪的定义”
Sprint Backlog的所有故事都满足“就绪的定义”
Sprint Backlog包含了所有在本Sprint承诺的工作（包括历史遗留任务、缺陷等）
所有故事的外部依赖得到了关联方的确认
Scrum Team拥有完成Sprint目标的所有技能，
Team知道如何演示所有故事等
Sprint“就绪的定义”
DoR
Scrum框架
Scrum概述
1、与利益相关者建立共同的愿景
2、建立一个带优先级的功能列表并持续优化
3、建立MPV，实施迭代增量开发
简化的敏捷需求过程
经过优先级排序的，并持续动态更新的产品需求清单
是用户故事动态管理的载体，用来制定发布计划和迭代计划
什么是Product Backlog?
近期要实现的用户故事多一些细节，远期的少些细节
大的用户故事一般位于PBL的底部
Detailed Appropriately 适度细节
顶部的用户故事有相对精确的估算，底部的用户故事不需要精确
Estimated 估算的
PBL一直在变化，初始的需求具有很低的完整性.
用户故事可以根据需要被增加、改变、拆分、合并、丢弃
Emergent 涌现的
最有价值的在顶部，低价值的在底部
最有价值的最先实现，以尽早价值最大化
Prioritized 排序的
Product Backlog的DEEP原则
Product Backlog/PBL 产品待办事项列表
验收条件提供了确认用户故事是否能被验收的标准，每个故事至少有一个验收条件
在写代码之前写验收条件
验收条件记录了与客户沟通的细节
验收条件记录了有关故事的假设
测试人员编写测试用例与验收条件对应
什么是故事的验收条件？
一个清晰的验收标准，能够触发团队从最终用户的角度考虑功能是如何工作的，帮助团队理解业务价值，编写准确的测试用例，开展设计和编码工作，且不产生歧义，从而避免返工
同时，它也有助于限定范围，消除不必要的功能，减少浪费
验收条件的价值
用户故事的验收条件
Independent，独立的，是指拆分后的用户故事相对独立，能够一个一个的进行单独开发，不具有强偶合性。
Independent
Negotiable，可协商的，故事并不不在一开始锁定太多细节，从故事卡所隐藏的背后含义我们也容易了解，一张卡片中是无法包含太多的细节内容的。
第一，用户故事符合远粗近细的原则，避免在一开始就引入太多的细节设计，使得相关人员误以为这个需求已经是非常明确的，不需要再展开讨论；
第二，故事卡本身就是一个沟通的工具，希望借此工具我们能够及时、面对面的沟通，从而避免细节遗漏；
第三，很多故事是随着对业务需求对场景的理解而不断深化的，所以在迭代开始前，我们后希望能够获取到更多的细节，将用户故事不断完善，最终开发的功能是客户真正想要的。
Negotiable
Valuable，有价值的，必须是有价值的。
Valuable
Estimable，可估算的，故事是可以估算大小的。
一是可估算的故事有助于我们进行迭代计划排期，团队有多少资源，我们能做多少故事，有估算的故事便于我们内外部协调资源、计划排期
二是可估算的故事其实可以帮助我们进一步澄清需求、降低风险，通过对故事工作量的评估，清楚这个故事的范围、识别要做的事情。
Estimable
对于为期2周一个迭代来讲，小于3~5天的颗粒度是合适的，尽量不要超过5天。
Small，颗粒度小的（也有翻译成 Size appropriate，大小适中的）
Small
Testable，可测试的，明确的完成的条件，可以被验收
Testable
用户故事INVEST原则
目的：显示进度及剩余规模的信息，用于计划、跟踪和预测
要求：不需要太精确，不需要花很多时间，适用于团队共同估算
采用相对规模估算方法
使用斐波那契数列（Fibonacci Sequence）
单位：故事点 (Story Point)
使用计划扑克（Planning Poker）
方案：
用户故规模估算
计划游戏的目标不是为了获得将来不再变化的估算，而是花尽可能最少时间，得到一个容易得到的值；且通过交流让大家对于构建的内容达成共识。
目标
团队选择一个合适的用户故事作为基准，并给出一个初始规模值
选择一个用户故事用作参考标准
选择另一个用户故事
解释用户故事
针对用户故事提出问题
澄清假设或风险
选择另一个用户故事，并进行讨论
每个团队成员拿该用户故事与基准（已估算）用户故事做比较
所有人都同时向他人亮出自己的估算结果
估算规模
否则，最高和最低估值者给出解释
如果达成一致，写下估算结果然后继续下一个用户故事。
若多轮之后仍不能达成一致，则说明该故事还需要进一步分析，留给将来估算
如果没有达到一致，需要再来一轮或者两轮讨论和估算。
承诺或讨论估算结果
过程
计划游戏过程
必须有 - Must have
应该有 - Should have
可以有 - Could have
不必有 - Won’t have
用户故事排序
MoSCoW原则
故事地图将传统的按业务价值排序的一维特性列表（譬如Product Backlog），替换为侧重于用户活动和产品总体愿景的二维地图
在水平轴上顺序展现用户活动/系统行为，也即用户旅程（User’s Journey）
在垂直轴展现更多的活动细节，并表示特性的优先级
用户故事地图
用户故事
PBL和用户故事
冲刺计划流程
团队每个迭代能够交付的故事点数
团队速度（Velocity）：
团队每个迭代能够用以开发的小时数
理想小时：排除非工作时间，每天6小时
冲刺活动：计划、评审、反思、需求梳理等，平均一周半天。
缓冲时间：建议每周半天左右
团队产能的计算=人数*工作天数*每天理想工作小时 - 非开发的计划任务时间 - 缓冲
团队产能（Capacity）：
团队速度和产能
回顾PBL
产品所有人向团队阐明本冲刺的目标
可以基于冲刺目标挑选用户故事，或者调整PBL优先级
默认情况，从PBL高优先级的条目开始选择
产品所有人回答团队关于所选择用户故事的问题
完成一个用户故事之后，再移到下一个，直到所选择用户故事的规模与团队速度相当
选择用户故事
团队思考和讨论如何实现用户故事，做概要设计和任务分解
识别使得每个用户故事达到验收标准，符合DoD要求的各项任务
任务分解
估算任务的规模（一般由该任务的执行者估算）
单位是“理想小时”（在理想情况下执行该任务所需要的时间）
合并或者分解任务，使得每个任务的规模适当（对于2周迭代，任务规模不超过2天）
任务估算
任务分解和估算
计算所选择用户故事包含的所有任务的总规模（小时）
对比所有任务总规模与团队产能（小时）的匹配情况
如果团队觉得任务太多或者太少，可以和PO重新进行磋商，减少或增加用户故事
经磋商，得到一个合理的范围
团队承诺可以完成所选择的用户故事
确定范围
燃尽图用以跟踪冲刺内的进度，横轴单位是天（每个冲刺的实际工作日），横轴单位是剩余小时（每天剩余的工作量）
计算起始任务总规模（Y小时），在图上标记起始坐标（0，Y）
理想情况下最后一天（第X天）完成所有任务，即所有任务的剩余时间为0，标志坐标（X，0）
在（0，Y）和（X，0）并在这两个点之间画一条直线，这条直线就是理想燃尽图
绘制燃尽图
冲刺计划
同时开始过多用户故事，迷你瀑布
反馈慢，质量问题
后期没有测试时间，无法“完成”
多用故事并行开发
团队成员合力完成一个用户故事，再转向新的用户故事
倡导T型/E-型技能
蜂拥式开发（swarming）/流模式
并行开发 VS 蜂拥式开发
每天同一时间，同一地点（团队任务板前）
保持站立，每次不超过15分钟
团队和Scrum Master
产品负责人（可选）
其他人可以出席，但会议结束前不能发言
参与者：
昨天完成了什么？
今天准备完成什么？
遇到了什么障碍?
站立会议的形式
站立会议
团队成员围在团队任务板前，面向整个团队，轮流回答下述三个问题
根据任务状态，及时在团队任务板上将任务移动到对应的列
所有任务都完成后，PO可以基于DoD和接受标准对用户故事进行确认
根据执行情况增添或移除任务，并估算新增任务的时间
更新任务板
统计所有未完成任务（不在“已办”列）的估算工作量，作为剩余工作量
对于部分完成的任务，也做未完成处理，其估算时间全部记在剩余工作量内
假定第X天，剩余工作量为Y，在图上找到对应的坐标（X，Y）
在第X天的坐标，与前一天的坐标之间，画上一条直线；每天更新，得到实际燃尽图
通过实际燃尽图与理想燃尽图的对照，准确了解团队在一个冲刺内的进度情况
更新燃尽图
冲刺执行
同步状态、协调工作、每日承诺、报告障碍
展示“真实”的产品：Team 应在真实环境中展示可运行的软件，判断是否达到“完成”标准
收集反馈：PO 根据演示情况及客户反馈意见，及时调整产品Backlog
产品负责人对所有参会者致以欢迎
产品负责人将未完成的条目移回产品待办事项列表
团队回答来自参会者的问题
团队回顾冲刺目标，以及承诺的产品待办事项条目
团队演示在本冲刺里“完成”的功能。如果可能，让用户试着使用
记录反馈，产品负责人会后会更新到Product Backlog里
示例：
开发团队演示“已完成”的工作
为大型项目举行联合演示会议
展示产品及发布整体状况
讨论冲刺过程遇到的问题
调整接下来的工作方向（范围、计划等）
庆祝冲刺成功的活动
DO
DO NOT 演示未完成的用户故事
DO NOT 向管理层做汇报
DO NOT 太多的技术术语
DO NOT 为错误的结果指责团队
DO NOT 隐藏事实
DO NOT 断断续续举行会议
DO NOT
冲刺评审要点
冲刺评审
Scrum冲刺回顾是团队专属的会议，团队成员通过回顾产品增量的构建过程，基于团队所面对的问题，识别改进机会，迅速采取行动，从而持续改进工作方法。
预设会议基调，营造安全氛围，使大家处在放松的状态
回顾客观数据，对阶段性工作形成共同认知
哪些做得好的地方？哪些做法应该停止？哪些做法可以尝试？
根据团队的情况，选择最高优先级的几个见解进行改进
示例
DO 放松并专注
DO 关注事件和事实
DO 小步改进
TRY 定义回顾重点
TRY 不同的回顾活动
DO NOT 取消回顾会议
DO NOT 评价人
DO NOT 抱怨
DO NOT 一次改进太多
DO NOT 过于关注团队能力范围之外的问题（放入障碍列表跟踪）
冲刺回顾要点
冲刺回顾
冲刺评审和冲刺回顾
所有成果必须可见
所有可见物皆真实反应情况
向所有干系人暴露所有的事情
透明
一旦发现偏差马上调整
尽可能快地调整
基于反馈做调整
调整
多层次的检查
快速的反馈
检查和反馈
检查
Scrum三大支柱
层次1: 产品愿景
层次 2: 产品路线图
层次 3: 发布计划
层次4: 冲刺计划
层次5: 每日运作
Scrum多层次的计划和跟踪
与业务人员的紧密合作
使用反映业务优先级的product backlog
冲刺/Sprint
发布和迭代计划
迭代演示
做正确的事
跨功能团队
使用用户故事来沟通和规划
计划扑克
每日站会的检查和调整
回顾会议改进工作方法
正确地做事
Scrum为什么有效？
Scrum总结
Scrum框架帮助团队创建一种做正确的事情和正确地做事的机制，团队紧密协作（自组织），被业务目标所驱动，管理流动、加快反馈，并持续改进
深度理解：敏捷开发方法-Scrum
0 条评论
回复 删除
下一页
