谈到技术管理,首要的一点就是管理者的角色认知问题,因此本篇文章的主要内容就是如何增强管理者的角色认知,持续提升自我管理能力。作为管理者,首要任务就是要认清自我并管理好自......
2021-11-17 199 Project教程
价值流分析是敏捷转型前期非常重要的一环,也是最基础的一项必做工作。
关于价值流,百度百科中这样定义:
价值流是指从原材料转变为成品、并给它赋予价值的全部活动,包括从供应商处购买的原材料到达企业,企业对其进行加工后转变为成品再交付客户的全过程,企业内以及企业与供应商、客户之间的信息沟通形成的信息流也是价值流的一部分。一个完整的价值流包括增值和非增值活动,如供应链成员间的沟通,物料的运输,生产计划的制定和安排以及从原材料到产品的物质转换过程等。
在软件开发领域,价值流主要是指从需求获取开始一直到产品成功上线发布的活动。在精益产品开发中,价值流是价值项从左至右的流动过程,是信息的产出过程,也是价值增加的过程。
而价值流分析则是针对从左到右的端到端的过程进行各个环节的分析,从而找出浪费、发现瓶颈,并进行持续改善。
那么,在敏捷转型的过程中,对于价值流分析我们应该如何做呢?
首先,建议采用看板方法,将软件开发过程中的各工作项等全部可视化出来。这里面可以借鉴《看板方法》、《看板实战》、《精益产品开发》等书中提到的有关可视化价值流动的相关方法。这个环节会用到看板搭建的一些方法,每一个团队可以结合实际开发流程,先绘制出最简单易懂的看板辅助开展价值流分析。
其次,要结合产品或项目目标、用户需求、交付要求等对各工作项进行价值分析。这里面要回归到用户需求/用户故事交付的本质上来,在需求、设计、开发、测试等环节也许会有很多的细分的工作任务,要理清楚这些任务的映射关系、依赖关系等等,同时标注每一个工作项的前置条件、优先级、拥有者、开始时间及预计完成时间等等。这个环节是价值流分析的核心环节,是后续能否真正发现问题及瓶颈并作出持续改进的先决条件,因此必须要让团队的全体成员参与,而且要将当前每个人手上的全部工作项都要可视化出来。在表现形式上,通常采用便利贴(预先定义好格式要求)等易于操作的方式罗列出来。
再次,要从价值流分析中找出问题和瓶颈。这里面要从价值交付的角度出发,从整体和局部等多角度审视各工作项的流动情况。从整体来看,主要关注需求、设计、开发、测试、发布等各个环节的工作项分布情况,是否会存在大面积阻塞的问题,或者虽然有很多工作项同时在进行,但在待发布或发布的需求很少,即在制品很多的情形,等等。之后是要标识阻塞的工作项,并分析为什么会阻塞,比如是否工作分配不合理,或者是需求拆解不合理,或者是任务要求不清晰,或者是团队技能跟不上,或者是团队工作不紧凑等等。并记录下这些问题可能存在的原因,深入分析,识别出主要问题和相应的瓶颈。
最后,要明确团队改进的方向。做价值流分析的最终目的是为了促进团队的持续改进并持续高质量地交付价值,这既是敏捷转型的重要基础,也是贯彻DevOps里面有关三步工作法中提到的有关持续学习与实验的思想。只有定下改进方向并确实行动起来,才能开启敏捷转型的大门。
在我曾参与敏捷转型的一个团队中,也是充分使用了看板方法来进行价值流的分析。在当时,整个团队常常接收到客户投诉,问题处理缓慢,需求交付周期长。为了实施敏捷转型,在初期充分了解团队现状之后,组织团队进行了价值流分析,将各项需求、开发任务、问题处理、测试任务等等全部按照约定的规则通过看板进行可视化,之后分析出存在的瓶颈,比如由于系统为多年前老旧的单体架构很多问题改动起来非常困难,比如由于业务非常复杂每个人都只能掌握其中一部分,比如由于人员流动频繁团队中有不少新人,比如需求过于庞大导致开发工作量很大,比如只能依靠单纯的手工测试而无法推行自动化测试,比如必须要等所有需求都完成才发布导致发布周期很长,诸如此类的问题等等。在明确了这些瓶颈后,项目团队对各类问题及瓶颈进行了分门别类,并制定了改进计划。
通过价值流分析,可能让团队很好地认清现实、看清团队自身,从而更有利于做出改变。诚然,每一个团队的价值流分析模式可能不尽相同,但最终的目标都是一致的,那就是对软件开发的整个价值流进行统一管理,发现浪费,降低或去除没有价值的工作,减少不必要的活动,从而做到持续高质量地交付价值,提高竞争力。
相关文章