迭代开发，价值优先

分解任务，真实进度

站立会议，交流畅通

用户参与，调整方向

结对编程，代码质量

测试驱动，安全可靠

持续集成，尽早反馈

自动部署，一键安装

定期回顾，持续改进

不断学习，提高能力

​ —–编程的武功秘籍

第1章 敏捷–高效软件开发之道

• 个体和交互胜过过程和工具
• 可工作的软件胜过面面俱到的文档
• 客户协作胜过合同谈判
• 响应变化胜过遵循计划

敏捷开发：一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法，要求在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。

重点：持续开发、持续反馈、发现问题及时解决问题。

重构：不断从自己写的代码中得到反馈，并且使用自动化工具不断构建（持续集成）和测试系统，在功能不变的情况下，对部分代码重新设计，来改善代码的质量。

迭代：将当前版本演示给客户，及时得到他们的反馈，然后根据实际情况进行修改。

敏捷工具箱：

• Wiki【Wiki之道】
• 版本控制
• 单元测试【单元测试之道Java版】
• 自动构建
• 《软件项目成功之道》

第2章 态度决定一切

专业的态度应该着眼于项目和团队的积极结果，关注个人和团队的成长，围绕最后的成功开展工作。

出了问题，第一重要的不是确定元凶，而是解决问题【指责不能修复bug】。

一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作，应互相帮助，而不是互相指责。

千里之堤，溃于蚁穴，大灾难是逐步演化来的。一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命。

实行代码复审，不仅有助于代码更好理解，而且是发现bug最有效的方法之一 ，所以不要孤立的编码，多花些时间阅读其他同事写的代码。

多投入时间和精力保持代码的整洁、敞亮。

不要急于修复一段没能真正理解的代码。

没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。

小故事：

多年以前，在我担任系统管理员的第一天，一位资深的管理员和我一起安装一些软件，我突然按错了一个按钮，把服务器给关掉了。没过几分钟，几位不爽的用户就在敲门了。
这时，我的导师赢得了我的信任和尊重，他并没有指责我，而是对他们说：“对不起，我们正在查找是什么地方出错了。系统会在几分钟之内启动起来。”这让我学到了难忘的重要一课。

在一个需要紧密合作的开发团队中，如果能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题，而不是勾心斗角，误入歧途。

负面的评论和态度扼杀了创新。 把重点放在解决问题上，而不是去极力证明谁的主意更好。

你不需要很出色才能起步，但是你必须起步才能变得很出色。 —莱斯·布朗

能欣赏自己并不接受的想法， 表明你的头脑足够有学识。—亚里士多德

没有最好的答案，只有更合适的方案。

开会的时候设立仲裁人，其责任就是确保每个人都有发言的机会，并维持会议的正常进行。

支持已经做出的决定，让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。

想要支持或者反驳一个观点，有时候你必须先做一个原型或者调查出它有多少的同意者或者反对者。

假如要你修复其他人编写的代码， 抱怨和发泄并不能解决问题，最有效的方式是动手重写这些代码，并比较重写前后的优缺点。

如果发现你以前的一段代码出错了，不要试图掩盖这些问题，而是应该主动承认，并且寻求解决方案。

要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。