课程优势

• 讲师具备Scrum联盟认证敏捷培训师资格(Certified Scrum Alliance Trainer)；
• 讲师具备专业的视觉引导技能
• 生动有趣的视觉引导方式增强课程的趣味性
• 采用视频、练习、讨论、模拟、复盘等多元教学方式。
• 互动性高，注重学员体验
• 沉浸式的场景探讨+实战演练
• 有问必答

授课顾问

敏捷与创新讲师、视觉引导师

Scrum联盟最高级认证敏捷教练 Certified Team Coach

中国视觉引导认证师CGFP

Liberating Structures释放性结构引导工具中国社区主理人

课程大纲

第一天

• 热身互动/入场调研
• 工作坊基本准则
• 团队公约/基本规范的制定
  • 建立团队公约应考虑的事项
  • 高效团队应具备的行为
• 什么是引导
• 什么是引导者
  • 引导者的目标
  • 引导者的关注点——过程
• 引导对于课堂教育带来的改变
• 一个引导者所应具备的基本素养和能力
  • Stance引导者的基本立场
    • 引导者的立场
    • 引导者的所具备的信念
  • Skills引导者应具备的技能
  • Structures引导结构介绍
    • 大结构——钻石模式
    • 微结构
      • 发散工具
      • 收敛工具
      • 大型团队引导工具
      • 释放性结构介绍
      • 结构的介绍及会议引导的结构模型
      • 基本的实践原则
      • 结合引导框架介绍释放性结构核心工具
        • 1-2-4-all
        • TRIZ
        • 15%Solution
        • 三人行咨询
        • 25/10
        • 等等
      • 带练演示结构串的组合
        • 模拟话题带练
        • 总结拆解

第二天

• 第一天课程反思
• 过程设计
  • 过程设计前的准备事项
    • 人/成果/外部信息/现实情况/挑战/假设
    • 前期问卷调研
  • 故事板的介绍和引入
  • 用故事板设计一个引导/会议议程
• 持续改进
  • 个人反思成长
  • 有效反馈（乔哈里窗-IIU反馈模型）
• 场景探讨——每组选定主题设计一个引导工作坊
  • 第一部分—设计工作坊前的问题梳理
  • 第二部分—设计工作坊
  • 第三部分—现场演练展示
  • 第四部分—工作坊的反馈
• 团队心理安全
  • 团队心理安全的概述
  • 作为引导师，需要促成团队什么样的心理安全
• 复盘总结
• 收获和期待

课程收益

在课程中通过一系列的练习、逐步体验引导的魅力。在真实场景的模拟演练环节，学员需要从客户访谈开始，理解客户面临的问题，设计整个工作坊，模拟引导演练，并进行自我反思及收集反馈。

学习会议引导/团队讨论的基本思路、引导流程、设计方法；学习带领高效会议，在企业的战略、文化、变革、创新、团队协作、流程改进、工作复盘等关键领域如鱼得水。通过学习演练不仅收获理性的团队产出，还绽放了团队的智慧掌握「窍」开团队智慧、激发讨论、提高团队生产力、共创有意义结果的有效方式。

学员们将组成学习小组，进行大量的小组讨论、共同设计工作坊、共同模拟演练，并共同进行自我反思。课程结束后将收获——

• 学习设计富有影响力的引导过程
• 探索引导者的心态、职责以及位置
• 培养引导思维、提升引导技能
• 进行现场沉浸式的引导案例演练

目标受众

**如果您符合以下任何一条：**

• 想要成为有影响力引导师
• 期望精进引导软技能
• 想要通过引导技能发展职业生涯
• 希望能共创有效讨论结果的团队管理者、引导者或协调者
• 改变传统课堂教育，增进互动式体验形式
• 想在会议中发声却不知道如何介入并产生促进和影响的人
• 任何渴望快乐团队和高效讨论的人士不限于职场任何职能

证书及其他

Certified Agile Facilitator

报名咨询及获取详细课程大纲：

Tel: 021-34753688

Email: Service@UPerform.CN

课程优势

• 讲师具备Scrum联盟认证敏捷培训师资格(Certified Scrum Alliance Trainer)；
• 讲师具备专业的视觉引导技能
• 生动有趣的视觉引导方式增强课程的趣味性
• 采用视频、练习、讨论、模拟、复盘等多元教学方式。
• 互动性高，注重学员体验
• 沉浸式的场景探讨+实战演练
• 有问必答

授课顾问

敏捷与创新讲师、视觉引导师

Scrum联盟认证敏捷教练 Certified Team Coach

中国视觉引导认证师CGFP

Liberating Structures释放性结构引导工具中国社区主理人

课程大纲

第一天

• 热身互动/入场调研
• 工作坊基本准则
• 团队公约/基本规范的制定
  • 建立团队公约应考虑的事项
  • 高效团队应具备的行为
• 什么是引导
• 什么是引导者
  • 引导者的目标
  • 引导者的关注点——过程
• 引导对于课堂教育带来的改变
• 一个引导者所应具备的基本素养和能力
  • Stance引导者的基本立场
    • 引导者的立场
    • 引导者的所具备的信念
  • Skills引导者应具备的技能
  • Structures引导结构介绍
    • 大结构——钻石模式
    • 微结构
      • 发散工具
      • 收敛工具
      • 大型团队引导工具
      • 释放性结构介绍
      • 结构的介绍及会议引导的结构模型
      • 基本的实践原则
      • 结合引导框架介绍释放性结构核心工具
        • 1-2-4-all
        • TRIZ
        • 15%Solution
        • 三人行咨询
        • 25/10
        • 等等
      • 带练演示结构串的组合
        • 模拟话题带练
        • 总结拆解

