码迷,mamicode.com
首页 > 其他好文 > 详细

FLEET 框架:研发时间减半质量倍增的秘密

时间:2019-12-12 20:01:05      阅读:108      评论:0      收藏:0      [点我收藏+]

标签:效能   北京   初始   多个   导入   能力   启动   回归   未来   

近五年来, Agilean 一直在帮助某大型股份行实施精益看板转型。从全面导入到落地深化,从基层赋能到量化改进,该行目前电子看板使用率已达90%,为国内领先水平。在此过程中,我们将精益思想和看板方法进行了更有机的贯通,形成了一个帮助企业快速提升研发效能的改进体系 FLEET(精益效能提升思维框架,Framework of Lean Efficacy Enhancement Thinking)。我将结合落地经验,对FLEET进行全方位阐释。

以下为FLEET 的的6条核心思路:

  • 看见:高效知识工作的最大敌人,是知识工作过程和成果的不可见性。首先要利用看板可视化,构造管理现场;
  • 整流:由于知识工作「不可见」,处理过程中很容易造成工作拥堵。建立需求优选机制,减少并行工作,可以保持专注,提升流动效率;
  • 细粒:进行整流之后,如果需求颗粒度过大,需求也无法快速流动。这就要进一步减小需求颗粒度,从而加速流动,提升质量反馈速度;
  • 润滑:需求交付质量低会造成返工,加剧需求并行度,使彼此之间产生「摩擦」。强化需求澄清、质量前移等质量活动,可以减小需求间的摩擦,缓解过程中的阻力;
  • 小批:定期的需求选择会、澄清会、版本移交等批量活动,会减慢端到端的流动速度,造成等待。应尽量减小批量,减少等待时间;
  • 降本:交易成本是批量存在的根本原因。通过推进自动化回归测试、自动化部署等活动,降低交易成本,使批量减小成为可能。

技术图片

看见:为管理者构造管理现场

知识工作管理者通常会有一种焦虑感,管的人越多越容易焦虑。在诸多原因中,缺乏有效的可视化管理手段是重中之重。越看不清,就越踌躇,越催生焦虑。陷入焦虑的管理者,往往采用更严格的管理手段,又引起下属更多遮掩和隐瞒,工作状态的不可见被进一步强化,从而形成一个恶性循环。

技术图片

在斯坦利?麦克里斯特尔(前美军特种作战司令部指挥官)所著的《赋能》一书中,作者提出一个很好的思路:“双眼紧盯,双手放开”。能够做到双眼紧盯,才敢把双手放开。FLEET 的第1个核心思路——用看板实现知识工作的可视化,便是要赋予管理者“看见”的能力。经过良好设计的看板,可以为研发团队管理者提供重要的管理现场。下图是我在2014年辅导的一个创新项目研发看板,该项目在4个月内完成了一个创新金融 APP 从0到1的过程。「可视化」实践里最大的挑战,在于对团队实际工作情况进行价值流的梳理和建模。

技术图片

整流:建立需求优选机制

请看下图并回答:直觉上,你觉得这是什么地点?

技术图片

在其它城市培训时,学员往往认为是火车站;生活在北京的学员却一眼看出,这是龙泽或西二旗地铁站。站外的铁栏杆就是地铁系统的整流措施——虽然让个体多走了些路、多了些等待,却保证了整体(每个个体)花更少时间候车。

在长期不可见的情况下,大多数研发团队处于高并行的过载状态,其特点就是持续打断、大量并行。有研究表明,软件研发的流动效率通常只有1%-5%。在流动效率很低的研发过程中,必须引入需求优先机制,即优先级选择。以下图看板为例,“开发”列之前为“选择”队列(红框),将积压需求停留在研发系统之外,避免进一步加剧流程中的阻塞,确保研发流程得以快速优化。

