【老袁讲敏捷】Scrum 指南 学习笔记

自学笔记

带项目越来越迷惑，到底怎么做才是对的？如何才能带着队伍有质量的完成项目？

看【老袁讲敏捷】2020版Scrum指南精读系列视频进行学习

1.Scrum 定义

Scrum 是一个轻量的框架，用合适的方法解决复杂问题，目的是为了创造价值。需要 Scrum Master 创造一个 Scrum 环境，从而：

1. 将解决复杂问题所需的工作整理成一份 Product Backlog（产品待办列表）。@PO(Product Owner)
2. 在一个 Sprint 期间，交付价值->审视结果->收集反馈->调整。 @Scrum Team （PO，SM, DEV）
3. 重复。

Scrum 是一种理论指导，不是一种具体的使用说明，指导团队人员关系和互动。 Scrum 的实践内容需根据具体情况进行调整。

老袁观点：

1. 既然是框架，那么就得有填充物。如工作坊、技术、工具等。
2. 用于解决复杂体系的问题，简单体系的问题没有太大必要。
3. 最终目的是创造价值，如果不是创造价值一切等于白说。

Scrum 观点：

1. 不是详细的指令式的操作手册，需要搭配其他的流程技术和方法。
2. 依赖使用者的心态理念和聪明才智。
3. 以人为中心、指导做人，而不是指导做事。
4. 反馈机制让相对效能，可见，可感知，可反馈。

中国古话： 荀子：主好要则百事详,主好详则百事荒。 论语：为政以德，譬如北辰，居其所而群星拱之。

2.Scrum 理论依据

Scrum 来自

经验主义 主张知识来自于经验，所作的决定应该来自于对事实的观察。

精益思想 关注减少浪费而非关注本质。

三个支柱 透明、审视、调整

• 透明：要干的活对执行人员和接受工作的人员都是可见的
  • 自己人清楚我们团队在做什么，和客户清楚我们团队在做什么，都是同等重要的事情。
• 审视：交付物和共同目标的进度必须频繁地，勤勉地审视，以便发现潜在的偏差或问题。
  • 共同目标清楚，才能知道现实与目标之间的偏差。
  • 具体事实可以把共同目标打印出来贴在墙上，保证每个人都能说的清楚，并且事实更新。
  • Scrum 活动就是用来带来改变的，进行审视的活动本身，也值得审视，是否带来了变化。
• 调整：如果在任何环境的发展超出了我们能够接受的底线，或者产品的结果不可接受的话，就必须对现有的流程和在制品进行调整。而且调整必须尽快执行，以减少偏差。
  • 指出错误是简单的，改正错误是困难的。因为修复错误要付出代价（时间、金钱、情绪）。因此团队要有能选择支付代价的权利，否则不会修复。
  • 当相关人没有授权或自管理的话，想调整其实很难了。
  • 团队应当在发现问题的当下，就做出调整。当前不修正，永远不修正。是问题就解决，不解决就不是问题。

3.Scrum 价值观

承诺，专注，开放，尊重和勇气。

• 承诺达成目标并且相互支持
• 专注迭代的工作，以尽可能地向目标方向前进
• 对工作和挑战持开放的态度
• 成员相互尊重，彼此是有能力和独立的人
• 有勇气做正确的事并处理那些棘手的问题

这些价值观是团队行为准则，所作的事情都应该增强这些价值观，团队在日常工作中需要学习和探索这些价值观。当这些价值观深入人心的时候，Scrum的三根经验主义支柱，透明、审视和调整才能够实现，并且建立信任。

老袁：价值观是一个每个人都自以为很懂的东西，经常会被话语权更高的人，用他自己的理解去解释为更有利于他的那个样子，比如：

• 承诺：那团队必须保证完成任务啊，公司承诺下周要交付客户，加班大家没意见吧?
• 专注：客户的需求就是我们的专注，客户提的需求都得马上处理。别折腾什么团建、分享这类没用的东西。
• 开放：团队得保持开放的心态，要自己暴露问题，该问责的问责，该检讨的检讨。
• 尊重：我们要尊重客户，我们要尊重所有合作的人，遇到问题，首先反省自己哪里做的不好。
• 勇气：遇到问题就迎难而上啊！都是简单的事情，还要你们干嘛？肯定是要去解决别人解决不了的问题啊！解决不了，好好分析为什么解决不了。

因此，光提价值观还不行，得看价值观是否正确的被理解和执行，可以看高效能之树。

• 树根：5种价值观。
• 枝叶：活动表现
  1. 团队成员之间互相帮助。（承诺）
  2. 团队敢于承诺时间，而不是老板替他们承诺时间。（承诺）
  3. 大家专注于迭代中的任务，很少受到干扰。（专注）
  4. 大家对目标有明确的认识，每个迭代都尽可能地向着目标前进。（专注）
  5. 团队敢于和利益相关人讨论失败和不顺利的事情。（开放）
  6. 团队成员都敢于面对困难，甚至主动挑战难的事情。（勇气）
  7. 团队成员互相尊重彼此，包容不同人的独立性格。（尊重）
  8. 大家尊重与团队合作的人，也受到他们的尊重。（尊重）
• 果实：
  1. 为自己做的事情而骄傲
  2. 交付的价值有目共睹
  3. 相信我们无所不能
  4. 不断学习和进步，并乐在其中
  5. 采用所知道的最好的实践和方法
  6. 有安全的心理环境
  7. 互相充满默契和信任

4.Scrum Team 团队角色

基本单位是小团队即Scrum Team，包含一名Scrum Master，一名 Product Owner 和 Developers。 没有子团队或层级结构。Scrum Team 是具有凝聚力的专业团队，一次专注一个目标，即Product Goal。

队伍内成员具有在每个Sprint中创造价值而所需的全部技能。他们也是自管理的，这意味着他们在团队内部决定谁做什么、何时做以及如何做。 队伍人数不应超过10人。共享相同的Product Goal、Product Backlog 和 Product Owner。

判断人数是否足够的方法： 如果有1-2人请假，心慌，做不完事情，就是人少了。相反如果有1-2人请假，感觉效率反而高了，则是人多了。

