| 2022-04-27
即使在我过去 20 年共事过的健康 IT 组织中，业务领导者也普遍存在一种常见的挫败感：软件交付速度太慢。这一观察得到了2019年的「DevOps 状态报告」的支持，其中 75% 的受访者将「加速软件交付」列为他们期望的敏捷采用结果。
每个人都希望交付更多、更快的产品。但是怎么做？
答案是：「采用敏捷方法」本身并不能保证成功，或者加速交付。而是要「关注价值」。
评估您的关注点：价值驱动的开发
构建任何产品的一个最大挑战是：退后一步，考虑目标是什么，然后围绕这些期望的结果进行构建。这一直是敏捷软件开发的承诺，但是，「声称自己的组织是一个敏捷组织」已不再是一个卖点。许多 IT 企业声称他们是敏捷组织。许多人做错了。
这些出错的组织，它们并没有将「敏捷」用作指导产品开发的指南针，而是将「敏捷」视为一组清单、便签、时间跟踪工具和流程。这些是工具箱，而不是一种心态。
这就是为什么所谓的「敏捷产品开发」经常失败的原因。
事实上，它可能一开始并不敏捷。但与其争论教条式的标签，或坚持一套规定的流程，更简单的方法是专注于定义价值，然后创造它。
我们把它称之为价值驱动开发：组织中的每个人——整个层次结构中的每个人——都应该专注于他们正在创造的价值。
大多数开发人员都擅长编写代码，但除非实现目标，否则代码本身并不能提供价值。
在价值驱动开发中定义价值
当然，「价值」的定义可能因人而异，因此在定义价值方面的组织一致性对于成功至关重要。这个过程需要坦诚的对话，但不必刻薄或痛苦。然而，它确实需要一种领导文化，该文化应接受商业计划可能并不完美，并且产品团队的健康怀疑分析几乎总能为各方带来更好的结果。
以下是一些有助于定义价值的问题：
- 我们试图解决的问题或挑战是什么？
- 解决问题的最简单和最快的解决方案是什么？
- 这对我们的客户有用吗？我们如何验证我们正在构建的东西是正确的？
- 对于我们的客户和我们的组织来说，实现价值的最短路径是什么？
很显然，这些问题全部来源于「持续交付2.0双环模型」的「价值探索环」。
回答完这些问题后，产品负责人的工作就是计划发布路线图，以最小的投入创造最大的价值。MVP（最小可行产品）这个词听起来好像总是有第二个版本。相反，价值驱动开发将 MVP 定义为您可以实施的最小变更增量，它将提供即时价值。完整的产品供应并不总是您想要或需要的，至少在最初是这样。
在确定一个特性的价值时，重要的是要考虑分析、数据和其他定量指标，而不是直觉、假设和其他定性观察。当然，这需要捕获真实的用户数据，然后对结果进行客观分析。
在每次迭代回顾会中，我都会包含图表和图表，其中包含基于使用某个功能的实际客户的数据——任何我可以用来展示其价值的东西。这是对开发人员的挑战：你正在开发此功能，弄清楚谁在使用它。这使我们能够通过调整价值和创造清晰度来确定每个功能的优先级。
以尽可能小的增量发布价值的方式消除浪费——不要开发你不需要的东西。当团队只专注于实现由验收标准定义的价值时，他们将做最少的工作来构建正确的东西。将此过程视为产品「虫洞」：它不是更快，而是让您更快地到达目的地。
通过价值驱动的焦点建立起「文化一致性」
定义了价值并建立了路线图，重要的是要授权产品团队中的个人保持相同的价值驱动的心态。例如，开发人员应该有这样的心态：「作为开发人员，我可以做些什么来发布价值？」， 而不是「我需要编写什么代码来满足我收到的这个设计？」。 有了这种心态，您你将让每个人都提出正确的问题，目标是将最大的精力花在对客户有价值的事情上，而在不重要的事情上花费最少的精力。
敏捷的一个常见反模式是：工作执行流程没有问题，但仍然会导致糟糕的解决方案。一个用户故事写出来后，产品负责人说，「这就是我认为应该的样子」，然后团队其它成员就开始照着他/她说的来构建它。而以价值驱动的开发时，你应该是：定义一个正确问题，找到解决该问题的最简单和最快的方法，然后与团队一起工作以产生最佳解决方案。
这种环境创造了一种参与文化：团队中的每个人都在推动解决方案，而不是成为生产轮子中的齿轮。
加速发展的下一步
敏捷的失败在很大程度上可以归因于「应该如何实施」，以及更重要的是「为什么要实施」的误解。我们提倡价值驱动的开发方法的一个原因是，它很简单，也更简洁。通过问「为什么」来寻找价值；建立价值。它很敏捷，没有噪音。
正如我们所概述的，「为什么」通常是最重要的问题。这也是加速软件交付的完美起点。