《敏捷整洁之道回归本源》阅读表述

为什么读这本书

会读这本书的原因是在浏览商城的时候被推送到了，正好想了解一些关于职业素养方面的信息。于是先买了3本，之后公司在推广敏捷开发，于是就把这本书优先读了。
首先是总体感受，作者不愧是干了几十年的程序员，遇到的坑真多，故事也多，于是在这一个个故事中，我逐渐了解了敏捷。

宣言发表之前

核心关键词**《敏捷宣言》** ，这是2001年一次聚会开启的一个宣言，背景是全世界都在瀑布式开发流程下着了魔，但是这玩意不靠谱，于是一堆人聚会商讨这方面的内容，最后整出来了一个宣言。（这是我的理解）大致描述一下，这是个宣言，致力于更好的写出符合产品需求代码的精神和指南，没有具体的形式，实践是以XP为代表，但是作者说了，这宣言不绑定任何开发的方法，因为时代在进步，总会有更好的方法的。

罗嗦了那么一堆其实可以忘掉，只要记住敏捷宣言只是知道性的一些话，但是后来的影响非常巨大，作者表示受到了很多响应，就现在来看也是越来越流行了。那么为什么会这样呢？

首先我们先了解没有敏捷开发这个概念前的世界吧，其实敏捷开发大致可以理解为小团体合作解决问题，重点在人员面对问题时的沟通，一开始程序员其实就是这么干活的。后来到了70年代程序员数量大爆发，作者猜大概是老一代和新一代程序员没交接好，然后就一直在探索正确的开发模式。这个时候，有个人说了瀑布开发模型，提出当靶子，然后提出者就在说这个模型不行。但是，瀑布模式对当时人来说过于有号召力，你想，大家都在一堆代码里遇到问题，这时候有人说，我们排好计划，按照日期，最后把代码写完就行了，多简单啊。（我理解过来是这意思）

实践过来，答案是不行。采用书中的故事吧：
老板让大家开了个会，来新项目了，项目6个月预期时间，商量下来，2个月调研，2个月设计，2个月码代码，散会。然后2个月过去了，奇迹发生了，需求调研完了；再过了两个月，奇迹又发生了，设计也设计完了；最后到交付前两个星期，程序员码代码，越码发现离实际的需求越来越远，越是死命码代码，偏离的就越厉害，最后说交付不了了。老板生气，问：“交付前两个星期才和我说这事？”然后延期交付4个月，大家疯狂加班疯狂码代码，可是项目还是没完成，然后项目砸了。
当然，这是个夸张的故事，现实中也有瀑布式开发成功的案例，但是很明显的说明了一个问题，瀑布式开发开发出来的东西会和客户的需求有极大的偏差，因为调研在一开始就完成没法改了，实际上客户需求是在不断变动的。

下图能很好的解释这些现象。

另一个问题，瀑布式开发是把程序写完了才给测试，那每修一个bug，不单单维修成本大，测试成本也大。如果说，告诉有一个庞大的代码，就靠着文档让人去改，其实是很需要勇气的。因为改下来，可能就不知道出什么岔子了。

所以再这样折腾了几十年后，2001年有人说我们有办法能解决上述问题，程序员间有强烈的反馈是很正常的。那么敏捷开发为什么能做到呢？

敏捷做了什么

先说书里面的内容：
四大核心价值：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

还有XP的生命之环，这个可以百度去查，大致讲的就是XP行动原则，此处不全讲。

一个概念铁十字：质量、成本、速度和完成，四者只能选三。
放弃质量，不可能快而脏的；
放弃成本，那永远不可能接收；
该时间表，那很难，因为交付日期有时候是有意义的，错过了就没价值了。
调整完成范围，也只有这样了。
增加人手？其实新人进来需要老人带，效率会短暂下降的。

最后强调，敏捷开发程序的特征：
个体和互动也就是指，大家之间互相代码有个基本的了解，有困难一起过，老手带新手，一个人不能工作项目也不会停止
可工作的软件高于文档，所以每个版本的软件都是可发布的
客户合作也就是指，实时了解客户的需求
响应变化也就是，出现状况能及时调整

在有上述三个概念的基础上，说一下，那么敏捷做到了什么？

作者说：提供了数据，每次会议的时候，把需求分割成小功能点，以故事为单位作为描述，然后以原故事作为标准预估工作量，以故事点作为描述单位。记住预估不用太准，不然成本太高，但是提供的数据可以作为决策依据。然后以每个一到两个星期作为一个周期，总结每个周期完成了多少故事点。
而个体互动的机制会让大家互相了解情况，在每天10分钟左右的站会上，大家只花30秒说三件事。我昨天做了啥，我今天要做啥，我进度被谁卡住了。然后会后有人协调卡住的事项。于是在敏捷开发原则下，XP的开发模式能告诉决策者很多很多很多信息。

还记得铁十字吗？管理层和利益相关者能根据反馈的数据进行决策，而不是等到项目还有两个星期完结了才告诉你项目必须得延期了。这给了决策者和利益相关者操作的空间。其实给开发人员也有操作空间，知道每周的工作进度，确保写出来的代码能在健壮性和简易性里

敏捷开发强调客户合作，这里指的不一定是客户本人，主要是客户的需求，包括产品经理等人。其实，客户和开发团队在一起，有时候开发人员聊天的情况下，客户发现他们理解有误后修正，这样的事情会极大的减少修正方向的成本。其实这一条的意义就是，紧跟需求，不要错的太多。
（瀑布模式的毛病，写了一堆代码，一旦客户目前不需要，写的越多错的越多，修正的越麻烦）

最后就是一点TDD，测试驱动开发。其实是测试程序驱动开发，这一块内容我理解有限，很可能有错误。就是不断测试每一次开发的一小块功能项，确保该项无BUG，减少寻找bug的成本。当每一个小项都有测试用小程序的时候，后面重构和改动代码才有勇气。当然，并不是说这样就不会有bug，但是情况会好很多。不用一有小问题就要花极大的精力巡查整段代码。书中作者说，一个合格的开发，应该是很少用断言定位问题的，因为问题在开发的小型测试模块中已经发现了大多数。（在后续学习代码的时候再试着这样做试试看）

结尾

作者写这本书就想告诉我们，为什么有敏捷开发和什么是敏捷开发的核心。
我的理解：
形式永远为目的服务，所以一切开发形式要根据实际情况选取适用的进行。
小步的发布以及多和客户沟通是为了确保实现的东西是客户想要的。
代码共有和共同开发是为了确保开发进度能一直高效的进行下去

最重要的一点，一个项目是马拉松，所以开发人员一定要休息好,适当加班，方向错了，做的越多，错了越多，而人筋疲力尽的时候是最不愿意思考，最能进行错误行为的时候。