Scrum Team 负责所有于产品相关的活动，包括与利益攸关者的协作、验证、维护、运营、实验、研究和开发，以及可能需要进行的其他任何活动。组织组建并授权 Scrum Team 自行管理他们自己的工作。以可持续的速度在 Sprint 中工作可以提高 Scrum Team 的专注度和一致性。

老袁解读观点：

1. 团队应保持足够简单。
2. 团队应自管理。
3. 团队人数应保持合理。
4. 保持可持续的节奏。

4.1.Developers

Developers 是 Scrum Team 中致力于创建每个 Sprint 可用 Increment 的任何方面的人员。 Developers 始终要负责：

• 创建迭代代办列表
  • Developer 每天自己建立工作计划，而不是向着 PO 或 SM 询问“接下来我该干嘛呢？”，也不是 PO 把 User Store 放在文档目录里，Developer 自己一个一个领任务的。
  • Developer 为了满足 Sprint 目标，我们应该做哪些事情。里面包含了对整体架构的优化，为提升质量做的一些工作，为团队做的一些改善，自动化的一些工具等等等等。
• 围绕着DoD（Definition of Done）建立质量
  • 太多的团队不停的抱怨质量不行，然而没有任何地方定义DoD，质量当然无从谈起。

  谁负责定义scrum中的 Definition of Done (DOD)？谁能判断用户故事是否完成？

• 每日向着迭代目标调整
  • 不应当敲定所有内容再进迭代。无论是用户故事还是工作任务，都不应当是文档约定好再进行迭代，而应该是在迭代的过程中及时调整。
• 作为专业人士相对彼此负责
  • 在条件和能力允许的情况下，团队中每个人都拿出了百分百的努力，每个人都这么做，也相信其他都这么做。这就是团队在一起工作的一个核心前提要素。

4.2.Product Owner

Product Owner 负责将 Scrum Team 的工作所产生的价值最大化。 Product Owner 还负责对 Product Backlog 进行有效管理，包括：

• 设计和明确交流产品目标；
  • 没有 Product Goal 就没有后续的一切
• 创建和明确交流 PBI（Product Backlog Items，产品代办列表）;
  • 设计和开发功能，解释给研发听，花费60-70%的时间在上面。其中绝大多数时间花在了写文档上面。较少的时间用在交流上面。
• 对 PBI 的组织排序；
  • 优先级的排序、迭代之间和版本发布的组织排序
  • Ordering 是一个持续性的工作，PBI 的排序永远不可能一步到位。随着认知的增加而调整，这才是 Ordering 的意义所在。
  • Ordering ≠ Prioritizing 不是一次性把列表拉出来，然后打上标签那么简单。常见的误区之一就是缺少了持续调整这个环节。
• 确保 PBI 是透明可见，被大家理解的。
  • 正如第三条所说， PBI 是一个动态持续调整地工作内容，自然带来了沟通上的挑战，需要做的不仅仅是对眼下要做的内容做一次或两次的沟通，而是要求 PBI 处于透明可见和被大家理解的状态。为了达到这一点，需要的透明、可视化的工具，以及验证对齐大家的机制，也需要大家去落实。

PO 可以自己做也可以委托其他小伙伴来做这些事，但是 PO 对这些事情负总体责任。PO 由于还要对接业务，导致一些事情忙不过来，需要其他人去分担一部分工作内容，但是业务目标，待办事项的优先级，业务的取舍，这些决定都必须由 PO 来决定。

整个组织需尊重 PO 的决定，这些决定将在 Product Backlog 里面体现出来，并可在 Sprint review 时进行审视，Product Owner 是一个人，不是一个委员会。PO 可以代表许多干系人的需求，但是所有的需求更该需征得 PO 的同意。

Scrum 框架下的 PO 类似一个团队的 CEO , 其他干系人相当于董事会，董事会可以开除 CEO 但是不是代替 CEO 做决定。

PO 的三个类别：

1. 文档驱动
   • 在文档里写好待开发的功能列表，按事前预估的时间来检查验收，发现问题之后再修修补补。
2. 进度驱动
   • 关注业务进展和开发进展，与开发团队频繁交流澄清，频繁与开发团队协商，懂得取舍。
3. 目标驱动
   • 设立业务目标，并驱动团队一起为之努力，关注的是各阶段的业务目标，以及各阶段的关键业务指标，能辅助开发团队制定阶段目标的实施计划，并通过关键业务指标审视进展。

4.3.Scrum Master

Scrum Master 敏捷教练有两个职责：

1. 依据 Scrum Guide 建立 Scrum 框架，在 Scrum Team 内和组织内，让大家理解 Scrum 理论和实践。 2. 在组织内建立 Scrum 文化，传播 Scrum 的文化理念。
2. 提升 Scrum Team 的效能，在 Scrum 框架内，让团队能够不断的改进实践。 4. 通过好的实践提升团队效能。

Scrum Master 的工作内容：

围绕 Scrum Team 的工作

• 教练自管理和跨功能能力，
  1. 实现自管理，组织上要信任团队，团队也要证明自身的能力。逐步实践半自管理和全自管理状态。
  2. 跨功能，可以通过结队来实现。比如开发+运营，提升自动化的持续部署能力；测试和产品设计人员结队写作可以让测试左移，测试和运维协作可以让测试右移；开发和产品写作，可以让开发小伙伴们学会产品的设计思维。Scrum Master 需要促成或教练这些结队写作。
• 帮助团队专注价值和 DoD
  1. 帮助指得是敏捷教练不会代替团队做团队本身应该做的事情，例如管理项目进度、编写自动化工具。敏捷教练的工作是帮助，不是监督、不是管理，也不是替代。可以提供一些优化的建议，更好用的工具，或者是更方便、更合理的工作方式和环境。
  2. 专注指的是在日常工作中团队会因为各种各样的事情分散精力，有团队主动想做的，但并都跟 DoD 或者是交付物有关。敏捷教练需要做那个提出问题的人。“这件事情跟交付价值有关吗？”、“哪些事情可以少做？哪些事情可以多做？”。团队要要重点关注 High Value Increment 和 Definition of Done，如果缺少 DoD 或 价值关注，敏捷教练是难辞其咎的。
• 移除障碍，保障 Scrum 活动
  1. Facilitator，把事情简单化
  2. Coach
  3. Helper

围绕 Product Owner 的工作

