写点什么

精益 + 敏捷,两大管理思路让研发效能「飞」起来|直播回顾

作者:万事ONES
  • 2022 年 8 月 16 日
    广东
  • 本文字数:4824 字

    阅读完需:约 16 分钟

精益+敏捷,两大管理思路让研发效能「飞」起来|直播回顾

8 月 10 日,ONES 研发管理大师课第二期课程正式开课啦。本期邀请的大咖讲师是 ONES 研发效能改进咨询顾问董晓红老师,分享主题为《精益敏捷组合管理提升研发效能》。通过精益和敏捷管理思路,探讨如何让有价值的需求顺畅、高质量地流动起来,从而提升企业研发效能。

 

以下是晓红老师分享的核心内容。

 

研发效能提升的必要性


我先从四个视角解读一下研发效能提升的必要性。

站在组织的视角上,组织发展规模化以及技术驱动商业差异化,已经难以应对市场的快速变化;站在组织内部的视角上,竞争日趋激烈,「谷仓效应」越发突出,局部优化但是无法全局优化,破局「大船难掉头」的尴尬势在必行;站在行业技术视角上,软件研发的各个环节已经全面数字化。为研发效能的数据收集和度量做好了准备;最后,站在外部资源视角上,在经济存量的大背景下,再加上今年新冠疫情的影响,业务发展不能仅靠烧钱、人海战术。随着产品利润的下降,企业需要降本增效,提升效能。这是我理解的提升研发效能的四个必要性。

 

精益的起源


讲到精益,它的生产系统有三个阶段。

第一个阶段是弗雷德里克·温斯洛·泰勒提出的科学管理方式阶段,就是有流程制度的标准作业,大幅提升了作业的效率;第二阶段是大规模生产方式,代表人物是亨利·福特,他创造了大众阶层也能买得起的 T 型汽车,在泰勒的科学管理方式的基础上,提出了更加规范化、标准化的大规模生产方式,让汽车走进千家万户;第三阶段是丰田生产方式,代表人物是大野耐一。据说,当时大野耐一去美国福特的流水线参观时,发现很多浪费现象,他觉得与日本的节约理念很不匹配,他想出来一种精益生产方式——小规模、小批量「拉动式」的生产系统。

 

此外,精益是怎么在 IT 软件应用中演进的呢?1996 年,詹姆斯·沃麦克和丹尼尔·琼斯发布了《精益思想》,精益生产方式由经验变成理论,使精益在其他领域进一步扩展;2003 年,Mary 和 Tom 在《敏捷软件开发工具——精益开发方法》把精益原则映射到软件开发中;2004 年,大卫·安德森在微软公司可持续工程团队进行精益化管理变革,通过 5 个季度把微软绩效排名最差的团队变为绩效最好团队;2010 年,大卫·安德森发布《看板方法:科技企业渐进变革成功之道》,看板方法脱胎于丰田生产方式和高德拉特的约束理论(TOC),是精益方法的进一步延伸;2014 年,在国内,华为最先开始推行精益看板方法,招商银行紧随其后。

 

接下来,我们看看精益管理的五大原则,也是精益实施的五个步骤。

 

第一步,定义价值,我们要站在用户的视角去定义价值。举个例子,软件开发中我们提一个需求,要站在用户的角度去思考是不是他们想要的,而不是我们自己臆想出来的,这就是定义价值。

 

第二步,识别价值流。我们以终为始,定义端到端过程中的一切活动。以软件开发为例,从需求的提出到评审、研发、上线整个过程就叫端到端的活动,这样才能有全局的视野。有了全局视野,我们才能看到整个过程中有没有多余的步骤、有没有阻塞、有没有瓶颈等。

 

第三步,增加流动。有价值流了,我们要让它像河流一样通畅流动起来。这一步有个比较重要的点,就是要从聚焦资源到聚焦价值流动。意思就是,团队要从一开始关注「人忙不忙」,逐步转变到关心「价值是不是在流动」,因为人在忙不一定能带来价值。这一点是很关键一点的,是要从思维上改变的。

 

第四步,需求拉动。降低库存,我们有订单后再生产,用下游拉动上游。

 

第五步,「完美」,也就是不满足现状,持续地去改进。在软件行业,「完美」最重要的是「质量内建」,意思就是不要把有问题的环节传到下一个环节。

 

这就是精益生产的五大原则,它最高的目标还是要降低成本、改善质量,缩短周期。


看板方法的核心内容与实践



「丰田生产系统-看板信号卡拉动」示意图

 

很多人其实对看板是有一种误解的,只把它看成「可视化的板子」。所以,理解什么是「生产制造中的看板」十分重要,它可以帮助我们理解本质,消除误解。看板一词来自于日文,本义是信号卡片,用于精益流程和及时的库存补充计划,帮助公司提高产量并减少总体库存。

 

