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

1、    scrum及xp組合應(yīng)用策略研究    高玄凌摘 要：本文介紹了軟件開發(fā)過程中傳統(tǒng)的開發(fā)模式，由于傳統(tǒng)方式存在某些不足之處，敏捷開發(fā)的概念孕育而生，通過對比，具體分析了極限編程和scrum兩種敏捷開發(fā)方法，提出了組合應(yīng)用兩種方法的一些策略，描述了使用的方法和適用場景，盡可能地發(fā)揮兩者的長處，通過科學(xué)的項目管理，使整個軟件開發(fā)過程取得更好地實踐效果。關(guān)鍵詞：scrum 敏捷開發(fā) 極限編程：tp311.5 ：a ：1672-3791（2017）11（b）-0013-02軟件過程作為軟件工程的基本要素，是決定軟件質(zhì)量好壞以及整個軟件項目成敗的關(guān)鍵因素。

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

3、、微軟過程以及敏捷開發(fā)已經(jīng)成為了主流，而快捷易用的敏捷開發(fā)方法更是成為了多數(shù)中小型項目的首選。敏捷開發(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)宣言中左項要高于右項。敏捷開發(fā)方法的代表包含了極限編程、scrum、dsdm、自適應(yīng)軟件開發(fā)、水晶系列、特

4、征驅(qū)動開發(fā)等，其中極限編程與scrum是主流的敏捷開發(fā)方法。1 scrum和xp的比較極限編程（extremeprogramming，簡稱xp）由kent beck在1996年提出的，是一個輕量級的、靈巧的軟件開發(fā)方法。極限編程遵循五個重要的價值觀：“溝通、簡單、反饋、勇氣、尊重”，同時提出了十二項原則：“計劃游戲、小型發(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)隊開發(fā)需求模糊或者快速變化的項目的需要，而且對任何規(guī)模的團(tuán)隊都起作用3。scrum源于橄欖球術(shù)語，由jeff sutherl

5、and和ken schwaber提出，是一種迭代式增量軟件開發(fā)過程，通常用于敏捷軟件開發(fā)。scrum定義了一系列實踐和預(yù)定義角色的過程框架，如角色有產(chǎn)品負(fù)責(zé)人、scrum主管、開發(fā)團(tuán)隊等，工件包括產(chǎn)品訂單（sprint backlog）、沖刺訂單、燃盡圖等，活動包括計劃會、每日立會、評審會、反思會等。因為xp和scrum的廣泛應(yīng)用，敏捷開發(fā)者們經(jīng)常會將兩者進(jìn)行比較，xp和scrum主要有四個差別4。（1）scrum的迭代長度通常要比xp長。前者的一個sprint的周期一般為26周，后者的一個迭代長度則大致為12周。（2）scrum在一個sprint的周期內(nèi)不允許修改需求（產(chǎn)品訂單），而xp在一

6、個迭代中允許使用其它的用戶故事（user story）替換尚未實現(xiàn)的，前提是實現(xiàn)的時間是相等的。（3）在迭代中，需求是否嚴(yán)格按照優(yōu)先級別來實現(xiàn)是不同的。xp是務(wù)必要遵守優(yōu)先級別的。但scrum在這點做得很靈活，可以不按照優(yōu)先級別來做。（4）scrum關(guān)注項目的管理和組織實踐，而xp關(guān)注的是實際的編程實踐。scrum和rup一樣定義了一套角色、活動和工件，是一套過程框架；xp則規(guī)定了測試驅(qū)動的開發(fā)、結(jié)對編程、簡單設(shè)計、重構(gòu)等約束團(tuán)隊的十二項原則。2 scrum和xp的組合應(yīng)用策略根據(jù)對一些軟件企業(yè)的敏捷實踐分析，在實際項目中，以scrum應(yīng)用為基礎(chǔ)，并選擇性的結(jié)合xp的某些原則，能夠取得更好的實

7、踐效果。2.1 保持迭代周期在23周scrum的一個sprint的周期一般為26周，xp的一個迭代長度則大致為12周。敏捷開發(fā)的基本思想就是迭代和循序漸進(jìn)，為保證能盡快提供小型發(fā)布版本，顯然迭代周期越短越好。但是周期越短，一個周期能夠完成的迭代任務(wù)就會過小，不僅導(dǎo)致分割訂單的成本增加，而且持續(xù)集成的壓力也更高，因此綜合兩者，將sprint的迭代周期限制在23周比較好，根據(jù)項目特性確定具體的周期。2.2 根據(jù)優(yōu)先級，集體確定每個周期迭代任務(wù)在每個sprint開始時，需要召開計劃會議來確定沖刺訂單（sprint backlog）。在一個穩(wěn)定而又熟練的團(tuán)隊中，產(chǎn)品負(fù)責(zé)人能夠清楚地分析每個backlo

8、g和每一個成員的能力，能夠輕易確定一個沖刺訂單。實踐中，團(tuán)隊成員可能經(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)隊中的每個成員獨立地對產(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 堅持測試驅(qū)動的開發(fā)，并持續(xù)集成測試驅(qū)動的開發(fā)方式本身具有很多好處，即時的白盒或黑盒測試能夠及時發(fā)現(xiàn)代碼中的b

9、ug，從而及時進(jìn)行修改或者重構(gòu)以改善代碼質(zhì)量，并保證不影響沖刺周期。當(dāng)然，測試驅(qū)動需要手工測試和自動測試并行，代碼首先在本機(jī)進(jìn)行單元測試或集成測試后才能提交到服務(wù)器上，通過對測試服務(wù)器進(jìn)行腳本配置以自動進(jìn)行集成測試。相當(dāng)多的企業(yè)會堅持每日持續(xù)集成，使程序中的缺陷當(dāng)天得到解決。2.5 堅持現(xiàn)場客戶的方式團(tuán)隊對項目領(lǐng)域不熟悉或者存在業(yè)務(wù)重構(gòu)時，現(xiàn)場客戶的作用尤其重要?，F(xiàn)場客戶能夠及時參與團(tuán)隊的每日立會以及其它相關(guān)會議，能第一時間明確沖刺訂單中的業(yè)務(wù)相關(guān)問題，及時給予解答。3 結(jié)語作為主流的敏捷開發(fā)方法，極限編程與scrum都有著廣泛的應(yīng)用實踐。通過對兩者進(jìn)行組合應(yīng)用，能夠有效避免各自缺點，取得更好的實踐效果。參考文獻(xiàn)1 王桐.數(shù)據(jù)分析方法論的革命再不掌握敏捷思維你就out了j.中國計算機(jī)報，2015（15）：39.2 王素芬.軟件工程與項目管理m.西安電子科技大學(xué)出版社，2010.3 （美）kent beck， cynthia andres，著.解析極限編程擁抱變化m.雷劍文，譯機(jī)械工業(yè)出版社，2011.4 （瑞）henrik kniberg，著.硝煙中的scrum和xp我們?nèi)绾螌嵤﹕crumm.李劍，譯.清華大