• 1,2. 帮助 PO 找到有效定义产品目标 (Product Goal) 的方法，帮助 PO 有效管理产品待办列表。帮助团队简单直白的明白 PBI。
• 3. 建立符合经验的产品计划，来应对复杂的环境
• 4. 促进于利益干系人的协作

主要涉及三个内容：Product Goal、Product Backlog、Product Planning，这三个内容都是与价值交付息息相关的内容。Scrum Master 有责任帮助团队，更好的理解和定义，内部和外部对齐。如果这些内容都没有被充分理解或者定义，Scrum Master 需要识别出来背后的问题，并帮助大家来解决。

至于促进相关干系人的协作，则是归属于 Facilitator 的范畴。

对于 PO 来说 Scrum Master 是 Facilitator 和 Helper

围绕 Organization 的工作

• 1,2. Leading、Training、Coaching、Planning、Advising。布道推广 Scrum 。一位 Scrum Master 只需要坚持敏捷信念并不断影响他人就好了。
• 3. 帮助员工和干系人理解并实施经验主义方法来面对复杂的工作。 实施经验主义即实施三个支柱理念，透明、审视和调整。
• 4. 消除干系人和团队的隔阂。Scrum Master 在与组织协作之间充当着积极重要的作用，建立沟通桥梁、建立信任、建立统一的文化、建立透明、审视和调整的工作方式。这些背后都有一个很重要的目的，就是能够让团队有自管理的环境。这也回答了上面关于 Scrum Team 里面的自管理如何实现的问题。这并不仅是团队需要学习的一个技能，而是背后围绕着利益干系人和团队的一系列工作，回归到最后，团队需要自己掌握如何与干系人合作，Scrum Master 只是消除其中的障碍，以及促进合作的发生。

总结

Scrum Master 需要运用 Scrum 里的原理和实践，为团队的效能负责。

对外需要协调团队和利益干系人的关系，建立能够允许团队自管理的内外部信任管理，以及适应复杂情况的透明、审视和调整的经验主义机制。

对内需要一方面帮助团队理清业务三要素，即是 Product Goal、Product Backlogh和Product Plan。另外一方面帮助团队建立能够起支撑理的能力，即是跨职能的协作能力，对价值的关注和对 Definition of Done 的关注。

无论对内对外不需要纠结 Leader、Coach 还是 Facilitator 等等帽子，Scrum Master 都得有那种闲人马大姐的觉悟，见到不对的事情需要抛出问题，然后把空的可乐瓶扔进垃圾桶。

5.Scrum Events 活动

5.1.Sprint 迭代冲刺

Sprint（迭代冲刺） 是 Scrum 的基本单元，所有的活动都在 Sprint 内组织，每个活动都是一个正式的机会来审视和调整交付物，这些活动都是为了透明化而专门设计的，没有执行 Scrum 内的活动会失去调整的机会。 Scrum 使用活动来创造规律性，并以此最小化对 Scrum 中未定义的会议的需要。

最理想的是，所有活动都在同一时间、同一地点进行，以便减少复杂性。

对敏捷团队的期待：

1. 保持规律 regularity
2. 减少复杂 reduce complexity
3. 减少会议 reduce the need for meetings

如果在 Scrum 活动中觉得很累人的话，可以给自己把把脉，看看自己团队是否接近这三个期待。

• 我们是把事情搞复杂了还是搞简单了呢？
• 我们的会议或者其他不必要的事情是增多了还是减少了？

Sprint 迭代冲刺

Sprint 是冲刺或者迭代，是 Scrum 的心跳，这期间将想法变成价值。Sprint 的特点有：

1. Sprint 的长度是固定的，以保持规律性。
2. 跨度是一个月或者更少，以保证时效性。
3. Sprint 结束即开始下一个 Sprint，以保证连贯性。

另外，为了达到迭代目标，Sprint 的里面除了日常的开发工作之外，还包括了迭代计划 Sprint Planning，每日站会 Daily Scrum，评审会议 Sprint Review，回顾会议 Sprint Retrospective。

Sprint 期间

1. Sprint Goal 不能受任何改变影响
2. 质量不可妥协
3. Product Backlog 按需细化
4. 随着认知的增加，辩解可以和 PO 一起澄清和协商。

老袁：可以理解是Sprint的三大要素，即：

1. 明确的迭代目标。有了大家都明确的迭代目标，才能谈得上迭代目标是否受了影响。
2. 不可妥协的质量。交付物并不是做完就完了，应当为质量付出的努力不能减少，符合 DoD 才算完成。
3. 符合认知的PBI。待办列表的内容和组织排序符合团队当下的认知。另外关于迭代目标的重要性，待办列表的按需细化和开发的内容，可查看【老袁讲敏捷】定Sprint Backlog是固定需求吗？对它的误解是有多深。

迭代周期短

为什么设置一个短的迭代周期？及时审视和调整，保证了迭代目标的时效性，控制复杂度、控制风险，缩短学习和反馈周期。

老袁：

如今在项目团队管理中，相信大部分团队，尤其是管理层对于缩短反馈周期都已经表示接受和认同，更短的反馈周期能够让管理层更快的看到项目是否有令人满意的进展。更直白点，可以看到员工是否在划水，如果看到员工拿出120%的努力在埋头干活，老板或者客户的焦虑感也会感到缓解。看到待办事项数量减少，老板和客户也会感到胜利在望。理论上有100个任务项，那么在项目进行到一半的时候，我应该完成了50个任务项，如果没有则存在延误、加班、客户管理等问题浮出水面。

是不是很熟悉？但是刚刚说的这些避免员工划水、跟踪项目进度、减少老板和客户的焦虑感，没有一个是设定 Sprint 的目的！也不是 Sprint 的意义所在!

有很多工具能够帮助我们了解项目进展，比如燃尽图 burn-downs，燃起图 burn-ups 或积累流图 cumulative flows，但是它们不能代替经验主义。在复杂的环境下，未发生的都是未知的，只有依赖过去已经发生的经验才能帮助向前决策。

老袁：

我个人觉得，与其叫经验主义，不如叫「认知积累」,过去积累的认知符合那个时候的情况，而当下的认知积累，是唯一能够帮助当下做最正确决定的，认知积累的过程，也符合 Scrum 理论里提到的透明、审视和调整三根支柱。

如果迭代目标无效了，迭代是可以取消的，只有 PO 有权取消迭代。

