对于程序员同学或技术管理者 5 星推荐。虽然是十年之前的研发经验，到现在依然有用。敏捷开发是一种把以人为本、团队合作、快速响应变化和可工作的软件 (目标结果) 作为宗旨的开发方法。它要求我们只关注真正重要的事情，少关注那些占用大量时间却不重要的事。从定义上我们可以看出，敏捷注重人与人的协同沟通，是一种团队合作方式。可以根据外部的反馈持续迭代，最终形成一个可执行的软件。书中的内容都是基于现实使用的问题为基础来阐述的。所以比较好理解。在团队运用敏捷开发时，能从中借鉴很多经验。毕竟你只需要记住这 45 个习惯就好。

这本书也不能说它好，也不能说它坏，因为我不懂。

虽然这本书的书名不叫敏捷开发，但其实都是在围绕敏捷开发的一些原则进行实践上的讲解。

这本书看前看后肯定对于认知来说是一个分水岭，这里面居然还穿插着很多有意思的故事，所以让我感觉当一个程序员，其实这份工作还挺有意思的，我自己身边有很多程序员的朋友，他们有些人大大咧咧的，有些人却特别细腻敏感，但是你能发现他们有一个共性，那就是非常的努力工作和生活，而且对每一件事都比较负责任，所以看完这本书以后就有一种自己当了一把程序员的体验，所以还是挺有意思的。不过现代社会的互联网发展节奏也开始进入缓慢周期，所以很多程序员其实也很害怕自己被淘汰掉，所以这些年他们不断地营销自己，尝试了很多新的办法，让自己更有价值，实际上我觉得很多答案可以从这本书里面去寻找。

非常精悍的一本书，非常容易读完，但是包含了很多很多不错的实践，特别是有很多需要实际开发过程中平衡的地方。即使读过好几本类似的书籍，比如《代码大全》《重构》《clean code》等，还是能从这本书学到很多真知灼见。

设定最终期限。如果你正在参加设计方案讨论会，或者是寻找解决方案时遇到问题，请设定一个明确的最终期限，例如午饭时间或者一天的结束。这样的时间限制可以防止人们陷入无休止的理论争辩之中，保证团队工作的顺利进行。同时（我们觉得）应现实一些：没有最好的答案，只有更合适的方案。设定期限能够帮你在为难的时候果断做出决策，让工作可以继续进行。

本书很多思考问题的角度，解决问题的方法，不但对做敏捷开发的人员有用，对于做软件的都有用，甚至对于其他行业也有启迪例如快速反馈，自动验证，对于其他工作也是一样的道理。

这是一本很容易理解并掌握，不需要太多基础就可以阅读的书。不管你是开发人员，还是管理人员、财务等后勤人员、学生、编程爱好者，只要你对敏捷有兴趣，就可以读懂这本书。你不会被众多的概念和曲折的逻辑所迷惑，不会被高难度技巧所困扰。这本书为你打开了了解和学习敏捷方法的一扇大门，并指出继续前进的道路。

技术方法介绍的很好，我应用在我的工作中很实用。

