程序员 - 演进式架构从不缺设计方法，最大的阻力在于「人」｜ONES Talk - 行业对话

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

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

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

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

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

市场环境急速变化，业务高速发展，架构设计也要不断演进，以适应业务需要；
随着企业规模的壮大，架构设计的腐化无法避免，只能在演进中持续进化；
架构可以在不破坏原有架构的基础上增量式变化。

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

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

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

职能型架构团队存在众多角色，如后端架构团队、前端架构团队、运维架构团队等等，不同职能有不同的架构目标；
架构支撑业务，需要协同跨职能、跨部门协同多个团队，管理难度大；

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

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

解决问题的直觉框架

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

发现问题：知道问题是什么？要改变什么？
分析问题：问题产生的根本原因是什么？要改变成什么样？
解决问题：基于问题分析的结果，找到解决的办法；
复盘问题：量化结果，复盘过程，持续改进，并发现下一个问题。

ONES 实践分享

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

（1）发现问题

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

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

内部压力

要深入了解过往的架构设计，在重构的同时，保证 ONES 的业务正常运行；
计划是 ONES 一切工作的基础，架构团队执行前要对投入产出比进行预估；
架构团队是 ONES 的精英团队，在研发团队遇到疑难杂症时，要帮忙排查。

外部压力

交付时间无法承诺，难以守时；
预估时间很短，但研发周期很长。

（2）分析问题

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

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

第一步：了解团队的工作

了解团队的工作项类型有哪些：是架构需求、缺陷还是临时任务，每个工作项类型的特征？来源是什么？工作流是怎样的？来源方对于工作项类型的交付期待是什么？每个工作项类型的到达率如何？是可规划还是完全随机的状态？
了解每种工作项类型的服务类别：团队处理这些工作项的服务策略是什么？是需要立刻放下手头上的工作，中断一切事务来响应，还是只需要保证在固定交付时间完成即可，还是常规响应，先进先出？
了解每种工作项类型的交付能力：分析团队能完成多少个架构需求？多少个缺陷？

第二步：构建可视化看板

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

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

服务开始点及交付点：确定在整条生产流水线上，从时间点开始确认交付，时间点确认已经交付完成；
定义 WIP 规则：定义工作项类型、服务类别和人的在制品规则；
定义流转规则：将这些规则透明化，同步给团队所有人。

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

分析问题的 Tips：

预估不产生价值，SLA 能起到同样的作用。精准预估只是架构团队给外部的一个承诺，花在预估上的成本实际上会拉低价值的输出，因为架构团队的输出是架构设计本身，预估则增加了架构设计到最终交付的时间。
固定交付不意味着紧急交付。如果一个任务耗时只需一周，但截止时间是一个月之后，需要尽快完成它吗？其实不需要，我们完全可以控制在截止前两周完成这个任务。
当一切都是紧急交付，就不再有紧急交付。如果同时来了多个需求，并超出了团队的整体负荷量怎么办？我们必须要从这些紧急事情中再评估出一个最紧急的事项，优先完成。

（3）解决问题

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

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

第一步：找出瓶颈

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

第二步：解决瓶颈问题

最大化利用瓶颈资源：前面我们已经识别出，瓶颈资源就是测试资源，接下下来，我们需要查看测试资源的时间投入在了哪些地方，是在隐含的工作上，还是非必要的工作上，我们可以去除一些对价值输出没有太大关系的非必要工作内容，来保证测试资源最大化输出。
配合瓶颈资源：当测试资源最大化输出时，还需要上下游配合输出，因为任何一项工作都少不了全团队的参与，比如说新增了一个需求，需要测试参与评估，研发上遇到问题，也需要测试的投入。这会导致瓶颈处的工作堆积起来，最终还是等待测试资源去完成。所以，如果不减少上下游资源的投入，就无法真正最大化利用瓶颈资源。
突破瓶颈：当我们把整个通路利用起来，就可以去考虑突破瓶颈，比如提高测试资源的人效，或者增加测试资源。

一些反直觉的疑问