5.2.Sprint Planning 迭代计划会议

团队的开发能力以故事点进行计算。

Sprint Planning 要把 Sprint 中要做的工作整理出来，最终的计划是由整个 Scrum Team 协作创建的。

PO 要确保参加者已充分准备好讨论最重要的 PBI，以及它们如何映射到Product Goal。Scrum Team 还可以邀请其他人参加 Sprint Planning 以提供建议。

老袁： Sprint Planning 三大坑

事前充分沟通，不是发一份邮件或者发一份共享文档就完事了，Sprint Planing 不应该是 PO 首次宣布开发方向的场合，这样会浪费很多时间去做项目背景介绍和关于可行性、合理性的争论。也不是澄清所有 PBI 需求细节的场合，细节应该在迭代过程中澄清。更不应是大家摁手印，保证完成多少个用户故事点的场合。如果想要更多的故事点，开发团队报一个虚高的故事点就行了。

那么 Sprint Planning 里面应该做哪些事情呢？

迭代计划会议三部曲：

1. 为什么这次 Sprint 有价值？
   • PO 提议和解释在当下 Sprint 中，产品有哪些方式可以增加价值和功能（欢迎大家PK）
   • 接着整个 Scrum Team 共同定义 Sprint Goal，这个 Sprint Goal 将会跟利益干系人说明，为什么这个 Sprint 值得做，Sprint Goal 必须在 Sprint Planning 结束前定义清楚。
   • 如果没有讨论出一个透明的 Sprint Goal，这个会议相当于没开。
2. 这次的 Sprint 能完成什么？
   • 通过与 PO 讨论，开发团队选择进入当前迭代计划的 PBI，团队可以讨论明确这些 PBI，选择多少 PBI 是有挑战的，然而团队知道过去的表现，接下来的产能（排除请假、其他干扰），以及明确的DoD，就能在迭代预期中更有信心。

   老袁：

   结合一下现实情况，文中提到了两次信心 Confident。在迭代计划中，信心经常是团队面临最大的问题。

   对于业务的不清晰、对技术的不清晰、外界的影响、第三方的依赖、风险等等，有许多不确定性因素，即使在迭代计划中一一澄清，也只能符合团队当下的认知。

   大家心里也清楚，一旦有任何的变动，需求的变动，团队的变动等等，事情很快就能变得不受掌控，这是不可避免的困难。团队信心决定哪些能做，哪些不能做。然而团队信心来自于哪里呢？

   指南里提到了团队的能力，项目经验，验收标准等等，除此之外，在迭代计划中，团队信心也取决于隐藏着的另一个因素，也就是组织和团队之间的信任，如果团队外部给团队很大压力，完不成就必须加班、责罚，必须交付多少个故事点。没有协商的空间，那么团队就会谨慎的在迭代计划中要求一一敲定细节并且保守的估计迭代中的内容。

   毕竟一个迭代多干少干也是那么长。真的有必要招来更多的麻烦吗？

   相反如果团队信任组织，组织也信任团队。团队会更主动的尝试做正确的事情，完成更多的挑战。交付更多的价值。

   在我的经历中可以很确定的说，对于组织的信心和对业务需求的信心同等重要。这是在指南里未提到的内容，另外在这个主题中，所有 Sprint 都是预测 (forecast)，也仅仅只是预测，意味着过程中可能会进行调整。

   在保证 Sprint Goal 的前提下，调整内容是可以被接受的。

3. 如何完成所选的工作？
   • 迭代中被选中的工作即 PBI，开发团队针对这些工作，制定能够满足 DoD 的实施计划。前期需要做哪些准备、过程中依赖如何解决、前后端开发如何验证是否满足DoD、哪些优化和自动化的工作需要做？这些需要做的事情，不应该限于某一个 PBI 以内，可能会涉及整个迭代，是真正需要计划的内容。团队常常把这些需要做的事情，分割成一个一个的工作项 (Work Items)。这些工作项有哪些、如何组织、由谁完成，由开发团队自己全权决定，这就是实施计划。其他不参与开发的任何角色，都不应该指挥开发团队，如何制定实施计划。

Sprint Planning 的三个输出：迭代目标、选中的PBI、实施计划组成了Sprint Backlog。

迭代计划会议时间限制大约是迭代中的星期个数 * 2。比如 4个星期的迭代，会议不应超过8小时。很多团队两个星期一个迭代，则会议不超过4小时。

老袁： 我认为这是每个敏捷团队中最让人疲倦，最容易产生分歧的地方，没有一个有成效的 Sprint Planning，一个有效的 Sprint 也就无从谈起。

5.3. Daily Scrum 每日例会 每日站会

每日站会的目的是为了审视迭代目标的进度，调整Sprint Backlog，调整接下来的工作计划。

点评：

常见的站会有很多种，有的是领导高谈阔论，团队沉默不语。也有是流水台账似的站会，你做了什么，我做了什么，他做了什么。也有的变成方案讨论会的站会，钻到技术细节里面讨论了起来。

站会的目的，既然有审视 Sprint Goal 的进度，那么肯定要明确一下 Sprint Goal 在哪里，我们在哪里。站会的目的也有审视调整工作计划的必要性，那么肯定也要看一下，工作计划符不符合现在的情况。如果没有提到 Sprint Goal，也没有宏观看一下迭代的工作计划，那么站会肯定是没有达到审视和调整的目的的。

每日站会是一个15分钟的活动，参与者是开发团队。每天在同一时间同一地点举行，以减少不必要的麻烦。如果 PO 和 SM 也参与了 PBI 里的工作，他们也跟开发团队一同参与。

点评：

每日站会必须参加的人是开发团队，这一点毫无疑问，那么问题来了，如果 Team Lead 请假或者几个团队成员请假，那该怎么办呢？即使不能参加远程站会，剩下的小伙伴们的站会依然有必要开，坚持开站会这一点比在同一时间，同一地点开站会更重要，即使团队仅剩下一个人在，在同一时间和地点整理一下 Sprint Goal 和计划，然后再开始一天的工作，都是极其有必要的。也完全符合 Daily Scrum 的初衷。

