敏捷软件开发宣言——4 个价值观和 12 条原则

Table of Contents hide
1 宣言中的 4 个敏捷价值观
2 12 条敏捷原则

让我们仔细看看敏捷宣言背后的 4 个敏捷价值声明和 12 条原则。

宣言中的 4 个敏捷价值观

下图来自敏捷宣言网站，显示了四个敏捷价值声明。

敏捷宣言和 4 个敏捷价值观回答了什么是敏捷

正如您在价值观的序言中看到的那样，作者表示他们正在发现更好的方法来开发软件并帮助他人。所有的值都很重要，但左边的项目比右边的项目更重要。

个人和交互胜过流程和工具

如前所述，当敏捷宣言发布时，推动了重量级的方法论。能力成熟度模型（Capability Maturity Model）和 ITIL 就是当时流行的流程化趋势。

因此，令人惊讶的是，这些思想领袖决定从人开始。他们认为在团队中找到合适的人（个人）并帮助他们一起工作（互动）比遵循任何特定流程和/或使用特定工具重要得多。所以他们把优先事项放在左边，个人和互动。

工作软件优于综合文档

在软件开发的传统或瀑布方法中，团队会花费大量时间收集需求并开发设计和规范，直到生命周期的后期才真正构建某些东西。宣言的作者认为，获得一个有效的解决方案比拥有一堆描述解决方案如何工作的书更重要。

合同谈判中的客户协作

第三个价值是客户协作而不是合同谈判，在这种情况下，合同谈判意味着争论范围内包含的内容，例如，您可能会听到短语“这不是您在需求文档中提出的内容”，这就是合同谈判。这些思想领袖认为与我们的客户合作以获得他们需要的解决方案更为重要。

响应变化而不是遵循计划

第四个也是最后一个敏捷价值是响应变化而不是遵循计划。作者同意计划很重要，事实上，敏捷团队实际上做了很多计划。只是这些思想领袖认为，能够对不可避免的变化做出反应比遵循在项目开始时制定的计划更重要，而此时您的信息很少

宣言中的所有这些值都很重要，但左侧的那些项目比右侧的项目具有更高的优先级。

12 条敏捷原则

除了这 4 个敏捷价值观之外，敏捷宣言的作者还同意了一组12 条敏捷原则，这些原则是敏捷工作方式的基础。虽然不如 4 条敏捷价值观广为人知，但我发现 12 条敏捷原则更有用，并且为敏捷工作方式提供了更多指导。

敏捷宣言背后的 12 条敏捷原则

