团队与技术敏捷性（TTA）能力描述了高绩效敏捷团队在敏捷发布火车上使用的关键技能、原则和实践，旨在为客户创造高质量解决方案。
团队与技术敏捷性（TTA）是业务敏捷性的七大核心能力之一。每项核心能力均配有专属评估工具，企业可通过度量与发展文章评估熟练度并获取改进建议，而系统的敏捷培训能帮助团队快速提升 TTA 能力，企业管理培训则可从组织层面为敏捷实践落地提供支撑。

为何需要团队与技术敏捷性？

敏捷团队创造并支持向企业客户交付价值的业务解决方案。因此，组织在数字时代蓬勃发展的能力完全取决于其团队能否可靠满足客户需求。团队与技术敏捷性是业务敏捷性的真正基石，包含三个维度（图 1）。通过Scrum 培训可帮助团队掌握维度落地的核心方法，Scrum 认证培训更能为团队提供标准化实践框架，确保敏捷能力的规范应用。

图 1. 团队与技术敏捷性的三个维度

• 敏捷团队：高绩效跨职能团队通过应用有效敏捷原则和实践奠定能力基础。
• 敏捷团队群：敏捷团队在敏捷发布火车（ART）环境中运作，ART 作为长期存在的团队群提供共同愿景方向，最终负责交付解决方案成果。
• 内建质量：所有敏捷团队应用定义的敏捷实践，创建支持当前和未来业务需求的高质量设计解决方案。

这三个维度是互补且相互依赖的力量，组织并引导着驱动价值流的人员。

敏捷团队

敏捷团队是敏捷开发的基本单元，也是 TTA 能力的第一维度。SAFe 中的敏捷团队是由不超过 10 人组成的跨职能小组，通过迭代定义、构建、测试并向客户交付价值。这些团队拥有管理工作的权责，从而提升生产力并加速上市时间。
每个敏捷团队采用 SAFe Scrum、SAFe 团队看板或混合方法协调同步与交付节奏。他们运用选定方法管理共享待办列表、增量交付、构建必要架构跑道，并获取客户与利益相关者反馈。团队对这些方法的熟练运用，可通过Scrum 培训中的实战演练强化，而Scrum 认证培训能进一步规范团队操作流程，确保方法落地效果。
敏捷团队的核心目标是交付卓越产品。如图 2 所示，他们通过聚焦五个关键责任领域实现这一目标。

图 2. 敏捷团队的五大责任领域

各责任领域概述如下：

• 连接客户：理解客户具体需求并指导产品开发，运用同理心与产品管理协作设计解决方案实验。
• 规划工作：规划工作并直接参与 PI 规划。维护团队待办列表，在迭代规划和待办列表梳理中校准优先级，在 PI 规划中发挥核心作用，并将工作与 ART 待办列表关联。这一环节的高效执行，可借助敏捷培训中教授的规划工具与技巧提升效率。
• 交付价值：拥有交付卓越产品所需的全部技能资源。通过各类同步事件和演示与 ART 保持对齐，建立持续交付流水线实现高频集成、测试、部署和发布变更。
• 获取反馈：定期寻求客户反馈以理解产品和技术价值。缩短与客户的距离，持续验证实施决策。
• 持续改进：追踪衡量绩效的流动、能力和成果指标，运用度量驱动回顾会，定义新绩效目标并实施改进。持续改进的方法论也是企业管理培训中组织效能提升模块的重要内容。

敏捷宣言指导团队履行职责（图 3）。尽管最初为软件团队设计，这些价值观适用于技术和业务领域的各类敏捷团队。

图 3. 敏捷宣言

价值交付常跨越传统组织边界。因此敏捷团队是多学科的（图 4），包含跨职能领域交付价值所需的全部人员和技能。团队成员全职投入，创造共同目标并增强流动。这种跨职能团队的搭建与管理，是Scrum 认证培训中团队动力学模块的核心教学内容，同时也需要企业管理培训中组织架构优化的支持。

图 4. 敏捷团队具备跨职能性

敏捷团队包含两个专业角色（图 5）：产品负责人确保团队待办列表符合客户需求，引导团队最大化业务价值；Scrum 主管 / 团队教练作为服务型领导者和团队教练，促进约定的敏捷流程并培育快速流动环境。两个角色的能力提升可通过专项Scrum 培训实现，确保团队核心岗位发挥关键作用。

