1. 敏捷-高效软件开发之道

个体和交互胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 虽然右项也有价值，但我们认为左项具有更大的价值。 敏捷宣言作者，2001年版权所有。

敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。

2. 态度决定一切

• 1.做事：指责不会修复 bug
• 2.欲速则不达：拙劣的代码工人会这样不假思索地改完代码，然后快速转向下一个问题。不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。
• 3.对事不对人:引导性地提出一个疑问，让他们自己意识到问题。你不需要很出色才能起步，但是你必须起步才能变得很出色。
  • 设定最后期限；设立仲裁人；支持已经做出的决定
• 4.排除万难，奋勇前进：

3. 学无止境

• 5.跟踪变化
• 6.对团队投资:一个学习型的团队才是好的团队
• 7.懂得丢弃：学习新东西，抛弃旧的东西
• 8.打破沙锅问到底：多问为什么
• 9.把握开发节奏：许多的敏捷技巧来源于时间盒——设定一个短时的期限，为任务设定不能延长的最终期限。

4.交付用户想要的软件

• 10.让客户做决定：开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定
• 11.让设计指导而不是操纵开发。设计满足需求即可。CRC（类—职责—协作）卡片：类名；职责（它应该做什么）；协作者（要完成工作与其他什么对象一起工作）
• 12:根据需要选择技术
• 13.保持可以发布：已提交的代码应该随时可以行动
• 14.提早集成，频繁集成
• 15.提早实现自动化部署
• 16.使用演示获得频繁反馈
• 17.使用短迭代，增量发布
• 18.固定的价格就意味着背叛承诺

5.敏捷反馈

• 19.守护天使：编写能产生反馈的代码：测试是可重复的；测试边界条件；不要放过失败的测试用例
• 20.先用它再实现它：TDD
• 21.不同环境就有不同问题
• 22.自动验收测试
• 23.度量真实的进度：待办
• 24.倾听用户声音

6.敏捷编码

• 25.代码要清晰地表达意图。清晰度应该排在效率之前
• 26.用代码沟通
• 27.动态评估取舍
• 28.增量式编程
• 29.保持简单。开发可以工作的、最简单的解决方案
• 30.编写内聚的代码：内聚性用来评估一个组件（包、模块或配件）中成员的功能相关性。内聚程度高，表明各个成员共同完成了一个功能特性或是一组功能特性。内聚程度低的话，表明各个成员提供的功能是互不相干的。
• 31.告知，不要询问:面向过程的代码取得信息，然后做出决策。面向对象的代码让别的对象去做事情。命令与查询相分离模式
• 32.根据契约进行替换: is-a has-a

7.敏捷调试

• 33 记录问题解决日志
• 34 警告就是错误
• 35 对问题各个击破
• 36 报告所有的异常:处理或是向上传播所有的异常
• 37 提供有用的错误信息

8.敏捷写作

• 38 定期安排会面时间:站立会议
• 39 架构师必须写代码
• 40 实行代码集体所有制
• 41 成为指导者
• 42 允许大家自己想办法
• 43 准备好后再共享代码
• 44 做代码复查
• 45 及时通报进展与问题。发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。

9.尾声：走向敏捷

• 9.1 只要一个新的习惯
• 9.2 拯救濒临失败的项目
• 9.3 引入敏捷：管理者指南:从立会开始（见第148页习惯38）。这可以让团队有机会进行彼此讨论，并对一些重大问题达成共识。把之前相对孤立的架构师带到团队中，并让他们参与到日常开发工作（见第152页习惯39）。开展非正式的代码复查（见第165页习惯44），并做出计划，让客户与用户也参与到项目中来（见第45页习惯10）。
• 9.4 引入敏捷：程序员指南举例来说，从单元测试开始是一个不错的选择。可以先针对自己的代码开始使用。在短时间之内（几周甚至更少），就可以看到代码质量提升了——减少了错误的数目，提高了质量，健壮性也有所提升。你下午5点就可以下班回家，而且所有的任务都可以顺利完成——不必担心半夜被电话叫醒，去修复bug。旁边的开发人员想知道你是如何做到的，而且消息也渐渐传开了。整个团队现在都想尝试这些新奇的习惯，而不需要你努力去说服他们。