【IT168 技术文章】

    AM的实践之间是相互促进的，因为他们彼此支持，彼此激发。为了使AM更有效率的工作，你需要了解它的实践是如何组合的。图1显示了AM的实践之间的关系，它们被分为七类。AM的核心实践集中在头四种类别中－验证，迭代和递增，团队协作，和简单，你需要完全接受它们才能真正理解敏捷建模。然后，才轮到属于辅助实践的文档，动机，生产率这三个类别。我们先针对核心实践的四个类别，讨论各类中的实践之间的关系，然后我们再针对辅助实践的三个类别，研究各类中实践之间的关系，最后我们来讨论类别之间的关系。

    图1.  AM的实践是如何组合的。

    核心实践

    在团队协作类别中有四项实践－－stakeholder的积极参与，和他人一起建模，公开展示模型，和集体所有制。stakeholder的积极参与对你的成功至关重要，因为你正是为了这些project stakeholder开发系统，正是为了了解和实现他们的需求。换言之，你需要和你的甲方们密切合作，这就自然的想到了和他人一起建模－－这个“他人”也包括你的stakeholder。当你的建模工作有多人参加时（至少一个project stakeholder和一个除你之外的开发人员），你就需要和众人共同协作，相互促进，取长补短。一个擅长于业务过程建模和业务规则定义的敏捷建模者看不到的方面，一个精通结构化建模技术（例如UML类图或数据模型）的人极有可能看得到。一样的道理，系统的直接用户给你的团队提供的信息极可能是高级经理提供不了的。所以，要有这样的观点：你要在项目甲方和开发团队中营造一种积极参与的氛围，只有这样，才能够收集各种不同的观点和经验。集体所有制能够提升协作性，因为一个人单独的进行建模的工作，他很快就会遇到瓶颈，而如果每个人都能够为建模工作献计献策，那么你们就能够成为一个团队，轻易的解决问题。公开展示模型能够使得人们对模型“瞻前顾后”变得容易了，能够立刻考虑模型传达的信息，从而提高团队的协作性。当然，我们是假设模型都在众人的视线之内，或者这些模型都是大家目前正在开发或相关的。这方面的主题我在Organizing an Agile Modeling Room中有详细的讨论。

    迭代和递增类别中包括了使用合适的artifact，并行创建模型，切换到另外的artifact，小增量建模这几项实践。不论哪一个artifact，都有它的长处和短处，任何一个单独的模型都不足以充分的描述你的项目的各个主要方面（如需求、架构）。例如你会发现你为了识别系统的需求，常常需要组合使用用例、业务规则定义、和技术需求定义。单单靠用例就能令project stakeholder立马告诉你他们所有的使用需求吗？这恐怕不太可能。你可以试试换用诸如业务规则之类的artifact来捕获他们的所有业务政策，再换用诸如技术需求的artifact来捕获他们的非功能需求。否则，他们会想起点什么就告诉你什么，还会返回去讨论先前提过的细节，甚至是改变他们的原来的主意。你的需求识别工作通常是一个动态的过程，分析、架构、设计工作也是一样。 我相信物力论中指出了人们以此种方式思考的原因，我们思考的方式明显是杂乱的。敏捷建模者要认识到人们是以一种动态的方式在思考，特别是人们处于群体行为时，这样才能制定对策。敏捷建模者并行创建模型，从而能够最广泛的收集信息。这项实践又是由实践切换到另外的artifact和小增量建模来支持的－－你可能正在使用用例来捕获使用需求的相关信息，而当stakeholder开始讨论他们对编辑屏幕的要求时，你最好是使用基本用户界面原型或是传统用户界面原型来记录这些需求。你需要在不同的artifact之间来来回回，每一个artifact最好都需要编码来验证，这种方式可以由小增量建模的实践来实现－－最典型的方式就是在这个artifact上做一会儿工作，再换一个artifact，依此类推。

    简单这个类别包括了创建简单的内容，简单地建模，使用最简单的工具这几项核心实践。创建简单的内容和简单地建模这两个实践集中于模型的简单性，在建模过程中这两项实践通产是密不可分的。把精力集中在如何简单描述，建模者常常会发现一些使得你手头的模型简单化的方法。举个例子，我曾经参加了一项存储层软件的开发工作，软件的概念类似于EJB的persistence container，封装了领域对象的一些存储操作。结果我们架构和设计非常的复杂，我们试着找到一种办法：建立一张简单的图表，帮助开发人员理解如何使用存储层来工作。其间我们还发现重构能够使我们的设计易于理解。实践使用最简单的工具能够使得过程变得简单。工具越简单就越容易使用，这就降低了他人在你的模型上工作的门槛，也就增加了实际中别人去这么做的机会，这也包括了你的project stakeholder。通过使用最简单的工具，简单描述模型也变得更自然了。此外，当你使用一些简单/低精度的工具，例如索引卡片，即时贴，白板的时候，你就能亲身体验这些简单工具的效力，你在不知不觉中已经强化了一些概念：最简单的解决方法实际上也能非常有效，对你正在开发的系统采用简单的设计。

    验证类别包含了两个核心实践：测试性思维和用代码验证。有一条哲学，我常从中受益：“如果你无法测试它，你就不应该建立它，而你建立的一切都应该加以测试。”这使得我在系统建模时就考虑测试，也使得我积极的去获取我的模型的反馈－－实际上，我把该条哲学归纳为“考虑你创建的所有artifact的可测试性，以及验证所有种类的artifact。”但这并不仅仅局限于AM的范围之内。通过这种可测试性的考虑，在我建模时，我能够建立起可测试的模型，而且积极的通过编码来验证模型，这样，我就能够尽快的证实我的模型是真正可以测试的。