局部调整. 你的软件开发方法要能够反映你的环境，这个环境包括组织特征，project stakeholder的特征，项目自身的特征。有可能受其影响的问题包括：你使用的建模技术（也许你的用户坚持要看到一个细节的用户界面，而不是初始草图或基本原型）；你使用的工具（可能你没有数字照相机的预算，或是你已经拥有某个CASE工具的license）；你遵循的软件过程（你的组织采用XP的开发过程，或是RUP，或是自己的过程）。因此你会调整你的方法，这种调整可能是针对项目的，也可能是针对个人的。例如，有些开发人员倾向于使用某一类工具，有些则不用。有些人在编码上花大力气，基本不做建模，有些则宁可在建模上多投入一些时间。
开放诚实的沟通.人们需要能够自由的提出建议，而且人们还应该能够感受到他们是自由的。建议可能是和模型有关的想法：也许是某些人提出某部分新的设计方法，或是某个需求的新的理解；建议还可能是一些坏消息，例如进度延误；或仅仅是简单的工作状况报告。开放诚实的沟通是人们能够更好的决策，因为作为决策基础的信息会更加准确。
利用好人的直觉.有时你会感觉到有什么地方出问题了，或是感觉什么地方有不一致的情况，或是某些东西感觉不是很对。其实，这种感觉很有可能就是事实。随着你的软件开发的经验的增加，你的直觉也会变得更敏锐，你的直觉下意识之间告诉你的，很可能就是你工作的关键之处。如果你的直觉告诉你一项需求是没有意义的，那你就不用投入大量的精力和用户讨论这方面的问题了。如果你的直觉告诉你有部分的架构不能满足你的需要，那就需要建立一个快速技术原型来验证你的理论。如果你的直觉告诉设计方法A要比设计方法B好，而且并没有强有力的理由支持你选择某一个方法，那就尽管选择方法A。勇气的价值就已经告诉你，如果未来证实你的直觉是错的，你也有能力来挽救这种情况。你应该有这种自信，这很重要。
敏捷建模的实践
敏捷建模（AM）在AM原则的基础上定义了一组核心实践（practice）和补充实践，其中的某些实践已经是极限编程（XP）中采用了的，并在Extreme Programming Explained一书中有详细的论述，和AM的原则一样，我们在描述这组实践时，将会注重于建模的过程，这样你可以从另外一个角度来观察这些已或XP采用的素材。
核心实践：
Stakeholder的积极参与.我们对XP的现场客户（On-Site Customer）的概念做了一个扩充：开发人员需要和用户保持现场的接触；现场的用户要有足够的权限和能力，提供目前建构中的系统相关的信息；及时、中肯的做出和需求相关的决策；并决定它们的优先级。AM把XP的“现场客户”实践扩展为“使project stakeholder积极参与项目”，这个project stakeholder的概念包括了直接用户、他们的经理、高级经理、操作人员、支持人员。这种参与包括：高级经理及时的资源安排决策，高级经理的对项目的公开和私下的支持，需求开发阶段操作人员和支持人员的积极参与，以及他们在各自领域的相关模型。
正确使用artifact.每个artifact都有它们各自的适用之处。例如，一个UML的活动图（activity diagram）适合用于描述一个业务流程，反之，你数据库的静态结构，最好能够使用物理数据（physical data）或数据模型（persistence model）来表示。在很多时候，一张图表比源代码更能发挥作用，一图胜千言，同样，一个模型也比1K的源代码有用的多，前提是使用得当（这里借用了Karl Wieger的Software Requirements中的词汇）。因为你在研究设计方案时，你可和同伴们和在白板上画一些图表来讨论，也可以自己坐下来开发一些代码样例，而前一种方法要有效的多。。这意味着什么？你需要了解每一种artifact的长处和短处，当你有众多的模型可供选择的时候，要做到这一点可没有那么容易。
集体所有制.只要有需要，所有人都可以使用、修改项目中的任何模型、任何artifact。
测试性思维.当你在建立模型的时候，你就要不断的问自己，“我该如何测试它？”如果你没办法测试正在开发的软件，你根本就不应该开发它。在现代的各种软件过程中，测试和质保（quality assurance）活动都贯穿于整个项目生命周期，一些过程更是提出了“在编写软件之前先编写测试”的概念（这是XP的一项实践：“测试优先”）。
并行创建模型.由于每种模型都有其长处和短处，没有一个模型能够完全满足建模的需要。例如你在收集需求时，你需要开发一些基本用例或用户素材，一个基本用户界面原型，和一些业务规则。再结合实践切换到另外的Artifact，，敏捷建模者会发现在任何时候，同时进行多个模型的开发工作，要比单纯集中于一个模型要有效率的多。
创建简单的内容.你应该尽可能的使你的模型（需求、分析、架构、设计）保持简单，但前提是能够满足你的project stakeholder的需要。这就意味着，除非有充分的理由，你不应该随便在模型上画蛇添足－－如果你手头上没有系统认证的功能，你就不应该给你的模型增加这么一个功能。要有这样的勇气，一旦被要求添加这项功能，自己就能够马上做到。这和XP的实践“简单设计”的思想是一样的。
简单地建模.当你考虑所有你能够使用的图表（UML图、用户界面图、数据模型等）时，你很快会发现，大部分时候你只需要这些图表符号的一部分。一个简单的模型能够展示你想要了解的主要功能，例如，一个类图，只要能够显示类的主要责任和类之间的关系就已经足够了。不错，编码的标准告诉你需要在模型中加入框架代码，比如所有的get和set操作，这没有错，但是这能提供多少价值呢？恐怕很少。
文章来源于领测软件测试网 https://www.ltesting.net/