第1章 敏捷——高效软件开发之道
- 敏捷开发宣言
*个体和交互胜过过程和工具
*可工作的软件胜过面面俱到的文档
*客户协作胜过合同谈判
*响应变化胜过遵循计划
2. 敏捷工具箱
*Wiki
*版本控制
*单元测试
*自动构建
第2章 态度决定一切
态度非常重要，包括团队中的所有人。专业的态度应该着眼于项目和团队的积极结果，关注个人和团队的成长，围绕最后的成功开展工作。
1. 做事
在敏捷团队中，大家的重点是做事。他们把精力直接放到解决问题上，而不是抱怨。你可以从自己先做起。如果一个开发者带着抱怨或者问题来找你，你要了解具体的问题，询问他你能提供什么样的帮助，这样简单的一个行为就清晰地表明你的目的是解决问题，而不是追究责任。
指责不能修复bug(Blame doesn’t fix bugs)。把矛头对准问题的解决方法，而不是人。这才是真正有用处的正面效应。
- 欲速则不达
在修改代码之前一定要很好地理解它。
如果团队成员花些时间阅读其他同事写的代码，他们就能确保代码是可读和可理解的。实行CodeReview，不仅有助于代码更好理解，而且是发现bug最有效的方法之一。
另一种防止代码难懂的重要技术就是UnitTest。Unit Test帮助你很自然地把代码分层，分成很多可管理的小块，这样就会得到设计更好、更清晰的代码。在更深入项目的时候，可以直接阅读单元测试——它们是一种可执行的文档。
不要坠入快速的bugfix之中。要投入时间和精力保持代码的整洁。
- 对事不对人
在同事John描述了自己的观点后，对于你的顾虑最适合并且最有效的表达方式应该是：“谢谢，John，但是我想知道，如果两个用户同时登陆会发生什么情况？”——询问你的队友，并提出你的顾虑，而不是否定其观点，更不是否定其个人能力。
在队友提出想法后，应该多给予鼓励，而不是否定，有利于问题的解决。
有效的特殊技术：
*设定最终期限。如参加设计方案，设定一个明确的deadline，例如午饭时间或者一天的结束。最有最好的答案，只有更合适的方案。
*逆向思维。先是积极地看到它的正面，然后努力地从反面去认识它。目的是要找出优点最多缺点最少的那个方案。
*设立仲裁人。选择一个仲裁人作为本次会议的决策者，确保每个人都有发言的机会。
*支持已经做出的决定。一旦方案被确定了，每个成员都必须通力合作，努力实现这个方案。
设计充满了妥协（生活本身也是如此），成功属于意识到这一点的团队。在开始寻找最好的解决方案之前，大家对“最好”的含义要先达成共识，包括对开发者和用户。
- 排除万难，奋勇前进
当发现问题时，不要试图掩盖这些问题。而要有勇气站起来，说：“我现在知道了，我过去使用的方案不对。我想到了一些办法，可以解决这个问题。”
做正确的事。要诚实、要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。
如果遇到一段奇怪的代码，在你没有马上理解那段代码，不要轻易地否定和重写它们。那不是勇气，那是鲁莽。
第3章 学无止境
敏捷需要持续不断的学习和充电。
- 跟踪变化
跟上技术变化的步伐的建议：
*迭代和增量式的学习。每天计划用一段时间来学习新技术。记下那些想学的东西，然后在计划的时间中深入研究它。
*了解最新行情。互联网上有大量的关于学习新技术的资源。选择一些公认的优秀技术博客，经常去读一读。
*如饥似渴地阅读。找一些关于软件开发和非技术主题的好书，也可以是一些专业的期刊和商业杂志。
跟踪技术变化。不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。
- 对团队投资
提供你和团队学习的更好平台。坚持有计划有规律地举行讲座，不要局限于纯技术的图书和主题，相关的非技术主题（项目估算、沟通技巧等）也会对团队有帮助。
- 懂得丢弃
敏捷的根本之一就是拥抱变化。学习新的东西，丢弃旧的东西。
- 打破沙锅问到底
在遇到/修复一个问题前，多问几个为什么，不停地问为什么，不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。但是，问问题，要问到点子上。还有，在问问题之前，想好为什么有这个疑问，为什么要问这个问题。
- 把握开发节奏
解决任务，在事情变得一团糟之前。
在每天结束的时候，测试代码，提交代码，没有残留的代码。不要搞得经常加班。以固定、有规律的长度运行开发迭代周期。小而可达的目标会让每个人全速前进。庆祝每一次难忘的成功：共享美食或团队聚餐。
第4章 交互用户想要的软件
- 让客户做决定
在设计方面，做决定的时候必须有开发者参与。可是，在一个项目中，他们不应该做所有的决定，特别是业务方面的决定。
要么现在就让用户做决定，要么现在就开始开发，迟些让用户决定，不过要付出较高的成本。
开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让客户做决定。
让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题并让他们做决定。
记录客户做出的决定，并注明原因，可以使用工程师的工作日志或Wiki、邮件记录等。
- 让设计指导而不是操纵开发
- 合理地使用技术
不要开发你能下载到的东西
- 保持可以发布
已提交的代码应该随时可以行动。在团队里工作，修改一些东西的时候必须很谨慎，要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。
下面是一个简单的工作流程，可以防止你提交破坏系统的代码：
(1).在本地运行测试。先保证完成的代码可以编译，并且能通过所有的单元测试，接着确保系统中的其他测试都可以通过。
(2).check-out最新的代码。从版本控制系统中更新代码到最新的版本，再编译和运行测试。这样往往会发现让你吃惊的事情：其他人提交的新代码和你的代码发生了冲突。
(3).提交代码。现在是最新的代码了，并且通过了编译和测试，可以提交它们了。
保证你的项目时刻可以发布。保证你的系统随时可以编译、运行、测试并立即部署。
如果不得不让系统长期无法发布，就做一个branch版本，可以继续自己的修改，如果不行，还可以撤销，千万不能让系统既不可以发布，又不可以撤销。
- 提早集成，频繁集成
集成和独立不是相互矛盾的，可以一边进行集成，一边进行独立开发。使用mock对象来隔离对象之间的依赖关系，这样在集成之前就可以先做测试。可以使用mock对象，编写独立的单元测试，而不需要立刻就集成和测试其他系统，只有当你自信它能工作时，才可以集成。
一般需要每天集成几次，最好不要2~3天才集成一次。绝不要做大爆炸式的集成。如果集成的问题很大，那一定是做得不够频繁，会发现整天在解决集成带来的问题。
- 提早实现自动化部署
一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖问题。QA人员要像测试应用一样测试部署。
在没有询问并征得用户的同意前，安装程序绝对不能删除用户的数据。这个有亲身体验，一个同事应一客户需求，给客户做了个小工具，没有问清客户在什么样的环境下使用，结果客户拿到工具，一执行，把客户的某些文件给删了，客户那个气啊……
- 使用演示获得频繁反馈
需求就像流动着的油墨。我们经常看到，给客户演示所完成功能的时间与得到客户需求的时间间隔越长，那么你就会离最初需求越来越远。应该定期地，每隔一段时间，例如一个迭代的结束，就与客户会晤，并且演示你已经完成的功能特性。
清晰可见的开发。在开发的时候，要保持应用可见。每隔一周或两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。当然，还要尊重客户的时间，如果客户只可以接受一个月一次的会议，那么就定一个月。
- 使用短迭代，增量发布
对付大项目，最理想的方法就是小步前进，这也是敏捷方法的核心。短迭代让人感觉非常专注且具效率。
增量开发。发布带有最小却可用功能块的产品。每个增量开发中，使用1~4周左右迭代周期。
- 固定的价格就意味着背叛承诺
第5章
第6章
第7章
第8章