論極限編程中的溝通

高 云

[摘要]極限編程的核心價值中的溝通對于軟件項目管理有著極其重要的意義。論述極限編程中的溝通方式，并探討作用。

[關鍵詞]極限編程軟件工程溝通

中圖分類號：TP3文獻標識碼：A文章編號：187t－7597(2009)1020064－01

一、極限編程

隨著軟件行業的飛速發展，原有的軟件開發方法已不能完全適應種類繁多的軟件項目。這些軟件開發方法需要繁雜的開發文檔，過于嚴格的項目流程，而這對于規模較小的項目來說卻成為沉重的負擔。規模較小的項目本身開發工作量并不多，這使項目開發人員不愿意多花精力來建立文檔和對項目進行管理。項目進行過程中，難以預計的需求變化對規模較小的項目更是常事，開發人員不得不多次調整項目需求以及已完成的項目內容，這使項目的。開發人員常常有做事目標不明確，事倍功半之感覺。這對于項目的開發進程起了負面影響作用。

為了解決以上的項目管理問題，一批業界專家在2001年創立了敏捷聯盟，并提出了一些可以讓項目團隊具有快速工作、響應變化能力的價值觀和原則。敏捷開發過程的方法有很多種，其中最重要的是極限編程(Extreme Programming，簡稱XP)[1]。

(一)極限編程的概念

極限編程(Extreme Programming，xp)適用于輕量級開發。它以客戶的需求作為項目的最終目標，并保證項目團隊中的所有活動均以此為基礎。

極限編程強調把需求細化，劃分為若干需求故事，這些需求故事的內容簡單明了，工作量較少，開發周期短，開發人員可以明確給出完成所需的時間。在完成這些需求故事的同時，測試代碼也相應完成，并用來對相應的需求故事進行測試，從而盡快發現問題。

極限編程的時間進程為一個個迭代周期。每個迭代周期中，客戶會提出一批需求故事，開發人員接受這些需求故事并估算花費時間，編寫其測試和代碼，將代碼通過測試，重構系統，記錄結果并完成版本控制。完成這些任務模塊并進行測試和集成，這樣盡快生成相應的項目版本以便客戶使用，幫助客戶更好地完成項目。

極限編程強調項目團隊中所有人員之間的合作，關注彼此之間的溝通交流和反饋。項目的進展在持續的溝通中向著最終目標穩步前進。

(二)極限編程的十二種方法

1、規劃策略；2、結對編程；3、測試：4、重構；5、簡單設計；6、代碼集體所有權；7、持續集成；8、現場客戶；9、小型發布；10、每周40小時工作制；11、編碼規范；12、系統隱喻。

(三)極限編程的核心價值

極限編程中有四個核心價值，即溝通、簡單、反饋和勇氣[2]。

極限編程在項目中體現了以人為本的精神，極力地幫助項目各方互相理解，通過種種方法激發人的潛力，幫助所有人減輕思想負擔，高度關注項目本身的實現。

二、極限編程中的溝通

極限編程項目首先擁有一個小規模但擁有各種不同職能的成員的項目團隊，以項目完成為項目團隊的共同目標。作為極限編程的核心價值，第一個就是溝通，這說明溝通成功與否直接決定項目的順利完成。

(一)開發場所

為了保證項目團隊充分掌握需求，保證所有人員對項目需求有充分的理解，開發場所必須是一個開放的場所，項目的所有參與者一起在這里工作，他們屬于同一個團趴。開發場所的墻壁上應張貼著與項目有關的圖表以及相關的文字內容，幫助團隊成員了解項目進度。每個成員可以根據項目進度制定工作計劃，并一起探討所遭遇問題的解決方案。所有與項目有關的意見和變化都在這個場所以第一時間傳達給所有參與者，所有人的交流都是面對面的。開發場所中應該必備用于交流的工具，如紙張、卡片和白板等等。

(二)現場客戶

項目的順利完成離不開客戶的合作，只有開發出滿足客戶需求的軟件，項目才是成功的。項目的需求其實只有客戶自己真正了解，因此項目團隊中應包含一名可以經常在開發場所與項目團隊一起工作的客戶。現場客戶提出需求故事，并將故事劃分出優先級，然后根據開發人員給出故事的費用從而做出決策。

現場客戶必須精通項目的業務流程，具有豐富的業務經驗。同時，他還必須具有項目的決策權限，能夠對項目的需求決定取舍。往往與項目有關的客戶人數不止一人，他們對項目的需求應匯總到現場客戶這里，經整理后再提交給開發團隊，使項目的需求不至于出現矛盾之處。

