敏捷开发方法 Scrum

Posted 2021-03-23 lijianming180

Scrum团队：由产品负责人、开发团队和Scrum Master组成。

• 是跨职能的自组织团队
• 自组织团队自己选择如何最好地完成工作，而不是由团队外的人指导
• 跨职能团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人
• 这种团队模式的目的是最大限度地优化灵活度、创造力和生产效率

三大角色：

Scrum管理-五事件

Scrum 管理:

• 所有事件是有时间盒限定的
• 每个事件都有时间限制的
• 一旦Sprint开始，它的周期也就固定下来了，不能缩短或者延长

Scrum 管理五事件包括：

1. Sprint
2. 计划会议
3. 站立会议
4. 回顾会议
5. 演示会议

Scrum管理实施步骤指南（1） Sprint 回顾会议

会议准备

• 会议物品：白板、便签纸、笔等；
• 会议资料：通常有《Sprint任务清单》《站立会议问题跟踪表》、《Sprint验证问题一览表》、《燃尽图》
• 参会人员：PO、SM、Team、敏捷教练；
• 会议组织：可由SM，或敏捷教练，或任一团队成员组织。
• 会议氛围：愉悦的环境，如：可采用简易茶话会的形式，促进团队成员轻松打开话题，畅所欲言，也可促进团队成员放下手中的其他工作，把思路带到会议中

会议过程

• 会议组织者介绍会议目标及会议进程。明确会议规则：回顾会要求每个人都参与，做完一个迭代肯定有感受的，调动大家进行坦诚交流。
• 上一迭代回顾：将站会问题一览表、燃尽图、验证问题一览表等的问题进行整理回顾，哪些做了，哪些没有完成，遇到了哪些问题。
• 团队总结：团队成员根据上述展现的情况及自身感受，在便签纸上分别写出认为上一迭代团队或个人做的“好的”及“可改进的”两类意见，两方面各写一条。注意‘可改进’的问题最好写能够改进的。之后由大家逐一讲解便签条内容，并贴到白板相应的一列上。这里要求每个人都要写下来，避免说过就忘了。
• 确定改进项：团队成员针对每一位提出的问题逐一投票，每人投三票,票数最多的三个问题将在下一跌代解决。之所以定义为三个问题，因为根据业内经验超过三个问题在一个迭代里很难有效解决。
• 改进措施：强调共同分析，这一过程会将问题提到客观全面的高度，让团队能够更清晰的认识到问题的实质，进行问题分析。问题分析可用到的方法及工具应有很多种，比如头脑风暴、鱼骨图等。对于新的敏捷团队，敏捷教练也要发挥价值，引入一些好的建议及方法。最后挑选出在下轮迭代中切实可行的改进建议并指定责任人。
• 问题跟进：下一迭代回顾会议总结开始前，大家一起根据《回顾会议问题一览表》回顾上一迭代问题的解决情况直至问题关闭。具体了解：待改进的问题是否落实并得到了 解决?解决办法是否可行？解决办法是否延用？如果没有得到解决就需要 在本次会议上重新进行讨论分析。也可能在解决别的问题同时已解决掉这个问题。

常见问题

Q：是否需要邀请领导参加？
A：因为回顾会议需要团队成员打开话题，畅所欲言。有些团队领导参加可能会影响到团队成员说真话。所以需根据团队自身情况决定，如1,2两个迭代过后，团队协作较为顺畅，可邀请领导支持者等参加。

Q：是否可以以远程的形式开展会议？
A：远程会议形式不仅耗费沟通成本，效果也会较差，SCRUM的一大特点就是Face To face，所以除特殊情况，还是要找个会议室开。

Q：是否强制要求每个人都要发言？
A：要求每个人都发言，做完一个迭代肯定会有感受的，参与才能融入其中。

Q：回顾会议的结果是否需要正式记录？
A：需要。回顾会议上最终确定要改进的问题及责任人要整理到书面文档里，发送团队全员。并且在下一迭代回顾会议上进行问题跟进，记录改进措施是否可行，问题是否解决。切实改进问题才能达到回顾会议的效果。

Scrum管理实施步骤指南（2） Sprint 计划会议

会议准备

