编者按：本文节选自周爱民著《程序原本》一书中的部分章节。

集成化工具需要有配套的生产过程和管理

应用开发的“集成环境”（IDE，例如Eclipse IDE）不是给一个人用的，开发工具公司的“套件”（Suite，例如VSTS，Visual Studio Team Suite）是为多种角色提供的。但这两点事实，大多数时候为工程人员所忽视。集成环境或套件都是基于工业生产的理念来提供的，这一理念认为：工业生产整体依赖于分工明确的产品过程。因此，开发人员需要代码文本的编辑环境，测试人员需要自动化测试与脚本驱动的工具，构建人员需要包、构件以及面向资源的管理界面，如此等等。

将这一切组织在一起的Suite或IDE，就如同工业生产线上的硬件环境。正如这个比喻所暗示的：在购买这个生产线的同时，也就意味着你需要这个生产线的过程模型与管理体系。大多数时候，我们的应用软件产品开发并不是工具用得不好，而是生产组织与管理得不好。而这其中，“模型”的指导意义尤其被忽略。

MSF（Microsoft Solution Framework）描述了“VSTS生产线”背后的工程模型，其核心并非来自于技术实施，而是来自对管理 “项目/产品过程”所需要进行的权衡（图1）¹，这与“项目平衡三角（项目管理三要素）”所阐述的问题是一致的（图2）：

¹ 引自“MSF Process Model v. 3.1”, Microsoft Solutions Framework White Paper。

图1　项目要素之间的平衡三角

图2　管理平衡三角

于是进一步地，MSF提出了三种模型来解决对应的问题，如图3所示。

图3　MSF的三种模型与项目要素之间的关系

其中组队模型讨论项目创建时的团队、资源、沟通模式，过程模型讨论开发过程的控制与管理方法，应用模型则讨论产品定义、产品实现以及产品特性的管理。当这些模型映射到Suite或IDE中时，相关的要素就变成了类似如表9所示的关系²。

² 这种对应关系并非是边界分明的，事实上IDE中的同一个功能可能应对的是不同模型中的问题或问题集。

表1　模型要素在理论框架与集成环境中的关系

这一类工具在“一致性”上的要求与“统一建模”、“统一过程”等思想同出一源。更确切地说，它们是“方法 + 过程 + 工具”这一传统工程模型的具体实践，即方法论决定了过程模型，工具是对方法论与过程模型的实现及其具体实施手段。

但问题在于：是要懂得使用工具，还是要懂得方法与过程？

敏捷工程实践者其实代表了工具精良派的产业工人的声音

集成环境或套件试图通过统一模型来建立整个团队对话、沟通、工作的一致化的界面，但这一过程其实并非依赖或只依赖特定的工具。

敏捷工程敌视那些强行植入开发工具的决策需求、管理需求以及产品需求³，进而否定“管理者、决策者以及产品相关角色”等在这一环境中的价值，并从“形式上”将这些角色推出团队，同时把产品定义与产品品质这些职责直接交给开发人员与用户。但是从根本上来说，它未能否定“过程模型”的价值。因此，大多数敏捷团队在弱化了管理与产品相关职责之后，仍无法摆脱软件工程过程（例如瀑布模型，以及基于瀑布模型的迭代）的约束⁴，只是他们有空间、有能力去选择更轻量、适用的工具来应付那些决策、管理与产品的需求。

³ 导致这一局面的部分的、且并非关键的原因在于：一方面，开发工具中使用Project、ProjectGroup等关键字来应对项目规模的扩大，而这一问题延伸到工程模型后所得到的抽象概念却是Product、Version以及ProductLine等；另一方面，工程工具与开发工具的提供商试图将这些合而为一，但形式上的统一未能弥补概念与领域上差异。

⁴ 这进一步导致了团队无法摆脱既有的公司组织与管理结构，于是实施敏捷变得在组织层面上既说不通也行不通。

除开这些因素，“敏捷”事实上是在探索用户与工程师进行有效沟通的最简方式。这种方式并不是说不要“模型”，敏捷工程师（也包括“不敏捷”的工程师）其实也试图为用户所描述的业务数据与业务过程进行建模⁵。一部分建模工作是这些工程师“乐于”去做的，通常它们是面向业务的“数据与过程”的。因为这跟编程世界中的“数据结构与算法”有着近乎天然的映射关系⁶，只是他们将这些工作换了一门“手艺”来做罢了。例如在UML中，逻辑视图与实现视图构建的就是这两类模型。而他们“不喜欢”做另一些建模工作（例如完整的业务建模与产品建模），只是因为这些内容与开发工作没法关联起来，因而在他们的工作中是不需要的。

⁵ 例如，正如此前所讨论的，敏捷中的原型事实上也是敏捷工程师与用户之间沟通的模型。

⁶ 你可以想象成开发过程中的“定义数据结构和写函数声明”，以及形式化的流程图与部分逻辑代码。

将VSTS等单纯视为“开发工具”是一个根本性的错误。既然这是生产线，那么正确的做法应是明确工程师在生产线上的角色，并将适当的工作交付给他们。但现实是，源于那些错误的认识，一些团队过度地要求工程师在生产线中的职责，反而激化了他们对相应职责的抵制。而敏捷工程与敏捷开发方法，不过是在这样的抵制运动中所诞生的“看起来有点革命性的”产物。

图书简介：https://www.ituring.com.cn/book/2429

相关阅读

程序原本（一）：应用开发基础

程序原本（二）：应用开发技术

创作场景

程序原本（三）：开发视角下的工程问题