另外，尽管在文中只是一笔带过，但是 PO 和 SM 在站会到场的必要性是非常非常大的。如果 PO 不是随叫随到，并且业务信息不一定跟所有人同步过。每日站会是一个很好的机会，让 PO 可以更新一下业务的信息，与大家确认 Sprint Backlog 的调整情况。让开发团队和业务人员能够频繁的信息同步是透明、审视和调整的重要环节。另外 Scrum Master 在站会上能够识别出团队可能会出现的问题，并提出疑问，这样会比在大家工作过程中发现问题，然后再介入会好很多。尤其是在对 Sprint Goal 方面的问题。是不是大家有一致的理解，业务价值是否得到了关注，Scrum Master 需要以第三方的身份进行观察。

但是总而言之，站会的时间不应该超过15分钟，应该保持一个轻松愉快的方式开始一天的工作。参与人应当避免说教的内容和复杂信息的分享，否则很容易超时，并且让大家跳出刚才的思维，回到工作上又需要一定转换脑筋的时间。

只要每日站会大家都聚焦在迭代目标的进展，以及当日可执行的工作计划，开发团队自主选择它们想要的实现方式。这样增加专注度并提高自管理能力。这没什么好说的，开发团队为自己的代码负责，相信大部分团队都能做到。

每日站会会增加交流，识别障碍，促进快速决策，因此排除其他会议的必要。每日站会不是开发团队交流和调整的唯一实践。他们在一天之中经常碰面详细讨论如何调整，甚至重新计划剩下来的迭代内容。

这里说每日站会会排除其他会议的需要，相信大部分团队无法做到，我只能说理解作者的用意是精简会议时间，但是很多技术方案和业务沟通以及过程中的决定，是无法在站会上完成的。极大可能需要一些成员围在白板前面写写画画才能梳理清楚。因此，每日站会并不是大家唯一聚在一起讨论的机会。日常大家就可以离开座位，聚在一起讨论问题。但这并不需要像正式会议一样，加上所有人发邮件邀请，约会议室，甚至还要做会议纪要等。

一个很好的实践就是在站会上，没人陈述经典的三个问题：昨天做了啥？今天要做啥？有没有什么问题？然后主持人回顾一下迭代目标:我们的迭代目标是……有没有问题？然后看一下目前的 PBI 和实施计划，有没有需要调整的地方，整理一下看板，最后有没有需要分享给大家的信息或者知识。

在过程中如果识别出来一些站会中没有时间做的事情，当下就记在旁边，等站会结束后，相关的人员留下，在白板前讨论这些内容。其他无关的小伙伴们，可以着手开展今天的工作。

曾经有多次自己参与的团队和在别人分享的案例中都有过个别团队成员，不愿意参加每日站会的情况，有人说站会是浪费时间，各自的任务和进度都已经同步在看板上了，谁关心进度可以自己去看，自己平常该沟通的信息都已经沟通过了，站会上重新说一遍真的没有必要。

也有人会说自己的工作不需要别人协调，肯定不会延时也不会出现问题。无需同步给别人也没空去管其他成员的工作。

也有的小伙伴参加站会，但是两眼放空，人在这里，但是已经神游很远了。

我的意见是，优秀的团队应该能够包容下不同的元素，一定不要将某件事情政治化。评价一个人是看他是否为团队做出他应该创造的价值，而不是参不参加站会，这是基本原则。

在实践中可以考虑以下几个问题：

1. 站会的形式是否很官方很枯燥，站会需要一个合适的主持人，建议有一个轻松愉快的氛围，这个主持人建议大家都来当当，组织站会也很能锻炼表达能力。
2. 站会的时间是否控制得当，如果是快刀斩乱麻的开会，理应不会给大家一个浪费时间的感觉，如果总是有人长篇大论，那少不了引起反感。每个人控制在1分钟以内的发言时间，言简意赅，相信效果会好很多。听说有平板支撑发言🤯，说的过多自己就撑不下去了，自然就没有废话了。
3. 日常工作的方式，为什么团队内部的工作不需要沟通呢？有没有存在信息孤岛，知识孤岛，团队内部有没有分裂的小团队，或者是边缘化某人的问题。某些人请假或离职的情况下该怎么处理呢？不愿意开站会所反映出来的更多的是团队内部缺少结队，缺少协作，缺少良好的团队氛围。

最后在日常工作中需要敏捷教练或者是 Team Leader 创造人性化的工作氛围。好的 Leader 会经常关心团队情况，问一下最近有没有困难，客户有没有找麻烦，第三方有没有配合，需不需要怎样的帮助等等。当你经常把一些话挂在嘴边，例如：不要找借口；我不关心过程，我要的是结果；我不听问题，你们就是应当解决问题的；不要抱怨，抱怨就是没能力。这样的话团队成员当然就没有必要跟你同步进展了，因为说了也是白说，透明、审视和调整都是飘在空中的云朵没你什么事。

5.4.review & retrospective

评审会议和回顾会议经常是团队不知道怎么组织或者是组织效果不好的

评审会议 Sprint Review

评审会议的目的是为了审视迭代的成果，并决定将来如何调整。 Scrum Team 向干系人演示他们的工作内容，大家讨论目前对于产品目标的进展。

在过程中，Scrum Team 和干系人回顾迭代中完成的工作，已经发生了的变化。基于以上的信息，大家决定接下来做哪些事情，产品待办列表该如何调整。 Sprint Review 是一个工作型会议，应对避免仅仅局限于演示部分。

Sprint Review 也是有时间限制的，对于一个月的迭代而言，会议时间限制于4小时之内，那么2周迭代的话，应该限于2小时之内。

老袁：聊一聊实践中经常遇到的问题 有的时候评审会议仅仅是一份上线通知邮件，有的团队会说产品上线了，业务人员或干系人他们自己去线上看就好了。我们也会邮件告知大家新上了什么功能，这不就足够了吗？有必要当面演示吗？万一演示过程中客户想法要变了，又需要改需求怎么办，这么多都已经做完了，想改那也来不及了。那不如不演示，满意也好，不满意也好，那就是这个东西，咱们按最初的约定做完了。最不愿意的，就是看到不靠谱的甲方又改需求，或者是不靠谱的领导，又冒出什么新点子。

