研发效率破局之道04 | 流程优化:怎样才能让敏捷、精益真正为我所用?

你好,我是葛俊。今天我们来聊聊怎样从流程⽅⾯来提⾼研发效能。 
从这⼀篇⽂章开始,我们就正式进⼊研发流程模块了。在第 1 篇⽂章中,我与你强调了软件开发的最⼤特点在于它是⼀条⾮常灵活的流⽔线,因此提⾼研发效 能的第⼀步就是优化流程。 
图 1 提⾼研发效能的第⼀步就是优化流程 
因为优化流程会涉及⽅法论,所以我会先和你介绍⾼效实践⽅法论的关键要素。然后,我会按照⽬标、原则和实践 3 个层次,从抽象到具体,给你逐步讲解 如何优化流程。 
需要说明的是,在这⼀篇⽂章中,我不会与你⼤量讨论实践细节,⽽是把这些内容放在了后续的⽂章中。 
如何实践⽅法论? 
其实,在研发流程上,最不缺的就是⽅法论,从敏捷到精益再到看板,层出不穷。但,实施效果却不理想。尤其是敏捷,⽆论在硅⾕还是在国内,绝⼤部分使 ⽤敏捷的团队实施得都不理想,导致这个概念的争议很⼤,Scrum 有时甚⾄成了贬义词。 
相⽐之下,像 Facebook、Google 等⾼效能公司,并没有强调使⽤ Scrum、看板等⼯具,研发效能却很⾼。这是不是说敏捷、精益这些⽅法论本身就有问题 呢? 
事实上,虽然 Facebook、Google 这些公司没有明确提及敏捷、精益、看板这些⽅法论,或者没有严格地去使⽤ Scrum 等框架,但在开发流程中却实实在在 地应⽤了这些⽅法论的精髓。所以说,⽅法论实施效果不好,关键在于没⽤好。 
在学习⽅法论的时候,我推荐使⽤类似美国著名作家、企业顾问⻄蒙斯 · 涅克(Simon Sinek)总结的 Why-How-What ⻩⾦圈法则。 
参⻅下图:最中间的⼀个圆是 Why,也就是这个⽅法论的⽬标,是要解决⼀个什么问题;第⼆个圆是 How,也就是这个⽅法论的基本原则、指导思想;最外 层的圆是 What,也就是这个⽅法论的具体实践。
图 2 Why-How-What ⻩⾦圈法则 
这 3 个圆圈,从内向外,是⼀个从抽象到具体,从通⽤到定制的过程。 在使⽤⼀个⽅法论的时候,⼀定要从内往外看。 
  • 中⼼的⽬标⼀般错不了。⽐如,敏捷的⽬标就是快速应对变化。 
  • 原则的通⽤性就差⼀些,你需要在理解的基础上挑选适合⾃⼰的。⽐如,敏捷中有⼀条原则是“⾯对⾯交谈是最好的沟通⽅式”,就不⼀定适合你的团队。 
  • 具体的实践,就更要⼩⼼,切忌⽣搬硬套。 
