Scrum精髓读书笔记

Scrum精髓

四 . Sprint

Sprint的定义

1. Scrum在最长一个月的迭代或周期中安排工作，一般为2个星期，这些迭代或周期称为Sprint

2. Sprint提供基本的Scrum骨架，大多数其他的活动和工件都以他为基础，Sprint是短期的，在时间盒之内，并且具有一致性的持续期，通常用Sprint的目标来定义Sprint,Sprint目标没有合理的理由不能更改，Sprint要产生一个潜在可发布的产品增量，完成时达到大家所认可的完成的定义，一致的程度

Sprint 的内容

1. Sprint是Scrum框架的基础，一个Sprint 中包含，Scrum中的三个工件，5个事件

2. 所有的Sprint都在一个时间盒内，都有固定的起始日期，一般为2周，每个Sprint的长度尽量保持一致

3. 每个Sprint都有Sprint的目标，每个Sprint都要完成一个潜在可发布产品增量，并且要达到团队一致认同的完成目标的定义

4. Sprint以时间盒这个概念为基础，帮助安排工作执行的情况和管理工作范围，每个Sprint都发生在一定的时间期限之内，有明确的开始日期和结束日期

时间盒

1. 设定开始但尚未完成的工作清单，范围是确定的

2. 强制排列优先顺序

   • 按照优先级排序工作清单，快速完成有价值的事情

3. 展示进度

   • 通过完成和验证重要的工作清单，确保每个Sprint都能产生有价值，可度量的进度，帮助干系人和团队知道为交付整个特性还需要做多少工作

4. 避免不必要的完美主义

5. 促进结束

6. 增强可预测性

持续期短的Sprint有很多好处

1. 容易规划

   • 为短时间做规划需要的时间更短，更容易一些，结果也准确的多

2. 反馈快

   • 快速的产生反馈，每个Sprint开发出可以工作的软件，然后有机会检视和调整，小步试错

3. 投入产出比高

4. 错误有限

5. 检查点多

一致的持续周期

团队应为Sprint选择一致的持续期，没有很特殊的理由，不要轻易的变更长度

1. 有节奏感
2. 简化规划活动

锁定Sprint目标

Scrum有一条重要的规则：一旦制定Sprint目标，在Sprint开始后，就不允许有任何变更对Sprint目标实际产生影响

Sprint目标描述当前Sprint的商业目的和价值。通常有清晰而单一的重点

1. 共同承诺

   • Sprint目标是团队和产品负责人做出共同承诺的基础，团队承诺在Sprint结束之前完成目标，产品负责人承诺在Sprint过程中，不更改目标

   • 顺应变化而调整业务需求，让团队集中精力在短周期内高效的发挥其才创造价值，Scrum团队高度关注一个明确定义的，有价值的目标

2. 是变更，还是澄清？

   • 变更：工作或资源的变动，在经济和时间上造成严重的浪费，中断工作流或在一个Sprint内增加工作范围，影响整个Sprint目标的进度和实现，放到下一个Sprint中去

   • 澄清：在Sprint执行期间提供更多的细节来帮助团队实现Sprint目标

3. 变更引起的后果

   • 造成额外的浪费

   • 损害团队的士气和信任关系

4. 注重实效，异常终止

   • Scrum团队注重实效不是铁律，业务发生变化，理应改变Sprint目标，用价值衡量，适应变化

   • Sprint的目标完全无效时，应当异常终止Sprint，并回顾当前Sprint

完成的定义

每个Sprint的结果，都会产出一个潜在可发布的产品增量，并不意味着构建的增量真的交付给用户，如何业务上需要，可以交付，为了确定开发出来的东西是潜在可发布的Scrum团队，必须要有一个明确定义的，大家一致认同的完成的定义

完成的定义是，在宣布潜在可发布的产品增量之前，要求团队成功的完成各项定义的工作检查，比如

1. 单元测试
2. 测试人员覆盖所有的测试用例
3. 采用的技术
4. 最终的文档
5. 验证产品增量，能否实现用户的期望和价值

五 . 需求与用户故事

