本文作者：CODING - 敏杰小王子
11 月 18 日晚，Scrum 框架的创始人 Jeff Sutherland 和 Ken Schwaber 联手发布了最新版 Scrum 指南。作为 Scrum 的权威定义，《Scrum Guide》已经走过 25 个年头，在这二十多年间，Scrum 在国内也从概念布道走向了广泛落地，接下来我们结合 CODING 帮助中国团队在 Scrum 转型运动中的感悟带你一起解读这份最新版的 Scrum 指南。
（文末附新版 Scrum 指南原文链接）
在了解最新版的变化之前，我们得先知道不变的是什么。Scrum 的经典框架没有改变，基于经验主义和精益思维，通过短周期的快速试验来暴露团队面对的潜在问题，并通过不断的检视与调整来持续改进产品、团队和工作环境，从而高效并创造性地交付最高价值的产品。
透明、检视、适应
承诺、专注、开放、尊重和勇气
开发人员、PO、Scrum Master
产品 Backlog、Sprint Backlog、增量
SprintSprint 计划会议每日 Scrum 会议Sprint 评审会议Sprint 回顾会议
在帮助国内团队实践 Scrum 的过程当中，我们也发现团队类型趋于多样化：除了研发团队外，有运营团队基于 CODING 项目协同进行工单处理、有销售团队用来进行客户线索跟踪。CODING 为各种类型的团队提供了实践 Scrum 的可能性，通过提供自定义工作流，使得团队可以按需设置跨情景的状态流转，可以在项目协同中使用多种事项类型。
“这些年来，Scrum 指南开始变得越来越有规定性。2020 版旨在通过删除或淡化规定性语言，使 Scrum 重新成为最低限度的框架。例如删除了每日 Scrum 会议三个提问、淡化了关于产品待办列表项属性的相关描述、淡化了 Sprint 待办列表中改进项的相关描述、删除了“取消 Sprint”一节更改为更为简单的描述等等。”
过度执着于招式反而会陷入反模式。比如在每日站立会议上的三个提问也会带来的不少问题：当 Scrum Master 询问每个成员时，成员们依次作答自己的一亩三分田耕得如何，使得站会成为了每个成员的工作进展拷问，大家关注的焦点就不再是实现 Sprint 目标的进展。。
中国团队在实践 Scrum 时，“三个提问”往往是入门时的第一招式。但总是带着热情开始，数周后流于形式，尬场更是经常。理解 Scrum 的精神内核比掌握具体形式和工具更为重要，仅模仿形式即认为团队已经开始了 Scrum 是一种错觉。“中国特色敏捷”之下产生了更多披着敏捷皮的瀑布，项目通常“前松后紧”，只在最后的链条测试发布阶段需要紧张加班，研发团队松紧不定。
CODING 项目协同在应用 Scrum Guide 的概念时贯彻了最小、紧凑、渐进的理念，为团队掌握和试验 Scrum 的阶段降低了门槛，且满足了直至应用大规模敏捷阶段时的概念所需。例如宽松的的迭代并行约束、迭代进行时的需求修改等，“史诗-需求-子任务”的预设结构符合团队在大、中、微需求粒度的规划需要。
“2020 版 Scrum 指南引入了产品目标的概念，为 Scrum 团队提供了一个更具价值的目标的专注点。每个 Sprint 都应使产品更接近整体的产品目标。”
如何让团队更加聚焦于产品目标，并在行进过程中不偏离产品目标？在研发上游应用精益原则、设计思维，下游应用 DevOps，鼓励全团队的交互和信息透明是现今数字化研发协同工具的精神内核。CODING 提供项目协同的同时推出了团队目标管理，也是国内为数不多将敏捷项目管理与团队目标管理紧紧结合的产品。
CODING 团队目标是以自上而下的形式贯穿了周期目标的信息流，综合了产品价值管理所需和人员绩效沟通所需。始终不能忽略的是，产品目标是一个使团队保持持续沟通的工具。目标关键结果与项目事项自动关联，目标负责人与任务负责人在不同视角下各司其职，不对原有工作习惯做出改变，避免了冗余的管理成本。
“Scrum 团队是具有凝聚力的专业团体，一次专注于一个目标，即产品目标。”
“因此，他们应该共享相同的产品目标、产品待办列表和产品负责人。”
CODING 项目协同始终将产品待办列表作为团队成员的首要视图，专注当前迭代的所有目标，避免开发团队局限于自己的信息场。
在全面 VUCA（易变、不确定、复杂、模糊）时代，企业与组织面对着的不仅仅是挑战，还有机会。我们相信，Scrum 以其强大的生命力会横向扩张到更多的领域，纵向渗透到企业的更多团队中。
CODING 项目协同也在一次次产品迭代中践行承诺、专注、开放、尊重与勇气的 Scrum 价值观，我们希望提供给中国团队的不仅仅是敏捷工具，更是应对复杂问题的解决方案。