敏捷开发的宣言和原则 宣言： 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 原则： 1．我们最优先做的是通过尽早、持续的交付有价值的软件来使客户满意。 2．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。 4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 5．围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且相信他们能够完成工作。 6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 7．工作的软件是首要的进度度量标准。 8．敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 9．不断地关注优秀的技能和好的设计会增强敏捷能力。 10．简单----使未完成的工作最大化的艺术------是根本的。 11．最好的构架、需求和设计出自于自组织的团队。 12．每隔一定时间，团队会在如何才能更有效地工作方面反省，然后相应地对自己的行为进行调整。 （一）敏捷开发思想之简单最好 极限编程中有一条著名的懒汉原则，称之为KISS原则，KISS是Keep it simple and stupid的缩写。简略地说，就是设计尽量保证简单。极限编程坚持只为今天的需求设计以及编码，而不用考虑明天。这颇有一些“做一天和尚撞一天钟”的意味。 这个原则带来一个问题，那就是我们还需要设计吗？ 我们强调设计，其目的就在于设计出合理、优雅的结构，以提供具有良好复用性与可扩展性的系统，这是一种未雨绸缪，为未来考虑。而现在，我们若要遵循 KISS原则，就是不再考虑明天的需求。显然，这两者的观点是相悖的。于是，矛盾出现：一方面我们需要保持设计简单，不做无谓的功能预测；另一方面，我们又需要拥抱变化，在尽可能少的改变结构与代码的情况之下，满足未来的需求。 如何解决这个矛盾。让我们先看看提出简单原则的初衷。在《敏捷开发思想之拥抱变化》一篇中，我提到需求的变化是不可避免的。即使是最优秀的需求分析师和架构设计师都不可能在项目之初穷尽所有客户要求的功能，作出最完美的分析与设计，即做到“增之一分则太多，减之一分则太少”。我们需要把握分析和设计的“度”。但事实却是，我们总喜欢越俎代庖，利用自己的经验帮助客...