1. Scrum认为，可以自由掌控需求是达成业务目标的关键，关注高价值的需求，需求的细节是在开发期间持续不断的对话中商讨出来的
2. PBI ，每个PBI代表客户期待的一个业务价值
3. Product Backlog 中的用户故事的粗细度，呈现为金字塔结构 ，近期需要开发的用户故事中需要进行细化，拆分 ，后面的故事可以是史诗级的用户故事，逐步的迭代，拆分
4. Sprint Backlog中用户故事来源于Product Backlog ，产品 负责人根据业务的愿景，目标，发布计划，以及价值，选取团队在一个Sprint能做完的用户故事，并进行细化和拆分用户故事

收集故事

1. 用户故事写作研讨会
2. 用户故事地图

六 . 产品列表

产品列表的定义

​ 产品列表是一个按优先级顺序排列的，预期产品功能列表，我们把所了解的以什么顺序构建什么特性这些信息都集中到产品列表，并团队共享

产品列表的内容

1. PBI，产品列表由各个待办事项组成，Product Backlog Item 或简称条目

四大特征DEEP

1. 详略得当，在同一时刻，各个PBI的详尽程度不相同，呈金字塔结构，越接近迭代开发的，越细

   • 马上要做的PBI应该放到列表顶部，工作量小，内容非常详细，可以在最近的一个Sprint中实现

   • 马上要做大的PBI时，应当将史诗级故事，拆分成一组小的，可以在一个Sprint内完成的故事

2. 涌现的

   • 根据实际需求，需求的价值，持续的更新条目，产品负责人必须考虑新涌现的信息，让产品列表重新保持平衡并排列优先级

3. 做过估算的

   • 每个条目都有大小的估算

   • 故事点，大多数都是以理想人天数估算，非常大的，靠近底部的条目，可以用类似于衣服的尺码的方式来估算，L ,M ,XL等

4. 排列优先级顺序的

   • 产品列表是一个排列好优先级顺序的PBI列表，但不可能其中所有的PBI都已经排好优先级顺序

   

近期的Sprint要做的条目，排列优先级很有用，如果在开发的过程中出现新的条日，需要按照正确的顺序插入新条目

梳理

为了得到一个良好的，符合DEEP原则的产品列表，必须积极主动的管理，组织，监督产品列表

梳理的重要三大活动，确定并细化PBI（增加PBI细节），对PBI进行估算，为PBI排列优先顺序

1. 由谁来梳理

   • 梳理产品列表是一个持续不断，合作完成的活动，有产品负责人牵头，内外部干系人中的主要参与者，包括Scrum Master 和开发团队

   • 优秀的产品负责人，会充分利用集体智慧和各个组员的不同观点，发现可能遗漏的重要信息，让团队成员参与梳理活动，可以让每一个人，更清晰，更一致的理解产品列表

   • 开发团队帮助产品负责人，根据技术依赖关系和资源约束来排列PBI的优先顺序

2. 梳理就绪的定义

   梳理时，应当确保列表顶部的条目已就绪，可以放入Sprint中，让开发团队有信心做相关工作，并在Sprint结束时完成

   

九 . 产品负责人

1. 产品负责人必须很好的理解组织中利益干系人，客户和用户的需求及其优先级，从这个角度来看，担任的是产品经理的角色

2. 对于要构建的特性及其构建顺序，产品负责人必须和开发团队进行交流，定义验收标准，确保特性完成

主要职责

1. 参与规划

   • 产品负责人和利益干系人一起制定产品愿景

   • 在做版本规划时，产品负责人与利益干系人及团队一起确定下一个版本的内容

   • 在做Sprint规划时，产品负责人与开发团队一起确定Sprint目标，给出有价值的意见，让开发团队根据实情在Sprint结束时能交付一组PBI

2. 梳理产品列表

   • 产品负责人负责管理产品列表的梳理活动，包括PBI的建立，细化，估算和排列优先顺序

   • 负责解答问题，澄清问题，确保梳理活动有助于价值交付，并顺利进行

