Question

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

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

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

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