第2章：态度决定一切

1. 做事：最高优先级是解决问题。指责不能修复bug。问问“为了解决或缓解问题，我能够做些什么？”
2. 欲速则不达：不要孤立的编码（代码复审），使用单元测试
3. 对事不对人：设计充满了妥协（生活本身也是如此）
4. 排除万难，奋勇前进：做正确的事。要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。用他们（生意人）能够听懂的话语表达。

第3章：学无止境

5. 跟踪变化：迭代和增量式的学习。跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。
6. 对团队投资：让每个人都觉得自己越来越聪明。
7. 懂得丢弃：打破旧习惯很难，更难的是自己还没有意识到这个问题。
8. 打破砂锅问到底：让他们耐心地回答你的问题，这是你的职责。不停地问为什么。
9. 把握开发节奏：项目开发需要有一致和稳定的节奏。庆祝每一次难忘的成功，共享美食和啤酒或者团队聚餐。

第4章：交付用户想要的软件

10. 让客户做决定：决定什么不该决定
11. 让设计指导而不是操纵开发：好设计是一张地图，它也会进化。好的设计应该是正确的，而不是精确的。它是目标，不是具体的处方。在设计过程中学习是有价值的，但设计本身也许没有太大的用处。复杂的建模工具智慧让你分散精力，而不是启发你的工作。
12. 合理地使用技术：在考虑引入新技术或框架之前，先要把你需要解决的问题找出来。根据需要选择技术。
13. 保持可以发布：千万不能让系统既不可以发布，又不可以撤销。
14. 提早集成，频繁集成
15. 提早实现自动化部署
16. 使用演示获得频繁反馈
17. 使用短迭代，增量发布
18. 固定的价格就以为着背叛承诺：基于真实工作的评估。让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。你仍然需要根据当前的知识和猜想，做一个大致的评估，解释如何才能到达这个目标，并给出误差范围。

第5章：敏捷反馈

19. 守护天使：需要自动化单元测试。忘掉“测试”这个词。就把它看作是一个极好、编写能产生反馈的代码的技术。
20. 先用它再实现它：编程之前，先写测试。将TDD作为设计工具，它会为你带来更简单更有实效的设计。
21. 不同环境，就有不同问题：要积极地寻找问题，而不是等问题来找你。
22. 自动验收测试：为核心的业务逻辑创建测试。让你的客户单独验证这些测试。
23. 度量真实的进度：不要用不恰当的度量来欺骗自己或团队。
24. 倾听用户的声音：每一个抱怨背后都隐藏了一个事实。

第6章：敏捷编码

25. 代码要清晰的表达意图
26. 用代码沟通：注释要说明为什么会这样写代码。
27. 动态评估取舍：即使不能面面俱到，你也应该觉得已经得到了最重要的东西——客户认为有价值的特性。
28. 增量式编程
29. 保持简单：要将目标牢记在心：简单、可读性高的代码。强行让代码变得优雅与过早优化类似，同样会产生恶劣的影响。
30. 编写内聚的代码：bug很容易跟踪，代码也易于修改，因为类和组件的责任都很清晰。
31. 告知，不要询问：不要抢别的对象或是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。
32. 根据契约进行替换

第7章：敏捷调试

33. 记录问题解决日志
34. 警告就是错误
35. 对问题各个击破
36. 报告所有的异常
37. 提供有用的错误信息

第8章：敏捷协作

38. 定期安排会面时间：使用立会
39. 架构师必须写代码：不要允许任何人单独进行设计，特别是你自己。
40. 实行代码集体所有制：代码集体所有制并不意味着可以随心所欲、到处破坏。有些场合是不能采用代码集体所有制的。
41. 成为指导者
42. 允许大家自己想办法：如果有人真的陷入胶着状态，就不要折磨他们了。告诉 他们答案，再解释为什么是这样。
43. 准备好后再共享代码
44. 做代码复查
45. 及时通报进展与问题