本节书摘来自异步社区《敏捷软件开发：原则、模式与实践（C#版.修订版）》一书中的第1章1.2节 原则，作者【美】Robert C. Martin , Micah Martin，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.2 原则
敏捷软件开发：原则、模式与实践（C#版.修订版）
从上述的价值观中引出了下面的12条原则，它们是敏捷实践区别于重型过程的特征所在。
(1) 我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。《MIT Sloan管理评论》杂志刊登过一篇论文，分析了对于公司构建高质量产品方面有帮助的软件开发实践1。该论文总结了很多对于最终系统质量有重要影响的实践。其中一个实践表明，尽早交付具有部分功能的系统和系统质量之间具有很强的相关性。该论文指出，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。该论文的另一项发现是，以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。
敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功能的系统。然后，我们努力坚持每几周就交付一个功能渐增的系统。如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产品中。或者，他们可以只是选择再检查一遍已有的功能，并指出他们想要做的改变。
(2) 我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竞争优势。这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好事情，因为那些改变意味着团队已经学到了更多如何满足客户需要的知识。
敏捷团队会非常努力地保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。在本书的后面部分，我们会学习一些面向对象设计的原则、模式和实践，这些内容会帮助我们维持这种灵活性。
(3) 经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。我们交付可以工作的软件，并且尽早地、经常性地交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真正要交付的东西。我们关注的目标是交付满足客户需要的软件。
(4) 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。为了能够以敏捷的方式进行项目的开发，客户、开发人员以及利益相关者之间就必须要进行有意义的、频繁的交互。软件项目不像发射出去就能够自动导航的武器，必须要对软件项目持续不断地进行引导。
(5) 依靠斗志高昂的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。人是项目取得成功的最重要的因素。所有其他的因素（过程、环境、管理等）都被认为是次要的，当它们对人有负面的影响时，就要对它们进行改变。
(6) 在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。在敏捷项目中，人们之间相互交谈。首要的沟通方式就是人与人之间的交互。书面文档会按照和软件一样的时间安排进行编写和更新，但是仅在需要时才这样做。
(7) 可以工作的软件是进度主要的度量标准。敏捷项目通过度量当前满足客户需求的软件量来度量开发进度。他们不是根据所处的开发阶段、已经编写的文档总量或者已经创建的基础设施代码的数量来度量开发进度。仅当30%的必需功能可以工作时，才可以确定进度完成了30%。
(8) 敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。敏捷项目不是50米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。
跑得过快会导致团队精力耗尽、抄捷径以致崩溃。敏捷团队会测量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以保证在整个项目开发期间保持最高质量标准的速度上。
(9) 对卓越技术和良好设计的不断追求有助于提高敏捷性。高的产品质量是获取高的开发速度的关键。保持软件尽可能干净、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱，就会在今天把混乱清理干净。
(10) 简单——尽量减少工作量的艺术是至关重要的。敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫。相反，他们在今天以最高的质量完成最简单的工作，并深信如果在明天发生了问题，也会很容易进行处理。
(11) 最好的构架、需求和设计都源自自我组织的团队。敏捷团队是自我组织的团队。责任不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定履行职责的最好方法。
敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与权力。不存在某个团队成员仅对系统构架、需求或者测试负责的情况。整个团队共同承担那些职责，每一个团队成员都能够影响它们。
(12) 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。敏捷团队会不断地对团队的组织方式、规则、约定和关系等进行调整。敏捷团队知道团队所处的环境在不断地变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。
1“Product-Development Practices That Work: How Internet Companies Build Software”MIT Sloan Management Review, Winter 2001, reprint number 4226。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。