【導(dǎo)讀】了大批軟件人員的關(guān)注。但許多人并不真正了解它。本文提供了XP的概述，闡述了XP的

　　

【正文】 要求項目團(tuán)隊人員每周工作時間不能超過 40 小時，加班不得連續(xù)超過兩周，否則反而會影響生產(chǎn)率。 該實(shí)踐充分體現(xiàn)了 XP 的 以人為本 的原則。但是，如果要真正的實(shí)施下去，對于項目進(jìn)度和工作量合理安排的要求就比較高。 17 項目：由于項目的工期比較充裕，因此，很幸運(yùn)的是我們并沒有違反該實(shí)踐。 規(guī)劃策略 ( Planning Game ) XP 要求結(jié)合項目進(jìn)展和技術(shù)情況，確定下一階段要開發(fā)與發(fā)布的系統(tǒng)范圍。 項目計劃在建立起來 后，需要根據(jù)項目的進(jìn)展來進(jìn)行調(diào)整，一成不變的計劃是不存在 的 。因此，項目團(tuán)隊需要 控制風(fēng)險、預(yù)見變化，從而制定有效、可行的項目計劃。 項目：在系統(tǒng)實(shí)現(xiàn)前，我們首先按照需求的優(yōu)先級做了迭代周期的劃分，將高風(fēng)險的需求優(yōu)先實(shí)現(xiàn)；同時，項目團(tuán)隊每天早晨參加一個 15 分鐘的項目會議，確定當(dāng)天以及目前迭代周期中每個成員要完成的任務(wù)。 結(jié)對編程 ( Pair Programming ) XP 認(rèn)為在項目中采用結(jié)對編程比獨(dú)自編程更加有效。其實(shí)，結(jié)對編程是一種非正式的同級評審 ( Peer Review )。它要求結(jié)對編程的兩個開發(fā)人員在性格和技能上應(yīng)該相互匹配，目前在國內(nèi)還不是十分適合推廣。結(jié)對 編程只是加強(qiáng)開發(fā)人員溝通與評審的一種方式，而非唯一的方式。具體的方式可以結(jié)合項目的情況進(jìn)行。 項目：我們在項目中并未采用結(jié)對編程，而是在項目實(shí)施的各個階段，加強(qiáng)了走查以及同級評審的力度。需求獲取、設(shè)計與分析都有多人參與，在成果提交后，交叉進(jìn)行走查；而在編碼階段，開發(fā)人員之間也要在每個迭代周期后進(jìn)行同時評審。 小型發(fā)布 ( Small Release ) XP 強(qiáng)調(diào)在非常短的周期內(nèi)以遞增的方式發(fā)布新版本 ，從而可以很容易地估計每個迭代周期的進(jìn)度，便于控制工作量和風(fēng)險。 同時，也可以及時處理用戶的反饋。小型 發(fā)布突出體現(xiàn)了敏捷方法的優(yōu)點(diǎn)。 項目：在籌備階段就配置了一臺測試與發(fā)布服務(wù)器，在項目實(shí)施過程中，平均每兩周（一個迭代周期結(jié)束后）進(jìn)行一個小型發(fā)布；用戶在發(fā)布后兩個工作日內(nèi)，向項目小組提交 用戶接收測試報告 ，由項目經(jīng)理評估測試報告，將有效的 BUG 提交至 Rational Clear Case，并分配給相應(yīng)的開發(fā)人員。項目小組應(yīng)該在下一個迭代周期結(jié)束前修復(fù)所有用戶提交的問題。 系統(tǒng)隱喻 ( System Metaphor ) XP 通過隱喻來描述系統(tǒng)如何運(yùn)作、新的功能以何種方式加入到系統(tǒng)。 在系統(tǒng)實(shí)現(xiàn)初期 ，不需要進(jìn)行詳細(xì)的架構(gòu)設(shè)計，而是在迭代周期中不斷的細(xì)化架構(gòu)。對于小型的系統(tǒng)或者架構(gòu)設(shè)計的分析會推遲整個項目的計劃的情況下，逐步細(xì)化系統(tǒng)架構(gòu)倒是 可以的。 但是，對于大型系統(tǒng)或者是希望采用新架構(gòu)的系統(tǒng)，就需要在項目初期進(jìn)行相信的系統(tǒng)架構(gòu)設(shè)計，并在第一個迭代周期中進(jìn)行驗證，同時在后續(xù)迭代周期中逐步進(jìn)行細(xì)化。 項目：開發(fā)團(tuán)隊在設(shè)計初期，決定參照 STRUTS 框架，結(jié)合項目的情況，構(gòu)建了針對工作流程處理的項目框架。首先，團(tuán)隊決定在第一個迭代周 期實(shí)現(xiàn)配件申請的工作流程，在實(shí)際項目開發(fā)中驗證了基本的程序框架。 而后，又在其它迭 代周期中，對框架逐漸精化。 簡單設(shè)計 ( Simple Design ) XP 認(rèn)為需求是 會經(jīng)常變化的，因此設(shè)計不能一蹴而就，而應(yīng)該是一項持續(xù)進(jìn)行的過程。對于國內(nèi)大部分的軟件開發(fā)組織來說，應(yīng)該首先確定一個靈活的系統(tǒng)架構(gòu)，而后在每個迭代周期的設(shè)計階段可以采用 XP 的簡單設(shè)計原則，將設(shè)計進(jìn)行到底。 項目：在項目的系統(tǒng)架構(gòu)經(jīng) 驗證后的迭代周期內(nèi)，我們始終堅持簡單設(shè)計的原則，并按照 Kent Beck 的四項原則進(jìn)行有效的驗證 。對于新的迭代周期中出現(xiàn)需要修改既有設(shè)計與代碼的情況 下 ，首先對原 系統(tǒng)進(jìn)行 代碼重構(gòu) ，而后 增加新 功能。 代碼重構(gòu) ( Refactoring ) 重構(gòu)不是 XP 所特有的行為，在任何的開發(fā)過程中都可能并且應(yīng)該發(fā)生。在使用代碼重 18 構(gòu)的時候要注意，不要過分的依賴重構(gòu)，甚至輕視設(shè)計，否則，對于大中型的系統(tǒng)而言，將設(shè)計推遲或者干脆不作設(shè)計，會造成一場災(zāi)難。 項目： 我們在項目中將 JREFACTORY 工具部署到 JBuilder 中進(jìn)行代碼的重構(gòu)，重構(gòu)的時間是在各個迭代周期的前后。代碼重構(gòu)在項目中的作用是改善既有設(shè)計，而不是代替設(shè)計。 1持續(xù)集成 ( Continuous Integration ) XP 提倡在一天中集成系統(tǒng)多次，而且隨著需求的改變，要不斷的進(jìn)行回歸測試。因為，這樣可以使得團(tuán)隊保持一個較高的開發(fā)速度，同時避免了一次系統(tǒng)集成的惡夢。持續(xù)集成也不是 XP 專有的最佳實(shí)踐，著名的微軟公司就有每日集成 ( Daily Build ) 的成功實(shí)踐。但是，要注意的是，持續(xù)集成也需要良好的軟件配置變更管理系統(tǒng)的有效支持。 項目：使用 VSS 作為軟件配置管理系統(tǒng)，堅持每天進(jìn)行一次系統(tǒng)集成，將已完成的功 能有效地結(jié)合起來，進(jìn)行測試。 1 集體代碼所有權(quán) (Collective Ownership) XP 認(rèn)為開發(fā)小組的每個成員都有更改代碼的權(quán)利，所有的人對于全部代碼負(fù)責(zé)。 代碼全體擁有并不意味著 開發(fā)人員可以互相推委責(zé)任，而是強(qiáng)調(diào)所有的人都要負(fù)責(zé)。如果一個開發(fā)人員的代碼有錯誤，另外一個開發(fā)人員也可以進(jìn)行 BUG 的修復(fù)。在目前，國內(nèi)的軟件開發(fā)組織，可以在一定程度上實(shí)施該實(shí)踐，但是同時需要注意一定要有嚴(yán)格的代碼控制管理。 項目：我們在項目開發(fā)初期，首先向開發(fā)團(tuán)隊進(jìn)行 代碼全體擁有 的教育，同時要求開發(fā)人員不僅要了解系統(tǒng)的架構(gòu)、自己的代碼，同時也要了解其它開發(fā)人員的工作以及代碼情況。這個實(shí)踐與同級評審有一定的互補(bǔ)作 用，從而保證人員的變動不會對項目的進(jìn)度造成很大的影響。在項目執(zhí)行中，有一個開發(fā)人員由于參加培訓(xùn)，缺席項目執(zhí)行一周，由于實(shí)行了 代碼全體擁有 的實(shí)踐，其它的開發(fā)人員成功地分擔(dān)了該成員的測試與開發(fā)任務(wù)，從而保證項目的如期交付。 以上是 XP 的最佳實(shí)踐在項目中的應(yīng)用情況，讓我們查看以下該項目的詳細(xì)統(tǒng)計數(shù)據(jù)： 條 目 描 述 ============================ 項目開始時間 2020/4/25 項目預(yù)期結(jié)束時間 2020/6/28 項目實(shí)際結(jié)束日期 2020/7/2 項目預(yù) 計成本 199080 項目實(shí)際成本 177340 CPI SPI ============================ 其中，項目執(zhí)行過程中提交了一個 用戶需求變更 ，該變更對于項目周期的影響為 6個工作日。項目實(shí)施后，在用戶接收測試中，只提交了 2 個 BUG，而且在提交當(dāng)天就得到了解決。目前，項目運(yùn)行平穩(wěn)，并得到了用戶的好評。因此，我們認(rèn)為， XP 在該項目中的實(shí)施有效地保證了項目質(zhì)量和項目周期。 結(jié)論 通過 此次 畢業(yè) 論文 ， 介紹了軟件工程的新技術(shù) —— XP，其中對極限編程（ XP）做了較全面地講解，包括 XP 的概念、核心價值、特點(diǎn)、規(guī)則，使用環(huán)境、過程等。對 XP 中提出的規(guī)則等有了較深入地了解，深刻體會到 XP 給軟件工程的發(fā)展及項目的開發(fā)、使用帶來的變化。 XP 19 是一個非常龐大的知識庫，每一項都是一門值得深 入研 究的學(xué)問 。 XP 是與眾不同的，它有點(diǎn)象快步的舞蹈。 XP 開發(fā)過程包括許多的小卡片，獨(dú)立的看，這些小卡片沒有什么意義，但是當(dāng)它們組合在一起，一幅完整的美麗的圖片就可以看見， XP 方法有別于傳統(tǒng)軟件開發(fā)，它是軟件開發(fā)的一 種新的重要的發(fā)展。它改變了我們開發(fā)程序的傳統(tǒng)思維方式。 由于作者 所學(xué)知識地 有限， 對 XP 的介紹和理解 方面 還不夠深刻，有 待進(jìn)一步的 提高 和完善，同時 這 也將 成為 作者今后在工作中的研究任務(wù)。 參考文獻(xiàn) [1]Kent Beck，《解析極限編程 —— 擁抱變化》，人民郵電出版社， 2020 [2]Kent Beck，《規(guī)劃極限編程》，人民郵電出版社， 2020 [3]Kent Beck，《極限編程實(shí)施》，人民郵電出版社， 2020 [4]解說極端編程 (eXtreme Programming eXplained)， Kent Beck, Addision Wesley, 2020. [5]Kent Beck《終極編程釋義 :擁抱變化》 (Extreme Programming Explained: Embrace Change) [6]尼米龍 —— 《 Ant 極限編程》清華大學(xué)出版社 2020 年 [7]網(wǎng)站： Extreme Programming Online， 附錄 XP 中一些基本概念 : 1. User Story：開發(fā)人員要求客戶把所有的需求寫成一個個獨(dú)立的小故事，每個只需要幾天時間就可以完成。開發(fā)過程中，客戶可以隨時提出新的 User Story，或者更改以前的User Story。 2. Story Estimates 和開發(fā)速度：開發(fā)小組對每個 User Story 進(jìn)行估算，并根據(jù)每個開發(fā)周期（ Iteration）中的實(shí)際情況反復(fù)計算開發(fā)速度。這樣，開發(fā)人員和客戶能知道每個星期到底能開發(fā)多少 User Story。 3. Release Plan 和 Release Scope：整個開發(fā)過 程中，開發(fā)人員將不斷地發(fā)布新版本。開發(fā)人員和客戶一起確定每個發(fā)布所包含的 User Story。 4. Iteration（開發(fā)周期）和 Iteration Plan：在一個 Release 過程中，開發(fā)人員要求客戶選擇最有價值的 User Story 作為未來一兩個星期的開發(fā)內(nèi)容。 5. The Seed：第一個開發(fā)周期（ Iteration）完成后，提交給客戶的系統(tǒng)。雖然這不是最終的產(chǎn)品，但它已經(jīng)實(shí)現(xiàn)了幾個客戶認(rèn)為是最重要的 Story，開發(fā)人員將逐步在其基礎(chǔ)上增加新的模塊。 6. Continuous Integration（整 合）：把開發(fā)完的 User Story 的模塊一個個拼裝起來，一步步接近乃至最終完成最終產(chǎn)品。 7. 驗收測試（功能測試）：對于每個 User Story，客戶將定義一些測試案例，開發(fā)人員將使運(yùn)行這些測試案例的過程自動化。 8. Unit Test（單元測試）：在開始寫程序前，程序員針對大部分類的方法，先寫出相應(yīng)的測 20 試程序。 9. Refactoring (重 構(gòu) 和優(yōu)化 ) ：去掉代碼中的冗余部分，增加代碼的可重用性和伸縮性 10. 發(fā)布 (Release)：每一期開發(fā)結(jié)束時提交給用戶的一個可運(yùn)行的系統(tǒng)。 11. 迭代 (Iteration)：一期 開發(fā)過程中 的一個開發(fā)周期。它有明確的目標(biāo)，計劃和實(shí)現(xiàn)方式，它包含了需求分析、設(shè)計、編程、測試等完整的開發(fā)過程。一個迭代的長度為 1 到 3 周。一期開發(fā)過程中，所有迭代的長度相同，如 3 周。 12. 小發(fā)布 (Small Release)：處于開發(fā)中的系統(tǒng)，每集成一個新功能，都可以稱為一個小發(fā)布。 13. 理想開發(fā)時間：估計完成一項工作所需的持續(xù)工作時間，不考慮意外因素。 14. SPIKE：對不確定的需求和設(shè)計等，通過寫一些程序、進(jìn)行詳細(xì)設(shè)計或者演算等等方式做探測和嘗試，以確定可行性。這些探測過程稱為 SPIKE。 15. 故事卡：用戶把 User Story 的內(nèi)容和屬性寫在一張卡片上，該卡片即故事卡。 1 Engineering Task： Team 一起分析設(shè)計一個 UserStory，把該 Story 要完成的事情分解，就形成了一些任務(wù) (Engineering Tasks)。這些任務(wù)要足夠小，以至于每個程序員都非常清楚要做什么，并能估計出完成該任務(wù)所需要的理 想開發(fā)天數(shù) . New technology of the soft project —— —— XP [Abstract] Extreme Programming (XP) is a kind of lightweight soft project method to put forward recently, its has attracted the concern of large quantities of software personnel soon because of it’s highefficient and practical. But many people not certainly understand it. This article has provided the XP outline, elaborated the XP value, the characteristic, the practice method, the suitable environment and so on, explained why it is so important, and has demonstrated it through a concrete project in the project application. [Keywords] Extreme Programming(XP)、 Pair Programming、 Refactoring