凡事都要问主管、东拉西扯没重点：敏捷破坏者实战手册

2019 年 6 月 25 日 DevOps时代

破坏易，建设难

建立一个敏捷的团队何其困难，但要破坏一个团队的敏捷性却是那么的容易。原因很简单；因为敏捷追求的是效能，而产出物要对客户有真正的价值才有意义。所以无论是破坏开发的效能或是故意产出客户不需要的东西，对运行敏捷都是一种破坏。

这里参照了 William J. Donovan 威廉. 唐纳文将军在二次世界大战时所制作的《简单破坏实战手册》撰写了一篇《敏捷破坏者实战手册》，旨在提供团队成员能够相互提醒并引以为戒，避免同僚之间误犯了破坏敏捷的忌讳。

敏捷性大都来自于团队成员之间的相互学习

你可能上过一天或是数天的敏捷训练课程，或者是经过一晚的熬夜之后便考上了CSM: Certified ScrumMaster 的证照(常常听人们这么说的)，有机会成为敏捷教练也就是所谓的敏捷教练 Scrum Master. 但随后当你面对问题时，迎面而来的怀疑与慌张会持续许久许久，请不要怀忧丧志，因为敏捷开发是一种经验主义，在你习得那些敏捷教练所教导的准则之后，实战才要真正的开始。

所以你的敏捷开发技巧与属性，大都来自与同僚之间互动中所习得，当然参加敏捷社群活动可能是酝酿你的敏捷实力最好的地方。但说穿了，懂得与人相处才是重点。

看书有用吗? 当然有用，但要获得实战经验才是重点，教学相长可能是一个好方法，尤其是获得回馈更是弥足珍贵。

要敏捷；先懂得如何与人相处。
没有比一群 Scrum Master 聚在起加入社群相互学习能更快敏捷化的了.

敏捷破坏者实战手册

第一招凡事都要问主管

也就是一切按照公司规定依据规范来做事，即便是显而易见的行事变通也绝不跨越公司规范。严格说起来你是最遵守组织规定的成员，理应得到奖赏，列为优秀员工并予以表扬，但试着想想看，有多少次你可以见机行事扩大工作成效或是避开错误细节的机会，但你却因为害怕违反公司规范而作罢。

老实说；有时你应该选择违规行事而不是事事请示上级。创始看板的 Toyota 生产线就有一句名言是这样说的：“现场的工头才是真正了解现况的人，因此决策应该是由他来下达才最正确”，所谓盲目遵循规范是最不敏捷的行为，敏捷追求小增量、多迭代的方式，正是避开错误的假设造成巨大错误的法则，追求的是持续修正，因此一切以回馈为重。视回馈为避开错误并持续修正的首要原则。

遵循公司一切的规定，就是所谓的服从者或可称之为「服从破坏者」，为什么称他为破坏者呢? 因为我们做事解决问题时，有时应该试着成为「违规者」，或可称为一种尝试失败的勇气，因为只有试过后才是学到最多东西的时候。

人们是依据自己的价值观行事，团队依据团队的价值观行事，组织依据组织的价值观行事(而这些行事的抉择将形成一种组织的文化)，因此当你面试一位新人要加入团队时，最重要的准则便是该人士的价值观与团队的价值观是否一致，一致的价值观足以形成团队的内聚力，这种内聚力便能形成团队一起工作时效能的后盾(反之；将成为排斥的力量)，这也就是为何 Scrum Master 会一直要求主管要后退一步的原因，让团队习惯获取自治的所有权，形成习惯性的自组织形式，让团队依据团队价值观决定行事的准则，才能引发群体智慧自行解决疑难杂症，你说应该是依据准则做事还是方便行事呢?

主管与团队行为相互影响循环

始作俑者是主管

主管的态度决定他的行为，而团队依据对主管行为的解读来决定团队的行为。所以主管的态度间接影响了团队的抉择，因此表现的公正不阿是任何一位做主管者应该要有的基本态度，而建立与下属之间的诚信度则决定了团队自组织的成效。

了解你的团队 – 常态分布检测法

