1、英文原作者是jeff.sutherland，中文译者是蒋宗强，网上查了下，他还翻译过跟敏捷没有什么关系《克林顿·重返工作》，然后阅读起来发现很多翻译都和业界的敏捷专用词语不太一致。比如每日立会，Scrum主管，我们一般就是叫每日站会，Scrum Master不翻译任何中文。

2、书的英文名叫《Scrum:the art of doing twice the work in half the time》，也就是Scrum：事半功倍的艺术，为什么翻译成敏捷革命，没什么道理，也可能是为了博眼球。我选择买这本书，本因为他会立意很高，在敏捷的基础上的革命，可惜我理解错了，他只是在传统的开发基础上，引申出敏捷Scrum。
3、本书作为Scrum的入门，不失为一本好书，可以让你从Scrum的创始人的角度学习Scrum框架，包括Scrum、过程、活动、透明性等的由来。

挑选一些细节来说：

第一章节：世界的运作方式已打破

要么改变，要不倒闭

​ 查看Scrum行业报告2017-2018显示，63%的Scrum项目是成功的。又在网上查了下来源于权威机构Standish Group数据，1994年的IT项目成功率大概16%，2003年成功率为34%。数据没有太多的关联性，但是2003年之前很多项目采用的是传统的软件开发方法，如瀑布；后期范围需求经常变化会出现巨大的代价，因而最近10多年多采用敏捷软件开发方法，所以总体上来看成功率在之前基础上有明显的提升。

检查和调整

​ Scrum三个支柱是transparent，inspect，adapt，透明的基础上进行检查和调整，比如回顾主要就是check和调整的过程，在回顾活动，我们就是监视哪些因素是制约把产品列表项做到完成的，基于这些因素做出一些改善的措施，措施在下一个迭代放在Sprint代表代办列表中跟踪执行。

第二章节：Scrum由来

守破离

​ 学习Scrum的框架，每个team使用起来都会有自己创新，比如活动的形式，类似回顾会议，我们不一定要在会议室么，可以找个户外亲近大自然一起回顾。团队之间的频繁紧密合作，我们也可以搞个团队间的每日站会。在学通这一套方式后，我们实施就摆脱这种形式的束缚，因为框架都熟记于心，很多都可以在下意识的情况下做出决定。熟悉的东西，不限于Scrum的框架，敏捷的价值观，精益的思想。

第三章节：聚焦团队，而非个人

团队小而精

​ 船小好调头，一般一个团队建议7+-2人，超过9个人，沟通就困难了。书本中建议的是不小于3个团队成员。总体建议是宜少不宜多。

指责他人是愚蠢之举

​ Scrum Master经常会看到团队成员出现问题，就不经意就说出问题来，说法不好 ，很容易给对方造成你是在挑刺，指责他。问题马上就来了，他会很有意见。也可以说是这个不再是问题是非的事情，而是面子的事情。书上说的是，不要一味的寻找“坏人”，而要寻找“坏制度”，也即那些奖励不良行为，奖励笨拙业绩的制度。

第四章节：以周期性的视角看待时间

时间有限，且行且珍惜

​ Scrum冲刺只有1-4周时间，业界平均是2.6周，交付周期是9个冲刺。在计划阶段，需要把工作分解开，在一个固定的、短暂的时间内能交付多少客户价值。

不展示，就没有效果

​ 每个冲刺结束都需要有成果。冲刺开始的待交付项是否做到完成就需要通过demo来展示。经常会出现在冲刺结束后，没有什么可展示的，没有demo的过程。这个时候往往是没有做到DoD的约定。或者没有DoD约定。

让每个人熟知一切

​ 管理者和非管理者的区别是什么？一般就是消息不对称，在Scrum团队，我们就是要避免消息不对称。

​ 提高沟通饱和度，也就是让团队自己感觉到掌控、控制，非常有助于加快交付。

每日站会

