迭代和递增类别中包括了使用合适的artifact，并行创建模型，切换到另外的artifact，小增量建模这几项实践。不论哪一个artifact，都有它的长处和短处，任何一个单独的模型都不足以充分的描述你的项目的各个主要方面（如需求、架构）。例如你会发现你为了识别系统的需求，常常需要组合使用用例、业务规则定义、和技术需求定义。单单靠用例就能令project stakeholder立马告诉你他们所有的使用需求吗？这恐怕不太可能。你可以试试换用诸如业务规则之类的artifact来捕获他们的所有业务政策，再换用诸如技术需求的artifact来捕获他们的非功能需求。否则，他们会想起点什么就告诉你什么，还会返回去讨论先前提过的细节，甚至是改变他们的原来的主意。你的需求识别工作通常是一个动态的过程，分析、架构、设计工作也是一样。 我相信物力论中指出了人们以此种方式思考的原因，我们思考的方式明显是杂乱的。敏捷建模者要认识到人们是以一种动态的方式在思考，特别是人们处于群体行为时，这样才能制定对策。敏捷建模者并行创建模型，从而能够最广泛的收集信息。这项实践又是由实践切换到另外的artifact和小增量建模来支持的－－你可能正在使用用例来捕获使用需求的相关信息，而当stakeholder开始讨论他们对编辑屏幕的要求时，你最好是使用基本用户界面原型或是传统用户界面原型来记录这些需求。你需要在不同的artifact之间来来回回，每一个artifact最好都需要编码来验证，这种方式可以由小增量建模的实践来实现－－最典型的方式就是在这个artifact上做一会儿工作，再换一个artifact，依此类推。
简单这个类别包括了创建简单的内容，简单地建模，使用最简单的工具这几项核心实践。创建简单的内容和简单地建模这两个实践集中于模型的简单性，在建模过程中这两项实践通产是密不可分的。把精力集中在如何简单描述，建模者常常会发现一些使得你手头的模型简单化的方法。举个例子，我曾经参加了一项存储层软件的开发工作，软件的概念类似于EJB的persistence container，封装了领域对象的一些存储操作。结果我们架构和设计非常的复杂，我们试着找到一种办法：建立一张简单的图表，帮助开发人员理解如何使用存储层来工作。其间我们还发现重构能够使我们的设计易于理解。实践使用最简单的工具能够使得过程变得简单。工具越简单就越容易使用，这就降低了他人在你的模型上工作的门槛，也就增加了实际中别人去这么做的机会，这也包括了你的project stakeholder。通过使用最简单的工具，简单描述模型也变得更自然了。此外，当你使用一些简单/低精度的工具，例如索引卡片，即时贴，白板的时候，你就能亲身体验这些简单工具的效力，你在不知不觉中已经强化了一些概念：最简单的解决方法实际上也能非常有效，对你正在开发的系统采用简单的设计。
验证类别包含了两个核心实践：测试性思维和用代码验证。有一条哲学，我常从中受益：“如果你无法测试它，你就不应该建立它，而你建立的一切都应该加以测试。”这使得我在系统建模时就考虑测试，也使得我积极的去获取我的模型的反馈－－实际上，我把该条哲学归纳为“考虑你创建的所有artifact的可测试性，以及验证所有种类的artifact。”但这并不仅仅局限于AM的范围之内。通过这种可测试性的考虑，在我建模时，我能够建立起可测试的模型，而且积极的通过编码来验证模型，这样，我就能够尽快的证实我的模型是真正可以测试的。
辅助实践
文档类别包括了三项辅助实践：丢弃临时模型，合同模型要正式，非到万不得已不更新。在项目的进行中，需求、对需求的理解、以及对可能的解决方案的理解，都在不断变化（回忆一下原则拥抱变化）。为了反映这种变化，你需要同步改进你大部分的项目artifact，包括模型和文档。就像在敏捷文档讨论的那样，比较好的方法是，不到万不得已不要更新你的模型和文档，这种做法才算是敏捷方法。遵循这项实践，如果你发现一个模型如果不再需要更新，那就是说这个模型对你的团队已经没什么价值了，一个没有价值的模型就可以视为临时模型，可以丢弃。不过，要注意合同模型。它定义了你的系统和其他系统之间的接口，不太可能经常改变，因为它们的重要性是勿庸置疑的。一言以蔽之，如果你有个非合同模型不再更新，那就意味着它已经没有用了。
为沟通建模和为理解建模这两项实践属于动机类别。实际上，这两项实践并没有太多的联系，有时候你创建模型的目的是为了研究和理解问题，有时候你的目的是为了和其他人交流你的想法，有时候你的目的包括了上述两者。就像你在图1中看到的，这两项实践常常会一起引出另两类的实践，这是下文要讨论的主题。
最后，生产率类别中包括使用建模标准，逐渐应用模式，以及重用现有的资源这几项实践。重用现有资源这个实践要求你尽量利用他人的工作成果并从中受益，这有很多种思考方向：一种是应用模式，根据经验，我认为它是所有重用方法中最有效率的一种，因为你重用的都是其它开发人员久经验证的解决方案 (Ambler, 1999)；另一种是遵循建模标准和指南，实际上，不论是标准还是指南，都能够提高你工作的一致性。是的，你可以自己写指南，有时你必须要这么做，因为你的实际环境中会有一些特别的情况。但是你只需要在Internet上稍做搜索就可以找到很多的开发指南。例如，你可javaCodingStandards找到Java的开发指南。
类别间的联系
让我们考虑团队协作类别。简单类别中的实践增强了实践stakeholder的积极参与的效果，因为简单性消除了参与的代沟。迭代和递增类别中的实践也使得参与成为可能，尤其是并行创建模型，因为它增大了stakeholder们参加的机会。动机类别中的实践可以提高集体所有制和和他人一起建模的效果，对问题的理解和沟通通常可以激发人们的协作精神，简单类别的实践也也坑达到激发协作效果，因为它降低了参与的门槛。公开展示模型的效果可以通过生产力类别中的实践得到提高。遵循标准，应用模式的做法可以增加一致性和可读性，而重用现有的资源（例如通用架构），则给别人开了一个好头，使别人能够在你模型的基础上继续。迭代和递增类的实践可以支持集体所有制的实行，特别是并行创建模型和切换到另外的artifact，它们使得人们在适当的模型上共同开发。
简单类别的实践由另外几类的实践来辅助。使用建模标准和逐渐应用模式这两项实践支持同一种建模语言（使用标准和容易理解的模式），从而支持了实践简单地建模。文档类别的实践也可以支持简单类别的实践－－只有到万不得已才更新模型，这样，你才不会给模型增加不必要的信息。才有可能创建简单的内容以及简单地建模。
文章来源于领测软件测试网 https://www.ltesting.net/
