本文共 6551 字，大约阅读时间需要 21 分钟。

《敏捷宣言》详述了4项价值观和12条原则

它是一项声明，旨在改善软件开发方法，并直接应对传统开发流程的低效率（传统的软件开发流程更依赖于重要的文档和监督管理的方式）。

虽然原始文档专门旨在帮助软件开发人员以更快，更高效的方式构建业务解决方案，但它对更广泛的开发行业及其他行业产生了巨大影响。

敏捷宣言中的四个敏捷价值观

• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.

• Customer collaboration over contract negotiation.

• Responding to change over following a plan.

• 在流程和工具上的个人和交互：敏捷在流程甚至工具上更加重视人员。人们响应业务需求并驱动开发过程。就其本质而言，过程和工具对变更的响应能力较弱，并且可能无法满足客户需求。
• 通过全面的文档工作软件：文档需要时间。这是敏捷争论的一个较慢的过程的一部分。从技术要求到测试计划和其他规范的每个文档都需要获得批准。这延迟了开发。敏捷是关于精简，而不是消除文档。尽管文档具有其价值，但在敏捷的思维方式中，最重要的是软件。
• 客户通过合同协商进行协作：客户和产品经理必须制定交货细节，但要倡导协作，而不是协商此过程。例如，在传统的项目管理方法中，客户在工作开始之前就详细协商产品的需求。但是，在项目的整个生命周期中，敏捷都将客户包括在内，以获取他们的持续反馈。
• 响应计划中的变更：变更发生时，在使用传统的项目管理方法时应尽可能避免。但是，敏捷在称为Sprint的短迭代中起作用，因为它们的简洁性可以进行更改，甚至可以将其作为改进项目和增加价值的一种方式。

Value 1 – Individuals and Interactions over processes and tools

While processes and tools will likely be necessary, we should try to focus attention on the individuals and interactions involved. This is because work is undertaken by people, not tools, and problems get solved by people, not processes. Likewise, products are accepted by people, scope is debated by people, and the definition of a successfully “done” project is negotiated by people.

What will help set up a project for success is an early focus on developing the individuals involved and an emphasis on productive and effective interactions. Processes and tools can help, yet projects are ultimately about people. So, to be successful, we need to spend the majority of our time in what may be the less comfortable, messy, and unpredictable world of people.

虽然过程和工具可能是必要的，但我们应该尽量把注意力集中在所涉及的个人和互动上。这是因为工作是由人来承担的，而不是工具，问题是由人来解决的，而不是由过程来解决的。同样地，产品被人们接受，范围被人们争论，一个成功的“完成”项目的定义被人们协商。

有助于建立一个成功的项目的是一个早期的重点发展个人参与和强调生产和有效的互动。过程和工具可以提供帮助，但项目最终还是与人有关。所以，要想成功，我们需要把大部分时间花在一个不那么舒适、混乱和不可预测的世界里。

Value 2 – Working software over comprehensive documentation

This value speaks to the need to deliver. It reminds us to focus on the purpose or business value we’re trying to deliver, rather than on paperwork.

Many developers are detail-oriented and process-driven. While these characteristics are often highly beneficial, they can also mean the developer’s focus is easily distracted from the real reason they are undertaking software projects—to write valuable software. So, this emphasis on valuing working software over comprehensive documentation acts as a useful reminder of why these projects are commissioned in the first place—to build something useful. Documentation by itself, or at the expense of working software, is not useful.

这个价值观说明了交付的必要性。它提醒我们要把注意力放在我们试图实现的目标或商业价值上，而不是放在文书工作上。

许多开发人员都是面向细节和过程驱动的。虽然这些特性通常是非常有益的，但它们也意味着开发人员的注意力很容易从他们从事软件项目以编写有价值的软件的真正原因上分散。因此，这种重视工作软件而不是综合文档的做法，是一个有用的提醒，提醒我们为什么这些项目首先是为了构建有用的东西而被委托的。文档本身或以牺牲工作软件为代价是没有用的。

Value 3 – Customer collaboration over contract negotiation

We need to be flexible and accommodating rather than fixed and uncooperative. This involves tradeoffs between the development team and business rather than reverting back to contracts and statements of work. We could build the product exactly as originally specified, but if the customer’s preferences or priorities change, it would be better to be flexible and work toward the new goal.

It is difficult to define an up-front, unchanging view of what should be built. This challenge stems from the dynamic nature of knowledge work products, especially software systems. Software is intangible and difficult to reference: companies rarely build the same systems twice, business needs change quickly, and technology changes rapidly.

We should recognize at the start that things are going to change, and we’ll need to work with the customer throughout the project to reach a shared definition of “done.” This requires a more trusting relationship and more flexible contract models than we often see on projects.

我们需要灵活和通融，而不是固执己见和不合作。这涉及到开发团队和业务之间的权衡，而不是回到合同和工作说明书。我们可以完全按照最初指定的方式构建产品，但是如果客户的偏好或优先级发生了变化，那么最好灵活一些，朝着新的目标努力。

很难预先确定一个应该建立什么样的、不变的观点。这一挑战源于知识工作产品，特别是软件系统的动态特性。软件是无形的，很难参考：公司很少两次构建同一个系统，业务需求变化很快，技术变化很快。

我们应该在一开始就认识到事情会发生变化，我们需要在整个项目中与客户合作，以达成“完成”的共同定义。这需要一种比我们在项目中经常看到的更信任的关系和更灵活的合同模式。

Value 4 – Responding to change over following a plan

The quote from scholar Alfred Korzybski, “The map is not the territory,” warns us not to follow maps if they do not match the surroundings. Instead, trust what you see and act accordingly.

In modern, complex projects, we know our initial plans will likely be inadequate. They are based on insufficient information about what it will take to complete the project.

Agile projects have highly visible queues of work and plans in the form of release maps, backlogs, and task boards. The intent of this value is to broaden the number of people who can be readily engaged in the planning process by adjusting the plans and discussing the impact of changes.

学者Alfred Korzybski的名言“地图不是领土”，警告我们，如果地图与周围环境不符，就不要跟着地图走。相反，相信你所看到的，并采取相应的行动。

在现代、复杂的项目中，我们知道我们最初的计划可能是不够的。他们所依据的是关于完成这个项目需要什么的信息不足。

敏捷项目具有高度可见的工作和计划队列，其形式为发布图、积压工作和任务板。这一价值观的目的是通过调整计划和讨论变化的影响来扩大参与规划过程的人数。

Individuals and interactions over process and tools: Agile places more importance on people over process and even tools. People respond to business needs and drive the development process. Process and tools by their very nature are less responsive to change and can be unable to meet customer needs.

Working software over comprehensive documentation: Documentation takes time. It’s part of a slower process that agile is arguing against. Each piece of documentation, from technical requirements to testing plans and other specifications, requires approval. This delays development. Agile is about streamlining, not eliminating documentation. While documentation has its value, in the agile mindset, it is software that is paramount.

Customer collaboration over contract negotiation: Customers and product managers must work out the details of delivery, but rather than negotiate this process, agile champions collaboration. For example, in traditional project management methodologies, customers negotiate the requirements for the product in detail—before work starts. However, agile includes the customer throughout the life cycle of the project for their continual feedback.

Responding to changes over following a plan: While change happens, it’s to be avoided as much as possible when working a traditional project management methodology. However, agile works in short iterations called sprints, because their brevity allows for changes, even embraces them as a way to improve a project and add value.

转载地址：http://cxvdi.baihongyu.com/