《敏捷整洁之道》读后感100字

《敏捷整洁之道》是一本由[美] 罗伯特·C.马丁著作，人民邮电出版社出版的216图书，本书定价：平装，页数：2020-7，特精心收集的读后感，希望对大家能有帮助。

《敏捷整洁之道》读后感(一)：故事

用户故事是软件功能的简单描述，遵循INVEST原则:

independent、

negotiable不描述细节、

valuable必须对业务具有明确且可量化的价值，重构及架构设计不可能是故事、

estimable、

small一个迭代能完成、

testable足够具体，并可测试说明。

速率是度量而不是目标，不要给度量对象施加压力。

唯一失败的迭代是无法生成数据的迭代。

《敏捷整洁之道》读后感(二)：读书笔记

“个体和互动高于流程和工具，可工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划”，敏捷的时代从四个短句开始，但是随着敏捷的流行，各种误解和“蹭热度”的产品也模糊了敏捷的根本思想，书名的clean正透露了作者想要追本溯源的想法——找到干净、整洁和最根本的敏捷思想和实践。

敏捷开发与反馈密不可分，敏捷开发以燃尽图等图表的形式为管理者提供了所需的数据，推动项目达到最佳效果。反馈是相对于乐观主义的一个准则，它可以呈现开发过程中遇到的问题，而且可以在多种时间级别中进行反馈。并且反馈越多，沟通就越容易，所谓“实践出真知”，反馈是一种通过实际状况来沟通的方式。

作者罗列了瀑布模型中分析、设计和实施三个阶段的典型活动，并且用“死亡行军”来形容最后的加班、赶工阶段，以此来代表一个失败的瀑布项目。然而敏捷不同，敏捷以迭代、sprint作为关键词，通过切分为子系统和一个迭代的实际数据来代替估算和预计，从而获得更加真实和准确的数据，打破乐观的幻想，帮助开发者更好地判断何时能够完成项目。

第二章提到：“要把敏捷做对，你需要结对编程、测试先行、重构并致力于简单设计”，这些实践都是为了避免交付糟糕的代码。通过这些敏捷的实践，每次迭代的结果都是技术上可部署、可发布的，团队的开发效率是相对稳定的，项目的结果是可预期的，变化是可以被轻松应对的，从而用户、客户、管理者和开发者对整个项目的期望可以被满足。

业务层面的敏捷实践包括计划游戏、小步发布、验收测试和完整团队。其中，用户故事是一个重要的概念，通过用户故事我们可以获得从用户角度出发的对系统功能的简短描述。用户故事结合卡片工具和迭代的方式，使得估算（故事点）可以更加精确，任务的完成次序更加明确。Git的存在使持续集成、持续部署和小步发布更加轻松，持续集成最大的优点就是避免了“集成地狱”，如果不进行频繁的集成，那么一次大规模的集成绝对会暴露一堆理不清剪还乱的bug。相反，持续集成可以轻松地定位到可能的问题的范围——那一定是最后集成进来的模块引入的问题。

团队层面的敏捷实践注重合作、交流和人以及团队的可持续发展，隐喻和词汇表都是为了让团队成员更好地沟通交流，而长时间的加班和持续的冲刺则是不利于可持续性发展的两个实践。

在技术实践的章节中提到了测试驱动开发，测试驱动开发倡导先写测试程序，然后编码实现其功能而得名。测试、实现、重构、测试等步骤是TDD的主要活动，开发者通过编写单元测试而获得对程序运行的信心，而这种信心又可以成为程序的一部分。同时，通过测试驱动开发，我们可以有效地避免过度设计带来的浪费，也可以在开发过程中拥有更全面的视角。但是，通过测试用例的编码不一定是真正实现了实际需求的，因此，重构就十分必要，结对编程也可以在一定程度上避免这个问题，让我们在关注测试用例的同时注重实际需求的实现。而测试驱动开发需要我们有勇气去放弃原有的代码，有勇气去大刀阔斧地修改原有的设计和实现，从而进行代码的重构，使得代码可以保持整洁有序的状态。