是的，这么做往往能把事情糊弄过去。但是产品往往也被客户糊弄过去了。 一个常见的场景就是，过段时间问客户，我们之前上线的功能用的怎么样了？往往的回答是，啊？什么功能？最近没看，以后再看吧！ 等我们大家把这个事忘得一干二净的时候，用户那边突然说：哎呀，之前这样做的不对呢，用不了啊！然后大家再着急的翻历史旧账。 总结一下的话，评审会议讨论两点：

1. outcome 成效、效果，而不仅仅是迭代产出的 output。开发人员可以把功能上线，但是带来的价值需要综合各方面的反馈。比如说，市场部门可以开始推广哪些活动了；用户可以开始做什么样的操作了；用户可以提升哪方面的效率了；使用的情况如何等等。
2. 围绕着 Product Goal 也就是产品目标，我们还应该做哪些事情。评审会议中，除了演示成功的掌声之外，还会有用户或者领导提意见，有的地方需要改动甚至重做，这是评审会议存在的意义。但也不能变成了用户或者领导，天马行空、高谈阔论的场合，可以有用户或者领导发表意见，但是需要判断这些意见是否符合我们的产品目标或者近期的目标。如果不符合产品目标，那么就应当被忽略掉，或者如果近期不考虑做，那么不妨等到需要做的时候，我们再展开讨论。如果业务专家指出了产品存在的重大问题，或者大家对于接下来要做的事情，有了一个明确共同的意见，不妨局限在这些范围之内，毕竟评审会议并不是吹吹牛，大家发表下意见就完了，会议是围绕着 Product Goal、Product Backlog 进行的。评审会议的产出是更新过的 Product Backlog，另外指南里没有提到过的 Product Plan，也就是产品计划，作为产品三要素，可以在评审会议中回顾一下，看看是否需要调整。

最后总结一句话，与其怕客户提意见，不如与客户一起梳理它们的意见，该 PASS 就 PASS，该以后再说就以后再说，该马上处理就马上处理

回顾会议 Sprint Retrospective

Retrospective 的目的是制定提升质量和效能的方式和计划。

Scrum Team 审视本次迭代中的内部各个方面表现，个人，互动，流程，工具以及DoD等。 审视的内容根据工作领域也会不一样。 在迭代过程中，有一些假设曾经误导了团队，这里需要探究一下这些假设的起源。

Scrum Team 讨论一下迭代中，做的好的方面，遇到了哪些问题，这些问题是如何解决的，或者遗留下来了哪些问题。

Scrum Team 定位哪些是对提升效能最有帮助的改变，最值得做的改进将尽快被安排，甚至放在下一个迭代中去落实。

Sprint Retrospective 是本 Sprint 最后一项，对于一个月的迭代而言，时间限制为不超过3小时，那么2星期的迭代，时间也应该控制在一个半小时内。

老袁：实践案例 经常碰到的问题，是回顾会议成了思想政治教育，批斗大会或者是吐槽大会。首先团队能开回顾会议或者复盘是一件好事，证明组织在意团队的成长，也能够意识到回顾或者复盘，能够帮助到团队成长。但这可能只是管理层的想法。实际过程中团队成员是否把回顾会议当成一次组织改进的机会，并且能够落实一些改进的尝试那么就是另外一码事了。建议看【老袁讲敏捷】#6，团队成员说回顾会议一点用都没有，怎么办？

回顾会议与评审会议不一样，是团队的闭门会议，组织回顾会议的方法也有多种多样。有时间-心情曲线图；有well, Less Well, Puzzle, Suggestion 或者其他类似的四象限；也有海星图等等的五花八门的方法。

但这些所有的方式都是为了一个目的，找到团队最应当着手改进的几件事情，并且组织实施。包括我们梳理迭代过程中做了哪些失败的假设，踩过哪些坑，并不是要责备某位团队成员，或者进行团队思想教育，这些都是被证明短视和无效的操作。最终的目的，还是希望改进组织的方式，梳理出来的改进建议，应当源自团队成员的想法，并且由团队成员组织实施，这些改进建议也应当遵守 S.M.A.R.T 的原则，也有相应的 DoD 来衡量，也应当遵守在制品限制的原则，有时效性。避免有太多的事情堆积。避免形成团队的惰性，如果这样最终会让团队对回顾会议失去了信任。

最后总结一句话。回顾会议最核心的产出是改进计划。怎么该？谁来改？什么时候改？怎么样评判是否达到目的？只要抓住会议的目的和产出物，那么会议的成效就不会差太远

6.Scrum Artifacts 交付物

老袁：交付物是非常核心又非常难以掌握的部分，涉及到的例如 Product Goal。Sprint Goal， Definitaion of Done 这些概念都很重要，但却在实践中经常被缺失的部分。我接触的敏捷团队中，经常看到 Scrum 各个角色有了，Scrum 迭代中各种会和流程议也有了，但是对于 Product Goal, Sprint Goal 和 Definitation of Done 完全没有概念的情况，导致在整个敏捷实践过程中，手忙脚乱，像打乱战的感觉。我常常用一个比喻，在行军打仗的时候，最让队伍害怕的不是对方人多势众，或者是自己的装备很差，而是不知道敌人是谁，不知道枪口应该冲哪，这样最让人害怕了。

Scrum 交付物这一个章节的目的，就是为了让大家更好的找到，团队要消灭的敌人是谁，他在哪。

Scrum Artifacts 代表了工作或者价值。它们是为了将关键信息透明化最大化而设计的，因此，所有人在调整的时候，就有了共同的基础。

每个 Artifacts 都包含了一个承诺，他能够有助于透明度和专注度，基于此，我们才能衡量产品的进度。

Artifacts 即交付物，有三种：

1. Product Backlog，它的承诺是 Product Goal，也就是产品目标。
2. Sprint Backlog，它的承诺是 Sprint Goal，也就是迭代目标。
3. Increment，他的承诺是 Definition of Done，也就是完成的定义。

这些承诺将会强化认知积累，以及整个组织的 Scrum 价值观。

6.1.各种交付物词汇的含义

第一个词 Arifacts 代表了工作或者价值，就是交付内容（交付物），无论是迭代中交付的，迭代完成之后交付的，还是产品总体交付的，都是工作和价值。

第二个词 Commitment，专属于一个活动、事业的状态或品质。翻译成承诺少了点意思，承诺有点像保证书、合约，强调约定好做一件事情这个动作。在这里的 Commitment 更强调事情应有的状态或者品质。所以这里的本意是，无论 Product Goal, Sprint Goal, Definition of Done，这些Commitment，重点不是强调团队做某件事情，而是这些交付物应当达到的状态和品质（不是承诺做，而是承诺做成什么样）。

