本文介绍了ScrumGuide的历史及其两位创始人Ken Schwaber和Jeff Sutherland的背景。详细解析了Scrum作为一个轻量级框架如何帮助人们、团队和组织通过适应性解决方案解决复杂问题。
各位小伙伴大家好，从今天开始，我打算出一套系列文章，名字叫做《跟我读Scrum Guide》。
《Scrum Guide》2020版英文版官方pdf算上封面共14页，文字不多，但其信息量巨大。然而有相当部分敏捷小伙伴没有读过、没有认真读过，或者认真读了但没有真正理解其中的奥义。
我尝试基于我多年的经验和理解，同时参考权威资料，力图用大白话扩充解释《Scrum Guide》中的各个点，从而降低阅读难度，供不同程度的小伙伴学习参考。同时非常欢迎大家能够在评论区批评指正，大家共同研讨和学习，共同进步！
本系列文章数目未知，因为《Scrum Guide》信息量实在太大，无法提前计算，即使计划，也非常有可能在中途增加很多。当本系列文章结束时，我会出一个合集文章，提供全部的链接。
我会从包括封皮在内的第1页开始依次寻找可进行分析评论的点，逐一写作和发表。
在封皮最上方，首先映入眼帘的是两位作者的名字：Ken Schwaber & Jeff Sutherland
因此，本系列就从二位作者的介绍开始。
Ken Schwaber在20世纪90年代初与Jeff Sutherland共同开发了Scrum流程，以帮助那些在复杂的开发项目中挣扎的组织。作为2001年敏捷宣言的签署者之一，他随后成立了敏捷联盟和Scrum联盟。他后来离开了Scrum联盟，成立了Scrum.org。
作为在软件开发行业驰骋30年的老司机，他写了三本关于Scrum的书：Agile Software Development with Scrum, Agile Project Management with Scrum, 和 The Enterprise and Scrum。他住在马萨诸塞州的列克星敦。
Scrum.org提供的认证包括：
Professional Scrum Master（大家熟知的PSM）
Professional Scrum Product Owner
Professional Scrum Developer
Scaled Professional Scrum（规模化敏捷框架Nexus）
Professional Scrum with Kanban
Professional Agile Leadership
Professional Agile Leadership - Evidence-Based Management
Professional Scrum with User Experience
Jeff Sutherland是Scrum的联合创始人，他在Scrum框架为满足当今商业的需求而演变的过程中起到了引领的作用。他在1993年开发并在1995年与Ken Schwaber一起正式确定的Scrum已经被全世界绝大多数的软件开发公司所采用。但Jeff意识到，Scrum的好处并不限于软件和产品开发。他已经将这一成功的策略应用于其他几个行业，包括：金融、医疗、高等教育和电信。
作为Scrum Inc.的CEO和OpenView Venture Partners的高级顾问和敏捷教练，Jeff为Scrum的成功设定了愿景。他继续与全球各地的组织分享最佳实践，并就Scrum规则和方法撰写了大量的文章。凭借对业务流程的深刻理解--多年来在11家不同的软件公司担任CTO/CEO--Jeff能够描述高层级组织级从Scrum获得的收益，以及创建高生产力团队所需的条件。
Scruminc提供的认证包括：
Registered Scrum Master
Registered Product Owner
Registered Scrum@Scale Practitioner
Registered Scrum Master@Scale
Registered Product Owner@Scale
Registered Agile Coach
《Scrum Guide》是Scrum的权威指南，这是全世界唯一精确定义Scrum的地方，这是所有践行Scrum的小伙伴的必读书目！阅读本文的小伙伴，你对《Scrum Guide》的熟悉程度是什么样的呢？
凡是不在《Scrum Guide》中提及的东西就肯定不是Scrum框架本身强制要求的，最典型的就是Scrum：
没有要求一定要使用用户故事
没有规定用什么方式进行估算
没有规定用什么方式进行排序
没有要求每日Scrum会一定要问那三个问题
Scrum只是一个框架，具体怎么干，由团队根据实际情况自己来选择。
在市面上你会看到大量的和Scrum相关的书籍，这些书籍或者进一步解释了Scrum，或者提供了很多可以和Scrum框架结合使用的大量的其他实践，但是千万不要误认为这些实践是Scrum的组成部分，从而限制了使用Scrum的灵活性，反过来怪Scrum不灵活！
现在还等什么，赶快翻开《Scrum Guide》，看看还有哪些东西不是Scrum要求的，你是不是觉得你的选择空间更大了呢？同时，你也一定会意识到，自己号称践行Scrum好多年，然而还有很多东西竟然被你忽略掉了，比如你真的每个迭代都认真设定了“Sprint目标”？
是时候重新审视《Scrum Guide》，是时候重新审视自己的Scrum实践，回归本源！
到目前为止，《Scrum Guide》已经经历过7个版本的变迁：
V1：2010年02月，由Scrum联盟发布
V2：2011年07月，由Ken和Jeff修订
V3：2011年10月，由Ken和Jeff修订
V4：2013年07月，由Ken和Jeff修订
V5：2016年07月，由Ken和Jeff修订
V6：2017年11月，由Ken和Jeff修订
V7：2020年11月，由Ken和Jeff修订
每个版本都有其不同的韵味，都在从不同的侧面和角度，分享着关于Scrum的方方面面以及背后的思考。
虽然随着时间的推移，《Scrum Guide》几经变化，内容几经取舍，但曾经存在于其中的智慧与最后留在最新版中的智慧具有同样的价值。
所以在后续的系列文章中，对于同一个东西，我会讨论它在不同版本中的变迁，从而帮助大家更好理解背后的思路。
方法论是指“一门学科所采用的方法、规则和假设的集合；一个特定的过程或一组过程。” 方法论需要预先知道解决方案是什么，还要知道达成解决方案的步骤是什么。
方法论在复杂和不可预测的领域中是行不通的。在复杂的领域中，团队必须使用经验主义来交付价值或解决问题。他们必须能够自主决定流程和技术，并且能在工作中了解到更多知识之后适当对其进行调整。
流程框架是一套脚手架，旨在具有更广泛的适用性，但需要针对每个环境进行定制，以填补缺失的空白。
Scrum 是一个提供最小边界的流程框架，它可以在限制风险的同时实现自组织。每个人对 Scrum 的实施看起来都有会所不同，因为每个产品和每个团队的需求都不一样。
读完这篇文章，相信你对如下这句话会有比较好的理解：
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
什么是复杂问题呢？看看下面几个：
你能确切知道用户想要的是什么吗？
你能准确判断市场的变化吗？
你的产品真的有人愿意买吗？
我们约定的工作方式真的能够起到预期的效果吗？
我们的工作进度真的能够按计划进行吗？
这些问题的共同点是：在这些问题的背后，不存在一系列输入与一系列输出之间的确定关系。所以我们无法确切知道这些问题的确切答案。你花再多的时间推导也不行，你把这些问题拆得再小也不行！事实上，大部分知识工作都属于复杂问题的范畴。
解决复杂问题，我们能做的只能是摸着石头过河，这样可以稳（风险更小）、准（更接近最终答案）、狠（速度更快<注意：这里说的不是干活的速度更快，而是用更短的时间解决问题/交付价值>）地解决问题，具体的步骤就是：
做出某种假设（假设这样做能解决问题，注意，这个假设可不是拍脑袋随便做的，是基于各种分析，认为是最有可能达成目标的假设）；
做试验（实现所做的假设）；
获取反馈（观察效果，看是否有助于解决问题）；
决定下一步如何调整（这里实际上是基于反馈结果再一次做出的假设）；
重复步骤2-4，并保持整个过程清晰可见，直至问题解决。
Scrum正是通过上述思路来解决复杂问题（“complex problems”）的，解决问题的过程是不断试验、不断调整（“adaptive solutions”）的，最终帮助人、团队和组织这三个层级创造价值（“generate value”），也就是说要以价值为导向探索解决方案，最终为价值服务。
谈到“复杂（Complex）”本身，有很多书如《管理3.0》和《第五项修炼》，以及很多理论如“Cynefin框架”和“Stacey矩阵”都对其从不同的角度做了非常详细的阐述，它们都在为我们提供思维上的指导，让我们知道什么样的问题要用什么样的解决思路，如果用错了，就会带来不可理解的结果，造成不可接受的灾难。（例如：用针对简单问题的解决思路去应对复杂问题，就会带来无尽的各种消耗，不但得不到期望的结果，还会产生巨大的反作用）。
我会在之后以“加餐”的方式对典型的理论进行总结，以最通俗的语言进行分析。(文章来源：徐东伟敏捷教练)
扫一扫
725
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
