程序员的“出路”何在？
我感觉在这本书中，Bob大叔颇有点敏捷反对“敏捷”的意味：第一个敏捷是Bob等人发明出来的真敏捷，第二个带引号的“敏捷”，是如今盛行的伪敏捷。
我的观点在这本书的副标题“回归本源”四个字中也得到了印证。当我第一遍阅读时，更多的是一种寻求知音的慰藉，觉得 Bob 大叔不愧是大师，能说出我心里想说但表达不好的话。而第二遍阅读时，我的心态已经平和了许多，读得更仔细更慢，于是便透过书中的文字，看到了真正的敏捷，以及能够真正实践敏捷的“梦之队”！甚至可以说，还看到了所谓的程序员的“出路”。
书中有很多乍一听惊世骇俗的观点，但细细品味后会发现敏捷本该如此。敏捷是多么简单呀，只需要遵守为数不多的几条纪律就可以了。那为什么如此多的团队却做不好呢？我经历了好几个团队，都是随着迭代数的增加，流程越来越繁杂，DoD列得越来越长，甚至要到十几条，但是无论效率还是质量都没有得到提高。Bob 大叔在书中指出，DoD 应且仅应有一条：通过验收测试。多么简洁明了！在他写出来后，读者肯定会说，这不是很显然的吗？然而在实际中，不少团队会列出长长的 Checklist，诸如：代码已提交、Code Review 已通过、代码格式符合标准、DevOps 相应的操作已执行、操作手册已更新，等等等等，然而就是不提验收测试。这是所有敏捷转型失败的通病，也是被砍掉的敏捷核心。
到底什么是敏捷的本源？
敏捷的本意被扭曲，最明显的就是大家普遍认为敏捷就是快、糙、猛。
Bob 大叔在书中反复强调，敏捷从来无关于快。敏捷被发明出来是用来戳破幻想的，幻想是项目管理的大敌。由于心存幻想，在项目刚开始的时候，大家会有一个蜜月期，一直是好消息。而直到临近上线，坏消息才传来，但这时神仙也回天乏术了。而敏捷可以抢在幻想杀死项目之前击毁幻想。
你可能觉得，这不也是显然易见的吗？如果质量越差反而可以更快的话，那追求高质量还有什么意义？事实上，我们只能在日期和范围中做取舍，而不能取舍质量。日期越确定，能做完的范围就越不确定；而范围越不容商量，那么能做完的日期就越不确定。这就是软件开发中的“测不准原理”。
但在实践中，由于上线日期不能改，项目范围业务也不妥协，那么很遗憾，质量就成了那个妥协点。这么做的后果就是项目很快进行不下去，这时就会有人提出“从头重写”的馊主意冒出来。如果真的从头重写，一个焦油坑就变成了两个焦油坑了……
其实啊，越老的项目，应该是越容易维护的才对。敏捷从来无关于快，但是《人月神话》里也指出了，没有银弹。敏捷不是银弹，也不存在其他银弹能做到比敏捷更快。
业务部的经理们以及“敏捷大师”们，用来压榨程序员最好的工具就是所谓的“承诺精神”。然而当我通读《敏捷整洁之道》，没有看到一处提到所谓的承诺精神，相反，Bob大叔在各个地方反复申明：这不是承诺，那也不是承诺！比如估点不是承诺，并且程序员们有权在出现变化的情况下修改自己的估点；速率也不是承诺，并且就算速率下降了，也不意味着团队失败了，而是好的技术实践被破坏的信号。此时，无论是经理还是敏捷大师，都不应该给团队施加压力，要求加油加班，在下一个迭代赶上。如果通过施加压力，下一迭代的速率确实得到了提升，这也只能说明是故事点出现了“通货膨胀”！要判断是否出现了故事点通货膨胀，可以找一个黄金故事卡，比如登录。如果登录的故事点是3，而某个迭代中一个方案修改的故事卡的故事点是10，那你可以很容易地感知到这个迭代中的故事点出现了通货膨胀。
故事点估算从来不是承诺，但它却是敏捷的重要部分。像敏捷中的其他部分一样，故事点会提供数据。敏捷的主要目标之一是戳破幻想，而数据正是戳破幻想的大头针。
《敏捷整洁之道》一书中有很多关键字，其中一个就是小。敏捷由几个小纪律组成，用来帮助小的软件团队管理一系列的小项目。尽管它强调小，但是影响巨大，毕竟大项目也是由众多小项目组成的。敏捷通过将一个项目拆解成一个接一个的小迭代，而每个迭代都会产生数据，通过数据而非幻想来管理项目的计划。软件项目更像是一场马拉松，而不是百米冲刺。迭代的意义仅仅是提供数据，而加班加点无异于数据造假，不可持续。每个迭代产生的数据都是用来持续评估项目的计划安排的，虽然迭代也产生可以工作的代码，但就算没有产出可工作的代码，也不算失败，因为其产生的数据仍有价值。
敏捷失败了吗？是的，但又不是。应该说，伪敏捷失败了，而且从来没有成功过。但是，我们不得不承认，最初由程序员们创建的真敏捷社区，很快涌进了越来越多的伪敏捷拥趸，已经变味了。这之后，“敏捷”不再是程序员们的出路了，反而成为了程序员们的枷锁。很重要的原因是，盛行的“伪敏捷”几乎从来不提技术实践，只有工具和流程。但是，在《敏捷整洁之道》中Bob大叔认为，技术实践才是敏捷成功的最重要的因素，比如测试驱动开发、重构、结对编程、浮现式设计，等等。
如何快速区分真敏捷和伪敏捷呢？根据我读《敏捷整洁之道》的体会并结合自己多年的观察，私以为，凡是没有实践测试驱动开发（TDD）的软件开发团队还宣称自己是敏捷团队的，那都是耍流氓！相反，采用了测试驱动开发的个人和团队，却是可以适应非敏捷的管理文化的。
关于测试驱动开发，Bob 大叔做了一个精彩的类比：会计行业中的复式记账法。自己记点流水账是可以的，但是在企业级必须采用复式记账法。同样，自己写点玩具程序是可以比较随意的，但是进行严肃的企业级软件开发，怎么能不使用测试驱动开发呢？Bob 大叔甚至做了一个预测，随着软件无处不在、无孔不入，软件对人们的经济活动甚至生命安全产生越来越重要的影响，立法要求企业级软件开发必须采用测试驱动开发的日子不远了！因此，我也希望技术实践还停留在石器时代或者青铜时代的伪敏捷，也尽快消亡吧。但也不能太乐观，与其期待公司的敏捷转型成功，更要做好在伪敏捷的幌子下，从个人层面实践敏捷的精髓。
《敏捷整洁之道》看似在为程序员们开脱，实际上并不是。书中开篇就说了，我们程序员统治着世界，并且我们做得相当糟糕。因此，敏捷不是对程序员没有要求，相反，有很高的要求。前面也提到了，技术实践才是敏捷最重要的部分。只是这种要求不是承诺在固定日期前交付固定范围的用户故事这种幻想，而是程序员们应该不断提高自己的职业素养和专业水平。就算公司不给这种条件，也应该自己花钱和花时间向更高的水准精进。
为了提高软件开发的水准以及回到敏捷的初心，Bob 大叔和其他程序员们一直致力于软件开发领域的理论研究。因此，除了《敏捷整洁之道》，还有Bob大叔的《代码整洁之道》《代码整洁之道：程序员的职业素养》，等等众多的经典名著，都值得寻找“出路”的程序员们读一读。
