在公司做了三次相关敏捷的主题：现有项目的敏捷之路，SCRUM,敏捷软件测试。
但是，有朋友说这几次都是站在管理的角度，程序员自己如何才能做做到敏捷呢？回来想想再结合之前看过的书总结出了如下18条，于是就起名“降龙十八掌”吧。到底哪一条对哪一掌，大家就自己对吧。
1. 态度积极。做事时专注，有问题积极找人帮忙同时也乐于帮助别人，勇于承认错误，如果你从没犯过错误，说明你可能没努力去工作。
2. 深入理解需求。对一个需求要尽可能多的理解，不要急于着手编码。
3. 不做世外高人。不要一个人默默无闻的编码，多阅读同事的代码，也请同事阅读自己的代码，保证代码易读，易理解。
4. 敢于发表意见。发现问题时，敢于提出来，不能任何事情都是全票通过，这样会扼杀创新，容纳自己并不接受的想法，贡献自己的好想法。
5. 持续学习，乐于分享。如果你很长时间不学习，发现很多东西很陌生，但如果你天天学习，每天学的东西很少，不要见到新技术出现“少小离家老大回”的现象。分享自己的知识，提高自己的团队，同时提高自己。
6. 保持合适的节奏。不要闲一天，忙一天，互上互下，冰火两重天。
7. 积极与客户沟通。对需求不确定的任何地方一定要问客户，给出建议同时让客户做决定。但不要问很多没有价值且耗费客户很多时间的问题。
8. 重视设计，每一个系统，每一个功能都需要设计，敏捷不是没有设计。但是设计不要太细，包含系统的结构或类的职责，形式可以多样，白板，草图，贴张纸就可以，最终还是通过代码来体现。
9. 尽早集成，频繁提交。注意提交不要破坏代码库。提交前在本地运行测试，获得最新代码，再运行本地测试，通过后提交代码。原子提交，一旦功能不能使用，可以立即快速回滚, 这样可以尽早暴露集成的问题，使修复bug的成本大大减小。
10. 用单元测试守护代码。自动化用户验收测试。这样可以快速回归。
11. 自动化部署。尽早实现一键部署，节省时间且可以尽早知道系统需要的软硬件环境。
12. 尽早提交，尽早得到客户的反馈。
13. 一定要个人计划，而且每天度量自己的进度，SCRUM里可以通过站立会议。要有自己的Backlog
14. 虚心接受用户的抱怨，认真对待抱怨，找出客户抱怨的原因
15. 代码集体所有，任何人都可以改自己的代码，自己也可以改任何人的代码。
16. 代码会说话，利用你的代码和同事沟通，代码要清晰表达自己要干什么。保持代码简洁易于理解，至少公用方法简洁易于理解。减少代码注释，用有意义的类名，方法名，参数名自己来解释。
17. 分离解决问题，修复Bug时把其它的地方隔离起来，就像修复电器一样，会把线路板拆下来修。比如使用Mock等方法。
18. 给客户显示可以查询错误的信息。比如可以在错误信息前加一错误号，这样可以方便开发人员在错误日志里定位。