3. 定义验收标准并验证

   • 产品负责人负责为每一个PBI定义验收标准，并确认PBI是否满足验收标准

   • 产品负责人要在执行Sprint的过程中验证，及时发现问题，让团队知道哪些特性满足了完成的定义

4. 与开发团队协作

   • 产品负责人必须经常与开发团队保持紧密合作，积极的参与，及时的给出反馈

5. 与利益干系人协作

   • 产品负责人必须与整个利益干系人团队，紧密合作，集思广益，形成一个统一的，愿景来指导产品开发工作

6. 管理经济利益和价值

特征/技能

1. 领域能力

   • 产品负责人要有预见性，能够结合干系人的关注点和期望，统一产品的愿景和目标

   • 有些事情，无法预见时，愿意做出调整，产品负责人必须具备适当的业务和领域知识

2. 人际交往能力

   • 产品负责人和利益干系人保持良好的人际关系，多个利益干系人需求冲突时，能协调并促成一致意见

   • 产品负责人需要在开发团队，利益干系人之间，传递信息，大胆发表意见，能简单明了，易于理解的方式进行沟通并且取得信任

   • 激励和鼓舞团队和利益干系人，让人们知道业务的价值和观点，让人们保持热情

3. 决策力

   • 产品负责人得到授权，可以制定决策，有决断力，关键时刻能做出判断

   • 制定决策时需要在业务需求和技术实现之间保持适当的平衡，在价值的视角进行平衡

4. 责任心

   • 产品负责人要负责交付令人满意的业务成果,重价值的角度合理利用资源

   • 产品负责人时Scrum团队的成员，团队协作一起交付成果

十. ScrumMaster

​ 主要负责帮助每个人理解并乐于接受Scrum的价值观，原则和实践，帮助团队和组织其他成员发展其具有组织特色的，高效的Scrum方法

主要职责

1. 教练

   • 团队中的敏捷教练，指导开发团队和产品负责人，理解和履行Scrum

   • 帮助团队和成员自己解决自己的问题，遇到团队和成员无法解决的问题时，才由ScrumMaster解决

   • 协助和组织，Scrum 过程中的各个活动

2. 服务型领导

   • 帮助团队高效的运行

3. 过程权威

   • 确保，团队使用特定的方法实施和遵循Scrum的价值观，原则和实践

   • 持续帮助Scrum团队改进过程，帮助团队定义并遵守自己的流程，确保工作完成

4. 保护伞

   • 保护团队免受外部干扰，让团队集中精力在每个Sprint交付业务价值，让团队专注于价值交付

5. 清道夫

   • 承担清道夫的职责，扫清妨碍团队生产效率的一切障碍

6. 变革代言人

   • 积极推动变更，帮助他人理解变革的需要，价值

特征/技能

1. 见多识广

   • 了解Scrum方方面面的知识，理解团队需要解决的技术问题以及解决方案

2. 善于提问

   • 结合流程，技术和业务方面的知识，提出重要的问题，帮助团队人员能够自己找到答案

3. 由耐心

   • 通过启发性的问题，一路指导，团队或者人员找到解决方案

4. 有协作精神

   • 想法设法的帮助团队之间高效率的合作，可以展现个人有效的协作技能协助团队开展工作

5. 保护团队

   • 帮助落后的团队成员，遇到困难时，人们容易回退到原来熟悉的非敏捷工作方式，帮助他们客服困难

6. 公开透明

   • 所有形式的沟通都是透明的，做到信息透明

工作内容

1. 每天准备，组织和推进Scrum活动，管理执行过程，使团队其他人的工作过程取的高价值的结果
2. 指导团队成员，帮助他们提高使用Scrum的技术实践和能力
3. 与产品负责人一起执行梳理活动，关于重要可变的因素，一起进行权衡
4. 变更的推动者，利用灵活时间，扫清团队遇到的障碍

十一 . 开发团队

​ 开发团队成员整体具备的技能足以实现产品负责人要求交付的业务价值

1. 专职团队

   开发团队能在每个Sprint都能完整的交付业务价值，包含，设计，开发，测试 ，产品等

   只要可能，我们就要建立跨职能团队

