Scrum及XP組合應(yīng)用策略研究

高玄凌

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

關(guān)鍵詞：Scrum 敏捷開發(fā) 極限編程

中圖分類號：TP311.5 文獻(xiàn)標(biāo)識碼：A 文章編號：1672-3791（2017）11（b）-0013-02

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

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

1 Scrum和XP的比較

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

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

因?yàn)閄P和Scrum的廣泛應(yīng)用，敏捷開發(fā)者們經(jīng)常會將兩者進(jìn)行比較，XP和Scrum主要有四個差別[4]。

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

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

（3）在迭代中，需求是否嚴(yán)格按照優(yōu)先級別來實(shí)現(xiàn)是不同的。XP是務(wù)必要遵守優(yōu)先級別的。但Scrum在這點(diǎn)做得很靈活，可以不按照優(yōu)先級別來做。

（4）Scrum關(guān)注項(xiàng)目的管理和組織實(shí)踐，而XP關(guān)注的是實(shí)際的編程實(shí)踐。Scrum和RUP一樣定義了一套角色、活動和工件，是一套過程框架；XP則規(guī)定了測試驅(qū)動的開發(fā)、結(jié)對編程、簡單設(shè)計、重構(gòu)等約束團(tuán)隊(duì)的十二項(xiàng)原則。

2 Scrum和XP的組合應(yīng)用策略

根據(jù)對一些軟件企業(yè)的敏捷實(shí)踐分析，在實(shí)際項(xiàng)目中，以Scrum應(yīng)用為基礎(chǔ)，并選擇性的結(jié)合XP的某些原則，能夠取得更好的實(shí)踐效果。

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

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

2.2 根據(jù)優(yōu)先級，集體確定每個周期迭代任務(wù)

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

2.3 制定統(tǒng)一的編碼規(guī)范

統(tǒng)一的規(guī)范有助于各成員理解其他成員的代碼，促進(jìn)代碼共享，降低集成的復(fù)雜度，提高代碼質(zhì)量。

2.4 堅(jiān)持測試驅(qū)動的開發(fā)，并持續(xù)集成

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

2.5 堅(jiān)持現(xiàn)場客戶的方式

團(tuán)隊(duì)對項(xiàng)目領(lǐng)域不熟悉或者存在業(yè)務(wù)重構(gòu)時，現(xiàn)場客戶的作用尤其重要。現(xiàn)場客戶能夠及時參與團(tuán)隊(duì)的每日立會以及其它相關(guān)會議，能第一時間明確沖刺訂單中的業(yè)務(wù)相關(guān)問題，及時給予解答。

3 結(jié)語

作為主流的敏捷開發(fā)方法，極限編程與Scrum都有著廣泛的應(yīng)用實(shí)踐。通過對兩者進(jìn)行組合應(yīng)用，能夠有效避免各自缺點(diǎn)，取得更好的實(shí)踐效果。

參考文獻(xiàn)

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

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

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

[4] （瑞）Henrik Kniberg，著.硝煙中的Scrum和XP—我們?nèi)绾螌?shí)施Scrum[M].李劍，譯.清華大學(xué)出版社，2011.endprint