1. 做实事不要抱怨，发牢骚，指责他人，找出问题所在，想办法解决。对问题和错误，要勇于承担。2. 欲速则不达用小聪明、权宜之计解决问题，求快而不顾代码质量，会给项目留下要命的死角。3. 对事不对人就事论事，明智、真诚、虚心地讨论问题，提出创新方案。4. 排除万难，奋勇前进勇气往往是克服困难的唯一方法。5. 跟踪变化新技术层出不穷并不可怕。坚持学习新技术，读书，读技术杂志，参加技术活动，与人交流。要多理解新词背后的所以然，把握技术大趋势，将新技术用于产品开发要谨慎。6. 对团队投资打造学习型团队，不断提高兄弟们的平均水平。7. 懂得丢弃老的套路和技术，该丢，就得丢。不要固步自封。8. 打破砂锅问到底不断追问，真正搞懂问题的本质。为什么？应该成为你的口头禅。9. 把握开发节奏控制好时间，养成好习惯，不要加班。10. 让客户做决定让用户在现场，倾听他们的声音，对业务最重要的决策应该让他们说了算。11. 让设计指导而不是操纵开发设计是前进的地图，它指引的是方向，而不是目的本身。设计的详略程度应该适当。12. 合理地使用技术根据需要而不是其他因素选择技术。对各种技术方案进行严格地追问，真诚面对各种问题。13. 让应用随时都可以发布通过善用持续集成和版本管理，你应该随时都能够编译、运行甚至部署应用。14. 提早集成，频繁集成集成有风险，要尽早尽量多地集成。15. 提早实现自动化部署 16. 使用演示获得频繁反馈 17. 使用短迭代，增量发布 18. 固定价格就意味着背叛承诺估算应该基于实际的工作不断变化。19. 守护天使自动化单元测试是你的守护天使。20. 先用它再实现它测试驱动开发其实是一种设计工具。21. 不同环境，就有不同问题要重视多平台问题。22. 自动验收测试 23. 度量真实的进度在工作量估算上，不要自欺欺人。24. 倾听用户的声音每一声抱怨都隐藏着宝贵的真理。25. 代码要清晰地表达意图代码是给人读的，不要耍小聪明。26. 用代码沟通注释的艺术。27. 动态地进行取舍记住，没有最佳解决方案。各种目标不可能面面俱到，关注对用户重要的需求。28. 增量式编程写一点代码就构建、测试、重构、休息。让代码干净利落。29. 尽量简单宁简勿繁。如果没有充足的理由，就不要使用什么模式、原则和特别的技术。30. 编写内聚的代码类和组件应该足够小，任务单一。31. 告知，不要询问多用消息传递，少用函数调用。32. 根据契约进行替换委托往往优于继承。33. 记录问题解决日志不要在同一地方摔倒两次。错误是最宝贵的财富。34. 警告就是错误忽视编译器的警告可能铸成大错。35. 对问题各个击破分而治之是计算机科学中最重要的思想之一。但是，要从设计和原型阶段就考虑各部分应该能够很好地分离。36. 报告所有的异常 37. 提供有用的错误信息稍微多花一点心思，出错的时候，将给你带来极大便利。团队协作篇 38. 定期安排会面时间常开会，开短会。39. 架构师必须写代码不写代码的架构师不是好架构师。好的设计都来自实际编程。编程可以带来深入的理解。40. 实行代码集体所有制让开发人员在系统不同区域中不同的模块和任务之间轮岗。41. 成为指导者教学相长。分享能提高团队的总体能力。42. 让大家自己想办法指引方向，而不是直接提供解决方案。让每个人都有机会在干中学习。43. 准备好后再共享代码不要提交无法编译或者没有通过单元测试的代码！44. 做代码复查复查对提高代码质量、减少错误极为重要。45. 及时通报进展与问题主动通报，不要让别人来问你。

糊里糊涂的刷了一遍。我对敏捷这个事情并没有太大好感。敏捷在军事中的意思就是保持机动性 那就要求参与人员随时随地做调整。要知道保持这种状态是非常辛苦的。要把神经调到略微紧绷的状态中，然后感觉变化而实时进行变化，我觉得还是比较辛苦的。

这本书最大的亮点是辩护法贯穿始终，不同的角度去看问题，为对立面找到合适的理由解释，最主要的目标是解决分析问题。

四月开始第一次做敏捷项目，每周交付的频率，整两个月累到模糊。期间在翻这本书，觉得每个点都精准踩在痛处，这里提到的问题我们都有。所以这也是我们人仰马翻的原因所在。当然理论应用于现实并不容易，好在里面提供了实操经验。方法论的意义在于，不会走了很远叉路才发现路标一直在明处。

虽然不懂，但是还是看了一遍！