《敏捷开发的艺术》读书总结

现在是2017年上半年，我又一次读完了《敏捷开发的艺术》一书。虽然八年前读过，但是这次读下来感觉完全不一样。因为以前读这本书的时候我还是一个工程师，很多问题感觉不到。而现在是在实际领导研发团队，遇到了实际的问题，而这些问题在这本书上都有所对应，实实在在地触达到了工作中的痛点。

这本书围绕着一个中心--“产生价值”，来讨论软件的开发。软件开发无疑是为了产生价值，只有产生了价值，客户才愿意购买，老板才愿意发高薪。没有价值的软件开发即使按时按质完成也是没有用的。

因此，为了产生价值，一定是满足客户自己知道的需求与那些客户尚且还不知道的需求（用户很多时候自己不知道自己需要什么，直到他们体验过了产品）。因此，敏捷开发提倡提交真正可以使用的软件是根本。就好比买一个家用电器，会有包装并配有说明书，但是用户买的主要是家用电器而不是说明书。产生价值的主体是家用电器，它可以解决用户的问题。可使用的软件就好比是家用电器，而文档等附带物件就好比是包装和说明书。不是说文档等附件不需要，而是它并不是产生价值的主体。以前一些老的软件开发组织把过多的精力花在了文档等附件上，动辄就是写出好几百页甚至上千页的软件需求分析说明书，而不是在产生价值的主体上多花精力，这是一种本末倒置。实际上产生价值的主体就是可以运行的有用的软件。

确定了“产生价值”这个中心目的，接下来就是讨论如何达到这个目的了。

首先，我们要开发出用户需要的软件，满足用户自己知道的和自己还并不知道的需求。这就产生了几条建议：“让真实用户参与”、“迭代演示”、“汇报”、“故事”、“增量式需求”、“客户测试”。但是一味地听从用户的建议也不行，一来用户的想法可能朝令夕改，二来用户群体可能会有不同的声音，甚至是互相矛盾的。如果简单地、不加区分地去满足一切用户的期望，会把产品做成四不像。为了避免跑偏，我们要有“愿景”、“发布计划”、“迭代计划”，系统地、前后一致地、有步骤有计划地开发出成功的产品。

其次，在开发的过程中如何保证进度和质量呢？本书给出了一些很有用的建议。其中的“结对编程”、“信息化的工作场所”、“坐在一起”、“站立会议”、“统一协作语言”提高了沟通的效率。提高了沟通效率就是提高了开发效率。而“全部完成”、“没有Bug”、“版本控制”、“十分钟构建”、“持续集成”、“精力充沛地工作”、“测试驱动开发”这些章节推荐了提升工作效率的方法，避免了无效的加班、返工和缺陷修复所带来的浪费，同时也提升了质量。“松弛”、“重构”、“简单设计”、“增量设计和架构”这些思想和实践提升了产品内部的代码和设计质量，这样降低了后期维护和升级的成本。因为要“重构”，所以提倡“简单设计”；因为要“简单设计”，所以提倡“增量设计和架构”。而在项目管理质量上，通过“计划博弈”、“估算”、“风险管理”提升管理项目的水平，提升利益相关方对团队和项目的“信任”。

最后，整个团队需要能够不断进化，形成优良的文化和价值观，这点也是团队生命力的根本。“根源分析”和“回顾”这两节说明了如何让团队不断进步，而本书的最后章节也若隐若现地表明了作者所推崇的文化和价值观，需要细细体会。

前面所列的每一个用引号括起来的关键词都是一个小节，下面为每个小节花一两句话概括其精要，重点地方会再插入一段补充说明。

“让真实用户参与” - 找到用户的痛点，建立有效沟通渠道。

“迭代演示” - 让团队、用户及其其他利益相关方看到产品在一点一点地创建并完善，整个过程是可见的，不是黑箱作业。这样也提升了信任感。

“汇报” - 对上级或者投资方的一个沟通工具。

“愿景” - 是产品存在的意义，是软件演进前进的方向。

“故事” - 用用户能听懂的话，描述产品的一个个价值点。例如，“作为投资者，我需要看到实时的股票价格”就是一个炒股软件的价值点。

“增量式需求” - 合抱之木，生于毫末；九层之台，起于垒土；千里之行，始于足下。

“客户测试” - 也是一个跟真实用户沟通的方式，让客户试用。

“发布计划”和“迭代计划” - 小步快跑，及时调整，朝向目标（愿景）。

“结对编程” - 提升开发者之间的交流和协作能力，帮助改善设计和编码，提升工作效率。