图 5. 敏捷团队包含两个专业角色

每个敏捷团队对应以下四种拓扑之一，明确团队在价值流中的角色：

• 价值流对齐团队：围绕工作流组建，直接向客户或最终用户交付价值。
• 复杂子系统团队：围绕需深度专业技能的特定子系统组建。
• 平台团队：围绕开发支持其他团队的服务平台组建。
• 赋能团队：协助其他团队掌握新技能或技术。
  

敏捷团队群

构建企业级解决方案需要超越单个团队的能力范围和技能广度。单个团队无法在合理时间内构建交付大型系统，复杂系统也需无法由单团队承载的广泛专业技能。因此多个敏捷团队作为 ART 成员协作（图 6），跨业务职能交付解决方案。

图 6. 敏捷发布火车构建、交付并支持高价值解决方案

围绕一个或多个价值流组建的 ART 使团队对齐共同业务技术使命。ART 通过五大责任领域交付客户价值（图 7）。ART 的协同运作需要管理者具备规模化敏捷管理能力，这可通过企业管理培训中的组织协同模块提升，同时团队成员通过敏捷培训可更好地融入 ART 协作体系。

图 7. 敏捷发布火车责任领域

ART 责任领域与敏捷团队相同，但 ART 在规模化价值流中应用这些领域，交付具备商业价值的集成解决方案。与敏捷团队类似，ART 共同规划、共同承诺、共同执行、共同改进。这种规模化协作的标准化流程，可通过Scrum 认证培训中的 SAFe 框架内容进一步规范，确保 ART 高效运转。

内建质量

内建质量是一套确保敏捷团队和 ART 输出符合质量标准的实践。这些实践主张在开发过程中内建质量，而非仅在发布前检验质量。内建质量减少返工成本，显著加速价值交付。
如图 8 所示，内建质量由五大领域的专项实践组成。团队对这些实践的掌握程度，直接影响产品质量与交付效率，而Scrum 培训中包含的质量管控模块，能帮助团队将内建质量实践融入日常开发流程。

图 8. SAFe 内建质量关键领域与实践

不同情境下的质量评估与应用方式各异。SAFe 将内建质量实践分为五大领域以适应主要差异：

• 业务职能：HR、市场、财务等非技术解决方案领域受专属质量标准约束（如会计准则、营销规范）。
• 软件应用：开发软件方案需关注功能、非功能和合规需求。
• IT 系统：软件运行的基础设施需具备可扩展性、可靠性和安全性。
• 硬件：物理解决方案需符合重量、张力、电气等工程规范。
• 信息物理系统：软硬件复合系统（如汽车飞机）涉及复杂质量标准。

在这些领域中，敏捷团队和 ART 在开发周期早期应用特定实践确保质量内建：

• 基础敏捷质量实践：适用所有领域的基础构建模块（如左移学习、结对编程）。
• 业务质量标准：业务职能领域专属实践（如隐私法规）。
• 敏捷软件开发质量实践：软件方案开发实践（如持续集成、测试驱动开发）。
• IT 系统质量实践：基础设施实践（如基础设施即代码、可观测性）。
• 敏捷硬件工程质量实践：硬件方案开发实践（如建模仿真）。
• 信息物理系统质量实践：复杂系统实践（如基于模型的系统工程）。

混合应用这些实践确保解决方案所有元素高质量开发，实现最短可持续前置时间。详见内建质量文章。企业在推动内建质量实践落地时，可通过企业管理培训建立质量管控体系，结合敏捷培训提升团队执行能力，形成 “体系 + 执行” 的双重保障。

加速价值流动

原则 #6：实现无中断价值流强调 SAFe 是基于流动的系统。当敏捷团队、ART 和组合能以最小延迟交付高质量产品服务时，流动即存在。
为加速价值流流动，SAFe 各层级持续识别并修复低效活动。TTA 能力使敏捷团队能快速识别价值流局部的低效点，并运用团队流动中的流动加速器进行纠正。团队 TTA 能力越强，识别纠正流动问题越快。团队识别与解决低效问题的能力，可通过Scrum 培训中的问题分析与改进模块强化，而Scrum 认证培训能提供标准化的问题解决框架，提升团队改进效率。
TTA 也促进 ART 加速流动，但敏捷产品交付能力更直接赋能 ART 流动。

