敏捷建模和极限编程(XP)
Agile Modeling and eXtreme Programming (XP)
敏捷建模和极限编程(XP)
Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner. On the AM home page I state that one of the goals of AM is to address the issue of how to apply modeling techniques on software projects taking an agile approach such as eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), and Scrum to name a few. Because the scope of XP is much greater than that of AM, XP covers the full development lifecycle, it is a candidate "base process" into which the techniques of AM may be tailored. Furthermore, although XP clearly includes modeling as part of its process it is not as explicit about how to do so as many developers would prefer. Hence an opportunity for AM. Luckily XP, like AM, is also an agile practices-based methodology which makes the conceptual fit between the two methods much easier than between AM and a process such as the Rational Unified Process (RUP) the topic of the article Agile Modeling and the Unified Process.
敏捷建模（AM）是一个实践为基础的软件过程，其范围是描述如何以一个有效和灵活的方式建模和建立文档，在AM主页，我指定AM的目标之一是如何应用软件工程建模技术，如敏捷方法解决的问题，比如极限编程（XP），动态系统开发方法（DSDM），和Scrum等等。因为XP的范围远远比AM大，XP涵盖整个开发生命周期，它是一个候选的AM技术，可定制的“基过程”。此外，虽然XP显然包括建模过程的一部分，但是许多开发人员宁愿不清楚它是如何做到这一点。因此有机会给AM。幸运的是XPAM一样，也是一个灵活的实践为基础的方法，这使得适合之间的两种方法比之间时要容易得多，如统一软件开发过程（RUP）的文章敏捷建模与统一过程的主题。
Table of Contents
目录
Setting the record straight
弄清真相
XP and AM?
XP和AM？
AM throughout the XP lifecycle
AM贯穿整个XP的生命周期
How do you make this work?
你如何做这项工作？
1. Setting The Record Straight
1。弄清真相
There are several common misconceptions that people seem to have regarding modeling on an XP project. The three most common misconceptions are that you don’t model on an XP project, that you don’t document on an XP project, or that if you do model your only options are the modeling artifacts of the UML. I’ll address these misconceptions in turn in this section, but first I want to explore why they occur so that you can recognize other misconceptions when they arise. From what I can gather based on the conversations on the AM mailing list the source of these misconceptions is often the result of one or more of the following:
有几个常见的误解，人们似乎已经对一个XP项目的建模。 3种最常见的误解是，你没有建模在一个XP的项目上，你不记录在一个XP项目上，或者说，如果你做模型的唯一的选择是UML的建模构件。我会在本节轮流来处理这些误解，但首先我想探讨他们为什么会发生的，以便在他们出现时你可以认出其他误解。从我收集的基础上在AM的谈话邮件列表列出这些误解的根源往往是一个或多个以下的结果：
Second-hand knowledge of XP. The Internet is a major source of information for many developers, in particular newsgroups and emails from colleagues. As people learn a new technique they often join a newsgroup or mailing list, such as the extremeprogramming list, and start monitoring the group/list. Someone will post something, which may not be accurate, and many people will accept it as official, particularly when they haven’t had an opportunity yet to try it out for themselves. Don’t believe everything that you hear.
XP过时的知识。互联网是一个许多开发人员信息的主要来源信息，特别是同事的新闻组和电子邮件。随着人们学习一门新的技术，他们往往加入新闻组或邮件列表，如extremeprogramming极限编程列表，并开始监测组或者列表。有人会发表某些东西，这可能是不准确的，很多人会接受它作为官方的，特别是当他们已经没有机会为自己尝试。不要相信你听到的一切。
Questionable sources of information regarding XP. It’s often hard to determine the quality of published material, be it electronic or printed form. Sometimes honest mistakes are made, that’s happened to me more than once, and sometimes people publish misleading information on purpose. When you’re just learning a new subject you often cannot distinguish between high-quality sources of information and questionable ones. If you base your understanding on questionable sources it is very easy to get the wrong idea about XP.
关于XP中的可疑信息来源。这往往很难确定公布的材料的质量，无论是电子或印刷形式。有时候，诚实的错误，这是发生在我身上不止一次，有时人故意发布误导性信息。当你刚开始学习一个新的课题，你往往不能区分高品质的信息来源和可疑的信息来源。如果你根据你对问题的来源的理解，这是很容易得到关于XP的错误观念。
Difficulty seeing beyond their current environment. Many developers find themselves in less-than-ideal environments. XP requires you to adopt practices that are often foreign to your current environment, pair programming and test-first development are new to most organizations, and sometimes these practices simply aren’t feasible to adopt. If you cannot adopt the practice of pair programming then XP isn’t going to work for you, but instead of proclaiming that XP doesn’t work in their environment many people will instead proclaim that XP doesn’t work at all. The reality is that XP does in fact work in the right situations, it is just that your situation may not be one of the right ones.
很难看出超出他们当前的环境下。许多开发人员发现自己在低于理想的环境。XP需要您采取的做法，往往是在当前的环境之外，对结对编程和测试优先开发的大部分组织是新的，有时这些做法根本是不可行的采用。如果你不能通过结对编程的实践，然后XP是不会为你工作，但很多人宣布XP根本不能用，而不是宣布XP并不在他们的环境中工作。现实的情况是，XP的确能工作在合适的情况下，事实上，这仅是您的具体情况可能并非正确做法中的一种。
Too much focus on the word “extreme”. XP’s name is both one of its greatest strengths its greatest weaknesses. Because of the name when some people hear XP’s advice to travel light, to reduce the amount of documentation that you create and maintain, that they instead translate it to “create no documentation at all”. That’s extreme, right? Or they’ll hear XP’s advice to use simple modeling techniques such as user stories and CRC cards and somehow translate that advice to “you don’t model at all.” That’s extreme, right? Sigh.
过多集中于“极限”的字。 XP的名字，既是其最大的优点，亦是其最大的弱点之一。因为当一些人听到XP的意见来轻装上阵，以减少您所创建和维护的文档的数量，，他们反而把它翻译为“根本不用创建文档”。这就是极限，对吗？或者他们会听到XP的意见去一些简单的建模技术，比如用户故事和CRC卡(注：Class类别, Responsibility责任, Collaborator辅助者)，或者换种方式说“你根本不必建模”这就是极限，对吗？哎.
In this section I will set the record straight regarding the three most common issues concerning modeling and XP:
在本节中，我将弄清楚最常见的三种关系建模和XP的问题：
Modeling is Part of XP
建模是XP的一部分
Documentation happens
建立文档的发生
XP and the UML?
极限编程和统一建模语言？
1.1 Modeling is Part of XP
1.1 建模是XP的一部分
User stories are a fundamental aspect of XP and artifacts such as Class Responsibility Collaborator (CRC) cards are common to XP efforts. User stories provide a high-level overview of the requirements for a system -- they are reminders to have a conversation with your project stakeholders regarding their requirements -- and are used to as a primary input into estimating and scheduling, and drive the development of acceptance test cases. CRC cards are used to explore structure, perhaps for conceptual modeling to understand the problem domain or for design to work through the structure of your software. User stories and CRC cards are both models, see the Artifacts for AM article, so therefore modeling is clearly a part of XP. XP developers will also create sketches, often on a whiteboard or a piece of paper, whenever user stories and CRC cards aren’t the best option. In Extreme Programming Explained, the first book written about XP, Kent Beck includes hand-drawn sketches of class diagrams and other free-form diagrams. In fact, in the second edition he includes a mind map in the inside cover overviewing XP. The bottom line is that modeling is a fundamental aspect of XP, something that I explore in detail in this article.
用户故事是XP和加工品的基本方面，如类责任合作者（CRC）卡对XP的努力来说是很普遍的。用户故事为一个系统需求提供了高层次的概述 - 他们有一个与您的项目利益相关者对他们的要求谈话提醒 - 被用来作为主要输入到估计和调度，并推动发展验收测试用例。 CRC卡是用来探讨结构，也许是为概念建模的理解问题域，或通过你的软件的结构来设计工作。用户故事和CRC卡都是模型，请参阅我的文章的加工品，因此建模显然是一个XP的一部分。 每当用户故事和CRC卡是不是最好的选择，XP的开发者也将创建草图，经常在白板上或一块纸上。在极限编程已说明过的，关于XP编写的第一本书，Kent Beck包括类图和其他自由形式的图的手绘草图。事实上，他在第二版包括在里面覆盖概览XP的脑海映像。底线是，建模是一个XP的基本方面，我在这篇文章中详细探讨。
1.2 Documentation Happens
1.2 建立文档的发生
Documentation is also an important part of XP. Ron Jeffries offers the following advice:
文件也是一个XP的重要组成部分。罗恩·杰弗里斯提供以下建议：
“Outside your extreme programming project, you will probably need documentation: by all means, write it. Inside your project, there is so much verbal communication that you may need very little else. Trust yourselves to know the difference.”
"极限编程项目外，你可能会需要的文件：通过各种手段，把它写出来。在你的项目中，有这么多的口头沟通，而您可能需要很少其他的。相信自己知道其中的差别。"
There are several interesting implications of that statement. First and foremost, the XP community recognizes that documentation should be produced for people external to your team, people that AM would term project stakeholders. Second, it points out that verbal communication between team members reduces the need for documentation within the team. This is the result of project team members being co-located, making communication easier, as well as aspects of XP such as Pair Programming and Collective Ownership that promote communication between developers. As I discuss in the article on Communication documentation is only one form of communication, one that is typically the least effective, that can be easily replaced by more effective techniques such as face-to-face communication. Third, it recognizes that sometimes you do in fact need internal documentation for your team. This is consistent with the advice presented in Extreme Programming Installed where the authors point out that information resulting from conversations with your project stakeholders regarding user stories are captured as additional documentation attached to the card. More on this in the Section A Closer Look At the XP Lifecycle. Fourth, it suggests that XP team members should know when documentation is required and be allowed to act accordingly. Fifth, it implies that you should trust the team and give them control over their own destiny. This can be hard in many organizations. If the team is untrustworthy then you have a serious problem that needs to be dealt with, this is true regardless of whether they are following XP, or if they are trustworthy but your organizational culture doesn’t allow you to act based on that trust then once again you have a serious problem to deal with. Another problem is that when you are an outsider to an XP team, when you haven’t been actively involved in the conversations and interactions that have replaced the need for documentation, that it appears that there isn’t enough documentation. When this is the case, instead of forcing the team to write documentation instead invest the time to determine if they need the documentation that you believe is missing – suggest the documentation to the team, and if there is an actual need for it then they’ll create it. As Ron Jeffries likes to say, “It’s called Extreme Programming not stupid programming”. Finally, the most important implication for XP teams is that if you need documentation then write it.
声明有一些有趣的影响。
首先，XP社会认识到，文件应为你的团队外部的人，那些人，是我会长期项目的利益相关者产生。
第二，它指出，团队成员之间的口头沟通，减少了队内的文档需要。这是项目团队成员的合作，使沟通更容易，以及XP的方面，如对编程和集体所有权，促进开发商之间的沟通。正如我在文章中讨论通讯文件是只有一种形式的沟通，一个是一般至少有效，可以如面对面沟通，更有效的技术容易被取代。
第三，它承认，有时你事实上，确实需要为您的团队的内部文件。这是极限编程提出的意见是一致的安装在那里的作者们指出，信息与项目利益相关者的对话关于用户故事捕获卡连接到其他文档。在此更在第一个关于建立更紧密看看XP的生命周期。
第四，建议XP团队成员应该知道什么时候文件是必需的，是允许采取相应的行动。第五，它意味着，你应该信任的团队，并给予他们控制自己的命运。在许多组织中，这是很难。如果球队是靠不住的，那么你有一个严重的问题，需要处理，这是真实的，不管他们是否遵循XP，或者如果他们是值得信赖的，但您的组织文化不允许你，信任的基础上采取行动，然后再一次，你有一个严重的问题来处理。
另一个问题是，当你是一个XP团队，局外人当你有没有积极参与谈话相互作用，已经取代了对文档的需要，似乎没有足够的文件。何时这种情况下，而不是迫使团队写文档，而不是投资，如果他们需要时间来确定您认为是文件丢失 - 建议文档队，如果有实际需要为它然后，他们将创建它。正如罗恩·杰弗里斯喜欢说，“这就是所谓的极限编程没有愚蠢的编程”。
最后，XP团队最重要的意义是，如果您需要的文件，然后把它写入。
The need for documentation on an XP project is reduced by several of its practices. First, because of test-first development and a focus on acceptance testing there is always a working test suite that shows that your system works and fulfills the requirements implemented to that point. For the developers, these tests act as significant documentation because it shows how the code actually works. When you think about it, this makes a lot of sense. When you are learning something new do you prefer to read a bunch of documentation or do you look for source code samples? Many developers prefer to start at source code samples, and the test suite provides these samples. Second, XP’s focus on simplicity and practice of refactoring result in very clean and clear code. If the code is already easy to understand, why invest a lot of time writing documentation to help you to understand it? This applies to both internal and external documentation – why add comments to code that is already clear and unambiguous? If the code isn’t so, then refactor it to improve its quality or as a last resort write documentation. Even though some development environments make it easy to include documentation in your code, Java’s Javadoc utility is such an example, you only want to invest in documentation when it makes sense to do so and not just because it is easy.
一个XP项目的文档需要减少一些做法。
首先，因为测试先行的开发和验收测试的重点始终有一个工作的测试套件，表明你的系统的工作原理和满足的要求落实到这一点。对于开发商，这些测试作为显著的文档，因为它显示了如何实际工作的代码。当你想想看，这使得很多的意义。当你学习新的东西，你喜欢读一堆文件，或者你看看源代码样本？许多开发人员喜欢源代码样本，并开始测试套件提供了这些样品。
第二，XP的非常干净，清晰的代码重构结果的简单和实践上的焦点。如果代码已经是很容易理解，为什么投资了很多时间写文档，以帮助你了解它吗？这适用于内部和外部的文件 - 为什么添加代码，已经是明确和毫不含糊的意见？如果代码是不是这样，然后重构它，以提高其质量或作为最后的手段写文件。即使一些开发环境中可以很容易包括在您的代码中的文档，Java的javadoc工具是一个这样的例子，你只希望在文档中进行投资时是有意义的这样做，不仅因为它很容易。
What confuses many people regarding XP and documentation is that XP doesn’t specify potential documents to create during development. This is unlike the RUP which suggests a slew of potential project artifacts. Instead, the suggestion is to work together with your project stakeholders in an environment of rapid feedback and trust them to determine the things that they need, not just documents but any type of project enhancements. Once again, you need to have the courage to trust the people involved with the project. In the article Agile Documentation I discuss a collection of documents that you may choose to create and provide advice for when to consider creating them.
什么迷惑了许多人关于XP的文件是XP不指定潜在的开发过程中创建的文件。这是不同于RUP，这意味着一个潜在的项目工件的回转。相反，建议是与项目利益相关者在一个快速反馈的环境共同努力，相信他们能够确定的事情，他们需要的不只是文件，但任何类型的项目增强。再次，你需要有这样的勇气，信任与参与该项目的人。敏捷文档在文章中，我讨论的文件的集合，您可以选择以创建和提供建议时，要考虑他们创造的。
One of the greatest misunderstandings people have about XP regards concept of traveling light – many people believe that it means you don’t create any documentation, but nothing could be further from the truth. What traveling light actually means is that you create just enough models and documentation, too little or too much puts you at risk. As I suggest in Agile Documentation a good rule of thumb to ensure that you’re traveling light is that you shouldn’t create a model or document until you actually need it – creating either thing too early puts you at risk of wasting your time working on something you don’t actually need yet.
一个最大的误解，人们对XP有一个轻装上阵的概念 - 许多人认为，这意味着你不创建任何文件，但没有可能进一步从真相。轻装上阵，实际上是指的是你创建只是足够模型和文件，太少或太多置于风险之中。我建议在敏捷文档的一个很好的经验规则，以确保你轻装上阵，你不应该创建一个模型或文件，直到你真正需要它 - 创造任何东西，过早让你在浪费你的时间工作的风险你但实际上并不需要。
An important thing to understand about documentation on an XP project is that it is a business decision, not a technical one. This is consistent with AM’s philosophy regarding documentation, discussed in Agile Documentation. Jeffries says it best:
一个XP项目的文档了解一件重要的事情是，它是一个商业决定，而不是一个技术之一。这是AM的理念敏捷文档中所讨论的有关文件，一致。杰弗里斯说，最好的：
“If there is a need for a document, the customer should request the document in the same way that she would request a feature: with a story card. The team will estimate the cost of the document, and the customer may schedule it in any iteration she wishes.”
如果有需要的文件，客户应以同样的方式，她会要求功能要求文档：用一个小故事卡。该小组将估计文件的成本，客户可以安排她希望在任何迭代。
1.3 XP and The UML
1.3 极限编程和统一建模语言？
See the article XP and the UML? Clearly the Wrong Question to be Asking
看到这篇文章XP和UML？显然问错了问题
2. AM and XP?
2. AM和XP？
AM should be tailored into an existing, full lifecycle methodology, in order to improve its approach to modeling. Because modeling is clearly a part of XP, see above, the potential exists for AM to add value to an XP project. This assumes of course that there is possible to tailor AM into XP, I believe it is and argue so below, and that you can do so without detracting from what currently exists within XP. In particular, XP’s practices of refactoring and test-first development clearly do a very good job of filling in for two critical goals – promoting clean design and thinking through your design before writing code – that are typically associated with traditional modeling processes. My experience is that both refactoring and test-first development are complementary to AM and arguably enablers of several AM practices, as I argue below. In this section I explore the following issues:
AM应调整到一个现有的，完整的生命周期方法，以改善其建模方法。因为模型显然是一个XP的一部分，见上面，存在潜在AM添加一个XP项目的价值。这当然假设是有可能进入XP定制AM，我相信这是认为这样下面，你可以做而不减损目前在XP中存在。特别是，重构和测试优先发展的XP的做法显然填补两个关键目标的一个非常好的工作 - 促进您的设计，编写代码之前，洁净的设计与思考 - 通常与传统的建模过程。我的经验是，重构和测试优先发展是相辅相成的，我可以说是几个AM做法引擎，我认为以下。在本节中，我探讨了以下问题：
The potential fit between AM and XP
AM和XP之间的潜在适合
Refactoring and AM
重构和AM
Test-first development and AM
测试先行的开发和AM
Which AM practices to adopt?
我将采取哪种AM实践？
2.1 The Potential Fit Between AM and XP
2.1 AM和XP之间的潜在适合
A critical issue that must be addressed is how well AM fits with XP. Table 1 lists the practices of AM and either maps them to existing principles or practices of XP or discusses the potential fit of the AM practice when it is not explicitly a part of XP. Because XP was used as a foundation for AM many of the practices map straight to XP. However, because AM’s focus is on modeling several practices are clearly new, hence the potential for AM to bring value to an XP project.
必须解决的一个关键问题是如何我适合用XP。表1列出了AM的做法和他们现有的原则或XP的做法，或讨论潜在的合适的AM实践时，它是没有明确的XP的一部分或者地图。因为XP是用一个AM的基础的做法，许多映射直接到XP。然而，因为AM的工作重点是模拟几种做法显然是新的，因此潜在AM的XP项目带来价值。
Table 1. Applicability of AM Practices on an XP Project.
表1。在一个XP项目上AM实践的适用性。
AM Practice
敏捷建模实践
Fit With XP
适用于极限编程
Active Stakeholder Participation
利益有关者积极参与
This practice is simply a new take on XP’s On-Site Customer practice. AM uses the term project stakeholder in place of customer and focuses on the concept of their active participation, hence Active Stakeholder Participation and not On-Site Stakeholder.
这种做法简直是对XP的现场客户实践的新的起飞。AM在顾客的地方使用的长期项目的利益相关者，并着重对他们的积极参与，因此活动的利益相关者的参与，而不是网站上的利益相关者的概念。
Apply Modeling Standards
应用建模标准
This is the AM version of XP’s Coding Standards practice.
这是AM版XP的编码标准的做法。
Apply Patterns Gently
轻量级应用模式
This practice reflects the YAGNI principle to the effective application of patterns within your system, in conformance to XP’s practice of Simple Design.
这种做法反映YAGNI原则模式的有效应用在您的系统，符合XP的设计简单的做法。
Apply the Right Artifact(s)
采用正确的加工品
This practice is not explicitly described by XP principles and practices although is very much aligned with XP philosophies of “if you need it do it” and using the most appropriate tool or technique for the job at hand.
这种做法是不明确XP的原则和做法，虽然是非常与XP的哲学相一致的“，如果你需要做”，用手头的工作最合适的工具或技术。
Collective Ownership
集体拥有权
AM has adopted XP’s Collective Ownership practice.
AM已通过XP的集体所有权的实践。
Create Several Models in Parallel
创建并行的几种模式
This is a modeling-specific practice. XP developers can clearly work on several models – such as CRC cards, acceptance test cases, and sketches – if they choose to do so.
这是一个建模的具体实践。 XP开发人员可以清楚地工作的几种模式 - 如CRC卡，接受测试的情况下，和草图 - 如果他们选择这样做。
Create Simple Content
创建简单的内容
This is complementary XP’s Simple Design practice that advises to keep your models as simple as possible.
这是互补XP的简单设计的做法，建议保持尽可能简单的模型。
Depict Models Simply
简单地描绘模型
This is complementary XP’s Simple Design practice that suggests that your models do not need to be fancy to be effective, perfect examples of which are CRC cards and user stories.
这是相辅相成的XP的简单设计实践表明，你的模型不需要看中的是有效的完美的例子，这是CRC卡和用户故事。
Discard Temporary Models
丢弃临时模型
This practice reflects XP’s Travel Light principle, which AM has adopted, explicitly advising you to dispose of models that you no longer need.
这种做法反映了XP的轻装上阵的原则，AM已通过，明确建议你，你不再需要处理模型。
Display Models Publicly
公开显示模式
This practice reflects XP’s (and AM’s) value of Communication, principle of Open & Honest Communication (adopted by AM), and reflects its practice of Collective Ownership.
这种做法反映了XP的（和AM）通信，开放和诚实的沟通原则（被AM采纳）的价值，并反映其集体所有权的实践。
Formalize Contract Models
正式联系模型
This practice is not currently reflected within XP, well perhaps in its “if you need to then do it” philosophy. This practice was included in AM to provide guidance for how to deal with the very common situation of integrating with other systems.
这种做法目前尚未反映在XP中，或许在其“如果你需要，然后做”的经营理念。这种做法被列入我对于如何处理与其他系统集成的很常见的情况提供指导。
Iterate to Another Artifact
迭代到另一个加工品
This practice explicitly states, in a general form, the practice of XP developers to iterate between working on various artifacts such as source code, CRC cards, and tests.
这种做法明确规定，在一般的形式，XP的开发实践迭代之间的各种文物，如源代码，CRC卡，测试工作。
Model in Small Increments
以较小的增量模型
This practice supports XP’s iterative and increment approach to development. Both XP and AM prefer an emergent approach to development and not a big design up front (BDUF) approach.
这种做法，支持XP的迭代和递增的发展方针。 XP和AM都喜欢发展的应急办法，不是前面的大设计（BDUF）方法。
Model With Others
与其他模型
This is the AM version of XP’s Pair Programming practice.
这是AM版XP的结对编程实践。
Prove it With Code
用代码证明
This is the AM version of XP’s Concrete Experiments principle. In fact, it was originally called Concrete Experiments although was renamed when it was evolved into a practice.
这是AM版XP的原则混凝土实验。事实上，它最初被称为具体的实验虽然改了名，当它被演变成一种做法。
Reuse Existing Resources
重用现有的资源
This concept is not explicitly included in XP, although it clearly isn’t excluded either. XP developers are practical, if there is something available that can be appropriately reused then they will likely choose to do so.
这个概念没有明确包括在XP中，虽然这显然是不排除。 XP的开发是可行的，如果有东西可用可适当重用，那么他们很可能会选择这样做。
Update Only When it Hurts
仅当触碰到是更新
This practice reflects AM and XP’s Travel Light principle, advising that you should only update an artifact only when you desperately need to.
这种做法反映了AM和XP的旅行轻的原则，建议你应该只更新一个神器，只有当你迫切需要。
Use the Simplest Tools
使用简单的工具
This practice reflects AM and XP’s Assume Simplicity principle and is consistent with XP’s preference for low-tech tools such as index cards for modeling.
这种做法反映了AM和XP的简单性原则，是XP的低技术手段，如建模的索引卡的偏好是一致的。
The fact that AM’s practices are complementary to XP isn’t sufficient; there should also be a philosophical alignment between the two methodologies as well. I believe that there is. First, AM has adopted the four values of XP – Courage, Simplicity, Communication, and Feedback – and added a fifth one, Humility, one that is clearly compatible with XP. Second, the principles of AM are closely aligned with those of XP. Nine of eighteen are adopted directly from XP, and the remaining ones – Software is Your Primary Goal, Enabling the Next Effort is Your Secondary Goal, Model With a Purpose, Multiple Models, Content is More Important Than Representation, Everyone Can Learn From Everyone Else, and maximize stakeholder ROI – are clearly compatible with XP’s philosophies. The three modeling-specific principles may cause a hard-core XP developer to pause for a moment, but on reflection should not prove arguable. Model With a Purpose advises that you shouldn’t work on a model without good cause, Multiple Models says that you have a wide range of techniques available to you that you may choose to apply (including but not limited to CRC cards, user stories, and the diagrams of the UML).
事实上，AM的做法是相辅相成的XP是不够的，以及两者之间的方法也应该是一个有哲学对齐。我相信有。首先，AM已通过XP的四个价值观 - 勇气，简单，沟通，反馈 - 增加了五分之一，谦逊，一个显然是与XP兼容。那么，你如何适用于AM和重构？简单。申请我建模时你输入到你的编程工作，使用这些模式，并重构您的代码，你通常会在适当的做法。如果你发现你需要尝试一个重大的重构，得到团队一起讨论，建模，然后适当的时候方法的主要你将不得不在过去的重构：作为一个小的重构集合。
