Certified ScrumMaster (CSM) 培训学员总结 - 曹天宇

作者：曹天宇

Scrum指南读后感

本人从事传统汽车行业，敏捷经验或scrum经验为0，甚至没有软件开发经验，参加本次培训目的是对敏捷开发有个入门的了解，并结合传统汽车行业的开发流程做一定的思考，因为现在汽车上也会涉及到越来越多的软件。

以下是看完Scrum指南后自己归纳的重点（理解还是更多基于理论层面）：

Scrum是一个框架 ，用于开发 交付 持续支持复杂产品的，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品。 Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成

Scrum的应用：最初是为了管理和开发产品而开发的

Scrum 的精髓在于小团队

Scrum 基于经验过程控制理论

Scrum 采纳一种迭代、增量式的方法来优化对未来的预测和控制风险

三大支柱：透明，检视，适应

4个正式事件：

• Sprint计划会议
• 每日Scrum站会
• Sprint评审会议(review)
• Sprint回顾会议(retrospective)

Scrum价值观：承诺commitment，勇气courage，专注focus，开放openness，尊重respect

Scrum团队：产品负责人 + Scrum master + 开发团队， 跨职能的自组织团队

产品负责人：将开发团队开发的产品价值最大化，产品负责人是负责管理产品待办列表的唯一负责人

产品待办列表的管理包括：

• 清晰地表述产品待办列表项
• 对产品待办列表项进行排序，使其最好地实现目标和使命
• 优化开发团队所执行工作的价值
• 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作
• 确保开发团队对产品待办列表项有足够深的了解。

为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定

开发团队：负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。开发团队由组织组建并得到授权，团队自己组织和管理他们的工作， 规模3-9人

• 不认可开发团队成员的任何头衔，他们都叫开发人员
• 不认可开发团队中所谓的“子团队“
• 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队

Scrum Master: 负责根据 Scrum 指南中的定义来促进和支持 Scrum， 服务型领导 服务于产品负责人：

• 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域；
• 找到有效管理产品待办列表的技巧；
• 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
• 理解在经验主义的环境中的产品规划；
• 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
• 理解并实践敏捷性
• 按要求或需要引导 Scrum 事件。

服务于开发团队：

• 在自组织和跨职能方面给予开发团队指导；
• 帮助开发团队创造高价值的产品；
• 移除开发团队工作进展中的障碍；
• 按要求或需要引导 Scrum 事件；以及，
• 在 Scrum 还未完全采纳和理解的组织环境中指导开发团队。

服务于组织：

• 带领并指导组织采纳 Scrum；
• 在组织范围内规划 Scrum 的实施；
• 帮助员工和利益攸关者理解并实施 Scrum 和经验产品开发；
• 引发能够提升 Scrum 团队生产率的改变；以及，
• 与其他 Scrum Master 一起工作，增加组织中 Scrum 应用的有效性。

Scrum事件： Sprint, Sprint Planning（计划会议）, Daily Scrum（每日站会）, Sprint Review（评审会议）, Sprint Retrospective（回顾会议）

Sprint：Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。

每个 Sprint 都可以被视为一个项目 Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权力，虽然他或她做这样的决定也可能受到来自利益攸关者、开发团队或是 Scrum Master 的影响。如果某个 Sprint 对其所在环境来说失去了价值和意义，那么它就应该被取消；取消 Sprint 会消耗资源

Sprint Planning（计划会议）：Sprint 计划会议是限时的，以一个月的 Sprint 来说最多 8 小时为上限。对于较短的 Sprint，会议时间通常会缩短。Scrum Master 要确保会议顺利举行 话题一：这次Sprint能做什么 话题二：如何完成所选的工作 确定Sprint目标，开发团队必须在工作中时刻谨记 Sprint 目标。为了达成 Sprint 目标，需要实现相应的功能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