总结

TTA 使跨职能敏捷团队摆脱固定工作方式束缚，加速价值交付。这促进长期共学共长的团队交付卓越产品。ART 由多个敏捷团队组成，具备跨职能性并能覆盖完整解决方案生命周期。敏捷团队与 ART 共同负责内建质量，最终形成具备企业级持续价值交付能力的组织。对于希望提升 TTA 能力的企业而言，Scrum 认证培训可提供标准化实践框架，敏捷培训能强化团队实战能力，企业管理培训则从组织层面优化流程与资源配置，三者协同推动团队与技术敏捷性落地，帮助企业在复杂商业环境中保持竞争力。

为何需要敏捷产品交付？

实现业务敏捷性要求敏捷团队和敏捷发布火车（ARTs）提升快速交付创新产品和服务的能力。这需要平衡执行与客户关注点，确保在正确的时间为正确的客户创造正确的解决方案。无论是通过Scrum 培训掌握的迭代开发方法，还是Scrum 认证培训构建的标准化框架思维，都能为团队达成这一目标提供关键支撑，同时也是企业管理培训中提升组织交付效率的核心方向。
图 1 展示了 APD 的三个维度：

1. 以客户为中心与设计思维
2. 按节奏开发，按需发布
3. DevOps 与持续交付流水线
   APD 能力的相互支持特性为持续市场和服务领导力创造了机会。

图 1. APD 的三个维度

以客户为中心与设计思维

以客户为中心和设计思维构成 APD 的第一维度。这种思维模式和业务方式将客户置于企业核心，优先提供积极的客户体验并建立长期关系，这也是敏捷培训中反复强调的核心原则，同时在企业管理培训的客户价值管理模块中也有深入探讨。

以客户为中心

以客户为中心是一种思维模式和业务方式，专注于为用户创造积极体验并促进客户与组织产品服务的互动。它将客户置于每个决策的中心，深度考虑对最终用户的影响。这种思维模式促进长期客户关系，以出人意料的方式创造更多客户价值。APD 的这一维度鼓励敏捷团队：

• 聚焦客户：运用用户和市场研究（包括创建用户画像），使组织聚焦特定目标用户群体。
• 理解客户需求：投入时间识别并构建满足这些需求的解决方案。
• 像客户一样思考感受：运用同理心，努力从客户视角看世界。
• 构建完整产品解决方案：为用户需求设计端到端解决方案，确保初期和长期的用户体验最优且能持续演进。
• 创造客户终身价值：超越交易思维，关注解决方案生命周期内的整体客户关系。

以客户为中心的企业能创造更高利润、员工参与度和客户满意度。以客户为中心的政府和非营利组织则能增强韧性、可持续性及实现使命所需的协同性。
产品管理负责协调并推动新解决方案上市，同时确保现有产品的持续成功。产品管理者对客户需求的精准把控和团队协同能力，可通过Scrum 认证培训中的产品管理模块进一步强化，提升决策与交付效率。

设计思维

设计思维是以客户为中心的组成部分。这是一种迭代开发流程，确保解决方案符合客户和用户期望，同时保证其在生命周期内的可行性、经济可持续性。
它包含两个主要活动以实现可持续解决方案：

1. 理解问题：在问题空间探索问题的复杂性，明确问题定义，洞察理想解决方案的需求与收益。
2. 设计正确解决方案：在解决方案空间生成想法、可视化设计、开发并测试原型。

图 2 展示了设计思维的核心流程，以双钻模型呈现。该流程强调在创建解决方案前充分探索问题空间。
在开发中应用设计思维确保解决方案具备合意性、可行性和可持续性。同时，理解并管理解决方案经济性可实现产品 / 服务的持久性，这一过程中团队的协作与迭代能力，可通过Scrum 培训中的实战项目不断打磨。

图 2. 设计思维流程与活动

理解问题通常包含以下两项活动：

• 探索：通过用户互动和市场调研理解问题，识别未满足需求。
• 定义：运用聚合技术分析探索阶段数据，形成对具体问题及未满足需求的洞察。

探索完成后，组织获得设计解决方案的输入，通常涉及以下活动：

