「2020 China DevOpsDays 大咖说」是一档敏捷和 DevOps 领域的直播访谈类节目,邀请业界专业、有态度的实践者,分享敏捷和 DevOps 的观点思路及实践经验。
对话嘉宾简介
主持人:
张乐,DevOpsDays 中国区组织者,京东 DevOps 与研发效能技术总监,负责 DevOps 工具链产品体系化建设工作。
许峰,DevOpsDays 中国区组织者,数字化转型方面的独立咨询顾问,也是 DevOps,敏捷精益,VeriSM 数字化服务管理的讲师。
本期嘉宾:
何勉,阿里巴巴云研发部门资深技术专家,研发效能方法和解决方案团队负责人,曾帮助不同的组织实施精益敏捷交付和创新实践,提升研发交付和创新效能,其中既包括阿里巴巴的新零售、云智能、大文娱等 BG,也包括外部企业客户。何勉是《精益产品开发:原则、方法与实施》一书的作者,国内最早的精益产品开发的实践者和传播者。
我们要的不是规模化敏捷
而是敏捷的规模化
所谓的规模化敏捷方法,往往先设定一个相对固定的组织结构,但恰恰这个会限定软件的灵活性。总结下来,我认为我们要的不是规模化敏捷,而是敏捷的规模化。我提出两个观点,第一,我们首先考虑的不是接受复杂的组织结构或者协作模式,而是考虑怎样 Scale down 和 Scale out,第二点,不要固化组织结构,否则会适得其反。
许峰:何老师怎么看规模化敏捷,以及敏捷的规模化?您是赞成哪一派?
何勉:哈哈,我不去站队,一切还是要从业务出发。我认为的确不存在规模化敏捷这件事情。当前在互联网行业面临的一个问题,就是协作路径在变长、复杂度在变高,但是绝不能因为有复杂的组织和协作结构,就需要一种规模化的敏捷方法。如果你通过一种方法把今天的组织结构固定下来,比如 Portfolio 层级,Program 层级,Team 层级,就是本末倒置了,反而让协作和软件变得更复杂。这是一个逆向的康威定律。
当我们面临复杂问题时,首先要考虑 Scale down,能否能把规模变小,再看能否 Scale out,也就是所谓的水平扩展,去变成一个自治的群体。我们最终追求的是敏捷的规模化,让整个组织都能变得越来越敏捷,能更快的去响应,不管是像阿里这样的,还是像亚马逊那样“两个披萨”的团队,其实都是一种水平扩展的方案,也就是先 Scale down 再 Scale out 的方式。这一定是代表未来方向的。
但我们看到一些规模化敏捷的方法,是反其道而行之的,它不是在 Scale down,我也不相信规模化敏捷方法比如 SAFe和 LeSS。他们的初衷是也许是好的,但是我看到现实中很多做成了这样,他们迎合了复杂组织的现状,而且好像还挺自豪。我觉得这个肯定是舍本逐末、甚至是南辕北辙的。
Craig Larman(克雷· 拉蒙)是 LeSS 方法的提出者,但是我更喜欢他之前的关于大型精益和敏捷开发的著作,他讲到了康威定律,也就是软件结构会复制组织结构,Craig Larman 对康威定律做了一个推论:软件结构会复制组织结构,但业务是很灵活的,因此软件也需要很灵活,所以组织结构也就应该很灵活。但后面提出的规模化敏捷的模型,多少与这个相违背。规模化敏捷是来自于电信领域的方法,对于方法和框架我不做评价,但一定要意识到它背后的假设是否适合你。比如说 LeSS,它认为你的组织一定是一个树状结构,PO 面对的需求和团队都是树状的,有树状的 Product Backlog。而实际上互联网公司无论需求还是组织都是网状化的,一个技术团队要支持多种业务,来了新业务也要去支持。我相信未来软件世界一定是网状的,所以组织结构必须非常灵活。
所谓的规模化敏捷方法,往往先设定一个相对固定的组织结构,但恰恰这个会限定软件的灵活性。总结下来,我认为我们要的不是规模化敏捷,而是敏捷的规模化。我提出两个观点,第一,我们首先考虑的不是接受复杂的组织结构或者协作模式,而是考虑怎样 Scale down 和 Scale out。第二,不要固化组织结构,否则会适得其反。
许峰:对于传统的金融企业或者银行,已经形成了比较固化的、多年形成的组织结构,是否可以先用一个规模化敏捷框架先把它框住,比如说我先规范一套流程,在这个过程中我总会实现一些效能改进。何老师觉得这样的说法有道理吗?
何勉:为了改进先去规范,是有一定的道理的,但记住永远不是去固化它。我们的组织结构要去服务价值流,而不是相反。我觉得招行就做得很好,他并不是去引进一个模型,而是真的去梳理价值流,然后通过价值流去规范流程,最后在不断优化的过程中,最终催生了组织结构的变革,这是精益思想,是我看到的一个好的案例。
但在这方面,我没看到规模化敏捷有好的案例,可能是我比较孤陋寡闻,有的话大家可以告诉我。但对所有的东西也不能一棒子打死,比如 SAFe 在 2.0 以后也做了很大的演进,也强调了对于价值流的管理,但要当心副作用,避免固化组织结构,要记住组织结构服务于业务模式。
对10倍效能充满信息
也充满了使命感和责任感
我对这个 10 倍效能充满信心,也充满了使命感和责任感。我们一定要端到端的去看,一定要落到具体实践上面,这些提升绝不来自于度量,也绝不会来自于刚才讲的规模化的方法,而一定是来源于创新、需求分析、软件设计这些具体的实践,在这方面已经有了一些突破。
张乐:去年有人在推特提出一个话题,关于 10 倍效能提升。从您的角度来讲,10 倍效能提升是有可能性的吗?
何勉:一定是有可能性的,我还不知道推特上有人讲这个。最早提出这个问题应该是彼得·德鲁克,管理学大师。他指出 20 世纪体力工作的效率提高了 50 倍,在 21 世纪我们知识工作者的效率能不能提高 50 倍,他认为应该可以做到。
软件开发是我们最重要的知识工作,首先我们看从理论上有没有 10 倍的空间?比如说从响应速度,我觉得是有可能的。我们服务的一家公司,版本周期从两个月到一周,业务需求的交付周期中位数在一个星期,那么这是不是 10 倍呢?10 倍的过程质量我也看到过,比如 BUG 存量从几百个变成 10 来个,都超过了 10 倍。而且过程的质量会影响最终交付质量,甚至于长期质量。
但在软件过程中最大的浪费是交付了那些没有用的东西。因此最难的是 10 倍的有效价值交付,但我认为是也有可能的,而恰恰这一点难以度量。像刚才说的那家公司,把两个月的交付周期变成了一周之后,反馈快了,一系列的创新实践和需求分析实践都可以很快展开,相比过去在一个业务上探索两三年一直不成功,我们把这一块做好了以后,很快就在业务取得巨大的成功,这个才是那个真正的效能提升。
我们最近探讨,在软件开发领域,未来 10 年什么会变什么不会变?我觉得工程方法会变,我相信会有越来越多的好工具,交付生态一定会朝好的方向改变。
但什么不会变?我们写代码,无非是把物理世界的需求转化为数字世界的,我们把它分析好抽象好,然后更快的去实现它,去完成转化,然后在数字世界里又产生了新的可能。软件开发的本质不会变。
业务分析不会变,再往前走,就是商业模式的设计和验证,这两方面有巨大空间,绝对可以贡献 10 倍有效价值,而且我也看到一系列成功的案例。我再强调一下,我对这个 10 倍效能充满信心,也充满了使命感和责任感。
在整个环节里,我们一定要端到端的去看,一定要落到具体实践上面,这些提升绝不来自于度量,也绝不会来自于刚才讲的规模化的方法,而一定是来源于创新、需求分析、软件设计这些具体的实践,在这方面已经有了一些突破。
许峰:何老师在精益方面耕耘了很长时间,是一名布道者。我看到一个有趣的现象,就是特斯拉的市值已经超过丰田。
丰田我们讲 TPS 或者精益思想,其实把人和系统都是作为一个并重的存在,通过人去持续优化系统。但是现在我们会看到,比如亚马逊的转运仓储,比如外卖小哥,其实是机器和算法在指挥人在不停的奔跑。所以我们要讲一讲人。对于丰田这种方法是能够长期存在,还是说算法最后会取代很多人?
何勉:我比较喜欢历史,尤其是工业发展史,包括几次工业革命。特斯拉和丰田也是有渊源的,他们收购了丰田和通用的合资工厂。当年丰田在看福特,福特是科学管理的践行者,可以追溯到泰勒和老福特,他们共同创造了科学管理,当时是讲大批量流水线。但是当你看大野耐一关于 TPS 的书,有这么一句话“如果福特今天还活着的话,他一定会同意我的方法的。”大野耐一是非常尊敬福特的,但是他认为时间变了,所处的技术环境变了,情况会不一样,所以老福特一定会同意他当时的做法。但别人往往会把丰田的尊重人和泰勒科学管理的流水线机器化对立起来看,但是在真正的大师大野耐一眼里,他是对这个东西的继承,因为背后的本质跟福特当年是一样的,都是为了更高的效率和用户价值。
今天的特斯拉,也是因为技术环境变了,当然实践也跟着变,但是丰田当年讲人治化的自动化,是说要给自动化赋予人的智慧,而特斯拉是从第一性原理去考虑这个问题的,都是为了更快的交付价值。特斯拉会考虑如何能让同样面积的工厂能产出更多的特斯拉,大家可以想象,流水线上流动的速度决定了生产速度,但如果有人在流水线上面,生产速度就不可能快。因为人的动作不可能比机器快,流动快了可能会伤害到人,所以要把人撤出来。但是在丰田那个时代,撤人是不可能的。
所以情况是不一样的,但都是为了更快的交付价值,因此我们不能简单的去看。但是最后再回到人文这个问题,我还是相信技术最终是服务于人的,虽然有的时候现实很残酷,但是我们做技术的还是要有人文情怀。
许峰:关于需求分析实践,创新的实践,有没有什么推荐的书?
何勉:创新的实践,我比较推荐的是《创新者的任务》。作者是克莱顿·克里斯坦森,哈佛大学的教授。它就讲我们做一个产品真正的是要解决,你要理解用户的问题是什么,他的一个概念即他所谓的 JTBD 模型(“Job-to-be-done”),这个产品是要解决什么问题。这不是一本专业的关于需求的书,但是关于需求背后思想的一本书,一定是值得去看的,因为可能是也是在创新领域被引用最多的。
关于需求分析方法,推荐一个叫《事件风暴》,这个方法是源自于 DDD 社区,你看它能给你在业务分析上面能有什么样的启示,另外一个就是实例化需求的介绍。
许峰:两本书一本是《创新者的任务》,然后后面一本是《事件风暴》即《Event Storming》。
何勉:《事件风暴》一本试读版电子书。关于实例化需求的,是有一本同名书的,也可以搜索我的文章。后来我知道的很多人是看过这篇文章,事实上很多看过这篇文章的人,真的是跟着在实践。关于需求实践,现实中我如果去指导一个100多个的团队,协作实践可能不会超过半小时,为什么?我前期会把大部分的时间用来做业务分析,而业务分析和需求分析做好了以后,那些后面的协作实践几乎是水到渠成的,所以多花一点时间在需求实践上。
——————
ONES 企业级研发管理工具,覆盖研发全生命周期管理,为不同行业、不同规模的研发团队提供灵活易用的敏捷开发管理解决方案,助力企业更好更快发布产品。
想了解 ONES 如何帮助您高效管理研发?欢迎访问 ONES 官网 https://ones.ai 或点击阅读原文进行免费试用!
相关阅读:
ONES 年终报告 | 功能升级123次,服务超100万客户
独家 | 大型团队敏捷研发管理实践与思考
Gartner:企业如何选择合适的敏捷项目管理工具