主要职责

1. 每日检视和调整

   • 每个开发团队成员，都应该参加每日站会，在会上，团队成员一起检验Sprint目标的进展情况，根据当天工作情况调整计划

2. 梳理产品列表

   • 准备下一个Spint，主要是梳理产品列表，包括PBI的创建和细化，估算，和排列优先顺序

3. Sprint 规划

   • 开发团队参与Sprint规划会，在ScrumMaster的协助下，开发团队和产品负责人合作为下一个Sprint建立目标，对于2周的Sprint，规划通常花半天时间

   • 团队更愿意在每个Sprint开始时，制定一系列更小的，更确定的且更集体的及时计划

4. 检视和调整产品和过程

   • 开发团队参加，Sprint评审会议和Sprint回顾会议，在Sprint评审会议上，评审当前Sprint完成的特性，并讨论下一步改进措施

   • 在Sprint回顾会议上，Scrum团队检视和调整自己的Scrum过程和技术实践，进一步改善团队使用Scrum来交付业务价值的方法

特征/技能

1. 自组织

   • 团队成员自组织决定实现Sprint目标的最佳方式，没有自上而下,命令与控制的权威告诉他们如何工作

2. 跨职能

   • 开发团队成员应该是跨职能多样化的，他们共同拥有必要的，足以完成工作的技能

3. T 型技能

   • 灵活的开发团队是由T型技能的成员组成，技能的深度和广度

   • 团队成员掌握的知识不一样，鼓励成员帮助其他成员掌握一些自己掌握的知识

4. 火枪手态度

   • "人人为我，我为人人"，团队成员共同承担完成工作的责任，成败是整个团队的事情

5. 沟通广泛

   • 开发团队成员，产品负责人，ScrumMaster 之间，需要进行广泛的沟通，彼此之间以最低的成本速度，高效的交换有价值的信息，更好的检视和调整，也增强自己在实现时的判断力

6. 透明沟通

   • 团队内部沟通也要透明，沟通透明能够使所有的成员都清楚现状，建立互信

7. 规模适中

   • 推崇小团队，由5到9名成员组成

8. 专注，由责任感

   • 专注是指每个团队成员参与并集中精力关注团队目标，责任感是指不论情况好坏，每个团队成员都会致力于完成团队共同的目标

9. 工作步调可持续

   • 团队成员必须以可持续的节奏工作，达到工作的平衡，不会出现大量高强度的工作

10. 团队人员稳定

十九 . Sprint规划

为了确定在下个Sprint中构建的，最重要的PBI子集，Scrum团队会做Sprint规划，对Sprint目标达成一致，开发团队确定与目标一致的具体每个PBI，同时确定时 间能在Sprint结束之前交付，开发团队创建一个PBI完成计划，PBI和计划共同组成Sprint列表

1. 时间安排

   一般发生在每个Sprint开始，利用最优信息来决定下个Sprint做那些PBI

2. 参与者

   Sprint规划由整个Scrum团队协作完成，

   产品负责人分享初始Sprint目标，展示排定优先级顺序的产品列表，回答团队提出的问题

   开发团队用心确定可以交付那些特性，在Sprint结束之前做出靠谱的承诺，

   ScrumMaster,提出深入细节的问题，引导并且帮助团队导出成果

3. 流程

   Sprint规划依赖于产品列表，产品列表最上面的PBI，是大小合适，经过估算，而且有优先顺序的

   

大多数团队会把每个目标PBI分解成一系列的任务经过估算的任务，遵循一个有用的任务分解规则，团队达成共识，实际要做什么，是否能在可用的时间内完成，确定Sprint目标，并对Sprint列表作出承诺

Sprint规划的两种方式

1. 两段式Sprint规划

​ 在1阶段，确定其完成工作的生产能力，预估在Sprint结束时能够完成的PBI，如果团队能完成40个故事点，就选大概40个故事点的工作

​ 在2阶段，大多数团队把PBI分解成一系列的任务，然后估算（以小时计）完成每个任务需要多少 工作量，根据任务估算的小时数和团队的以小时计的生产能力，确定1阶段的承诺是否现实

