▼

生产力和生产关系，引用这么学术化的术语，只是想借用其中的一个规律：生产力决定生产关系，生产关系要适应生产力的发展。以前政治经济的课学得并不够好，但还是非常认同这个规律。

生产力，可以用劳动者单位时间的产出来衡量。驱动生产力发展的是生产经验和生产工具。软件的道理类似。每人每月编的代码行，或功能点，只要数据真实，总是可以在一定程度上代表软件生产者的生产力。不断发展的编程经验、编程语言和工具，自动化工程等，都在促进软件生产力的提升。

生产关系，是人们在生产过程中形成的相互关系，具体内容包括物质资料的生产、交换、分配、消费等方面的关系。软件的道理也类似。软件开发过程中，围绕软件交付件，SE （系统工程师）、开发、测试相互之间也形成一定的关系。在软件发展的初级阶段，比如汇编语言时代，没有这么多角色和分工，一个开发者甚至可以连硬件和软件全包了。随着软件规模和复杂度激增，软件生产力的提升，出现了各种角色，分工也更细。一个大特性分成不同的子模块交与不同的人开发，每个子模块都有设计人员、开发人员和测试人员。这样形成的矩阵型软件生产关系，在促进软件生产力提升的同时，也会制约软件生产力的发展。软件生产关系要不断调整，与时俱进，不能阻碍软件生产力的发展。本文重点探讨软件生产关系，或者说是软件生产模式。

2008 年之前进入公司的软件开发人员，对瀑布开发模式都不陌生。随着 CMM 的引入，大家对瀑布式开发模式的理解更为深刻。一个版本的交付分成需求、设计、开发、测试等几个阶段。每个阶段都有严格的准入和准出。符合要求了，才能进入到下一阶段。瀑布开发模式的优缺点这里不做详述，只说一句，每个时期都有与之相适应的开发模式。

瀑布开发模式

从 2008 年开始，逐渐推行敏捷开发模式。相比瀑布开发模式，敏捷强调的是快速反馈。把一个大迭代分成若干个小迭代，每个小迭代中，特性按 Story 进行分解，分到项目组并行开发，最终放到一起集成、验证。

敏捷开发模式

敏捷开发模式的几个突出优点：

• 快速反馈，快速修正。得益于自动化工程、工具能力的发展，从开发、集成、编译、验证的周期大大缩短，可以快速地获得可运行的版本，验证开发的功能。结果可以得到快速反馈，Bug 可以快速修正；

•  强调人与人之间的交流、交互，可以运行的软件胜过面面俱到的文档，拥抱变化，快速响应客户需求，迭代开发，逐渐生长，符合人性和软件的规律；

• 聚焦价值，突出团队，适应变化，并和 TDD（测试驱动开发）、PP （结对编程）、重构、CI （持续集成） 等优秀实践相结合，顺应软件开发的本质诉求。

敏捷实际上是软件开发思想的一次解放，极大地促进了软件生产力的发展，在软件复杂性和规模发展到一定程度后，特别在互联网软件时代，对 TTM （快）的要求几乎到了一个疯狂的程度，从需求提出到交付，可能就是一周或更短的时间。另外，弹性收缩，水平扩展，按需部署，快速上线等，都对软件开发提出了更高的要求。

传统的敏捷开发模式，受架构限制，难以做到端到端解耦。特性可以分成 Story 来并行开发，但最终还需放到一起来集成，以整个版本为粒度来编译、验证、发布，这样集成就是一个阻塞点。在这个点上，一个人的一个错误都可能使整个版本的集成被阻塞。由于敏捷强调的是快速反馈，参与版本的每个人都需要实时获得集成版本来验证自己的特性。一旦集成环节被阻塞，几十甚至上百人的工作都要受影响。

持续集成 (CI) 是版本高压线，任何人都不能破坏，否则后果很严重。即使集成环节通过，由于修改代码的影响范围和故障传播不可知，一个开发者修改的特性可能会影响到其他人的特性甚至存量老特性，导致故障被放大，在验证环节也会导致相互的影响和阻塞。这种集中 CI 和故障扩散造成开发人员之间的影响、等待、依赖和代码上库前的战战兢兢。为了不使上库代码影响版本集成和其它特性，开发人员一般都是能不改的就不改，一定要改的，代码上库之前要做充分的过验证，这不但降低了开发效率，也违背了软件需要不断优化的本质。

微服务开发模式，强调的是特性端到端解耦，特性可以独立、并行地开发、集成、验证和发布，特性之间的故障传播可预测、可控，这样就减少开发人员相互之间的影响、等待和依赖。从这个意义上来说，微服务开发模式可以很好地解决传统敏捷开发模式的集成和验证阻塞问题。

微服务开发模式

微服务开发模式可以看作是一种新型的敏捷开发模式。消除集中耦合点，控制故障传播路径，减少阻塞和依赖，是架构发展对开发模式的一大贡献。

原有的角色分工，SE 负责设计，MDE （模块设计工程师）/SWE （软件工程师） 负责编码，TE 负责测试。分工细化有利于专业化运作，各领域深耕。但也不可避免地带来扯皮、交接损耗，前期埋下的问题也得不到及时的发现和纠正。全功能团队打破这个分工，SE 负责价值分析和架构设计，特性模块级设计、编码、功能级验证都有 MDE/SWE 完成，TE 负责面向商用场景和客户的系统级验证。特性端到端负责，减少交接损耗和问题解决成本。

全功能团队的开发模式

如果说微服务开发模式是从横向减少了开发者之间的依赖，那么全功能团队是从纵向减少 SE、开发、测试之间相互传递的依赖。早期推行全功能团队，困难重重。因为在传统敏捷开发模式下，每个开发者都要集成整个版本后才能验证自己的特性，从某种程度上是降低了效率。微服务开发模式，让开发人员的验证范围仅限于一个特性，极大降低了集成和验证的工作量，释放了真正的全功能团队的生产力。

全功能团队和微服务开发模式相匹配

编程语言、编程工具、自动化工程等软件技术的发展，降低软件开发门槛，使单个软件开发者的生产力不断提升。软件架构的发展，从 Monolithic，到 SOA，再到微服务，本质是追求解耦，独立，自治，去中心化，减少开发者之间相互的影响、等待和依赖，最大程度地释放每个开发者个体、小团队的创造力，这也是软件生产关系的进步。

软件生产力决定软件生产关系，软件生产关系要适应软件生产力的发展。这个规律，也许就是我们在推行敏捷开发模式、微服务开发模式以及全功能团队的驱动力。