​ 站会一般是持续15分钟，有的站会采用讨论的方式，有的是固定三个问题。形式不重要，重要的是解决站会的目的，就是看看目前的工作进展是否吻合冲刺的目标吻合，存在哪些障碍阻碍我们达到目标。

第五章：浪费是一种犯罪

同时执行多项任务会让你变愚蠢

如果同时执行2项或者更多任务，会让这些任务完成的更慢、更糟糕，也是丰田生产方式中说到的Work in progress,控制在制品数量有着异曲同工之妙。

工作时间越长，效率越低

书本中有个统计数据，瀑布软件开发，一周工作60小时是产出量最大，而Scrum软件开发，一周工作40小时产出量最大。

不要依赖英雄

如果依赖一个英雄去完成工作，那么一定是管理方式出了问题。项目、产品只依赖部分几个人，那么一定会出现，这几个人成了大家的万能钥匙，有问题都会求助于这样的人。专家请假了，项目也会停滞或者大受影响。

第六章：务实规划，拒绝空想

匿名征求意见

尽量不要实名征求意见，以免出现光和效应和从众效应

仅仅规划你需要做的事情

不要试图规划几个月后乃至几年后的事情，只规划团队能够保持忙碌的事情就可以了。按照书本中“不确定性圆锥”图片显示，最初估算的时间可以是实际情况的4倍，也可以能是1/4,这样就相差16倍，可怕吧。

如何知道自己的速度

每个人团队都需要准确知道自己的每个冲刺中完成多少工作，并且应该知道如何以更聪明的办法消除障碍，加快工作速度。

对每个事项进行故事点(难度)估算，结合每个冲刺完成多少个故事点，经过2-3个冲刺后，看看团队的平均故事点是多少，那么这个就是团队的速度。

第七章：把快乐转化为高的绩效

快乐才是王道

快乐时候才会更充分参与，比如一个引导一个会议，参与的人都精神饱满，与会者才更乐意听引导者讲什么，配合你做完成，会议才会更容易产生积极成果。快乐的人可以做出更明智的决策，更容易完成或者取得出人意外的成绩。真是快乐在于过程，而非结果，所以我们应该奖励的是努力奋斗的过程，而非重点奖励结果。快乐

怎么样才能更加快乐

自主感、掌控感和目标感会让人更加快乐。比如一个小公司的老板，公司是他的，什么事情都要管，目标就是赚钱养活公司员工，你觉得他快乐么，我理解相比于没有掌控感、做事完全没有自主性，也没有目标的工作，他肯定愿意选择前者。

保密是毒药

工作最重要的是透明性，团队运作不应该有秘密。

快乐如何量化

有个”快乐指标“概念，在每个冲刺结束，每个团队成员都要回答如下几个问题：

1、你对自己在公司的角色感觉如何？ 请以1-5分加以评价。

2、你对公司整体情况感觉如何？请以1-5分加以评价。

3、为什么有这种感受？

4、在下一个冲刺阶段中，什么事情会让你感到更快乐？

4个问题，团队轮流作答。齐心协力，很快就可以找到改善的地方。

这个就是我们回顾一种方式，通过快乐指标的方式来催进、提高改善。值得一提的是，书本中有个，快乐与速度的图表，显示员工快乐水平下降时候，速度可能最高（比如加班），而后速度就迅速下降。

第八章：找到最有价值的20%

拟定产品代办列表，检查两遍

价值最高、风险最低的事项的排在前面，价值曲线显示，最晚交付日期时候，20%的功能传递80%的价值。20%是指”最简化可行产品“（可称为原型）的基础上，进行增量迭代出的最有价值的功能。

观察--导向--决定--行动

战略上着眼全局，策略上迅速行动。有点DevOPs的味道，同时也有点敏捷transparent-inspect-adapt的原则。

第九章：未来我们的工作

Scrum有助于加快人类所有的活动

Scrum可以 帮助项目提高绩效和取得成功。在教学、扶贫等等方面都有广泛应用。

附录

Scrum的导入，Scrum方法启动一个项目，比较简单介绍。可以参考。