• Product Blacklog 的 Commitment 是 Product Goal；
• Sprint Backlog 的 Commitment 是 Sprint Goal；
• Increment 的 Commitment 是 Definition of Done。

强调这几个 Artifacts 和 Commitment 之间的关系是 2020 版 Scrum 指南里相对于前版本的非常大的一个改动。

第三个词 Increment，很多地方翻译成增量，感觉有点别扭，但是也算还好理解。

Increment 不一定是程序员的代码提交，也不一定是某个 User Store，某个功能，也不一定是某个临时开发分支，也不一定是某个上线的版本。我的理解，Increment 更准确的翻译是在 Sprint 过程中的一次价值交付。

第四个词 Empiricism，它不应当翻译成经验主义，而应是知识积累（认知积累）。经验主义是个贬义词，说的是过分强调用有限的经验，把局部的经验误认为是普遍真理。在实际过程中狭隘保守、眼光短浅。这里绝对不是一个贬义词，而是一种科学的、必要的积累认知的思维方式。所以认知积累可能会更贴切一点。

6.2.Product Backlog 待办事项列表

产品代表列表是一份实时动态的和先后排序的列表，描述产品需要改善的地方，也是 Scrum 团队工作事项的唯一来源。

通常经过需求细化之后，如果这个产品待办事项，也就是 PBI，大家认为能够在一个迭代中完成，那么它也就可以放在迭代计划会议中进行讨论了。

产品待办列表的细化是将产品待办事项逐步拆分，逐步细化的过程。这是一个持续增加细节的过程，像描述、先后顺序、大小等等，可以添加的信息因工作内容而异。

开发人员最终决定一件待办事项的工作量大小，PO 可以通过澄清需求、选择取舍来与开发人员协商。

Product Backlog： D.E.E.P 原则， 持续动态，持续细化。

分层细化是敏捷中一个很推荐的实践。通常我们会分三个级别的需求。Epic 级别、Feature 级别、Story 级别。

Epic 级别的需求会比较宏观，不会有很详细的内容；Feature 级别次之，描述的是功能模块级别的内容；Store 级别的需求会比较详细，团队会对功能需求、可行性、时间大小有较为准确的概念。

通常会选择 Store 级别的待办事项进入迭代，并且在迭代中进一步细化，甚至会拆分成更细的工作任务。在细化过程中，工作量的评估，有些时候是火药味很浓的步骤，践行敏捷的团队往往知道敏捷估点、斐波那契数列（1、2、3、4、8等等），有的开发团队和 PO 之间， 会因为一两个点争执半天，争执的重点往往是故事点数大小。然而呢，其实更应该关注的是 trade-off 妥协和排序 ordering。

有没有一些可以舍弃的功能或者效果，或者是先后做哪一些 PBI，这很重要。

Ron Jeffries 曾经自己说过这个有意思的话 "I may have invented sory points, and if i did, i'm sorry now."

有时前期沟通理解没有问题，估点也没有问题，但开发人员在不是很重要的功能上花了巨大代价，而导致真正的功能很久才能发布，这其实不是 PO 所期望的，如果团队和 PO 可以多沟通一下，选择合适的功能做妥协(trade-off)，情况可以好很多。这样的案例比比皆是。

6.3.Commitment: Product Goal 产品目标

承诺：产品目标

产品目标描述的是产品未来的状态，这也是 Scrum Team 指定实施计划的目标。

产品目标是产品代表列表的内核，产品代表列表的其他部分，将实时动态地描述产品目标该如何达成。

一个产品是传递价值的载体。它具有明确的边界、已知的利益干系者和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。

Product Goal 是 Scrum Team 的长期目标。必须先实现（或放弃）一个目标，然后再开始下一个目标。

老袁： 我的理解，Product Goal 可以随着产品的进展而修改或者演化，变得更清晰。这是 PO 的重要工作之一。但是不能同时存在两个 Product Goal，这是很荒唐的。不同的产品目标应该应用在不同的团队上，起码在同一团队的不同时期采用。不能胡子眉毛一把抓。我曾经经历过很多团队，其中老旧平台的维护要保障，新平台的建设要如期进行，另外还要做很多创新型的尝试。在这种情况下，确实团队会一直处于很混乱，丧失目标的状态。

Product Goal 在新版指南里是新加入的一个元素，坦白说是比较难以理解的，但这个概念不是新发明出来的。各个团队常常会提到类似 Product Vision, Bussiness Goal，愿景，产品战略等等概念，但它们与 Product Goal 并不一定是一回事。另外一个好的 Product Goal 能够指导 Sprint Goal 如何制定，一个不好的 Product Goal 让人摸不着头脑，也不知产品做了多少，进展如何，到底做完了没有。

为了分清 Vision, Business Goal, Product Goal，我们可以举一个例子。

Vision 愿景。愿景的特点就是永远不可能达到，并且有很重的社会属性，并不用来衡量进度，只是用来判断对错，例如：“让天下没有难做的生意”、“让世界人民更健康”。

Business Goal 业务目标。跟商业挂钩，必须要确定市场、用户人群，收益规模。这些都与商业模式是直接相关的。例如：“占领电动牙刷线上销售的15%的市场份额”、“成功运营武汉市1000个产生月度净收益的电动汽车充电桩”。

Product Goal 产品目标。需要聚焦到一个产品上来，因此使用这个产品的用户也就固定下来了。产品目标定义了用户在产品上的使用情况。另外一个 Product Goal，应该有明确的“达到”还是“未达到”的分界线，进度可衡量。例如：“100%的用户全部开始使用2.0版本的平台”、“70%的用户创建了用户健康档案”。

以“70%的用户创建了用户健康档案”这个目标为例。为了达到这个产品目标，需要做一系列事情。例如用户能够建立健康档案、平台要引导新用户注册时建立健康档案、平台引导老用户去创建健康档案等等。

这一系列的动作就可以做为每个迭代的迭代目标。

由此我们能够看出，合格的产品目标 Product Goal 是能够承接产品愿景和业务目标的，并且能够为迭代目标提供指导，能够衡量产品进度，也能够明确产品本阶段是否成功的唯一标尺。

