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

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

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

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

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

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

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

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

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

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

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

那么，「人」会带来哪些问题呢？

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

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

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

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

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

解决问题的直觉框架

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

• 发现问题：知道问题是什么？要改变什么？

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

• 解决问题：基于问题分析的结果，找到解决的办法；

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

ONES 的实践分享

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

（1）发现问题

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

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

内部压力

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

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

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

外部压力

• 交付时间无法承诺，难以守时；

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

（2）分析问题

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

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

第一步：了解团队的工作

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

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

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

​用 ONES Wiki 进行工作项分析

第二步：构建可视化看板

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

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

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

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

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

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

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

分析问题的 Tips：

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

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

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

（3）解决问题

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

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

第一步：找出瓶颈

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

 

第二步：解决瓶颈问题

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

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

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

一些反直觉的疑问

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

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

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

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

（4）复盘问题

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

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

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

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

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

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

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

04 思考与总结

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

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

05 大会现场精彩瞬间

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

​

​

​

​