演进式架构从不缺设计方法,最大的阻力在于「人」

8月18日,极客邦科技旗下 InfoQ 主办的 ArchSummit 全球架构师峰会在北京举行,本届峰会以「升级架构思维、支撑业务发展」为主题,聚焦前沿趋势与技术实践案例分享。

作为企业级研发管理工具的领军者,ONES 受邀出席本次大会。ONES 研发总监陈亮宇发表了题为《后架构时代:技术管理如何助推架构持续演进》的演讲,与各行各业的技术管理者、架构师一起,分享 ONES 在演进式架构设计中的思考与实践。

以下是陈亮宇演讲的精华内容。

01「后架构时代」有哪些特点?

「后架构时代」又称为「演进式架构设计时代」,这一时代主要有以下三大特点:

  • 市场环境急速变化,业务高速发展,架构设计也要不断演进,以适应业务需要;

  • 随着企业规模的壮大,架构设计的腐化无法避免,只能在演进中持续进化;

  • 架构可以在不破坏原有架构的基础上增量式变化。

02 演进式架构的困境有哪些?

演进式架构从来都不缺设计方法,最大的阻力在于「人」。正如著名的康威定律(Conway's Law)中所说,「设计系统的架构受制于产生这些设计的组织的沟通结构」,换言之,制约系统架构的是组织架构,也就是人。

那么,「人」会带来哪些问题呢?

  • 职能型架构团队存在众多角色,如后端架构团队、前端架构团队、运维架构团队等等,不同职能有不同的架构目标;

  • 架构支撑业务,需要协同跨职能、跨部门协同多个团队,管理难度大;

  • 研发团队的管理也要贴合架构目标。 

03「如何走出「人」的困境?

架构设计是一个生产过程,会经历从设计、实现到交付的完整生命周期,流水线是提高生产效率的有效方法,构造高效的生产架构流水线,能够减少「人」这一变量可能会带来的问题,帮助我们走出困境。

解决问题的直觉框架

遇到问题时,我们通常会按四个阶段进行处理:

  • 发现问题:知道问题是什么?要改变什么?

  • 分析问题:问题产生的根本原因是什么?要改变成什么样?

  • 解决问题:基于问题分析的结果,找到解决的办法;

  • 复盘问题:量化结果,复盘过程,持续改进,并发现下一个问题。

ONES 的实践分享

接下来,我们会从 ONES 的实践出发,围绕「发现-分析-解决-复盘」这一问题解决框架,和大家分享如何利用产品建立公开透明的反馈循环,构造高效的架构流水线。

(1)发现问题

不同的视角会有不同的反馈,因此,要发现问题,我们必须要从内到外全方面的收集反馈。

以 ONES 为例,要分析架构流水线上的问题,我们需要从内部架构团队和外部业务团队两个维度,识别出要解决的问题。

内部压力

  • 要深入了解过往的架构设计,在重构的同时,保证 ONES 的业务正常运行;

  • 计划是 ONES 一切工作的基础,架构团队执行前要对投入产出比进行预估;

  • 架构团队是 ONES 的精英团队,在研发团队遇到疑难杂症时,要帮忙排查。

外部压力

  • 交付时间无法承诺,难以守时;

  • 预估时间很短,但研发周期很长。

(2)分析问题

明确问题后,就进入了分析阶段。分析的基础是可视化,看不到的东西是没办法客观分析的。

在 ONES,我们会遵从以下两个步骤,来搭建可视化的架构流水线。

第一步:了解团队的工作

  • 了解团队的工作项类型有哪些:是架构需求、缺陷还是临时任务,每个工作项类型的特征?来源是什么?工作流是怎样的?来源方对于工作项类型的交付期待是什么?每个工作项类型的到达率如何?是可规划还是完全随机的状态?

  • 了解每种工作项类型的服务类别:团队处理这些工作项的服务策略是什么?是需要立刻放下手头上的工作,中断一切事务来响应,还是只需要保证在固定交付时间完成即可,还是常规响应,先进先出?

  • 了解每种工作项类型的交付能力:分析团队能完成多少个架构需求?多少个缺陷?

演进式架构从不缺设计方法,最大的阻力在于「人」_第1张图片

​用 ONES Wiki 进行工作项分析

第二步:构建可视化看板

当获取了足够多的信息后,就需要构建一个清晰直观的可视化看板。ONES Project 支持看板视图,帮助我们高效构建整个工作的可视化看板。

演进式架构从不缺设计方法,最大的阻力在于「人」_第2张图片

 ​用 ONES 快速构建可视化看板

在构建可视化看板时要注意:

  • 服务开始点及交付点:确定在整条生产流水线上,从时间点开始确认交付,时间点确认已经交付完成;

  • 定义 WIP 规则:定义工作项类型、服务类别和人的在制品规则;

  • 定义流转规则:将这些规则透明化,同步给团队所有人。

构建完成后,我们可以检验下,所有的工作是否都实现了可视化,是否还有一些隐含的工作没被记录下来,如果有,重复前面的工作,先分析,再构建可视化看板,直到团队中所有人都能通过看板知道所有的工作有哪些。

分析问题的 Tips:

  • 预估不产生价值,SLA 能起到同样的作用。精准预估只是架构团队给外部的一个承诺,花在预估上的成本实际上会拉低价值的输出,因为架构团队的输出是架构设计本身,预估则增加了架构设计到最终交付的时间。

  • 固定交付不意味着紧急交付。如果一个任务耗时只需一周,但截止时间是一个月之后,需要尽快完成它吗?其实不需要,我们完全可以控制在截止前两周完成这个任务。

  • 当一切都是紧急交付,就不再有紧急交付。如果同时来了多个需求,并超出了团队的整体负荷量怎么办?我们必须要从这些紧急事情中再评估出一个最紧急的事项,优先完成。

(3)解决问题

在架构生产流水线中,瓶颈节点的节拍决定了整条流水线的生产力。这就像在一条公路上,公路最窄部分的流速决定了整个公路的车辆通过的速度。

基于这一规律,ONES 将复杂问题化繁为简,通过持续分析和解决瓶颈问题两个环节,提高了架构流水线的产出速度。

第一步:找出瓶颈

瓶颈处有一个明显的特征,上游堆积,下游饥饿,如下图所示,大量的工作已经研发完成,正在等待测试,但测试已经满负荷,通过可视化看板清楚地发现,在当前阶段,测试资源就是瓶颈。

演进式架构从不缺设计方法,最大的阻力在于「人」_第3张图片

 

第二步:解决瓶颈问题

  • 最大化利用瓶颈资源:前面我们已经识别出,瓶颈资源就是测试资源,接下下来,我们需要查看测试资源的时间投入在了哪些地方,是在隐含的工作上,还是非必要的工作上,我们可以去除一些对价值输出没有太大关系的非必要工作内容,来保证测试资源最大化输出。

  • 配合瓶颈资源:当测试资源最大化输出时,还需要上下游配合输出,因为任何一项工作都少不了全团队的参与,比如说新增了一个需求,需要测试参与评估,研发上遇到问题,也需要测试的投入。这会导致瓶颈处的工作堆积起来,最终还是等待测试资源去完成。所以,如果不减少上下游资源的投入,就无法真正最大化利用瓶颈资源。

  • 突破瓶颈:当我们把整个通路利用起来,就可以去考虑突破瓶颈,比如提高测试资源的人效,或者增加测试资源。

一些反直觉的疑问

为什么不在一开始就直接增加瓶颈处的资源投入?

答案很简单,如果我们一开始就招聘,会导致测试需要花大量时间培训新人,并在新人能独立工作之前,监督他的工作,这样一来,在一段时间内,瓶颈处的工作量反而增加了,流速会变得更慢。

为什么要减少上下游的资源投入?

还是以公路为例,大家都知道,堵车通常发生在最窄的路段,如果突然从一个宽路段进入窄路段,车的流速会很快降下来,但如果公路是一条直道,反而不会出现这样的问题,因为道路是通畅的。

(4)复盘问题

在衡量研发效能时,涉及到非常多的衡量指标。但在分析、解决问题的过程中,ONES 会重点关注下面三个核心指标:

  • 业务前置时间:衡量需求从创建到最终交付的整体时间;

  • 交付前置时间:衡量需求从交付开始到最终交付的交付时长;

  • 吞吐量:通过对比优化前后的吞吐量,可以评估团队能力是否提升。

前两个指标非常重要,我们会利用它们进行整体的价值流评估,确认当前阶段在哪个环节花了更多时间。

演进式架构从不缺设计方法,最大的阻力在于「人」_第4张图片

​ONES 支持多种研发效能报表

当我们明确指标后,就可以通过各种各样的报表帮助我们进行可视化分析,比如直方图、面积图、趋势图。

04 思考与总结

演进式架构设计最大的阻力是人,做好技术管理的目的是管好人,简而言之:做好技术管理,能有效地助推架构持续演进。

此外,我们在解决路径中反复提到了一个词:渐进式,这指的是我们通过不断地发现、解决瓶颈瓶颈,可以逐步提升架构流水线的生产力,因此:渐进式改进,是构造高效架构流水线的重要手段。

05 大会现场精彩瞬间

大会现场,ONES 与众多行业专家及技术管理者进行热情交流。

演进式架构从不缺设计方法,最大的阻力在于「人」_第5张图片

演进式架构从不缺设计方法,最大的阻力在于「人」_第6张图片

演进式架构从不缺设计方法,最大的阻力在于「人」_第7张图片

演进式架构从不缺设计方法,最大的阻力在于「人」_第8张图片

演进式架构从不缺设计方法,最大的阻力在于「人」_第9张图片

你可能感兴趣的:(研发管理,研发效能,架构,系统架构,运维)