敏捷工具箱
1. Wiki 网站 是一个很友好的支持协作的工具，团队中的每一个人都可以根据需要动态的新增和重新组织网页中的内容
2. 版本控制 使用CVS
3. 单元测试 《JunitRecipes 中文版》
4. 自动构建 《项目自动化之道》
5.http://draconet.sourceforge.net 供.net平台使用的持续集成工具，通过Windows 服务的方式运行。
6.http://sourceforge.net/projects/nunit
7.http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign //面向对象设计原则
8.http://c2.com/cgi/wiki?TestDrivenDevelopment //测试驱动开发
9.http://www.xprogramming.com/software.htm //测试工具在内的资源集合.
第一章 敏捷---高效软件开发之道
1.先难后易。我们要首先解决困难的问题，把简单的问题留到最后。
第二章 态度决定一切
1. 做事：把矛头对准问题的解决办法，而不是人。这是真正有有用处的正面效应。
2. 欲速则不达：不要坠入快速的简单修复之中，要投入时间和精力保持代码的简洁、敞亮。
3. 对事不对人：让我们骄傲的应该是解决了问题，而不是比较谁的主意更好。
4. 排除万难，奋勇前进；做正确的事情.要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。
第三章 学无止境
5.跟踪变化：跟踪技术变化，你不需要精通所有的技术，但是需要清楚知道行业的动向，从而规划你的项目和职业生涯。
下面是一些建议：
迭代和增量式学习。每天计划用一段时间来学习新技术。记下你想要学习的东西——当你听到不熟悉的术语或者短语的时候，记录下来.
了解最新行情;
参加本地的用户组活动;
参加研讨会议；
如饥似渴的阅读。
6.对团队投资: 提供你和团队学习的更好的平台。通过午餐会议可以增进每一个人的知识和技能，并帮助大家聚集在一起进行沟通交流。唤起人们对技术和技巧的激情，将会对项目大有裨益。
7.懂得丢弃: 学习新的东西，丢弃旧的东西。在学习一门技术的时候，要丢弃会阻止你前进的旧习惯。毕竟，汽车要比马车车厢强的多。
8.打破砂锅问到底： 不停的问为什么。不能只满足于别人告诉你的表面现象。要不停的提问直到你明白问题的根源。
9.把握开发节奏: 解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。
第四章 交付用户想要的软件
10.让客户做决定：让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
11.让设计指导而不是操纵开发：好设计是一张地图，它也会进化。设计指引你向明确的方向前进，它不是殖民地，它不应该标识具体路线。你不要被设计（或者设计师）操纵。
12.合理的使用技术：根据需要选择技术。首先决定什么是你需要的，接着为这些具体的问题评估使用技术。对任何要使用的技术，多问一些挑剔的问题，并真实地作出回答。
13.保持可以发布:保持你的项目时刻可以发布。保证你的系统随时可以编译、运行、测试、并立即部署。
14.提早集成，频繁集成: 代码集成是主要风险来源。要想规避这个风险，只有早集成，持续而又规律的进行集成。
15.提早实现自动化部署：一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。
16.使用演示获得频繁反馈：清晰可见的开发。在开发的时候，要保持应用可见（而且客户心中也要了解）。每隔一周或者两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
17.使用短迭代，增量式开发：发布带有最小却可用功能块的产品。每个增量开发中，使用1-4周左右迭代周期。
18.固定的价格就意味着背叛承诺：基于真实工作的评估，让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。
第五章 敏捷反馈
19.守护天使：使用自动化的单元测试。好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试，不要进行任何设计和代码修改。
20.先用它再实现它：编程之前，先测试。将TDD(Test Driven Development，测试驱动开发)作为设计工具，它会为你带来更简单更实效的设计。
21.不同环境，就会有不同问题：使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等问题来找你。
22.自动验收测试：为核心的业务逻辑创建测试。让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。(FIT,即 集成测试框架 http：//fit.c2.com)
23.度量真实的进度：度量剩下的工作量，不要用不恰当的度量来欺骗自己或者自己的团队。要评估那些需要完成的代办事项。
24.倾听用户的声音：每一个抱怨的背后都隐藏了一个事实。找出真相，修复真正的问题。
第六章 敏捷编码
25.代码要清晰的表达意图：要编写清晰的而不是讨巧的代码。向代码阅读者表明你的意图。可读性差的代码一点都不聪明。
26.用代码沟通：用注释沟通。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能代替优秀的代码。
27.动态评估取舍：动态评估权衡。考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够好了，就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
28.增量式编程:在很短的编辑/构建/测试循环中编写代码。这要比话费长时间仅仅做编程写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。
29.保持简单：开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，否则不要使用模式，原则和高难度技术之类的东西。
30.编写内聚的代码：让类的功能尽量集中，让组建尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。
31.告知，不要询问：不要抢别的对象或组件的工作。告诉它做什么，然后盯着你自己的职责就好了。（将命令和查询分离开来）。
32.根据契约进行替换：通过替换代码来扩展系统。通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是集成。（两者之间的关系可以描述问 has-a 或是 uses-a 就使用委托。）
第七章 敏捷调试
33.记录问题解决日志：维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或相似问题时，就可以很快找到并使用了。
34.警告就是错误：将警告视为错误。签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。
35.对问题各个击破：对问题各个击破。在解决问题时，要将问题域与周边隔离开，特别是在大型应该中。（用原型进行分离）。
36.报告所有的异常：处理或是向上传播所有的异常。不要将它们压制不管，就算是临时这样做也不行。在写代码是要估计会发生的问题。
37.提供有用的错误信息：展示有用的错误信息。提供更易于查找错误细节的方式。发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。
第八章 敏捷协作
38.定期安排会面时间：使用每日立会。立会可以让团队达成共识。保证会议短小精悍不跑题。（时间不超过30分钟）
39.架构师必须写代码：架构、设计、编程和测试，这些工作给人的感觉就像是同一个活动——开发的不同方面。感觉它们彼此之间应该是不可分割的。
40.实行代码集体所有制：项目中绝大部分的代码都可以轻松应付。
41.成为指导者：分享自己的知识很有趣——付出的同时便有收获。还可以激励别人获得更好的成果，而且提升了整个团队的实力。
成为指导者意味着要分享——而不是固守——自己的知识、经验、和体会。意味着要对别人的所学和工作感兴趣，同时愿意为团队增加价值，一切都是为了提高队友和你能力与水平而不是毁掉团队。
然而，努力爬到高处，再以蔑视的眼神轻视其他人，这似乎是人类本性。也许在没有意识的情况下，沟通的障碍就已经建立起来了。团队中的其他人可能出于畏惧或尴尬，就不愿提出问题，这样就无法完成知识
的交换了。这类团队中的专家，就像是拥有无数金银财宝的有钱人，却因健康因无福享受。我们要成为指导别人的人，而不是折磨别人的人。
42.允许大家自己想办法：给别人解决问题的机会。指给他们正确的方向，而不是直接提供解决方案。每个人都能从中学到不少东西。
43.准备好后再共享代码：绝不要提交尚未完成的代码。故意签入编译未通过或是没有通过单元测试的代码，对于项目来说，应视做玩忽职守的犯罪行为。
44.做代码复查：复查所有的代码。对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而高效的成果。要让不同的开发人员在每个任务完成后复查代码。
例如：通宵复查、检拾游戏、结对编程。
45.及时通报进展与问题：发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。及时通报进展与问题，有情况发生时，就不会让别人感到突然....