《SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架》一2.6 原则#6——可视化和限制在制品,减少批次规模,管理队列长度

本节书摘来自华章出版社《SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架》一书中的第2,第2.6节 作者[美]迪恩·莱芬(DeanLeffingwell),更多章节内容可以访问云栖社区“华章计算机”公众号查看。


2.6 原则#6——可视化和限制在制品,减少批次规模,管理队列长度

接近满负荷地使用产品开发流程是一场经济灾难。

——Donald Reinertsen

为了实现可持续的最短前置时间,精益系统构建者们努力实现持续流动的状态,即新的系统可以迅速地从概念到盈利。实现持续流动需要消除传统方法中的基于“开始–完成–开始”的项目启动和开发流程,也要消除阻碍流动的现行“阶段–门限”的方法(原则#5)。

实现流动的三个关键点是:可视化和限制在制品,减少工作项的批次规模,以及管理队列长度。

可视化和限制在制品

团队和项目群的工作过载,任务量超出了他们所能承担的范围,这是一个常见且有害的问题。系统中如果在制品(Work in Process,WIP)过多,就会导致人员复用和频繁地在不同工作场景之间进行切换。这种情况会使员工工作过载,减少了对正在执行任务的专注度,降低了生产力和吞吐量,并增加了交付新功能的等待时间。

第一步是让当前的在制品对所有利益相关者清晰可见。这个可视化说明了在每一个步骤的工作总量,也作为对初始过程的诊断,并显示出当前的瓶颈。在某些情况下,仅需简单地可视化当前的工作,就可以唤醒开发人员,让他们开始意识到要解决同时开展工作太多而没有形成流动的问题。下一步就是处理在制品数量和可用开发容量平衡的问题。如果在执行过程中达到了在制品的上限,就不再承接新的工作任务。

 

然而,限制在制品是需要有知识、有纪律和有承诺的。甚至有些时候是看起来是反直觉的,比如以前有些人认为放入系统的工作越多,完成得就越多。在一定程度上这是正确的,但是如果超出了一定的限度,系统就会变得动荡,也会降低流动性。这说明,有效的在制品管理是不可取代的。

减少批次规模

减少在制品和提高流动性的另一种方法是减少工作的批次规模,这些工作包括需求、设计、编码、测试和其他相关工作。简单地说,小批量通过系统的速度更快,变异性更小,并能够促进快速学习。显而易见,因为随着批次规模的增加变异性是累积增加的,所以批量越小速度越快。

从经济的角度上来看,最优的批次规模依赖于持有成本(延迟反馈和价值交付带来的成本)和交易成本(实现和测试的成本)。如图所示,说明了“U型曲线”是批次规模的最优曲线(参考资

料[1])。

为了提高处理小批量的经济效益,从而增加吞吐量,主要的工作重点需要聚焦在减少批次的交易成本上。通常包括更加关注在基础设施和自动化上的投资,比如持续集成和构建环境、DevOps自动化,以及系统测试的配置时间。以上这些都是与系统思考的融合(原则#2),也是进行长期优化的关键要素。

管理队列长度

实现流动性的第三个措施是管理队列长度(一般来说是减少队列长度)。利特尔法则(基于排队论的法则)告诉我们,系统提供服务的等待时间等于队列的长度除以平均的处理效率(这可能看起来很复杂,可是在星巴克排队买咖啡的时候也会用到这个公式)。因此,假设平均的处理效率一定,队列越长,等待时间越长。

对于解决方案开发来说,这意味着无论团队多么有效地处理工作任务,只要团队实现的工作任务队列越长,那么等待时间就越长。如果你需要更快地完成,就必须减少队列的长度或者提高处理效率。虽然提高处理效率是我们都希望达到的共同目标,但是减少等待时间最快的方式是减少队列长度。在工作中,可以通过保持较短的待办事项列表和并不过多进行承诺来做到这一点。同时,可视化工作可以极大地帮助过程改进。

减少队列长度可以减少延迟、减少浪费,增进对于成果的可预测性。可视化和限制在制品,减少批次规模和管理队列长度,这三种方式对于提高吞吐量非常有效。通过采取这些方式,可以在客户满意度和员工参与度方面达到快速和可衡量的改进,对系统构建者及其客户也可以带来全面的经济效益。

参考资料

[1] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009.

上一篇:openStack 主机流量计运行状态 随笔记录


下一篇:Java学习路线-47:Ajax学习XMLHttpRequest、XStream、json-lib