如何在软件交付中建立流程

Flow Framework的想法始于我尝试可视化制造,如软件交付的生产流程。Flow Framework的核心前提是我们需要衡量端到端的业务价值流。

Flow Framework 完全侧重于端到端价值流及其与业务结果的相关性。测量是通过软件传递的基本事实完成的,该事实是通过价值流网络层的工件流观察到的。敏捷和DevOps指标和遥测位于Flow Framework下方。例如,如果敏捷团队一直在努力实现其发布目标,那么SAFe或Scrum框架可以提供更好的优先级和规划的指标和指南。相比之下,Flow Framework专注于端到端指标,用于确定这些瓶颈可能位于何处 – 例如,如果它们位于开发的上游或下游。

此外,Flow Framework避免了有助于跟踪流量指标并将其与结果相关联的活动度量。没有关于组织如何“敏捷”或“如何开发”的指标,只关注每个价值流中流动的商业价值以及它产生的结果。如果对市场的响应是关键需求,那么Flow Framework可以突出显示对于特定值而言过慢的流量和反馈周期,这意味着可能需要更多的敏捷实践。

Flow Framework的作用是帮助您确定您在Agile和DevOps实践中的投资结果,并为您提供改进这些实践所需的指标。我们的目标是为您提供扩展流程,反馈和持续学习的方法,不仅可以用于开发和操作,还可以用于软件交付的端到端业务流程。

使用值流流程
在顶层,Flow Framework提供了两件事。首先,价值流指标允许您跟踪组织内的每个价值流,以便您可以将生产指标与业务成果相关联。其次,价值流网络层提供了衡量每种产品交付结果所需的基础设施。

在最高级别,Flow Framework是一种机制,用于协调组织中围绕软件产品的所有交付活动,跟踪这些活动的业务结果,以创建结果驱动的反馈循环。

要做到这一点,我们必须切换到第一原则并定义客户,他们正在拉动什么,以及如何将这种拉动作为价值流流动来实施。一旦定义了一个或多个价值流,我们就需要专注于使价值流顺畅地跨越这些价值流。但在我们这样做之前,我们必须定义沿软件价值流流动的单位。

Flow Framework旨在以最大的组织规模工作,并在需要时支持严格的监管要求。这意味着即使是最传统,最复杂或最安全的组织也可以应用这些概念,以适合其业务的速度推动软件创新。为此,我们首先需要了解构成框架的四个主要流程项。

四个流量因素
每当我向高级或行政级IT领导者询问他们的瓶颈时,我都会收到一个空白的凝视或模糊的答案。但是,当设置在正确的背景下时,只是探索这个问题的思维过程就会出现一个严重的问题。绝大多数企业IT组织没有明确的生产力度量来衡量软件生产过程中的流量。

衡量生产力
如果没有对生产力的共同理解,企业就无法对瓶颈有共同的理解。与汽车行业形成对比,汽车行业生产的汽车数量是衡量汽车价值流的非常明确的生产率指标。更糟糕的是,不仅仅是那些忙于调整重要指标的组织; 它是整个软件行业。

学术界或行业思想领袖对软件开发生产力的构成没有明确的共识。组织在看到它时就知道了 – 可能通过推动市场采用和收入的产品比其他产品更快。但是,将发展活动与这些结果联系起来更多的是一种不透明的艺术,而不是一种纪律活动。要在价值流中定义生产力,我们必须首先定义流量。

要做到这一点,我们需要回到本章前面概述的精益思想的第一原则。精益思维不是从产品开始,而是从客户所带来的价值开始。如果我们回想起软件的早期阶段,公司会将安装好的磁盘包装在收缩包装的盒子中,我们可以尝试对汽车生产进行类比,并将生成的小部件定义为那些盒子。但那个类比当时很弱,并且在这个持续交付和云的时代变得无关紧要。如果客户没有发布产品,那么客户有什么价值?

为了提升价值,客户必须能够看到这个价值,并愿意为此交换一些经济单位。对于内部产品,这可以是采用(例如,具有不同的业务单元采用共同的认证系统)。对于外部产品,该单位可以是收入; 或者对于具有间接或基于广告的货币化的产品(例如社交媒体工具),可能需要花时间与产品进行交互。对于政府或非营利组织,它可以是新推出的数字产品的采用率。

了解价值流
使用上述任何一种情况,请考虑上次从产品中获取新值或使用之前未使用过的产品。在花费你的时间或金钱方面,是什么触发了价值交换?有可能这是一项新功能,可满足您的使用需求,并可能以某种方式让您高兴。或者是修复了一个阻碍您使用您原本重视的产品的缺陷。这就是定义软件价值流中流量的关键:如果我们提取的是新功能和缺陷修复,那么这些是软件价值流的流程项。

如果这些是流项,那意味着我们可以将价值流中所有人和团队的工作描述为应用于其中一个项目 – 我们可以。通过全面了解组织中的每个流程和工具,您可以确切地确定有多少设计人员,开发人员,经理,测试人员和帮助台专业人员参与创建,部署和支持特定功能。缺陷也是如此。但这是价值流中唯一的工作吗?

包括值流中的所有工作
“ 挖掘企业工具链的真相它由组织内部拉动; 例如,首席风险官及其团队。

减少技术债务
最后和第四种工作是减少技术债务,它描述了对软件和基础设施代码库进行工作的需要,如果不这样做,将导致将来修改或维护该代码的能力降低。例如,对功能交付的关注可能导致技术债务的大量积累。如果不采取措施减少技术债务,那么它可能会妨碍未来提供功能的能力; 例如,通过使软件架构过于纠结以进行创新。

虽然风险和技术债务的概念在流程框架中并不新鲜,但是对每个流程项目的衡量重点导致对如何管理它们产生非常不同的结论。在使用流程框架时,应该优先考虑的唯一技术债务工作是通过价值流增加未来流量的工作。技术债务永远不应仅仅为软件架构而做,比如用它来改善架构层的分离。这意味着每个流程项的流程应该塑造软件架构,而不是相反,这与许多企业架构的发展方式背道而驰。

最后更新于 三月 19, 2021

心有多大,路就有多远