Scrum及XP組合應用策略研究

高玄凌

摘 要：本文介紹了軟件開發過程中傳統的開發模式，由于傳統方式存在某些不足之處，敏捷開發的概念孕育而生，通過對比，具體分析了極限編程和Scrum兩種敏捷開發方法，提出了組合應用兩種方法的一些策略，描述了使用的方法和適用場景，盡可能地發揮兩者的長處，通過科學的項目管理，使整個軟件開發過程取得更好地實踐效果。

關鍵詞：Scrum 敏捷開發 極限編程

中圖分類號：TP311.5 文獻標識碼：A 文章編號：1672-3791（2017）11（b）-0013-02

軟件過程作為軟件工程的基本要素，是決定軟件質量好壞以及整個軟件項目成敗的關鍵因素。軟件開發使用的主要傳統模型是瀑布模型，瀑布模型流傳至今，影響深遠。瀑布模型根據軟件生命周期，將軟件過程主要分為問題定義、可行性研究、需求分析、設計、編碼、測試、運行和維護等階段，各階段要求有明確的結果、規范的文檔以及嚴格的評審，階段間有明確的界限，只有上一階段結束才可進入下一階段，是標準的順序模型。在需求明確的情況下，瀑布模型的特點能夠保證軟件的質量。隨著軟件行業的飛速發展，軟件應用的差異化、需求的不確定性以及系統的復雜性等因素導致瀑布模型無法滿足軟件發展的需要，開始出現原型法、迭代開發、增量開發的思想，快速原型法、增量模型、噴泉模型、螺旋模型等不同的軟件過程模型也隨之誕生。發展到今天，RUP、微軟過程以及敏捷開發已經成為了主流，而快捷易用的敏捷開發方法更是成為了多數中小型項目的首選。

敏捷開發是以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發[1]。2001年2月，17名知名的軟件工程專家聚集在美國的猶他州雪鳥滑雪勝地，這些不同敏捷方法的支持者經過兩天的討論，共同起草了一份《敏捷軟件開發宣言》，強調了敏捷軟件開發的四個核心價值觀：“個體和互動高于流程和工具，工作的軟件高于詳盡的文檔，客戶合作高于合同談判，響應變化高于遵循計劃”[2]。這份宣言正式明確了“敏捷”這一術語，同時強調宣言中左項要高于右項。敏捷開發方法的代表包含了極限編程、Scrum、DSDM、自適應軟件開發、水晶系列、特征驅動開發等，其中極限編程與Scrum是主流的敏捷開發方法。

1 Scrum和XP的比較

極限編程（ExtremeProgramming，簡稱XP）由Kent Beck在1996年提出的，是一個輕量級的、靈巧的軟件開發方法。極限編程遵循五個重要的價值觀：“溝通、簡單、反饋、勇氣、尊重”，同時提出了十二項原則：“計劃游戲、小型發布、簡單設計、測試驅動開發、持續集成、重構、結對編程、代碼集體所有、現場客戶、系統隱喻、編碼標準”[2]。Kent Beck認為XP不但可以適應中小規模的團隊開發需求模糊或者快速變化的項目的需要，而且對任何規模的團隊都起作用[3]。

Scrum源于橄欖球術語，由Jeff Sutherland和Ken Schwaber提出，是一種迭代式增量軟件開發過程，通常用于敏捷軟件開發。Scrum定義了一系列實踐和預定義角色的過程框架，如角色有產品負責人、Scrum主管、開發團隊等，工件包括產品訂單（Sprint Backlog）、沖刺訂單、燃盡圖等，活動包括計劃會、每日立會、評審會、反思會等。

因為XP和Scrum的廣泛應用，敏捷開發者們經常會將兩者進行比較，XP和Scrum主要有四個差別[4]。

（1）Scrum的迭代長度通常要比XP長。前者的一個Sprint的周期一般為2～6周，后者的一個迭代長度則大致為1～2周。