• 开发：运用客户旅程地图和故事地图快速设计高性价比的潜在解决方案。
• 交付：产出适用于创建解决方案的各类产出物，这些方案常以原型形式启动，由 ART 持续交付。

图 2 还展示了发散与收敛思维如何应用于探索想法、达成目标和应对挑战。二者缺一不可，共同为需探索创造力的挑战提供独特解决方案。

精益用户体验（Lean UX）

在 SAFe 中，精益 UX 将传统用户体验设计扩展到超越单纯设计执行和预测用户交互。它更全面地审视特性的存在原因、实现所需功能及其预期效益的假设。通过领先指标和即时客户反馈可验证系统是否满足客户需求与业务目标。精益 UX 提供定义、假设、构建、衡量价值与学习的闭环方法。
在精益 UX 中，设计师角色演变为设计引导者，承担新职责。除精益创业外，精益 UX 还有两大基础：设计思维与敏捷开发。设计思维将用户体验工作范围从界面和产出物扩展到整个系统，运用设计工具解决更广泛的客户问题，高度依赖协作、迭代方法和同理心作为问题解决核心 [2]，这些能力也能通过系统的敏捷培训得到系统性提升。

按节奏开发，按需发布

图 3 展示了按节奏开发和按需发布的概念。它将开发解决方案与发布价值分离，确保客户在需要时获得所需，从而提升业务敏捷性，这与Scrum 培训中强调的迭代节奏管理、价值增量交付理念高度契合，也是Scrum 认证培训的核心实践内容之一。

图 3. 按节奏开发实现按需发布价值

为何按节奏开发？

在基于流动的系统中，建立快速同步的规划区间（PI）节奏 —— 团队与 ART 活动的规律性预测节奏 —— 是管理产品开发固有可变性的有效策略。以下活动支持该节奏：

• ART 事件：ART 包含多个基于节奏的重要事件：PI 规划、系统演示和检视与调整。产品负责人和教练同步事件贯穿 PI，帮助消除障碍、解决瓶颈并传达团队所需调整。
• 敏捷团队事件：PI 划分为迭代，帮助对齐敏捷团队并快速响应变化。团队基于节奏的事件进一步支持工作：迭代规划、团队同步（通常每日）、迭代评审和迭代回顾，这些标准化流程的落地执行，可通过Scrum 认证培训中的角色职责与事件管理模块，确保团队高效协同。

简言之，团队采用针对高可变知识工作优化的流程，在可预测的节奏中提供可靠事件与活动序列。

为何按需发布？

按需发布通过按客户、市场和业务需求提供价值，带来显著战略优势。产品管理与利益相关者协作决定发布时间、发布内容和接收对象。
部分产品面向可即时提供新功能的细分市场，而其他产品可能受特定市场节奏制约（如实施路线图所述），需在最佳窗口期发布。
图 4 展示了新功能部署至生产环境后，根据用户或市场需求逐步或立即发布给客户的 RoD 流程。

图 4. 按需发布的四项活动

• 发布：描述一次性或增量式向最终用户交付解决方案的必要实践
• 稳定与运营：描述确保解决方案功能与非功能性表现良好的必要实践
• 衡量：描述量化新发布功能是否提供预期价值的实践
• 学习：描述决策如何处理收集信息并为 CDP 下一学习循环做准备的实践

构建并维护持续交付流水线（CDP）使各 ART 能定义、构建、验证并发布新功能以实现其 PI 目标，而 CDP 的规划与资源统筹，也是企业管理培训中技术与业务协同模块的重要内容。

DevOps 与持续交付流水线

DevOps 与持续交付流水线奠定了按需（全部或部分）发布价值以满足需求的基础。
虽然按需发布是 CDP 的目标，但获得可靠熟练的按需发布能力需要付出努力。这涉及接纳 DevOps 思维文化并创建高度自动化的流水线。
每个 ART 构建并维护（或共享）一个 CDP，包含尽可能独立交付解决方案所需的资产和技术。如图 5 所示，流水线的前三部分 —— 持续探索、持续集成和持续部署 —— 支持新功能交付。

图 5. 持续交付流水线

• 持续探索：推动创新并明确应构建内容。设计思维持续探索客户与市场需求，定义愿景和路线图。
• 持续集成：通过持续集成多个敏捷团队的工作，在开发过程中内建质量。
• 持续部署：代表将解决方案从预发布环境迁移至生产环境的相关流程。

