在读本书之前，许多同事与我讲，《敏捷革命》是由敏捷开发创始人之一的杰夫.萨瑟兰所著，是关于敏捷的入门级经典，通过故事介绍敏捷的理念、由来、概念。虽经典但不建议，因为太简单，而且更像是故事书，但我却毫不犹豫的选择了它，因为我是入门，而且更是喜欢读故事。
1， 在关于联邦调查局关于虚拟案件档案系统（VirtualCase File System）中，其关于复杂需求，谈到的甘特图/需求文档的描述引发了我深深的同感，花了几个月整理出来的需求、流程，其实并非用户真实需求或者只是用户之前的需求，一堆的文档真正能看懂，了解清楚的几乎没有。在这个时候，瀑布法在Scrum法前不堪一击。
对于复杂/有创新性的活动，解决问题最重要的方法之一是“检查与调整”：每过一小段时间就停一停手头的工作，检查一下已经完成了哪些任务，看看这些任务是不是自己应该做的，看看有没有更好的方法。
2， 在第三章 –“聚焦团队，而非个人”中，文章谈到赋予团队自主决定如何做事的自由，尊重他们，让他们自由发挥专长。结合之前培训，感觉在平时工作中陷入某些误区，因为某同事有能力，而把某团队与此同事划上等号，其结果是其它员工失去前进动力，而此员工在习惯后陷入孤军作战的陷阱。提升团队业绩。这比提升个人业绩的影响大得多，会超出后者几个量级。
3， 第八章 找到最有价值的20%
很多项目的失败在于开发了一个开发成员自认为的完美作品，但用户不接受，或者市场不接受，缺少实用性。一个产品80%的价值来自20%的功能，Scrum的魔力就在于能帮你把价值最高、风险最低的事项置于最优先的位置。找出那些最有商业影响力，对顾客最重要的，最有利可图的，而又最容易实现的，能在最低风险下创造更多价值，这样才能让客户、市场都满意。
4， 再次强调每日立会的三个问题：
你昨天做了什么去帮助团队完成冲刺？
今天你打算做什么来帮助团队完成冲刺？
什么因素阻碍了团队的前进之路？
时间短，不超过15分钟，任务尽量不分配，自下而上认领。
5， 冲刺评估或冲刺展示。
结合日常工作，我们对于DoD（完成定义）的认识不够，任务的完成没有真正定义清楚，让工作出现许多偏差。
6， 冲刺回顾。
冲刺回顾是我们之前做得不好的部分。本来是展示之前冲刺中创造的成果，并征求反馈意见，想想哪些事执行得很顺利，哪些事应该做得更好，以及在下一个冲刺阶段中可以做出什么改善。但是在某些不太顺利的冲刺中，回顾容易变成对某人或某几人的批斗会。SM应该做好引导，以积极乐观的讨论为主，大家从解决问题的角度向前看，要让这个冲刺回顾过程有效，团队需要相互信任。
要将注意力集中在流程上，认真分析以下几个问题：
为什么会发生那件事？
为什么我们当时忽略了？
怎样才能加快工作进度？
团队必须有勇气把真正的障碍摆到台面上来，并虚心接受他人反馈的意见和建议，以便寻求问题解决之道，而非只想着为自己辩解。
总的来说，整本书中有很多值得深入学习的地方，如冲刺规划会、如何透明化管理，但基于当前自己对于敏捷的理解，最有共鸣的点如上，此书以后可以多次阅读，必定能学到更多体会。