• 邀请与会者：产品负责人、Scrum Master、团队所有成员
• 在sprint计划会议之前，要确保产品backlog的井然有序（已按优先级排列的产品 Backlog ）
• 把产品 Backlog 公开给会议中的每个人，保证其可被获取
• 保证房间环境适合小组讨论，一个比较安静的会议室，有投影仪
• 每个人都可以获取上次 Sprint 评审会议和 Sprint 回顾会议的结果
• 用作计划纸牌的卡片
• 一个任务看板

会议进程

第一部分：产品负责人和团队一起，在先前评估的成果基础上，定出 Sprint 目标和Sprint Backlog，决定在Sprint中需要完成哪些工作。

• SM把 Sprint 完成周期公开给所有人
• SM把 上一次Sprint 评审会议的结果公开给所有人
• SM把 上一次Sprint 回顾会议的结果公开给所有人
• PO向团队产品阐述产品远景，以及达成该远景所需要完成的产品Backlog，让团队成员了解客户的需求。
• 整个Scrum团队为了更好地了解Sprint的工作进行讨论。
• PO和团队一起确认sprint目标。
• 团队初步确认要放入sprint中的Backlog。(sprint backlog)

第二部分：决定这些工作如何完成，并评估相应的完成时间。

• 团队从最重要的故事开始逐一讨论每个故事，估算时间。在必要的情况下拆分backlog条目，建议每个条目最好不要超过一天。拆分工作任务，SM带团队拆分 (task)
• 产品负责人在必要时修改重要性评分，理清每个条目的含义。(拆分sprint backlog 时做的)
• 产品负责人和团队需要对“完成”有一致的定义。
• 确定评审会日期
• 确定回顾会日期
• 确定每日站会时间和地点
• 制作任务看板和燃尽图
• Sprint计划会议结束时，开发团队最好能够解释他们将如何以自组织团队的形式完成Sprint目标并开发期望的产品

会议输出

• Sprint 目标和 Sprint Backlog
• 任务看板（含燃尽图）
• 确定好sprint演示日期
• 确定好sprint回顾日期
• 确定好时间地点，供举行每日站会

常见问题

参会人员哪些是必须的？
PO是必须的，产品需求，客户价值就靠他了；SM必须的，他要保证流程，整个环节里面，他是最了解流程的，会议需要他把握节奏，风险等；团队成员更是必须的。三种角色缺一不可。

sprint应该多长才好？
经验证明一般2-4周比较合适，可以拥有足够的敏捷性，又让团队进入“流”的状态，团队刚开始要确定sprint的长度，不要浪费太多时间做分析，选一个可以接受的长度先开始再说，等做完一两个sprint再进行调整。

不过，团队确定了最合适长度之后，就要在长时间内坚持住。因为接下来的迭代过程有的时候会稍稍感觉有点长，有的时候感觉有点短。但保持住这个长度以后，它似乎变成了大家共同的心跳节奏，每个人都感觉很舒服。接下来无须讨论发布日期之类的事情，因为大家都知道：每过三周都会有一个发布。

挑选任务的量是多少合适？
建议是（Sprint周期）0.8~（Sprint周期） 1.2，防止乐观估计和悲观估计，保证悲观的时候可以完成，乐观的时候有的做。把0.8~1.2之间的内容放到缓冲区中，以备挑选。

Sprint过程中，Sprint backlog是否可以随意添加？
由SM进行风险把控，确保整个Sprint不被影响。需要判断添加的backlog优先级，是否紧急，sprint剩余工作量等进行综合考虑。

在sprint计划会议之前，要确保产品backlog的井然有序，是什么意思？
井然有序表示的意思是： 所有重要的backlog条目都已经根据重要性被评过分，不同的重要程度对应不同的分数。

无论任何故事，如果产品负责人认为它会在下一个sprint实现，那它就应该被划分到一个特有的重要性层次。

分数只是用来根据重要性对backlog条目排序。假如A的分数是20，而B的分数是100，那仅仅是说明B比A重要而已，绝不意味着B比A重要五倍。如果B的分数是21而不是100，含义也是一样的。

最好在分数之间留出适当间隔，以防后面出现一个C，比A重要而不如B重要。当然我们也可以给C打一个20.5分，但这样看上去就很难看了，所以我们还是留出间隔来。

是否可以把一个产品backlog当做一个Sprint backlog？
看情况而定，如果产品backlog就是一个比较小的特性来说，是可以的，如果产品backlog确实很大，那么作为Sprint backlog来说，就不太合适了。建议每个Sprint backlog最好不要超过一天。

Scrum管理实施步骤指南（1） Sprint日站立会议

会议准备

