敏捷宣言十二条原则分别是什么

敏捷宣言在2001年发布，开头是四条价值观，随后列出十二条原则。十二条原则是价值观的展开，说明敏捷团队在日常工作中如何行动。本文按原文顺序给出十二条原则的完整清单和逐条主张，并说明它与价值观、Scrum等具体方法各自的定位。文中原则表述采用常见中文译法转述，便于对照理解。

要点总览（TL;DR）

• 敏捷宣言在2001年发布，四条价值观之后列出十二条原则，原则是价值观在日常工作中的展开。
• 十二条原则按原文顺序覆盖交付节奏、协作与团队、技术与持续改进三个方面，组合使用才形成完整机制。
• 原则属于行为准则层，不规定角色、会议、迭代长度或需求池字段，Scrum、看板等是原则的落地方式。
• 常见误解包括把原则当固定流程、把欢迎变化理解为没有计划、把自组织理解为没有管理，文中给出对应纠正方式。

十二条原则的完整清单与逐条主张

十二条原则在宣言中紧随四条价值观之后，按顺序排列，没有编号分组。每条原则用一段话表达一个主张，合起来覆盖交付节奏、协作方式、团队自主、技术标准和持续改进五个方面。下表按原文顺序列出常见中文译法的转述，并概括每条的核心主张。

序号	原则表述（常见中文译法转述）	核心主张
1	我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。	把尽早交付客户认可的价值放在最高优先级。
2	欣然面对需求变化，即使在开发后期也一样。敏捷流程善于利用变化来为客户创造竞争优势。	把需求变化视为机会，而非需要抵制的干扰。
3	经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。	用短周期、高频率的交付保持反馈循环。
4	业务人员和开发人员必须相互合作，项目中的每一天都不例外。	业务与开发保持日常协作，而非阶段性交接。
5	激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。	围绕有动力的人组织工作，并给予环境与信任。
6	不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。	优先选择信息损耗最小的沟通方式。
7	可工作的软件是进度的首要度量标准。	用交付成果而非文档或工时衡量进展。
8	敏捷流程倡导可持续开发。发起人、开发者和用户应能长期维持稳定的节奏。	保持可持续的工作强度，避免短期冲刺透支。
9	持续关注技术卓越和良好设计，敏捷能力由此增强。	技术质量是保持敏捷的前提，而非可选项。
10	以简洁为本，它是极力减少不必要工作量的艺术。	减少不必要的工作和产出，保留必要部分。
11	最好的架构、需求和设计出自自组织团队。	让团队自行决定如何完成工作。
12	团队定期反思如何能提高成效，并相应地调整自身的行为。	通过定期反思和调整持续改进工作方式。

逐条阅读时，可以注意原则之间的呼应关系。第1条和第3条都指向交付节奏，第2条为变化留出空间，第7条给出衡量进展的尺度；第4条到第6条围绕人与沟通展开；第8条到第10条关注节奏、质量与精简；第11条和第12条把决定权和改进权交给团队本身。这种排列没有严格的分段标题，但内容上形成了从交付到协作、再到团队自我改进的递进。

敏捷宣言十二条原则的范围与边界

十二条原则出自2001年发布的《敏捷软件开发宣言》，与四条价值观同属一份篇幅很短的文本。价值观给出四条方向性判断，原则则把这些判断展开为团队日常可以对照的行为准则。两者合起来构成敏捷的思想基础，而不是一套操作规范。

从约束范围看，十二条原则规定的是价值取向和行为取向，例如优先交付可用成果、保持日常协作、维持可持续节奏。它不规定团队必须设哪些角色、开哪些会议、用哪些文档模板，也不规定迭代长度或需求池的字段结构。同一个团队可以在不改变原则取向的前提下，采用不同的流程安排。

需要区分的是，原则本身不涵盖迭代管理的操作细节，例如迭代规划如何开、评审和回顾如何组织、迭代目标如何设定；也不涵盖需求池管理的内容，例如需求条目如何拆分、优先级如何排序、需求状态如何流转。这些属于具体实践层面的主题，原则只提供判断依据，具体做法需要结合团队情况另行设计。把十二条原则直接当作流程手册使用，容易产生“照着原则开会”的形式化问题。