第二天

• 第一天课程反思
• 过程设计
  • 过程设计前的准备事项
    • 人/成果/外部信息/现实情况/挑战/假设
    • 前期问卷调研
  • 故事板的介绍和引入
  • 用故事板设计一个引导/会议议程
• 持续改进
  • 个人反思成长
  • 有效反馈（乔哈里窗-IIU反馈模型）
• 场景探讨——每组选定主题设计一个引导工作坊
  • 第一部分—设计工作坊前的问题梳理
  • 第二部分—设计工作坊
  • 第三部分—现场演练展示
  • 第四部分—工作坊的反馈
• 团队心理安全
  • 团队心理安全的概述
  • 作为引导师，需要促成团队什么样的心理安全
• 复盘总结
• 收获和期待

课程收益

在课程中通过一系列的练习、逐步体验引导的魅力。在真实场景的模拟演练环节，学员需要从客户访谈开始，理解客户面临的问题，设计整个工作坊，模拟引导演练，并进行自我反思及收集反馈。

学习会议引导/团队讨论的基本思路、引导流程、设计方法；学习带领高效会议，在企业的战略、文化、变革、创新、团队协作、流程改进、工作复盘等关键领域如鱼得水。通过学习演练不仅收获理性的团队产出，还绽放了团队的智慧掌握「窍」开团队智慧、激发讨论、提高团队生产力、共创有意义结果的有效方式。

学员们将组成学习小组，进行大量的小组讨论、共同设计工作坊、共同模拟演练，并共同进行自我反思。课程结束后将收获——

• 学习设计富有影响力的引导过程
• 探索引导者的心态、职责以及位置
• 培养引导思维、提升引导技能
• 进行现场沉浸式的引导案例演练

目标受众

**如果您符合以下任何一条：**

• 想要成为有影响力引导师
• 期望精进引导软技能
• 想要通过引导技能发展职业生涯
• 希望能共创有效讨论结果的团队管理者、引导者或协调者
• 改变传统课堂教育，增进互动式体验形式
• 想在会议中发声却不知道如何介入并产生促进和影响的人
• 任何渴望快乐团队和高效讨论的人士不限于职场任何职能

证书及其他

Certified Agile Facilitator

报名咨询及获取详细课程大纲：

Tel: 021-34753688

Email: Service@UPerform.CN

前言

科技的进步日新月异，如何利用新科技和新工具进行企业的数字化转型，创造新的竞争优势，已经成为许多企业面临的重要挑战。然而，在企业数字化转型的道路上，敏捷教练扮演着非常重要的角色，这一点很多人并不了解。

2019年，一家知名欧洲药厂的中国分公司在全球企业500强中，寻求UPerform优普丰敏捷咨询教练申健Jacky（江湖人称申导）的帮助，目标正是数字化转型。对于这样的大型企业来说，推动数字化转型就像是要让一艘大船急转弯，非常困难。然而，这家药厂却在短短一年内取得了令人瞩目的成绩。

从最初连人才招募都遇到困难的阶段，到后来不仅培养了上百名敏捷人员，还将交付周期缩短了30%。隔年，他们在全球药厂排名中跻身前8强，取得了令整个行业惊叹的成绩。

国际药厂数字化转型，多头马车难整合

在国际知名药厂中，为何急于进行数字化转型？原因在于集中采购等政策对药厂利润造成了压力，高层迫切希望通过数字工具更精准地了解客户拜访效果和市场反馈。他们希望将过去口耳相传的市场消息和销售战绩转化为实际的数据和资料，通过分析、评估和控制费用，让业务运作流程在合规的前提下更加自动化和透明。

然而，面对如此庞大的组织结构，仅仅建立网络医院系统、营销整合系统、在线会议和支付系统就涉及到医学、市场、销售、法律、人力等多个部门。在数字化转型过程中，谁来决策、谁来主导整体规划，以及各部门之间如何有效沟通，成为这家药厂面临的最大难题。尽管花费了整整一年的时间，公司高层仍然感到头疼，因为整个过程仍然像一盘散沙，缺乏整体协调。

敏捷教练剥洋葱

在对这家药厂进行深入剖析后，申导和他的团队发现了该企业在数字化转型过程中面临的五大痛点。这些痛点包括人才缺失、缺乏建章立制、技术与业绩难以融合、员工欠缺能力培养以及文化宣导不足。

首先，人才缺失是一个重要问题。由于药厂是传统产业，尽管他们提供高薪吸引科技人才，但外界仍担心转型失败可能导致裁员。因此，许多人持观望态度，导致招募人才方面遇到困难。此外，药厂内部员工大多是传统医药人才，缺乏数字相关能力和经验，甚至高层也认为员工能够熟练使用Excel已经是幸运了，更别提数字化转型了。

其次，缺乏建章立制也是一个问题。办公室的格局和环境对于工作氛围至关重要。传统办公室通常是封闭、安静、各部门独立的状态。相比之下，明亮、开放的办公空间更有利于沟通。针对这个问题，教练团队与装修部门进行了沟通，根据敏捷需求，在办公室内增设了看板等基本工具，使工作项目和进度一目了然，并潜移默化地融入敏捷文化。

