感谢王大爷在《远离敏捷状态的Scrum框架》文末对我的感谢。从这个感谢也能看得出来，原本就是我跟大爷之间在观点上产生了很大的不同，进而引发了辩论。

坦率地讲，大爷你让我失望了，看看你用什么来作为评判敏捷与否的标准，“敏捷是一种不停尝试、不停调整、不停优化的状态”，我不同意。我用于评判是否敏捷的唯一标准就是敏捷宣言。那四条价值，或者可以说成是价值观，以及十二条原则，不仅奠定了从2001年到现在所有冠以“敏捷”名号的活动的基准线，更重要的是，它并非限于软件开发行业，而是对硬件设计/开发、法务、人力资源（虽然对于把人当成资源我很不苟同）、本地化/全球化等很多行业都有很好的指导作用。不拿敏捷宣言，而是拿一位爱尔兰诗人的话作为评判敏捷与否的标准，这个是不是有些说不过去呢！

大爷你还好吧？如果你同意用敏捷宣言来作为评判一个框架/实践是否敏捷的标准，我们逐一地往下看你的文章。我觉得可以批判的地方实在是太多了。为了避免断章取义，我会引用你的一段文字，然后给我出的观点。

很多人会说敏捷就是一种心态（Mindset），老太太 Linda Rising 说有两种心态：

固定心态认为

能力：恒定的，如身高

目标：有面子

挑战：避免

失败：影响身份

努力：没有天赋的人

对挑战的响应：无助的

敏捷心态认为

能力：能成长，如肌肉

目标：去学习

挑战：拥抱

失败：提供信息

努力：成为高手的路径

对挑战的响应：执着、韧劲

抱歉，Growth Mindset不是Rising的原创，而是斯坦福的心理学家Carol Dweck博士经过多年的研究得出的结论，可以参见http://www.mindsetonline.com/

观点：

敏捷是一种不停尝试、不停调整、不停优化的状态。（Being Agile）

如我开篇所说，敏捷宣言所倡导的是四条价值观，十二条原则。

说起来，什么是状态？百度百科对状态的定义是“状态，是指物质系统所处的状况，由一组物理量来表征”，英文中status的定义是“relative social or professional position; the situation at a particular time during a process”。恕我直言，这两种文字的定义都表明，似乎你误用了“状态”这个概念。

敏捷其实更强调“破”和“离”的状态，而不是“守”的状态。尽管“守”的过程是重要的。“守”你可以理解就是Doing，“破”或“离”就是Being。（Being就是上一段所说的内容）

这两种时间分配比例达到 9比80，这也就是说Doing重要，因为如果不是Doing我们不知道如何走向Being。但真正的敏捷是融合在日常工作之中，而不是所谓的几个会议、角色、工件之中。

观点：

一个撇开实践的敏捷理论就是扯淡，必须让人们先做起来（Doing），然后通过练习慢慢提高到（Being）状态。

让我很吃惊的是，大爷你居然误解（还是说劫持）了Doing Agile和Being Agile的含义。如果经常参与国际间的敏捷讨论，我们会知道，关于Doing Agile和Being Agile的关注焦点在于，敏捷是关于流程和工程实践的，还是关于文化和思维的。而且现在广泛的共识是，不要期望通过Doing Agile来达到Being Agile。大爷你一篇文章相当于否定了敏捷社区过去近十年的讨论，着实狠！

此外，根据Bas Vodde的总结，Doing Agile和Being Agile的区别在于：

这可不是关于“参与几个仪式”vs.“从事软件生产活动”的区别。顾名思义地理解Doing Agile和Being Agile，可是会害死人啊！

在《Scrum指南》中第20页的"结束语"部分：

看到了没有，不能改变。整体应用叫Scrum，部分应用叫ScrumBut。那太好了，我喜欢这个爱憎分明的家伙。我后面的文字，部分瞄准的也是它这句话。

Scrum指南的原文，并没有说部分应用Scrum就是不敏捷的，也没有声明不完整地应用Scrum就必然导致失败，只是指出，这样做就不是Scrum了。所以大爷你要想好，你后面攻击的到底是什么。

我对一个“敏捷”框架的期望：

简单（一个高中毕业的人就能够明白）且关注关键点；

100%能落地（能够实施）且能够灵活的应对现实中的不同情况（覆盖广）；

关注实践（Doing）并通过实践自然达到敏捷的状态（Being）；

观点：

Scrum是一个爱憎（对错）分明，多一分不多少一分则少的过程实施框架；（它本身是硬的，不能调整）

100%能落地，这是对确定性的管理，而非对不确定性的管理。大爷你确定这样做敏捷吗？再一次地，敏捷社区经过长达近十年的讨论，已经明确地得出结论，通过Doing Agile达到Being Agile是糟糕的想法。

关于纯真信仰的“自组织”

我曾经问过我所带领的团队成员：“你觉得自由是一件好事吗？” 当时有些人点头有些人摇头。我非常明确的对他们说：自由不一定是个好东西，对于那些无法独立思考的人，自由对他们就是负担。刚才那句话我一般会说两遍，当说完的时候我也看到很多赞同的点头。

中国从来就是精英社会，而不是民粹体系。你可能真诚的说：来看看你想干点什么活？他估计会回答你：领导，您说干哪块咱们就干哪块吧。这种状态根深蒂固，并且估计80%的团队成员是这样的。自组织个毛啊（这句话真心看着不像专业教练说的）。

真正重要的是

让团队中少量的核心分子真正的积极起来，拥抱协作的敏捷文化；

给剩下大部分跟着跑的团队成员成长空间，让他们知道如何提出请求，如何反馈意见，了解成为核心成员的成长路线。

