靈活模組化和極限程式設計(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

适用于極限程式設計

<a href="http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm">Active Stakeholder Participation</a>

利益有關者積極參與

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在顧客的地方使用的長期項目的利益相關者，并着重對他們的積極參與，是以活動的利益相關者的參與，而不是網站上的利益相關者的概念。

<a href="http://www.agilemodeling.com/practices.htm#ApplyModelingStandards">Apply Modeling Standards</a>

應用模組化标準

這是AM版XP的編碼标準的做法。

<a href="http://www.agilemodeling.com/practices.htm#ApplyPatternsGently">Apply Patterns Gently</a>

輕量級應用模式

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的設計簡單的做法。

<a href="http://www.agilemodeling.com/practices.htm#ApplyTheRightArtifacts">Apply the Right Artifact(s)</a>

采用正确的加工品

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的哲學相一緻的“，如果你需要做”，用手頭的工作最合适的工具或技術。

<a href="http://www.agilemodeling.com/practices.htm#CollectiveOwnership">Collective Ownership</a>

集體擁有權

AM has adopted XP’s Collective Ownership practice.

AM已認證XP的集體所有權的實踐。

<a href="http://www.agilemodeling.com/practices.htm#CreateSeveralModelsInParallel">Create Several Models in Parallel</a>

建立并行的幾種模式

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卡，接受測試的情況下，和草圖 - 如果他們選擇這樣做。

<a href="http://www.agilemodeling.com/practices.htm#CreateSimpleContent">Create Simple Content</a>

建立簡單的内容

This is complementary XP’s Simple Design practice that advises to keep your models as simple as possible.

這是互補XP的簡單設計的做法，建議保持盡可能簡單的模型。

<a href="http://www.agilemodeling.com/practices.htm#DepictModelsSimply">Depict Models Simply</a>

簡單地描繪模型

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卡和使用者故事。

<a href="http://www.agilemodeling.com/practices.htm#DiscardTemporaryModels">Discard Temporary Models</a>

丢棄臨時模型

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已認證，明确建議你，你不再需要處理模型。

<a href="http://www.agilemodeling.com/practices.htm#DisplayModelsPublicly">Display Models Publicly</a>

公開顯示模式

This practice reflects XP’s (and AM’s) value of Communication, principle of Open &amp; Honest Communication (adopted by AM), and reflects its practice of Collective Ownership.

這種做法反映了XP的（和AM）通信，開放和誠實的溝通原則（被AM采納）的價值，并反映其集體所有權的實踐。

<a href="http://www.agilemodeling.com/practices.htm#FormalizeContractModels">Formalize Contract Models</a>

正式聯系模型

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中，或許在其“如果你需要，然後做”的經營理念。這種做法被列入我對于如何處理與其他系統內建的很常見的情況提供指導。

<a href="http://www.agilemodeling.com/practices.htm#IterateToAnotherArtifact">Iterate to Another Artifact</a>

疊代到另一個加工品

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卡，測試工作。

<a href="http://www.agilemodeling.com/practices.htm#ModelInSmallIncrements">Model in Small Increments</a>

以較小的增量模型

這種做法，支援XP的疊代和遞增的發展方針。 XP和AM都喜歡發展的應急辦法，不是前面的大設計（BDUF）方法。

<a href="http://www.agilemodeling.com/practices.htm#ModelWithOthers">Model With Others</a>

與其他模型

This is the AM version of XP’s Pair Programming practice.

這是AM版XP的結對程式設計實踐。

<a href="http://www.agilemodeling.com/practices.htm#ProveItWithCode">Prove it With Code</a>

用代碼證明

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的原則混凝土實驗。事實上，它最初被稱為具體的實驗雖然改了名，當它被演變成一種做法。

<a href="http://www.agilemodeling.com/practices.htm#ReuseExistingResources">Reuse Existing Resources</a>

重用現有的資源

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的開發是可行的，如果有東西可用可适當重用，那麼他們很可能會選擇這樣做。

<a href="http://www.agilemodeling.com/essays/singleSourceInformation.htm">Single Source Information</a>

單源的資訊

The goal of storing information in a single place reflects the XP concept of traveling light.

将資訊存儲在一個地方的目标，反映的輕裝上陣XP的概念。

<a href="http://www.agilemodeling.com/practices.htm#UpdateOnlyWhenItHurts">Update Only When it Hurts</a>

僅當觸碰到是更新

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的旅行輕的原則，建議你應該隻更新一個神器，隻有當你迫切需要。

<a href="http://www.agilemodeling.com/practices.htm#UseTheSimplestTools">Use the Simplest Tools</a>

使用簡單的工具

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的原則與XP中的密切配合。八九十是通過直接從XP，其餘的 - 軟體是你的首要目标，使下一步的努力是你的第二個目标，模型的目的，多種模式，内容更重要比表示，每個人都可以學習别人和最大化利益相關者的投資回報率 - 顯然是與相容XP的理念。三種模組化的具體原則可能會導緻暫停硬核XP片刻開發的，但反思不應該證明值得商榷。模型有目的的建議，你不應該無正當理由工作模型，多模型，說你有一個廣泛的技術提供給您，您可以選擇适用于（包括但不限于CRC卡，使用者故事，和UML的圖）。

2.2 Refactoring and AM

2.2重構和AM

Refactoring is a technique to restructure code in a disciplined way, a technique that is a fundamental practice of XP.  The basic idea is that you make small changes to your code, called refactorings, to support new requirements and/or to keep your design as

simple as possible.  The advantage of refactoring is that it enables programmers to safely and easily evolve their code to fulfill new requirements or to improve its quality.

重構是一種技術來重組一個有紀律的方式，這是一個XP的基本實踐的技術代碼。基本的想法是，你做小改動你的代碼，稱為重構，以支援新的要求和/或保持你的設計盡可能簡單。重構的好處是，它使程式員可以輕松，安全地發展他們的代碼，以滿足新的要求，以提高其品質。

Is refactoring compatible with AM?  Yes.  Refactoring is a coding technique whereas AM does not address programming-related issues, therefore there is no technical overlap between the two.  What about a conceptual overlap?  AM address design modeling and refactoring

addresses design improvement of source code.  This begs the question “What do you do when you have an existing design model and you refactor your code?”  Although it’s an interesting question, the real issue is that you have two artifacts, a design model and

source code, that describe the design of your system.  One has changed, the source code, now you need to decide whether or not you wish to update the model.  The way that you originally arrived at the model is irrelevant to this issue, you could have gotten

there because you took an AM approach to develop it, you could have taken a BDUF approach, or you could adopted an existing model and are coding to it (for example, several organizations have developed persistence frameworks based on the design that I present

at http://www.ambysoft.com/persistenceLayer.html).  The issue is irrelevant of the type of design model, be it a UML class diagram, CRC cards, a physical data model, or a procedural structure chart.  The good news is that AM provides advice for how to deal

with such a situation, in particular the practice Discard Temporary Models suggests that you should consider whether you really need the design model and then if not get rid of it and the practice Update Only When it Hurts suggests that it’s often reasonable

to have artifacts such as the design model and the code out of sync.

重構與AM是相容的？是。重構是一種編碼技術，而我并沒有解決程式設計相關的問題，是以，兩者之間是有沒有技術的重疊。一個概念的重疊是什麼？位址設計模型和重構位址的源代碼的設計改進。這引出的問題：“你做什麼時，你有1現有的設計模式和你重構你的代碼”雖然這是一個有趣的問題，真正的問題是，你有兩個工件，一個設計模型和源代碼，描述設計您的系統。一個已經改變，源代碼，現在您需要決定您是否要更新模型。您最初在到達模型的方式是與這個問題無關，你可以得到，因為你拿了一個AM的方法來開發，可以采取BDUF方法，或者你可以通過現有的模型和編碼（例如，一些組織已經開發出持久性架構的基礎上設計的，我目前在http://www.ambysoft.com/persistenceLayer.html）。問題是設計模型的類型無關，它是一個UML類圖，CRC卡，實體資料模型，或者程式結構圖。好消息是，AM提供如何處理這種情況的意見，特别是實踐丢棄臨時模型表明，你應該考慮你是否真的需要設計模型，然後如果不擺脫它與實踐的更新隻當它傷害的建議，它是合理的，有文物，如設計模型和代碼同步。

So how do you apply AM and refactoring together?  Simple.  Apply AM practices as appropriate when you are modeling, use those models as input into your programming efforts, and refactor your code as you normally would have.  If you discover that you need to

attempt a major refactoring, get the team together to discuss it, modeling whenever appropriate, then approach the major refactoring as you would have in the past: as a collection of small refactorings. 

那麼，你如何适用于AM和重構？簡單。申請我模組化時你輸入到你的程式設計工作，使用這些模式，并重構您的代碼，你通常會在适當的做法。如果你發現你需要嘗試一個重大的重構，得到團隊一起讨論，模組化，然後适當的時候方法的主要你将不得不在過去的重構：作為一個小的重構集合。

Modeling tools that reverse-engineer your code can prove valuable when you are refactoring code, particularly when you are unfamiliar with that code. Many developers think visually, they grasp information communicated via pictures

more readily than they do information communicated textually, so CASE tools that quickly import a bit of code and create diagrams from them can be very useful.  It's quite common for CASE tools to import object-oriented source code, perhaps written in Java

or C++, and generate UML class diagrams that show the static structure of the code and UML sequence diagrams that depict its dynamic nature.  These diagrams can be used to quickly understand the existing code, the first step in refactoring it.

模組化工具，逆向工程的代碼可以被證明是有價值的，當你重構代碼，尤其是當你不熟悉的代碼。許多開發商認為，在視覺上，他們掌握更容易比他們傳達文本資訊，通過圖檔傳達的資訊，是以CASE工具，快速導入的代碼位，并從他們建立圖表是非常有用的。CASE工具導入Java編寫的面向對象的源代碼，也許這是相當普遍的或C + +，生成UML類圖顯示的代碼和UML序列圖的描繪，其動态性質的靜态結構。這些圖可用于快速了解現有的代碼，在重構的第一步。

2.3 Test-First Development and AM

2.3 測試先行的開發和AM

Test-first development is a development practice where you work in very short cycles where you consider a test, write the test and business code for it, get it to work, then continue.  These tests are collected into a development integration testing suite that

must be successfully run whenever code is submitted into your shared repository.  This practice is integral to XP.

你在很短的周期，你認為測試工作，測試先行的開發是一個發展的實踐，寫的測試和業務代碼，得到它的工作，然後繼續。這些測試收集到的發展內建測試套件必須成功運作時代碼送出到您的共享庫。這種做法是不可或缺的XP。

Is test-first development compatible with AM?  Yes.  Like refactoring, test-first development is more of a coding practice so there is little opportunity for technical overlap.  However, there is room for conceptual overlap because test-first development clearly

delves into the realm of detailed design since it provides developers with an opportunity to think through their code before they write it (as well as important feedback regarding their code).  If you’ve chosen to do a little modeling before writing your code,

perhaps to think through an issue larger than a single test case, then that’s okay.  In fact, it may even make your test-first development efforts easier, because you've thought things through better.  

測試先行的開發與AM相容嗎？是。像重構，測試先行的開發是一個編碼實踐，是以有技術重疊的機會很少。然而，有概念重疊的地方，因為測試先行的開發明确詳細設計領域的深入研究，因為它提供了一個機會，想通過他們的代碼之前，他們把它寫（以及重要的回報，對他們的代碼）的開發。如果你選擇了編寫代碼之前，做一點點的模型，也許是想通過一個問題大于一個測試用例，然後沒關系。事實上，它甚至可以使您的測試先行的開發方面的努力，更容易，因為你想通過更好的東西。

How do you apply AM within a test-first development environment?  As with refactoring, simply apply AM practices as appropriate when you are modeling, use those models as input into your programming efforts, and iterate between modeling, testing, and programming

as needed.  For more details, read the AMDD article.

如何申請我在測試先行的開發環境？至于與重構，簡單地套用AM在适當的做法，當你模組化，輸入到你的程式設計工作中使用這些模型，疊代模組化，測試和程式設計之間需要。有關詳細資訊，請閱讀的AMDD文章。

2.4 Which AM Practices to Adopt?

2.4 采用哪種AM實踐？

Only the ones that add value to what your team is trying to accomplish.  Ideally that will at least be the core practices of AM, therefore it would be fair to claim that you are in fact “doing AM”, and perhaps even adopt the supplementary practices as well.

 It is important to note that your goal isn’t simply to be able to say that you’re agile modeling, it is to improve your productivity as software developers.

隻有你的團隊，努力實作增加值。理想的情況下，将至少是AM的核心做法，是以這将是公平的要求，事實上，“做AM”，甚至采取補充的做法，以及。重要的是要注意，你的目标不隻是要能說，你是靈活模組化者，它是作為軟體開發人員來改善您的生産力。

3. AM Throughout the XP Lifecycle

3. AM貫穿整個XP的生命周期 

To explain how the practices of AM can be applied on an XP I will work through a portion of the SWA Online Case Study and show how  modeling is used throughout the XP lifecycle in the article AM and XP: AM Throughout the XP Lifecycle. 

解釋如何使AM實踐可以應用在一個XP上，我将努力通過部分的SWA線上為例，展示如何模組化是整個XP的生命周期在AM和XP的文章：在整個XP的生命周期。

4. How Do You Make This Work?

4. 你如何做這項工作？

How should you approach modeling during development on an XP project?  Beck suggests that you should apply the XP practice of Small Initial Investment and draw a few pictures at a time.  He states that the XP strategy is that anyone can design with pictures

all they want, but as soon as a question is raised that can be answered with code then the designers must turn to code for the answer.  In other works you should then seek Rapid Feedback to discover whether your pictures are on target by following the AM practice

Prove it With Code.

你應該如何對待一個XP項目的開發過程中的模組化？貝克建議，你應該适用于小的初始投資的XP實踐和時間繪制了幾張圖檔。他指出，XP的政策是，任何人都可以設計圖檔所有他們想要的，但隻要作為一個問題提出，可以用代碼回答，然後設計者必須把答案代碼。在其他作品中，你應該尋求快速回報，發現你的照片是否目标是通過以下的AM實踐證明它的代碼。

When should you consider modeling during development on an XP project?  Whenever creating a model is more effective that writing code.  In other words, follow the AM principle maximize stakeholder ROI and the AM practice Apply the Right Artifact(s).

當你應該考慮一個XP項目的開發過程中的模組化？每當建立一個模型是更有效地編寫代碼。換句話說，按照AM的原則，最大限度地發揮利益相關者的投資回報率和采用正确的加工品的AM實踐。

How should you model?  Follow AM’s practice Use the Simplest Tools and prefer tools such as index cards, whiteboards, and Post It notes over more complicated CASE tools.  Simple tools tend to promote interaction and communication, two factors that are critical

to your success.  Although XP favors the use of index cards to record user stories, CRC models, and story tasks there is nothing wrong with using a CASE tool as long as its use provides positive value to your effort.

你應該如何模組化？遵循AM的實踐，用最簡單的工具和喜歡索引卡，白闆等工具，并張貼注意到以上的更複雜的CASE工具。簡單的工具，往往促進互動和交流，您的成功是至關重要的兩個因素。盡管XP有利于使用索引卡來記錄使用者的故事，CRC模型，和劇情任務，隻要使用一個CASE工具，它的使用提供了積極的價值你的努力沒有錯。

How should you document?  XP teams prefer to write clean, easy-to-understand source code – their philosophy is that only the source code is in sync with the source code.  However, remember that AM’s principle Model With A Purpose states that you should understand

the needs of a model/document’s audience.  If the audience for documentation is your system’s users or your senior management then clean source code isn’t going to do it, instead you will need to develop external documentation for this audience.  Your stakeholders

should request this documentation and should understand the costs involved, one of which is the fact that any time you spend writing documentation isn’t spent writing software, and be willing to accept those costs.

你應該如何記錄？XP團隊喜歡寫幹淨，易于了解的源代碼 - 他們的理念是，隻有源代碼是在與源代碼同步。但是，請記住，我的原則與目的國模型，你應該了解模型/文檔的觀衆的需求。如果觀衆檔案系統的使用者或進階管理人員，然後幹淨的源代碼不打算這樣做，而不是你将需要開發這個觀衆的外部文檔。你的利益攸關方應請求這個檔案，并應了解所涉及的費用，其中之一是沒有花任何時間花在編寫文檔編寫軟體，并願意接受這些費用的事實。

XP developers need to recognize that you can model on an XP project, that modeling is in fact a part of XP already with its existing application of user stories and CRC cards.  More importantly, XP developers must abandon any preconceived notions that they

may have about modeling - that big modeling up front (BMUF) is the only approach to modeling, that models are permanent documents that must always be updated, that you need to use complex CASE tools to model, and that the UML defines the only models available

to you - and approach modeling from a new perspective.  One such perspective was presented in this article, that you can tailor Agile Modeling (AM) into a software process based on eXtreme Programming (XP) and still remain effective as software developers.

XP開發人員需要認識到，你可以模拟一個XP項目，該模型實際上是一個XP的一部分已經與現有的應用程式其使用者故事和CRC卡。更重要的是，XP的開發必須摒棄任何先入為主的觀念，他們可能有大約模組化 - 大，前面模組化（BMUF）的模型，模型是必須始終更新的永久檔案是唯一的辦法，你需要使用複雜的情況下工具的UML模型，并定義唯一的車型為您提供 - 從一個新的視角和方法模組化。這樣一個觀點，在這篇文章中，你可以定制靈活模組化（AM）到極限程式設計（XP）的基礎上，仍然有效的軟體開發商的軟體過程。

Reference sit: http://www.agilemodeling.com/essays/agileModelingXP.htm