• 确定会议主持人：SM或团队成员轮流。
• 确定参会人员：团队所有成员、Scrum Master、产品负责人（可选）、相关人员（可选）。
• 选择一个合适的固定地点，便于团队成员站立围成一圈进行交流，建议选择靠近团队办公的地点。
• 确定一个合适的固定时间，便于团队成员养成一个习惯，这样就不要每次开会都要下通知了，建议每日早上9:00。
• 每日站会时要有任务看板，在看板上粘贴本项目组的任务状态和任务工作量：未开始的任务，进行中的任务，完成的任务。也可以借助一些敏捷的工具，例如JIRA系统，可以电子化sprint backlog。物理看板更有视觉的冲击力，电子看板更便于查询、统计、度量和优化。团队成立初期可以采用物理看板，后续团队在持续迭代的过程中需要进行过程数据分析，以便不断改进优化，电子看板将必不可少

会议进程（15 分钟内）

• 主持人召集并控制会议时间，会议中注意引导话题，如果相关人员想发表些言论，礼貌地提醒他，该会议只允许让小组成员讨论。
• 会中团队成员每个人就3个问题回答，并且更新每个任务的进展状态，直接在白板上移动任务贴纸：
  • 昨天我为开发团队达成Sprint目标做了什么？（要关注细节，又不能过分详细）
    • 如果任务状态为已完成，把任务从“待处理”或“处理中”转为“已完成”状态；
    • 如果任务状态为进行中，把任务从“待处理”转为“处理中”状态；
    • 如果任务状态已经是“处理中”，需标明剩余工作量，并说明是否存在阻碍任务完成得问题；
    • 如果任务不在 Sprint Backlog 上，添加这个任务，并标明工作量。
  • 今天我准备如何帮助团队达成Sprint目标？ （当成员间的工作有依赖关系时，会给其他成员一个很好的提醒）
    • 如果任务状态为“待处理”转为“处理中”状态
    • 如果任务状态已经是“处理中”，，需标明剩余工作量，说明是否存在阻碍任务完成得问题
    • 如果任务不在 Sprint Backlog 上，添加这个任务，并标明工作量
  • 遇到有什么事情阻碍了我帮助团队达成Sprint目标？（让团队成员认识到在任何任务中他们都不是孤立的）
    • 如果有阻碍团队开发进度的问题，把该障碍加入到障碍 Backlog 中。
    • 如果有问题需要讨论，但只需要几句话的讨论，那么在会上解决；否则需要详细讨论的，记下来，单独安排一个会议专门讨论。
    大专栏  敏捷开发方法(一) Scrum
• 在会议结束时，主持人计算剩余的工作量，更新燃尽图，预测达成Sprint目标的可能性，可以做个简短的总结，我们在何处？我们离目标有多远？
• 会后SM要及时解决会议上提出的问题，否则会影响大家，反映问题的积极性。

会议输出

• 得到最新的障碍 Backlog
• 得到最新的 Sprint Backlog
• 最新的燃尽图

常见问题

每日站会有必要每天召开吗？
项目的延期源自每天的延期，所以要每天实时跟踪进展，站立会议必须每天都要开。

每日站会可以用邮件代替吗？
站立会议重在面对面的沟通，不能用邮件替代，E-mail只会增加沟通成本，而且不能提供细节信息或者给他人问问题的机会。

每日站会仅仅是状态汇报吗？
每日站会不是状态汇报，避免团队成员陷入提供状态相关信息的这样一种模式。

真正价值在于优化开发团队达成Sprint目标的可能性，激励团队成员不断地为达成“承诺”而努力。

每日站会项目组外部的管理人员能够参加吗，可以发言吗？
站立会议只允许团队成员讲话，项目组外部的管理人员可以列席，尤其是主管领导，但不能发言，不能下指令，只能旁听。在SCRUM中提倡的是团队自我管理。

每日站会可以坐着开吗？
不能围在桌子周围坐着开，所有人站立围成一圈，站立暗示这个会会很短，强迫大家更专注和投入，还可以避免有人坐着收发邮件和其他分心的事情。

站立会是向SM汇报吗？
不是，成员在回答三个问题时目光要注视着大家，而不是 Scrum Master，否则就变成了向领导汇报工作。对每个人回答的问题有疑问，其他成员都可以提出，而不是只有Scrum Master 一个人在问。大家是平等的，这也是一种文化的培养。