观点：

在中国自组织就是一个神话，现实之道是团结精英推行任何改进；

对于无法独立思考的人，是帮助他们逐渐独立思考起来，还是让他们一直保持不独立思考？徐毅在其一篇文章中说得好，“价值观是没有前提的，秉持某种价值观就意味着你要克服现实世界中的困难去做到，而不是意味着要让你的价值观去吻合现实世界”。后者虽然容易，但没什么价值。

从这个意义上来讲，自组织不是神话，自组织是敏捷教练尽其所能帮助团队达到的目标。你可以有策略，团结精英以推进改进，但是如果你不抱着向自组织方向发展的强烈目的，那么团结精英的结果只能是进一步强化精英的作用，让自组织真的成为神话了。所以说，大爷，我同意你的策略，但反对你的观点。出发点不一样，哪怕策略类似，结果也是大不相同的。

Scrum 框架的反敏捷之处

（1）关注角色而不是要达到的效果

伟大而又神奇的Scrum Master（斯格拉姆·马斯塔）

好消息是：经过2天或3天的培训、考试之后，你会获得Scrum联盟发出的Scrum Master 证书。恭喜你你被联盟认证了！

坏消息是：在我经历过的国内团队之中，我认为靠谱的斯格拉姆·马斯塔人数在20人以下。

也恰恰是因为不靠谱人员数量庞大，对团队造成了很坏的影响。这也使得我在国内导入的敏捷过程完全不引入这一概念。

斯格拉姆·马斯塔的终极目标是消灭自己（形成真正的自组织团队之后），但在《Scrum指南》8-9页之中没有任何文字描述。而这一角色又堂而皇之的成为框架永恒的一部分。

Scrum不是由Scrum联盟设计出来的，Scrum联盟也不是Scrum的全部。所以尽管我赞同大爷的说法，2 - 3天的培训无法批量制造出来靠谱的Scrum Master，但是用这一点来论证Scrum“关注角色而不是要达到的效果”，逻辑上完全站不住。另外，Scrum Guide上明确地列出了Scrum Master的职责及其要达到的效果，怎么能说Scrum只关注角色呢！

至于说不靠谱的Scrum Master数量庞大，就要干掉这个角色……恕我直言，每个合格的敏捷教练都是从不靠谱的状态走过来的，大爷你不能因为现在自己已经靠谱了，就断了其他有志于此的实践者的道路啊！

缥缈的Product Owner（产品负责人）

拜李国彪（Bill Li）所赐 ;P，基本所有Product Owner都被翻译成产品负责人了。但这是负责人吗？这不是产品业主嘛？（关于这点他也经常开玩笑）

在中国的团队之中到底有多少能做得了主的“产品负责人”，增加了无数新的ScrumBut词汇。比如：PPO(Proxy Product Owner), POA(Product Owner Assistant)；

不好意思，你这玩的不是Scrum是ScrumBut。但纠结角色的时候是不是可以看看他/她管的事是否大家都可以分担了呢？

在导入敏捷过程的时候，恰恰有很多个角色或个人能够满足这些要求。那太过于强调这个角色是否又是一个合理的坚持呢？

这段文字不错，是可以讨论的地方。但是Product Owner反敏捷吗？跑题了不是！没有完美的实践，没有绝对的银弹，这没错。但因此就二元论，非此即彼，非完美即反敏捷，这个这个……大爷你可以思考得更好一些的。

（2）关注会议而非会议之前的准备

Scrum有对会议的精细安排，比如建议多长时间，比如结构分成几个部分。但恰恰是这种划分使得使用者的注意力关注到会议本身。会议的时间越来越长，效率越来越低。但只要有特定的会议并且关注Scrum所要求的方向就达标啊。

再一次引用徐毅的文章，“Scrum自身……就是一个框架，我的总结是它主要关注项目、组织（人）、事务的管理，而不是具体细节的操作……”会议之前的准备也要管，那可真是不厌其详的流程了。想一想敏捷宣言的第一条价值吧，大爷，到底是谁在反敏捷！

（3）冗余的概念

（4）框架的缺失

（5）不精确的词汇

（6）框架补充的堆砌（非Scrum框架本身）

这四条我只保留标题。再一次地，这些都是可以讨论的地方，但它们的“不完美”，是能够跟“反敏捷”划等号的吗！文不对题啊大爷！

总结一下

关注角色而不是要达到的效果：反敏捷评级【四颗星】

关注会议而非会议之前的准备：反敏捷评级【五颗星】

冗余的概念：反敏捷评级【三颗星】

框架的缺失：反敏捷评级【一颗星】

不精确的词汇：反敏捷评级【一颗星】

框架补充的堆砌（非Scrum框架本身）：反敏捷评级【一颗星】

回到我对一个敏捷框架的期望，并综合上面所表达的观点进行Scrum满足程度评估：

回到你的总结上，我的结论，在你看来不完美的，就是反敏捷的。大爷你追求的是银弹LoL

下面关于王大爷自己认为“完美”的，或者在王大爷的观念里，“敏捷”的做法，我就不评论了。每个人有自己做事情的方式，只要客户认可、真正地帮助交付了业务价值（更快，更好，更节省……客户总会有自己的标准的），并且是可持续的、可复制的，那就没什么可指摘的，一个经验分享嘛。

总而言之，大爷你的这篇文章让我很失望。你不是用敏捷宣言，而是别的标准来检验Scrum是否敏捷，并且在检验过程当中，也并非一次又一次地回到检验标准上来做讨论，而是用“不完美”替换了“反敏捷”概念，从而在你的论证当中，因为Scrum处处不完美，所以Scrum处处反敏捷。这种观点，着实不完美！