第三，技术与业绩难以融合。无论数字化转型多么成功，最终目的都是提升公司业绩。然而，该企业过去常常将业务和科技分开处理，忽视了将新科技与业务结合的重要性。业务单位向IT部门提出要求后就离开，导致数字化转型停滞不前。

第四，员工欠缺能力培养。过去，药厂各部门分工明确，缺乏敏捷思维意识，并且很少进行专业职能的进修和培训。为了解决这个问题，教练团队对内部员工进行了需求分析和产品体验等培训，并为未来的敏捷团队培训了不同角色，如Scrum Master和Product Owner，以便每个人都能根据个人业务需求进行专业技能的再造和再培训。

最后，文化宣导不足也是一个问题。人们的观念转变需要时间的洗礼。面对新的观念或工作方式，大多数员工的第一反应是抗拒。因此，教练团队鼓励高层经常分享成功的故事或案例，以便这些观念逐渐渗透到每个员工的思想中，并通过敏捷日等活动加深信念。

不只拟定策略 “陪跑”才是敏捷落地关键

为了推动数字化转型，企业高层首先需要理解敏捷的概念。因此，申导制定了”统一思想”的策略，邀请了该公司的首席PO、人资部长、采购主管、敏捷转型负责人、HR和OD负责人等参与培训，让Scrum的基本架构在高层的思想中扎根，共同学习敏捷的基本概念，如33355和看板等。

其次，教练团队从药厂的关键业务入手，通过分析大数据和产品资料来评估可能的绩效指标和工作内容方案。第三步是加强外部人才招募，同时加强内部人才培训，陆续组建了15个敏捷团队，分别负责不同的任务目标。接下来，教练团队与这些敏捷团队签订辅导合约，通过定期测评来推动改进，明确游戏规则并进行解释。最后，将方案实施，并由教练团队在旁边提供支持，定期进行成效评估。

在这家药厂中，敏捷团队的PO多数来自营销部门，开发人员则由不同部门的成员组成任务型小组。每个Sprint结束后，教练团队会介入进行成效评估，并提供专业反馈。这种循环的方式体现了迭代的思想，并落实了二八法则，力求在最短的时间内解决最大的痛点，并交付最大的价值。

交付周期减3成，业务满意增3成

经过近一年的努力，药厂的数字化转型终于步入正轨。到目前为止，已经成立了5至6个小型数字产品团队和4到5个非数字的工作团队。通过敏捷实践培训，成功培养了上百名专业的敏捷人才。相比传统工作模式，药厂在引入敏捷后，交付周期缩短了整整30%，业务单位通过频繁的交互和修正，对交付成果的满意度提高了3成。

申导说：”敏捷转型是一条永无止境的学习和优化之路。”教练团队最初介入辅导已经超过3年，药厂从最初团队组建困难的阶段一步步克服难关，通过数字化提升业绩、解决产品反馈问题，目前转型工作仍在持续进行。

许多人可能会好奇，既然企业的数字化转型已经进展顺利，为什么教练团队仍然没有退出？申导说：”教练团队无法在短短一年内解决企业长期积累的问题，他们只能从当下最关键、影响最大的问题入手，然后逐步处理次要但重要的问题，以此循环迭代优化。”

敏捷转型大不易？最常卡关的3大难题

申导总结了他在过去10年中辅导超过30家国内外大型企业的经验，指出了敏捷转型中最难克服的三个难题，分别是”思想认知”、”能力建设”和”基础设施打造”。

首先，人们习惯于接受确定性，待在舒适区，并按照过去熟悉的工作模式进行工作。因此，突然要求他们从事新的工作内容，适应新的组织方式，这种不确定性必然会对许多人造成冲击，他们担心自己做不好，害怕失去职位，因此产生各种反弹。在这种情况下，可以通过心理建设和教练的方式启发团队成员，帮助他们打开眼界，提出一些可行的方案，让他们感受到一些踏实和确定性，让他们知道”别人都是怎么做的，你也可以做到”。

在能力建设方面，无论是数字转型还是营销能力，在像药厂这样的传统产业中，都是全新的事物。大多数员工没有经验，也不知道该如何做。只有通过学习来补充硬技能和软实力，才能在数字转型的浪潮中保持竞争优势。

最后，系统和工具等基础设施是推动敏捷转型不可或缺的重要基础。特别是在当今大型企业团队经常分布在世界各地的情况下，敏捷方法也应与时俱进。采用电子看板进行随时更新，有利于各地工作团队的对齐和协作。这样的基础设施能够支持团队的敏捷工作方式。

AI时代，企业不只要敏捷更要拥抱AI

随着人工智能（AI）时代的到来，申导呼吁企业在敏捷转型的过程中敞开心胸迎接AI，因为AI将成为未来企业不可或缺的重要思维。他指出：”如果说，数字化是先进生产力和生产关系的综合，那么敏捷是生产关系，AI就是下一波先进生产力，也是’数字’的进阶版”。

随着AI的发展，未来只需说一句话，AI就能帮助企业创建一个网站。这将导致许多人力资源被淘汰，人与人之间的协作也可能减少。因此，企业必须在AI的基础上建立各种系统，如AI客服和AI营销机器人。申导认为，如果企业不赶紧跟上这股AI浪潮，垄断性行业或许还能维持一段时间，但被淘汰的风险是可以预见的事实。

