从实施推进的角度来看，模型事实上允许我们将系统拆分成多个阶段，并尽早地预期了系统的每个阶段所依赖的(前一个阶段的、可能的)事实基础，因此模型具有可描述、可分析、可预期等性质①。而敏捷工程本质上是把决策域与产品域中的需求拉到了实施域中，就地决策与设计(产品),并将这一过程开放给用户，

①正因为如此，上一节一开始就讲到：它适于解决时间因素所致的复杂性。

问题的总量并没有减少，但是这里的“可讨论对象”(即原型),变成了纯粹用于工程师与用户之间沟通的桥梁。这符合一些应用开发工程的现实场景，例如用户通常更关心产品特性是否能够得到满足，他们多数时候并不关注市场、产品或实施阶段等问题。因此敏捷(以及类似基于原型、快速迭代的)工程模型有着很强的实用性。

然而原型不能解决一切问题。在一定程度上来说，原型是轻量级的试错，而抽象模型则可以通过严密的论证与分析过程来得到决策依据。因此，原型与模型的适用领域也有所不同。原型适合于在参与者之间建立简单的、直观的、允许快速纠错的讨论对象，更适用于快速推进以及短期、逼近式的产品开发。而模型则适合于抽象出系统中方向性、支撑性、不易频繁变化的关键环节，在此基础上进行论证，以尽可能减少出错或预期风险，甚至更进一步地提供中长期的系统演进规划(例如产品版本、产品线等)。

【三】

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

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

MSF(Microsoft Solution Framework)描述了VSTS生产线背后的工程模型，其核心并非来自于技术实施，而是来自对管理“项目/产品过程”所需要进行的权衡(图3-10)①,这与“项目平衡三角(项目管理三要素)”所阐述的问题是一致的(图3-11):①引自"MSF Process Model v.3.1",Microsoft Solutions Framework White Paper。

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