​ 如果团队发现选取的PBI太多或者太少，或者选取的PBI由于种种限制不能在一个Sprint中完成，可以进行调整，能达到预期后，确定承诺的PBI列表，结束Sprint规划活动

2. 一次性Sprint规划

​ 开发团队首先确定可用的生产能力，Sprint目标可能需要细化，接下来，团队依次选择PBI，并表示有信心在当前Sprint完成它，直到团队没有余力做更多的工作，确定承诺，结束Sprint规划活动

确定生产能力

确定可用的团队生产能力，了解团队在每个Sprint中能完成多少工作，有助于能够交付那些特性

1. 用故事点来表示生产能力

   PBI的故事点或者理想人天，Sprint列表的任务工时

   利用团队的平均速率和上一个Sprint的速率，作为新一轮Sprint的初始速率

2. 用工时来表示生产能力

   确定团队成员每天有多少时间能完全投入到Sprint的工作，每个人都给出一个范围，团队估算出能用于做PBI的生产能力的范围

选取PBI

1. 有Sprint目标，就选取与目标一致的PBI
2. 产品列表从最上面的PBI开始，依次选取合适的的PBI
3. 最好不用选择评估出来比较大的PBI，需要拆分和细化，选取合适的，选取的PBI在Sprint结束之前能达到一个潜在可发布产品增量的目标

获得信心

1. 使用预测速率来看看承诺是否实际，对承诺进行检查和权衡
2. PBI分解成任务需要精心设计，适当的规划
3. 让团队成员在Sprint执行过程中，见机行事，适时，自主的选择工作任务

细化Sprint目标

1. Sprint目标总结了业务目标的价值，产品负责人带着初步的Sprint目标参与Sprint规划活动，团队可以进行优化，可以一起决定实际能够交付那些PBI

2. 确定Sprint承诺，表明团队能够交付的业务价值

二十 . Sprint执行

​ Sprint执行有点像一个小的项目,为交付一个潜在可发布产品增量而必须完成的所有工作

1. 时间安排

   • Sprint执行占Sprint中大部分时间，开始与Sprint规划，结束于Sprint评审

2. 参与者

   • 开发团队成员自组织并想方设法完成Sprint确定的目标

   • ScrumMaster作为教练，引导师和清道夫，参与执行，帮助团队取得成功

   • 产品负责人在执行的过程中，回答需要澄清的问题，检视工作进展，为团队提供反馈，讨论Sprint目标的调整，验证PBI是否满足验收标准

3. 流程

工具

1. 任务板 + 燃尽图

   • 团队成员在每日站会上，按照合理的顺序，领取任务，更新任务 ，并汇总任务工时，更新燃尽图

二十一 . Spring 评审

检视和调整当前构建的产品，让干系人清楚的看到产品当前的状态，包括各种让人头痛的真相

干系人可以进行提问，发表见解或给出建议，讨论结合当前实际最好采取那些措施，来解决各种问题

1. 参与者

   • Scrum整个团队

   • 能邀请到的所有的干系人

准备工作

1. 确定邀请谁参加

   • 确定干系人，并邀请他们参加会议

   • 如果某个人或某个团队的意见对Sprint评审非常重要，应该重点关注

2. 安排活动日程

   • 需要安排Sprint评审的活动日程（时间，地点，多长时间）

3. 确定Sprint工作完成

   • Sprint评审时，只允许团队展示已经完成的工作，并且满足完成的定义

4. 演示准备工作

   • 团队在Sprint评审时演示潜在可发布产品的增量，需要做准备工作，比如部署环境，数据准备等

   • 一次仪式少，价值高的非正式会议，开城布工的方式进行检视和调整

5. 确定谁做什么

   • 团队需要确定谁负责组织评审会议，谁来演示

方法

执行Sprint评审的常见方式是：总结或概要说明Sprint的目标中那些完成了，那些没有完成，演示潜在可发布的产品增量，讨论产品当前的章台，调整产品未来的方向