在面对AI时代的挑战时，企业需要灵活应对，将AI作为一种工具和资源，与敏捷转型相结合，以提高效率和创造更大的价值。同时，企业也需要关注人力资源的培养和转型，使员工具备适应AI时代的技能和思维。只有这样，企业才能在激烈的竞争中保持竞争优势，并实现可持续发展。

总结

科技的进步推动了企业数字化转型的需求，而敏捷教练在这一过程中扮演着重要的角色。通过深入剖析一家药厂的案例，我们看到了数字化转型所面临的挑战和敏捷教练的作用。人才缺失、缺乏建章立制、技术与业绩融合困难、员工能力培养和文化宣导不足是数字化转型中的痛点，而敏捷教练通过培训、建立合作团队和提供支持等方式，帮助企业克服这些难题。

在数字化转型的过程中，敏捷教练不仅制定了策略，还与企业高层和团队密切合作，通过分析数据、评估绩效和持续改进来推动转型。经过一年的努力，药厂取得了显著的成果，交付周期缩短了30%，业务满意度提高了3成。然而，敏捷转型并非一蹴而就，企业需要持续学习和优化，解决思想认知、能力建设和基础设施打造等难题。

随着人工智能时代的到来，敏捷转型不仅需要关注数字化，还需要拥抱AI。AI将成为未来企业不可或缺的重要思维，企业应将其作为工具和资源与敏捷转型相结合，以提高效率和创造更大的价值。同时，企业也需要关注人力资源的培养和转型，使员工具备适应AI时代的技能和思维。只有这样，企业才能在激烈的竞争中保持竞争优势，并实现可持续发展。

因此，敏捷转型不仅是一项技术和工具的应用，更是一种思维和文化的转变。企业需要不断学习和适应新的挑战，与时俱进，才能在快速变化的市场中立于不败之地。敏捷教练的角色将继续发挥重要作用，帮助企业实现数字化转型，并在未来的AI时代中保持竞争优势。

Scrum是一个实现了敏捷思维的框架，帮助团队快速前进和学习，是一种把事情搞定的敏捷方法，Scrum常常与其他敏捷框架结合起来使用。Scrum认证是全球最权威和最流行的敏捷实践集。

Scrum认证由国际Scrum联盟（ScrumAlliance.org）制定和维护，针对个人职业发展的敏捷认证体系，Scrum认证证书由Scrum联盟官方统一颁发和维护。其中基础级认证面向Scrum团队的三个角色：ScrumMaster认证(CSM)、Scrum Product Owner认证(CSPO)和Scrum Developer认证(CSD)。UPerform敏捷学院是中国领先的Scrum认证及敏捷培训授权服务机构。

https://www.uperform.cn/scrum-certification-course/

Scrum Alliance总部位于美国，是一个为Scrum和敏捷实践者提供教育、资源和支持的组织。深入一步，你会发现Scrum联盟是观念和变革运动的一部分。Scrum联盟提供主张、社区参与、研究、人际网络和关注组织变革，这些变革正在改变着全球的工作方式。Scrum是一个非盈利组织，由全球超过50万认证者组成，驱使我们的不是商业，也不是什么财务盈亏；我们的动力正是来自于全球社区的成员，以及寻求实现真正工作与生活平衡的每个人。

2017年11月17-18日， 上海优普丰敏捷学院 Scrum Master中文认证公开课在上海世纪大道圆满落幕啦！

学员们现学现用，认真思考！！

Scrum 指南的目的

Scrum 是用于开发和持续支持复杂产品的一个框架。本指南包含了 Scrum 的定义，其中包 括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum，Scrum 指南也由他们撰写与提供。总之，他们是 Scrum 指南的后盾。

Scrum 的定义

Scrum (名词): Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能

高效并创造性地交付尽可能高价值的产品。 Scrum 是:
 轻量级的
 易于理解的
 难以精通的

Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发 上。Scrum 并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架，在此框架中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和开发实践的相对成效更加 清楚地显现出来，因此您可以去改进它们。

Scrum 框架由 Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部 分都有其特定的目的，其对于 Scrum 的成功与使用是至关重要的。

Scrum 的规则把事件、角色和工件组织在一起，管理它们之间的关系和交互。对于 Scrum 的规则描述将会贯穿全文。

使用 Scrum 框架的其它不同特定技巧将不在本文中描述。

Scrum 的应用

Scrum 最初是为了管理和开发产品而开发的。从上世纪 90 年代初开始，Scrum 在全球范 围内已得到了广泛应用：

1. 研究与确定可行的市场、技术和产品能力；

2. 开发产品和增强功能；

3. 每天频繁多次发布产品和增强功能；

4. 开发和维护云（在线、安全、按需）和其他产品的运营环境；

5. 支持和更新产品。

Scrum 已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶汽车、学校、政府、 市场、管理组织运营，以及几乎我们（作为个体和群体）日常生活中所使用的一切。

随着技术、市场和环境的复杂性及其它们之间相互作用的快速增长，Scrum 在处理复杂性方面的效用日益得到证实。

在迭代与增量的知识迁移中，Scrum 被证明特别有效。Scrum 现广泛用于产品、服务和母公司管理。

