《价值流动》从项目到产品: 到底是什么应该流经软件价值流？| IDCF

译者：无敌哥

原文地址: https://www.tasktop.com/blog/what-flows-through-a-software-value-stream/ 本文翻译仅供学习交流之用。

原文作者 Mik Kersten 出版了《Project to Product》

本系列共四篇文章，分别是

• 01 从项目到产品：软件需要从物理产品交付中学到什么？| IDCF（点击查看）

• 02 《价值流动》从项目到产品：生产线类比的终结 | IDCF（点击查看）

• 03 《价值流动》从项目到产品：到底是什么应该流经软件价值流？| IDCF

• 04 《价值流动》从项目到产品：软件时代需要价值流架构师 | IDCF 

  在本系列文章中，我探讨了我们如何需要将同样的严格性引入到软件交付价值流的设计中，正如我们在先进的制造工厂所看到的那样。一旦我们就流动的内容达成一致，我们就可以分析这些流动，以确定瓶颈和消除它们的机会。然而，每当我问一个高管级别的 IT 领导，他或她的瓶颈在哪里，我都会得到一个空洞的凝视或一个模糊的答案，尽管在其他方面来说，他们都是非常有能力的人。

  要在生产系统中寻找瓶颈，首先我们必须了解流经该系统的内容。我们已经看到了许多软件交付流的度量，包括代码行(LOC)、功能点、工作项、故事点、部署和发布。每个度量都从不同的角度捕获了价值流的概念，但是每个度量都有其局限性，特别是当您考虑端到端业务价值流时。

  以我与 IT 领导人的交谈经验来说，从商业角度来看，我们对于什么流经软件价值流这个核心问题没有足够的共识。然而，如果我们要将精益原则应用于软件交付，这应该是需要回答的最基本的问题。

  这种缺乏一致意见的情况意味着，绝大多数企业 IT 组织没有一个定义良好的生产力度量标准来衡量软件生产过程中的流程。相比之下，汽车行业生产的汽车数量是衡量汽车价值流的一个明确指标。

  另一个衡量标准是生命周期利润，这是 Donald Reinertsen 在他的开创性著作《The Principles of Product Development Flow》中提出的。诸如 LOC 和每天部署的数量之类的度量属于这一类，因为它们是交付给软件消费者的价值的代表物，而不是该价值的直接表示。例如，一行代码的更改所产生的价值没准相当于1,000行代码的更改。但是，如果没有一个明确的协议，什么是流动的，什么是生产单位，我们就远远没有实现任何像Reinertsen建议的生命周期利润衡量。

  商业领袖看到生产力时就知道它的价值，例如，通过能让市场买单的产品，或者通过比其他产品更快获得收入的产品。但是，将开发活动与这些结果联系起来更像是一种不透明的艺术，而不是一种有纪律的活动。要在价值流中定义生产力，以及瓶颈在哪里，我们必须首先定义流动的是什么。

  四大流动工作项

• 为了定义流，我们可以回到精益思维的第一原则，这些原则推动了大规模生产的改进。精益思维首先考虑的不是我们生产什么，而是客户拉动的价值。如果我们回想一下早期的软件时代，公司把安装 CD 放在包装盒里，我们可以试着把它比作汽车生产，定义软件生产的是盒子，或许也可以把这个比喻延伸到当前DevOps 世界里的发布。但是这样的类比，在现在来看是站不住脚的，在云计算和软件即服务的时代，这种类比变得更加无关紧要，因为发布是如此频繁和自动化，以至于用户都看不到它们。如果不是消费者拉动发布，他们拉动的是什么样的价值单元？

  要拉动价值，客户必须能够看到这种价值，并愿意为它交换东西。他们可以交换金钱或者时间。譬如社交媒体工具，一些间接的和基于广告的盈利产品，他们可以交换使用产品的时间。想想上一次你从一个产品中获得新的价值，或者重新使用一个你已经有一段时间没有使用的产品是什么时候。是什么引发了你们在时间和金钱上的价值交换？很有可能这是一个新的特性，它满足了你的需求或者在某种程度上让你感到高兴。或者，它可能是一个缺陷的修复，在价值交互发生之前，阻止了你继续使用这个产品。这就是定义什么流经软件价值流的关键所在。如果客户所需要的是新特性和缺陷修复，那么这些必须成为流程的一部分。

  如果我们将特性增加和缺陷修复作为生产单元，也就是流中的工作项，那么我们就可以将价值流中所有人员和团队的工作描述，应用于其中一个单元。如果对组织中的每一个过程和工具都有充分的了解，我们就可以确定有多少设计师、开发人员、管理人员、测试人员和Helpdesk专员参与了特定功能的创建、部署和支持。对于缺陷修复也是一样的。但这是价值流中唯一的工作吗？

  在对308个工具链的分析中，我和我的同事们发现了另外两种工作，这两种工作对于用户来说是不可见的，并且是由不同类型的利益相关者在价值流中拉动的。这包括必须由业务分析人员定义的安全性、规范性和合规性工作，这些工作安排在备份日志开发、实现、测试、部署和维护中。这些工作与特性和缺陷竞争优先权。它不会被客户拉走，因为通常等到客户发现的时候已经太晚了。例如，一次安全事故会导致一系列安全缺陷得到修复，并增加了安全特性，但已经发生了。这项工作是由组织内部牵引的，如由首席风险官及其团队牵引。

  我们观察到的第四类工作是减少技术债务。技术债务的概念是由 Ward cunningham 提出的，它描述了对软件和基础设施代码库进行修缮工作的必要性，如果不这样做，将导致今后修改或维护该代码的能力下降。例如，对特性交付的关注可能导致大量的技术债务积累；在没有足够自动化的情况下扩展操作环境可能会导致基础设施债务。如果不努力减少这些债务，它可能会阻碍未来功能交付能力-----例如，使软件架构过于复杂以至于无法进行创新。这项工作往往是由软件架构师完成的。

  

  表1总结了四个流程项目

  在分析308个工具链时，我们发现了大量不同类型的工作项，这些工作项被定义为敏捷工具、软件生命周期管理工具或 DevOps 工具，每个都对应着一些交付工作。一些组织使用了详细的敏捷分类法。Scaled Agile Framework (SAFe)提供了一种这样的分类方法，可以对流经价值流的工作类型进行细致的区分。其他组织使用更多的临时方法，创建自己的工作项目分类，如需求和缺陷。在某些情况下，这些方法导致了几十种缺陷类型。

  无论采用何种方法，当我们通过客户拉动的视角来看待时，我们都可以将所有类型的工作划分为表1中的四个流动项。这些流程项遵循 MECE 原则（金字塔原理）: 它们是相互排斥的，完全详尽的。换句话说，所有流过软件价值流的工作项都是这些工作项中的一个，而且只能是一个。

  软件交付的其他视角 

