3.4　敏捷建模

敏捷建模（AM）是一个基于实践的方法论，它关注软件系统的有效建模和文档。详细级别的AM是由价值观、原则、实践组成的集合，其以有效的、轻量级的方式将软件建模的实践应用于软件开发项目中。提出AM的目的是为了提供一系列可被裁剪并应用到其他基础过程框架中的敏捷策略，而DAD过程框架也从AM中受益匪浅。
敏捷模型驱动开发（Agile Model Driven Development，AMDD）（见图3.3）是指通常在项目的最开始阶段仅仅进行高层建模，从而理解系统所涵盖的范围以及潜在的架构。在构造迭代周期内，敏捷建模是迭代计划活动的一部分，其以即时（JIT）方式进行敏捷建模风暴，在进行几个小时的编码前，先花几分钟建模。AMDD虽然不强制从业者必须采用测试驱动开发方法，但是推荐使用它（DAD采取同样的立场）。
从图3.3中我们不难看出，AMDD的主要观点是建模和文档活动要贯穿于整个生命周期。而图3.4则列出了AM所包括的建模和文档实践图。这些实践包括以下内容。
利益相关者积极参与。利益相关者（或他们的代表）应该及时地提供相关的信息，及时地做出相应的决策，并借助工具和技能的运用积极参与到开发过程中。
架构预想。在敏捷项目的开始阶段，需要做一些初始的、高层架构建模，为解决方案确定可行的技术策略。架构预想和需求预想是紧密关联在一起的。
持续文档。在整个软件开发周期内，为已交付的功能编写说明文档应该与开发剩余功能同时进行。值得注意的是，有些敏捷团队会选择晚一个迭代周期再编写说明文档，此时相关信息都比较成熟和稳定了。
推迟文档。尽可能延迟编写说明文档，以避免一些不确定的信息还需要反复修改。这个实践和上一条实践（持续地编写文档）同时进行，大家应该根据实际情况采用最适合的方法。
可执行的需求规格。用可执行的“客户测试”的形式描述详细的客户需求，用可执行的开发人员测试来描述详细的设计，而不是那些不具可执行性的“静态的”文档。另外，值得注意的是，这仅适用于详细文档的编写，对于那些高层次的或概念性的文档则适合用图表和/或散文的形式表述。还请注意，有些复杂建模工具，如在IBM Rational Rhapsody和IBM Rational Software Architect（RSA）中则可以执行图表构件。

迭代建模。在每个迭代周期的开始阶段做敏捷建模，这也是迭代计划活动的一部分，其可以帮助团队了解接下来要做什么以及怎么做。
恰到好处的工作制品（足够的工作制品）。一个敏捷模型或文档要能够充分代表当前的情形，且够用即可，并非多多益善。
前瞻性建模。有时候靠近工作项列表最上方的用户需求相当复杂，这激励团队在它们还没弹出工作项栈之前先花些精力去探究明白，这样有助于降低全局的风险。
模型风暴（model storming）。在每个迭代周期内，团队需要依照即时（JIT）原则，在需要的时候适时地进行模型风暴，比如，挖掘一个需求背后蕴含的细节信息或理通一个设计上的问题。
多样化模型。每种类型的模型都有自身的优点和缺点。高效开发人员在他们的知识工具包中需要有一系列的敏捷模型，以便他们在特定情况下运用最适合的敏捷模型。第8章和第9章会详细介绍很多不同类型的敏捷模型以及如何应用它们。
给用户需求定优先级（工作项列表）。利益相关者给每项用户需求定一个优先级，敏捷团队则要按照这个优先级高低顺序逐个交付相应的用户需求，以便尽可能地提供最大的投资回报率（ROI）。
需求预想。在敏捷项目的开始阶段，团队需要明确项目范围，并对用户需求进行优先级排序。
单一信息来源。尽量从同一个且唯一的地方获取信息。
测试驱动开发（TDD）。请参考前面章节所介绍的XP实践的相关内容。