十二条原则如何组成一套工作机制

十二条原则单独看是十二条主张，放在一起则构成一套相互支撑的机制。可以按它们回答的问题分成三组：交付节奏回答“多久交付一次、如何对待变化”，协作与团队回答“谁在一起工作、如何沟通和决策”，技术与改进回答“靠什么保持长期交付能力”。

分组	包含原则	回答的问题
交付节奏	第1、2、3、7条	交付多早、多频繁，变化如何处理，用什么衡量进展
协作与团队	第4、5、6、11条	业务与开发如何配合，团队如何获得动力、沟通和决策权
技术与持续改进	第8、9、10、12条	如何保持可持续节奏、技术质量和精简，如何持续调整

三组之间存在明确的支撑关系。短周期交付要求业务与开发日常协作，否则需求理解偏差会在每个周期被放大；日常协作又依赖面对面的沟通和团队的自组织决策，否则协作会退化为层层审批。反过来，可持续节奏和技术卓越是短周期交付能够长期维持的条件：如果每个周期都靠加班赶工、靠堆积技术债务换速度，交付频率迟早会下降。第12条的定期反思则把上述做法串成闭环，团队在每个周期结束后检视哪些环节偏离了原则，并调整下一周期的做法。

这种结构说明，十二条原则不能只挑其中几条执行。只强调频繁交付而忽略技术卓越，短期见效、长期失速；只强调自组织而忽略定期反思，团队自主容易变成各自为政。原则的价值在于组合使用。

十二条原则与四条价值观、敏捷方法的关系

价值观、原则、方法、实践构成四个层次，越往下越具体，可替换性越强。理解这个层次，有助于判断某条做法改变时，是否触及了敏捷的核心。

层次	内容	作用	可调整程度
价值观	四条价值观，如“个体和互动高于流程和工具”	给出方向性判断，说明什么更重要	低，属于敏捷的基本立场
原则	十二条原则	把价值观展开为可对照的行为准则	低，跨框架通用
方法	Scrum、看板、极限编程等框架	提供角色、事件、工件等结构性安排	中，可按团队情况选择
实践	每日站会、迭代评审、看板列设置、需求拆分方式等	具体执行动作	高，可随团队调整

价值观与原则的关系是方向与展开：价值观说“个体和互动高于流程和工具”，原则第4条到第6条就具体说明业务与开发要日常协作、要以有动力的人为核心、要优先面对面沟通。原则与方法的关系是通用与落地：十二条原则不绑定任何具体框架，Scrum用迭代、角色和事件来承载这些原则，看板用可视化流程和限制在制品数量来承载，极限编程用结对编程和测试驱动开发来承载。选择哪种方法，取决于团队的工作性质和约束条件。

原则与迭代管理、需求池管理的区别也在这个层次上。迭代管理关注一个迭代从规划到回顾的完整操作，需求池管理关注需求条目的收集、拆分和排序，两者都属于方法与实践层。原则为这些操作提供判断标准，例如“经常交付可工作的软件”会影响迭代长度的选择，“以简洁为本”会影响需求拆分的粒度，但原则本身不规定这些操作的具体步骤。

当团队把原则落到日常协作时，需要工具承载需求、任务和迭代的流转。ONES可以在同一平台管理需求条目、任务分配和迭代进度，让业务与开发围绕同一份工作项协作，也便于在迭代结束后回看交付情况。工具承载的是协作动作，原则的判断仍由团队自己做出。

具体例子与常见误解

以下场景为演示性质，用来说明多条原则如何在同一个团队中同时体现。某产品团队把交付周期定为两周，每个周期结束时向客户交付一个可用的功能增量。周期中途客户提出一项需求调整，团队评估后把它纳入下一个周期的候选范围，并在当期与客户确认了替代方案。业务人员每天参加团队的短会，当场澄清需求细节；团队自行决定任务如何拆分、由谁负责，技术负责人只在架构争议时提供意见。周期结束后，团队用实际交付的功能清单向客户汇报进展，并花半小时讨论本期哪些环节可以改进。