如前所述，按需发布（图 4）是根据市场与业务需求一次性或以临时方式向客户提供价值的能力。

拥抱 DevOps 思维、文化与实践

高绩效组织通过 DevOps 快速响应客户需求来交付和支持产品服务，从而显著超越竞争对手。
图 6 显示开发（Dev）常处于快进模式以跟上持续变更与创新需求，而运维（Ops）因对生产稳定性和韧性负责常对变更按下暂停键。
DevOps 协调开发、运维及其他业务职能，实现速度与稳定性的最佳平衡。

图 6. DevOps 促进跨职能协作

最终，DevOps 是一种思维模式、一种文化及一套技术实践，可在无交接或过多外部生产运维支持下向客户交付解决方案元素。如图 7 所示，SAFe 的 DevOps 方法基于五大概念：文化（Culture）、自动化（Automation）、精益流动（Lean Flow）、度量（Measurement）和恢复（Recovery）（CALMR），简要说明如下。

图 7. SAFe 的 CALMR DevOps 方法

• 文化：需要建立跨整个价值流的共享责任文化，所有相关部门（开发、测试、安全、合规、运维、架构等）共同创造价值。
• 自动化：通过减少或消除 CDP 中人工干预来降低错误并缩短发布周期时间。
• 精益流动：促进限制在制品（WIP）、减小批次规模和缩短队列长度，即实现无中断的价值流（原则 #6），加速客户反馈。
• 度量：通过理解和度量流水线中的价值流支持学习与持续改进。
• 恢复：构建支持快速修复生产问题的系统，如自动回滚、“前向修复” 能力和不可变基础设施等。

团队对 DevOps 实践的掌握，可通过敏捷培训中的 DevOps 专项模块深化，同时管理者通过企业管理培训可更好地推动跨部门文化融合，为 DevOps 落地创造组织环境。

云计算是 DevOps 的关键使能者

不断扩展的云能力从根本上改变了数字化解决方案的构建、部署和维护方式。自诞生以来，云计算一直是改变企业 IT 交付模式最具颠覆性的驱动因素。向云迁移的主要动因正是提升产品开发速度与敏捷性。
云无处不在，它推动数字业务发展并赋能 DevOps 与更高效的 CDP。SAFe 企业可利用云的强大能力与普适性提升组织各领域的敏捷性，而团队对云环境下敏捷实践的适配能力，也可通过Scrum 培训中的技术协同案例进一步强化。

团队与 ART 价值流

由于 SAFe 是基于流动的系统，必须快速解决任何中断以实现持续价值交付。SAFe 提供六篇文章帮助解决流动障碍：原则 #6—— 实现无中断的价值流、价值流管理、团队流动、ART 流动、解决方案火车流动和组合流动。每篇文章定义了一套 “八大流动加速器”，帮助识别、修复、优化和调试问题以实现持续价值流。
ART 与团队流动指南直接适用于 APD 能力：

• ART 流动：代表 ART 向客户持续交付价值的状态，描述敏捷团队群（ART）如何与利益相关者协作贴近客户并构建 CDP。CDP 加速产品与服务交付。
• 团队流动：代表敏捷团队持续交付客户价值的状态。

SAFe 的团队与技术敏捷性（TTA）能力提供创建高效跨职能敏捷团队与 ART 的实践，促进内建质量实践应用以及与扩展利益相关者协作以更快交付解决方案。高效团队的搭建与管理，是Scrum 认证培训中团队动力学模块的核心内容，同时也是企业管理培训中组织效能提升的关键课题。

总结

企业需平衡执行聚焦与客户聚焦，确保在正确时间为正确客户创造正确解决方案。APD 植根于以客户为中心、设计思维和精益 UX，将客户置于每个决策核心。应用设计思维确保解决方案具备合意性、可行性、生存力和可持续性。
按节奏开发帮助管理产品开发的固有可变性。按需发布将发布与开发节奏分离，确保客户在需要时获得所需。DevOps 与 CDP 奠定按需（全部或部分）发布价值以满足客户与市场需求的基础。APD 增强业务敏捷性，为企业及其客户提供卓越成果。对于希望落地 APD 能力的组织而言，Scrum 认证培训能为团队提供标准化实践框架，敏捷培训可强化实战能力，而企业管理培训则能从组织层面优化流程与资源，三者协同推动企业敏捷转型。