6.4.Sprint Backlog

Sprint Backlog 由三个部分组成：

1. Why Sprint Goal， 迭代目标
2. What Product Backlog Items PBI，产品待办事项
3. How actionable plan，可执行的计划

为了达到迭代目标，Sprint Backlog 将由开发团队自己制定并执行实施计划，这个实施计划有几个特性：

1. highly visible 高度可见的。
2. real-time，update throughout the sprint 在迭代过程中实时更新的。
3. toward sprint goal 以 Sprint Goal 为导向的。

每日站会上，大家可以审视这个实施计划，是否顺利地向着迭代目标前进。

6.5.Commitment: Sprint Goal

承诺：Sprint Goal 迭代目标

迭代目标是迭代的唯一目的。虽然迭代目标是开发团队的承诺，但工作具体如何实施是有充分弹性的。迭代目标也保证了连贯性和专注度，让团队协作工作而不是各自为战。迭代目标是在迭代计划会议中定义出来，加入到 Sprint Backlog 里的，开发人员在整个迭代过程中，时刻谨记迭代目标，如果工作内容与预期的不符，开发团队则需要与 PO 一起协商该如何调整 Sprint Backlog 的范围，而且不影响迭代目标。

总结一下，迭代目标的特性：

1. 弹性的，迭代目标不会对团队具体实施内容或功能进行限制。
2. 连贯性和专注。迭代不应当是一系列不相关的事项列表。比如说我们要修改 5 个 bug，4 个功能，这不叫连贯和专注。
3. 不可改变。Sprint backlog 的范围可以协商，但迭代目标不可以改变。举一个正面的例子：本次迭代的迭代目标是“开启创建通道之后，平台能够验证老用户是否愿意创建自己的健康档案”。 反面例子：“用户能够点击创建按钮，填写姓名，联系方式，家庭住址后，创建健康档案，并且修改编号为111,222,333,444号的bug”。

6.6.Increment

一次价值交付是迈向产品目标的一个深深的脚印。

每次价值交付都是在之前的价值交付上前进了一步，并且是认真验证过，以保证所有的交付都能够有效。为了产生价值，价值交付必须处于可用的状态。

一个迭代中可以有多次价值交付，迭代评审会议将会对它们进行审视，有助于积累认知。但是价值交付可以在迭代过程中发生，并不一定等带爹的结束，迭代评审永远不应该成为价值交付的关卡。

一个工作如果不符合 DoD 的话，就不能作为价值交付的一部分。

总结 Increment 价值交付的特点：

1. 是向着产品目标前进的。
2. 对之前的质量不能有任何回退。
3. 是可以使用的。
4. 满足 Definition of Done 完成的定义。
5. 尽早交付的。评审会议的审视只是为了积累认知，并不是允许交付的前提，符合完成的定义就可以交付。

6.7.Commitment: Definition of Done

完成的定义 DoD 是价值交付的一个正式的要求描述，约定了当价值交付符合产品质量要求时，所应当有的状态。

当一个产品待办事项符合了 DoD，就变成了一个价值交付。

DoD 为所有人统一明确了哪部分工作完成还是没有完成。如果产品待办事项没有符合 DoD 中的要求，它是不能发布，也不足以在评审会议上展示。只保留在产品待办列表中。

如果 DoD 是组织的执行标准的一部分，所有 Scrum Team 的价值交付最低都必须符合它的标准。如果组织里没有一个通用的 DoD，那么 Scrum Team 各自应该有符合自己的 DoD。

开发团队必须遵守 DoD，如果多个 Scrum Team 在同一个产品上共同协作，那么这些 Scrum Team 需要共同制定和服从同一个 DoD。

总结：

1. DoD 是官方的正式的，应用在某一产品上或某一组织内，所有采用的团队必须统一服从这个约定。
2. DoD 是描述产品状态的，主要针对的是衡量产品质量状态的统一标准瓶，而不是针对某一两个产品功能进行描述。
3. DoD 是直观清晰的，所有人应很容易理解，并能够让所有人很清晰的知道一个产品待办事项是否完成。

举一个正面例子： 完成的定义 本次价值交付的内容必须：

1. 经过必要的系统联调测试，处于可用的状态，随时可以上线。
2. 必须有100%的单元测试覆盖。
3. 有自动化测试看护其核心功能。
4. 在测试环境和预生产环境下，回归测试现实没有对老旧功能造成影响。
5. 扫描显示不会产生安全漏洞。
6. 没有生产“严重”或“中等”级别的bug。
7. 对系统的性能影响必须符合性能要求约定。
8. 产品文档和技术文档得到相应更新。
9. 相关代码与团队进行过Code Review。

完结

趁着十一假期抽空终于学完成了整个Scrum指南，感谢老袁的精讲，干货满满！不仅有独到的讲解而且在还有很多的实践经验分享。赞赞赞！！！

昨天，10月7日晚上，儿子喊我陪他一起画画。然后我们一起画下了这幅《桂花树的成长.gif》

然后在画完后在洗碗时，我突然意识到刚刚我和儿子一起进行了一场 Scrum。

Product Goal是进行一场酣畅淋漓的像素绘画。小项目只有一个 Sprint，大约 20 分钟。本次项目中我是PO、SM、DEV，儿子是干系人和DEV（哈哈，比较奇怪的团队组合）。

开始画画前进行 Sprint Planning，讨论具体要画什么，因为今天下雨，家门口的桂花树落了一地的桂花，记忆深刻，所以决定就画桂花树了，Sprint Goal 是画一幅桂花树成长的“小动画”。然后再讨论了下从小树发芽->成长->花开->下雨->花落，一共5个用户故事。

第一帧树苗开始前，我们讨论了小树需要种在土地上，同时小树苗不应该画太大，然后进行作画。

每一帧前我们都进行“Daily Scrum”，讨论小树接下来应该是长到哪个阶段。

过程中积累经验，比如：桂花应该用另外一个图层，这样擦除时不会将小树擦掉。同时也吸收了场外专家（孩子他妈）的意见，桂花树长大后树叶的颜色内层应该比外层更深。积极响应调整，在下一帧的实现上做出优化。

最终完成后，再次检查了是否有突兀不连贯的地方，然后一幅18帧的gif诞生了。🤣🤣🤣