极限编程
维基百科，自由的百科全书
极限编程（XP，eXtreme Programming）是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。XP的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。
XP为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信，这些在传统的软件工程中看来是“极端的”实践，将会使开发过程比传统方法更加好的响应用户需求，因此更加敏捷，更好的构建出高质量软件。
目录 |
[编辑] 历史
极限编程的创始者是肯特·贝克（Kent Beck）、沃德·坎宁安（ Ward Cunningham）和罗恩·杰弗里斯（Ron Jeffries），他们在为克莱斯勒综合报酬系统（Chrysler Comprehensive Compensation System )(C3) 的薪水册项目工作时提出了极限编程方法。Kent Beck在1996年3月成为C3的项目负责人，开始对项目的开发方法学进行改善。他写了一本关于这个改善后的方法学的书，并且于1999年10月将之发行，这就是《极限编程解析》（2005第二版出版）。克莱斯勒在2000年2月取消了实质上并未成功的C3项目，但是这个方法学却一直流行在软件工程领域中。至今2006年，很多软件开发项目都一直以极限编程做为他们的指导方法学。
該書闡述了如下的極致編程的哲學思想 ：
- 一種社會性的變化機制
- 一種開發模式
- 一種改進的方法
- 一種協調生產率和人性的嘗試
- 一種軟體開發方法
把極致編程一般化並用於其它型別的專案稱為極致專案管理。
[编辑] 背景
The 90s had seen the great promise of object technologies launch ambitious projects that in many cases ended in failure. Objects themselves, while conferring numerous advantages of reuse, were not the panacea that many had hoped they would be. Fluid, rapidly-changing requirements demanded shorter lifecycles, and did not go well with more traditional methods of development, which usually required extensive design up front and penalized later design changes with higher costs or missed deadlines.
[编辑] 起源
The Chrysler Comprehensive Compensation project was started in order to determine the best way to use object technologies, using the payroll systems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the persistence layer. They brought in Kent Beck, a prominent Smalltalk practitioner, to do performance tuning on the system, but his role expanded as he noted several issues they were having with their development process. He took this opportunity to propose and implement some changes in their practices based on his work with his frequent collaborator, Ward Cunningham.
- The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else. —[Kent Beck]
Beck invited Ron Jeffries to the project to help develop and refine these methods. Jeffries thereafter acted as a kind of coach to instill the practices as habits in the C3 team.
Information about the principles and practices behind XP was disseminated to the wider world through discussions on the original WikiWiki, Cunningham's Portland Pattern Repository. Various contributors dissected and expanded upon the ideas, some becoming fervent advocates, others becoming critics, and yet others picking out ideas (see agile software development).
[编辑] 現狀
Beck edited a series of books on XP, beginning with his own Extreme Programming Explained, spreading his ideas to a much larger yet very receptive audience. Authors in the series went through various aspects attending XP and its practices, even a book critical of the practices.
XP created quite a buzz in the late nineties and early two thousands, seeing adoption in a number of different milieus and environments radically different from its origins.
[编辑] 未來的方向
The high discipline required by the original practices often went by the wayside, causing certain practices to be deprecated or left undone on individual sites. Agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field. In the second edition of Extreme Programming Explained, Beck added more values and practices, and differentiated between primary and corollary practices.
[编辑] XP的目標
極限編程的主要目標在於降低因需求變更而帶來的成本。在道統系統開發方法中（如SDM），系統需求是在專案開發的開始階段就確定下來，並在之後的開發過程中保持不變的。這意味著專案開發進入到之後的階段時出現的需求變更—而這樣的需求變更在一些發展極快的領域中是不可避免的—將導致開發成本急速增加。這一概念可以用下圖來表示：
極限編程透過引入基本價值、原則、方法等概念來達到降低變更成本的目的。一個應用了極限編程方法的系統開發專案在應對需求變更時將顯得更為靈活。下圖展示了這一降低變更成本的目的︰
[编辑] XP 核心的實踐
極致編程實踐作業的核心，正如 Extreme programming explained 所描述的，可以被區分為以下四個範圍（12個實踐作業）:
小規模回饋
- 測試驅動發展
- 策劃遊戲
- 全隊（原名：在場客戶）
- 結對程式設計
反覆性程序而不是批量的
- 持續整合
- 設計最佳化（原名：軟體重構）
- 小型發佈
共同認識（共識）
- 簡單的設計
- 系統隱喻
- 集體程式碼所有
- 程式設計標準/程式設計規約
程式設計師的利益
- 恆定速路
- 可反覆性速率（原名：每週40小時）
在第二版的Extreme programming explained中，在主要實踐之外，還列出了一系列延伸的實踐。
核心實踐源自被廣泛接受的最佳實踐，並且被推向極至：
- Interaction between developers and customers is good. Therefore, an XP team is supposed to have a customer on site, who specifies and prioritizes work for the team, and who can answer questions as soon as they arise. (In practice, this role is sometimes fulfilled by a customer proxy.)
- If learning is good, take it to extremes: Reduce the length of development and feedback cycles. Test early.
- Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual needs at the present time in a project, and go to some lengths to reduce complexity and duplication in their code.
- If simple code is good, re-write code when it becomes complex.
- Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard (which also improves communication) so that all code is reviewed as it is written.
- Testing code is good. Therefore, in XP, tests are written before the code is written. The code is considered complete when it passes the tests (but then it needs refactoring to remove complexity). The system is periodically, or immediately tested using all pre-existing automated tests to assure that it works. See test-driven development.
It used to be thought that Extreme Programming could only work in small teams of fewer than 12 persons. However, XP has been used successfully on teams of over a hundred developers. It is not that XP doesn't scale, just that few people have tried to scale it, and proponents of XP refuse to speculate on this facet of the process.
[编辑] XP的價值
最初，极限编程技术只提出了四条价值标准，而在《极限编程解析》的第二版中又加入了第五条。以下就是这五条标准：
- 溝通
- 簡單
- 回饋
- 勇氣
- 尊重（最新添加的价值）
[编辑] 溝通
构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。
极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法（Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team）。它的目标是向所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与反馈。
[编辑] 簡單
极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。
[编辑] 反馈
在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：
- 来自系统的反馈：通过编写单元测试，程序员能够很直观的得到经过修改后系统的状态。
- 来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度。
- 来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户。
反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性的测试。用Kent Beck的话来说：“编程中的乐观主义是危险的，而及时反馈则是解决它的方法。”
[编辑] 勇氣
极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。
[编辑] 尊重
尊重的价值体现在很多方面。在极限编程中，团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试case失败、或者以其他方式导致工作延期。团队成员对于他们工作的尊重体现在他们总是坚持追求高质量，坚持通过重构的手段来为手头的工作找到最好的解决设计方案。
[编辑] 原则
组成极限编程基础的原则，正是基于上面描述的那几条价值。在系统开发项目中，这些原则被用来为决策做出指导。与价值相比，原则被描述的更加具体化，以便在实际应用中更为简单的转变为具体的指导意见。
[编辑] 快速反饋
当反馈能做到及时、迅速，将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间，一般被用来掌握新情况以及做出修改。与传统开发方法不同，与客户的发生接触是不断反复出现的。客户能够清楚地洞察开发中系统的状况。他/她能够在整个开发过程中及时给出反馈意见，并且在需要的时候能够掌控系统的开发方向。
单元测试同样对贯彻反馈原则起到作用。在编写代码的过程中，应需求变更而做出修改的系统将出现怎样的反应，正是通过单元测试来给出直接反馈的。比如，某个程序员对系统中的一部分代码进行了修改，而假如这样的修改影响到了系统中的另一部分（超出了这个程序员的可控范围），则这个程序员不会去关注这个缺陷。往往这样的问题会在系统进入生产环节时暴露出来。
[编辑] 假設簡單
假設簡單認為任何問題都可以"極度簡單"的解決。傳統的系統開發方法要考慮未來的變化，要考慮程式碼的可重用性。極致編程拒絕這樣作。
[编辑] 增量變化
极限编程的提倡者总是说：罗马不是一天建成的。一次就想进行一个大的改造是不可能的。极限编程采用增量变化的原则。比如说，可能每三个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式，使得整个开发进度以及正在开发的系统对于用户来说变得更为可控。
[编辑] 包容變化
可以肯定地是，不确定因素总是存在的。“包容变化”这一原则就是强调不要对变化采取反抗的态度，而应该包容它们。比如，在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。作为程序员，必须包容这些变化，并且拟定计划使得下一个阶段的产品能够满足新的需求。
[编辑] 活動
XP describes four basic activities that are performed within the software development process.
[编辑] 編碼
The advocates of XP argue that the only truly important product of the system development process is code (a concept to which they give a somewhat broader definition than might be given by others). Without coding you have nothing.
Coding can be drawing diagrams that will generate code, scripting a web-based system or programming an object-oriented C# program that needs to be compiled.
Coding can also be used to figure out the most suitable solution. For instance, XP would advocate that faced with several alternatives for a programming problem, one should simply code all solutions and determine with automated tests (discussed in the next section) what solution is most suitable.
Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem and finding it hard to explain the solution to fellow programmers might code it and use the code to demonstrate what he or she means. Code, say the exponents of this position, is always clear and concise and cannot be interpreted in more than one way. Other programmers can give feedback on this code by also coding their thoughts.
[编辑] 測試
沒有經過測試的程式碼什麼都不是。如果你沒有測試，客戶可能感覺不到，很多軟體在發佈的時候沒有經過完整的測試，它們還都在工作（或多或少的工作）。 在軟體開發程序中，極致編程認為，如果一個函數沒有經過測試就不能認為它可以工作。 This raises the question of defining what one can be uncertain about.
- You can be uncertain whether what you coded is what you meant. To test this uncertainty, XP uses Unit Tests. These are automated tests that test the code. The programmer will try to write as many tests he or she can think of that might break the code he or she is writing; if all tests run successfully then the coding is complete.
- You can be uncertain whether what you meant is what you should have meant. To test this uncertainty, XP uses acceptance tests based on the requirements given by the customer in the exploration phase of release planning.
[编辑] 傾聽
Programmers don't necessarily know anything about the business side of the system development. The function of the system is determined by the business side. For the programmers to find what the functionality of the system should be, they have to listen to business.
Programmers have to listen "in the large": they have to listen what the customer needs. Also, they have to try to understand the business problem, and to give the customer feedback about his or her problem, to improve the customer's own understanding of his or her problem.
Communication between the customer and programmer is further addressed in The Planning Game (see below).
[编辑] 設計
From the point of view of simplicity, one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, that will not work. One can come a far way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear.
One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system.
[编辑] 實踐
[编辑] 策劃遊戲
在極致編程中主要的策劃程序稱為策劃遊戲。 本節將通過程序模型介紹這個程序。
策劃程序分為兩部分：
- 發佈策劃: This is focused on determining what requirements are included in which release and when it’s going to be delivered. The customers and developers are both part of this. Release Planning consists of three phases:
- Exploration Phase: In this phase the customer will give all his requirements for the system. These will be written down on user story cards.
- Commitment Phase: Within the commitment phase business and development will commit themselves to the functionality that will be included and the date of the next release.
- Steering Phase: In the steering phase the plan can be adjusted, new requirements can be added and or existing requirements can be changed or removed.
- 反覆狀態: This plans the activities and tasks of the developers. In this process the customer is not involved. Iteration Planning also consists of three phases:
- Exploration Phase: Within this phase the requirement will be translated to different tasks. The tasks are recorded on task cards.
- Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated.
- Steering Phase: The tasks are performed and the end the result is matched with the original user story.
[编辑] Exploration phase – Release planning
This is an iterative process of gathering requirements and estimating the work impact of each of those requirements.
- Get Requirement from Customer: Business has come with a problem; during a meeting, development will try to define this problem and get requirements.
- Write a Story: Based on the business problem, a story has to be written. This is done by business, where they point out what they want a part of the system to do. It is important that development has no influence on this story for so far the functionality. The story is written on a so called user story card.
- Split a Story: If development isn't able to estimate the story (next item), it needs to be split up and written again. Again, this may not influence the business requirements.
- Estimate a Story: Development estimates how long it will take to implement the work implied by the story card.
When business cannot come up with any more requirements, one proceeds to the commitment phase.
[编辑] 送出狀態 – 發佈計劃
這一階段涉及成本、利潤和計劃影響這三個因素，包含四個部分：
- 按照價值排序：業務方按照商業價值為使用者故事排序。
- 按風險排序：開發方按風險為使用者故事排序。
- 設定周轉率：開發方決定以怎樣的速度開展專案。
- 選擇範圍：挑選在下一個發佈中需要被完成的使用者故事，基於使用者故事決定發佈日期。
[编辑] 價值排序
業務方按照商業價值為使用者故事排序。它們會被分為三類：
- 關鍵：沒有這些故事系統無法運作或變得毫無意義。
- 重要的商業價值：有重要業務價值的非關鍵使用者故事。
- 最好能有：並沒有重要商業價值的使用者故事；例如在可用性或使用者界面上的改進。
[编辑] 風險排序
程式設計師按照風險對使用者故事進行排序。他/她們將使用者故事的風險劃分成三類：低、中、高。以下是這種方式的一個範例：
- 決定風險索引：依照以下因素給每個使用者故事一個0到2的索引：
- 完全度（我們是否已經瞭解所有的故事細節？）
- 完全（0）
- 不完全（1）
- 未知（2）
- 發散性（可能會發生變化嗎？）
- 低（0）
- 中（1）
- 高（2）
- 複雜度（是否難以建構？）
- 簡單（0）
- 標準（1）
- 複雜（2）
- 完全度（我們是否已經瞭解所有的故事細節？）
為每個使用者故事增加所有這些索引後，給這些使用者故事指定一個風險索引：低（0–1），中（2–4），高（5–6）。
[编辑] 激勵狀態 – 發佈計劃
在作業階段開發人員和業務人員可以「操縱」整個程序。這意味著，他們可以做出改變。個體的使用者故事，或是不同使用者故事的相對優先等級，都有可能改變；預估時間也可能出現誤差。這是做出相應調整的機會。
[编辑] 探索階段- 反覆計劃
反覆計劃中的探索階段是關於建立任務和預估實施時間。
- 收集使用者故事：收集並編輯下一個發佈的所有使用者故事。
- 組合/分割任務：如果程式設計師因為任務太大或太小而不能預估任務完成時間，則需要組合或分割此任務。
- 預估任務：預測需要實作此任務的時間。
[编辑] 約定階段 - 反覆計劃
在反覆計劃的約定階段以不同使用者故事作為參考的任務被指派到程式設計師。
- 程式設計師接受任務：每個程式設計師都挑選一個他/她負責的任務。
- 程式設計師預估任務：由於程式設計師對此任務負責，他/她必須給出一個完成任務的估計時間。
- 設定負載係數：負載係數表示每個程式設計師在一個反覆中理想的開發時間。比如：一周工作40小時，其中5小時用於開會，則負載係數不會超過35小時。
- 平衡：當團隊中所有程式設計師都已經被配置了任務，便會在預估時間和負載係數間做出比較。任務配置在程式設計師中達到平衡。如果有一個程式設計師的開發任務過重，其它程式設計師必須接手他/她的一部分任務，反之亦然。
[编辑] 作業階段 - 反覆計劃
各個任務是在反覆計劃的作業階段中一步步實作的。
- 取得一張任務卡片：程式設計師取得一張由他/她負責的任務的卡片。
- 找尋一名同伴：這個程式設計師將和另一位程式設計師一同完成開發工作。這在實施結隊程式設計中會做更深入的探討。
- 設計這個任務：如果需要，兩位程式設計師會設計這個任務所達成的功能。
- 編輯單元測試：在程式設計師開始編輯實作功能的程式碼之前，他/她們首先編輯自動測試。這在實施單元測試中會做更深入的探討。
- 編輯程式碼：兩位程式設計師開始編輯程式碼。
- 執行測試：執行單元測試來確定程式碼能正常工作。
- 執行功能測試：執行功能測試（基於相關使用者故事和任務卡片中的需求）。
[编辑] 結對程式設計
結對程式設計的意思是所有的程式碼都是由兩個人坐在一台電腦前一起完成的。一個程式設計師控制電腦並且主要考慮編碼細節。另外一個人主要關注整體結構，不斷的對第一個程式設計師寫的程式碼進行評審。
結對不是固定的: 我們甚至建議程式設計師盡量交叉結對。這樣，每個人都可以知道其它人的工作，每個人都對整個系統熟悉，結對程式設計加強了團隊內的溝通。 (這與程式碼集體所有制是息息相關的).
[编辑] 集體所有制
集體所有制意味著每個人都對所有的程式碼負責；這一點，反過來又意味著每個人都可以更改程式碼的任意部分。結隊程式設計對這一實踐貢獻良多：借由在不同的結隊中工作，所有的程式設計師都能看到完全的程式碼。集體所有制的一個主要優勢是提升了開發程序的速度，因為一旦程式碼中出現錯誤，任何程式設計師都能修正它。
在給予每個開發人員修改程式碼的權限的情況下，可能存在程式設計師引入錯誤的風險，他/她們知道自己在做什麼，卻無法預見某些依賴關係。完善的單元測試可以解決這個問題：如果未被預見的依賴產生了錯誤，那麼當單元測試執行時，它必定會失敗。
[编辑] 現場客戶
在極致編程中，「客戶」並不是為系統付帳的人，而是真正使用該系統的人。極致編程認為客戶應該時刻在現場解決問題。例如：在團隊開發一個財務管理系統時，開發小組內應包含一位財務管理人員。
[编辑] 單元測試
單元測試是用以測試一小段程式碼的自動測試（例如：類，方法）。在極致編程中，在程式碼編輯前就編輯單元測試。這種方式的目的是激勵程式設計師設想他/她的程式碼在何種條件下會出錯。極致編程認為當程式設計師無法再想出更多能使他/她的程式碼出錯的情況時，這些程式碼便算完成。
[编辑] 重構
由於XP教條提倡編輯程式時只滿足目前的需求，並且以盡可能簡單的方式實作。有時會碰上一套僵硬的系統，所謂僵硬的系統，表現之一是需要雙重（或多重）維護：功能變化需要對多份同樣（或類似）的程式碼進行修改；另一種表現是對程式碼的一部分進行修改時會影響其它很多部分。XP教條認為當這種情況發生時，意味著系統正告訴你通過改變系統架構以重構程式碼，使它更簡單、更泛用。參見重構。
[编辑] 具爭議性的問題
Extreme Programming also has its share of controversial aspects:
- Detailed specifications are not created or preserved.
- Programmers are required to work in pairs - not all software developers expect to be asked to work this way.
- There is no Big Design Up Front. Most of the design activity takes place on the fly and incrementally, starting with "the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. This could result in more re-design effort than only re-designing when requirements change.
- A customer representative is attached to the project. This role can become a single-point-of-failure for the project and some people have found it to be a source of stress.
In 2003, Matt Stephens and Doug Rosenberg published a book under Beck's XP series imprint called "Extreme Programming Refactored: The Case Against XP" which questioned the value of the XP process and suggested ways in which it could be improved (i.e. refactored). This triggered a lengthly debate in articles, internet newsgroups and web-site chat areas. The core argument of the book is that XP's practices are interdependent but that few practical organisations are willing/able to adopt all the practices; therefore the entire process fails. The book also makes other criticisms and it draws a likeness of XP's "collective ownership" model to socialism (the authors appear to regard this as undesirable).
Certain aspects of XP have changed since the book was published, in particular XP now accomodates modifications to the practices as long as the required objectives are still met. It also uses increasingly generic terms for processes. Some argue that these changes invalidate previous criticisms; others claim that this is simply watering the process down.
Recently, authors have attempted to reconcile XP with the older methods that XP sought to replace (such as the waterfall method) in order to offer a unified method. See http://www.lux-seattle.com/resources/whitepapers/waterfall.htm for an example.
[编辑] 極致編程的特徵
極致編程方法的基本特徵是：
- 增量和反覆式的開發 - 一次小的改進跟著一個小的改進。
- 反覆性，通常是自動重複的單元測試，回歸測試。參見JUnit。
- 結對程式設計
- 在程式設計團隊中的使用者交互（在場的客戶）
- 軟體重構
- 共享的程式碼所有權
- 簡單
- 回饋
- 用隱喻來組織系統
- 可以忍受的速度
這些內容屬性來源於那些被認為是有效的原則，並把它們發揮到極致：
- 開發人員和客戶之間的交互是有益的. 因此,一個極致編程的小組從理論上要求需要一個軟體使用者在身邊,這個使用者制定軟體的工作需求和優先等級, 並且盡可能在各種問題出現的時候馬上就能回答.
- 如果學習是好的, 那麼就把它做到底: 這樣減少了開發和回饋週期的長度,測試也能更早完成.
- 簡單的程式碼更可能工作。所以極致編程的程式設計師在一個軟體專案中唯寫出能夠滿足目前實際需求的程式碼,這樣或多或少降低了程式碼的複雜性和重複性.
- 如果簡單的程式碼是好的, 那麼把變得複雜的程式碼改寫成簡單的.
- 程式碼評審是好的。因此,極致編程的程式設計師以兩人搭檔的方式工作. 他們共享一個螢幕和鍵盤,增加了隊員之間的交流,也讓程式碼在一被寫出的時候就被人評審了.
- 測試程式碼是好的。因此,在極致編程中,測試用例在實際程式碼之前就被寫出來了. 程式碼只有在通過測試的時候才被認為完成了. (當然,需要進一步分解來降低複雜性). 整個軟體系統用一種週期化的,實時的,被預先變好的自動化測試方式來保證它的確有作用.參看 測試驅動的開發.
一般來說，極致編程被認為對於少於12人的小團隊很有用。一些人認為極致編程可以用於大的團隊，但是其它人認為統一軟體程序更適合大的團隊。然而,極致編程在一些超過100人的開發小組中獲得成功. 並不是極致編程不能夠推廣到更大的團隊,而是很少有更大的團隊來試著用它. 極致編程的人員也拒絕去隨便推測這個問題.
[编辑] 爭論的觀點
極致編程也有其被爭論的一面：
- 沒有書面的詳細的規格說明書
- 客戶代表被安排在專案中
- 程式設計師以結對的方式工作
- 測試驅動的開發
絕大多數設計活動都匆匆而過，並漸進式的，開始一個「最簡單的可能工作的東西」並當其需要時（測試失敗）才增加複雜性。單元測試促成為了設計紀律。
[编辑] 極致編程中的溝通
建構軟體系統的一個基本任務是向系統的開發人員傳達系統的需求。在形式的軟體開發方法學中，溝通是通過文件完成的。
極致編程方法可以被看作為在開發團隊成員間快速建構和散佈統一的知識的一種方法。目的在於給所有開發人員一個共享的關於系統的看法，這個看法與使用者持有的看法相一致。為了這個目的，極致編程熱衷於簡單的設計，隱喻，使用者與程式設計師之間的合作，頻繁的口頭溝通和回饋。
參見:
- 阿里斯代·寇本的Crystal輕量級方法
[编辑] 參考資料
- 肯特·貝克：《極致編程解析：擁抱變化》， Addison-Wesley, ISBN 0201616416
- 阿里斯代爾·寇本：《敏捷軟體開發》，Addison-Wesley, ISBN 0201699699
- 雷劍文 陳振沖 李明樹：《超越傳統的軟體開發——極致編程的幻象與真實》, 電子工業出版社, ISBN 7-121-00657-X
[编辑] 外部連線
- 沃德·坎寧安的網站，極致編程，關於極致編程和相關主題的更多資訊。
- 面對客戶的極致編程介紹
- 羅恩·傑弗裡斯的網路雜誌XProgramming.com - 極致編程資源
- ExtremeProgramming.org
- 馬特斯蒂芬斯的批評網站，對極致編程的問題的深邃的批評 （參見該頁得到更多對極致編程的批評的連結）
- 馬丁·福勒論極致編程
- 搭檔編程，極致編程實踐
- 敏捷軟體開發的宣言
- 工具: "XPlanner"
- 工具: "XPWeb"
- 來自CiteSeer的引文
- 來自方法與工具雜誌的文章脫離極致編程的極致編程測試：利用敏捷測試實踐的優勢
- 來自方法與工具雜誌的文章 結對程式設計真能改進你的專案？