所以,我们必须⾸先深⼊理解这个⽅法论的⽬标和基本原则,然后根据原则因地制宜地选择具体实践。在选择具体实践时,往往需要在已有实践上做些修改才 能达到效果,否则事倍功半。 
以最容易出现问题的 Scrum 为例。敏捷的⽬标是快速应对变化,⽽ Scrum 就是⽤来服务这个⽬标的。但是,很多团队在使⽤的时候,严格照搬 Scrum 的具 体⽅法,⽽“严格照搬”本身就已经违背了敏捷的⽬标。 
相⽐起来,Facebook 的众多团队,“严格”使⽤ Scrum 的很少,却⼀直在⼤⼒优化管理、开发等流程来快速应对变化,最快找到并满⾜⽤户的最新需求。具 体来说,他们很早就引⼊了 A/B 测试、灰度发布、每周定时全量代码部署等实践。这些都是和敏捷⽅法论相吻合的,也是 Facebook 业务成功的关键技术⽀ 撑。 
在引⼊实践的时候,我的建议是逐步优化已有的开发流程和框架,甚⾄只给出原则,让团队成员逐步摸索并最终找到合适的⽅法。⽐如,你可以把⼀个核⼼原 则通知给团队:“流程中总是有⼀个核⼼瓶颈。找到它,并解决它”。通过这样⼀个基本原则的指导,让具体实践逐步形成,对现有⼯作的影响,以及受到的阻 ⼒都会⽐较⼩。 
了解了怎样使⽤⽅法论,接下来我和你⼀起看⼀组提⾼研发流程的⽬标、原则和实践。其实,这些并不是⼀套全新的⽅法论,⽽是基于 Facebook、Google 等⾼效能公司的实践,并结合对精益、看板、敏捷等⽅法论的思考,我得出来的⼀个总结。 
⽬标⼀:寻找⽤户价值 
以终为始地来看,我们最终⽬的是产⽣⽤户价值,⽣存下去。为此,我们经常需要主动去寻找最好的产品形态。只有⽅向找准了,流程产⽣的结果才能有效, 才能产⽣⽤户价值。所以,优化研发流程的第⼀步,就是提⾼寻找⽤户价值的效率。 
在这⼀点上,精益创业(Lean Startup)系统最有效。虽然名字⾥⾯有创业⼆字,也有较多商业模式设计和⽤户开发⽅⾯的内容,但它有两条原则值得作为开 发流程的参考。 
第⼀条原则是:衡量每⼀个时间段成果的标准,应该是价值假设⽅⾯的进展。也就是说,你的⼯作应该让你学习到如何更好地给⽤户提供价值,⽽不是开发了 多少功能。 
举⼀个极端的例⼦。⽐如,你的团队在⼀⽉份开发了 5 个功能,⽤户反馈都⼀般。这时,你看不出⽤户更喜欢什么东⻄,更讨厌什么东⻄。⽽在⼆⽉份,你 们只开发了⼀个功能,预计很有⽤,但收到的⽤户反馈却是负⾯的,被迫连夜回退了这个功能。 
那么,哪个⽉的成果更好呢?显然是⼆⽉份,因为它能明确告诉你,这个假设是错的,让你们在寻找产品符合市场吻合度(Product-Market-Fit)上前进了 ⼀⼤步。 
第⼆条原则是:使⽤最⼩可⾏性产品(Minium Viable Product,MVP)来帮助学习。这⾥的关键点是,要以探索价值为出发点设计产品,最快地验证你的假 设,功能要尽量少,能够使⽤就可以。具体的⽅法有数据驱动、A/B 测试、灰度发布等。 
在 Facebook ⼯作的时候,我们开发⼀个功能时,都会提前计划要验证哪些假设,然后设计怎样收集数据才能够验证这些假设。这样⼀来,功能上线的时候 就开始收集数据了,⼀旦发现功能不能提供⾜够的⽤户价值,就把这个功能下线,从⽽确保每个功能都是本着提供⽤户价值的⽬的去的。 
同时,公司也会不断投资 A/B 测试等试验框架,让开发⼈员能够尽量容易地收集和处理数据。这种开发⽅式有⼀个名字,叫作度量驱动开发(Metrics Driven Development)。如果你想深⼊了解这种开发⽅式,可以参考 Uber 公司的这篇⽂章。 
⽬标⼆:提⾼⽤户价值的流动效率 
软件研发是⼀条流⽔线,⾥⾯流动的是⼀个⼀个给⽤户提供价值的功能。那怎么提⾼这条流⽔线的效率呢?也就是,如何提⾼⽤户价值的流动效率。 
这⾥有 4 条⽐较直观的基本原则: 
  • 第⼀,让功能尽快地流动; 
  • 第⼆,让节点之间的联动更加顺畅; 
  • 第三,节点之间的融合; 
  • 第四,发现整个流程中的瓶颈,并解决它们。
