阻碍工程效率的13大凶兆

通往“工程效率目标”的道路上，有13大凶兆出没……

在讨论软件研发工程效率之前，需要明确工程效率的目标到底是什么。

一提到工程效率的目标，很多人的第一反应就是“要快”。

但什么要快？是研发人员要更快地忙碌吗？如果价值流动到用户手中很慢，研发人员忙得再快，也是没有用的。

工程效率的目标

不管是工程效率的目标，还是敏捷、精益、DevOps的目标，如果放到软件开发的领域，那么目标都只有一个。

工程效率的目标，就是让用户能及时在生产环境，持续稳定地享受软件所提供的良好服务。

这个目标的定义，其实涉及了工程效率的四个维度。

图1. 工程效率的目标与四维度

工程效率的目标，就是让用户能及时（流速快）在生产环境，持续稳定地（稳态久）享受（价值准）软件所提供的良好服务（质量好）。

这四个维度，可以按照重要性进行排序：

1. 稳态久
2. 价值准
3. 流速快
4. 质量好

其中，稳态久，指后面3个维度“价值准”、“流速快”和“质量好”，都要能持续地保持，即能保持收益稳态。之所以排名第一，是因为其所涉及的“凶兆1：用线性思维解决复杂系统问题”，经常被大家忽视，导致开发团队难以保持后面3个维度的收益稳态。

流速快，指价值向用户流动的速度快，而不是指某个员工或某个部门完成工作的速度快。因为如果价值在两个部门间发生了等待，即使每个部门工作得再快，价值流向用户的速度还是变慢了。

13大凶兆

在通往工程效率目标的路上，潜伏着13大凶兆，阻碍工程效率的达成。

图2. 阻碍工程效率的13大凶兆

这13大凶兆，按工程效率的四维度，可分为4类。

1. 稳态久

凶兆1：用线性思维解决复杂系统问题。比如靠“加班和加人”加快进度。易事与愿违，老板易破财，员工易加班伤身，大凶。

为何软件开发过程本身，就是一个复杂系统？

我们身边有很多复杂系统的实例，比如全球气候、人脑和电网等等。

复杂系统具有以下特点：

• 内部组件相互作用
• 与环境之间的相互作用
• 相互作用的类别多种多样，比如合作、依赖、竞争……
• 组件及其相互之间的关系数量庞大，难以在一个人的大脑里完整建模
• 非线性，经常事与愿违，难以预测

想想在软件开发过程中，光涉及到的人员、设备、数据、过程、环境就多得不计其数，更别提它们之间的相互关系的数量了。

有人说能否将复杂系统，简化为线性的简单系统？这样就不必应对复杂系统了。

遗憾的是，这样做，短期可行，但长期不可行。

Frederick Brooks于1986年在论文No Silver Bullet中，将复杂性粗略地分为两类——偶然复杂性和本质复杂性。

软件开发的资源，总是有限的。所以妥协总是要做出的。一旦做出妥协，就会形成次优代码。而次优代码不断积攒，总会到达一个令人难以理解的状态。这样就出现了偶然复杂性。

软件的功能越丰富，复杂度越高，就增大了本质复杂性。W. Ross Ashby于1958年所发表的论文Requisite Variety and Its Implications for the Control of Complex Systems中解释了“必要多样性法则”。简而言之，对于能够完全控制系统B的系统A，必须至少与系统B一样复杂。

简言之，只要资源有限，且不断增加新需求，那么偶然复杂性和本质复杂性就必然随着时间推移，不断增大。这样，就无法实现将复杂系统，简化为线性的简单系统。

应对复杂系统的方法有哪些？有下面两种。

第一，是可视化安全边界。

Jens Rasmussen于1997年在论文Risk Management in a Dynamic Society所提出的“动态安全模型”。

图3. 动态安全模型

可以想象，图中的小人腰上拴着3根橡皮筋，每一根都绑到相应的一个方块上。

因为人对于“经济性”和“工作量一般都有直觉，比如不会随意浪费，每天至少有几小时的睡眠和休息，所以这两根皮筋一般不会绷断。但由于“安全性”很少能被可视化出来，所以员工经常会让系统在线上出现故障，从而把“安全性”这根橡皮筋绷断。

所以，应对复杂性，可以把安全边界可视化出来，让员工自觉地远离漏洞，减少故障的风险。

第二，是改善可逆性。