最后，作者指出了现在的组织在向敏捷转型、应用敏捷时遇到的问题，正如一开始提到的那样，敏捷逐渐模糊了最初的目标。软件匠艺就是在这种情况下被提出的，它作为敏捷的补充，关注软件开发的水准，希望可以稳步增加软件的价值，通过形成专业人员的社区和建立卓有成效的伙伴关系增加沟通和交流。

《敏捷整洁之道》读后感(三)：程序员的“出路”何在？

我感觉在这本书中，Bob大叔颇有点敏捷反对“敏捷”的意味：第一个敏捷是Bob等人发明出来的真敏捷，第二个带引号的“敏捷”，是如今盛行的伪敏捷。

我的观点在这本书的副标题“回归本源”四个字中也得到了印证。当我第一遍阅读时，更多的是一种寻求知音的慰藉，觉得 Bob 大叔不愧是大师，能说出我心里想说但表达不好的话。而第二遍阅读时，我的心态已经平和了许多，读得更仔细更慢，于是便透过书中的文字，看到了真正的敏捷，以及能够真正实践敏捷的“梦之队”！甚至可以说，还看到了所谓的程序员的“出路”。

书中有很多乍一听惊世骇俗的观点，但细细品味后会发现敏捷本该如此。敏捷是多么简单呀，只需要遵守为数不多的几条纪律就可以了。那为什么如此多的团队却做不好呢？我经历了好几个团队，都是随着迭代数的增加，流程越来越繁杂，DoD列得越来越长，甚至要到十几条，但是无论效率还是质量都没有得到提高。Bob 大叔在书中指出，DoD 应且仅应有一条：通过验收测试。多么简洁明了！在他写出来后，读者肯定会说，这不是很显然的吗？然而在实际中，不少团队会列出长长的 Checklist，诸如：代码已提交、Code Review 已通过、代码格式符合标准、DevOps 相应的操作已执行、操作手册已更新，等等等等，然而就是不提验收测试。这是所有敏捷转型失败的通病，也是被砍掉的敏捷核心。

到底什么是敏捷的本源？

敏捷的本意被扭曲，最明显的就是大家普遍认为敏捷就是快、糙、猛。

Bob 大叔在书中反复强调，敏捷从来无关于快。敏捷被发明出来是用来戳破幻想的，幻想是项目管理的大敌。由于心存幻想，在项目刚开始的时候，大家会有一个蜜月期，一直是好消息。而直到临近上线，坏消息才传来，但这时神仙也回天乏术了。而敏捷可以抢在幻想杀死项目之前击毁幻想。

你可能觉得，这不也是显然易见的吗？如果质量越差反而可以更快的话，那追求高质量还有什么意义？事实上，我们只能在日期和范围中做取舍，而不能取舍质量。日期越确定，能做完的范围就越不确定；而范围越不容商量，那么能做完的日期就越不确定。这就是软件开发中的“测不准原理”。

但在实践中，由于上线日期不能改，项目范围业务也不妥协，那么很遗憾，质量就成了那个妥协点。这么做的后果就是项目很快进行不下去，这时就会有人提出“从头重写”的馊主意冒出来。如果真的从头重写，一个焦油坑就变成了两个焦油坑了……

其实啊，越老的项目，应该是越容易维护的才对。敏捷从来无关于快，但是《人月神话》里也指出了，没有银弹。敏捷不是银弹，也不存在其他银弹能做到比敏捷更快。

业务部的经理们以及“敏捷大师”们，用来压榨程序员最好的工具就是所谓的“承诺精神”。然而当我通读《敏捷整洁之道》，没有看到一处提到所谓的承诺精神，相反，Bob大叔在各个地方反复申明：这不是承诺，那也不是承诺！比如估点不是承诺，并且程序员们有权在出现变化的情况下修改自己的估点；速率也不是承诺，并且就算速率下降了，也不意味着团队失败了，而是好的技术实践被破坏的信号。此时，无论是经理还是敏捷大师，都不应该给团队施加压力，要求加油加班，在下一个迭代赶上。如果通过施加压力，下一迭代的速率确实得到了提升，这也只能说明是故事点出现了“通货膨胀”！要判断是否出现了故事点通货膨胀，可以找一个黄金故事卡，比如登录。如果登录的故事点是3，而某个迭代中一个方案修改的故事卡的故事点是10，那你可以很容易地感知到这个迭代中的故事点出现了通货膨胀。