Scrum 的精髓在于小团队。个体团队具有高度灵活性和适应性。当单个、几个、多个和团队网络在开发、发布、运营和维护成千上万人的工作和工作产品时，这些优势得以持续运 作（并发挥价值）。他们通过精良的开发架构和目标发布环境来协作和互操作。

当 Scrum 指南使用“开发（动词）”和“开发（名词）”这两个词时，它们指的是复杂性的工作，包含上面提到的各种类型工作。

Scrum 理论

Scrum 基于实验性过程控制理论，也称之为经验主义(Empirical Process)。实验性过程主张知识源自实际经验以及从当前已知情况下做出决定所获得。Scrum 采用一种迭代、增量式的方法来优化对未来的 预测和管理风险。

透明、检视和调整是实验性过程控制的三大支柱，支撑起每一个实验性过程控制的实施。

透明

过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。

例如:
 所有参与者谈及过程时都必须使用统一的术语。同时，
 负责完成工作和验收工作的人必须对“完成”的定义，有一致的理解。

检视

Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要的 差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉 地执行时，效果最佳。

调整

如果检视者发现过程中的一个或多个方面偏离于可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化 进一步的偏离。

Scrum 规定了 4 个正式事件，用于检视与调整，这 4 个事件在 Scrum 事件章节中会加以 描述:

 Sprint计划会议

 每日 Scrum 站会

 Sprint评审会议

 Sprint回顾会议

Scrum 价值观

当投入、勇气、专注、开放和尊重五大价值观为 Scrum 团队所践行与内化时，Scrum 的透明、检视和调整三大支柱成为现实，并且在每个人之间构建信任。Scrum 团队成员通过 Scrum 事件、角色和工件来学习和探索这些价值观。

Scrum 的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现 Scrum 团队 的目标。Scrum 团队成员有勇气去做正确的事并处理那些棘手的问题。每个人专注于 Sprint 和 Scrum 团队目标的工作。Scrum 团队及其利益攸关者同意将所有工作和执行工作 的挑战进行公开。Scrum 团队成员相互敬重，彼此成为更有能力和独立的人。

Scrum 团队

Scrum 团队由一名产品负责人、开发团队和一名 Scrum Master 组成。Scrum 团队是跨职能 的自组织团队。自组织团队自己选择如何以最好的方式来完成工作，而不是由团队之外的 人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。Scrum 的团队模式乃是设计用来提供最佳的灵活性、创造力和生产力。

Scrum 团队迭代增量式地交付产品，籍此最大化获得反馈的机会。增量式交付“完成”的产 品保证了一个可工作产品的潜在可用版本总是存在。

产品负责人

产品负责人负责最大化产品和开发团队工作的价值。如何实现这一点的方式会随着组织、 Scrum 团队和单个团队成员的不同而不同。

产品负责人是负责管理产品待办列表的唯一责任人。产品待办列表的管理包括:

 清晰地表述产品待办列表项;
 对产品待办列表项进行排序，使其最好地实现目标和使命;
 优化开发团队所执行工作的价值;

 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做 的工作; 以及，

 确保开发团队对产品待办列表项有足够深的了解。 产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。

产品负责是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个委 员会的期望要求，但是想要改变产品待办列表项的优先级必须经过产品负责人。

为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定。产品负 责人对产品待办列表的内容和排序的决定必须是可见的。任何人都不得要求开发团队按照 另一套需求开展工作，另一方面开发团队也不允许去做任何其他人所说的。

开发团队

开发团队包含了各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产 品增量。只有开发团队成员才能创建增量。

开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应 能最大化开发团队的整体效率和效用。

开发团队具有下列特点:

 他们是自组织的。没有人(即使是 Scrum Master)有权告诉开发团队应该如何把产品 待办列表变成潜在可发布的功能增量;

 开发团队是跨职能的，团队作为一个整体，拥有创建产品增量所需的全部技能;
 Scrum不认可开发团队成员的头衔，不管承担哪种工作他们都叫开发人员，即只有开发人员这一头衔。此规则无一例外;
 Scrum不认可开发团队中所谓的“子团队”，无论是否有特别的专业领域，例如无论是测试还是业务分析的成员都不能划分为“子团队”。此规则无一例外; 同时,
 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。

开发团队的规模

开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工作。 少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的 团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产 品增量。超过 9 人的团队则需要过多的协调沟通工作。过大的开发团队会产生太多的复杂 性，不便于经验过程管理。产品负责人和 Scrum Master 角色不包含在此数字中，除非他们 同时也参与执行 Sprint 待办列表中的工作。

Scrum Master

Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。

Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。

Scrum Master 服务于产品负责人
Scrum Master 以各种方式服务于产品负责人，包括:

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

Scrum Master 服务于开发团队
Scrum Master 以各种方式服务于开发团队，包括:

 在自组织和跨职能方面给予开发团队指导;

 帮助开发团队创造高价值的产品;
 移除开发团队工作进展中的障碍;
 按要求或需要引导 Scrum 事件; 以及,

 在 Scrum 还未完全采纳和理解的组织环境中指导开发团队。

Scrum Master 服务于组织
Scrum Master 以各种方式服务于组织, 包括:

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