Trento大学经济学系主任Enrico Zaninotto教授于2002年在一次演讲中所提出的“复杂性的经济支柱模型”。

图4. 复杂性的经济支柱模型

在复杂系统中，如果缺乏“可逆性”，即使能在“状态”、“关系”、“环境”上取得优势，那么所获得得收益也是暂时的。比如上个世纪福特的T型车，通过标准化零件，车身只有黑色，来减少”状态。通过标准化工人在流水线上动作，简化人与流水线的关系。通过打赢了与ALAM美国特许汽车制造商协会的官司，创造了设计创新车型，不再支付高额许可费的环境，从而让汽车首次进入寻常百姓家。但面对之后丰田的能实现“可逆性”的精益制造，福特却败下阵来。

在应对复杂系统时，可以使用上述两种方法，来让应对的过程更安全和更灵活。

下面会从应对剩下12个凶兆的技术中，选取一些技术，来讨论它们如何能体现出“可视化安全边界”和“改善可逆性”。这能帮助我们更好地理解，一些熟知的技术，是如何能通过这两种方法，应对复杂系统的。

2. 价值准

凶兆2：不分析用户问题。领导经常以解决方案的形式提需求。易返工，老板易破财，员工易加班伤身，凶。

分析用户问题的技术有哪些？

• 电梯演讲
• 用户画像
• 用户目标
• 用户问题定义
• 快速启动
• 纸面原型

用户画像，通过描述用户痛点，可视化了安全边界。

分析用户问题的工具有何推荐？

• BeeArt
• Figma
• Invision
• Sketch

凶兆3：找不到业务和测试人员。开发人员经常找不到业务和测试人员，澄清需求文档上的疑问。易返工，老板易破财，员工易加班伤身，凶。

解决“找不到业务和测试人员”的技术有哪些？

• 全功能团队
• 故事梳理工作坊
• 用户故事验收条件
• 用户故事开卡
• 用户故事验卡
• 产品共识沉淀（用于为团队新成员传递知识）
• 领域驱动设计工作坊
• 迭代展示会

带有验收条件的用户故事，既通过验收条件可视化了边界，又通过用户故事本身都是需求纵向拆分的小批量，来改善可逆性。

3. 流速快

凶兆4：大需求。业务人员每次给的需求都很大，每个都需要几个月才能完成。阻碍财路，大凶。

拆分大需求的技术有哪些？

• 用户体验地图
• 用户故事地图
• 用户故事拆分

用户故事拆分，通过小粒度的需求纵向拆分，能加快价值流速，尽早获取用户反馈，改善了可逆性。

凶兆5：大批量上线。数量众多的新特性和缺陷修复，都集中在一起上线。发现缺陷难以定位，阻碍财路，因压力大，领导和员工精神易受刺激，都易加班伤身，大凶。

应对“大批量上线”的技术有哪些？

• 部署与发布分离
• 暗部署
• 特性开关

特性开关，通过调整开关来决定特性是否能够发布，来改善可逆性。

凶兆6：线上故障修复过程不规范且耗时长。线上故障抢修不走设计、开发、测试等规范过程，而是直接在生产环境改代码。易火上浇油，阻碍财路，老板易破财，影响领导仕途，员工易加班伤身，大凶。

应对“线上故障修复过程不规范且耗时长”的技术有哪些？

• 部署流水线
• 基础设施即代码

基础设施即代码，当抢修故障时，能通过代码从零开始构建整个健康状态的基础设施，从而改善可逆性。

凶兆7：长寿命Gitflow分支。代码向生产环境的测试晋级，靠分支合并晋级，而不是包晋级。阻碍财路，易发生代码合并遗漏，员工易加班伤身，大凶。

“从本质上讲，长寿命分支与将所有变更都不断集成到源代码库背道而驰。”——技术雷达2020年5月

应对“长寿命Gitflow分支”的技术有哪些？

• 主干式开发
• 持续集成

主干式开发，通过频繁小批地解决合并到主干上的代码提交的冲突，来可视化安全边界，并改善可逆性。

凶兆8：大批量代码提交。开发人员对每个用户故事，不做纵向拆分，不用特性开关，过几周才一次性提交大量代码。阻碍财路，易产生代码合并地狱，员工易加班伤身，大凶

应对“大批量代码提交”的技术有哪些？

• 任务拆分
• 特性开关
• 暗部署
• 单意图提交
• 7步提交法