接下来,我们分别看看这四条基本原则。 
第⼀,让功能尽快地流动,说⽩了就是快速开发。问题发现得越晚,修复代价越⾼,这已经是常识。要做到快速开发,开发⼈员需要尽量把功能拆分同时做 好⼀个提交之后尽快提交。要做到这⼀点,关键原则是降低提交的交易成本(Transaction Cost)。 
提交的交易成本指的是,每⼀个提交都需要做的额外⼯作。只有把这个⼯作量降下来,才能让功能拆分有价值,否则就会抵消掉拆分带来的好处。  
具体⼯程实践包括提⾼本地构建速度,提供⽅便的⾃测环境、测试⾃动化、持续集成、定位问题提交⾃动化等。快速开发这个话题是开发⾼效的关键因素,我 会在下⼀篇⽂章中与你详细讲述。 
第⼆,让节点之间的联动更加顺畅,可以通过对关键流程的⾃动化、⼯具之间的⽹状互联,以及节点之间的融合来实现。在具体实践上,个⼈代码上线后,在 和他⼈的代码集成时容易出现问题,这时就可以使⽤ CI/CD(持续集成 / 持续交付)流⽔线来⾃动化代码集成过程。 
尤其是 CI,基本上对所有软件开发公司都很有价值。我们⼀定要尽量⽤上 CI。 
另外,有些公司有从需求到开发到上线的⼀条⻰流⽔线,也被叫作开发者桌⾯。国内的公司,尤其是⼤公司很喜欢这种⽅式。它的好处是,可以把很多底层的 东⻄隐藏起来,容易上⼿。但它的缺点就是灵活性不够,毕竟难以⽤⼀条流⽔线做到⾼度的定制,来满⾜各种各样的⾼效开发。 
开发者桌⾯的全景图如下所示。开发者桌⾯作为核⼼节点,连接其他所有⼯具,各个⼯具之间也有⼀些连接。 
图 3 开发者桌⾯的全景示意图 
在 Facebook 和 Google,并没有⼀个端到端的流⽔线,它们采取的⽅式是:让这些流程中使⽤的⼯具通过开放的 API 进⾏⼀个⽹状连接,从⽽开发者可以灵 活定义⼩范围的流程,⾼效⼯作。在这个⽹状结构⾥⾯,关键节点会作为重要节点⼤量连接其他流程中的⼯具,公司对这些关键的、⼩范围的流程进⾏⼤量优 / 化。 
⽐如下⾯这张图⽚,⼀共有 11 个⼯具,互相之间连接很多,形成⽹状结构。其中⼯具 4 和⼯具 9 是关键节点,与很多⼯具有连接。 
图 4 ⼯具⽹状连接示意图 
⽐如在 Facebook,代码审查⼯具 Phabricator 是⼀个关键节点,可以⽀持代码审查、代码静态检查、单元测试、集成测试、前后端联调等关键开发⼯作。这 ⼀组⼯作就是上⾯提到的⼀个关键的、⼩范围的流程。 
最近⼏年由于 IDE 的发展,Nuclide 成为了⼀个新的重要节点。开发者可以在 Nuclide ⾥直接进⾏⾼效的代码开发,以及代码审查等⼀系列⼯作。类似地, Google 的 WebIDE 也是⼯具链的⼀个重要节点。 
从我个⼈的经验看,这种⽹状结构提供的灵活性,对提⾼开发效率和提升开发体验,都有积极的促进作⽤。 
第三,节点间的融合,也是为了保证节点间的联动顺畅。也就是模糊节点间的边界,让功能在节点之间的流动更顺畅。在这⼀⽅⾯,我⻅到⽐较有效的⽅式 是:职能团队提供平台和⼯具,让全栈⼯程师能够⾃⼰处理端到端的⼯作。⽐如,测试团队提供测试平台和⼯具,运维团队提供运维平台和⼯具,这些平台和 ⼯具可以通过服务化⾃助使⽤。 
⽐如,在 Facebook 没有专职的测试⼈员,只有测试⼯具团队,运维⼈员也很少,主要是提供⼤量的⼯具让开发⼈员能够⾃⼰进⾏测试、运维的基本⼯作, 实现开发⼈员在“开发、测试、运维”这⼏个步骤上的全栈⼯作。因为开发⼈员对⾃⼰开发的功能最为熟悉,所以这种端到端的全栈⼯作⽅式,可以让开发和调 测效率达到最⾼。在国内,我看到阿⾥云效也在推荐这种⽅式。 
第四,发现整个流程中的瓶颈,并解决它们。约束理论创始⼈艾利 · ⾼德拉特(Eliyahu Moshe Goldratt)在 20 世纪 90 年代,提出了解决约束的聚焦五步 法,⾄今仍然适⽤软件研发这个价值流体系。具体步骤如下: 
  • 第⼀步,找到系统中的瓶颈; 
  • 第⼆步,最⼤限度地利⽤(Exploit)瓶颈,尽量通过提⾼效能的办法解决瓶颈; 
  • 第三步,让企业的所有其他活动都让步于瓶颈改善⼯作; 
  • 第四步,打破(Elevate)瓶颈,如果第⼆、三步⽆效,就通过给瓶颈节点增加资源的⽅法来解决瓶颈; 
  • 第五步,重返(Repeat)第⼀步,找出新的瓶颈,持续改善。