想知道自己的团队是属于服从破坏者较多，还是违规者较多呢 ?做一个简单的问卷分析便能清楚了。实验是这样的：做一个问卷，问每个人假设他是一位柜台经理，他有权利给予入住房客升等房型的决定权。他可以破例给任何一位旅客升等，也可以不给。

给了以后升等房型就减少了，旅社就少赚一点钱了。不给则可能失去那些上回被升等过的老客户。由他们回答问卷的行为模式，便可以统计出来团队的服从者与违规者的数量。基本统计应该是呈现标准的常态分配曲线，如下图。

敏捷较害怕服从型的破坏者

对于违规者只要多加耳提面命，几次之后就不难修正他善于违规的行为。但因绝对服从而造成的破坏者行为就比较困难了。如果团队表现的让上面的钟形曲线偏右，怎显示这个团队拥有较佳的敏捷性。反之；则团队固执于传统的管理模式。

先知道平衡点在哪里才可能站得稳

这是八条破坏手则的第一条，我认为它是最重要的。这是因为我们以自组织为最优团队的原故，而团队要自主到什么地步呢？他们懂得拿捏分寸吗？决定就在这个平衡点了。团队必须首先拥有认同于企业文化的思维方式之后，才具有塑造自己价值观的能力。因此发掘并创造一个团队的价值观正是自组织的基础，所以拥有决策时能一致的服从性，应该是最重要的一环。

对效能的破坏就是对敏捷的破坏

不管是对是错，人们总是顷向于支持对自己有利的事物上，例如:篮球场上裁判吹有人犯规，通常只要对我方有利，我们都会鼓掌，对我们不利，当然要大嘘特嘘裁判啰！这个时候事实的真相就不在我们的观注范围里了。

我撰写《敏捷破坏者实战手册》的目的是要提醒大家，其实对效能的破坏就是对敏捷的破坏，也就是对精益观念的破坏，我们经常不经意地为之，感觉上无伤大雅，但其实正是对团队实行敏捷化的残害，请大家务必引以为戒。

给客户他不会用到的功能让团队一直多做是上策

需求做多了是人们求好心切的常态，负责撰写需求的人士会担心在一开始就有所遗漏，因此极力的思考各种细节来完备这个功能，反而造成工程师多做了一堆没有意义的工作，但其实客户要的只是一个简单的功能，我们却把它做大了。

这也是造成工程师一直都很忙的最佳途径，让做一个小功能要花上一个大功能的时间，则是累死团队的最好方法。解决方法可以参考《简单的法则》一书里作者推荐的SLIP原则。

经常灌注团队要作出全世界最好的功能程序的概念，

而不是刚刚好、够用就好的程序。

运用迭代的方式来完备功能，避免一开始就求完美

参考

美国情报机构所设计出创新的方法来击败对手，在1944年中情局(CIA)的前身战略服务办公室(OSS)创建，由 William J. Donovan 威廉. 唐纳文将军所创的《简单破坏实战手册》.
声明上面图示均出自《谁在团队搞破坏》一书，作者为罗伯特．M．加尔福特, 鲍伯．福瑞奇，凯瑞．格林，出版社：天下文化。
《简单的法则》by: John Maeda，书中，作者提出十个原则，帮助每个人在「能够多简单？必需多复杂？」两端之间，思索合乎商业（市场）、设计创意与生活美学的平衡点。

2019年7月5日，台湾著名精益布道师李智桦老师将在 DevOps 国际峰会 2019 北京站为您分享《敏捷破坏者实战手册》

李智桦

台湾著名精益布道师

91App 总经理室敏捷教练

GOPS/DOIS 金牌讲师

个人简介：
具有超過35年的工程師經歷，擅長帶領研發團隊開發與創新，著作有:精實開發與看板方法、Windows Azure雲端開發、WF工作流程引擎程式設計、微軟 VSTS 開發實戰等書。為專業的軟體工程顧問、Scrum及看板課程教學的講師。曾擔任四家資訊公司的研發部經理。擅長新創公司的專案開發工作，現任91App 公司的敏捷顧問。

7月5日-6日的 DevOps 国际峰会 2019 北京站，这里有：