讲师：Jack Hou, 侯伯薇

地点：上海

价格：RMB 7000元每位，提早报名或团队报名有优惠。

联系方式: 021-34753688

Email: Service@uperform.cn

授课顾问

侯伯薇

• 管理3.0认证引导师 & 共同所有人
• Scrum联盟CSPO，CSM，CSP
• 英国皇家管理公会CIPMT认证培训师
• 英国贝尔宾团队角色认证顾问

标准时长：

3天

课程目标

当前的团队越来越多都是由知识工作者组成，这与传统工业组织中的团队有非常大的区别。在IT行业里面尤其是这样。

在面对这样的团队时，您是否遇到以下问题：

• 传统的管理模式已经无法适应当前的团队和项目，需要选择新的管理模式和方法？
• 面对多种敏捷相关的方法和框架，不知如何选择和遵从？
• 需要激励团队中的成员主动、积极地提升自己，从而为了团队的共同目标而努力？
• 对团队成员的能力模型缺少足够的了解，无法让合适的人在合适的岗位上工作？
• 如何通过赋能、信任、授权，让组织达到自组织和自管理的状态？
• 在面临各种约束和障碍的时候，如何做出沟通和协调？
• 如何迅速提升团队成员的能力，并促进其持续改进和替身？

……

本课程会让大家：

• 更好地了解团队这个复杂系统；
• 了解如何通过内驱力来激励员工；
• 掌握深入了解团队成员的各种方式；
• 知道如何通过信任、授权和赋能逐步让团队实现自组织和自管理的状态；
• 了解团队存在的各种意义，并通过意义来调和约束；
• 知道如何提升团队成员的能力，并采用合适的度量标准进行检验；
• 掌握通过沟通形成的合力促进结构的成长；
• 如何在面临变革的时候，能够保证组织的全面提升和进步；
• ……

从而让您可以具有更适应新时代的团队管理能力和领导力，更有效地促进团队成员以及组织整体的成长，为即将到来的变革做出最好的准备，为已经进行中的变革做出最佳的决策！

课程特色

• 本次课程会采用体验式游戏的方式，带领大家在轻松、愉快的气氛下，理论联系实际，不仅让大家可以收获到各种先进的理论和工具，而且知道如何在工作中把合适的措施落地；

面向对象：

想提高管理能力和组织绩效的任何人，不管你是否拥有敏捷或软件经验。这个课程定位于想变得敏捷的领导者/管理者，以及其他涉及到领导力和管理的人士，包括CxO、创始人、高层管理者、项目领导者、敏捷教练、ScrumMasters等等角色（课程参与者不需要有敏捷（Agile）的实操经验，若对敏捷原则和实践有一定程度的熟悉确实对学习有帮助）。课程结束后，每位学员获得Management 3.0机构(www.management30.com)颁发的证书

你的收获：

管理3.0是关于走向更加敏捷的组织，在管理层面的一套思想、理论与具体实践的强大组合。由Jurgen Appelo 创建并持续发展，并源于其重要著作《管理3.0》及正在编写的《管理3.0 Workout》

• 了解复杂性科学和系统性思考；
• 了解何时去管理和何时去领导；
• 如何激励员工（Energize People）;
• 如何赋能团队（Empower Teams)；
• 如何调和约束（Align Constraints）;
• 如何培养能力（Develop Competence）；
• 如何结构成长（Grow Structure）;
• 如何全面改进（Improve Everything）；
• 同时获得PMI的PDU学分或者ACP Contact Hours

课程大纲

第一天上午

一、 敏捷管理（从更高的高度思考敏捷）

    1. 当前团队的特点

    2. 梅里的故事与中国员工幸福感

    3. 各种敏捷实践的关键点

        a) Scrum

        b) 看板方法

        c) 极限编程

    4. 敏捷的解读

        a) 频密交付可见、可用的软件

        b) 主动、持续地做学习和改进

    5. 管理3.0简介

二、 复杂性理论

    1. 现代的组织是复杂性系统

    2. 敏捷方法与复杂性理论

        a) 敏捷面对的是复杂的时代

        b) 敏捷就是面对复杂时的适应性

    3. 如何应对复杂性问题

