Scrum是一种敏捷过程，它使用迭代和增量方式管理和控制复杂的软件与产品开发。Scrum的开发流程非常简单。首先，Product Owner根据客户的需求编写Product Backlog，然后召开计划会议，评估各项功能的相对工作量，并确定Sprint的愿景和目标，生成Sprint Backlog。然后，在Sprint（即迭代）的开发过程中，召开每日会议，Scrum Master通过它了解开发的进展以及出现的问题，检查团队成员的工作与进度。迭代结束后，团队会召开评审会议，向项目关系人展示可运行的增量版本，并检查是否达到了Sprint的目标。评审会议之后的回顾会议则会总结以往的实践经验，以提高团队生产力。
Scrum的核心在于迭代。团队首先浏览开发需求，考虑可用技术，并对自身技术及能力做出评估。然后共同确定构建功能的方案，并每日调整方法，以应对新的复杂问题、困难和出乎意料的情况。团队找出并选择最佳方案去完成任务。此创造性过程便是Scrum生产力的核心1。Scrum的所有实践就是围绕着一个迭代和增量的过程开展的。
1.2 Scrum的不足
与XP（eXtreme Programming，极限编程）不同，Scrum并没有提供核心的价值观与指导原则，也缺乏具体的实践方法，例如结队编程、测试驱动开发。Scrum仅仅规定了实施的基本流程与检查表，它是一个开放的管理框架，重心在于项目管理，而不是指导团队成员如何进行开发。这既是Scrum的优点，因为它很灵活，能够适应大多数场景，也可以兼容并包地引入其他方法学所提倡的实践；同时也是Scrum存在的固有缺陷，使得它难以被实践。如果没有一位优秀的Scrum Master，而团队成员又缺乏自我组织和管理的能力，就会让开发过程变得一团糟，团队成员将会无所适从。
在开发实践方面，Scrum可以借鉴XP提倡的结队编程以及测试驱动开发实现编码，通过重构对编码进行调整以适应需求的变化。但是，Scrum在建模方面却是一片空白。例如，Scrum对于如何创建Product Backlog，如何建立架构模型，以及如何在编码之前进行必要的模型设计，都没有给出具体的解决方案。缺乏正确的建模活动，就可能会对Scrum开发过程造成阻碍，影响团队达成Sprint的目标。
- 敏捷建模与Scrum的契合
敏捷建模（Agile Modeling）是一个基于实践的建模方法，包括一系列以特定原则和价值为导向的，可被软件专业人员应用到日常工作中的实际做法2。敏捷建模有效地将建模敏捷化，利用敏捷方法的思想对传统的建模理念进行了重新梳理，使其更加适用于敏捷开发。敏捷建模描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时避免过度简化和不切实际的期望。
敏捷建模可以弥补Scrum在建模方面的不足。如果说Scrum是一个对开发过程的所有活动进行了规定的基本框架，则敏捷建模由于其对建模活动的核心关注，极大地丰富和增强了Scrum的软件过程。建模在所有的软件开发中都是不可缺少的一个重要环节。传统的建模活动，常常会重视对文档与工具的使用，要求创建的模型涵盖软件开发过程的方方面面。这种重量级的建模活动与敏捷开发方法在核心思想上是相悖的。敏捷方法需要敏捷的建模，Scrum自然也不例外。
敏捷建模定义了一组与轻量级的建模有关的价值观、原则和实践，并说明如何把它们付诸实施。本文将从敏捷建模的价值观、核心原则和核心实践三个方面讨论敏捷建模与Scrum的契合。
2.1 敏捷建模的价值观与Scrum的契合
敏捷建模的价值观包括交流、简单、反馈、勇气和谦虚。前面四条来自于XP的价值观，但完全可以说是敏捷开发的价值观。敏捷软件开发宣言强调与客户交流和团队的合作。宣言对可工作软件的重视甚于详尽的文档，凸现了简单的价值观。宣言对变更的重视体现了反馈的重要性，以及拥抱变化的勇气。Scrum同样体现了敏捷建模的第五条原则------谦虚。Scrum将整个团队定义为一种角色，作为一个整体负责将Sprint Backlog转化为可运行的产品。在开发过程中，团队成员需要管理自身的工作，同时对每次迭代和整个项目共同负责。如果没有谦虚的精神，Scrum的团队是无法运作的。
2.2 敏捷建模的核心原则与Scrum的契合
敏捷建模提出了十一条核心原则。Ambler认为，只有完全采纳这些原则，才能真正地宣称自己在进行敏捷建模。Scrum虽然没有提出具体的指导原则，但在Scrum框架和实施流程中，仍然体现了部分敏捷建模的核心原则。表1展现了在Scrum项目中敏捷建模核心原则的适用性。
表1 在Scrum项目中敏捷建模核心原则的适用性
|---------------|---------------------------------------------------------------------|
| 敏捷建模的核心原则 | 与Scrum的契合 |
| 软件是你的首要目标 | Scrum坚持所有的Sprint都结束于演示，其目的就是要交付可工作的软件。 |
| 支持后续工作是你的第二目标 | Scrum认为，需求列表是推动迭代的主要力量，只要项目有资金，迭代就不会停止。项目的后续工作属于需求列表的内容。 |
| 轻装前进 | Scrum的最终产出物除了可工作的软件外，只包括Product Backlog和Sprint Backlog。 |
| 主张简单 | Scrum主张在一开始就要保持设计尽可能简单。 |
| 包容变化 | Scrum要求Product Owner根据不断变化的商业环境对产品作出调整。 |
| 递增的变化 | Scrum属于增量式开发，要求团队在每个Sprint周期内完成一部分产品功能增量。 |
| 有目的地建模 | 与建模相关的原则，Scrum并未要求 |
| 多种模型 | 与建模相关的原则，Scrum并未要求 |
| 你需要一个技术知识工具箱 | 团队的基本要求。 |
| 高质量的工作 | Scrum要求开发过程具有可视性，提倡对最后结果会产生影响的各个方面必须是清晰可见的，同时要求频繁的检查，以及对不合格的内容进行调整。 |
| 快速反馈 | Scrum每日会议、评审会议与回顾会议反映了这一原则。 |