技术图片小团队比较容易建立需求优选机制。对大型组织而言,建立需求优选机制的主要挑战,在于如何有效平衡各业务方的诉求。我们在实践中发现,部落制是解决这个问题的有效方式。将研发组织和业务组织拉通(可采用虚拟方式),将研发资源合理分入不同部落、面向不同业务方,然后在部落内建立合适的需求优选机制。

P.S. 流动效率、部落制等话题均较复杂,未来我们将专文详述。

细粒:需求拆分加速流动

需求优选机制运行起来后,下一个改进点是减小需求颗粒度,将需求拆分成更小的可验收可测试单元。规模过大的单元,不利于透明其执行过程中的等待、阻塞和风险。对于大型组织,我们建议采用需求、系统任务、个人任务的三级体系,系统任务控制在10人天,个人任务拆至2-3人天。

下图为之前提到的创新项目快速启动现场(研发正式开始前的启动环节,通常为2-3天)。业务和IT共同拆出350多个粗粒度用户故事,据此制定了迭代计划和关联系统计划,完成看板建模,形成风险应对方案。团队在其后的三个月里完成6个迭代,项目准时上线,产品内容、功能和质量都获得了高度认可,在当年赢取了国内若干重要银行奖项。

技术图片

润滑:降低需求摩擦

需求颗粒度减小后,通过降低需求彼此之间的摩擦,可以让研发过程流动更加顺畅。什么是需求摩擦?看图——

技术图片

这段对话熟悉吗?对不少研发同学来说,本来正在做A需求,中间被叫去评审B需求,过会儿又要修改C需求的缺陷,需求之间就产生了摩擦。有很多方法可以降低需求之间的摩擦:

  • 实例化需求,提升需求初始质量;
  • 产品经理制度,专人负责与业务澄清需求;
  • 需求研发双迭代,需求澄清迭代和研发迭代并行,澄清迭代的输出是研发迭代的输入;
  • 建立开发自冒烟制度、代码评审制度,提升初始移交质量,减少测试摩擦。

小批:尽一切可能减小批量

加速流动的一个有效方法是减小批量。「批量」指在某些环节中多件事情一起处理,比如多个需求一起澄清,多个设计一起评审,多个功能一起上线,这些都是批量。批量必然导致一些需求等待另一些需求,减慢端到端的需求流动速度。

技术图片

批量减小后,需求可以更快速地从开发流动到测试和UAT环节,尽早对质量产生反馈。如上图,通过减小批量,原来3个月完成600个需求,现在变成每两周完成100个需求,前置时间缩短到原来的1/6,交付速度大大加快。因此,我们应寻找一切可能的机会减小批量。例如,IT和业务团队不在一个职场的时候,要每周约定开会澄清需求;如果能在一个职场集中办公,澄清需求变得容易很多,就消除了周澄清会所造成的批量。

降本:与合理批量达成最优解

消灭所有批量,实现单件流,最大限度减少等待造成的浪费,这是一种理想状态。在现实中,由于交易成本的存在,形成合理的批量大小,才是我们要寻求的最优解

交易成本指在做一件事的过程中,需要付出的额外附加成本。例如,需求澄清要预定会议室,要协调参会者时间;版本发布要回归测试,要进行评审,要熬夜发版,这都是交易成本。

技术图片

交易成本越高,人们就倾向于形成越大的批量。为了减小批量,很多时候需要先降低交易成本。自动化回归测试、自动化部署、减少不合理的流程制度,这些都是降低交易成本的手段。

FLEET 是一套帮助企业快速定位问题、推动初始优化和改进的思维框架,其目标是为企业快速带来改善。我们将 FLEET 与过往实践经验互相印证,形成的精益效能提升实践体系,已帮助多家大型组织实现了「优化冲刺、提速增质」的目标。

FLEET 框架:研发时间减半质量倍增的秘密

标签:效能   北京   初始   多个   导入   能力   启动   回归   未来   

原文地址:https://blog.51cto.com/14638745/2457951

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!