第一天下午

三、 激励员工（内驱力）

    1. 为何以及如何激励员工

    2. 内在驱动力

        a) 好奇

        b) 荣誉

        c) 认可

        d) 能力

        e) 权力

        f) 自由

        g) 关系

        h) 有序

        i) 目的

        j) 地位

四、 了解团队成员

    1. 了解团队成员的各种方法

    2. 贝尔宾团队角色

        a) 个人测评

        b) 团队测评结果

        c) 贡献者游戏

第二天上午

五、 赋能团队（如何授权）

    1. 为何以及如何赋能团队

    2. 信任

    3. 授权

        a) 告知

        b) 推销

        c) 咨询

        d) 商定

        e) 建设

        f) 征询

        g) 委托

    4. 授权扑克故事

    5. 应用授权版

第二天下午

六、 统一目标（团队的意义和目标）

    1. 为何以及如何调和约束

    2. 团队存在的三种意义（目标）

        a) 外在

        b) 内在

        c) 浮现

    3. 创建团队的目标

    4. 团队愿景

        a) 愿景的创建

        b) 愿景的传播

        c) 远景的理解

第三天上午

七、 培养能力（如何考核）

    1. 守破离

    2. 培养能力的方式

        a) 自学

        b) 教练 & 指导

        c) 培训 & 认证

        d) 文化 & 社交

        e) 工具 & 基础设施

        f) 监督 & 控制

    3. 快速提升的循环模型

        a) 学习

        b) 思考

        c) 分享

    4. 思考力提升练习

第三天下午

八、 结构成长（在保证沟通的前提下扩展组织）

    1. 领导力的层级与法则

    2. 自组织团队

        a) “T”型人才

        b) 非正式领导力

        c) 宽泛的职位名称

        d) 价值单元

    3. 成员的职责

    4. 团队扩展

    5. Meddlers

九、 变革管理（如何导入变革）

    1. 变革需要考虑的因素

        a) 系统

        b) 个体

        c) 交互

        d) 环境

    2. 导入变革的方式

    3. 持续改进与提升

    4. 变革管理的步骤

十、 总结和展望

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)

1. 不能确定优先级

如果你大部分的任务要求你去同等的专注时，识别出你最高优先级的任务就成为极为重要。例如，你正开始工作在一个高优先级任务上，此期间你又和团队一起脑风暴一些美妙的创意而此时你的一个同事牵涉你的注意力说你需要再关注一个刚刚出现的突发问题。（你和你的团队成员正着手一个高有先级的任务，正当你们热火朝天地讨论着头脑风暴带来的各种绝妙的点子，你的一个同事冲进来提请你要处理一个突发的紧急事件）要知道这种情景是无法避免的而且总会有我们必须处理的一些浪费时间的情景。学会怎样排优先级是一个过程而且你需要时间和经验去发现最有效的方法，这也是(也就是)一个对你最适合的方法。有些工具如“行动优先级矩阵”或“Google Keep” 都能帮助你排优先并维持在一个稳定的效率层面上。

2. 拖延开始你的一天

不管怎样要求任务，如果你不能早点开启你的每一天所有你想要顺利完成你的日常任务的努力将要失败。所有大的预言家们（有真知灼见）和最有影响力的领导者们都共同分享到（有一个共通点）： 他们起得早去做他们最有价值的任务。延迟开启你的每一天就会促发多米偌骨牌效应。你将不得重新规划你的大部分任务并感觉到一天的忙乱。

3. 无效率地规划任务

我们效率的高低不仅仅每天变化，而且依赖于一些因素也随着人的不同而变化着。有些人在清晨睁开眼睛的时刻就处在效率的巅峰，而有些人恐怕要在太阳下山后才展现出他们最大的潜能。平衡好你时间的最容易方式就是发现你的巅峰期并分配好该时光去做最高优先级的工作而不是把它摊分到完成一些不太重要的重复性的任务上。

4. 拖延症

拖延症也许是你最可怕的敌人。没有什么更可怕的是在那里兜圈子和找借口而无法来认真对待你的工作去损耗你的注意力和正在的能力。这不仅堆积了大量要办的工作事项而且也使得你没有开始你的工作感到内疚，尤其是如果是紧急的事情。