图5. 7步提交法

7步提交法，既通过本地和流水线代码构建可视化安全边界，又通过失败提交回退改善了可逆性。

4. 质量好

凶兆9：线上故障频发。阻碍财路，老板易破财，影响领导仕途，员工易跳槽，大凶。

应对“线上故障频发”的技术

• 验尸报告
• 代码重构
• 自动化测试
• 持续集成
• Code Review
• 技术债管理
• 韧性工程

验尸报告，能通过记录线上事故的整个过程和所发现的漏洞，可视化安全边界。

凶兆10：烂代码。开发人员经常在进度的压力下图省事，复制粘贴代码，命名不揭示意图。易产生难以维护的烂代码，影响领导仕途，阻碍财路，且员工易加班伤身，大凶。

应对“烂代码”的技术有哪些？

• 重构
• 命名即过程
• 自动化测试
  • 自动化单元测试
  • 遗留系统单元测试
  • 自动化组件测试
  • 自动化契约测试
  • 自动化接口测试
  • 自动化用户界面测试
• 代码评审
• 技术债管理

应对“烂代码”的工具有何推荐？

• IntelliJ IDE
• SonarLint
• SonarQube
• JUnit
• Mockito

技术债管理，通过静态代码扫描工具，发现漏洞，可视化安全边界

凶兆11：流水线是摆设。没有搭建流水线，或者有流水线，但变红了没人搭理。易返工，老板易破财，员工易加班伤身，大凶。

快速发现代码集成问题的技术有哪些？

• 持续集成
• 持续集成证书

快速发现代码集成问题的工具有何推荐？

• GoCD
• LambdaCD
• Spinnaker
• Drone
• Jenkins（暂缓）

“Jenkins 2.0虽然引入了“流水线即代码”，但却继续使用插件对流水线进行建模。且未能将核心Jenkins产品更改为直接对流水线进行建模。 根据我们的经验，将部署流水线视作一等公民的构建工具才更好用。”——技术雷达2016年11月

凶兆12：Code Review没做好：开发人员很少做Code Review，要做也是等产品快上线前才集中做一次。易返工，易产生烂代码，影响领导仕途，阻碍财路，且员工易加班伤身，大凶。

做好Code Review的技术有哪些？

• 尽早、频繁、小批地做Code Review
• 频繁分享Code Review收益

尽早、频繁、小批的Code Review，既能发现代码漏洞，可视化安全边界，又能及时修复漏洞，改善可逆性。

凶兆13：单人开发。固定单个开发人员开发和维护某些模块，且不安排轮岗。易发生单点故障，领导精神易受刺激，无人能提反馈，代码难以改进，凶。

应对“单人开发”的技术有哪些？

• 频繁轮换搭档的结对编程

结对编程，既能通过随时提出编程反馈，实现可视化安全边界，又能通过修复代码缺陷，改善可逆性。

如何衡量工程效率？

衡量工程效率的指标，按工程效率的四维度，也可分为4类，共16个。

这16个指标，每个都属的维度，代表了这个指标所衡量的价值。

每个指标，都以“渐多”、“渐好”或“渐快”结尾，表示指标的绝对值没有意义，而与自己团队之前的指标相比，才有意义。

这16个指标，并不是一成不变的，需要根据团队的实际情况，进行取舍，或增加新指标。

图6. 如何衡量工程效率

1. 稳态久

• 可视化安全边界渐多
• 可逆性渐好

2. 价值准

• NPS渐高
• 分析出用户问题渐多
• 开发人员找到业务和测试人员速度渐快

3. 流速快

• 部署频率渐高
• 需求纵向拆分渐小
• 交货时长渐短
• 故障修复时长渐短
• 长寿命gitflow分支渐少
• 小批量代码合并渐多

4. 质量好

• 失效变更渐少
• 烂代码渐少
• 流水线修复渐快
• Code Review收益渐多
• 单人开发情况渐少

总结

工程效率的目标，就是让用户能及时在生产环境，持续稳定地享受软件所提供的良好服务。

在通往工程效率目标的道路上，按稳态久、价值准、流速快、质量好这4个维度分类，潜伏着13大凶兆。如果在团队开发工作中，看到了这些凶兆，就要警惕。

可以参考16个度量指标，来度量工程效率的变化趋势，以便达到工程效率的目标，并持续稳定地保持该目标的达成状态。