高玄凌

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

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

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

軟件過程作為軟件工程的基本要素，是決定軟件質(zhì)量好壞以及整個(gè)軟件項(xiàng)目成敗的關(guān)鍵因素。軟件開發(fā)使用的主要傳統(tǒng)模型是瀑布模型，瀑布模型流傳至今，影響深遠(yuǎn)。瀑布模型根據(jù)軟件生命周期，將軟件過程主要分為問題定義、可行性研究、需求分析、設(shè)計(jì)、編碼、測(cè)試、運(yùn)行和維護(hù)等階段，各階段要求有明確的結(jié)果、規(guī)范的文檔以及嚴(yán)格的評(píng)審，階段間有明確的界限，只有上一階段結(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名知名的軟件工程專家聚集在美國(guó)的猶他州雪鳥滑雪勝地，這些不同敏捷方法的支持者經(jīng)過兩天的討論，共同起草了一份《敏捷軟件開發(fā)宣言》，強(qiáng)調(diào)了敏捷軟件開發(fā)的四個(gè)核心價(jià)值觀：“個(gè)體和互動(dòng)高于流程和工具，工作的軟件高于詳盡的文檔，客戶合作高于合同談判，響應(yīng)變化高于遵循計(jì)劃”[2]。這份宣言正式明確了“敏捷”這一術(shù)語，同時(shí)強(qiáng)調(diào)宣言中左項(xiàng)要高于右項(xiàng)。敏捷開發(fā)方法的代表包含了極限編程、Scrum、DSDM、自適應(yīng)軟件開發(fā)、水晶系列、特征驅(qū)動(dòng)開發(fā)等，其中極限編程與Scrum是主流的敏捷開發(fā)方法。

1 Scrum和XP的比較

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 結(jié)語

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

參考文獻(xiàn)

[1] 王桐.數(shù)據(jù)分析方法論的革命—再不掌握敏捷思維你就out了[J].中國(guó)計(jì)算機(jī)報(bào)，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