（2）Scrum在一個Sprint的周期內不允許修改需求（產品訂單），而XP在一個迭代中允許使用其它的用戶故事（User Story）替換尚未實現的，前提是實現的時間是相等的。

（3）在迭代中，需求是否嚴格按照優先級別來實現是不同的。XP是務必要遵守優先級別的。但Scrum在這點做得很靈活，可以不按照優先級別來做。

（4）Scrum關注項目的管理和組織實踐，而XP關注的是實際的編程實踐。Scrum和RUP一樣定義了一套角色、活動和工件，是一套過程框架；XP則規定了測試驅動的開發、結對編程、簡單設計、重構等約束團隊的十二項原則。

2 Scrum和XP的組合應用策略

根據對一些軟件企業的敏捷實踐分析，在實際項目中，以Scrum應用為基礎，并選擇性的結合XP的某些原則，能夠取得更好的實踐效果。

2.1 保持迭代周期在2～3周

Scrum的一個Sprint的周期一般為2～6周，XP的一個迭代長度則大致為1～2周。敏捷開發的基本思想就是迭代和循序漸進，為保證能盡快提供小型發布版本，顯然迭代周期越短越好。但是周期越短，一個周期能夠完成的迭代任務就會過小，不僅導致分割訂單的成本增加，而且持續集成的壓力也更高，因此綜合兩者，將Sprint的迭代周期限制在2～3周比較好，根據項目特性確定具體的周期。

2.2 根據優先級，集體確定每個周期迭代任務

在每個Sprint開始時，需要召開計劃會議來確定沖刺訂單（Sprint Backlog）。在一個穩定而又熟練的團隊中，產品負責人能夠清楚地分析每個Backlog和每一個成員的能力，能夠輕易確定一個沖刺訂單。實踐中，團隊成員可能經常會流動，業務的領域復雜性也會產生干擾，導致產品負責人無法準確進行判斷?？梢圆扇〉囊粋€有效方法，是由產品負責人根據產品訂單的優先級團隊中的每個成員獨立地對產品負責人提出的沖刺訂單進行成產率評估，然后綜合大家的評估，從而確定沖刺任務。當然，成員間估算差異較大時，應該分別闡述理由，以做出更加合理的決策。

2.3 制定統一的編碼規范

統一的規范有助于各成員理解其他成員的代碼，促進代碼共享，降低集成的復雜度，提高代碼質量。

2.4 堅持測試驅動的開發，并持續集成

測試驅動的開發方式本身具有很多好處，即時的白盒或黑盒測試能夠及時發現代碼中的bug，從而及時進行修改或者重構以改善代碼質量，并保證不影響沖刺周期。當然，測試驅動需要手工測試和自動測試并行，代碼首先在本機進行單元測試或集成測試后才能提交到服務器上，通過對測試服務器進行腳本配置以自動進行集成測試。相當多的企業會堅持每日持續集成，使程序中的缺陷當天得到解決。

2.5 堅持現場客戶的方式

團隊對項目領域不熟悉或者存在業務重構時，現場客戶的作用尤其重要?，F場客戶能夠及時參與團隊的每日立會以及其它相關會議，能第一時間明確沖刺訂單中的業務相關問題，及時給予解答。

3 結語

作為主流的敏捷開發方法，極限編程與Scrum都有著廣泛的應用實踐。通過對兩者進行組合應用，能夠有效避免各自缺點，取得更好的實踐效果。

參考文獻

[1] 王桐.數據分析方法論的革命—再不掌握敏捷思維你就out了[J].中國計算機報，2015（15）：39.

[2] 王素芬.軟件工程與項目管理[M].西安電子科技大學出版社，2010.

[3] （美）Kent Beck， Cynthia Andres，著.解析極限編程—擁抱變化[M].雷劍文，譯機械工業出版社，2011.

[4] （瑞）Henrik Kniberg，著.硝煙中的Scrum和XP—我們如何實施Scrum[M].李劍，譯.清華大學出版社，2011.endprint