超越敏捷:为什么「价值」才是你的加速器?

| 2022-04-27

即使在我过去 20 年共事过的健康 IT 组织中,业务领导者也普遍存在一种常见的挫败感:软件交付速度太慢。这一观察得到了2019年的「DevOps 状态报告」的支持,其中 75% 的受访者将「加速软件交付」列为他们期望的敏捷采用结果。

每个人都希望交付更多、更快的产品。但是怎么做?

答案是:「采用敏捷方法」本身并不能保证成功,或者加速交付。而是要「关注价值」。

评估您的关注点:价值驱动的开发

构建任何产品的一个最大挑战是:退后一步,考虑目标是什么,然后围绕这些期望的结果进行构建。这一直是敏捷软件开发的承诺,但是,「声称自己的组织是一个敏捷组织」已不再是一个卖点。许多 IT 企业声称他们是敏捷组织。许多人做错了。

这些出错的组织,它们并没有将「敏捷」用作指导产品开发的指南针,而是将「敏捷」视为一组清单、便签、时间跟踪工具和流程。这些是工具箱,而不是一种心态。

这就是为什么所谓的「敏捷产品开发」经常失败的原因。

事实上,它可能一开始并不敏捷。但与其争论教条式的标签,或坚持一套规定的流程,更简单的方法是专注于定义价值,然后创造它。

我们把它称之为价值驱动开发:组织中的每个人——整个层次结构中的每个人——都应该专注于他们正在创造的价值。

大多数开发人员都擅长编写代码,但除非实现目标,否则代码本身并不能提供价值。

在价值驱动开发中定义价值

当然,「价值」的定义可能因人而异,因此在定义价值方面的组织一致性对于成功至关重要。这个过程需要坦诚的对话,但不必刻薄或痛苦。然而,它确实需要一种领导文化,该文化应接受商业计划可能并不完美,并且产品团队的健康怀疑分析几乎总能为各方带来更好的结果。

以下是一些有助于定义价值的问题:

  • 我们试图解决的问题或挑战是什么?
  • 解决问题的最简单和最快的解决方案是什么?
  • 这对我们的客户有用吗?我们如何验证我们正在构建的东西是正确的?
  • 对于我们的客户和我们的组织来说,实现价值的最短路径是什么?

很显然,这些问题全部来源于「持续交付2.0双环模型」的「价值探索环」。

回答完这些问题后,产品负责人的工作就是计划发布路线图,以最小的投入创造最大的价值。MVP(最小可行产品)这个词听起来好像总是有第二个版本。相反,价值驱动开发将 MVP 定义为您可以实施的最小变更增量,它将提供即时价值。完整的产品供应并不总是您想要或需要的,至少在最初是这样。

在确定一个特性的价值时,重要的是要考虑分析、数据和其他定量指标,而不是直觉、假设和其他定性观察。当然,这需要捕获真实的用户数据,然后对结果进行客观分析。

在每次迭代回顾会中,我都会包含图表和图表,其中包含基于使用某个功能的实际客户的数据——任何我可以用来展示其价值的东西。这是对开发人员的挑战:你正在开发此功能,弄清楚谁在使用它。这使我们能够通过调整价值和创造清晰度来确定每个功能的优先级。

以尽可能小的增量发布价值的方式消除浪费——不要开发你不需要的东西。当团队只专注于实现由验收标准定义的价值时,他们将做最少的工作来构建正确的东西。将此过程视为产品「虫洞」:它不是更快,而是让您更快地到达目的地。

通过价值驱动的焦点建立起「文化一致性」

定义了价值并建立了路线图,重要的是要授权产品团队中的个人保持相同的价值驱动的心态。例如,开发人员应该有这样的心态:「作为开发人员,我可以做些什么来发布价值?」, 而不是「我需要编写什么代码来满足我收到的这个设计?」。 有了这种心态,您你将让每个人都提出正确的问题,目标是将最大的精力花在对客户有价值的事情上,而在不重要的事情上花费最少的精力。

敏捷的一个常见反模式是:工作执行流程没有问题,但仍然会导致糟糕的解决方案。一个用户故事写出来后,产品负责人说,「这就是我认为应该的样子」,然后团队其它成员就开始照着他/她说的来构建它。而以价值驱动的开发时,你应该是:定义一个正确问题,找到解决该问题的最简单和最快的方法,然后与团队一起工作以产生最佳解决方案

这种环境创造了一种参与文化:团队中的每个人都在推动解决方案,而不是成为生产轮子中的齿轮。

加速发展的下一步

敏捷的失败在很大程度上可以归因于「应该如何实施」,以及更重要的是「为什么要实施」的误解。我们提倡价值驱动的开发方法的一个原因是,它很简单,也更简洁。通过问「为什么」来寻找价值;建立价值。它很敏捷,没有噪音。

正如我们所概述的,「为什么」通常是最重要的问题。这也是加速软件交付的完美起点。