每日会议时间一般多长？
应该控制在15分钟之内，如果要讨论技术问题，会后单独开会，少数人参与讨论。

如果有人开会总是迟到怎么办？
建议制定惩罚措施，例如每次罚款10元，定期用罚款买一些小零食给团队成员分享，培养团队守时的文化。

Scrum管理实施步骤指南（1） Sprint 评审会议

会议准备

• 评审会议之前，由测试人员准备本迭代成果的演示环境，PO/需求人员协作测试团队准备演示数据，脚本等。
  • 演示环境建议使用独立的环境，非开发环境。
  • 评审会议之前，PO/需求/测试保证所有迭代已验证条目部署到演示环境。
  • 基于用户业务场景设计演示的操作线路，并保证覆盖到该场景下所有的待演示条目。
• PO确定并邀请参会人员，通常有：Scrum团队（PO、SM、开发测试、UE/UI、敏捷教练）、用户/用户代表、其他相关干系人（如：产品线相关人员、管理人员等）。
• 会议资料通常有：Sprint目标、Sprint backlog等

完成情况说明及产品演示

• 首先由SM描述本迭代目标,确保参会人员都了解目标。
• SM说明本迭代开发任务完成情况，及未完成的原因说明，需求/UE协助补充验证情况，测试依据测试报告补充测试情况。
• 通常由测试人员依据《Sprint backlog》进行产品演示；
• 参会人员根据上述演示及说明提出疑问，Scrum团队进行回答，并记 录发现的问题及期望的改进，改进可能是新的功能需求或一个功能的调整完善。
• 用户/PO最后依据产品演示、需求/UI/测试的验证情况，接受或拒绝 Sprint开发成果。
• 根据1）中的记录及2）的结果调整PBI。会后根据评审通过情况进行基线标识。

会议输出

• 《Product Backlog清单及验证》/《Sprint Backlog清单及验证》
• 《Sprint验证问题一览表》《标识Sprint基线清单》

评审会规则

• 迭代评审会在迭代结束前的最后一天进行，不能延期；
• 评审会议时间，建议根据迭代周期时间，一周对应一小时。
• 演示过程中，建议不要展开讨论，先记录下来演示结束后讨论。
• 评审通过标准：用户/PO结合演示情况及测试报告决定是否可交付

Scrum 三大工件

Scrum工件

• 定义： 以不同的方式表现工作任务和价值，可以用来提供透明性以及检查和调整的机会；
• 特性：
  • 透明度： Scrum依赖于透明性，所作出的优化价值和控制风险的决定都是基于所获知的工件状态。工件的状态必须是完全透明的，才能为产品作出决定提供一个坚实的基础；否则，作出的决定就是有缺陷的。
  • “完成” 定义：统一完成标准，团队理解一致；

产品待办列表

• 一个有序的列表，其中包含产品需要的一切可能的东西，也是产品需求变动的唯一来源
• 产品待办列表项包含描述、次序、估算和价值；
• “产品待办列表细化”指的是为列表项补充细节、估算和排序

监控实现目标的进度

• 产品负责人至少要在每个Sprint评审会议的时候追踪剩余工作总量。
• 产品负责人比较这个数量与之前Sprint评审时的剩余工作量，来评估在希望的时间点达成目标的进度。

监控预测进度工具：

• 趋势燃尽图（burn-downs）
• 燃烧图（burn-ups）
• 累积型的工作流（cumulative flows）

Sprint待办列表

• 一组为当前Sprint选出的产品待办列表项，外加交付产品增量和实现Sprint目标的计划
• Sprint待办列表拥有足够的细节，因此能够在每日站会中对进度的变化有清楚的认识
• 随着任务的进行或者完成，团队需要估算并更新剩余的工作量

监控Sprint进度

• 在Sprint中的任意时间点都可以计算Sprint待办列表中所有剩余工作的总和。
• 开发团队在每日站会时跟踪剩余的工作量，预测达成Sprint目标的可能性。
• 团队通过在Sprint中不断跟踪剩余的工作量来管理自己的进度。

增量

• 一个Sprint完成的所有产品待办列表项，以及之前所有Sprint所产生的增量价值的总和；
• 在Sprint的结尾，新的增量必须是“完成”的，必须可用并且达到了Scrum团队“完成”的定义的标准；
• 无论产品负责人是否决定真正发布它，增量必须可用；