软件交付工作的其他特征也存在，例如 Philippe Kruchten 和他的同事们的“积极 / 消极”与“可见 / 不可见”的四象限(见图1)和《 DevOps实施手册》中描述的特性。这种特性描述对于识别开发工作的类型很有用。例如，ITIL (信息技术基础设施库)流程定义了问题、事件和变更之间的重要区别。

图1. Philippe Kruchten 和他的同事们对改进软件相关任务的描述

不过，这些描述是从流动工作项向下的一层，因为它们更具有交付特性，而不是客户和价值流特性。因此，我们相信它们对于描述流动工作项交付过程中正在处理的工件类型更加有用。例如，在SAFe中，架构工作的术语是使能（Enabler）。这项工作可以用于支持新特性、修复缺陷、减少技术债务或通过提供支持合规性所需的基础结构来解决风险。我们已经观察到我所描述的几类流动工作项，在这样的体系结构中在流动。

从客户和业务利益相关者的角度来看，虽然流动工作项之下的那一层是至关重要的，但是流动工作项的交付决定了某些东西是否通过价值流。这是如何实现的，是否是通过添加新的 API还是仅仅通过向 UI 添加附加内容来实现的，都只是这个高层级视角的一个实现细节。

我们将继续分析给到我们的每个工具链，以确定是否存在其他顶级工作项类型。但到目前为止，我们分析的所有工作项类型都可以映射到这四类流动工作项。我们相信它们是分析软件价值流的一个有用的抽象，通过这些流动工作项提供的透镜来研究软件交付，可以产生有趣的结果。因为这些流动工作项提供了一个不同的、更加以业务和客户为中心的视角来看待软件价值流中的流，我们希望它们能够引发进一步的辩论和讨论，并帮助我们建立一个基于交付给客户的价值而不是已完成工作的虚假的生产力模型。

想要了解更多关于工作是如何在你的软件价值流中流动的信息，可以深入学习《 Project to Product 》。

注：本文的一个版本最初发表在2018年7月出版的 IEEE 软件: m. Kersten，“什么流经软件价值流，” IEEE 软件，卷。35，no. 4，pp. 8-11,2018 IEEE doi: 10.1109 / ms 2018.2801538-Original article

这是一系列来自于Mik的博客，这些核心内容可以认为是 《Project To Product》的起源。对Mik来说，从项目到产品，是一个20年的旅程，开始于作为一个开源开发者的十年学习，并将这些学习应用到他过去十年与 不同行业IT 领导者的合作中。这些帖子代表了他一路上最有趣的学习和合作历程。这些文章最初发表在 IEEE 软件杂志的“ On DevOps”专栏中，目标读者是对软件体系结构进化感兴趣的读者。

这是我筛选出来的第三篇。如今，这本书的中文版《价值流动：数字化场景下软件研发效能与业务敏捷的关键》由张乐、姚东、李淳、吴非四位译者翻译，王勇审校出版问世了，让我们国内的读者也能在数字化转型的路上借鉴米克.科斯腾的流框架成功转身。