这节课,我们主要讲解精益看板方法。大卫·安德森最早在软件开发中借鉴和应用看板实践,并总结为完整的「看板方法体系」,包含以下三个核心内容:

 

第一,将流程可视化。把工作拆分成小块,一张卡片写一件任务,再把卡片放到墙上。这可以理解为,我们要做一个软件,把需求写到一张卡片上,然后再把这个卡片放到看板墙上;看板墙划分为多列,每一列都有状态,显示每件任务在流程中处于什么位置。

 

第二,根据能力限制在制品。明确限制流程中每个状态上最多同时进行的任务数。每个团队的能力、基础设施是不一样的,需要团队根据自己的情况去探索。它有两个目的,一方面,通过减少并行任务数量,加快价值流动,从而缩短周期时间;另一方面,它有暴露问题的张力,有助于暴露瓶颈和问题,激发团队协作解决问题。

 

第三,度量生产周期。这有助于对流程进行调优,尽可能缩短生产周期,并使其可预测。这个步骤可以帮助团队判断过程中有没有不必要的步骤、有没有浪费、有没有可能缩短生产周期等等。

 

明确好核心内容以后,我们来看看精益看板的五大实践。

 

第一个实践,可视化工作流程。它有三个要点:可视的是用户价值、可视的是用户价值端到端的流动过程、问题和瓶颈也要可视化显示出来。

 

第二个实践,控制在制品数量。每个环节内在制品数量小于设定的数量时,才可以从上一环节拉动,否则不允许拉入新工作。我们要聚焦已开始的工作,聚焦有问题的地方。

 

第三个实践,显示化定义规则。这里指的是看板中从一列移入另一列的规则。另外,其他规则也要定义出来,比如:需求优先级、紧急需求等定义也要显示化出来,以便团队达成共识,按照规则来执行。

 

第四个实践,管理工作项流动。这里有两个要点,一是就绪队列的填充,就绪队列是看板价值流的源头,只有管理好源头,才能重视价值的顺畅流动和质量。二是每日站会,站会也是管理价值流动过程的活动,重点会关注价值流动过程的问题和阻塞。

 

第五个实践,建立反馈,持续改进。它需要关注流动是否顺畅的反馈以及关注质量的反馈。


敏捷的起源与基本框架


说完精益的起源,我们再来说说敏捷的起源。2001 年,17 位软件开发者带着他们轻量级框架「Scrum、XP、FDD、DSDM」,齐聚在美国的犹他州的雪鸟滑雪场。他们把框架里面的共性特征抽象出来,梳理形成了敏捷的十二原则,并写下了敏捷软件开发宣言。

 

同时,Scrum 的历史可以追溯到 1986 年。《哈佛商业评论》的一篇文章《新型产品开发策略》描述了一种快速灵活的开发策略,以满足快速变更的产品需求。该文章第一次将 Scrum 与产品开发进行了关联。

 

我们再详细讲解一下 Scrum,它的目标是通过一种自组织跨职能的迭代小团队去交付价值。支撑这个目标是敏捷的三大支柱——透明、检视、适应。Scrum 框架还有很重要的「3355」原则——3 个角色、3 个工件、5 个价值观、5 个事件:


  • 3 个角色:产品负责人、团队成员、敏捷教练

  • 3 个工件:产品待办列表、迭代待办列表、产品增量

  • 5 个价值观:承诺、勇气、专注、开放、尊重

  • 5 个事件:迭代、迭代计划会、每日站会、迭代演示会、迭代回顾会

 


Scrum 与 Kanban 的相似与不同


接下来,我们看看 Scrum 与 Kanban 的对比。这个对比不是评价孰优孰劣,而是以此来加深对两种方法的认识,并在实践中相互借鉴。它们的相似性有这几部分:

  • 都是既精益又敏捷

  • 都限制了 WIP

  • 都以透明的方式驱动过程改进

  • 都关注于尽早交付,频繁交付可发布的软件

  • 根基都是自组织团队

 

同时,Scrum 与 Kanban 有 6 项差异点,我们从变更导入、节奏、控制在制品、事件、角色、默认度量这 6 个维度进行了对比,详情请看下面这张对比图:

 

ONES 精益敏捷组合管理思路

 

最后,和大家分享一个 ONES 给客户做的精益敏捷组合管理的思路。如下图,我们可以看到,能效、流程、方法工具是从「事」的角度出发,组织是从「人」的角度出发。研发效能的提升,无论是看板实践还是敏捷 Scrum 实践,更多解决的是如何让有价值的需求顺畅、高质量地流动。所以,我们要想提升效能,不能仅靠部分的管理实践,还需要一些工程实践,比如要持续集成、持续部署、持续监控、自动化测试等等,形成一个闭环作业。

 