为方便起见，我对 12 条原则进行了编号，但在网站上它们只是没有编号。

  1. 第一个原则是最优先的原则是通过早期和持续交付有价值的软件来满足客户。“有价值的软件”这个词困扰着一些人。请记住，2001 年，当这些思想领袖提出敏捷价值观和原则时，他们只考虑软件开发。从那时起，几乎所有行业都引入了敏捷，包括建筑、汽车装配，甚至喷气式战斗机的制造。如果它对您更有意义，请将“有价值的解决方案”替换为有价值的软件。
  2. 第二个原则是即使在开发后期也欢迎不断变化的需求。在撰写本文时，大多数人都专注于控制变更或管理“范围蔓延”。 现实是，改变是不可避免的。敏捷流程推迟决策，缩短开发周期，并支持对请求的及时分析。这允许敏捷团队以低成本快速更改。这提供了竞争优势，并且是敏捷工作方式的关键之一。
  3. 第三个原则是频繁地交付可工作的软件，从几周到几个月不等，并且倾向于更短的时间范围。频繁交付的主要好处之一是获得反馈以确保您走在正确的轨道上，以确保您实际上正在构建客户需要的解决方案。
  4. 第四个敏捷原则是关于业务人员和开发人员在整个项目中每天一起工作。在撰写本文时，业务人员通常会创建需求文档并将其“扔到墙上”给开发人员。经过数月或数年的努力，开发人员会将其透露给请求者进行最终测试，然后才知道该解决方案的表述有误、构建不当或不再需要。这些原则的重点是针对构建者和使用解决方案的人进行协作以避免这些结果。
  5. 第五个敏捷原则是围绕积极进取的个人构建项目，为他们提供所需的环境和支持，并相信他们能够完成工作。这实际上是一个 3 部分——它是关于让人们有动力，赋予他们权力并信任他们。
  6. 第六个敏捷原则，敏捷流程促进可持续发展。赞助商的开发者和用户应该能够无限期地保持恒定的步伐。 回到我刚开始从事技术项目时，它们可能长达 6 个月或 12 个月或更长时间。在第一个月或两个月内完成很少的工作是很常见的。毫不奇怪，这导致了最后的巨大紧缩，必须完成大量工作。团队成员需要在晚上或周末工作，以按固定范围和固定时间表完成任务。这被称为死亡行军计划。 敏捷并不是说你永远不必在晚上或周末工作。它只是说每个人都应该以可持续的速度工作。
  7. 原则七是工作软件是进度的主要衡量标准。传统上，完成百分比用于衡量项目的进度。完成百分比非常不可靠，因为人们很难确定百分比，尤其是当它达到 80% 或 90% 时。很少有 90% 的完成意味着只剩下 10% 的努力或时间。 敏捷团队不是使用完成百分比，而是将工作分解为特性或功能，将它们分解成小块，然后再构建成小块。他们跟踪这些小块是否完成并避免完成百分比。
  8. 第八个是向开发团队和在开发团队内部传达信息的最有效和最有效的方法是面对面的交谈。当今最流行的通信工具可能是电子邮件。这对发件人来说是有效的——毕竟，他们可以同时向数百或数千人发送信息。然而，这不是真正的交流。 事实证明，当我们阅读其他人的作品时，会有很大的误解空间。敏捷支持者已经了解到，为了真正的共享理解，必须将人们聚集在一起。如果无法面对面，请使用可用的最高带宽通信形式。那可能会变成视频会议或电话会议。这仍然比将文档发布到 SharePoint 好得多！此处的指导是使用您可用的最高带宽通信渠道。 偏好面对面交流的一个副作用是，将同一敏捷团队中的人员放在一起才有意义。如今，许多组织忽略了似乎是常识的事情。
  9. 第九条敏捷原则是持续关注技术卓越，良好的设计可以增强敏捷性。重点是避免建立技术债务的捷径或技术。不要做一些在短期内让它变得更快的事情，或者减少一些步骤，但从长远来看这实际上成本更高。如果您继续积累技术债务，您将不会有太多的敏捷性！ 这在使用固定期限的瀑布式开发的项目中很常见。为了达到承诺的日期，角落被削减了。可以减少或消除测试周期以节省时间。这意味着在上线日期后的后期生产中会出现更多问题。其中设置了灭火和难以维护的代码。
  10. 原则 10 是关于保持简单并消除不必要的工作。简单性——最大化未完成工作量的艺术——是必不可少的。也就是说，我们应该审视我们的流程并消除任何对客户没有价值的东西，从而最大限度地提高未完成的工作，同时仍提供所需的内容
    原则 10 是关于自组织团队。最好的架构、需求和设计来自自组织的团队。 我们应该让最接近工作的人决定如何最好地完成它，这是这一原则的精髓。
  11. 最后，第 12 条原则是关于回顾的。团队定期反思如何变得更有效，然后相应地调整和调整其行为。

敏捷价值观和原则今天可能看起来并不激进，但当它们在 2001 年宣布时，它们就有些激进了。因此有了“宣言”一词。他们概述了一种与组织在上个世纪学会的工作方式截然不同的工作方式。在那之前，软件开发主要是模仿工业时代开发的工作实践。如下所述，了解这一历史背景非常重要。