敏捷宣言：四大核心价值观与十二项原则详解

下图来自敏捷宣言网站并展示了四个敏捷价值观声明。

Agile Manifesto and the 4 Agile Values answer what agility is

如你在价值观前言中所见，作者们表示他们正在探索开发软件和帮助他人的更好方式。所有价值观都很重要，但左侧的价值观优先于右侧。

以人为本，而非流程与工具

如前所述，当敏捷宣言发布时，它挑战了重型方法论。当时，能力成熟度模型（CMM）和ITIL是流程导向方法的流行趋势。

因此，这些思想领袖选择从人开始，令人惊讶。他们认为，找到团队中的合适人员（个人）并帮助他们有效协作（互动）远比遵循任何特定流程和/或使用特定工具更为重要。这就是为什么他们将重点放在左侧：个人与互动。

可工作的软件胜于详尽的文档

在传统或瀑布式软件开发中，团队会花费大量时间收集需求并设计和制定规范，直到生命周期后期才构建出可交付的成果。宣言的作者们认为，拥有一个可工作的解决方案，比拥有大量描述解决方案如何运作的文档更有价值。

客户协作胜于合同谈判

第三个价值观是客户协作胜于合同谈判——其中合同谈判指的是就范围内的内容进行争论。例如，你可能会听到类似“这不在你的需求文档中”的说法。这些思想领袖认为，与客户协作以交付他们真正需要的解决方案，远比其他任何事情都重要。

响应变化胜于遵循计划

第四个也是最后一个敏捷价值观是响应变化胜于遵循计划。作者们认同计划的重要性——事实上，敏捷团队做了大量计划。但这些思想领袖认为，应对不可避免的变化的能力，比坚持项目初期制定的计划（当时信息仍有限）更为关键。

宣言中的所有价值观都很重要，但左侧的价值观优先级高于右侧。

十二项敏捷原则

除了这四项敏捷价值观外，敏捷宣言的作者们还同意一组十二项敏捷原则，它们构成了敏捷工作方式的基础。尽管不如四项敏捷价值观广为人知，但我认为十二项敏捷原则更具实用性，并为敏捷实践提供了更清晰的指导。

12 Agile Principles behind the Agile Manifesto

为方便起见，我为这十二项原则编号了，尽管在官方网站.

  1. 第一条原则是最高优先级是通过尽早并持续交付有价值的软件来满足客户。短语“有价值的软件”让一些人感到困惑。请记住，在2001年，当这些思想领袖引入敏捷价值观和原则时，他们仅专注于软件开发。自那时起，敏捷已被几乎每个行业采纳——从建筑设计、汽车制造，到战斗机生产。如果你觉得更合理，可以用“有价值的解决方案”替代“有价值的软件”。
  2. 第二条原则是欢迎需求变更，即使在开发后期也是如此。虽然如今大多数人关注的是控制变更或管理“范围蔓延”，但现实是变更不可避免。敏捷流程推迟决策，缩短开发周期，并支持对需求的及时分析。这使得敏捷团队能够快速且低成本地适应变化。这带来了竞争优势，也是敏捷工作法的关键支柱之一。
  3. 第三条原则是频繁交付可工作的软件，时间从几周到几个月不等，最好采用较短的时间周期。频繁交付的主要好处之一是获得反馈，以确保你走在正确的道路上，并真正构建客户所需的内容。
  4. 第四条敏捷原则是关于业务人员与开发人员每日协作在整个项目过程中。如今，业务相关方常常编写需求文档，然后“扔过墙”给开发人员。数月甚至数年后，开发人员将解决方案交付给请求者进行最终测试——却发现解决方案被误解、错误构建，或已不再需要。这一原则的重点在于构建解决方案的人与使用解决方案的人之间的协作，以避免此类结果。
  5. 第五条敏捷原则是围绕有动力的个人构建项目，为他们提供所需的环境和支持，并信任他们完成工作。这本质上是一种三步方法：赋能人员、赋予他们自主权，并信任他们。
  6. 第六条敏捷原则倡导可持续发展。赞助方、开发人员和用户应能够无限期地保持稳定的工作节奏。当我刚开始从事技术项目时，项目通常持续6个月、12个月甚至更久。在最初的几个月里，往往进展甚微。毫不奇怪，这导致了项目末期出现巨大的工作压力，必须完成大量工作。团队成员被期望加班或在周末工作，以满足固定的时间和范围目标。这种项目被称为“死亡行军”项目。敏捷并非说你永远不会加班或周末工作，但它强调的是让每个人都以可持续的速度工作。
  7. 第七条原则是可工作的软件是衡量进展的主要标准。传统上，人们使用完成百分比来跟踪项目进展。完成百分比非常不可靠，因为很难判断，尤其是在达到80%或90%时。90%的完成度往往意味着仅剩下10%的工作量或时间。敏捷团队通过将工作分解为功能或特性，将其拆分为小块，并跟踪这些小块是否完成，从而避免使用完成百分比。这种方法避免了误导性的进度指标。
  8. 第八条原则是，向开发团队及其内部传递信息最有效且高效的方式是通过面对面交流。如今，最受欢迎的沟通工具可能是电子邮件。对发送者来说很高效——毕竟他们可以一次向数百甚至数千人发送消息。但这并非真正的沟通。研究表明，阅读他人的文字存在大量误解的空间。敏捷倡导者已经认识到，真正的共同理解需要将人们聚集在一起。如果无法面对面交流，就应使用带宽最高的沟通方式——这可能是视频或电话会议。这远胜于将文档发布到SharePoint！这里的要点是使用可用的最高带宽沟通渠道。偏爱面对面交流的一个副作用是，让同一敏捷团队的成员集中办公是有意义的。如今，许多组织却忽视了这一看似显而易见的要点。
  9. 第九条原则是持续关注技术卓越与良好设计以提升敏捷性。重点在于避免走捷径或积累技术债务。不要做那些短期内能加快进度但长期代价更高的事情。如果你不断积累技术债务，就会失去敏捷性。这在具有固定时间表的瀑布式项目中很常见。为了满足承诺的截止日期，常常会牺牲质量。测试周期可能被缩短或取消以节省时间，导致发布后生产环境中出现更多问题。这导致了频繁的紧急修复，以及难以维护的代码。
  10. 第十条原则是保持简单并消除不必要的工作。简单性——即最大化未完成工作量的艺术——至关重要。也就是说，我们应该审视我们的流程，消除任何对客户没有价值的内容，从而在仍能交付所需内容的前提下，最大化未完成的工作量。
  11. 第十条原则也涉及自组织团队。最佳的架构、需求和设计来自自组织团队。我们应该让最接近工作的人决定如何最好地完成它——这正是这一原则的核心。
  12. 最后一条原则，第12条，是关于回顾。团队定期反思如何变得更加高效，然后调整并适应相应地调整他们的行为。

敏捷的价值观和原则在今天看来可能并不显得激进，但当它们在2001年公布时，却是相当革命性的。因此有了“宣言”这一术语。它们描绘了一种与前一个世纪组织运作方式截然不同的工作方式。在此之前，软件开发在很大程度上模仿了工业时代的工作实践。理解这一历史背景至关重要，如下文所述。

 

 

Leave a Reply