Scrum 事件

Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。所有 事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始，它的持续时间是规定的，不能缩短或延长。而其他事件则可以在该事件的目 标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。

Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum 中的每个事件都是用来进行检视和调整的正式机会。这些事件都是被特别设计用来确保达成透明和检 视。如果 Sprint 不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与调整的机会。

Sprint

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

Sprint 由 Sprint 计划会议、每日 Scrum 站会、日常开发工作、 Sprint 评审会议和 Sprint 回顾会议构成。

在 Sprint 期间:

 不能做出有害于 Sprint 目标的改变;

 不能降低质量的目标;以及,

 随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会要澄清 和重新协商。

每个 Sprint 都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint 被用于 完成某些事情。每个 Sprint 都会定义要开发什么，还有一份设计过和灵活的计划用来指导 如何做这些事、工作内容和最终产品。

Sprint 的长度限制在一个月内。当 Sprint 的长度太长的话，对要构建什么的定义就有可能 会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一 次对达成目标的进度进行检视和调整，来实现可预测性。Sprint 同时也把风险限制在一个 月的成本上。

取消 Sprint

Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权力，虽然 他或她做这样的决定也可能受到来自利益攸关者、开发团队或是 Scrum Master 的影响。

如果 Sprint 目标过时，那么 Sprint 就会被取消。比如公司的发展方向或者市场上或技术上 的状况发生改变，这些变化都可能导致 Sprint 被取消。总的来说，如果某个 Sprint 对其所 在环境来说失去了价值和意义，那么它就应该被取消。然而，由于 Sprint 的时间都很短， 所以取消 Sprint 的意义不大。

当取消某个 Sprint 时，任何做完和“完成”的产品待办列表项都需要评审。假如成果的任何 部分具有潜在可发布的话，产品负责人通常会接受这个成果。所有未完成的产品待办列表 项都会被放回到产品待办列表中，并重新估算。花在它们身上的工作会很快地贬值，所以 必须经常性地重估。

取消 Sprint 会消耗资源，因为每个人都必须重新集合在另一个 Sprint 计划会议来开始另一 个 Sprint 。取消 Sprint 通常会对 Scrum 团队造成重创，这种情况非常罕见。

Sprint 计划会议

Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队共 同协作完成的。

Sprint 计划会议是限时的，以一个月的 Sprint 来说最长 8 小时为上限。对于较短的 Sprint， 会议时间通常会缩短。Scrum Master 要确保会议顺利举行，并且每个参会者都理解会议的 目的。 Scrum Master 要教导 Scrum 团队遵守时间盒的规则。

Sprint 计划会议回答以下问题:
 接下来的 Sprint 交付的增量中要包含什么内容?

 要如何完成交付增量所需的工作?

话题一: 这次 Sprint 能做什么?
开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该目 标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。

Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预 测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团 队可以评估接下来的 Sprint 可以完成什么工作。

在开发团队预测完这个 Sprint 中可交付的产品待办列表项之后，Scrum 团队草拟一个 Sprint 目标。Sprint 目标是在这个 Sprint 通过实现产品待办列表要达到的目的，同时它也为 开发团队提供指引，使得开发团队明确开发增量的目的。

话题二: 如何完成所选的工作?

在设定了 Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后，开发团队将决定如 何在 Sprint 中把这些功能构建成“完成”的产品增量。这个 Sprint 中所选出的产品待办列表 项加上交付它们的计划称之为 Sprint 待办列表。

开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需 要的工作。工作有不同的大小，或者不同的预估工作量。然而，在 Sprint 计划会议中，开 发团队已经挑选出足够量的工作，以此来预估他们在即将到来的 Sprint 中能够完成。在 Sprint 计划会议的最后，开发团队规划出在 Sprint 最初几天内所要做的工作，通常以一天 或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作，领取工作在 Sprint 计划会议和 Sprint 期间按需进行。

产品负责人能够帮助解释清楚所选定的产品待办列表项，并作出权衡。如果开发团队认为 工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可 以邀请其他人员参加会议，以获得技术或领域知识方面的建议。

在 Sprint 计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master 解释他们将如 何以自组织团队的形式完成 Sprint 目标并开发出预期的产品增量。

Sprint 目标

Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的。它为开发团队提供指 引，使得团队明确为什么要构建增量。Sprint 目标在 Sprint 计划会议中确定。Sprint 目标为 开发团队在 Sprint 中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供一个 连贯一致的功能，也即是 Sprint 目标。Sprint 目标可以是任何其他的连贯性来促使开发团 队一起工作而不是分开独自做。

开发团队必须在工作中时刻谨记 Sprint 目标。为了达成 Sprint 目标，需要实现相应的功能 和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

每日 Scrum 站会

每日 Scrum 站会是开发团队的一个以 15 分钟为限的事件。每日 Scrum 站会在 Sprint 的每一天都举行。在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计 划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化团队 协作和性能。每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。

开发团队借由每日 Scrum 站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。每日 Scrum 站会优化了开发团队达成 Sprint 目标的可能性。每 天，开发团队应该知道如何以自组织团队来协同工作以达成 Sprint 目标，并在 Sprint 结束时开发出预期中的增量。

会议的结构由开发团队设定。如果会议专注于达成 Sprint 目标的进展，开发团队可以采 用不同的方式进行。一些开发团队会以问题为导向来开会，有些开发团队会基于更多的讨 论来开会。以下为示例：

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么？

• 今天，我为帮助开发团队达成 Sprint 目标准备做什么？

• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。

Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议。Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。

每日 Scrum 站会是开发团队的内部会议。如果有开发团队之外的人出席会议，Scrum Master 必须确保他们不会干扰会议进行。

每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显 并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与调整的关键会议。

Sprint 评审会议

Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办 列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的 工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可 能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的 目的是为了获取反馈并促进合作。

对于长度为一个月的 Sprint 来说，评审会议时间最长不超过 4 小时。对于较短的 Sprint 来说，会议时间通常会缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议 的目的。Scrum Master 教导每位参会者遵守时间盒的规则。

Sprint 评审会议包含以下内容:

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

Sprint 回顾会议

Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。

Sprint 回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。对于长度为 一个月的 Sprint 来说，回顾会议时间最长不超过 3 小时。对于较短的 Sprint 来说，会议时间通常会缩 短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master 教导大家遵守时间盒的规则。Scrum Master 作为 Scrum 过程的责任者，作为团队的一员参加 该会议。

Sprint 回顾会议的目的在于:
 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何;

 找出并加以排序做得好的和潜在需要改进的主要方面;同时,

 制定改进 Scrum 团队工作方式的计划。

Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。在每个 Sprint 回顾会议中，Scrum 团队通过适当地调整“完 成”的定义的方式来计划提高产品质量。

在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在下一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然改进可以在任何时间执行，Sprint 回顾会议提供了一个专注于检视和调整的正式机会。

Scrum 工件

Scrum 的工件以不同的方式表现工作任务和价值，可以用来提供透明以及检视和调整的机会。Scrum 所定义的工件是特别地设计的，是为了给关键信息提供最大透明化，因此每个人对工件都需要有相同的理解。

产品待办列表

产品待办列表是一份有序列表，其中包含产品需要的一切可能的东西，也是产品需求变动 的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。

产品待办列表永远是不完整的。最早开发的产品待办列表只列举最初所知的以及理解最透 彻的需求。产品待办列表会随着产品及其应用环境的改变而演进。产品待办列表是动态 的，需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用。只要产品存 在，产品待办列表也就同样存在。

产品待办列表列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的改 变。产品待办列表项具有这些属性:描述、次序、估算和价值。

随着产品的使用、价值的获取和获得市场的反馈，产品待办列表会成长为更大和更详尽的 列表。因为需求永不停止改变，所以产品待办列表就如一份活的工件。业务需求、市场形 势或者技术的变化都会引起产品待办列表的改变。

多个 Scrum团队常常会一起参与对同一产品的开发。一个产品只有一个产品待办列表用于 描述下一步产品开发工作。那么这就可能需要使用能够对产品待办列表项进行分组的属 性。

产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续 的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精 化过程中，产品待办列表项被重新评审和修改。Scrum 团队决定如何来完成精化以及何时来完成。精化的工作通常占用开发团队不超过 10% 的产能。然而，产品负责人或者其他人 在产品负责人的斟酌下，产品待办列表项可以在任何时间来更新。

排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节。根据更清晰的内容 和更详尽的细节信息就能做出更为准确的估算;同样，排序越低，则细节信息越少。产品 待办列表项中那些即将会占用开发团队下一个 Sprint 大部分时间的项会被加以精化，因此，任一产品待办列表项都能够在 Sprint 的时间盒期限内适当地“完成”。这些能够被开发 团队在一个 Sprint 中“完成”的产品待办列表项称为“准备就绪”，它们将作为 Sprint 计划会 议中的待选产品列表项。产品待办列表项的足够透明程度通常要经过上述的精化活动来获得。

开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求，并根据 情况权衡取舍来影响他们，但是最终估算是由开发团队决定的。

监控目标实现的进度

在任何时刻，达成目标的剩余工作是可以累计的。产品负责人至少在每个 Sprint 评审会议 中都必须跟踪剩余工作总量。产品负责人比较这次的剩余工作量与之前 Sprint 评审会议时 的剩余工作量，来评估在期望的时间点达成目标的进度。这个信息对所有的利益攸关者都 是透明的。

各种不同趋势走向的实践已经被使用在预测进度方面，例如，燃尽图(burn-downs)、燃 烧图(burn-ups)或者累积流图(cumulative flows)。这些工具都被证实是有用的。然而，它们并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生的事是无法 预知的。只有已经发生的事才能用来做前瞻性的决策。

Sprint 待办列表

Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功能以 及交付那些功能到“完成”的增量中所需工作的预测。

Sprint 产品待办列表将开发团队用来达成 Sprint 目标的所有工作变得清晰可见。为了确保持续改进，它至少包括一项在先前回顾会议中确定下来的高优先级过程改进。

Sprint 产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日 Scrum 站会中清 晰地看到。开发团队在 Sprint 期间修改 Sprint 待办列表，使得 Sprint 待办列表在 Sprint 期 间涌现。涌现发生在开发团队按计划开展工作并学习到更多的关于哪些工作是达成 Sprint 目标所必需的工作时。

当新工作出现时，开发团队需要将其加入到 Sprint 待办列表中去。随着工作的执行或完 成，剩余的工作量被估算并更新。当计划中的某个部分失去开发意义，就可以将其移除。 在 Sprint 期间，只有开发团队可以改变 Sprint 待办列表。Sprint 待办列表是高度可见的， 是对开发团队计划在当前 Sprint 内工作完成情况的实时反映，该列表由开发团队全权负责。

