架构词典：工程



• 软件开发其实也是一个生产过程，只是偏柔性生产，毕竟每次的需求都是不一致的。既然是生产，那么工程中的很多常识也都是能起作用的。

• 比如最简单的两条规则是啥呢，一是建立规则，二是建立过程改进的循环。

• 对于规则本身

• 首先是规则应该可以落地，至少要让各个同事能做到：“遵守规则，除非遵守规则会发生危险”。

• 第二是应该有一个统一的地方放这些规则，比如可以把软件的生产分为：架构、开发、测试、上线、运维等各个阶段，针对不同阶段建立规则的wiki页面，确保大家在做这些事情时可以快速了解规则。

• 第三是规则应该为最终效果服务，而不是为了政治正确，比如软件生产的最终效果一般可以分为产生物的质量，以及生产效率。那么所有这些规则，都应该是围绕这两者去优化的。

• 第四是规则不能无限增长，尽量做到加一条，减一条，定期review规则，删减掉不合时宜的规则，以及那些无法落地的规则。定期宣讲规则，确保大家了解这些规则。

• 最后是需要引入软件生产的管理系统，把部分规则固化在管理系统中（比如在发布的 pipeline 中引入检查点），减少大家的心智负担。

• 对于建议过程改进循环，一般可以用 定位->测量->分析->解决->复盘 这个流程来做

• 对于软件工程，前面已提到优化目标是软件质量和生产效率。过程改进循环也应该围绕这两者来展开。

• 关于质量，上一篇提到过一些开发质量相关的内容，里边讲的更多是一个结论，要固化到规则，但推导到这些结论的过程，其实还是靠上面提到的过程改进循环来做。当然，质量控制是一个整体工程，除了开发阶段，其他几个阶段也会有对应的质量控制问题。

• 关于生产效率，现在的 Scrum+Sprint 其实是一种不错的机制，Sprint其实也内建了改进循环，比如 Sprint 开始的时候要做工作量评估，Sprint结束的时候要做复盘，复盘的内容要去影响下一个Sprint的工作方式。