具体的实践有可视化和复盘。 
在可视化⽅⾯,粘上便利贴的⽩板,或是像 Trello 那样的电⼦看板就是很好的⼯具。  
图 5 可视化实践示意图 
这⾥我需要强调⼀下,我们⼀般把这种任务卡⽚化的系统叫做看板,但它并不是真正的“看板”,只是⼀个任务可视化的⾯板⽽已。 
真正的“看板”是信号卡⽚,⽤来表示流⽔线系统可以增加新的⼯作项了。后⾯我会详细介绍。通过任务可视化,我们可以直观地看到哪⼀个环节的任务特别 多,卡住了,也就是瓶颈在哪⼉。另外,前⾯⽂章提过的累积流程图,也是发现问题的⼀个有效⼯具。 
另外,统计图表和仪表板也是很不错的⼯具。在 Facebook,任务管理系统、部署系统、代码审查系统的 API 是开放的,各个团队可以⽅便地查询数据制作图 表。在仪表板⽅⾯,2014 年的时候就有 4 个系统可使⽤。⼤部分的统计图表和仪表板,都是⾮⼯具团队⾃⼰开发出来并最终推⼴全公司使⽤,定制功能也很 强。 
在复盘⽅⾯,Facebook 做得也很好。他们有⼀个 SEV 复盘系统,⽤来记录公司发⽣的重要事故进⾏复盘。每个团队也会不定期地复盘,以定位瓶颈问题并 提⾼。 
举⼀个复盘⽅法的例⼦。我在国内某公司遇到⼀个问题,就是团队在协作上配合不积极,出了问题不是先去解决问题,⽽是先想⽅设法甩锅。为解决这个问 题,我引⼊了线上事故回溯讨论会,每两周⼀次,对发⽣的事故进⾏讨论,重在根因分析和以后如何避免,并事前强调⽬的不是追责。因为,每个故障分析都 能暴露出藏在深处的问题,对提⾼产品质量和团队间的信任效果都很好。 
⼩结 
优化流程,是提⾼研发效能的第⼀步。我们应该按照⽬标、原则和具体实践的顺序学习和使⽤各种⽅法论,选择和配置最适合⾃⼰团队的⼯程实践。 
我基于 Facebook、Google 等⾼效能公司的实践,并结合对精益、看板、敏捷等⽅法论的思考,给你介绍了“寻找⽤户价值”和“提⾼⽤户价值的流动效率”两 条⽬标,以及它们对应的 6 条原则和若⼲具体实践。 
从我的经验来看,⾼效的研发⼯作流,对产品质量和研发速度⾄关重要,同时可以提升员⼯的幸福感,进⽽保证持续的⾼效产出,提⾼研发效能。 
Facebook 在流程⽅⾯的实践,给我最⼤的⼀个感受就是,以实⽤主义的态度,从原则出发,灵活优化流程。在 Facebook 的⼏年时间⾥,我并没有听到很 多新⽅法论的时髦术语,但是公司的很多实践却和这些⽅法论的原则是⼀致的,甚⾄是超前这些⽅法论的。 
⽐如,在 DevOps 流⾏前的很多年,Facebook 就开始了打通开发和部署的⼯作,以及推⾏全栈⼯程师的⼯作⽅式。 
从实际出发、以终为始的实⽤主义,是我从 Facebook 学到的⾼效研发的最重要原则,没有之⼀。 
思考题 
你理解的精益看板,跟⽂中提到的任务可视化⽩板⼀样吗?你知道它们之间的关系吗? 
感谢你的收听,欢迎你在评论区给我留⾔分享你的观点,也欢迎你把这篇⽂章分享给更多的朋友⼀起阅读。我们下期再⻅!

发表评论

您的电子邮箱地址不会被公开。