监控 Sprint 进度

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

增量

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。

工件透明

Scrum 依赖于透明。优化价值和控制风险的决定都是基于所获知的工件状态。当工件的状 态是完全透明时，这些做出的决定才有一个坚实的基础;当工件的状态是不完全透明时， 这些做出的决定就会有瑕疵，而价值也可能因此遭受损失，同时风险也可能会因此而增 加。

Scrum Master 必须和产品负责人、开发团队和其他相关人员一起合作，以确保所有工件都 是完全透明的。有些实践就是为应对不完全透明的状态而生的，Scrum Master 必须帮助每 个人，让他们能够在遇到不透明的情况下采取最合适的实践。Scrum Master 能够通过检视 工件、嗅探模式、倾听周围的声音以及观察预期和实际结果的差异来发现不完全透明。

Scrum Master 的职责就是和 Scrum 团队以及组织一起合作增加工件的透明化。这一工作通 常包括学习、说服和改变。 透明化不会在一夜之间发生，但是这是一条必经之路。

“完成”的定义

当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么。虽然 在不同 Scrum 团队之间会存在巨大的差别，但是每个团队成员必须对完成工作意味着什么 有相同的理解以便确保透明化。这就是 Scrum 团队的“完成”定义，用来评估产品增量是否 完成。

这一定义也同时被用来指导开发团队了解在 Sprint 计划会议时能够选择多少产品待办列表 项。每个 Sprint 的目标在于交付符合 Scrum 团队当前“完成”的定义的潜在可交付功能增 量。

开发团队在每个 Sprint 都交付产品功能增量。这一增量是可用的，所以产品负责人可以选 择立即发布它。如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所有 Scrum 团队都必须遵守它，以此为最低标准。如果增量“完成”的定义不是开发组织的惯 例，那么 Scrum 团队中的开发团队就必须制定适合于产品的“完成”的定义。如果系统或产 品发布由多个 Scrum 团队一起开发，那么所有 Scrum 团队中的开发团队必须一起参与制定 “完成”的定义。

每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有 增量都能工作。

随着团队的成熟，“完成”的定义会扩大，包含更为严格的标准来保证更高的质量。任何产 品或系统都应该对其上面开发的工作有“完成”的定义。

结束语

Scrum 是免费的，在本指南中提供。Scrum 的角色、工件、事件和规则是不可改变的。虽然只实施部分的 Scrum 是可能的，但这样就不是 Scrum 了。Scrum 只以整体的形式而存在，唯其如此才能作为其他技术、方法和实践的容器运作良好。

致谢

人们

在千千万万对 Scrum 作出贡献的人中，我们要特别感谢那些在其最初十年提供帮助的人们。首先，要提到 Jeff Sutherland 以及与他一道工作的 Jeff McKenna，还有 Ken Schwaber 及与其一道工作的 Mike Smith 与 Chris Martin 。在随后的几年中，许多人都作出了贡献， 没有他们的帮助，Scrum 不会被提炼至如今这般。

历史

Ken Schwaber 和 Jeff Sutherland 在 1995 年举行的 OOPSLA 大会上首次联合公开演讲 Scrum。那次演讲本质上记录了 ken 和 Jeff 在之前几年间使用 Scrum 时所学到的经验。

在软件开发的世界中，Scrum 的历史已经算是很长了。我们对首批尝试和提炼 Scrum 的公司: Individual，Inc.、 Fidelity Investments 和 IDX(现在的 GE 医疗)表示致敬。

Scrum 指南记录 Jeff Sutherland 和 Ken Schwaber 开发和培育 Scrum 已经超过 20 多年了。其他的一些资源从模式、流程和见解方面为 Scrum 框架提供了补充，从而优化生产效率、价 值、创造力及提升自豪感。

翻译

本中文指南( 2017 版 )是从 Jeff Sutherland 和 Ken Schwaber 联合撰写的《 Scrum 指南》 ( 2017 版)的英文原版翻译而来。链接 http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Chinese-Simplified.pdf

译者:周建成 (Agile Coach)

修订: Jacky Shen (CST, CTC)

时间：2017年10月30日-11月1日
地点：Citywest Hotel,  Saggart, Co.,  Dublin, Ireland, + 353 1 401 0500 (爱尔兰都柏林)

大会介绍：

Scrum  Gathering是什么？

Scrum Gathering为全球的敏捷及Scrum实践者提供一次聚会的机会，分享关于在各行各业内的Scrum和敏捷的实践以及知识，体验scrum 和敏捷的热情。在为期2天的盛会中，你将遇见来自全球五湖四海热情的Scrum实践者、讲师、教练和粉丝，聆听精彩的主题演讲，参与开放空间活动，升华你对Scrum及敏捷的理解，激发变革的热情和勇气！

报名参会：

获得Scrum认证的学员已经自动成为Scrum Alliance会员，享受门票会员价 $1,350，(非会员价$1,600)

官网报名：https://www.scrumalliance.org/sgdub

UPerform优普丰敏捷学院学员可以联系Scrum培训导师获取支持，以及指导如何获得申请CSP认证所需的SEU学分。

UPerform优普丰敏捷学院作为中国区组织者和赞助商，从2008年开始支持Scrum Gathering China，并培养多名讲师做为演讲嘉宾分享案例和经验。