如果你知道Bob大叔，如果你对他的整洁之道有所耳闻，你一定能想象这场直播具有的非凡意义。从2001年敏捷宣言的诞生，到2009年《代码整洁之道》的面世，再到之后的《代码整洁之道：程序员的职业素养》、《整洁结构之道》，今年，刚好整整20年，Bob大叔创作的《敏捷整洁之道：回归本源》构成了“整洁三部曲”，其背后的思想和历程值得每一位希望写出整洁代码的程序员挖掘。
鲍勃大叔《Clean Agile》翻译版《敏捷整洁之道》
您还没有拥有吗？扫描上方二维码
只需一张毛爷爷即可获得由敏捷大咖「申健」「熊节」
亲笔签名的『限量版』图书
另外，还有一点难得的是，这场直播请到的嘉宾正是“整洁三部曲”的译者，时隔十年，齐聚一起，为你解码“Bob大叔”关于整洁代码的核心理念和价值。
观点提要：申健老师以“Bob大叔对敏捷清理门户”这样极具话题性的主题，展开讲解了人们对敏捷的误解，批判了大型伪敏捷，最后给出了敏捷在企业落地的建议。
（这篇回放稿总共接近4万字，在这里小编尽量保证不曲解大咖们的原意，将其主要观点和精华浓缩出来，呈现给大家，希望大家有所收获。）
正本清源：Bob大叔欲对敏捷行业清理门户
分享嘉宾：申健
优普丰敏捷学院首席敏捷教练，自2007年开始敏捷实战。国际Scrum联盟CST认证培训师和CTC认证教练，极限编程实践者。擅长结合教练技术等软技能助力金融、通信、互联网等企业进行敏捷转型咨询和落地。《敏捷整洁之道:正本清源》译者。
主题由来
敏捷这个概念太火了，吸引了方方面面的人进来，传统的咨询行业，一些卖工具的都来了，都打着敏捷的旗号，把这个行业就搞乱了。
所以Uncle Bob在这本书里讲了业务实践、技术实践、团队实践，然后告诉大家我们本来的敏捷是怎么回事，不是你现在卖的那套东西。
对敏捷的误区
对敏捷最大的一个误区——敏捷就是快，用了敏捷以后，原来3个月的项目，我现在一个月就能做出来，那都是不可能的，那都是骗子。
敏捷其实是想要打破原有传统的瀑布式工作方法，以前很多公司的项目开发流程都是先做需求，把需求都搞清楚，再做开发，然后再做测试，然后再做上线。
你会发现这个方式并不适合于软件开发这种智力型的、创造型的行业，早在1970年，这个人叫Winston Royce，他写了一篇文章，批判阶段性Gate based process，说这个方式不适合，结果瀑布模型流传到现在，很多公司，包括我们一些客户的公司仍然还是这样一个开发模式。再加上2000年左右，由于CMMI传入中国，不能说它们没有作用，当时可能是对中国的软件工程行业也起了一些作用，但是逐渐就演化成一种企业资质的一种方式，咨询师跟评估师串通一气，给你刷一个证，最后发现能力完全还是没有提高。
在现实中，人们对敏捷现在还有其它的期望。
第一，我抄。我没有什么创新能力，但是我抄竞品，比比皆是。Uncle Bob说了，敏捷不见得能帮你少花时间，只是能让你该去抄哪，你抄作业得抄对了吧。
第二，少招点人，资源利用率提高点，这也没有错，但敏捷不见得能帮你提高产能，只是能增加一些可管理性，可管理性来自于哪呢？来自于透明性，信息可视化、透明性，然后你才有机会做检视和调整。你如果信息不够透明，你也没有机会检视、调整。
第三，按时上线。按时上线当然也挺重要，但是敏捷不见得能帮你确保时间，它只是摧毁你不切实际的幻想。什么叫不切实际的幻想？就是我到每个时间点，我想要的东西都能上去，不太可能，即使都上去了，通常你也会得到程序员的偷工减料，因为程序员都是高智商人士，他们是非常清楚如何偷工减料，所以你逼他，他就会给你采取那些办法。
第四，营业额。用了之后，我的经营业绩是不是能提升，营业额增加了，客户量也增加了。恐怕不行，敏捷只是能让你更早的知道你哪个产品方向行不通，但是并没有办法让你知道你哪个方向能够行得通。
而且敏捷是一套工作方法，它能够助力你业务功能上线、交付，但是它与营业额、用户量或者钱的增加，并没有直接的关联关系。
最后要讲的一点，不管是极限编程还是Scrum，他们都是一些框架和实践集。但我们很多客户想要落地，要的是敏捷转型或者叫变革管理，这是正交的两回事。在这里先放一句，你要分成两个角度去看，实践集放在那里，但是我们怎么走过去，这是另外一回事。
不管是哪种方法，都是通过一种叫做加速反馈机制来破解复杂性，为什么要敏捷？大家常见的需求经常变更、软件质量差、可维护性差，导致项目失败率。
首先他们讲需求没有不变，因为业务就是在变的，因为市场是在变的，所以不要幻想说我代码能够整整齐齐写干净，然后放在那里供起来，这是不可能的。
第二个就是你的团队、人员、资源能力是一个动态的变化，人员有流动，今天走俩，明天来俩，太正常了。这个敏捷就靠什么呢？就是我们走一步看一步吧，“天下难事必作于易，天下大事必作于细”，你把困难的事拆成简单的，大事拆小，才能够去应对，敏捷里面就能把大的组织拆成小团队，把大的产品需求拆细，拆成用户故事，拆成小任务，把大的时间周期拆成小的、迭代的周期，然后把代码也写的越小越好，都是在破解复杂性，就是反馈机制才是敏捷的根本。
批判大型伪敏捷
市面上有一些方法论，号称叫规模化敏捷，套了一个敏捷的帽子，其实就是原来的瀑布改了名字，仍然是一个传统的矩阵结构，这是一种误区。
还有人说敏捷宣言没区分IT敏捷还是业务敏捷，他就没搞明白，IT敏捷和业务敏捷之间是不是一回事，IT敏捷是干什么的，软件开发敏捷是怎么达到的，是通过屏蔽验证达到的，把代码写清楚，然后通过咱们讲的持续集成、开发迭代，去看跟需求方讲的是不是一样的，是不是人家要的。
业务敏捷是什么？你的诉求是说我的公司能够在市场环境里面增强能力，听起来没错，但是业务方向，战略上其实不一定是通过迭代来进行或者达成的，它可能是通过资源交换来达成，另外它可能是通过广撒网来达成，所谓广撒网就是我孵化好几个业务方向，我看哪个行我就做哪个，像腾讯叫赛马机制。
Martin Fowler当然也是极限编程，和Uncle Bob一样，是极限编程的发起人或者是主要成员之一。他们都在喷SAFe的一个所谓规模化敏捷的东西，包括敏捷宣言其他创始人都对这个东西Say No，说这个东西根本就不是敏捷，套上敏捷的帽子来骗人。
Uncle Bob在《敏捷整洁之道》这本书里讲了一句话，他说敏捷是解决小团队的问题，不是解决大团队的问题，他说大团队、大项目的应对之道，几十年前就已经解决了，怎么解决？咱们讲的矩阵式结构、层级式结构，这就是解决之道。事情分解，已经解决了，但是小团队如何协作的问题没解决，这是提出敏捷的原因。
敏捷在企业的落地
所谓敏捷规模化，在大型产品里面多团队合作、多人合作的时候，解除依赖才是敏捷应对之法。
架构怎么组，不是说我画一个所谓的规模化敏捷图形架构问题就解决了，他一定是靠不断的沟通，跨团队的协调机制，你放一个集中化的架构团队架构师，仍然解决不了这个问题。
剩下还有一些组织的转型、组织障碍的移出、内部社区等等还有自动化测试这事怎么做，都知道自动化测试好，都知道重构好，大型遗留代码，几年甚至十几年留下来的，想补，别说想补重构，补自动化测试，你看都看不懂，人员流动你看都看不懂，你怎么补，所以这也有一个策略的问题。
另外就是绩效考评，这个在企业中是绕不开的，敏捷方法，各个方法都没有提到说应该怎么考评，那我觉得绩效考评根本也不是敏捷要去直接解决的问题，他就是看你公司的导向，你想公司业绩是什么样的或者工作方法像什么，你就考核什么就行了。
另外还有一些配套的事情，包括我们给一些企业做落地转型，发现产品经理能力不行，或者BA需求分析能力不行，就是编程基本功的问题，最后都会落到基本功的问题，你就是不会，你用什么方法论他也做不出来。
程序员的基本功写代码，你知道程序员最头疼的事就是起名字，再加上英语不好，业务领域知识不知道，就只能起到像Run、Process、Handle等等这个水平。Uncle Bob在之前的一本书也提到你要想知道代码质量的好坏，就是数数这个程序员在阅读别人的代码时心里骂了多少次WTF。
怎么练基本功，Uncle Bob提出来极限编程，现在市面上其实也有一些练基本功的培养的方式，包括线上线下的基本功练习，程序员练功房、工具箱练功房等等，Scrum联盟他有一个CST的课程也是在讲这些极限编程手艺，还有一些朋友在做直播，直播就是写代码，直播做重构，直播给你讲集成，这些都是值得大家去参考的一些资源。
另外还有敏捷合同，敏捷合同像Craig Larman等等给出了一些合同的思考和模板，因为你如果像传统像项目管理签的这种合同，时间范围成本都定死了，当不可避免的需求到来的时候，你就没有任何变化的余地，所以敏捷合同签署也是有一定学问的。
最后是教练式的领导力，这个特别有意思，在Clean Agile这本书里面，Uncle Bob除了讲团队实践、基础实践和业务实践之外，特意开了一章讲敏捷教练的事情，我理解他以前这些事情管理的东西其实不是特别在意，但是现在随着敏捷教练行业的兴起，他也提出了一些自己的想法。
我们知道市面上比较流行的敏捷教练的入门学习可能就是美国Scrum联盟CSM培训认证，但是上了这么一个课并不代表你对敏捷有了了解，只是一个入门。再往上就是要真正成为一个敏捷教练要发展自己的软技能，软技能通常指Facilitation会议引导的技巧，还有coaching教练式对话的技巧，包括教练式领导力的技巧才是帮助人们慢慢去转变的一个方式。
总结一下，用Uncle Bob这句话说，敏捷是一种帮助小团队运作小项目的小方法，任何大项目都是由若干小项目组成的。所以以小见大，梦想要大，步子要小，别总扯什么大型敏捷，大型咨询，没有用，先把小团队运作好了，然后慢慢暴露组织中的组织结构问题，互相依赖的问题，去推进整个组织或者更大范围的转变才是正道，上来就想搞一个大型敏捷框架也好，实践也好，往上一套基本上就是输在起跑线上了。
所以我也奉劝行业中的各位敏捷教练，包括我们自己，一起共勉。还是先把小团队的敏捷之道搞好，如果丢了代码年头太多，想法拾起来，如果没有任何代码基础，给别人做敏捷咨询的话，最好先学学潘石屹，了解一下程序员的工作情况才能更好的理解敏捷到底是怎么一回事。