从「事」的角度,我们需要梳理流程规范,要确保组织上下文形成一系列的共识,包括统一的术语、业务以及研发数据流的串联、度量单位的一致性等等。有了流程规范以后,我们就通过工具去固化流程规范。在这过程中,可以兼顾一些度量埋点的设计,把我们想要的一些指标设计进去,这样数据就自然而然地落到了系统中。最后,通过度量 UI 展现层,展示出一些数据供各个领域,持续改进、持续做决策。

从「事」的角度提升效能,是有一定成效的,但更重要的还是要从「人」的角度出发。我觉得,需要有一个变革的引领者,比如说是 Scrum Master 或者过程改进专家、效能专家等等。这些人需要有:

  • 引导的技能,如:能够引导团队有效地开会,引导团队实践落地。

  • 教练的技能,通过这种启发式提问,让团队成员找到自己的目标、实现目标的驱动力、激发团队整体的潜能。

  • 当然,这个变革者他自身必须有自驱力,他能影响团队,帮助团队成员成功,帮助团队成员光彩夺目;同时,这个人要养成成长型思维,允许团队成员犯错,这种文化也很重要。

 

以上是我今天分享的主要内容,希望能给大家启发,感谢聆听。

 

-Q & A-


Question 1:

网友:软件敏捷开发模式下,市场需求会拆分成多个产品需求,开发继续拆分产品需求到更小颗粒度去编码。因此,开发团队经常用产品需求来衡量交付,每年研发效率都在提升。但市场侧却认为从市场需求角度看,效率并没有提升。如何让双方的效率提升达成一致的看法呢?

晓红老师:研发侧有自己的持续改进度量指标我觉得没问题,通过统计数据看到研发侧效率的提升,加强了团队持续改进提升的信心。关于「市场侧不认可」,需要了解市场部不认可的原因,如果市场部觉得在业务上并没有感知到研发效率的提升,可以定义一些业务指标来牵引研发更好地支撑业务。一般来说,市场部的指标要根据市场部的战略、目标来制定。

 

Question 2:

网友:在企业管理场景中如何推动敏捷在企业中落地呢?

晓红老师:我觉得有以下几点。第一点,无论你推动敏捷或者 DevOps 变革,我建议要有一个目标,相当于内驱力:我为什么要做这个敏捷转型,我要解决哪些痛点等等;第二点,就像刚才说的,最好有一个变革的引领者,领导者可以是 Scrum Master,他要辅导团队怎么去做敏捷,在企业中如何落地,让大家理解这个背后的原则等等;第三点,一个好的工具是非常必要的,它可以帮助你加速整个敏捷的落地。

 

Question 3:

网友:我们公司践行敏捷实践也有一段时间了,但是团队中有很多人不愿意开敏捷回顾会议,怎么办?

晓红老师:我觉得可能要分以下几点。第一,和团队成员去聊一下为什么不愿意参加回顾会,是不是觉得没有价值?如果是没有价值,那就需要检视一下回顾会是不是基于目标开的,需要有明确的目标;第二点可能也要去跟团队成员去聊一下,他们期待的敏捷回顾会是什么样的,他心中完美的敏捷回顾会是什么样?大家可以集思广益。

 

Question 4:

网友:我们是制造业,正在敏捷转型期,在敏捷实践过程中,员工配合度不高怎么办?

晓红老师:我觉得还是要看看他们不配合的原因,或者间接地去检视他们是不是没有理解敏捷的实质。其次,还是看看他有没有什么好的工具或者方法,可以更好地帮助大家达成敏捷转型的目标。

 

Question 5:

网友:Scrum 核心要点「3355」是必须的,还是说可以根据企业的自身情况做调整呢?

晓红老师:我想还是要根据企业不同的情景而定。比如说,公司刚进行敏型转型的时候,还是需要尽量遵守「3355」;当达到一定的敏捷成熟度了,也许都可以不需要 Scrum Master 这个角色。我之前看到过好多客户的团队,合并两个迭代进行回顾会,却可以很好地解决问题。所以,不同的阶段,企业可以根据自身情况采用不同的方法。



ONES 研发管理大师课第一季课程还在继续,「大型软件团队高效协作的方法与实践」「研发效能度量的行业趋势及五项精进」等课程即将上线。


用户头像

万事ONES

关注

助力企业更好更快发布产品! 2018.08.06 加入

一站式企业级研发管理解决方案,满足敏捷、瀑布、通用多种研发管理模式,打造高效协作环境,助力企业更好更快发布产品。

评论

发布
暂无评论
精益+敏捷,两大管理思路让研发效能「飞」起来|直播回顾_万事ONES_InfoQ写作社区