这个场景中，两周交付对应第3条，需求调整的处理对应第2条，业务人员每日参与对应第4条，团队自行拆分任务对应第11条，用功能清单汇报对应第7条，周期末的讨论对应第12条。多条原则在同一段工作里自然发生，没有额外的仪式。

常见误解主要有三类，纠正方式如下：

• 把原则当成固定流程。有人认为十二条原则规定了必须开哪些会、设哪些角色。原则只给行为准则，会议和角色属于方法层的设计，团队可以按需增减。纠正方式是把每条原则翻译成“我们团队用什么做法来体现它”，而不是“我们必须执行哪个动作”。
• 把欢迎变化理解为没有计划。第2条欢迎变化，前提是团队有稳定的交付节奏和清晰的价值判断，才能评估一项变化是否值得纳入。没有计划的团队无法判断变化的代价。纠正方式是保留周期目标和优先级排序，把变化放进明确的评估入口，而不是随时打断当前工作。
• 把自组织团队理解为没有管理。第11条说最好的架构、需求和设计出自自组织团队，指的是团队对如何完成工作有决定权，同时要对结果负责。管理者仍然需要提供目标、资源和边界。纠正方式是把管理动作从分配任务转为明确目标和清除障碍，让团队在边界内自主安排。

理解十二条原则的准确内容与边界，比记住某一种流程更重要。团队可以据此检视自己的做法：交付是否足够早、协作是否足够直接、节奏是否可持续、改进是否有固定入口。原则提供的是判断依据，具体流程由团队结合自身情况设计。

常见问题

十二条原则有官方统一的中文译本吗？引用时要注意什么？

敏捷宣言原文为英文，中文表述存在多种译法，用词略有差异。引用时建议注明所依据的译本或说明为常见中文译法转述，避免把某一译法当作唯一标准原文。若用于正式文档或培训材料，可对照宣言发布方的英文原文核对关键措辞，尤其是“可工作的软件”“自组织团队”等核心概念。

团队规模很小，十二条原则是否都适用？

十二条原则面向的是敏捷团队的一般行为取向，没有规定团队规模门槛。小团队在面对面沟通、自组织决策上往往更容易做到，但在可持续节奏、技术卓越、定期反思上同样需要刻意安排。实际落地时可以把每条原则翻译成适合自身规模的具体做法，例如小团队用每日短会替代正式会议，用共享文档记录反思结论。

已经采用Scrum的团队，还需要单独对照十二条原则吗？

需要。Scrum提供了角色、事件和工件等结构性安排，属于方法层；十二条原则提供判断标准，用于检视这些安排是否真正服务于交付价值、协作和持续改进。团队可以定期对照原则检查：迭代是否真的产出了可用增量、业务与开发是否日常协作、技术质量是否被持续关注。原则帮助团队发现“流程做了、效果没到”的情况。

把原则落到日常协作时，工具能起什么作用？

工具承载的是协作动作，例如需求条目、任务分配、迭代进度和交付记录的集中管理，让业务与开发围绕同一份工作项沟通，也便于周期结束后回看实际交付情况。ONES可以在同一平台管理需求、任务和迭代进度，为这些协作动作提供承载。原则的判断仍由团队自己做出，工具不替代团队对优先级、变化取舍和改进方向的决策。

十二条原则和四条价值观冲突时以哪个为准？

两者是方向与展开的关系，通常不构成冲突。价值观给出方向性判断，原则把这些判断展开为可对照的行为准则。如果团队在实践中感到某条原则的做法与价值观取向不一致，更可能是具体做法设计有问题，而不是两者本身矛盾。此时应回到价值观检视做法，例如“个体和互动高于流程和工具”提示团队检查是否让流程压过了协作本身。