研发效率破局之道
葛俊
前Facebook内部工具团队Tech Lead
立即订阅
3343 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要关注研发效能?
免费
研发效能综述 (3讲)
01 | 效能模型:如何系统地理解研发效能?
02 | 效能度量:效果不好甚至有副作用,怎么回事?
03 | 效能度量:如何选对指标与方法,真正提升效能?
研发流程 (7讲)
04 | 流程优化:怎样才能让敏捷、精益真正为我所用?
05 | 代码入库前:Facebook如何让开发人员聚焦于开发?
06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?
07 | 分支管理:Facebook的策略,适合我的团队吗?
08 | DevOps、SRE的共性:应用全栈思路打通开发和运维
09 | 信息流通:让团队高效协同,让产品准确击中目标
10 | 答疑篇:反对996并不是反对奋斗
工程方法 (10讲)
11 | 研发环境:Facebook怎样让开发人员不再操心环境?
12 | 代码审查:哪种方式更适合我的团队?
13 | 代码审查:学习Facebook真正发挥代码审查的提效作用
14 | 质量与速度的均衡:让“唯快不破”快得更持久
15 | 开源:从Phabricator的开源历程看开源利弊
16 | 高效上云:如何用云计算来提高效能?
17 | 测试左移:测试如何应对新的开发模式?
18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?
19 | 不再掉队,研发流程、工程方法趋势解读和展望
20 | 答疑篇:如何平衡短期收益和长期收益?
个人效能 (11讲)
21 | 高效工作:Facebook的10x程序员效率心法
22 | 深度工作:聚焦最有价值的事儿
23 | 效率工具:选对用对才能事半功倍
特别放送 | 每个开发人员都应该学一些VIM
24 | VIM:如何高性价比地学习VIM的实用技巧?
25 | 玩转Git:五种提高代码提交原子性的基本操作
26 | Facebook怎样实现代码提交的原子性?
27 | 命令行:不只是酷,更重要的是能提高个人效能
28 | 从工作场景出发,寻找炫酷且有效的命令行工具
29 | 1+1>2,灵活的工具组合及环境让你的工作效率翻倍
30 | 答疑篇:关于价值导向和沟通
管理和文化 (6讲)
31 | 业务目标和技术目标两手抓:怎样打造高效团队?
32 | 从Netflix公开的著名PPT谈硅谷公司文化
33 | Facebook企业文化:工程师文化是创造力引擎
34 | Facebook工程师文化实践三大支柱之一做感兴趣的事
35 | Facebook工程师文化实践三大支柱之二拥有信息和权限
36 | Facebook工程师文化实践三大支柱之三绩效调节
结束语 (1讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

04 | 流程优化:怎样才能让敏捷、精益真正为我所用?

葛俊 2019-08-30
你好,我是葛俊。今天我们来聊聊怎样从流程方面来提高研发效能。
从这一篇文章开始,我们就正式进入研发流程模块了。在第 1 篇文章中,我与你强调了软件开发的最大特点在于它是一条非常灵活的流水线,因此提高研发效能的第一步就是优化流程。
图 1 提高研发效能的第一步就是优化流程
因为优化流程会涉及方法论,所以我会先和你介绍高效实践方法论的关键要素。然后,我会按照目标、原则和实践 3 个层次,从抽象到具体,给你逐步讲解如何优化流程。
需要说明的是,在这一篇文章中,我不会与你大量讨论实践细节,而是把这些内容放在了后续的文章中。

如何实践方法论?

其实,在研发流程上,最不缺的就是方法论,从敏捷到精益再到看板,层出不穷。但,实施效果却不理想。尤其是敏捷,无论在硅谷还是在国内,绝大部分使用敏捷的团队实施得都不理想,导致这个概念的争议很大,Scrum 有时甚至成了贬义词。
相比之下,像 Facebook、Google 等高效能公司,并没有强调使用 Scrum、看板等工具,研发效能却很高。这是不是说敏捷、精益这些方法论本身就有问题呢?
事实上,虽然 Facebook、Google 这些公司没有明确提及敏捷、精益、看板这些方法论,或者没有严格地去使用 Scrum 等框架,但在开发流程中却实实在在地应用了这些方法论的精髓。所以说,方法论实施效果不好,关键在于没用好。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 囧囧冰淇淋
    一个问题:大公司流行的方法论,为什么到我们身上就没用了?

    1.原封不动的照搬。
    2.文中提到的WHY?HOW?WHAT?没有思考
    WHY=为什么会发生这个问题?原因在哪?
    HOW=找到原因后我们该怎么做?
    WHAT=做完后我们得到了什么?不正确就返回WHY
    3.管理和员工传达不准确,只有向下的传达,没有向上的反馈。

    当团队思考清晰后,不再是看哪个方法论流行就套用,而是根据目前存在的问题去寻找答案。

    实践原则时候则有二个目标:
    1.寻找用户价值
    2.提高用户价值的流动效率

    用户价值,PM或者运营接触的更多,接触的更近,这里要和团队追求的用户价值一样,需要协同思考。挺担心PM或者运营解释模糊,甚至要求开发直接做出来,干好自己的本分,别多问。在前面有看见说:“开发周期长,经常加班,上线时间紧急,上线BUG不断,都是PM经常改需求造成的,PM最后还甩锅开发完不成。”实践原则的第一个目标寻找用户价值,不仅仅对开发提出了问题,还要求团队之间的相互支持和信任。

    有了上面条件后,我们就可以把寻找的过程拆分为两个:
    1.衡量每一个时间段成功的标准,应该是价值假设方面的进展。
    2.使用最小可行性产品来帮助学习。
    为什么是这两个参考呢?单纯看数量,团队会因为利益的问题只把数量推高,公司不知道哪个成功、哪个失败。就像第三篇有团队做出了50+个微服务,但每一个都没用,大家是完成了指标,但是公司利益,用户价值全被丢一边了。
    用价值时间段成功为团队指引方向,最小可行性产品为团队改进优化,形成一个正向循环。


    用户价值流动效率,它包括四个点:
    1.让功能尽快流动
    2.让节点之间的联动更加顺畅
    3.节点之间的融合
    4.发现整个流程中的瓶颈,并解决
    个人理解这里更关注人,关注技术的沟通。缩短生产周期,提高不同工具之间的流通效率,个人工作的流畅性,出现问题后如何找到问题和复盘问题。
    运营岗位,我要做的是和其他部门沟通,看看他们的问题是什么?我有什么工具或者数字可以作为一个指标而不是kpi来指引方向。对于自己而言,则是如何改进优化工作。

    思考题:
    第一次看到。目前理解的是梳理工作流程,找到问题积压最多的一个地方,我可能套用不了。

    作者回复: 关于思考题,有空可以看一下这本书理解看板:
    中文版:https://book.douban.com/subject/25788807/
    英文版:https://book.douban.com/subject/5350839/

    2019-08-30
    2
    3
  • 小树苗
    我会在看板中针对每一道工序都设定两个环节,一个是等待中,一个是处理中,处理完的就到下个工序的等待中或处理中。我们会合理控制处理中的在制品数量,于是等待中就会有任务堆积,当某个工序的等待中的任务数量多起来了,我们就会去分析这中间有什么问题,一般问题分为三类,资源数量(人不够多),资源能力(人不够强),资源协同(流程机制方面的的问题)。
    既有可视化面板的作用,也有看板的作用,不过现在是用一块白板搞的,没有屏幕,也没有系统,所以白板上写完,还要录到文档里,比较麻烦。

    作者回复: 赞!这个是正确使用看板的姿势。工具麻烦一点不要紧,慢慢慢提高,关键是方式正确。

    至于具体工具,Trello这样的应该可以实现你们实用的这种工作流呀?

    推荐阅读:4 BENEFITS OF WIP LIMITS(https://leankit.com/learn/kanban/benefits-of-wip-limits/)

    2019-09-01
    2
  • Winon
    “在具体实践上,个人代码上线后,在和他人的代码集成时容易出现问题”---这个问题老师可以给出具体的实例吗?我理解本地构建经过两步:第一步是自己的代码的本地构建,第二部是拉取最新代码仓库的代码进行集成后的本地构建。如此之后,在什么场景之下,还会有代码集成的问题。这种问题多吗,还是极少数情况?

    作者回复: > 我理解本地构建经过两步:第一步是自己的代码的本地构建,第二部是拉取最新代码仓库的代码进行集成后的本地构建。
    一般本地构建并没有要求做第二步。如果做了第二步,实际上是你在代码入库之前,在自己的本地做过了集成验证。所以会避免很多上面提到的”再和他人代码集成时出现问题”

    2019-09-14
    1
  • 曾轼麟
    我们公司的看板会分为:待评审需求,已评审需求,转开发,开发中,转测试,测试中,待上线(任务纬度),需求底下由开发自己创建任务,一个需求,不同的任务有时可以分开上线有时候需要一起上线,通过这样分可以了解到,需求消化瓶颈在哪,可以针对,开发,测试,产品进行优化

    作者回复: 看起来你们的看板使用的不错👍

    你们有限制WIP吗?

    2019-09-08
    1
  • 舒偌一
    围绕提高用户价值的目标出发,尽快让用户验证我们现在做的事是正确的,为了提高速度,利用工具让节点通达,使用任务看板和进度工具找到瓶颈。我们使用任务看板和员工日志,系统识别哪个任务超出预期了。我们现在的瓶颈是需求不细、用户验证慢,导致连带返工。

    作者回复: > 我们现在的瓶颈是需求不细、用户验证慢,导致连带返工。
    你们有什么提高计划吗?

    2019-08-31
    2
    1
  • 杜林
    看了下面的评论,有所老师总结的好的,有说有些东西太形式主义了的

    大学学的东西,出生社会工作后才发现,几乎全是「形式主义」,那大家怎么把这个社会向前推动的呢?

    方法论没有对错,大学老师给你讲授的课程,是让你通过3-4年的学习,带领你到这个行业,出来以在这个行业如何发展、还得靠自己的努力

    葛老师给给我们教授的也是方法论,希望我们有高效研发的意识,这个很重要,没有这个意识和意愿再多干活也没有,其次根据自身公司、 所处工作环境去摸索一套适合自己、 适合公司的流程和方法才是重点

    作者回复: 越灵活的东西,越需要掌握本质。

    2019-08-30
    1
  • 刘培培
    最近正在把部门所有的移动 App 接入基本的 CI,直接用 gitlab ci 工具最简单,之前试过 Jenkins 可把我烦死了。

    作者回复: Jenkins 比较麻烦,但是比较成熟,跟其他工具集成比较完备。 GitLab CI比较新,好用很多,但是有一些场景应该不支持(新的东西的通病)。如果你们的场景能使用GitLab CI,那就最棒了。

    2019-08-30
    2
    1
  • 栗芳凯
    无招胜有招
    2019-08-30
    1
    1
  • 红旗漫卷西风
    在复盘方面,Facebook 做得也很好。他们有一个 SEV 复盘系统,用来记录公司发生的重要事故进行复盘。能否请教这个复盘系统主要的功能是什么,主要记录哪些关键的信息?

    作者回复: 好的,我后面文章里面做一些详细介绍。

    2019-09-17
  • Dragoonium
    我司的开发瓶颈,在于中间件。每个产品都要用到少则五六个多达十几个的中间件,那那些中间件都是在不同的国家开发的,质量良莠不齐,互相的依赖性又很强,幸好有CI的存在,对于新安装的产品,中间件表现还行,但对于已经安装好的产品在升级时,由于组件版本繁多,升级路径扑朔迷离,基本上产品的每个版本,要花费六成的资源在中间件的整合与升级上,团队苦不堪言。

    作者回复: 这些组件都是在不断更新吗?
    安装好的产品升级,总是使用最新的版本,还是有的情况继续使用旧版本?

    2019-08-31
  • Robert小七
    云效目前自身的问题还是挺多的,但是对于流程方面的建设确实不错!比如老师提到的复盘系统,云效有与之对应的故障台!云效开发模式中,开发利用云效平台拉取分支,编码后可以一键构建部署,之后进入运维系统查看是否有问题,自行快速回滚!云效商业化后,对很多传统公司都起到了一个很好的效能提升!

    作者回复: 云效对推动国内企业对研发效能的重视度,起到了很重要的作用

    2019-08-31
  • 囧囧冰淇淋
    软件开发会用到钉钉么?如果用到,会要求写日报,周报,月报不?写短了被批评,长了也很少人看,大家都很痛苦的那种?

    作者回复: 日报,周报,月报如果用得好,可以达到至少两大作用:1. 沟通信息并电子化;2. 促进自己和团队计划、总结、反思

    > 写短了被批评,长了也很少人看
    主管要明确这些周报的作用。让花在写报告的时间花得值得。

    2019-08-30
    2
  • 许童童
    老师总结得很好,我也很喜欢Facebook这种实用主义,很讨厌形式主义,我们就冲着目标去,完成目标,达到目标,遇到问题解决问题,而不是为了敏捷而敏捷,站会要不要开怎么开,都可以根据团队的需要去设定。寻找用户价值、提高用户价值的流动效率,这两个目标是今天的重点,要记在心里。

    作者回复: 👍👍👍

    2019-08-30
收起评论
13
返回
顶部