避免这种情景的最好方法用一小部分时间来专心开启任务。这将唤起你的想象力并吸引你的注意力。很快你将全身心地投入到项目中。如果这不能有帮助的话，尽量把任务切分成可管理的几部分。前述的方法也将帮助你跟踪时间并给你留下一个清晰概括多少时间你需要去完成这个任务（让你更清楚地知道你需要多少时间去完成这个任务）。

5. 不能管理许多分心的事

当大量交流平台和社交媒体允许我们较容易地进行交流时，它们也是我们在生活和事业（工作）中感受到分心的主要原因（的主要干扰源）。

无论是响个不停的电话还是从聊天或社交媒体群中不断获得的通知，它们打断我们的工作流程（节奏）和破坏我们创新的流程（思路）。关掉所有的通知和聊天，规划避免打扰的时间如一个或两个小时，缩短你花在那些不影响你工作的一些（对你工作意义不大的）事情上的时间。

6. 低估要完成某些事的时间

一个最通常最有抱负的人倾向（通常激进的人最容易）掉进去的陷阱是错误地计算他们需要去完成一个特殊（某项）任务的时间和精力。这种行为是典型A类过于强求成功的人。他们认为能将一切事情置于可控之中，绝不拒绝任何一个机会不管怎样要求它（它会花掉他们多少时间和精力）。

7. 多重任务

极力精通我们所做的事（努力去胜任我们的工作），人们通常会掉进多重任务并发的陷阱。理论上讲，如果你必须把工作量放在你的首位（能承受高负荷的工作量）那么同一时间处理多重任务也是可行的。然而在同一时间做多个事情使得你无法均衡专注在多个任务上，和顺序完成你的任务相比较就要花费更多的时间（比较一件事情一件事情按部就班地去做，多重任务会导致你花更多的时间去完成）。换句话说，如果你想擅长多重任务你需要具备极强的条理性并维持在一个高度专注，有创造性和精准的层面上。

总之，多重任务不是针对（适合）每个人的，所以要仔细选择你战场。无论什么时候一些场景容许多重任务的话（只要情况允许），应放弃多重任务，并（请）专注一个时间一个任务。这将帮助你产出高质量的工作并使得你有成就感。

8. 忙而无效

尽管我们尽可能多专注在高价值的工作上，我们有时仍会跑偏发现我们自己做大量低价值事情，它们不仅吞噬我们的精力和时间而且对最终的我们尽力想取得的结果产生微小甚微的影响或毫无影响。

要避免这种情景，你必须时常告诫你自己：

• 这个有用吗？
• 这个怎样有助于最终结果

如果你有些琐碎的任务要处理，试做将他们聚集在一起。比如，不是一天做一个任务，而是在一个下午做在三天内要做（完三天）的琐事。这或许帮助你专注在真正的工作上。

9. 完美主义

我们的整个人生是一个学习过程。每次我们投身到一个新项目中，我们要面对许多障碍，但是我们也学会怎样在整个过程中越过它们。然而(虽然)我们应该尽力会朝着最佳的表现（达到最佳效果），你需要记住你没有赐予一切（时间）来完成每个任务至臻至美。

再回到优先级。你的时间是有限的并且如果你不想总是超时工作你必须有时是见好就收 -正如他们所说的那样不要让完美成为好的对立面。

10. 忽视休息

这听起来像是反生产力但它的确是非常重要的体现在你的日常事务中从长期中想要看到的结果（从长远效应来看它在日常工作中的体现尤为重要）。无论你是正工作（在）做在（一件）紧要的任务还是一些琐碎的差事，设定一定的时间休息是完全必要的。根据一项由Draugiem Group进行的研究，我们的大脑完全不能长期专注8个小时。唯一合理的方案是离开并做些与你工作无关的事 -吃，去疾走一下，锻炼，或者完全不做任何事情并且放松一下。这可以帮助你清晰你的思考并获得更多心理能量来应对接下来的工作。

要更好地控制你的计划，你需要前期投入一些时间来识别妨碍你完成一些事情的障碍。总之，在合理的时间管理上，我们是自己最大的敌人，我们必须控制住好自己。

作者：Maja Mrsic
译者：Shirley
原文：http://labs.openviewpartners.com/common-time-management-mistakes/