由Scrum团队成员（通常是产品负责人）展示Sprint目标和Sprint目标相关的PBI，概述在Sprint中实际产生的产品增量，如果结果与目标不符，Scrum团队需要给出解释，不要指责他人

评审的目标：描述完成的目标，参与者之间深入交谈和合作碰撞得出建设性的，实际可行的调整建议，然后利用这些信息确定最佳前进路线

1. 演示

   • Scrum团队演示当前Sprint产生的产品增量
   • 有演示的东西，必须是测试通过的，产品负责人，验证符合验收标准的
   • 没有演示的东西，比如，架构和重构等，必须说服产品负责人，加入到Sprint的PBI中，让产品负责人，认识到其价值

2. 讨论

   • 产品增量的演示会成为深度讨论的焦点，积极鼓励参与者就产品和方向发表言论，评论与合理的讨论
   • 讨论使非Scrum团队的参与者能够提出问题，了解产品当前的状态，帮助指导产品的方向，同时，Scrum 团队成员，获得客户或用户的反馈意见之后，能够更深入的从业务和市场两方面理解产品

3. 调整

   1. 通过演示和讨论，团队能够提出并回答下面几个问题
      • 利益干系人喜欢他们看到的东西吗？
      • 他们希望看到变化吗？
      • 产品在市场上或对内部客户来还是一个好的想法吗？
      • 我们是否遗漏重要的特性？
      • 我们是否在不必要的特性上过度开发和投入？
      • 产品的增量，满足了干系人的期望吗，解决了他们的痛点吗？
   2. 大多数团队会在Sprint评审会上都会顺带做一些梳理工作，干系人更多的了解当前开发工作和进展情况，新增，修改，一些PBI，调整PBI的排列顺序，可能会影响下一个Sprint中的内容
   3. 根据梳理工作的影响，确定影响的范围和时间，调整版本计划，Sprint评审结束时找出调整方案，响应变化

二十二 . Sprint回顾

在回顾期间内团队可以无拘无束的检查发生的事情，分析自己的工作方式，找出改进的办法，制定改进计划，任何影响团队产品构建的事都可以仔细的检查，讨论，包括，过程，实践，沟通，环境，工件，工具等

每个Sprint都要举行回顾会议，检视和调整Scrum过程，尽早的发现问题，解决问题

怎样执行Sprint回顾

1. Sprint可以很简单，比如团队成员一起讨论下面几个问题
   • 这个Sprint那些地方做的好，需要继续发扬?
   • 这个Sprint那些地方做的不好，今后要避免?
   • 我们要开始做什么或改进什么?
   • 团队成员制定出一些可实施改进的措施，一次最好不要解决太多的问题，选取最有价值的问题，一起找到根本原因，并给出解决方案，并记录问题和解决方案，形成列表，方便以后对照，并贯彻执行

参与者

1. Scrum团队全员参加

准备工作

1. 定义回顾重点

   • 每次Sprint回顾都要有一个明确定义的重点默认重点是各方面回顾当前Sprint中使用的过程
   • 确定重点有利于回顾会议的准备和进行比如，数据，邀请参与者，缩短会议的时间

2. 选择练习活动

   选择合适的练习活动可以帮助参与者投入，思考，探索和决策，做好准备工作，保持灵活，典型的回顾会议包括下面几个二练习

   • 建立并挖掘Sprint事件的时间线
   • 通过头脑风暴获得见解
   • 将获得的见解进行分组并投票表决

3. 收集客观的数据

   短时间内完成的在回顾会议开始之前应当完成数据收集工作，比如，PBI的完成情况，燃尽图等

4. 安排回顾日程

   • 确定会议的时间，地点，以及会议的大概时长
   • 确定负责引导回顾的人，一般有ScrumMaster 做引导

方法

• 回顾期间要求分析团队的行为和表现，最好先营造氛围，让人们能够轻松参与
• 人们发表意见时必须要有安全感，不用担心，回顾侧重于组织体系和过程，不针对个人
• 建立一个积极参与的惯例也很重要，团队积极的发言，讨论