事实上结对编程虽然是两个人一起编程，表面上看是浪费，实际上效率的提升和错误的避免带来的好处会超过这种所谓“浪费”带来的开销。这是因为：一、结对编程时注意力高度集中，私人事务不会处理，时间利用率高；二、不容易犯错误，一次错误的代价通常要用好几倍的时间来修正和弥补，少犯错误就是提高效率；三、一个人写代码，另外一个人负责导航，不容易偏离方向。

“信息化的工作场所” - 提升工作效率的方式。

“坐在一起” - 减少沟通成本。

“站立会议” - 减少会议时间，及时同步信息。抬头转头就能看到需要的信息。

“统一协作语言” - 减少误解，提升沟通效率，并帮助建立和谐一致的团队文化。

“全部完成” - 定义了什么叫完成，只有真实能够运行才能算作完成。这种对“完成”严格的定义避免了风险。因为程序员通常认为代码写完了就是完成，而实际上“代码写完了”和“软件可以用”还可能有很大的差距。

“没有Bug” - 追求代码写出来就没有Bug的极致目标。

这是一种思想，提倡让程序员写出没有bug的代码，而不是写出有缺陷的代码让测试不断地找bug。因为瑕疵而不断回炉重做的产品通常不如一次就做好的产品质量高。这对程序员个人和团队的要求更高。同时也让软件质量变得更高，因为

而且不产生或者少产生bug对程序员乃至整个团队也是一种正能量激励。想达到“没有Bug”，就要使写代码的时候集中精力，做设计的时候考虑得更全面。因为一个人很难集中精力很久，也很难考虑全面，因此需要“结对编程”。

“版本控制” - 管理代码和文档，现在流行的版本控制工具就是Git、SVN等。

“十分钟构建” - 方便快速的从代码仓库中同步代码，构建系统，部署环境。这是提升开发效率和避免出错的方法。

“持续集成” - “十分钟构建”的配套。

“精力充沛地工作” - 提升个人工作效率，避免“磨洋工”。

与熟知的“996”工作方式不同，这是一种本书所提倡的工作方式，即以提升效率为主、保证全神贯注。要达到这样的状态，一是要养成时间管理习惯，番茄工作法是一个值得推荐的方法；二是工作的时候礼貌回绝别人的打断，并小心避免打断别人，相互之间理解和体谅。三是作息时间也要安排好，如果前一晚熬夜很晚，第二天起很早，那么肯定无法“精力充沛地工作”。另外如何判断一个人工作效率高还是低，需要有一个评估手段。软件开发的工作量是最难评估的，因为无法像生产流水线那样标准化。本书的“估算”（在下面会提到）一节提供了一个工具。

“测试驱动开发” - 第一步，写测试代码；第二步，写正式代码让测试代码运行通过；第三步，重构。

测试驱动开发的方法很早就有人提出来了，但是在实践中很少用到，我的圈内朋友也都没真正实践过。这种方法的效果如何是一个未知数，需要未来有机会尝试。理论上测试驱动开发减少了浪费，减少了调试找bug的时间，但是需要程序员改变习惯，在写正式产品代码之前先写测试代码。

“松弛” - 迭代之间留出空隙做优化、重构和预研。

“重构” - 一种方法、一种理念、一种态度，让代码和设计更加完美。

“简单设计” - “简单设计”并不简单，需要花更多的精力。

“增量设计和架构” - 让设计和架构有弹性，能够适应未来的变化。这需要很高的系统设计能力和经验。

“计划博弈” - 就是权衡，哪些更重要，哪些可以延后，哪些可以舍弃。人生也是这样，舍与得。

“估算” - 敏捷开发中用故事点作为评估任务工作量的单位，而故事点这个神奇的东西是来源于团队经验。估算的过程中一定要开发团队全员参与，让程序员去评估程序员的工作量。

“风险管理” - 用敏捷开发可以有效降低风险，因为是“小步快跑”而不是“大步跑”，有坑可以及时反应。

“信任” - 信任是上述各种行为的结果，也是我们追求的目标。好的结果建立了信任。

插一个本书提到的Murphy定律，我的经历告诉我很正确，“如果可能发生错误，就一定会发生错误”。

我想借用本书的一个思想作为总结：人类一定比机器更容易犯错、更容易疲劳，但是机器比不上人类的是人类拥有创造力、情感和解决复杂问题的能力。因此尽量用机器去处理重复性的事务，例如基本测试和系统部署。让人类去处理相对复杂的创造性的劳动，例如探索性测试、可用性测试和编写程序。而人类的创造力需要有一个出口，那就是创造真正的价值，而软件开发的价值就是给予用户及其相关者一个可运行的有用的软件。