经济实惠的Scrum Master认证：分步计划
我们自豪地宣布，本文获得了推荐……
就在LinkedIn这里 >>>
自从 Scrum框架 成为开发与交付软件的最佳方式之一，似乎每个人都有同样的目标。
早晨醒来，打开笔记本电脑，因拥有这样的东西而感到欣喜与安心：
Scrum Master认证。
这就是梦想，对吧？
交付优秀的 软件 给雇主与客户。
凭借Scrum流程的技能与知识，以及您的 Scrum Master认证，拥有精彩的职业生涯.
对大多数人来说，Scrum Master认证是开始接触Scrum框架的方式。
在本文中，我首次分享一份深入、详细的分步指南，帮助您获得Scrum Master认证。
经济、快捷、在线、省心！
仅需四个简单步骤，您就能成为出色的Scrum专业人士，并获得 您的Scrum Master认证。
本文旨在说明Scrum如何支持您的职业发展、提高专业成效，以及为何应尽早持续发展Scrum Master的技能与能力。
定义：什么是Scrum Master认证？
您可以找到关于以下内容的最佳定义： Scrum Master认证，拥有精彩的职业生涯 见于 International Scrum Institute™的 Scrum Master Accredited Certification™.
Scrum Master认证是 您具备Scrum软件开发与交付流程能力的证明。 Scrum Master认证认可 您在正式选择题考试评估后展示出的Scrum框架知识与出色专业能力。
Scrum软件开发流程迄今已为数百万名专业人士带来巨大益处。因此，您完全有理由加入这些成就卓越的人士，他们借助Scrum框架提升了职业发展与技能。
如果仍有疑问，我想向您保证，没有Scrum Master认证，便难以想象持续发展的职业生涯。无论您在以下生态系统中的角色、头衔和经验如何： 信息技术（IT） 生态系统。
现在，即使不是IT专业人士，也可以理解什么是Scrum、Scrum如何运作，并获得Scrum Master认证。
无论从事什么职业、是否属于IT部门，都有一个重要且无可争辩的事实：您为组织承担的任务与提供的专业业务价值，都依赖并关联于IT、软件，以及 敏捷Scrum流程与原则.
此外，随着传统商业模式转向由以下模式驱动的业务： 软件即服务（SaaS） 也就是所谓的 数字化运动, 无论IT部门内外，专业人士取得Scrum Master认证都已不再是可有可无的选择。 如今，获得Scrum Master认证已成为必须。
您可能刚开始职业生涯，也可能是资深IT专业人士。这并不重要，您都需要获得Scrum Master认证。
您的角色可能涉及人员与职能管理，也可能不涉及。这同样不重要；您仍需要Scrum Master认证。
您的职位可能是：
- 业务分析师，
- 软件架构师，
- 企业架构师，
- 软件设计师
- 用户体验（UX）设计师，
- 用户界面（UI）设计师，
- 软件开发人员，
- 软件开发经理，
- 测试工程师，
- 测试自动化专家，
- 测试经理，
- IT系统运维专家，
- Unix/Linux管理员，
- 信息安全（InfoSec）工程师，
- IT网络工程师，
- 数据库管理员（DBA），
- 项目经理，
- 项目集经理，
- 产品经理，
- 团队负责人、经理、总监或高管，
- 或者其他未列出的职位。
您应学习Scrum软件开发框架，今天就通过获得以下资格成为Scrum Master： Scrum Master认证，拥有精彩的职业生涯.
采用敏捷Scrum流程与Scrum Master认证之前的3大混乱与沮丧因素
为了更好地理解Scrum框架对软件工程实践与业务的影响，不妨回顾工作中的一天，或一个真实软件项目。
因此，我想简要谈谈过去的一个软件项目，那时我们的组织尚未采用Scrum开发与软件交付框架。
写下这些文字前几天，我与一位近20年前共事的前同事吃了午饭。这位名叫Marcus的先生已获得Scrum Master和Scrum Product Owner认证，颁发方是 International Scrum Institute™.
他目前在敏捷项目管理软件领域的一家领先软件公司担任Scrum Master。
作为Scrum Master，Marcus如今支持一个敏捷Scrum团队，成员分布在全球不同地点。
午餐时，Marcus承认分布式敏捷Scrum团队面临许多典型挑战。他特别提到的软件项目配置问题包括：
- Scrum团队成员之间工作风格不同，
- 时区差异，
- 文化不契合，以及
- 语言限制。
尽管有这些困难，Marcus仍补充说，与20年前的工作方式相比，采用敏捷Scrum流程开展软件项目更有趣、更高效，也更充实。 相比于以前没有Scrum软件开发与交付流程的时候。
Marcus的评价来自一位成就卓越、经验丰富的经理、Scrum Master与Product Owner，是对Scrum框架的有力肯定。
谢谢你，Marcus！
接着，我向他讲述了自己接触Scrum框架之前的一个软件项目。相信许多Scrum Master会联想到自己获得认证之前的项目经历。
在1990年代末，我加入一个软件工程团队，负责构建基于智能卡的 公钥基础设施。智能卡安全保护成员私钥，关联公钥和封装证书则公开分发，正如“公钥”的名称所示。
当时项目本身相当复杂，需要多个相互依赖的硬件与软件团队，进行大量 研究与开发（R&D） ，才能构建完整可用的软硬件系统。
请记住，那是在以下事物出现之前： 最小可行产品（MVP） 概念来实验、创造、学习并再次实验。
如需进一步了解如何采用敏捷方法构建MVP，欢迎阅读这篇 文章 来自Cleevio，帮助您更好地了解这一复杂流程。
在没有Scrum的情况下，构建包含众多硬件和软件元素的复杂基础设施，确实是一项挑战。
没有Scrum Master，团队中也无人持有Scrum Master认证时，我们遇到了以下三项重大挫折。
没有Scrum Master认证时的第1个混乱与沮丧因素：尚未理解项目全貌，就必须规划整个项目
没有Scrum时，我们的团队开发并交付了完全错误、无法满足客户需求的软件与硬件产品。
在职业生涯中，我们曾遇到第三方公司强行规定应如何构建软件产品或服务。
能力成熟度模型（CMM）, ISO 9001:2008 及其衍生方法试图帮助企业确保以正确方式构建正确软件。
它们曾多么成功，不在本文讨论范围内。本文旨在关注Scrum流程与Scrum Master认证的价值，而非把质量管理和流程改进标准视为已被淘汰的Scrum替代方案。
不过，需要补充的是，在Scrum软件工程框架出现之前，这些流程改进框架在项目中通过阶段式方法实施。我们采用的分阶段软件工程方式称为 瀑布式软件工程模型.
采用瀑布模型时，每个软件项目都应从需求分析开始，目的是理解客户需要什么、想要什么。
随后，我们针对需求进行设计、实现、测试（验证），并在软件生产环境中维护，最终走完软件工程生命周期。
但现实并非如此！
瀑布式软件工程模型某个阶段的意外延误，必然会对后续阶段产生负面影响。
这就是Scrum框架出现前的工作。
没有持有Scrum Master认证的专业人士指导，软件在不同团队之间反复移交，令工作繁琐、复杂且低效。
最终，受损的不只是产品，员工士气和对组织使命的投入也遭到严重破坏。
没有Scrum Master认证时的第2个混乱与沮丧因素：不同团队缺乏承诺、变更管理与协作纪律
Scrum 之前的流程改进框架，最大弱点是： 他们主要关注满足领导层自身利益的组织要求。
例如监控、合规和可预测性。 完全不关注如何服务好客户、提升员工士气。
因此，软件管理团队和内外相关方试图设定固定交付期限，并轻松监控工程阶段进展。
偏离计划就处罚员工，期望在预定完成日前解决新问题。
此外，独立孤岛执行彼此完全分离的软件工程阶段。例如，开发团队与软件测试（验证）团队完全独立。多数本应为同一业务使命工作的人，甚至连彼此的姓名都不知道。
猜得到为什么组织重视孤岛，而非业务使命及员工的专业和业务成熟度吗？
原因就是 矩阵管理。它是一种组织和人员管理结构，自 1970 年代存在于企业。乍看之下，矩阵的独特理念似乎聪明。
领导层将具备相似职能与技术技能的员工放入同一孤岛，或至多相邻孤岛，由此形成组织结构。
当时，企业中的所谓“能力中心”相当常见，每个中心都是独立自主的孤岛。
C++ 开发一处、数据库管理一处、质量保证又在海外独立一处，没完没了。真让人费解！
矩阵组织结构最大的挑战是：没有Scrum框架和Scrum Master时，为交付软件项目，项目经理必须临时从各孤岛借调员工。
这些员工甚至不会与项目团队坐在一起，仍留在各自能力中心的办公室。
项目完成后，临时团队解散，参与人员转到下一项任务，为其他项目服务。
所以项目追求的业务价值，从不是这些独立孤岛的最高重点。
它们把工作看作此项目打个勾、彼项目打个勾。
领导和矩阵结构没有教人如何承诺改善业务，包括销售、收入和利润。
McKinsey & Company 在 McKinsey Quarterly 的文章也清楚说明了这种 矩阵组织中的成本优化幻觉.
原文引用了Gartner关于全球年度情况的估算 花费 6000 亿美元恢复 IT 系统 ，以应对计划外维护和缺陷。
现在，让我们花点时间想象，软件项目的变更管理和障碍处理是如何开展的。 在采用瀑布模型、矩阵组织且没有Scrum流程的项目配置中，它们如何运作。
对，你说得没错。 管理层与员工将 变更管理、障碍与错误处理 视为本不该发生的恶性例外。
因此，软件项目中的变更成为延误的同义词，通常引发层层延误的多米诺效应。团队需要找人指责，为缺陷和障碍背锅。
最后，由于没有处理、纠正和学习错误的机制，孤岛不断重复相同错误。
此外，他们不断增加 技术债务 ，却被动应付问题。
没有Scrum Master认证时的第3个混乱与沮丧因素：专断决策凌驾于民主决策之上
Steve Jobs 曾说：
“雇聪明人再告诉他们做什么，没有道理。我们雇聪明人，是让他们告诉我们做什么。”
然而，这与Scrum时代之前多数主流领导者的决策方式恰好相反。
在组织采用Scrum流程之前，领导者的专断决策凌驾于团队集体智慧之上。
他们否定了负责实际工作的群体的民主决策能力。 而这些工作跨越从构想到运维的整个生命周期。
决策离受其影响的工作中心（团队）越远，就越难作出正确的关键决策。
领导的判断常冲动、欠思考，通常迟缓且犹豫，有时又过早。
这些 专断决策 自上而下强加，让员工觉得不受重视，彻底阻碍组织以创新方案应对竞争性业务和软件挑战。
此外，当软件工程团队被要求参与决策时，这种方式也会打击他们提供意见的积极性。
以上简要回顾了组织采用Scrum框架之前，我们如何开发与交付软件服务及服务产品。现在，让我们看看Scrum流程如何帮助解决这些混乱与沮丧因素。
什么是Scrum？
首先，我想强调，本节并非旨在成为回答所有Scrum框架问题的权威参考。不过，这些内容将为大多数初级和中级Scrum专业人士提供深入的起步帮助。
对于希望快速学习Scrum框架、寻找更深入却仍实用的指南的人，我们也有准备。建议您 通过这里的链接下载我们的Scrum框架指南。
什么是Scrum？不必过于复杂，Scrum框架可定义如下：
Scrum是一种轻量级框架，通过针对复杂问题的适应性解决方案创造价值。迭代与增量式软件开发是其重要应用之一。
虽然软件是Scrum框架的主要关注点，迭代且敏捷的Scrum流程也可以，而且已被应用于软件行业之外。
IT行业许多人认为，“Scrum”一词在2000年代初随着敏捷软件开发与交付趋势兴起而创造。这种说法不正确！
1986年1月的Harvard Business Review文章描述了一种早于后来的Scrum框架的产品开发方法。Hirotaka Takeuchi与Ikujiro Nonaka合著该文：The New New Product Development Game。（没错，有两个New）
您应该看看 "The New New Product Development Game" 了解有关Scrum的一切是如何开始的！
IT行业谈论Scrum框架时，常在同一语境中听到“Agile Scrum”和“Scrum”。这使一些人开始思考并寻找两个术语之间的区别。
好消息是，“Agile Scrum”与“Scrum”指的是同一件事，都是指Scrum软件工程流程。那么，为什么有时在“Scrum”前加上“Agile”一词？
因为Scrum框架完全接受并融入了 敏捷宣言（敏捷软件开发宣言） 融入其核心流程、原则与底层理念。因此，在深入Scrum流程的技术细节前，应先更好地理解敏捷宣言与Scrum流程的价值观。
敏捷宣言（敏捷软件开发宣言）
敏捷宣言价值观：
- 个体与互动高于流程与工具，
- 可工作的软件高于详尽文档，
- 客户合作高于合同谈判，
- 响应变化高于遵循计划。
虽然右侧各项仍有重要价值，敏捷宣言更加重视并优先考虑左侧各项。
宣言偏重的要素经过时间检验，精心选择，以便：
- 更好服务客户与利益相关者，通过软件创造价值，
- 提升软件工程职业，无论您的角色、头衔或职业阶段如何。
Scrum框架价值观
前面提到，Scrum框架不仅是软件工程流程，也有一套坚实的基本原则。
实际上，大多数专业业务领域都能应用这些原则。
仅获得Scrum Master认证，不足以在Scrum领域取得巨大成功。您必须牢牢把握Scrum价值观，才能成功。
从而出色完成工作，开发出客户和雇主喜爱的软件。 现在，让我进一步介绍Scrum流程的这些原则。
勇气
有时，为客户创造最佳价值与益处而做正确的事，并不是最容易的选择。这时，Scrum Master、Scrum Product Owner与团队成员应牢记自己的职责与义务。
也就是在各自业务和信息技术领域，打造尽可能出色的产品与服务。要超越平庸， Scrum团队迟早会面临困难决策，无法让其利益相关者生态系统中的每个人都满意。
为应对这种情况，所有团队成员都应记住Scrum Master认证培训所学内容。
他们应牢记勇气，并学会勇敢决策与行动。
专注
在Scrum框架中，听到“专注”这一价值观时，应思考两件事：
- 识别正确的工作： 哪些任务是实现Sprint目标所必需的？哪些事情对于为客户开发最佳软件产品和服务、使其满意至关重要？
- 确定优先级： 接下来我应该处理哪些任务？
每时每刻，整个Scrum团队，包括Scrum Master与Product Owner，都必须回答一个关键问题。 这个问题是：“为了履行雇主最初聘用我们的目的，现在最重要的事是什么？”
Scrum框架包含多项内建事件（仪式），确保用户故事与任务得到合理排序。根据Scrum流程，应持续重视用户故事及相关任务的优先级安排。
这样才能确保Scrum团队按正确顺序做正确的事。 正式Scrum事件与相关细化实践，帮助我们检视关注重点并调整工作：
- Scrum梳理会议： 细化对即将开展的Product Backlog条目进行澄清、拆分与大小估算，并为排序提供信息。会议只是开展这项持续活动的一种方式。
- Sprint 规划会： 这些会议帮助我们看清依赖关系和正确的工作顺序，以交付用户故事。
- 每日 Scrum 会议： Daily Scrum（每日站会）帮助我们确定即将开始的工作日的基调，应把注意力放在最需要的地方。
- Sprint 评审会： Sprint Review会议间接显示团队应将关注重点放在哪里，以便未来的评审更加成功。
- Sprint 回顾会： 这些会议帮助Scrum团队确定工程流程中应优先改进的方面。
本节仅从专注的角度讨论Scrum仪式。更详细的说明见 本文后面的Scrum事件部分.
读到这里，您应该已经清楚，排序与专注对Scrum框架多么重要。
承诺
没有Scrum Master、Scrum Product Owner与团队的承诺，就无法通过软件交付出色成果。
在Scrum软件开发流程中，多数人将承诺理解为对某个Sprint交付目标的认同与约束。
这种理解完全说得通，却还不够完善。 在Scrum价值观语境下谈到“承诺”时，作者用“执着”强调投入。按照Scrum定义，承诺涉及团队目标与相互支持，并不要求过度工作，也不要求对每个预测条目都确定无疑。
要在软件工程、生活与业务中成功，应执着于目标。因此，在Scrum流程中， 您应执着于为客户打造出色软件，解决他们的问题。
为何承诺及对Scrum目标的执着如此重要？因为若不执着于构建和交付出色软件的团队使命，每次遇到较大障碍，工作都会放慢甚至停滞。
随后，Scrum Master与团队就会开始编造解释，向Scrum Product Owner说明并合理化无法实现Sprint目标的原因。 如果目标是成为超越平均水平的Scrum团队，借口就不应再有容身之地。
只有具备极高投入，解决客户问题、通过软件帮助客户创造价值，才会更轻松且更有成就感。
尊重
无论年龄、性别、种族、信仰、经验、能力、观点与工作表现如何，每位Scrum团队成员都应相互尊重、相互信赖。
尊重不局限于团队内部。与团队互动的每位内部或外部IT与业务利益相关者，都应得到充分尊重与欢迎。
经验丰富的成员应注意，不要打击经验较少成员的参与意愿。
尤其应妥善接纳并回应多数人不同意的反对意见。
开放
“开放”常是普通团队与高绩效Scrum团队的主要区别之一。可以将团队的开放能力，理解为一群思想开放者汇聚而成的巨大能力。
他们富有创造力、创新精神与智慧，诚实、直接且谦逊。 在Scrum软件工程与交付流程中，人们应能公开讨论挑战和不同观点。开放并不意味着每个决策或行动都合适；尊重、质量和团队目标依然重要。
唯一条件是保持透明，并以对Scrum团队共同使命作出贡献为目标。
这并不意味着每项决策与行动，都必须加快团队产出并创造重大成功。
凭借开放与勇气，Scrum软件开发团队不怕犯错。 他们把错误和不够理想的结果，看成切实提高整体生产力与工作质量的重要机会。
Scrum框架的主要组成部分
Scrum Team由一位Product Owner、一位Scrum Master及Developers组成，具有三项不同职责。本文前面的“Scrum Team Member”指开发群体，并非第四项职责，也不是另一个完整Scrum Team。
除了为全球学生提供的其他课程， International Scrum Institute™ 还为这三项职责提供三大主要培训与认证。
这些课程是 Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™)，以及 Scrum Team Member Accredited Certification™ (STMAC™).
完善的Scrum组织应配备充分具备这三类技能的人才，这对成功运用Scrum软件开发框架尤为重要。
每项Scrum职责都必须履行，责任仍各自独立。Product Owner或Scrum Master在执行Sprint Backlog工作时，也可作为Developer参与，同时保留其另一职责的责任。
多个Scrum Team共同开发一个产品时，共享一位Product Owner、一个Product Goal与一个Product Backlog。每个团队都具有Scrum Master职责并需要有效支持；Scrum并未规定一人只能支持一个团队。
请不要低估理解这些角色的目的、职能，并安排适当人才的重要性。我们多次发现，团队困难的根源是未理解这些角色，或未安排合适人员。
现在来谈谈这三个角色。
Scrum三种角色：Scrum Product Owner角色
Scrum Product Owner 通过排序Product Backlog最大化产品价值，并与利益相关者合作作出产品和发布决策。Developers选择预测可在Sprint中完成的工作，发布安排则取决于产品情境。她代表最终用户的功能与非功能需求。
比传统项目经理、项目群经理或产品管理职责广泛得多。
该角色整合产品与项目管理任务，并与软件开发和交付紧密结合。
Scrum Product Owner的重要任务包括：
- 管理澄清需求，
- 引导发布并确保投资回报（ROI），
- 与Scrum团队紧密合作，
- 管理利益相关者。
Scrum三种角色：Scrum团队成员角色
Scrum团队 实现软件。Developers选择预计能在以下周期内完成的工作量： Sprint。Sprint是固定时长的事件；期间创造的可用产品成果，是符合完成定义的Increment。
高绩效Scrum团队通常具备大多数软件工程技能。开发人员、架构师、测试人员、数据库管理员及其他角色成员共同工作。
他们共同构建并交付客户付费购买的优秀软件。
Scrum团队成员不再属于矩阵组织的职能孤岛。开发人员不再属于软件开发能力中心，测试人员不再属于软件测试能力中心，其他角色亦然。
无论原先在组织中处于何处，Scrum团队成员都归属于当前Scrum项目。现在，他们的工作是构建尽可能好的软件，满足Scrum Product Owner的需求。
Scrum团队的特点包括：
- 获得授权，
- 自主，
- 跨职能，
- 自组织，
- 小型，
- 成员有充分时间参与（全职参与是常见组织选择），
- 无论集中办公还是分布式办公，都能密切协作，
- 我为人人，人人为我。
Scrum三种角色：Scrum Master角色
Scrum Master 服务于项目所有参与者和外部利益相关者，帮助其正确理解并应用Scrum框架。她支持团队成功执行Scrum流程，并持续提高生产力与表现。
Scrum Master的角色是建立Scrum流程，以及新的思考与行动方式。
此外，Scrum Master是变革推动者，辅导团队制定新的规范与标准。她应让团队随时能够联系；物理距离近可能有帮助，但并非Scrum要求。
Scrum Master的重要职责包括：
- 在业务与IT生态系统中建立Scrum，
- 辅导团队理解并践行Scrum价值观，
- 确保Scrum Product Owner与团队紧密协作，
- 移除障碍，
- 通过服务来领导，
- 支持有效的Scrum事件，必要时提供引导，同时保留Developers对Daily Scrum的自主权。
产品待办列表（Scrum Backlog）
产品待办列表（Scrum 待办列表） 是管理Scrum项目全部已知需求的核心要素。
它包括成功执行并完成项目所需的所有客户需求与工作项。需求涵盖功能、非功能需求，以及与以下内容相关的其他特性： 用户体验 和 用户界面 设计。
Product Backlog包含功能请求及其高层级 用户故事。其中也可包括前置或配套项目需求，例如搭建测试与开发环境。此外，用于解决已知缺陷、减少技术债务或改进特定功能的其他用户故事，也应纳入Product Backlog。
每个产品都有自己的Product Backlog。Scrum Product Owner负责创建、维护和微调它。 Product Backlog不会、也不应回答这些需求将如何开发与交付。
这是Scrum团队的职责。团队决定满足需求所需的任务，并将其记录在Sprint Backlog中。 请注意，Product Backlog和Sprint Backlog是不同工件，不一定是物理上独立的文档或工具，虽然前者的条目决定后者的内容。
Product Backlog是一份动态文档。 正如软件逐步改进，Product Backlog也随着团队学习而变化，包括添加、删除和重新排序。 Scrum框架本身不要求独立的变更管理流程。Scrum Product Owner根据对产品最初的最佳理解，创建Product Backlog初始版本。
随着她密切观察产品在各Sprint间的发展，并加深对客户需求的理解，她会添加、删除并微调Product Backlog中的需求。
Scrum Product Owner为Product Backlog中的需求排序。 Product Backlog条目优先级越高，细节就应越充分，使团队易于理解高优先级需求，并创建实现它们所需的任务。
此外，采用以下估算方式： 故事点，Scrum团队定期估算Product Backlog需求。高优先级用户故事的估算应进一步调整和完善，为Sprint Planning做好准备。
Sprint
在Scrum框架中，所有实现需求的活动都在Sprint期间进行。 Sprint 是用于开发可交付软件产品或服务增量的工作周期。 Sprint有时也称为迭代。
可以把Sprint想象为微型项目。正如“Sprint”一词所暗示的，它不会持续很久，时长为一个月或更短。四周Sprint是常见例子，并非框架规定的精确最长日历时长。
与跑步比赛不同，Sprint结束时团队不应气喘吁吁、精疲力竭，而应保持充沛状态，精力充足地开始下一个Sprint。
Scrum软件开发与交付框架并非为了给成员制造压力。众所周知，人们在专注、放松且不受干扰时表现最佳。正确运用Sprint，正能帮助我们做到这一点。
每个Sprint都从以下事件开始： Sprint 规划会。在Sprint Planning会议中，Scrum团队决定本Sprint实现哪些需求、实现多少，随后开始执行交付需求所需的活动。
Daily Scrum（每日Scrum会议） 在Sprint的每个工作日，于同一时间、同一地点进行。 Developers借此检视实现Sprint Goal的进展，并调整次日计划。 团队成员也可以请Scrum Master帮助移除可能减慢或阻碍Sprint进展的障碍。
Scrum团队以Sprint Review和Sprint Retrospective会议结束Sprint。 Sprint Review会议 让Scrum Team与关键利益相关者检视Sprint成果及实现Product Goal的进展，并讨论未来调整。这是工作会议，而非Product Owner签字批准的关卡。
在 Sprint Retrospective会议, Scrum团队反思协作方式、如何运用Scrum框架，以及如何改进。
这样，团队就能在下次Sprint Planning中共同考虑这些改进机会与反馈。 Sprint 用较短周期和小批量工作实现这样的反馈循环。 这正是 Scrum 帮助团队和组织持续自我改善的重要原因及方式。
Scrum检视与适应
Scrum检视与适应易于理解，却极难正确实施并掌握。
企业最终确认，没有哪位项目经理能完全预见复杂系统的全貌，也无法进行可靠的端到端规划。显然，他们需要尝试不同的方法。
结合 精益制造 （也称为 精益运动），企业需要发展一种在战略层面赋能自身的流程。 他们需要标准操作程序，帮助自己在执行项目甚至日常运营时，学习并纠正行动方向。
由此诞生了 丰田改善套路，可与Scrum的检视和适应作有益比较。这些改进方法目的相关，但丰田改善套路并不只是Scrum经验主义支柱的另一名称。按照“Scrum检视与适应”：
- 步骤1：检视： 我们依据当前知识和理解，尽力掌握项目现状。
- 步骤2：适应： 我们明确项目下一步的方向与愿景，再制定策略并执行。
- 步骤3：学习： 过程中，我们仔细观察、学习并互相传授知识，持续记录工作中什么有效、什么无效。
- 步骤4：重新开始： 再次从步骤1开始。
请注意，下面四步是教学类比，并非与Scrum事件一一对应的定义。检视、适应和学习贯穿整个Sprint。
- 步骤1：检视 类比于Sprint Review与Sprint Retrospective会议。
- 步骤2：适应 类比于Sprint Planning会议。
- 步骤3：学习 类比于Daily Scrum会议。
- 步骤4：重新开始 类比于结束一个Sprint并开始新的Sprint。
自组织
Scrum团队自我组织，成员通过共识决定实现Sprint目标所需任务。自组织团队无需经理或团队负责人。
Scrum框架中的自组织具有严格纪律。
Sprint Backlog 和 Daily Scrum会议 支持自我管理。一个 Sprint燃尽图 是将进展可视化的一种可选方式。
多数团队需要经过学习阶段才能自行组织工作。具备Scrum Master认证的合格Scrum Master，会帮助团队迅速提升自组织能力。
自组织还包括在意见不同、成员可能发生冲突时仍能协作的能力，也要求遵守并信任共同决策流程。
Scrum框架的这些决策流程包括但不限于：规划、估算、实现、汇报和评审团队共同负责的工作。
Scrum事件与持续Backlog细化
Scrum事件1：Sprint Planning（为何、做什么、如何做）
在 Sprint 规划会，Scrum团队制定可行的Sprint Backlog，确定Sprint期间将实现的需求。
Scrum各角色在Sprint Planning会议中的任务如下：
- Product Owner提出本Sprint为何有价值。整个Scrum Team协作制定Sprint Goal，Developers选择预测能够完成的Product Backlog条目。
- Scrum Team识别所需任务及其估算。Developers依据过往表现、容量与完成定义，决定预测能在Sprint中完成哪些条目、完成多少。
- Scrum Master主持会议，确保Scrum Team的自组织与自主决策能力不受损害。
Scrum Product Owner必须参加Sprint Planning会议。 这样，她就能回答团队问题，澄清需求及其验收标准。
Scrum Team可以邀请最终用户或经理等其他人员参加Sprint Planning，提供建议。 受邀参与者提供建议，但不接管Developers对工作开展方式的决定权。
Scrum事件2：Daily Scrum会议（每日站会）
这个 每日 Scrum 会议最长15分钟，每个工作日在同一时间、同一地点举行。最好能够直接访问Sprint Backlog与Sprint燃尽图。 这样团队就能根据人人可见的事实和进展开展每日 Scrum。
每日 Scrum 旨在支持自组织，并系统地识别障碍。
Daily Scrum面向Developers。执行Sprint Backlog条目的Product Owner或Scrum Master，以Developer身份参与。其他参与安排必须维护Developers的专注和自我管理；Scrum不要求所有角色或利益相关者出席。
Developers选择有用的结构，聚焦Sprint Goal与可执行计划。以下三个问题是常见可选形式，并非现行Scrum规定的问题。
- Daily Scrum会议：问题#1。 自上次每日 Scrum 以来，我做了哪些活动？
- Daily Scrum会议：问题#2。 下次每日 Scrum 前，我计划做什么？行动计划是什么？
- Daily Scrum会议：问题#3。 我是否遇到或预见会拖慢、阻碍工作进展的障碍？
开发人员自行开展每日 Scrum。 必要时，Scrum Master帮助Developers理解其目的与成效。事件时长仍为15分钟；三个问题的形式可选。
Daily Scrum会议的目标不包括耗时决策或解决问题。 为协调决策与解决问题，团队可以按需另行开会。这些聚焦决策或问题的会议，通常紧接Daily Scrum之后举行。
Scrum Master将发现的障碍及日期记录在团队可访问的独立日志、挂图或报告中。我认为，在Daily Scrum结束时快速更新未解决障碍的状态，非常有益。
Scrum事件3：Sprint Review会议
这个 Sprint 评审会 在Sprint结束时举行。一至两小时可能适合某些团队；一个月Sprint的正式时长上限为四小时，较短Sprint的事件通常也应更短。根据软件类型与可用基础设施，会议可在会议室、实验室或团队办公室进行。
Sprint Review会议旨在评审Sprint期间构建的可交付产品增量，并提升产品开发流程的透明度。
团队展示工作成果。Scrum Team与利益相关者讨论已完成的工作及环境变化，检视成果并考虑下一步行动；Review并非针对固定承诺任务清单的合规检查。
Sprint Review让Scrum Team与利益相关者检视产品成果，并调整Product Backlog。之后，整个团队协作制定下一个Sprint Goal。因此， Sprint Review会议是“检视与适应”的正式实践。
Sprint Review参会者包括Scrum团队、Scrum Product Owner与Scrum Master。最终用户、客户、业务代表等其他利益相关者可以选择参加。
在Sprint Review中，他们可以就展示的产品增量提供反馈。 通过这种方式，团队有机会直接获得其软件服务对象的利益相关者未经筛选的意见。
Scrum事件4：Sprint Retrospective会议
这个 Sprint Retrospective会议 在Sprint Review之后进行，并结束Sprint。一个月Sprint的最长时长为三小时；较短Sprint通常更短。
Sprint Retrospective会议旨在改进团队成员协作及Scrum流程的运用。
因此，Sprint Retrospective会议有助于提高生产力、成员表现与软件质量。
Sprint Retrospective实际上是一次小型复盘，用于明确改进机会、移除流程障碍。我们在项目中常见的改进机会包括：
- 采用敏捷软件开发实践，例如 极限编程（XP） 或 测试驱动开发（TDD）.
- 确定新的团队规范与原则，或
- 提高产品负责人的可联系程度。
Scrum团队在每个Sprint结束时都开展Sprint Retrospective，没有例外。 只有这样，这些会议才能让团队根据项目特点，系统调整并改进Scrum流程的应用。
相关实践：Product Backlog细化（梳理）
Scrum Backlog细化（梳理）会议 旨在保持Product Backlog及时更新。 这样，产品待办列表就能反映 Scrum 团队对当前项目最充分的知识与理解。
细化可以按需进行，也可安排定期讨论。每周两次、每次30分钟只是实用示例，并非规定频率或上限。Product Owner与Developers协作，Scrum Master及其他参与者按需要加入。
在Scrum Backlog细化会议中，参与者通过以下行动完善Product Backlog：
- 根据新发现的需求添加用户故事。
- 删除产品不再需要的用户故事。
- 微调用户故事估算。
- 更新用户故事优先级。
- 将巨大的用户故事拆成易于消化的小故事，并相应排序。
获得Scrum Master认证的四个简单步骤
获得Scrum Master认证的方式非常简单、快捷，且全程在线。
得益于 International Scrum Institute™，您现在可以比以往更快、更经济地获得Scrum Master认证。
获得以下资格的四个简单步骤： Scrum Master认证，拥有精彩的职业生涯 无需浪费时间和金钱，也无需繁琐手续，步骤如下。
-
步骤#1：在线报名
通过以下页面在线报名Scrum Master认证： Scrum Master Accredited Certification™报名页面。
报名后，International Scrum Institute™立即在线提供考试访问码。
通过以下链接，您可以 报名Scrum Master认证课程.
-
步骤#2：在线学习
使用以下资料，在线准备Scrum Master认证： Scrum学习指南The Scrum Framework™.
The Scrum Framework™完全以实践为导向，帮助您作为有才华的Scrum Master应对工作与职业中的日常挑战。书中充满案例研究和实用示例，展示最成功Scrum Master的日常工作。
通过以下链接，您可以 申请免费获取The Scrum Framework™.
-
步骤#3：在线参加Scrum Master认证考试
仔细阅读、学习并消化Scrum学习指南The Scrum Framework™后，您应该已准备就绪！现在应能充满信心地参加并通过Scrum Master认证考试。
通过以下链接，您可以 进入Scrum Master认证考试.
-
步骤#4：获取Scrum Master认证
通过考试后，我们立即提供您的Scrum Master认证。
雇主与客户可使用面向雇主的Scrum认证验证工具，核验认证真伪。通过以下链接，您可以 访问面向雇主的Scrum认证验证工具.
我对Scrum Master认证的结论
现在回顾一下。如果您没机会逐字读完这份成为Scrum Master的分步指南，让我梳理想法。以下是我对获得Scrum Master认证的利弊看法。
优势
员工、自由职业者、教练与培训师的收益
- Scrum Master认证认可您在Scrum领域的能力与最新知识。
- Scrum Master认证帮助您超越不再自我提升的同侪，并作为经过认证、成就出众的Scrum Master获得理想工作。
- Scrum Master认证拓展视野，让您以更开放的心态持续学习，并帮助您承担更多责任、获得精彩职业机会。
- Scrum Master认证提供全新工具集，让您交付客户与雇主喜爱的优秀产品和服务。
组织与雇主的收益
- Scrum Master认证通过提升团队、活动与流程效率降低成本。
- Scrum Master认证帮助您借助受过培训、技能娴熟的员工，赢得原本无法获得的项目。
- Scrum Master认证鼓励员工接受培训、发展技能，提升其满意度与投入程度。
- Scrum Master认证提高交付质量、客户满意度，最终提升组织的成功与盈利能力。
局限
-
Scrum Master认证不应让学习止步。请记住，取得认证只是第一步。
秉持从Scrum框架学到的“检视与适应”精神，持续实验、观察与学习仍是您的职责与义务。
-
没有适合全球所有组织的通用方案，Scrum软件开发与交付框架也不例外。
我们观察到，多数无法充分发挥Scrum框架绩效的组织都有一个共同特点：未能让Scrum适应自身的业务与IT生态系统。
因此，再次秉持“检视与适应”精神，不要把Scrum框架视为100%保证成功的配方。请不要低估自己将其调整以适应业务与IT动态的认知能力。事实上，作为获得报酬的专业人士，您就应这样做，才能通过Scrum获得最佳吞吐量与业务成果。
-
Scrum 没解决 IT 部门全部问题。请继续用 DevOps等新兴软件开发与交付流程。
如需进一步了解Scrum框架的已知不足及DevOps如何处理，请稍后阅读这篇精选文章： DevOps与Scrum的6大主要区别是什么？
总的来说，Scrum Master认证是开始实践敏捷软件开发与交付的绝佳途径。
根据 Gartner 的研究 《Becoming a Better Scrum Master》 文章发表于2019年，其中对2023年的预测是 全球92%的企业以及美国96%的企业将采用敏捷Scrum实践。这是原文报告的预测，并非测得的当前采用率。
因此，现在就是最佳时机：
唯一剩下的问题是：你什么时候开始？