現場客戶對軟件開發的了解水平有高有低，有的現場客戶對技術不夠了解，或是不善于描述需求故事，從而屢屢修改需求故事而沒有考慮帶來的影響。對于這樣的現場客戶，可與其交流項目的架構和開發技術，告知其需求修改可能產生的損失，并通過需求故事的調整和工作流程的再造來解決問題。有的客戶希望掌控項目的技術細節，這可能會對開發人員的技術決策帶來一定的影響。對于這樣的客戶，開發團隊應滿足其，解的愿望，在制定需求故事時應全面考慮其意見。讓客戶在每日例會中充分了解項目的進展和問題。強烈的參與意識將樹立客戶對項目的信心，在項目出現問題時也會積極需求解決方案，這對項目的順利進展起到不可忽視的推動作用。

現場客戶不僅要和開發人員一起制定需求故事，還需要保證每個需求故事都有驗收測試用例進行驗證。極限編程中的測試包括單元測試和驗收測試。現場客戶所負責的是驗收測試。現場客戶可以自己編寫測試用例，也可以由現場客戶所在單位的人員來編寫測試用例。當然，現場客戶也可以直接讓項目團隊的開發人員來編寫驗收測試用例。驗收測試的結果直接為現場客戶提供項目決策依據。

(三)需求故事卡片

舊有的軟件項目中用大量的文檔來記錄項目需求及進展，保證項目順利進行。有必要編寫好和維護好項目文檔，但時間的要求和需求的變化使其變得難以保證。開發人員需要在完成編碼任務的同時完成文檔的編寫和維護，而規模不大的項目中的編碼工作量不大，開發人員不愿意去花費過多的時間在文檔上面。

所謂需求故事是指項目的基本需要所分解成的小的、重耍的用戶故事。它由客戶提出，并被開發人員所接受，作為開發和測試的依據。客戶將一個個需求故事寫在一張張卡片上，內容包括需求故事的名稱和需求故事的業務邏輯，然后將其按優先級排列，交給開發人員去處理。當需求發生變化時，客戶只需要重新制作需求故事卡片，并被開發人員認可就可以了。現有的需求故事卡片內容就是當前的項目需求，相比項目文檔的維護而言。這樣的工作量減少很多。

(四)每日例會

項目進行離不開會議交流，開發人員在會議中匯報自己的工作并提出需要解決的問題，但會議往往會間隔一段時間后召開，間隔時間或長或短，開發人員不能及時溝通，如果采取個別交流的方式則無法讓全體開發人員了解。

開發人員應該在完成自己任務的同時，了解其他開發人員所做的工作，并學習其他開發人員所使用的技術方法，以及幫助其他開發人員解決

工作中的難題，從而提高開發效率。每日例會滿足了這樣的需求。

每日例會的時間較短，所有開發人員報告昨天的工作成就、獲得的成果和今天的工作計劃，提出自己面對的困難。不能在例會上解決的問題將放到會后進行個別討論。每日例會避免了開發人員各自為營、相互脫節的局面。在會上，所有的開發人員必須暢所欲言，誠實地匯報自己的工作現狀，同時不避諱自身的缺陷，將工作中的難題公開并向項目團隊尋求盡快解決的方法，達到真正的有效溝通。實際上，遇到難題時，開發人員最好應該立即尋求幫助，既然整個項目團隊在一個開放的工作環境中工作，那么所有人都會立即了解他的問題并援助，大大節約了開發的時間。

(五)結對編程

以往的項目通常會把分解的各模塊任務下發給單個開發人員完成，這樣會出現以下問題：每個開發人員的技術水平不同，對項目的理解也會存在不同，這會導致開發模塊與需求的差異，盡管經過修改可以達到目標，但走了彎路，花費了時間和精力。如果遇到難題而沒有他人的幫助，單個開發人員往往會花費更多的時間來解決。個人開發有可能會受自身的種種因素影響，如精力不夠集中、時間安排不合理等等，使得開發計劃受到影響。

結對編程使得參與編程的開發人員必須共同熟悉所開發的內容，對所涉及的需求達成共識，共同完成設計決策。結對編程的工作方式使得開發人員更全面地了解項目需求，更快地達到目的，同時提高了個人的工作效率，加快了項目開發速度。同時，經過結對編程人員之間的審查后的代碼相比單獨編程的代碼而言，具有較高的規范性和準確程度。

因為項目團隊中的編程人員的結對極有可能發生變化，原有結對編程人員將共同完成的需求的理解以及技術方法傳播給項目團隊中的其他人員，促使更多的開發人員了解項目需求，有利于開發人員之間的溝通。

(六)編碼標準

基于極限開發的共同擁有代碼和結對編程的方法，項目的代碼為項目團隊中所有成員所擁有并可以進行修改。因此，項目按照規范的編碼標準來開發，提高了代碼的質量，可以方便所有開發人員理解和修改項目代碼，這對于開發人員之間的溝通也是極為有利的。

三、結束語

有效溝通是影響軟件項目質量乃至成敗的關鍵因素之一。極限編程方法中的所強調的溝通對項目管理具有積極的意義。無論是否采用極限編程方法-我們在軟件項目中都應高度關注項目相關人員之間的有效溝通，在滿足客戶的需求之上提高軟件質量，減少時間和消耗。