《敏捷软件开发》的原文摘录
-
唯一能够加快进度的方法便是缩减范围。不要经受不住诱惑盲目冲刺。
在程序员所能表现的各种不专业行为中，最糟糕的是明知道还没有完成任务却宣称已经完成 (查看原文)
-
敏捷开发人员知道要做什么，是因为：
（1） 他们遵循敏捷实践去发现问题
（2） 他们应用设计原则去诊断问题；并且
（3） 他们应用适当的设计模式去解决问题。
软件开发的这三个方面间得相互作用就是设计。 (查看原文)
-
人的因素完全能非常好的预测项目的轨迹，人的因素高于过程和技术的选择
如果我们想要构建出人的系统，那么我们就应当理解人们在操作上的特性 (查看原文)
-
一个人的个性影响了他执行赋予他的特定任务的能力 (查看原文)
-
我们不能做的是：期望人们是可以预料或彼此相同的
高级语言能够让人们在一个与问题空间更接近的技术空间思考问题，而减少了那些关于实现约束的打扰 (查看原文)
-
技术四作用：1、使人们更简单地表达思想。2、完成手工不能完成的任务。3、使乏味、易出错的活动自动化。4、使人们沟通更便利。 (查看原文)
-
技术与人的文化价值和人的认识本质矛盾时，技术便不能提高效率 (查看原文)
-
学习就是知觉的重新组织 (查看原文)
-
这种知觉经验变化的过程不是渐进的尝试与错误的过程，而是突然的顿悟 (查看原文)
-
当一些个体被安排在一起时，会自然得组织并形成特定的信息，而给予人一种超越原先个体总和信息的印象 (查看原文)
-
当人们失去一些以及得到的东西时，他们一般厌恶风险；当他们处在一个可得可失的境地时，他们一般会接受风险 (查看原文)
-
三种高度纪律化的方法集：净室法、个体软件过程、极限编程 (查看原文)
-
世界有着自己的结构，因此特异性总是暗示着一般性。这就是为什么在传达思想时故事能够有那么强大的作用，并且这种作用往往比思想本身清晰度的作用更强大。 (查看原文)
-
在「充满积极讨论的屋子（war room）」里工作，生产效率非但不会降低，反而会成倍的提高。 (查看原文)
-
该启发式规则建议不应该依赖于具体类——也就是说，程序中所有依赖关系都应该终止于抽象类或者接口
任何变量都不应该持有一个指向具体类的引用
任何类都不应该从具体类派生
任何方法都不应该重写它的任何基类中已经实现了的方法 (查看原文)
-
一个大而笨重的过程会产生它本来企图去解决的问题。它降低了团队的开发效率，使得进度延期，预算超支。它降低了团队的响应能力，使得团队经常创建错误的产品。遗憾的是，许多团队认为，这种结果是因为他们没有采用更多的过程方法引起的。因此，在这种失控的过程膨胀中，过程会变得越来越庞大。 (查看原文)
-
人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。 (查看原文)
-
合适的工具对于成功来说是非常重要的。像编译器、IDE、源代码控制系统等，对于团队的开发者正确地完成他们的工作是至关重要的。然而，工具的作用可能会被过分地夸大。使用过多的庞大、笨重的工具就像缺少工具一样，都是不好的。
我们的建议是从使用小工具开始，尝试一个工具，直到它无法适用时才去更换它。
……
在决定为团队购买最好的 CASE 工具许可证前，先使用白板和方格纸…
不要认为更大的、更好的工具可以自动的帮你做得更好。通常它们造成的障碍要大于带来的帮助。 (查看原文)
-
一个类只有一个引起它变化的原因 (查看原文)
-
敏捷开发基本宣言
我们正在通过亲身实践以帮助他人实践，揭示更好的软件开发方法，通过这项工作，我们认为：
人和交互 重于 过程和工具
可以工作的软件 重于 面面俱到的文档
客户合作 重于 合同谈判
随时应对变化 重于 遵循计划
虽然右项也有其价值，但我们认为左项更加重要。
我的建议是从使用小工具开始。尝试一个小工具，知道发现它无法适用时才去更换它。不要急着去购买那些先进的、价格昂贵的源代码控制系统，相反应该先使用一个免费的系统，直到能够证明该系统已经不再适用。在决定为团队购买最好的CASE工具许可证前，先使用白板和方格纸，直到明确地知道需要更多的功能。在决定使用庞大的、高性能的数据库系统前，先使用平面文件。不要认为更大的、更好的工具可以自动帮你做的更好。通常，他们造成的障碍要大于带来的帮助。 (查看原文)