Daily Scrum（每日站会）：每日 Scrum 站会是开发团队的一个以 15 分钟为限的事件。每日 Scrum 站会在 Sprint 的每一天都举行。每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。开发团队借由每日 Scrum 站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。 Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议，每日 Scrum 站会是开发团队的内部会议。Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。

Sprint Review（评审会议）：Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的工作。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。 对于长度为一个月的 Sprint 来说，评审会议时间最长不超过 4 小时，Scrum Master 要确保会议举行。

主要内容： - 产品负责人邀请 Scrum 团队和主要的利益攸关者参加会议 - 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成” - 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的 - 开发团队演示“完成”的工作并解答关于所交付增量的问题 - 产品负责人讨论当前的产品待办列表的情况。根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话） - 参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的 Sprint 计划会议提供有价值的输入信息 - 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变 - 为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场 Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。

Sprint Retrospective（回顾会议）：Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。对于长度为一个月的 Sprint 来说，回顾会议时间最长不超过 3 小时。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的 目的： - 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何 - 找出并加以排序做得好的和潜在需要改进的主要方面 - 制定改进 Scrum 团队工作方式的计划

Scrum工件 （Artifacts）：Product Backlog（产品待办列表）， Sprint Backlog， Increment（增量）

Product Backlog（产品待办列表）：产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。产品待办列表永远是不完整的。产品待办列表列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的改变。多个 Scrum 团队常常会一起参与对同一产品的开发。一个产品只有一个产品待办列表用于描述下一步产品开发工作。排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节。 开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求，并根据情况权衡取舍来影响他们，但是最终估算是由开发团队决定的。 监控目标实现的进度，在任何时刻，达成目标的剩余工作是可以累计的。产品负责人至少在每个 Sprint 评审会议中都必须跟踪剩余工作总量。 预测进度方面，例如，燃尽图（burn-downs）、燃烧图（burn-ups）或者累积流图（cumulative flows）

Sprint Backlog（待办列表）：Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测。 Sprint 产品待办列表将开发团队用来达成 Sprint 目标的所有工作变得清晰可见。Sprint 产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日 Scrum 站会中清晰地看到 在 Sprint 期间，只有开发团队可以改变 Sprint 待办列表。Sprint 待办列表是高度可见的，是对开发团队计划在当前 Sprint 内工作完成情况的实时反映，该列表由开发团队全权负责。

Increment（增量）: 增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。无论产品负责人是否决定发布它，增量必须可用。

工件透明 Scrum 依赖于透明。优化价值和控制风险的决定都是基于所获知的工件状态。当工件的状态是完全透明时，这些做出的决定才有一个坚实的基础；当工件的状态是不完全透明时，这些做出的决定就会有瑕疵，而价值也可能因此遭受损失，同时风险也可能会因此而增加。 Scrum Master 必须和产品负责人、开发团队和其他相关人员一起合作，以确保所有工件都是完全透明的。有些实践就是为应对不完全透明的状态而生的，Scrum Master 必须帮助每个人，让他们能够在遇到不透明的情况下采取最合适的实践。Scrum Master 能够通过检视工件、嗅探模式、倾听周围的声音以及观察预期和实际结果的差异来发现不完全透明。

“完成”的定义 当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么。虽然在不同Scrum团队之间或许会存在显著差异，但是每个团队成员必须对完成工作意味着什么有相同的理解以便确保透明化。 开发团队在每个 Sprint 都交付产品功能增量。这一增量是可用的，所以产品负责人可以选择立即发布它。如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所有Scrum团队都必须遵守它，以此为最低标准。 如果增量“完成”的定义不是开发组织的惯例，那么 Scrum 团队中的开发团队就必须制定适合于产品的“完成”的定义。如果系统或产品发布由多个 Scrum 团队一起开发，那么所有 Scrum 团队中的开发团队必须一起参与制定“完成”的定义。 随着团队的成熟，“完成”的定义会扩大，包含更为严格的标准来保证更高的质量。

欢迎报名我的线上课程 - Scrum敏捷精髓