故事点估算从来不是承诺，但它却是敏捷的重要部分。像敏捷中的其他部分一样，故事点会提供数据。敏捷的主要目标之一是戳破幻想，而数据正是戳破幻想的大头针。

《敏捷整洁之道》一书中有很多关键字，其中一个就是小。敏捷由几个小纪律组成，用来帮助小的软件团队管理一系列的小项目。尽管它强调小，但是影响巨大，毕竟大项目也是由众多小项目组成的。敏捷通过将一个项目拆解成一个接一个的小迭代，而每个迭代都会产生数据，通过数据而非幻想来管理项目的计划。软件项目更像是一场马拉松，而不是百米冲刺。迭代的意义仅仅是提供数据，而加班加点无异于数据造假，不可持续。每个迭代产生的数据都是用来持续评估项目的计划安排的，虽然迭代也产生可以工作的代码，但就算没有产出可工作的代码，也不算失败，因为其产生的数据仍有价值。

敏捷失败了吗？是的，但又不是。应该说，伪敏捷失败了，而且从来没有成功过。但是，我们不得不承认，最初由程序员们创建的真敏捷社区，很快涌进了越来越多的伪敏捷拥趸，已经变味了。这之后，“敏捷”不再是程序员们的出路了，反而成为了程序员们的枷锁。很重要的原因是，盛行的“伪敏捷”几乎从来不提技术实践，只有工具和流程。但是，在《敏捷整洁之道》中Bob大叔认为，技术实践才是敏捷成功的最重要的因素，比如测试驱动开发、重构、结对编程、浮现式设计，等等。

如何快速区分真敏捷和伪敏捷呢？根据我读《敏捷整洁之道》的体会并结合自己多年的观察，私以为，凡是没有实践测试驱动开发（TDD）的软件开发团队还宣称自己是敏捷团队的，那都是耍流氓！相反，采用了测试驱动开发的个人和团队，却是可以适应非敏捷的管理文化的。

关于测试驱动开发，Bob 大叔做了一个精彩的类比：会计行业中的复式记账法。自己记点流水账是可以的，但是在企业级必须采用复式记账法。同样，自己写点玩具程序是可以比较随意的，但是进行严肃的企业级软件开发，怎么能不使用测试驱动开发呢？Bob 大叔甚至做了一个预测，随着软件无处不在、无孔不入，软件对人们的经济活动甚至生命安全产生越来越重要的影响，立法要求企业级软件开发必须采用测试驱动开发的日子不远了！因此，我也希望技术实践还停留在石器时代或者青铜时代的伪敏捷，也尽快消亡吧。但也不能太乐观，与其期待公司的敏捷转型成功，更要做好在伪敏捷的幌子下，从个人层面实践敏捷的精髓。

《敏捷整洁之道》看似在为程序员们开脱，实际上并不是。书中开篇就说了，我们程序员统治着世界，并且我们做得相当糟糕。因此，敏捷不是对程序员没有要求，相反，有很高的要求。前面也提到了，技术实践才是敏捷最重要的部分。只是这种要求不是承诺在固定日期前交付固定范围的用户故事这种幻想，而是程序员们应该不断提高自己的职业素养和专业水平。就算公司不给这种条件，也应该自己花钱和花时间向更高的水准精进。

为了提高软件开发的水准以及回到敏捷的初心，Bob 大叔和其他程序员们一直致力于软件开发领域的理论研究。因此，除了《敏捷整洁之道》，还有Bob大叔的《代码整洁之道》《代码整洁之道：程序员的职业素养》，等等众多的经典名著，都值得寻找“出路”的程序员们读一读。