《敏捷革命》读后感
在阅读《敏捷革命》之前，我一直不太能够全面的理解敏捷开发。也是通过阅读本书，了解了相关的知识。那么在这里，我会通过对本书的梳理，将我所了解到的知识点写下来。：
本章主要是通过失败的项目表达了对一个项目管理新思维的迫切性，在很长一段时间，人们习惯使用甘特图、瀑布法来管理项目，花大量的时间来制作精美的图片，“猜测”可能发生的问题。
但我们知道计划往往是跟不上变化的，在项目开发中更是如此，没有亘古不变的需求，也没有计划之中的BUG，那么之前的方法更加强调规范性，自上而下逐步实施的瀑布式软件开发方法。但很显然，这种开发流程进度缓慢，具有高度的不可预测性，还容易产出用户不愿意购买的产品，就是闭门造车的产物。
思维
本书提出的新思维就是“Scrum”，作者提到了它的优点——先进灵活，具有自我修复能力。
的确，两周一个迭代的开发工作具有灵活性和自我修复能力，但其实在很长一段时间，我都没感觉到它的先进性，这不是敏捷开发的问题，而是我和我的团队的问题。
因为在很长一段时间，我们只是了解了敏捷开发的皮毛，并没有了解到它的核心，因为现在很少有人能认真的去了解一个方法，并将它表述的通俗易懂。而我，也仅仅将敏捷开发做为“资本家压榨血泪”的产物而没有去神人了解。
那么敏捷开发的先进性体现在哪里呢？我认为本书提到了很重要的一点，就是“这种架构之所以奏效，原因很简单，因为我看到的是人们实际上怎么工作的，而不是他们嘴上宣称自己是如何工作的。”是的，很明显，软件不总会按照我们所期望的方式运行，那么人的工作方式也一样，我们有的时候会不停的询问和检查工作的进度情况，因为我们知道，如果不检查和询问，结果总是会有较大的偏差。
而敏捷开发充分考虑到了可能出现的不确定性因素，同时具有鲜明的创造性。它的结构是围绕着学习过程建立的。这个过程是不断的自我进化和自我训练，是检查与调整的循环。
价值
本章通过“哨兵”项目的新生来讲述价值的意义，因为一个项目80%的价值来自于20%的功能，在评审需求时我们要考虑需求的价值，是否值得我们用大量的时间？或是否值得上一个高优？那么针对需求的划分，我们可以使用四象限法则。
那敏捷的思想的价值时什么呢？在《敏捷软件开发宣言》中提到了：
人胜过流程、可以使用的软件胜过面面俱到的文件、客户合作胜过合同谈判、应对变化胜过遵循计划。
流畅
我自己在生产过程总是被会议等一些琐事打断，一个天能有6个小时安心写代码就谢天谢地了。而这种状态时不健康的，很有可能因为自己耽误业务的进度，一个人如此还好说，钥匙人人如此，敏捷的意义就不复存在了。
那么一个流畅的节奏就是很重要的，开发团队必须明确哪些障碍会拖累进度，整个生产流程之内的各个环节应该做到无缝衔接、迅速流畅地接续下去，管理团队也应该负责去解决这些障碍，任何障碍都是一种浪费。
迭代
我们上面说到了迭代，刚接触敏捷时，听到最多的也就是迭代，那么迭代是什么呢？
指把一个复杂且开发周期很长的开发任务分解为很多短期可完成的任务,这样的一个周期就是一次迭代的过程
TODO
道理我们都懂
阅读之前，阅读之后
为什么高效
因为我看到的是人们实际上怎么工作的，而不是他们嘴上宣称自己是如何工作的
为什么使用敏捷：瀑布法：这种开发流程进度缓慢,具有高度的不可预期性,而且往往会制造出用户不想要或不愿购买的产品 => 用户故事
为什么不高效
敏捷的核心是节奏，工作中的自我损耗，浪费，把事情做完整
- 节奏
- 浪费 => 无理（团队是否超负荷） => 无稳（开发节奏、是否完整的做着一件事） => 无驮（是否有价值，是否存在资源的浪费，20%重要的需求是否重要）
- 需求评审0.5 -> 方案设计1 -> 技术方案评审0.5 -> 测试用例评审0.5 -> 周会总结0.5
开发周：2.5 - 沟通渠道数量=n(n-1)/2 => 66
- 有自主权，得到授权，扫清障碍。从被动接受 -> 主动提出 -> 民主决策
- 舒适度：通常我们只奖励结果，但我们真正要奖励的是人们努力奋斗的过程
故事点，自我驱动
检查与调整
计划(Plan)、执行(Do)、检查(Check)与行动(Action)
PDCA：“行动”意味着根据实际成果与环境去改变原有的工作方法
拟定和改进清单，是否存在浪费。明白很多道理，依然过不好这一生。盯住一点，敏捷式的提高，不要拖延