Scrum Master的职责之一：和Scrum团队以及企业一起增加工件的透明性
Scrum Master的职责之二：和Scrum团队一起明确团队的完成标准

燃尽图

定义

是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。燃尽图向项目组成员和管理层提供工作进展的一个公共视图。

燃尽图描述的是项目团队随着时间的推移而剩余的工作量，它能形象地展示当前迭代中的剩余工作量和剩余工作时间的变化趋势，是反应项目进展的一个指示器。这种可视化的管理方式，能够帮助团队工作进展更加透明。

您可以使用物理的白板＋手工更新来维护燃尽图，也可以使用EXCEL来生成和更新燃尽图也可以使用一些的敏捷团队协作工具（如：Leangoo等）来自动生成和更新燃尽图。

维护燃尽图是项目团队的日常工作。一般在每日例会后（对于敏捷研发项目，是指每日站立会）后，团队会根据任务的完成情况对其进行更新。这种可视化、简单易操作的管理方式能够帮助团队提升协作效率，并使团队工作进展更加透明，而过重的管理工具会成为团队的负担。

项目团队可以从燃尽图中识别出当前迭代的风险和问题，以便及时采取对策解决问题、规避风险。

另外，可以通过对多个迭代的燃尽图的持续分析，来对项目团团队进行持续地改进

实施方法

燃尽图组成：燃尽图通常由4个核心部分组成

• 燃尽图横坐标：表示工期；
• 燃尽图纵坐标：表示要完成的工作；
• 计划曲线：假定项目组成员工作生产率恒定下的进度曲线；
• 实际曲线：实际进度曲线。
  

燃尽图绘制

1. 绘制时间点：
   在项目组进行完项目计划会议后进行燃尽图的绘制。对于敏捷研发项目来说，是在每个sprint计划会议后进行该sprint的燃尽图绘制
2. 绘制方法：
   绘制人员：燃尽图绘制和后续的更新，由项目经理指定人员进行。可以是项目经理、SM、QA或团队里的其他成员

绘制方法：在业界用的比较多的绘制方法有二种（针对故事点燃尽、针对工作量燃尽），如下:

• 步骤1：画出横轴和纵轴。横轴为工期，纵轴为故事点数【或工作量（人天）】。
• 步骤2：先出第一个点。第一个点，横坐标为开发周期的第一天，纵坐标为这个工期内估计能完成的总故事点数【或总工作量】。这个工期内估计能完成的总故事点数【总工作量】为计划会上估算的最终结果。
• 步骤3：找出项目计划结束点。计划结束点，横坐标为开发周期的最后一天，纵坐标为0。也就是计划在项目的最后一天“烧尽”至零。
• 步骤4：连接第一个点和项目计划结束点，产生的这个线就是“计划曲线”

3. 燃尽图“实际曲线”的更新
   在每日例会后（对应敏捷研发项目，是指每日站立会），项目负责人安排人员计算出剩余工作的估算之和（剩余的故事点数，或剩余的总工作量），然后在燃尽图上画出一个新的点。直至项目结束，停止更新。
   
   

读懂燃尽图

对于项目团队来讲，燃尽图可以说的上是最有用的一种信息发射源（Information Radiator）。对燃尽图的分析，有助于把握团队的进展情况，另外可以还揭示很多问题，比如团队的表现如何、如何进一步改进等等。

燃尽图有助于回答的问题，例如：

• 团队的计划制订情况如何？
• 在一个Sprint中，团队对计划的故事的执行情况如何？
• 团队是自我管理的么？作为“团队”来说，大家的工作步调一致么？
• 团队能进行哪些改进？

可以借鉴和学习一些敏捷大师对燃尽图的分析和总结，来解读各项目自己的燃尽图，Hiren向我们展示了如右图这张图表：

• 图表中的蓝线 Hiren给出了自己的看法：该团队的计划并不好，因为线根本就没有触到零点，这其中的原因可能有很多。团队的一致性上也出现了问题，他们需要教练。因此，对于该团队来说，计划与自我管理方面亟需改进
• 图中的紫线表明该团队已经达成了目标，但并没有主动去更新数字，原因可能有二：要么他们太懒了，没有更新剩余的工作量；要么是在该Sprint的最后舍弃了很多用户故事。
• 图中的绿线表明对于一个计划良好的成熟团队工作量的燃尽情况，该团队是自我管理并且在整个Sprint中拥有足够的故事要去实现。这条线接近于理想情况，表明了软件开发的复杂性。